Jump to content
IGNORED

Why do WAV and FLAC files Sound Different


Recommended Posts

But not to everyone's and not on everyone else's systems - some of which are probably much more resolving than yours. (And of course, some are not... didn't mean that as a cut, just that it isn't a question of resolving, or how good or bad one's ears are...)

 

The problem is that we don't know if your results are because of the conversion, or because your system is running on a high resolution low powered processor, or because you put them on different media, or because of <fill in the blank>.

 

I certainly have no problem believing you hear a difference, but I find it very very unlikely indeed that if your conversion software was operating correctly, that the files themselves are responsible for the difference. By that, I mean more precisely, the second WAV files WAV -> FLAC -> WAV, should be identical to the first, save perhaps for timestamp data. If that was not the case, then we can point to your conversion software as the culprit.

 

Elsewise, it is more mysterious. Try copying the file to a different disk, or to a USB thumb drive, and playing it from a different computer. See if the sound changes for you under those circumstances.

 

It would be great to get a fresh view on this age old problem. :)

 

-Paul

 

Until recently I believed that flac was just as good sounding as wav files. A dealer told me he preferred wav and explained why. He said that cymbals e.g. sound less well defined at the start as if something was missing. I asked my wife about this. She is a professional violin player and said that musicians talk about articulation.

Well the dealer suggested to listen to a simple jazz recording with open sounding percussion.

I ripped a CD of the Pierre Favre Ensemble on ECM called Fleuve. I ripped it to flac setting 5 and to wav using the same CD-ROM drive.

Than we listened several times to the opening track Mort d'Eurydice.

We both found the wav version sounding completer and better articulating indeed.

Later that week I redownloaded albums from Qobuz in wav. I consider them better sounding than flac. If I now listen to a flac album I miss something. I do not miss anything with dsd or mqa.

 

Robert-Jan

Robert-Jan

Link to comment
Until recently I believed that flac was just as good sounding as wav files. A dealer told me he preferred wav and explained why. He said that cymbals e.g. sound less well defined at the start as if something was missing. I asked my wife about this. She is a professional violin player and said that musicians talk about articulation.

Well the dealer suggested to listen to a simple jazz recording with open sounding percussion.

I ripped a CD of the Pierre Favre Ensemble on ECM called Fleuve. I ripped it to flac setting 5 and to wav using the same CD-ROM drive.

Than we listened several times to the opening track Mort d'Eurydice.

We both found the wav version sounding completer and better articulating indeed.

Later that week I redownloaded albums from Qobuz in wav. I consider them better sounding than flac. If I now listen to a flac album I miss something. I do not miss anything with dsd or mqa.

 

Robert-Jan

 

it is good you have found a configuration that pleases you, and despite all the ornery comments floating around, if it sounds better to you, then it really does sound better to you. It isn't your imagination. :)

 

Sometime when you are bored, try different playback software and see if the difference still holds - just for fun. You do not and should not be worrying about convincing the rat pack of what you hear on your own system.

 

Yours,

-Paul

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment
The issue with wav and flac files sounding different is probably because of computer generated noise differences.

 

If there is noise, how many dB the computer noise by FLAC higher than by WAV?

AuI ConverteR 48x44 - HD audio converter/optimizer for DAC of high resolution files

ISO, DSF, DFF (1-bit/D64/128/256/512/1024), wav, flac, aiff, alac,  safe CD ripper to PCM/DSF,

Seamless Album Conversion, AIFF, WAV, FLAC, DSF metadata editor, Mac & Windows
Offline conversion save energy and nature

Link to comment
If there is a difference there is no single number. Generated noise will depend on the renderer hardware and the software being used. In general, purpose built renderers, with low noise, are sounding better than general purpose computer boards.

 

Noise hypothesys FLAC vs. WAV easy tested.

 

Noise is fully measurable feature. There may be viewed as integral value across full frequency band (total noise energy), as compared energy of parts of the spectrum.

 

It will interesting information, if somebody show us figures.

AuI ConverteR 48x44 - HD audio converter/optimizer for DAC of high resolution files

ISO, DSF, DFF (1-bit/D64/128/256/512/1024), wav, flac, aiff, alac,  safe CD ripper to PCM/DSF,

