flac dev - Jul 2015 - FLAC implementation in Windows 10

On Jul 14, 2015, at 8:18 AM, Declan Kelly <flac-dev at groov.ie>
wrote:
> On Mon, Jul 13, 2015 at 01:28:22PM +0200, mvanb1 at gmail.com wrote:
>> FLAC is not the only one though, Apple Lossless has been added 
>> to the mix in the same way, but (properly) creates smaller files.
> 
> Can anyone on the list (possibly someone who works for MSFT) get this
> fixed before Win10 is released?
What size differences are we talking about? How many types of files are
affected? What is the percent difference in size for the typical file?

Brian

Op 16-07-15 om 07:50 schreef Brian Willoughby:
> On Jul 14, 2015, at 8:18 AM, Declan Kelly <flac-dev at groov.ie>
wrote:
>> Can anyone on the list (possibly someone who works for MSFT) get this
>> fixed before Win10 is released?
> What size differences are we talking about? How many types of files are
affected? What is the percent difference in size for the typical file?
The files are typically slightly larger than FLAC 1.3.0's -0 
setting (compression level 0), usually within 1%. This means 
that there is a difference of 6 percentage points (10%) with the 
default -5 setting in filesize.

I just updated to the latest version (which is rumoured to be 
the RTM), it has the same issue. That means it won't be fixed 
before the release. I wouldn't bother though, I think it's 
already quite a feat Microsoft decided to implement both 
decoding as well as encoding support.

On Jul 18, 2015, at 10:46 AM, Martijn van Beurden <mvanb1 at gmail.com>
wrote:
> Op 16-07-15 om 07:50 schreef Brian Willoughby:
>> On Jul 14, 2015, at 8:18 AM, Declan Kelly <flac-dev at groov.ie>
wrote:
>>> Can anyone on the list (possibly someone who works for MSFT) get
this
>>> fixed before Win10 is released?
>> What size differences are we talking about? How many types of files are
affected? What is the percent difference in size for the typical file?
> 
> The files are typically slightly larger than FLAC 1.3.0's -0 
> setting (compression level 0), usually within 1%. This means 
> that there is a difference of 6 percentage points (10%) with the 
> default -5 setting in filesize.
> 
> I just updated to the latest version (which is rumoured to be 
> the RTM), it has the same issue. That means it won't be fixed 
> before the release. I wouldn't bother though, I think it's 
> already quite a feat Microsoft decided to implement both 
> decoding as well as encoding support.
I agree. It's far better for Microsoft to support any FLAC commands,
hard-coded or not, than to not support FLAC at all. In contrast, Apple
hasn't made it terribly easy to support FLAC in iTunes or any other
simplified audio applications.

There might even be a good reason for Microsoft to use the lowest compression
level: it probably takes less CPU to compress and decompress, compared to the
maximum compression ratios.

In a similar, but not exactly equivalent comparison, Apple enables Sample Rate
Conversion for music playing through iTunes, but they did not select the highest
quality conversion available in CoreAudio. Instead, Apple seem to have favored
the quality level that uses the least amount of CPU. It's probably true that
casual music listeners far outnumber audiophile listeners, and thus it makes
sense for the simplest features to favor minimal CPU rather than maximal
quality. Perhaps Microsoft decided not to showcase the best that FLAC can do in
terms of compression efficiency, but rather to select the best that FLAC can do
in terms of minimal CPU impact. In both cases - Apple SRC and Microsoft FLAC -
power users have an option for manual access to high performance options, but
they have to use third-party software instead of the simplified built-in
software.

I don't want to be an apologist for either Microsoft or Apple, but there are
other preferences in the computer-user world than our own.

Brian Willoughby