[flac-dev] FLAC implementation in Windows 10

Brian Willoughby brianw at audiobanshee.com
Sat Jul 18 15:16:56 PDT 2015


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



More information about the flac-dev mailing list