WAV vs FLAC - Magazine Test

Disturbing article, challenges all the choices I made. Flac storage and in the fly Wav conversion. At the same time I will not go through the crazy process of converting back to Wav. For the future I will consider my approach, perhaps starting to download Wav instead...

Thanks for sharing....

I've seen this before, multiple conversions seems to cause 'orphaned' data to accumulate in the metadata records.  It's also important to note that the system used is a computer supplying a DAC with a S/PDif signal in a near real-time manner.

The logical conclusion is that the extra real-time processing in the computer used to remove the greater amount of metadata (and possible to process the significant metadata in the presence of the 'orphaned' records) is degrading the signal in the S/PDif cable (either by affecting the timing of the S/PDif signal or by introducing additional noise).

This is an argument in favour of using UPnP / DLNA streaming rather than S/PDif from a computer as UPnP is non real time and S/PDif is real-time(ish).  Hence the data stream in UPnP streaming has already had the metadata stripped (by the Media Server) before it is sent to the renderer and turned into a real time signal.  This also supports the argument for using ferrites on the streamer Ethernet cable.

By 'degrade' they mean 'alter the perceived height of some sound above a speaker'? I can't see any reference to the height it should actually be, as specified by those who produced the music.

Sorry if I have this wrong but surely a bespoke binaural recording and headphones should have been used? Why is actual audio data not compared?

Quite worrying all this - I spent quite a bit of time when getting NDX to investigating best way to Rip CDs - came to the conclusion that FLAC was fine, so that was what I did

I cannot see me repeating ripping 500+ CDs - but would obviously like the best sound I can get from my equipment.

Perhaps the debate will never come to a definitive conclusion ???

Al

I don't think there is a simple answer to this, I believe it is system dependent.

When I was using my NS01 as a renderer WAV was clearly better than flac. My previous system there was no difference. My current system? Well I haven't tested it, but I run all WAV now, although I have just added a load of meta-data to improve functionality, according to that article I may have degraded things, not hearing that though!

M

Al, Mr Underhill,

As you're using UPnP systems, don't worry about it - the effect is an artefact of the listening system they were using for the test and probably won't occur with UPnP streaming.

Hafler, I agree.

I think the test and their assessment is fundamentally flawed, and that flawed nature throws some degree of doubt on the conclusions.

So, if I've understood this correctly, the problem doesn't exist if you rip CD to FLAC and transcode to WAV? It only manifests itself when converting to FLAC from WAV?

Huge posted:

Hafler, I agree.

I think the test and their assessment is fundamentally flawed, and that flawed nature throws some degree of doubt on the conclusions.

Thanks! I thought I was going to get someone saying "re-read all that and come to the desired conclusion this time" 

I am a real cynic when it comes to digital music - as far as I am concerned everything feeding the DAC is snake oil in terms of SQ except for the quality of the source audio file.

I am a computer software engineer and everything in front of the DAC is computer based data - i.e. 1's and 0's:

* the fundamental quality of the audio is defined by the sampling rate and bit  depth of the file; the format is irrelevant as long as it is, or can be reconstituted to, the same as the original.

* These 1's and 0's are fed into the DAC; the only issue with this is timing and this has been solved for real-time computer systems for many, many years - it is called buffering; just like the DAC V1 does. In fact I would not consider buying a DAC that does not have internal buffering in order to guarantee the samples' processing timing (avoiding jitter).

All the "stuff" between the source file and the DAC input is concerned with 2 things:

1. Delivering the bits to the DAC at a rate that will not neither overload nor underload its buffer.

2. Providing user management of tune selection, playing control, etc -this is the 'control point' functionality in the UPNP architecture but exists for every system.

Metadata resides for the purpose of the second activity above and has absolutely no impact on SQ of activity 1.

... so why does everyone get excited about all the storage, network, connection, server and streaming technologies and components? Why do they report audible differences?

Well my analysis above makes 1 large assumption - all the equipment storing, serving and communicating the data is placed well away from the audio rig. I do understand that power supplies, computer processing, etc can adversely affect analogue signal processing which begins in the DAC.

Hence the comparisons are actually describing the affect of this ancillary equipment's proximity on the analogue audio processing, not any inherent effects of the equipment itself.

So my perfect system would be one with NAS, server, network routing etc all in a cupboard somewhere, feeding the DAC through the simplest streamer that simply translates the Ethernet protocol into the digital audio data stream for the DAC. No need for audiophile components, just ones that are robust, preferably enterprise grade.

After all, consider running a program or accessing a data file on your computer - it gets it bit perfect every time doesn't it?!

... now I will wait for the brickbats ...

Alan

Here comes the first one.... Thud!  (well sort of)

You're wrong to say that everything before the DAC is irrelevant... but for the reasons you point out!

Jitter passed to the DAC does affect the reconstructed audio, as does noise conducted by the digital connections and through the power supplies.  Even if many of the digital components are at a considerable distance from the analogue electronics, they are connected by cables to other circuit elements that are close to the analogue circuits (and hence their noise can break through).  In addition the digital circuitry (e.g. DSPs) that precede the DAC are also in close proximity to the analogue circuitry.

Hi Huge,

thanks for this:

Jitter is (or should be) resolved, as I said, through simple buffering at the input side of the DAC with the digital circuitry within the DAC itself being able to "pull" the samples it requires at a highly accurate rate through some internal clock. The only issue would be if the input digital stream is arriving too slowly to keep the buffer from emptying or indeed too fast so that it overloads the buffer (this latter would probably result in lost samples).

In my vision, the only input connection to the DAC is a single digital cable of some sort. Noise on this would not affect the bits themselves but could, I accept, be passed on in some way to the audio circuitry - I would guess it would have to be pretty poorly shielded/isolated for this to happen though. I may be being presumptive here in that I am assuming the input for a DAC implements the relevant protocol detection/correction to ensure bit consistency, this may not be so, I don't know for a fact?

