Thanks for the revealing analysis, Bruce!
Lest people draw the wrong conclusions about FLAC, I'd like to discuss this finding a little more:
2. Whether Naxos is doing it or the individual DSP's, someone is mucking around with your files. You can see the different file sizes, which means they are using different data compression ratios for the FLAC files.
Let me start by saying Bruce's conclusion is 100% accurate (someone is definitely mucking around with the files), however I'm concerned that people might misinterpret FLAC's "data compression" with sound compression algorithms, especially given the context Bruce provided (the pictures showing audibly compressed and damaged waveforms).
I've always understood FLAC to be a 100% lossless compression algorithm, but I've heard lots of speculation as to whether or not it impacts the resulting sound, etc. I'm going to posit that FLAC is
not the problem and will seek to demonstrate that to you all here. I'm also not asserting that Bruce is suggesting that FLAC is in any way a problem. More on that later.
Bruce's observation is factual and sensible. Smaller FLAC files will cost you less to distribute than larger ones. If the compression is truly lossless, then it behooves you to crunch every file down to its smallest possible size. Lower cost for you + faster download for the end consumer + no loss of quality = everybody wins.
To prove the "Lossless" part of FLAC's "Free Lossless Audio Compression" to myself, I did a round-trip experiment with a hi-res PCM (DXD) file of
Nidarosdomens jentekor & Trondheim Solistene's "Arnesen: MAGNIFICAT 4. Et misericordia". I performed the following steps:
- Convert WAV (DXD PCM) -> FLAC with flac tools 1.3.1 at compression levels 0 (lowest), 3, 6 ('recommended'), and 8 (max)
- Convert the resulting FLAC files -> WAV (again with flac tools 1.3.1; this is known as a "round-trip" conversion and the output WAVs from this step should be identical to the INPUT WAV (DXD) from step 1. Incidentally, this conversion is the same thing that happens when you "play" a FLAC file. The FLAC is first "de-compressed" into the original WAV (raw PCM data) and fed to your DAC.
Analysis:
Resulting files & sizes as follows:
Code:
624,907,628 2L-Magnificat.wav (ORIGINAL file given as INPUT to flac encoder)
483,149,157 2L-Magnificat.0.flac ("0" compression - lowest)
423,566,900 2L-Magnificat.3.flac ("3" compression)
409,314,887 2L-Magnificat.6.flac ("6" compression - recommended)
400,708,221 2L-Magnificat.8.flac ("8" compression)
624,907,628 2L-Magnificat.wav (ORIGINAL file given as INPUT to flac encoder (same as above))
624,907,628 2L-Magnificat.0.wav (from Magnificat.0.flac)
624,907,628 2L-Magnificat.3.wav (from Magnificat.3.flac)
624,907,628 2L-Magnificat.6.wav (from Magnificat.6.flac)
624,907,628 2L-Magnificat.8.wav (from Magnificat.8.flac)
Interpretation:
Output file size comparison suggests reveals the "round-tripped" files are probably identical regardless of compression level used. This data supports FLAC's claims that the compression level only impacts the amount of time it takes to compress the files, and the compression is truly "lossless."
Analysis:
Looking deeper, we can do a bitwise comparison of the file contents with a command-line tool that is built into Windows called "FC" (file compare):
Code:
>fc /?
FC [/A] [/C] [/L] [/LBn] [/N] [/OFF[LINE]] [/T] [/U] [/W] [/nnnn]
[drive1:][path1]filename1 [drive2:][path2]filename2
FC /B [drive1:][path1]filename1 [drive2:][path2]filename2
/A Displays only first and last lines for each set of differences.
/B Performs a binary comparison.
.
.
.
File Compare will let us do a binary (bitwise) comparison and will tell us (bit-for-bit) if there are any differences whatsoever between two files. Here are the results of comparing the SOURCE wav file with the ROUND-TRIP resulting WAVs:
Code:
>for /R %i in (*.?.wav) do (fc /B 2l-magnificat.wav %i)
>(fc /B 2l-magnificat.wav C:\Users\Jeremy\Desktop\2L-Magnificat.0.wav )
Comparing files 2L-Magnificat.wav and 2L-MAGNIFICAT.0.WAV
FC: no differences encountered
>(fc /B 2l-magnificat.wav C:\Users\Jeremy\Desktop\2L-Magnificat.3.wav )
Comparing files 2L-Magnificat.wav and 2L-MAGNIFICAT.3.WAV
FC: no differences encountered
>(fc /B 2l-magnificat.wav C:\Users\Jeremy\Desktop\2L-Magnificat.6.wav )
Comparing files 2L-Magnificat.wav and 2L-MAGNIFICAT.6.WAV
FC: no differences encountered
>(fc /B 2l-magnificat.wav C:\Users\Jeremy\Desktop\2L-Magnificat.8.wav )
Comparing files 2L-Magnificat.wav and 2L-MAGNIFICAT.8.WAV
FC: no differences encountered
Interpretation:
WAV->FLAC->WAV ("round-trip") bits are IDENTICAL regardless of compression level.
Visual & Aural Analysis
For those who prefer it in pictures, I loaded the original WAV and the round-tripped level "8" (the most highly compressed (which should show the most deviation if any was to be found)) WAV into Audacity:
View attachment 20607
The original is on top. The WAV->FLAC(8)->WAV result is on the bottom.
I also listened to them both through a pair of highly-resolving Sony MDR-Z7s, a LH Labs Geek Out 1000 DAC, and a pre-production MIT Labs Vero Reference headphone cable (which I have on loan).
Interpretation
Visually the waveforms appear identical.
Sonically the waveforms sound identical.
Re-Compression
Lastly, some people might wonder what happens if you further FLAC compress a FLAC file. I was too, so I took my "0" level compression file and squeezed it down to an "8" level file and then did the round-trip and compare. The significant output follows:
Code:
>flac -V -8 2L-Magnificat.0.flac -o 2L-Magnificat.0-8.flac
2L-Magnificat.0.flac: Verify OK, wrote 400708221 bytes, ratio=0.829
>dir *flac
483,149,157 2L-Magnificat.0.flac (INPUT file, created with "0" compression)
400,708,221 2L-Magnificat.0-8.flac (OUTPUT file, created with "8" compression)
>flac -V -d 2L-Magnificat.0-8.flac (converting FLAC to WAV)
>dir *wav
624,907,628 2L-Magnificat.wav (SOURCE file)
624,907,628 2L-Magnificat.0-8.wav (from 2L-Magnificat.0-8.flac)
>fc /B 2L-Magnificat.wav 2L-Magnificat.0-8.wav
Comparing files 2L-Magnificat.wav and 2L-MAGNIFICAT.0-8.WAV
FC: no differences encountered
So, there we have it. No difference in a "re-compressed" FLAC file either.

(The eagle-eyed ones will have noticed that the file size of this "2L-Magnificat.0-8.flac" file and the "2L-Magnificat.8.flac" file are also identical... and as you might suspect a FC will reveal that there are no differences there. The FLAC algorithm is internally consistent.)
Conclusions:
FLAC compression, re-compression, and decompression at any level does not affect the resulting PCM data at all.
FLAC should not be held accountable for the any perceived or actual differences in the waveforms that Bruce discovered.*
* (
Please note: I'm not asserting in
any way that Bruce was ever trying to suggest otherwise; I'm trying to ensure that people don't draw the
wrong conclusions from the data Bruce offered or use this data to give FLAC a "bad name." FLAC is not nor ever was the problem here!)
The following points Bruce raises are very much worthy of deeper investigation:
3. Also whatever they are using is altering the sonics because of the different loudness, which is audible. You can see this by Min/Max Sample values, RMS value and such.
4. There are different filter algorithms, taking out the noise compared with the waveforms of the original/DSP 3 and the others.
Someone needs to take these file vendors to task and let us know who is honoring Bruce's (and others') amazing efforts to give us the highest possible quality music... and who is not. People are mucking about with Bruce's work and that's deeply unsettling to me as a consumer. I've spent non-trivial money on just about every reputable download vendor. It would be nice to know I've got the "real deal" and not some filtered, squashed, mangled version of the music I paid for.
The way forward...
Let's focus our attention on the real culprit: a lack of integrity with regard to how our music is being processed by the various vendors. I'm not a supporter of DRM, but in this particular case what I would advocate strongly for is
digital signing. It would be a boon to the consumer if a mastering engineer like Bruce could digitally "sign" his work in a manner that is easily verifiable by the end consumer (such that
any tampering with the file would cause signature validation to fail). Then consumers would have a way of knowing whether or not the file they got was "mucked with." I've got some ideas on how to achieve this in a non-burdensome manner, but I'm keeping it close to my chest for now.
I'd like to thank Bruce for bringing this information to light. What an unsettling discovery!
I'd also like to thank tailspn and nativedsd.com for the transparency about how they're processing the files and their pledge to do no harm do the music data therein. These are the kinds of policies and processes we need (en masse) to ensure that customers are getting what they're paying for!
Shouldn't music be "worry free"?
