Naim Rips -vs- Ruby Ripper Alias WAV -vs Flac!

It would be interesting to know if the WAV files (the Naim rip and the decompressed RubyRipper FLAC) contain the same data. There is a bit compare tool in Foobar that can easily do this.

However, I'm not surprised that you can't hear any difference between the two. This does imply that the degradation in quality comes as a result of the overhead of decompressing the FLAC file on the UnitiServe, and the same quality difference has been heard on the NDX (but I haven't tested this myself).

This tells me that if you are streaming  you should configure your uPnP server to decompress FLAC to WAV on the fly on the server. That way you get the benefits of FLAC (portable meta-data and reduced disk space) combined with the sonic benefits of presenting the Naim renderer (NDX, Qute, Uniti) with WAV rather than a compressed format.

It doesn't really help if you are accessing a music store of already-ripped FLAC files on a NAS from a UnitiServe. In that case, I suppose you have to weigh up whether the increase in quality is worth batch converting from FLAC to WAV and then dealing with WAV tagging. Or, you can re-rip everything using the UnitiServe...not an option that appeals to me!

Hi Adrian,

...you should configure your uPnP server to decompress FLAC to WAV on the fly on the server

Appears logical.

...It doesn't really help if you are accessing a music store...

Yes.

Interestingly I took the UnitiServe back to my dealers this afternoon, and the DC1.

I'm now back using my Stereovox cable between the NS01 and the nDAC .....and I can no longer distinguish between flac and wav files.

The Stereovox does not convey that bit of top end digititus the DC1 does for flac files.

M

WAV files (containing PCM ) can be internally structured differently, albeit the conveyed PCM is exactly the same. This is the the same for FLAC, where redundant data is removed from the packaged PCM. It is almost certainly the case that NAIM has optimised it's WAV encoding and decoding software to work together, hence why it sounds the best. Another vendors WAV encoding or indeed FLAC may not sound the same, as a consequence of the artefacts produced in the renderer of decoding and reconstructing the PCM from the WAV or FLAC file.

This is why WAV files from rippers on different platforms can 'sound' different, even though the PCM is identical. What you are hearing is actually differences from the decoder, not the encoder...I hope that makes sense.

Simon

Simon - are you saying that Naims FLAC decoding must be wrong?

Very interesting, Simon, I didn't realise that subtle differences in WAV file structure existed or that they could have an appreciable effect on sound quality.

@likes, I don't think Naim's FLAC decoding can be "wrong" --- they must, after all, be using the same libraries as everyone else. Perhaps it is just the act of doing that decoding that introduces these subtle effects.

This is a bit like particle physics -- as soon as you think you have reached an immutable, fundamental particle, a whole new layer of complexity reveals itself when you dig deeper. We live in a chaotic world. But it's great that we get music at one end!

Adrian

One of the best explanations I've heard - thanks Simon

So even if your NAS decodes Flac into wav on the fly - it may not be a wav optimised for Naim's renderer?

Tog

Simon

Very interesting and something I've not read about previously.  Can you point me in the direction of further reading on this subject please.

Steve

WAV optimised for different renderers .. mysteriouser and mysteriouser ...

Perhaps my memory is failing, but I could have sworn that someone claimed, in the not too distant past, that a Naim WAV rip and a non-Naim WAV rip were bit-for-bit identical. 

I believe this was using some binary compare tool, so I would not have thought that such a utility would be able to distinguish between the WAV file structure info and the PCM data.   I do not have a UnitiServe or HDX, or I would do this test for myself.

I can understand if Naim has (for now) optimized its decoder for WAV.   Does that also mean there is there room for improvement in FLAC playback a future release of their decoder code?

Also, when using a Naim network player, can anyone actually hear a difference between a Naim WAV rip, and a non-Naim WAV rip of the same song?  Just had a quick look at the WAV file structure, and it is hard (for a relative novice like me) to see anything that could give one decoder a leg-up versus another.  Maybe artificially inflating gain value?  And if Naim has altered the WAV file structure just for their rips, does that mean you cannot play a Naim WAV rip using a non-Naim decoder?

Ouch, this is making my head hurt....am sure I am missing something basic here.  Thanks in advance for any clarifications.

Hook

The consensus seems to be they are bit for bit but it is what you do with those bits that matters ...

Tog

Simon suggests that the that Naim rippers with encoder enhancements produce WAV files that are "internally structured differently" than standard WAV files.

If true, then I think that this begs the other questions I asked.

It also suggests a reason why buying a Naim network player without also buying a Naim ripper is less than optimal.   To be honest, this would make an NDX less appealing to me, since I have no intention of re-ripping.

Hook

Somewhile ago it was shown on this forum that dBpoweramp and Itunes can both produce a rip which is bit-identical to the same track downloaded from the Naim cd store.

Anyone with a Naim cd can repeat this experiment. You can use foobar or dBpoweramp to compute checksums of the different rips, and foobar to bit-compare the audio.

Anyone with a Unitiserve can contribute further by making similar comparisons.

If a Unitiserve is influenced in some mysterious way by non-audio aspects of the file then it kinda puts me off thinking about one - like Hook I don't see why I should re-rip my cds. And what about downloads?

I just did a few quick checks:

A file ripped via the UnitiServe is as Simon states structured differently to a file ripped via EAC and dbPowerAmp (checked with hex editor). I don't know how to check that the PCM data is exactly the same but I see no reason to think otherwise particularly given the rips are accurate.

Although the file sizes are the same the checksum for each file is different. I suspect that the EAC and dbPowerAmp rips are almost the same - the differences are most likely down to the fact that I rip using dbPowerAmp with tagging enabled. Even though I removed the tags before I did the comparison there may well be some metadata references left in the file resulting in the checksum differences. The fact that they are similar is also supported by the fact that searching to a specific offsets in the two files shows the same data values - I guess at some point this would not be true otherwise the checksums would be the same!

However, comparing offsets in the Naim rip with EAC are completely different - I guess this is a result of how the file is structured (as stated by Simon)

Very interesting.......I would be really interested to understand what these "optimisations" are in the wav file? Also what type of artefacts can be introduced by the render when there is no optimisation.

Maybe a subject for one of the Naim chats!

I did an MD5 checksum on the Naim -vs- my uncompressed flac, they are different.

As I noted in the first post:

...No difference that I would be able to pick blind.

There were minor differences, but I wouldn't want to have to try and differentiate between teh files on a double blind test!

You can do a bit-compare of the audio portion of the files using foobar - you need to download the bit compare plug in.

You can use dBpoweramp batch convert to calculate the checksum of the audio portion of the files.

Either of these will work round the issue of potential differences in tagging.  You may need to correct for drive offsets though.

What happens when you rip a Naim cd on your Unitiserve and compare it to the same track downloaded from the Naim store?

I think naim will not commend on this. If they let their method out, every one of the freeware programmer can churn out a program doing that in 24 hours! They will protect their intellectual property I guess.

I dont know about that..... maybe the other way around.  I would guess Naim learned much from existing open source ripping engines like EAC.  Their process is VERY similar.

I think silence is a very astute marketing tool that is very effective in reinforcing ownership cults.



Some of you make it sound like there is some form of electronic voodoo at work here.



Tog

Hi

Ok this link might be a good primer on different lossless formats

http://web.inter.nl.net/users/...ossless/lossless.htm
 
There are lots on the web, but this quite interesting.

To the point about MD5 checksum being different on different FLAC compressions, well of course you would, as the files are different. The bit you after is the PCM, ie the digital worse stream of sampled data which is carried within the files.

Here is a link to the wave file format:
http://www-mmsp.ece.mcgill.ca/...rmats/wave/wave.html

Points to note is that chunks can be split into sub chunks, and that information chunks can appear at different points in the WAVE RIFF structure.

In surfing around this topic it would appear the older original 'canonical' structured mode of wave files would be more / completely consistent as there was only one FMT chunk and DATA chunk for PCM.

Having said this I think the processing overheads compared to FLAC are trivial.

Simon

It's the CRC32checksum you want, because this is of the audio data, whereas the MD5 checksum includes the tags and other bits of file structure. As I said, dBpoweramp batch convert (free) will calculate this  for you.

If the claim is that dBpoweramps rips are incorrect, lets see the proof. This is an absolutely objective, measurable issue.

No I agree, the dBpoweramp checksum method for recovered PCM of CD is excellent. I always use it. Notes with it.

You can get occasionally different checksums with different CD releases.... Interesting



Simon

Zzzzzz





Tog

In what way does that comment help anyone or contribute anything Tog?

If you aren't interested, don't care or have nothing to add, just say nothing.

What's at issue here, amongst other things, is whether dBpoweramp can rip correctly. If it does not, and the Unitiserve does, then many of us have wasted a huge amount of time ripping with it.

If on the other hand it is the UnitiServe that is wrong, then some people can avoid wasting a huge amount of money on it.

If they both produce the same rips, people can make informed choices according to their budget and inclination.

Maybe you've got £2000 to throw around on a maybe, or weeks to waste on rubbish rips. I haven't.

Tog, Yes. So is keeping the boxes black with green logo. It's designed to associate with naim and if naim was any good to you in the past, triggers your brain to associate with good sound. Part of it is psycho acoustic. They have made their statement clear. Ndx rip and serve better. In the product brochure it says they use proprietary in house algorithm for data reading and analysis. I guess we need to decide by listening and see if that is different from others.

Guys, this is kind of a non issue. I don't have a Naim ripper so can't compare dBpoweramp with it. But assuming both don't put additional header chunk into the wave file and don't use wave lists and use the traditional single FMT and DATA  chunks then try this.

1. Rip a small CD track ( no cue notes or labels ) as 16 bit stereo file.

2. Look at this link and familiarise your self with basic wave RIFF structure. Only using the FMT and DATA chunks.    
 https://ccrma.stanford.edu/cou...projects/WaveFormat/
 
3. Get any free binary file viewer such as BinViewer

4. Compare both files... Look for the word 'data'  near the beginning and look at the following 20 or so bytes.

5. If they are the same - including length sums then  I say they are both ripping correctly (or incorrectly) and they are using the same simplified WAVE format (Canonical) which has the minimm valid RIFF data required and in the same structure and so should 'sound' the same on different renderers.

Simon