Yes the DAC contains both DSP/filtering digital and analogue circuitry but this is designed to be that way and is constant for all kinds of input so would not affect the perceived SQ in any way for a specific DAC. Obviously different DACs would still have a different "sound" since they use different circuitry/software.

Allan

Hi Allan,

Whist jitter can be reduced by buffering, if the input protocol to the DAC system is a real time feed (e.g. S/PDif) there is always a residual lower level as the local master clock has to spped up and slow down to maintain synchronisation.

The input required for the DAC itself is usually a stream of synchronous serial data samples, one sample at a time.  This has to be extracted from the data carried by the input protocol, and that very often has to be decoded before the individual data samples can be extracted.  All this processing in the digital domain inherently creates high frequency switching pulses in the PSU lines.  Due to the HF nature of the digital edges it's actually impossible to fully isolate this from the analogue circuits, and the more decoding that is needed, the more processing is required, so more digital noise is created and passed to the analogue circuits.

I accept that these aren't major effects, but they do cause lesser differences in the analogue output from the DAC.

Hi again Huge,

Yep, I like that.

In the context of the OP, this processing is still all close to (or actually in) the DAC; the digital pipeline prior to this should still, I assert, have no bearing on the SQ.

The wav vs flacc results are, IMO, artifacts of the file processing, not inherent to the file formats themselves. They may still be relevant in the audio management context but are not relevant to replay.

Allan

Great discussion guys and an interseting read 

We have been here many times before. I have my performed my own tests, and the extracted PCM from wav and FLAC is identical if there is no fault.. and when I create FLACs I test this each time.. but this is not the point

However also being a computer engineer, by profession and graduate, it's not obviously just about about ones and zeros.. those are abstractions. We need to consider the engineering of the physical systems and effect of system intermodulation with digital clocks and analogue audio stages. Good old systems theory shows on a closed system one function can effect an other. Therefore the processing of a digital payload can effect the digital clock of am audio transport stream within a closed system. The better the system the smaller the error or interaction here. 

Now FLAC data requires a different set of physical process to unpack the audio data than wav PCM... Hence the potential system interaction error can be different.

The same goes for Ethernet, and again I have performed recent tests and measurements here... Different TCP timing characteristics cause different closed system error interactions.

Both SPDIF and Ethernet are quite similar in this regard (especially in modern systems where the DAC clock is NOT directly taken from the SPDIF transport clock )  .. although the underlying transport protocols are different, with SPDIF looking more like a network UDP stream than a TCP flow.

Now to some specifics, there are some meta data types (from memory these are NOT the Ogg Vorbis music description types) that are interleaved into the FLAC payload. This is deliberately done it it be possible to allow decode of FLAC part way through a stream on supported equipment. Therefore if additional meta data is added or changed, the above processing signature in a closed system may subtly changed. Therefore it is possible such perturbations in a closed system become audible.

So in a closed system a nice consistently spaced flow of data on the network will cause a lower or more consistent system modulation noise than a flow with a high degree of inter frame /packet timing variation. In a similar way WAV  decoding will produce a more consistent noise floor than decoding FLAC. 

But all this is quite standard and  understood and has been mitigated for years in other circles. After all I was studying the causes and impacts of closed system interactions as a humble computer engineering undergraduate  back in the late 80s. I guess however it's all a bit new in the domestic hifi circle 30 years later.

Simon

Having said that.. Of course it's not all new for those building this stuff.. and I know that Naim have become  quite aware of closed system intermodulation and errors with its latest firmwares...and I understand they have developed some great understanding of the effects of noise floor modulation from system digital code processing within their (closed system) streamer products.

Simon - how dare you!

It's 7.19 in the morning and you have your head on (I take it you actually do live in Suffolk) - that is just not natural

I have now had my second cup of tea and am almost feeling human ...

This is why I was/am a software engineer - hardware did my head in and kept adding more and more exceptions to the nice maths I was doing; i.e. it was never as simple as it looked! I remember learning that electricity was electrons moving about and all that stuff about transistor transition layers - then all of a sudden it is holes that are moving, but then nothing is really moving either ... maybe that's why engineers don't do drugs, their heads are psycadelic already!

... but remember that software makes hardware happen

Good stuff, so there is some intra-system  noise going on but, as you say, this is minimised by keeping the closed system as small as possible.  Just process and stack those digital samples up in "virtual" real-time somewhere remote from the audio analogue circuits and have a simple gateway between all that remote noisy stuff and the delivery to the DAC input.

Having said that, my UnitiServ is sitting next to the DAC ... go figure

Allan

Allan Milne posted:

 ...

It's 7.19 in the morning and you have your head on (I take it you actually do live in Suffolk) - that is just not natural

... 

 

And boy what a head - just look at his avatar!

Allan - limbering up for the day 

You poor thing - since I managed to retire early at the end of last year I have managed to get into the habit of leveraging myself slowly into the day, nothing hard until after 11am at least

enjoy,

Allan`

You hear what you hear. Measurements are  meaningless if your preference  leads you elsewhere.  Trust your ears. Please yourself. If you are looking for assistance making a choice, the good news is that files are easy to interconvert, easy to play back and easy to store  in as many formats as you like. You don't need someone else to tell you what you should hear and why. Many things have a  certain zing  to  them  which can't be measured on paper (not remotely restricted to HiFi) and fail to connect  with  many users  whilst  winning over others. Life is interesting = good.

Allan,I went down to a three day week 4 years ago retired end of last year money's not brilliant but it makes flexi hours look like slavery best job I've ever had.

Must get back to the Naim system for a lazy afternoon of music.