Seamless Album Conversion, AIFF, WAV, FLAC, DSF metadata editor, Mac & Windows
Offline conversion save energy and nature

Link to comment
I would be curious to see a latency variation analysis of different patterns in FLAC recording being decoded to output signal. Wouldn't surprise me if there was enough variation by the unpacking algorithm to have some detectable effect below a certain threshold of computational power.

 

If the CPU is fast enough to complete the decoding before the data has to be sent to the DAC, there should be no effect. If it is not fast enough, there will be skips and nasty noises. There's no subtle deterioration. The CPU always executes the same algorithm. It doesn't think to itself, "I'm not keeping up, I'll skip some of the decoding steps."

"People hear what they see." - Doris Day

The forum would be a much better place if everyone were less convinced of how right they were.

Link to comment
If the CPU is fast enough to complete the decoding before the data has to be sent to the DAC, there should be no effect. If it is not fast enough, there will be skips and nasty noises. There's no subtle deterioration. The CPU always executes the same algorithm. It doesn't think to itself, "I'm not keeping up, I'll skip some of the decoding steps."

 

It does, however, think to itself, "He's having a big party, time for vacation."

One never knows, do one? - Fats Waller

The fairest thing we can experience is the mysterious. It is the fundamental emotion which stands at the cradle of true art and true science. - Einstein

Computer, Audirvana -> optical Ethernet to Fitlet3 -> Fibbr Alpha Optical USB -> iFi NEO iDSD DAC -> Apollon Audio 1ET400A Mini (Purifi based) -> Vandersteen 3A Signature.

Link to comment
If the CPU is fast enough to complete the decoding before the data has to be sent to the DAC, there should be no effect. If it is not fast enough, there will be skips and nasty noises. There's no subtle deterioration. The CPU always executes the same algorithm. It doesn't think to itself, "I'm not keeping up, I'll skip some of the decoding steps."

 

As far as I am aware no clock timing is attached to a wav or flac data sample until after its handed to the CPU for transmission to the DAC. What mechanism in the CPU would care if the data was delayed by a cycle in decoding for DAC hand off? Algorithms are software, which then gets into what does the application level support vs what is handled by hard coded chip logic. My general impression after much PC tinkering is that the relationship between CPU processing and attaching clock isn't a hard relationship, given that you can improve clocking output accuracy by reducing running processes and disabling unneeded devices in a PC

Regards,

Dave

 

Audio system

Link to comment

Playback algorithm is:

 

It work on level of audio player software.

 

 

Main code:

1. Put several portions (processed in code A) to operation system's buffer.

 

2. Wait for DAC's (audio programming interface) request (just empty next portion).

 

3. By the request launch code A (an audio processing).

 

4. Go to step 1.

 

 

Code A:

 

1. Read data from HDD,

 

2. There are 2 and more new requests?

 

2.1. YES. Interrupt code A.

 

2.2 NO. Goto step 3.

 

3. Process it (FLAC decode, etc.)

 

4. There are 2 and more new requests?

 

4.1. YES. Interrupt code A.

 

4.2 NO. Send processed data to DAC.

 

 

Code A may work independently Main code (it called "they works in different threads").

 

 

 

If Code A work inside Main code steps 2 and 4 may be excluded.

But for this case we lost control under the DAC's requests. And operation system's buffer may be full empty.

 

 

On certain player's implementations at interruption code A may be sent emty portion with zeroes or with last sent level values.

 

It will sound as coarse distortion (clicks, sound interruptions, sometimes fast periodical).

 

If don't put dummy portion and the operation system's buffer is empty, there DAC "empty buffer behaviour" will out a player software control.

 

And interruption of input stream processing performed by DAC.

 

There may be performed either freeze output level or auto fade out to zero or set zero.

 

Simple set to zero give click when data interrupted.

 

When next portion appear may be click too in case of big level difference.

AuI ConverteR 48x44 - HD audio converter/optimizer for DAC of high resolution files

ISO, DSF, DFF (1-bit/D64/128/256/512/1024), wav, flac, aiff, alac,  safe CD ripper to PCM/DSF,

Seamless Album Conversion, AIFF, WAV, FLAC, DSF metadata editor, Mac & Windows
Offline conversion save energy and nature

