WAV vs. FLAC - Should Naim aim for no difference?

So Geoff are you saying that you haven't actually compared WAV versions corresponding to the FLAC downloads you have?  You are just making absolute statements about the FLAC downloads you have bought? Have you tried converting them to WAV? Do they sound better? Comparing a DVD audio rip you made to a FLAC you downloaded isn't imo a very convincing comparison - you have no idea whether the source is identical.

> As Simon has said if you hear the difference then transcode at the server.

How? I don't have that option as far as I can tell. Does the UnitiServe transcode? 

Asset is still not available on OS X or Linux .... 

Hi Hook. What I belive i have said is that I can't hear any meaningful difference between FLAC and WAV when it is transcoded by Asset. However I definitely hear FLAC sounding different and not as enjoyable as WAV when fed directly to the NDX connected to my NDAC / 555PS. I realise my setup might be more analytical and revealing than some.. But that's how I like it.

I can't comment whether the NDS into NDAC still exhibits the difference.. It doesn't seem a likely combo though.

Simon

No I am not saying that.

I am comparing WAV versions I ripped myself from specific CDs with the same Album downloaded as a 44.1/16 FLAC set so not absolute statements at all, comparative rather.

I have not tried converting FLAC to WAV outside Asset UPnP but am using Asset to transcode to WAV as it delivers FLAC files to the KDS.

The DVD audio discs I am discussing are Hires versions created as masters of mainstream albums and when played to the KDS are reported to have the correct 192 or 96/24 resolutions. The FLAC versions CLAIM to be created from the original masters so I think it a reasonably fair comparison.

Anyway its what my ears hear no theory just gut reaction 

regards

Geoff

imo the only fair comparison is between a FLAC and a WAV ripped from the same source, or a WAV and the same WAV converted to FLAC by a proven converter. I don't think the basis for your comparisons are anywhere near as rigorous as they could be. Far too many other variables are involved - Hires remastering to DVD for one thing. Remastering isn't a passsive, copying process - it is active, involves remixing and rebalancing. It is almost guaranteed that there will be differences between remasters to different formats.

Bit perfect?  Doesn't exist. The perception of perfect copying is  a result of imperfect measurement techniques.

Forensic scientists believe that every contact leaves a trace. If you compress something you cannot decompress it again without altering it in some way, no matter how small. No need for anyone, let alone Naim, to have to seek to minimise that 'trace' of contact. Just stop the contact.

Andy

Eh ?

Eh x 2?

The perception that "bit perfect" is necessary is bogus.

What does it matter if a dozen or so bits are imperfect in a track that contains umpteen zillion bits. They will be inaudible.

Well I know the angles of a triangle don't add up to 180 degrees cos I measured 'em. 

However, I do know PCM data sent in to my UQ comes out of it without alteration as that is just a matter of counting which is exact. There are no measuring techniques involved as it is not continuous, it is discrete so you can count it exactly - every single bit if you have a mind to. 

By the way my computer boasts 1280 x 1024 pixels, but I swear when I checked them yesterday one was missing - should I see if I can get my money back? 

PChaps, i believe 'bit perfect'' is a meaningless concept here, as it really relates to nothing useful other than loose concepts, and I think people get unduly hung upabout it.

1. Stereo Samples are in interleaved words in most files like AIF and WAV

2. The timing that each stereo sample is decoded is important to the integrity of the analogue signal and it's frequency content.

3. SPDIF  consists of specially encoded frames for left and right sample words and  header info.

Therefore 'bit perfect' doesn't really help any of the above accurately, as the 'perfection' depends on the format and timing of the data.

A bit is a discrete level, true/false. It has no concept of timing information which is important in a discrete data stream such as sample continuous (analogue) audio, and furthermore our 'bits' ate manipulated when we oversample, dgitally filter and change word legth. Perhaps data integrity is a more useful concept.

Simon

Bit transparency is surely a well-defined and measurable quality.

The modern streamers do a regular "computer" job on receiving the data through network as well as decoding and uncompressing (when necessary) the data without bit loss (based on the basic code redundancy and checksum verification). In other words I'm sure the PCM data chunk from the hard drive is transported to the streamer's DAC buffer flawlessly: whether it's been stored in the form of WAV or FLAC.

It's hard to believe that streamer's CPU may flip the bits during decompression and fail the parity check and still carry on with processing the next data chunk because of the limited time-frame.

But this could be just my wishful thought 

As far as I can see the only difference between streaming WAV and FLAC is the contaminated feedback which streamer's CPU "on a heavy FLAC duty" apply to the streamer's Power Supply which is usually shared with audio section. Splitting the two or adding more isolation between the digital and analogue rails should help to develop immunity to the WAV/FLAC effect. 

