WAV vs FLAC revisited

Vincent Kars · Nov 25, 2011

One of the many debates is if there is an audible difference between FLAC (lossless compression) and WAV (lossless uncompressed).

From 14.1 on, dbPoweramp supports uncompressed FLAC

FLAC encoder wording changed, also includes a FLAC Uncompressed encoding option (which stores audio uncompressed, for those who want WAVE PCM but with better ID Tagging).

This sounds like we finally have WAV with excellent tagging options.
As I don’t hear a difference between WAV and FLAC, anybody who does has tried this option?

http://www.dbpoweramp.com/Version-Changes-DMC.htm

mauidan · Nov 25, 2011

See:

http://www.computeraudiophile.com/content/WAV-vs-new-FLAC-Uncompressed-format

amirm · Nov 25, 2011

Probably should wait for Gary to chime in/get him to try it.

Dan, I looked at that thread and after 20+ posts, they are still having a food fight as to whether there should or should not be a difference. So I gave up on them having the answer to Vincent's question.

mauidan · Nov 25, 2011

Amir, after getting banned so many times I thought you'd remember my name.

FLAC stands for Free Lossless Audio Codec, an audio format similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality.

Isn't "uncompressed FLAC" an oxymoron?

Dan

Bruce B · Nov 25, 2011

I have a workstation that plays wav, flac and aiff. I can put all 3 into a single project and quickly switch between each. I have also checked at certain points along the timeline and have determined that all 3 are exactly the same!

amirm · Nov 25, 2011

devert said:
Amir, after getting banned so many times I thought you'd remember my name.

Your tussle wasn't with me so no, I don't have your name memorized. I was abbreviating it based on your alias.

FLAC stands for Free Lossless Audio Codec, an audio format similar to MP3, but lossless, meaning that audio is compressed in FLAC without any loss in quality.

Isn't "uncompressed FLAC" an oxymoron?

Dan

No it is not.

Here is the theory as to why there may be a difference. All lossless codecs are CPU intensive systems. Predictive coding is use to find maximum redundancy and the reverse logic needs to be applied at decode time. I wrote a tutorial on lossless audio codecs if you want to learn more.

We know that the thing that can cause digital audio to sound different is its timing, not the digital samples. The digital samples are almost always correct if you are not hearing audio glitches. So the fact that FLAC is lossless in that regard, is not material. What is material is that it changes the activities on your computer. Instead of a WAV file workload where the system is simply reading the files and after a tiny bit of parsing the file format, outputs the digital samples, in case of FLAC and other lossless formats, the CPU load goes up substantially (comparatively). The increased CPU activity changes the system EMI/RFI and power supply conditions in the PC. It is this kind of activity that can change digital audio timing.

Now, it is impossible to conclude automatically that just because there is CPU activity, the quality drops. For one thing, the difference may be so subtle that you can't tell anyway. Further, since PCs have so much going on in them anyway, just sitting there, it is not easy to determine if jitter gets worse with lossless decoding. It is entirely possible that it gets better, or it gets worse and better in every frame of audio.

So no, it doesn't automatically follow that uncompressed FLAC sounds the same as compressed. As a practical matter in may very much be that way but not as a matter of how it works.

amirm · Nov 25, 2011

Bruce B said:
I have a workstation that plays wav, flac and aiff. I can put all 3 into a single project and quickly switch between each. I have also checked at certain points along the timeline and have determined that all 3 are exactly the same!

I don't think that simulates the same thing Bruce. The workstation would need to decode all the streams to PCM and then play them so what the CPU workload remains the same regardless of which one you are hearing.

Whatmore · Nov 25, 2011

Without having read much about this I would think that any differences due to CPU load could easily be eliminated with a sufficiently large buffer.

Vincent Kars · Nov 25, 2011

amirm said:
.. in case of FLAC and other lossless formats, the CPU load goes up substantially.. (comparatively).

In case of WAV the I/O increases substantially compared with a compressed format.
The I/O also requires CPU.

Vincent Kars · Nov 25, 2011

Whatmore said:
Without having read much about this I would think that any differences due to CPU load could easily be eliminated with a sufficiently large buffer.

As our OS are multi-tasking, almost all devices have an input buffer including the soundcard.
Inherent to multi-tasking is that the arrival of the data on a specific time is not quranteed.
So you need a buffer to avoid dropouts.

In a nutt shell:
PCM=fixed word length + fixed time step e.g. 16 / 44
The time step is generated by a clock.
If you modulate the power driving this clock its speed will change so you get time steps of varying length.

amirm · Nov 25, 2011

Vincent Kars said:
In case of WAV the I/O increases substantially compared with a compressed format.
The I/O also requires CPU.

With computers built in the last 15 to 20 years, the CPU overhead is not measurable for such operations -- it is that small. This is especially true of disk I/O which is the only thing impacted here as far as I/O as that is DMA programmed so other than set up, nothing else is required by the CPU.