Link to comment
As far as I am aware no clock timing is attached to a wav or flac data sample until after its handed to the CPU for transmission to the DAC.

 

Correct. There is only a sample rate provided in the file header.

 

What mechanism in the CPU would care if the data was delayed by a cycle in decoding for DAC hand off?

 

None. Nor does the DAC care exactly when a sample was placed in the buffer provided it happened before said sample is read by the DAC or whatever is feeding it (USB etc).

 

Algorithms are software, which then gets into what does the application level support vs what is handled by hard coded chip logic. My general impression after much PC tinkering is that the relationship between CPU processing and attaching clock isn't a hard relationship, given that you can improve clocking output accuracy by reducing running processes and disabling unneeded devices in a PC

 

There's a buffer between the decoder software and the DAC. This buffer is divided into two or more segments. Whenever the DAC is done playing a segment, it notifies the OS/application which can then start writing freshly decoded samples into that segment. The DAC then moves on to the next segment. If the decoder is fast enough, the new segment will already be filled with fresh samples. If not, the old samples get played again. This is generally very obviously audible.

 

As for clocking, the DAC has a fixed clock (usually a crystal oscillator separate from the rest of the system). Whatever the CPU is up to, the DAC simply loops over the sample buffer, firing an interrupt each time it completes a segment. If the OS crashes, you sometimes get the last 10-100 ms of audio repeating forever. This is because the DAC simply doesn't care about the software.

Link to comment
Correct. There is only a sample rate provided in the file header.

 

 

 

None. Nor does the DAC care exactly when a sample was placed in the buffer provided it happened before said sample is read by the DAC or whatever is feeding it (USB etc).

 

 

 

There's a buffer between the decoder software and the DAC. This buffer is divided into two or more segments. Whenever the DAC is done playing a segment, it notifies the OS/application which can then start writing freshly decoded samples into that segment. The DAC then moves on to the next segment. If the decoder is fast enough, the new segment will already be filled with fresh samples. If not, the old samples get played again. This is generally very obviously audible.

 

As for clocking, the DAC has a fixed clock (usually a crystal oscillator separate from the rest of the system). Whatever the CPU is up to, the DAC simply loops over the sample buffer, firing an interrupt each time it completes a segment. If the OS crashes, you sometimes get the last 10-100 ms of audio repeating forever. This is because the DAC simply doesn't care about the software.

 

Interesting. So given the two phenomena below, where would you posit the clocking degradation ( or I suppose it could be intermittent data sample loss) comes in? Stuttering by the way would require multiple consecutive read failures; I very much doubt that you could detect a 1 out of 40 repeat of last segment sample other than as a blurring of resolution.

 

1. PC systems running OS streamlining applications like AO or Fidelizer produce more detailed sound than stock OS

2. PC or Linux NAS with USB attached SDXC card drive produces more detailed sound than vs USB attached SSD

Regards,

Dave

 

Audio system

Link to comment

Don't know if one should laugh or cry when reading that article linked to at the beginning of this thread... I've spent a lot of time and effort comparing different formats (I admit I have a bit of OCD personality when it comes to music reproduction) but pretty soon was convinced that there is absolutely nothing "wrong" with flac (or alac, wavpack etc.). The concept and the implementation is sound. You can convert an uncompressed music file to and from flac an indefinite amount of times and the audio part of the resulting file will be exactly the same. All objective ways of analyzing, for example, a wav file that has been converted from flac and back a thousand times will confirm the integrity of the stored audio, bit by bit. To find that some people are still questioning that fact in 2016 is pretty weird, even sad.

 

