WAV vs. FLAC vs. AIFF

Okay, here's my hypothesis:

When using networked servers, such as Sonos and Logitech, the decoding processes of FLAC and ALAC have plenty of time to execute because the other processes are not real-time. This is because the networked stream is packetized and transmitted very quickly, and does not get involved with the S/W audio stack in the computer. The data processing in the computer is minimal and happens very quickly making the latency very low for these transfers. This allows the CODEC to run as slow or fast as it needs to run to achieve accurate results. As a result, the sound quality differences with these lossless formats is usually minimal if even detectable when using network protocol.

On the other hand, when you use Firewire or USB for data streaming, some of the audio stack is involved and the CODEC must run in real-time and keep-up with the stream rate. Because the audio stack creates a lot of latency, even when playing uncompressed files, there is evidently not much time left for FLAC decoding to keep up with the bit stream. As a result, the timings are very tight and sound quality suffers as a result. This is why I believe on a resolving system using USB or Firewire, FLAC files sound like listening through a tunnel and the same FLAC uncompressed to .wav sounds normal. I dont know if this is a result of poor programming for the FLAC and ALAC CODECs or maybe just the way that they execute when they are competing for resources and repeatedly queue and stall in the execution sequence. With multi-threading in computer OS now, these applications dont run continuously ever.

There is a lot of anecdotal evidence to support the above hypothesis. I have no technical proof however.

Steve N.
Empirical Audio

Steve - I am using flac files, running J River from memory and with less than 5% CPU usage on Windows 7 and an async USB converter. Do you still think that the PC cannot keep up with a async USB converter in that case? I would guess J River can keep the memory buffer full. Are you suggesting that there can be enough latency in WASAPI event mode to cause timing problems with an async USB converter?

DTC - I believe the problem is latency and interference, not CPU usage. When the core audio stack interferes with smooth execution of the FLAC CODEC, this is where the problems start.

Has nothing to do with async USB converter and delivering data to that.

Have you tried changing the FLAC file back to .wav with dbpoweramp and compare the two tracks by listening?

Steve N.
Empirical Audio

First, sorry for moving the discussion to the age old jitter, timing discussion.

Steve - I do understand everything that is going on. I belive the flac codec is filling a buffer, in my case the memory buffer for J River. I am assuming that J River decompresses the flac before it goes into memory, but that might not be the case.

If the audio stack delivers in real time, rather than through a buffer, then the question seems to be what the async driver (like the M2Tech one you use) is actually doing. My assunmption was that the async driver is drawing from a buffer, not from real time delivery of data from the Windows audio stack. That may be incorrect. Do you have enough details on the async drivers to know if process swapping can actually effect the async driver significantly? If there really is a problem there, then improving the clocks in async converters should not be important. It is a complicated process. I probably just do not have enough detail on the audio stack/asyn driver to understand why flac decoding (or any other running process) should interfer with the async driver timing.

I am not trying to be argumentative. I just do not understand the internal details of what is actually happening.

I do not hear a difference between wav and flac files. But I believe my DAC also reclocks so that may be the determing factor.

I have not done extensive comparisons, but .wav and flac seem to be a wash in terms of inherent sound quality due to format alone. The difference is what is done with teh format, ie how well the recording is made and how well delivered during playback. Just like CDE, vinyl or any other format, recording quality will range from very bad to very good.

The main considerations are compatibility with your gear and how you will handle metadata/tagging.

flac is better for flexible metadata and tagging over time, if that is something you really want to spend time doing. Personaly I do not. I mostly use .wav and make sure the metadata is correct before ripping. This approach works well ripping with Windows Media Player (good quality rips possible and is included with most WIndows computers) and using Logitech MEdia Server (formerly Squeezeserver) as the music server for Squeeze or other compatible devices . The caveat is thatyou cannot change metadata tags (artis, album, title, etc.) once ripped with .wav. You have to redo the rip with new metadata to make a change, which is pretty easy assuming you actually have access to the original CDs ripped when needed. I recommend keeping your CDs as archived versions of your music and for reference as needed. Do not rip and then get rid of the CDs. You might regret it later.

You need to pick another program to rip .flac, but once you do, then that format works well for editing tags when needed and also sounds good with the Logitech/Squeeze system.

Beware of any conclusions drawn about sound quality differences between formats based on a limited test sample. any results are possible. In teh end, I believe the format to be essentially a wash in regards to how good it can sound.