The ratio of CPU required for lossless decoding to programming the input operation from disk is at least 1,000,000:1 if not higher.

With lossless providing 2:1 compression, the amount of I/O difference is not that big anyway.

The only unknown is that you get probably 2X more interrupts and that could cause its own pattern of jitter which may or may not be worse than doing half as much.

amirm · Nov 25, 2011

Whatmore said:
Without having read much about this I would think that any differences due to CPU load could easily be eliminated with a sufficiently large buffer.

The CPU is fast enough in either case as to not have glitches that need fixing with buffering. Buffering could regulate the frequency of CPU usage however so depending on the OS and media player, there will likely be differences in pattern of operation.

microstrip · Nov 25, 2011

amirm said:
(...) Now, it is impossible to conclude automatically that just because there is CPU activity, the quality drops. For one thing, the difference may be so subtle that you can't tell anyway. Further, since PCs have so much going on in them anyway, just sitting there, it is not easy to determine if jitter gets worse with lossless decoding. It is entirely possible that it gets better, or it gets worse and better in every frame of audio.

So no, it doesn't automatically follow that uncompressed FLAC sounds the same as compressed. As a practical matter in may very much be that way but not as a matter of how it works.

Amir,

IMHO, any test carried on these matters will depend on source recording and system. All recordings have some distortion due to the jitter of the recording system and the differences you listen can be due to the interaction between it and the jitter of the reproducing system. Also, unless you carry many tests in many systems and find a well established correlation, you are not comparing WAV versus FLAC, but only testing a few samples in an enjoyable test without statistical value. .

amirm · Nov 25, 2011

Microstrip, for sure this is as random of a situation as one can get, with a million variables. So it is doubtful that anyone's experience translates to another.

That said, encoding jitter is usually far less than decoding. Problem with decoding is that we are trying to lock to an external source. So on top of any clock instability, we are trying to adjust to another source's vagaries. When digitizing, we don't have to do that.

Audio is so broken in so many ways! It is a miracle that we enjoy it regardless

.

mauidan · Nov 25, 2011

Another recent article:

http://www.audiostream.com/content/cut-flac

fas42 · Nov 25, 2011

amirm said:
That said, encoding jitter is usually far less than decoding. Problem with decoding is that we are trying to lock to an external source. So on top of any clock instability, we are trying to adjust to another source's vagaries. When digitizing, we don't have to do that.

Audio is so broken in so many ways! It is a miracle that we enjoy it regardless .

As an engineer I find that hard to accept: the process of retrieving a data stream which encodes music is a straightforward technical process, and another, completely separate process which converts that stream of digital data to an analogue signal is also no great challenge. Getting the data from one process to the other in a fashion so that no abberations, electrical glitches get through from the first to the second is the issue, and that is just an engineering issue. The fact that a lot of this engineering is sloppily, or poorly done through lack of understanding or appreciation that you have to be fussy doesn't mean the process is difficult, just that some people have to try a bit harder ...

Frank

amirm · Nov 25, 2011

What do you find hard to believe? That audio is broken? If so, create another thread and let's dig into it.

Johnny Vinyl · Nov 25, 2011

Yeah...them thar is fightin' words! Come on Sonny-boy...put up y'er dukes!

fas42 · Nov 25, 2011

This seems relevant here: the discussion is whether Flac has problems, and you've stated that it can be due to extra CPU activity causing interference to the process of converting the digital to analogue. And I agree with that, I'm sure that is what the problem is; you say it manifests as jitter, I would say that there is a general level of interference going on, but that is neither here nor there. The end result is that the conversion to analogue is compromised, and the audible effects will probably be similar whether you interpret it as jitter or general interference.

The key thing is that the DAC aspect of the music replay processing should be completely isolated from electrical interference, whether as jitter or other, and that then solves the Flac vs. Wav thing. This isolation has been sorted out, many times, there are no mysteries here, but that doesn't help if people don't actually implement a proper such solution, and do it with good, solid engineering values ...

Frank

FrantzM · Nov 26, 2011

Hi

I am certain one can compare how the different codec/compression schemes loads the CPU. It remains that with a modern PCs the load variation is infinitesimal...
I find this typical of the audiophile psyche: If there is any difference, whatever that it is even the color of an LP jacket ... We infer an audible difference. This, unfortunately is not always the case, it is actually rarely the case.
My entire library is in FLAC and ape. And it is about the equivalent of 3000 CD strong and growing.

WAV vs FLAC revisited

WBF Technical Expert: Computer Audio

Member Sponsor

Banned

Member Sponsor

WBF Founding Member, Pro Audio Production Member

Banned

Banned

Well-Known Member

WBF Technical Expert: Computer Audio

WBF Technical Expert: Computer Audio

Banned

Banned

VIP/Donor

Banned

Member Sponsor

Addicted To Best

Banned

Member Sponsor & WBF Founding Member

Addicted To Best

Member Sponsor & WBF Founding Member

Similar threads