A completely different matter though is that different formats may "sound" different in a playback situation. Although I can't claim to reliably pick out a flac 8 file from a wav file of the same music in an a/b test, I always end up using wav for playback (prefer it even over aiff). I can't shake the feeling (it's nothing more than that really) that I enjoy listening to music for longer periods of time when I play wav. So I do. Even though I've had this feeling regardless of hardware or software (J River/Foobar on a PC, Audirvana on a mac, the streamer I use right now etc.) I would guess some players are better than others at converting flac to uncompressed PCM on the fly.

 

But the difference is miniscule at most and has absolutely nothing to do with flac not doing it's job of losslessly storing the music.

Link to comment
produce more detailed sound than stock OS

 

Words "detailed sound" is reason to ask: Why can it be?

 

For sound all features are measurable. There is no any mystery.

 

Clock unstability / jitter - higher noise.

 

Distortions - visible harmonics.

 

Turn on/off additional task (FLAC decoding) = higher noise? Theoretically - may be yes / may be no.

 

Practically there is us need refer to figures only.

AuI ConverteR 48x44 - HD audio converter/optimizer for DAC of high resolution files

ISO, DSF, DFF (1-bit/D64/128/256/512/1024), wav, flac, aiff, alac,  safe CD ripper to PCM/DSF,

Seamless Album Conversion, AIFF, WAV, FLAC, DSF metadata editor, Mac & Windows
Offline conversion save energy and nature

Link to comment
You can convert an uncompressed music file to and from flac an indefinite amount of times and the audio part of the resulting file will be exactly the same. All objective ways of analyzing, for example, a wav file that has been converted from flac and back a thousand times will confirm the integrity of the stored audio, bit by bit. To find that some people are still questioning that fact in 2016 is pretty weird, even sad.

 

A completely different matter though is that different formats may "sound" different in a playback situation. Although I can't claim to reliably pick out a flac 8 file from a wav file of the same music in an a/b test, I always end up using wav for playback (prefer it even over aiff). I can't shake the feeling (it's nothing more than that really) that I enjoy listening to music for longer periods of time when I play wav. So I do. Even though I've had this feeling regardless of hardware or software (J River/Foobar on a PC, Audirvana on a mac, the streamer I use right now etc.) I would guess some players are better than others at converting flac to uncompressed PCM on the fly.

 

But the difference is miniscule at most and has absolutely nothing to do with flac not doing it's job of losslessly storing the music.

 

The difference is quite large in my system, most probably because my DAC isn't totally isolated from ground/power plane noises over at the computer during processing.

 

An even more flabbergasting is the difference between BugHead playing a WAV file and that same WAV file played by another player: what BugHead does is avoid the cache memory...

 

So, different systems, different results. I avoid FLAC in my current system since TBs of storage is now available for low cost and I usually offline process WAV/AIFF to DSD128 before critical listening.

 

Finally, people aren't questioning a FLAC contains the same content as the original file when decompressed... This is something which comes up from other people who believe there never is any difference during async USB playback as an 'explanation why there shouldn't be any difference'...

Dedicated Line DSD/DXD | Audirvana+ | iFi iDSD Nano | SET Tube Amp | Totem Mites

Surround: VLC | M-Audio FastTrack Pro | Mac Opt | Panasonic SA-HE100 | Logitech Z623

DIY: SET Tube Amp | Low-Noise Linear Regulated Power Supply | USB, Power, Speaker Cables | Speaker Stands | Acoustic Panels

Link to comment
I'm not familiar with Zeilig and Clawson, but I am glad to hear that this is not definitive. Takes an awful long time to rip an entire collection.

 

Indeed, especially if you have something like 500+ CDs.

 

However, once you are done with it, everything else is just incremental ripping.

 

So, large initial time-investment, but after that, it's always a tiny time investment for a large convenience and audiophile enjoyment.

 

Well worth it.

Dedicated Line DSD/DXD | Audirvana+ | iFi iDSD Nano | SET Tube Amp | Totem Mites

Surround: VLC | M-Audio FastTrack Pro | Mac Opt | Panasonic SA-HE100 | Logitech Z623

DIY: SET Tube Amp | Low-Noise Linear Regulated Power Supply | USB, Power, Speaker Cables | Speaker Stands | Acoustic Panels

Link to comment
Interesting. So given the two phenomena below, where would you posit the clocking degradation ( or I suppose it could be intermittent data sample loss) comes in? Stuttering by the way would require multiple consecutive read failures; I very much doubt that you could detect a 1 out of 40 repeat of last segment sample other than as a blurring of resolution.

 

The decoder running slow might result in anything from a single sample to most of the buffer being repeated. One or two bad samples may or may not be audible (a large error in a single sample causes a clear tick), but any glitch of more than a millisecond is immediately obvious. It is extremely unlikely that the decoder would be just barely keeping pace and falling behind by a few samples now and then. Realistically, it is either fast enough and stays well ahead of the playback (even though the exact distance between decode and playback position will vary back and forth a bit), or it is too slow, in which case you'll hear the music progress but with many repeated fragments (stuttering).

 

For the purpose of FLAC decoding, modern computers are very, very fast. My old i7 from 2009 decodes a 28-minute 96/24 stereo FLAC file in about 6 seconds. That's about 280 times faster than it needs to be. Now even with a fast computer, without a true real-time OS, it is possible for the decoder to get arbitrarily held up, leading to a buffer underrun. If this does happen, it is again unlikely that the resulting glitch with be limited to a few samples, especially repeatedly. A persistent problem of this nature results in mostly correct playback with occasional glitches. In severe cases, it might glitch several times per second but rarely more. This is because when the decoder does get to run, it is fast enough to quickly fill the entire available buffer space. Should your system be thus afflicted, the cure usually consists of increasing the audio buffer size until the problem goes away. A total buffer of 100 ms is usually enough.

 

1. PC systems running OS streamlining applications like AO or Fidelizer produce more detailed sound than stock OS

2. PC or Linux NAS with USB attached SDXC card drive produces more detailed sound than vs USB attached SSD

 

Neither of those effects have been shown to exist under controlled conditions.

Link to comment

Finally, people aren't questioning a FLAC contains the same content as the original file when decompressed...

 

That's exactly what the people who wrote that article and some other people in this thread suggests, hence my post.

 

With my current network streamer the difference between flac and wav for playback is indeed miniscule, if there at all. The difference was less subtle with Foobar and a PC eight years ago when I got into computer audio.

Link to comment
Until recently I believed that flac was just as good sounding as wav files. A dealer told me he preferred wav and explained why. He said that cymbals e.g. sound less well defined at the start as if something was missing. I asked my wife about this. She is a professional violin player and said that musicians talk about articulation.

Well the dealer suggested to listen to a simple jazz recording with open sounding percussion.

I ripped a CD of the Pierre Favre Ensemble on ECM called Fleuve. I ripped it to flac setting 5 and to wav using the same CD-ROM drive.

Than we listened several times to the opening track Mort d'Eurydice.

We both found the wav version sounding completer and better articulating indeed.

Later that week I redownloaded albums from Qobuz in wav. I consider them better sounding than flac. If I now listen to a flac album I miss something. I do not miss anything with dsd or mqa.

 

Robert-Jan

 

You should try converting your flac file into a wav file and compare that to your original wav file.

Synology DS1515+ >  PS Audio P10 > Innuos Zenith Mk II running Roon Core > IsoRegen/LPS-1 > Lyngdorf TDAI 2170 > Tekton Double Impact Speakers

Link to comment
...

 

It appears to be due to RF/EMI issues in less than perfect computers, both at the encoding to .flac from the original format, and decoding back to the original format . This also applies to conversions to flac done by the distributor or record company, i.e. whoever does the original conversions. The conversion back to say .wav again MAY sound a little better sometimes, but it isn't quite as good as the original music file. The better the power supply to various areas of the PC and the more improved isolation between different areas of the PC, the less the degradation is.

BTW, I was also involved in more recent testing with one of the authors of the report. (Dr.Charles Zellig) and the results were posted in HFC forum. HFC Forum is not currently available to access by non members, due to hacking attacks by foul mouth members of Snake Oil forum a few months ago.

 

My findings are similar to those of YashN in post 117.

 

Of course, some members here have perfect PC s or servers and it doesn't happen to them !

 

How a Digital Audio file sounds, or a Digital Video file looks, is governed to a large extent by the Power Supply area. All that Identical Checksums gives is the possibility of REGENERATING the file to close to that of the original file.

PROFILE UPDATED 13-11-2020

Link to comment

I believe it hinges around the way flac files are compressed. With wav, each and every sample of each channel has equal weighing. The flac encoder may compress each frame of data to varying degrees depending on how compressible the data is. There is also a process of Interchannel Decorrelation, where one of 4 methods are used on a frame-by-frame basis to compress the L/R channel data.

 

Essentially flac is creating slight timing variations between frames (or L/R channels) that dont exist with wav format (even if it may only be less than 1us).

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...