WAV vs. FLAC vs. AIFF

Al:

Thanks for the clarification. I've read the same elsewhere and it seems to all boil down to the competition for power and the sound card that goes on inside of a computer. It is not optimized for music playback as currently set up. That's probably the reason why a third party add on like Bitperfect (for those of us with shallow pockets) dramatically cleans up the sound.

Once you have an optimized platform, like a well designed music server, then differences between files should be minimal, at best, when it comes to the better ones. It will be nice when some sort of standardization takes effect so makers can concentrate on perfecting software/hardware and we can just rip and download to our hearts content and sit back and enjoy.

I have yet to hear all that's out there so this is conjecture, on my part, but it seems to make sense.

Al the best,
Nonoise

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.