Why do Wav and Flac Files Sound Different?

The gist of this thread had to to with the possibility that any metadata was a potential pollutant of the musical information. When I used to download albums from allflac.com removing the "cover" file from the track list before loading it into JRiver would nix the cover art showing up in the thumbnail header for the albums which seems to indicate that this data was no longer involved in the track files. Not the case with Quobuz. None of this may matter sonically. Or it might in some small. way.

OP:

The metadata and audio are separate. They share a file, but it’s not as if the album cover art is being sent per musical frame. It is in a different location, along with all the credits, so once the music starts to play, it is completely out of the picture. At best, these should could cause picoseconds of delay in starting to play the music, but zero when playing has begun.

HDCD and MQA however are interwoven into the music data itself.

It does take a little more CPU power to decompress FLAC or ALAC vs. WAV, which is going to take more network time, but if your player sounds different, it's messed up.

Interesting. I wasn't aware there were different levels of compression available in FLAC. I used the default in Exact Audio Copy when I ripped to an external hard drive and don't know what setting that is. I wonder if that is why I hear difference between FLAC and WAV on replay.

Jim S.

@erik_squires

Maybe I’m reading something into your last message, but can you explain what HDCP has to do with FLAC v. WAV?

I’m not trying to hassle you, this is an honest question posed to an obviously knowledgable colleague.

FWIW, this is a topic long of interest to me. I wrote some lengthy articles about digital copy-protection the topic for mainstream tech publications back when the first round of DVD CP standards emerged, and at the time, HDCP’s only application for audio had to do with DVD-Audio media (and then hirez SACD DSD-encoded stereo).

I understand that today HDCP is incorporated into HDMI/DVI/etc.-transported signals, but that would not distinguished between FLAC & uncompressed PCM content.

Btw, +1 re: your comments about metadata being processed independently of digital-audio content. Jeez. Yes, nothing’s impossible, but Sagan’s Law ("extraordinary claims require extraordinary proof") applies here.

D

@stilljd - The FLAC compression levels are aspirational. Think of them more as setting how much time to spend attempting to compress a song, more than how much they will compress a song.

That is, as you increase FLAC compression it spends more and more time to compress the data, but may not actually be able to do so.

@cundare2 No offense is taken.

HDCD was a way of encoding a variety of features into a 44.1 kHz/16 bit signal, most famously it was a way of encoding 24 bit data into 16 bits. This compression did in fact affect the original music, in the sense that the original 44.1 kHz/16 signal was no longer bit identical as it now had information encoded about dynamic range. HDCD was complex and encoded more features than just this.

MQA is also not a bit-perfect conversion. It attempts to encode in a low resolution signal (44.1/48.1, etc) high resolution content (96 kHz/24, or higher).

In the case of HDCD or MQA you are left with 44.1 kHz/16 bit data which is no longer bit-perfect of the original.

On the other hand, ALAC, FLAC and WAV formats though result in exactly the same bit-perfect signal resulting from decoding their files. Conversion between them to each other should result in exactly the same set of 44.1 kHz/16 bit data streams (if that’s what you started with). How they handled metadata might be different but in all cases the metadata is NOT encoded into the music stream.