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.
[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 .
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.
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
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.
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?
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.
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.
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.