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

Simon,

Will try and do that later, got to go out now, however, I did a quick bit compare with Foorbar and the tracks ripped with EAC and dbPoweramp are the same. The Naim ripped track is different, here is what it reports:

Differences found in 1 out of 1 track pairs.
Comparing:"C:\Documents and Settings\Jack\My Documents\EAC Ripped\01 - Donald FagenEAC -Morph the Cat.wav""C:\Documents and Settings\Jack\My Documents\EAC Ripped\01 - Morph the Cat.WAV"Differences found: 36089147 sample(s), starting at 0.0000000 second(s), peak: 1.9451294 at 235.6461452 second(s), 1ch 

I no longer have the UnitiServe so only have a few test rips I completed when I played with it

Lighten up Likesmusic - if you have read any of my previous posts you will know that I'm not in favour of throwing £2000 anywhere - indeed some around here think I'm on some form of Vortexbox fuelled (-£2000) anti UnitiServe crusade (which I'm not by the way) 

I am interested but not sure where this argument of rip comparisons is getting anyone. I've been ripping music for years, Itunes, Max and XLD. They are fine but that is not to say the software rendering them hasn't got better or that Naim have a bias towards wav and Linn like flac.

I worry more about the quality of the source recording as any rip differences will be tiny IMHO. I worry about the grey in my hair not the shape of the follicles.

@Ihau -"in house algorithm" bet the marketing boys love that - bit like this face cream contains bi-retinol H - basically means we've either adapted some open source code, licensed some proprietory code or called the guys in ad-land for help.

If you use an Ipad on this forum you can't use so I'm using an Imac now ..... so

   Tog

I would be interested in any hard evidence that dBpoweramp rips are incorrect.

It's also worth noting that, afaik, a UnitiServe cannot rip the full 20 bits of an HDCD encoded disc, whereas dBp can.

Now my curiosoty was raised I compared three rippers creating wave files from CD

iTunes: Ripped the audio as just two RIFF chucks (fmt & data) but ommitted samples at the very start of the track - not audible however - and the chunk size was correct

dBPowerAmp: Ripped audio. had no missing samples, had one fmt and one data chunk but also had two extra RIFF chunks called  'LIST' and 'id3' which I assume contain meta data

EAC: Ripped data with no missing samples, and only contained the two fmt and data chunks with no additions


Therefore conclusion is EAC and dBPoweramp are accurate, iTunes is not (might be to do it is not correctly handling the offset in my CD Drive). iTunes and EAC produced the purest/simplest wave file format with just the fmt and data RIFF chunks.

In practice although dBPoweramp added chunks and so there is a parsing overhead - albeit minutely small, the additional chunks are at the end of the file and so I can't see it really having any difference in practice on a renderer - as the data would have all ready been rendered.      

But as you can see I produceed three different wav files from the same CD track...     
  
Simon

I suspect if you knock off the drive offset, the audio of the iTunes rip will be the same as the other two. But to be absolutely  pedantic all you've shown is that dBpoweramp and EAC produce the same rip, not that either is correct. And the issue has been raised as to whether the UnitiServe is. So we need a UnitiServe rip to compare, and for completeness, a download from the Naim store. Any offers anyone?

Because the forum has moved homes, I can't locate the posts that compared EAC, WMP, dbPoweramp, iTunes and the Naim store the last time this issue was raised - but iirc the CRC32 checksums showed that all five were identical, if you allowed for drive offset.

imo it is a really serious accusation to suggest that dBpoweramp gets rips wrong, and should be proved.

Ike, there is no way I can see to adjust the offset in iTunes. The point is the samples are all shifted in time slightly and padded, so as long as the track has a tiny slience at the start and at end you are fine - otherwsise you might hear a click. This might be an issue for tracks that flow into each other without breaks.
Indeed all I have shown is that the variations in wave files produced by different rippers.
I agree it would be interesting to see the format of a Naim ripper. I suspect it will be a basic canonical two format RIFF file with no meta data - ie the purest / simpelst form.. and Naim will almost certainly have accounted for the CD drive offset - and so my money is that it looks identical to the EAC - but we will see hopefully from Jack's test files...

Simon

You assume that the downloads on the Naim Label site are identical to the CD releases, though, which may not be the case. All of this reminds me of the concept of "fake fakes" from the writings of Philip K. Dick. Since we have no way of knowing whether a WAV file (or any other type) corresponds to a specific CD rip (as PQ subcode is not copied across), there is no homomorphism between CD rips and the extracted files. Likewise (having worked on the mastering side) there is no map from 16-bit / 44.1 kHz mix files to an assembled CD (as there is no PQ subcode in the original file). So-if the CD is THE release and is treated as the ideal copy, what is the measure of "fakeness" that reduces the value of subsequent copies (either the disc in toto, or extracted tracks)?

Dave - I agree. However I beleive we are talking about rips created with Naim products such as Unitiserve and comparing them with other ripping methods. There is no mustique or magic just nice straightforward bits and bytes. Thats the beauty of digital file formats. How they are rendered and converted into analgue formats is another matter......

Absolutely - i use dBPoweramp all the time and am happy it produces accurate relaible PCM within its WAV files. What I have discovered today is that adds its own Chucks into the Wave file format. PCM and Wavefiles are not the same. As long as the PCM data is not corrupted  it can always be converted and repackaged. Indeed there utiliities on the web that could take a dBPoweramp wave file and covert it to the simplest wave file format to simplify decoding by the renderer and aid interoperability. The PCM hasn't changed however, and this is the same argument that holds for  FLAC.

Anyway I have provided the links earlier hopefully to allow anyone to do their  own comparisones rather than rely on anyone else to tell them - its all quite straightforward and rather enlightening, it was for me. Its better to see the evidence yourself rather than rely on others in my books - as you never know whether they have vested interests....

Here are some good utilites to decode chunks to see what is in those wav files besides the PCM.
http://techweb.rfa.org/bu/chunk.html   
   
Simon

You do have a way of knowing whether a WAV file corresponds to a CD rip if you made the WAV file and the CD. Naim make cds, and sell them in their stores. If you are suggesting that the Naim cd store has inaccurate rips, then let us know. If you are suggesting that the UnitiServe rips differently then let us know. Either way, put up a UnitiServe rip of a Naim cd so that people can compare it to rips from other ripping engines. Otherwise you are just using a lot of long words to obfuscate what is really a simple issue.

simon - iirc if you temporarily set the disc offset in dBpoweramp to 0 you'll get the same CRC32 checksum as an iTunes rip.

...which implies that, given a Windows PC with both iTunes and dBpoweramp installed and a supported drive mechanism with a non-zero drive offset, if the dBpoweramp rip is shown to be frame-accurate, then the iTunes rip must not be.

Likemusic I think what Dave means is that since naim didn't have to rip the music from a cd - they already have the high res file. They may not be the same on the cd?

It is often hard to understand what Dave means.

Last time anyone did the experiment it was possible to use dBpoweramp to rip a Naim cd with exactly the same CRC32 checksum as the same cd downloaded from the Naim store.

It is hard to undertand how a UnitiServe could do a better job.

The drive offset issue only concerns a very few microseconds of silence right at the beginning of an album.

Once again I challenge David to produce a UnitiServe rip to substantiate his claims that it is superior.

Everyone who makes a ripper or software that rips is going to say theirs is the best - anyone ask Spoon over at Asset? I think I know what his answer will be. I really don't know what all the fuss is about ... if your rips sounded OK to you yesterday - why are they not OK today. I'm happy with Itunes. Max, XLD and Ripit.

Tog

       




I think ppl are just trying to optimize the absolute best here.



From a forum full of people trying to adjust speaker spike to the mm, it is not too surprising ppl want to know about this I guess.

I compared the content of a rip completed with EAC without any tagging and one completed with the Unitiserve. The EAC rip appears to align completely with the canonical form as described in one of the links Simon provided. It contains the fmt and data chunk.

However, the Naim rip also includes a "fact" chunk and some additional padding near the start of the file. The data portion doesn't look the same either. I've been trying to align the values but they don't seem to line up.  One of the links Simon provided indicated that non-PCM files require a "fact" chunk......I need to do some more reading!

Jack interesting... the non canonical wavefile format looks like

<WAVE-form> ->
RIFF (

'WAVE’
<fmt-ck> // Format
[<fact-ck>] // Fact chunk
[<other-ck>] // Other optional chunks
<wave-data> // Wave data
)

Ok - further reading I see that any wave file to support high definition audio (or multimedia / AV etc) should  use the new wave format with a fact chunk and an extended wave format description within the fmt chunk. This is what I suspect you are seeing.
8 and 16 bit wave files can use the older canonical format, but for higher values it is recommended to use the new fromat - becasue of ambiguities in the interpretation of various paramters in the old format such as bits per sample and Block align which can cause interoperability errors between encoders and decoders.

Therefore this suggests to me that Naim might have optimised the encoding of the wave file to follow aonsistent approach no matter the resolution of the file. This perhaps simplifies decoding the wave file for a more consistent result,

Simon

Guy & Tog -

Agreed.  But the whole point of this exercise, as far as I am concerned, is to determine if there is anything special about the Unitiserve->Naim Rip->NDX cycle that makes the whole greater than the sum of its parts.

I can accept that an NDX has great sound quality, but question whether it can get more out a Naim rip than an EAC rip.

I can accept that a UnitiServe offers great ease-of-use, and is a fine digital source for the Naim DAC on its own.  But I question whether it is doing anything better than EAC when it comes to the actual musical data in the rip.

I, for one, am very appreciative of Jack's and Simon's efforts to bring some of this more mysterious stuff into the light.   For me, it is not a simple intellectual exercise.  To me, it is the basis upon which a decision to (someday) invest wholly or partially in Naim's server/renderer strategy will be made.

Hook

It looks as follows:

<WAVE-form> ->
RIFF (

'WAVE’ 
<fmt-ck> // Format
[<fact-ck>] // Fact chunk
<wave-data> // Wave data
)

I cant find any chunk called 'wavl'. I also had a look at a FLAC file that I had downloaded from the Naim web site and subsequently converted to wav - it looks like the standard canonical not like the Naim ripped file.

 

Jack - yes please refer to me previous post that I have now updated. You Naim wave decode makes sense now.
Regarding your FLAC to wave point,  the strcuture of that wave file will entirely depend on the encoder used to convert the FLAC to wave - remember the PCM stays the same.

In summary it appears that Naim, quite correctly, are using the extensible wave format configs so as to cater for hidef audio and possible processing optimisations with thier decocders on sample block boundaries.

http://msdn.microsoft.com/en-u...ws/hardware/gg463006

Simon

Simon,

That makes sense, thanks for all the pointers to additional information. What I can't understand is why I don't seem to be able to match the PCM data in both files, surely this should be the same? Maybe I'm not looking hard enough but certainly the data at the start of the data section in each file is different!

That is the essence of it. For were it to be true, it implies needing to re-rip all your cds in order to make the most of them, were you to buy an NDX.