I’m looking for opinions on the audio quality difference between a Qobuz streamed high res FLAC verses the download purchase of same album in the same high res. but in AIFF format. Is there a big difference in your opinion?
I’m one who believes uncompressed (AIFF) wiill always sound better than compressed (FLAC) but how much better is the question.
Sure, compressed files need to be uncompressed in real time during playback which can potentially lead to minute timing errors. Where as the uncompressed file doesn’t need to do that. This is also one of the reasons why professional studios never use compressed files.
I suppose timing errors in the context of a recording studio means delays between diferent signal paths. There it makes sense to have minimal delays when you do multi-track recordings, have artists playing live to already recorded parts etc. timing is crucial. In a listening setup without need on timing beyond that all your speaters or drivers are served in sync, maybe also in lip sync to TV or video material, timing is much less of an issue. All streaming systems produce a delay between when a bit is read from media drive to when it arrives at the endxpoint. They do not stream bits but packets, which by nature produces delay. This delay can be between a few ms and seconds. Important is that different paths to different speakers or even to different drivers are in sync within audible ranges, I would say 20us. To be lip sync delays between audio and video can be around 20ms. This is way sufficient for decompression algorithms. Roon doesn’t need to be lipsync as there is no way to have any signal/data input except the integrated streaming services and the local library. These inputs cannot be composed or merged together. So Roon is allowed to introduce an overall delay in the range of 100ms without being perceived as not immediate. This is currently with v. 1.6 what many perceive as annoying that the streaming services do not deliver the meta data and the music streams within 100ms but only within seconds. In conclusion decompression delays in a home reproduction system would only be a problem when they would produce delays between signal paths that are used together, i.e. left and right channel or multidriver or multispeaker setups and have delays of more than 20us. Of course everyone has the right to say the shorter the delays are the better.
This really makes no sense. Roon buffers the music file after is has been decompressed and converted to PCM. The buffer is certainly larger than the ever so small delay that decompressing a FLAC would create versus reading an uncompressed AIFF or WAV file. Roon is using USB to transfer the song data to your M Scaler. That is a buffered process that is not sensitive to the decompression time delays you are worried about.
If you really want something to think about. Note that FLAC files are about half the size of WAV files. The time it takes to read a WAV file and convert it to PCM is about the same time it takes to read a FLAC file, decompress it, and convert it to PCM.
I believe the latency between L and R in a stereo signal should ideally be zero. 20us is ok for lip sync or two systems playing in different rooms at the same time.
If I understand this correctly there is ‘processing’ involved for both AIFF, WAV and FLAC. AIFF and WAV is basically the same, but (modern) AIFF is litte endian and WAV is big endian while FLAC obviously needs decompression before the result is converted to PCM. @brian should be able to educate us here if he has time…
I have compared a streamed flac track to a purchased AIFF track and the AIFF certainly sounds better to me and seems to overall (for lack of a better word) breathe better. I don’t think it’s something that everyone will necessarily notice but if you do an A/B test it may be an eye opener.
There’s a good possibility you’re not comparing apples with apples. FLAC encode the AIFF file then compare the md5 of the audio stream (it’s embedded in the resultant FLAC) with the FLAC you felt sounded inferior. If the md5’s differ you’re not dealing with the identical audio stream.