Hi AMA, I am not sure bit transparency is well defined, it's more a conceptual marketing term that people get hung up about when trying to apply to specifies.

For example technically  bits are deliberately flipped in SPDIF to comply with the transport encoding rules, or compressed and manipulated in FLAC files, but it doesn't change the meaning of the sample. Also if the timing of the sample is incorrect, just because the bits in the sample word are correctly set, it doesn't mean the data is then correct.

So the real issues are.

1) sample integrity; have the samples been modified such as with file formats, transport encodings or conversion by software drivers etc

2) in a stream of samples is timing maintained, or is there sample timing jitter, or RF noise affecting clocks in conversion processes.

So I state in audio the terms should be 

1) Sample value integrity  through the digital chain from start to end.

2) Sample timing accuracy at the point of conversion between domains.

You can't rely on 'bit transparency' as they may well be manipulated and changed in the digital chain. But that is fine if 1) and 2) above are maintained.

Finally with regard to EMI from FLAC decoding, I think you'll find it not so much to do with micro controller /processor load, but more to do that the EMI produced per sample is not constant as per largely the vase with WAV or AIF and therefore leaves more of a sonic impact. Things that vary tend to affect us more to things that are constant. Yes theoretically decoupling should render this EMI inconsequential, but clearly as I have evidensed so far, decoupling where you are sharing many common resources like power, case, internal powerlines is easier said than done.

[Hint to Naim: why do you not twist the internal power wires in the NDS so to mitigate EMI emmission as per regular RF electronic engineering? - an early picture I saw still showed these as running parallel]

Simon

Simon, there is no "timing" issue with streamers. They pull bits through the network protocols and secure that a data chunk on the hard drive is "copied" to the streamer's memory buffer flawlessly.

This means it does not really matter if the original file was stored in FLAC or WAV.

In both cases the PCM data chunk will be carefully getting the final destination in a streamer's memory buffer.

Obviously, the PCM data chunk is then digitally processed and clocked to D/A -- and that's what DAC designers do to voice the DAC. Here is the point where "bit-flips" and "timing" concepts come back to the game  but I consider this as a part of a DAC section, not streaming. 

As for S/PDIF it is a very different concept from streaming and it stays dependent on RF and step-reflections and waveform distortion and time/phase deterioration and cable lengths and cable designs and connector design and quality of S/PDIF generator and quality of S/PDIF receiver -- all along the whole path. And still never gets bit-perfect.

Much inferior to non-timed data transmission.

I accept your points but in mitigation of my position on WAV vs FLAC I did say in a post above ..quote:

"When I first setup a streaming system a few boxes and years ago I did a few tests of the first CDs I ripped to compare FLAC & WAV and felt then that FLAC's took on a slight metallic edge when the volume ramped up that didn't set in with WAV. As a result I decided up front to rip to WAV."

Admittedly I had not done an 'only yesterday' comparison of files personally ripped side by side to WAV & FLAC at that time. I rectified that last night with a selection of tracks off multiple CD's. 

I still prefer WAV 

Geoff

Hi Ama,

Yes i was not wanting to get hung up on terms such as streamers etc - as these are subjective. But yes I was including a streamer or NetworkPlayer can be at the end of the chain with a DAC - where timing is important.

I don't quite follow your point on SPDIF. The transmission speed isn't directly timed to the sample rate per say - however typically the underlying sample clock is 'calculated' from the rate at which the frames are received - where each frame contains a channels worth of sample data or header information. However the frame timing used in the SPDIF protocol is not directly coupled to the sample clock, its more like the synchroniation method of an analogue video recorder rotating tape head based (with PAL) where the start of certain scan line syncs the spin.

I sometimes think, (though not saying you do), that some people think SPDIF is just a stream of sample PCM bits - and this is not really the case - its no more so  than say UDP datagrams over an Ethernet network (as used in realtime media streams). However the conveyed sample values are maintained unless there is a data corruption or buffer over/under flow - due to a poor link, timing or otherwise , but in my expierience this is rare - and if occured I would expect you to probably lose transport synchronisation or get a click or pop or temporary silence.

Simon

Ok are hi-res files i.e. those recorded as 96/24 and higher (which are invariably sold as FLAC by Linn, Naim, B&W, HDTracks etc) played directly as FLAC by Naim/Linn streamers, or are they decoded to WAV?

Hi, you have a choice; you can play them as FLAC files, or depending on your setup either convert or transcode to WAV as per personal preference. I transcode to WAV as I just prefer the way they sound as WAV as opposed to FLAC, but it's a personal thing, and many are equally happy playing FLAC. I guess there is no right or wrong way... It's down to what you prefer, or if it sounds the same to you - great you need do nothing.