Oh my, if one were to do a little searching from many years ago, one would find heated arguments about whether WAV and AIFF sound different, and if so, which sounds better. It was borderline hilarious. Or pathetic. Take your pick. I tried to hear a difference and could not. I stuck with AIFF for much easier and richer metadata, though I believe that most, if not all, of that difference has gone by the wayside.
Hi Greg,
Yeah… I was afraid that could happen with this one : )
A good expression, and frequent occurence (alas) in audio discourse is having the conversation go “off the rails” ; )
If you were ripping a collection today, with no legacy files to worry about, what would you rip to and why?
(I’m thinking of ripping to AIFF and wanted to know if folks suggest WAV? Per above, I don’t know what the difference is, or if the choice matters)
Thx!
I’d probably just stick with AIFF. It’s what I know. Never let me down.
“If you were starting over what would you do,” is a great question.
I wonder what our answers (mine would be “FLAC again”) depend on, though.
- If you’ve had problems (as Greg hasn’t, happily)
- If you’re now short on storage space (why it’s a good idea to go bigger than you need with disks)
- If your initial concern about storage space hasn’t proven a problem after all (disks should get cheaper)
- If you now realise that new equipment means you CAN hear a difference (this was me from a high bitrate MP3 to lossless)
For me, one of the bullets I’ve not listed would be:
- The dread I feel at the thought of doing it all over meaning that there’s no chance of my answer being entirely honest
1 Like
FLAC is specifically designed for efficient packing of audio data, unlike general-purpose lossless algorithms. FLAC is able to reduce the size of audio data by 40–50% by taking advantage of the characteristics of audio.
The technical strengths of FLAC compared to other lossless formats lie in its ability to be streamed and decoded quickly, independent of compression level.
Since FLAC is a lossless scheme, it is suitable as an archive format for owners of CDs and other media who wish to preserve their audio collections. If the original media are lost, damaged, or worn out, a FLAC copy of the audio tracks ensures that an exact duplicate of the original data can be recovered at any time.
FLAC is an open format with royalty-free licensing and a reference implementation which is free software. If ever Apple decides to drop or alter their AIFF specs, you might be in trouble.
3 Likes
Merry Christmas everyone!
@Ermos, in @all2ofme’s post in this chain a few days ago, uncompressed FLAC was +/- 1% of AIFF and WAV, which makes sense to me, not -40-50%.
Have you tested this Ermos?
Uncompressed FLAC is pointless. FLAC is intended for efficient packing of audio data, lossless.
I hope you understand this, and it makes sense to you.
1 Like
[quote=“Ermos, post:46, topic:2082”]
Uncompressed FLAC is pointless. FLAC is intended for efficient packing of audio data, lossless.
[/qu
No, it is not pointless. Many users report inferior sound from compressed FLAC in comparison to .wav files. It seems that in some replay situations there are latency issues arising from decoding compressed FLAC files on the fly. This problem is avoided by using uncompressed FLAC. So why not use .wav instead? The reason is that .wav has no inherent provision for retaining metadata. You can only associate a separate metadata file with a .wav music file. A FLAC file, however, actually contains the metadata within a recognised protocol i.e. ID3. Thus by using uncompressed FLAC you have a file that is the equivalent to a .wav file without any decompression on the fly issues yet also have the superior metadata handling of FLAC. I have already said this above .
1 Like
I believe thats a long held audiophile myth - that compressed FLAC files are somehow inferior sounding because of the processing requirements of uncompressing the FLAC file.
That may have been true maybe decades ago, but the reality is that a modern day processors can receive and uncompress a FLAC file faster than a full WAV file can be transmitted. 
IMHO, on a dCS system, there’s no difference in sound quality between a compressed FLAC file versus a WAV file from the same source.
1 Like
Anup all I can say is that I have test files of the same material in .wav and various compression levels of FLAC. With some replay configurations e.g. JRiver running on a Win 10 PC into both Paganini and Vivaldi v.1 DACs the compressed FLACS sounded notably ( repeat, notably) inferior to the .wav versions. Not decades ago and clearly audible.
However changing to Network Bridge/Mosaic/Vivaldi v.2 ( Map 1) I could hear no difference. A good result but one that persuaded me that compressed FLAC is not the best choice for archive storage as I cannot guarantee that I may have the advantage of Vivaldi 2 or equivalent in the future. Further Bartok owners do not have the double speed processing of Rossini 2 or Vivaldi 2 so my observations may still be relevant to them.
Was this over USB? I’d venture a guess that something else is going on that caused it to sound different. Possibly even from differences in how the streaming software (JRiver) handles FLAC versus WAV in the past.
With current Ethernet based streams via UPnP or Roon RAAT, theres absolutely no technical reason why FLAC would sound inferior to WAV.
On dCS systems, the stream board ARM process[or] won’t even break a sweat handling a FLAC file, and by the time its unpacked and exits the stream board as an I²S stream into the FPGA, they’re identical 
1 Like
I am sure that you are right. As I confirmed I can replay compressed FLAC files with no audible difference to uncompressed ones. However this is not necessarily always the the case if the conditions for doing so (such as you mention) are not available to the listener.
I was only pointing out that the issues experienced by me in a past system and reported by many other listeners occur " in some replay situations". Those replay situations are not mythical. I am suggesting that one can sidestep this issue entirely by using uncompressed FLAC which retains the metadata handling advantage of the codec.
Pete, it might seem like a good idea to FLAC encode without compression to avoid any sonic impact, but the process of decoding a FLAC file is relatively independent regardless of how the file was encoded.
You’ve probably read widely that the FLAC coding process is asymmetric in nature; it takes a lot less CPU cycles (and time) to Decode than it does to Encode. What’s less commonly known though is that the decoding process is very efficient and relatively independent of the compression level.
Let me show you what I mean. I’ll take a 151MB .WAV file (Diana Krall’s “The Christmas Song”) and encode it into 3 different FLAC files; with no compression (.flac), with compression level 0 (.flac0), and with compression level 8 (.flac8).
Most people would assume decoding the 3 files would vary significantly, but thats not the case. Have a look, I’ve included file sizes and time-stamps for each of the encoding and decoding processes.
In fact, notice that it took 0.08 seconds longer to decode the no-compression FLAC file then it did the compression-level 0 file. This makes sense when you refer back to the file sizes; the no-compression file is about 50% larger, so it takes longer to load for decoding - this effect is even more pronounced on FLAC streaming decodes!
In other words, it’s not such a good idea to encode CDs with no-compression FLAC. 
2 Likes
Now that’s fascinating.
Thanks for posting this detailed information @Anupc. I’d like to break down your comments to make sure I understand:
(1) “In fact, notice that it took 0.08 seconds longer to decode the no-compression FLAC file then it did the compression-level 0 file.”
Ok, yes I see this, thank you.
(2) “This makes sense when you refer back to the file sizes; the no-compression file is about 50% larger, so it takes longer to load for decoding - this effect is even more pronounced on FLAC streaming decodes!”
This comment mixes two ideas, loading and decoding. How do we know which took longer, and if the loading takes longer, this could imply the decoding is faster. It is presently (at least in this thread) indeterminate.
(3)In other words, it’s not such a good idea to encode CDs with no-compression FLAC.
Not sure I am there yet with the logic flow above. Why does FLAC even offer no compression? What was the motivation behind offering it in the first place?
FLAC in “no compression” mode makes no sense at all.
If you like to understand why, you may need to read this:
2 Likes
In fact, it includes 3 aspects; the reading time of the FLAC file off the HDD, the actual decoding process time, and the writing time of the .wav output file to the HDD.
With the Time utility alone we can’t say for sure what the reading/writing times are versus the actual decoding process time. However, we can deduce it by elimination;
-
since the output .wav files are all identical in size, we can eliminate the writing times in the deltas between the 3 decodings
-
it’s safe to assume that the actual decoding process time for the no-compression FLAC is, at worst, the same as that for compression level-0. That being the case, the time delta between the two (0.072 seconds to be precise) is in essence the extra time taken to read the 50% larger (no-compression) FLAC file off the HDD.
In any case, my main point with that flac decode demonstration is that the overall decoding time difference between no-compression FLAC and full compression FLAC is small, contrary to what some might imagine, and the fact that the time-difference becomes significant due to the file sizes, rather than the actual decoding time.
Your guess would be as good as mine 
1 Like
As per the Github thread linked above:
A FLAC compression level “no compression” is basically an uncompressed PCM track (.wav) in a flac container, and offers these possibilities:
- .wav files could potentially be neglected altogether
- tagging features, replaygain etc. of flac could be used throughout the lossless PCM collection
- postprocessing could be more generalized (less filetypes) in some cases
- some might use it for this or for test purpose
2 Likes
Erno, thanks for that link. Interesting reading. In addition to the “makes no sense” theme (with a nod to the metadata advantage of wrapping a .wav file in a FLAC container), I found this comment interesting:
The original author of the FLAC algorithm left the project almost 10 years ago. Those of us who like @lvqcl maintain this code, do the best we can. @lvqcl in particular has done a lot of work to optimize the FLAC code for recent Intel CPUs and helped with Windows support.
1 Like
I found that interesting too, but misread it. I interpreted it as the subset of people who enjoy @lvqcl’s company being the ones doing the maintaining, rather than @lvqcl being one of the people cutting code.
<— Venn diagram of “reading too quickly” and “absent punctuation” goes here.
Love that so far no-one is lamenting their choice of codec and that seemingly illogical differences in sound are dropping away with new hardware and software releases (such as @PAR’s Vivaldi v2 update). Will be interesting to see what else that happens to in the next few years.
2 Likes