Naim Rips -vs- Ruby Ripper Alias WAV -vs Flac!
Posted by: Mr Underhill on 17 March 2011
In auditioning the UnitiServe & NS01 I have been struck by how much better the Naim rips were than those made using my standard ripping technique, RubyRipper on Ubuntu.
Naim rips to WAV, so was the difference due to the way Naim handles a flac file?
I used flac to decompress three of my 'flacced' albums:
Praise & Blame - Tom Jones;
The Rock Soundtrack; and
Diva - Annie Lennox.
I reripped these CDs using the UnitiServe.
In all cases playing back via US/NS01 -> nDac -> EAR864/534 -> Living Audio Auditorium II.
The WAV was easily picked for P&B and Diva. A slight edge on vocals was apparent.
Naim WAV -vs- Decompressed flac. No difference that I would be able to pick blind.
BUT:
I think this is well worth mentioning. The Naim ripping process it amazingly fast and easy. Usability is a very nice quality.
M
Naim rips to WAV, so was the difference due to the way Naim handles a flac file?
I used flac to decompress three of my 'flacced' albums:
Praise & Blame - Tom Jones;
The Rock Soundtrack; and
Diva - Annie Lennox.
I reripped these CDs using the UnitiServe.
In all cases playing back via US/NS01 -> nDac -> EAR864/534 -> Living Audio Auditorium II.
The WAV was easily picked for P&B and Diva. A slight edge on vocals was apparent.
Naim WAV -vs- Decompressed flac. No difference that I would be able to pick blind.
BUT:
I think this is well worth mentioning. The Naim ripping process it amazingly fast and easy. Usability is a very nice quality.
M
Posted on: 20 March 2011 by likesmusic
Jack - have you tried using foobar to compare the audio portions? Or using dBpoweramp to calculate the CRC32 checksum of the audio data? Both these products are free - I'd be happy to let you know how to use them to do the comparison. Should only take a few minutes.
Posted on: 20 March 2011 by Guido Fawkes
Originally Posted by Hook:
Originally Posted by Guido Fawkes:
Originally Posted by Tog:
I'm happy with Itunes. Max, XLD.
Tog
As am I - IMHO, the SQ is just as good no matter which ripper you use. Tog
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
I like the idea of an all Naim set-up and I feel confident it, at worst, would match other set-ups and could well sound better, but not convinced if it does this is because of a magic ripping process. It seems Simon and Jack are confirming that Naim's ripping engine is very well thought out as we would expect and it is very interesting - puzzled why the PCM is different though.
Posted on: 20 March 2011 by Guido Fawkes
Originally Posted by Guido Fawkes:
Originally Posted by Hook:
Originally Posted by Guido Fawkes:
Originally Posted by Tog:
I'm happy with Itunes. Max, XLD.
Tog
As am I - IMHO, the SQ is just as good no matter which ripper you use. Tog
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
I like the idea of an all Naim set-up and I feel confident it, at worst, would match other set-ups and could well sound better, but not convinced if it does this is because of a magic ripping process. It seems Simon and Jack are confirming that Naim's ripping engine is very well thought out as we would expect and it is very interesting - puzzled why the PCM is different though.
Posted on: 20 March 2011 by Jack
Likesmusic
Yes I did the comparison yesterday in Foobar and posted earlier in this thread with the details...they are different
Yes I did the comparison yesterday in Foobar and posted earlier in this thread with the details...they are different
Posted on: 20 March 2011 by Jack
Update:
I wasn't looking hard enough! Laptop no good for this sort of thing, much easier on a 24" wide screen
The first 43 bytes of the EAC file and the first 465 bytes of the Naim file are not consistent, I guess this is he difference between canonical and extended format of WAV. However, the rest of the data (i.e. from the relevant offset) is exactly same. Well almost.....there appears to be an extra 113 bytes at the end of the EAC file that isn't on the Naim file
I wasn't looking hard enough! Laptop no good for this sort of thing, much easier on a 24" wide screen
The first 43 bytes of the EAC file and the first 465 bytes of the Naim file are not consistent, I guess this is he difference between canonical and extended format of WAV. However, the rest of the data (i.e. from the relevant offset) is exactly same. Well almost.....there appears to be an extra 113 bytes at the end of the EAC file that isn't on the Naim file
Posted on: 20 March 2011 by likesmusic
Sorry Jack, should've read more closely. Got any Naim cds of which you could also download a track from the Naim store?
Posted on: 20 March 2011 by Jack
Have made an update to my previous posting.....I'm going to validate my findings as I have been playing with lots of files and editors....just to make sure my facts are correct.
Likesmusic....what comparison are you after? I have some Naim CDs but only one FLAC downloaded from the web site and that isnt on any of my CDs
Likesmusic....what comparison are you after? I have some Naim CDs but only one FLAC downloaded from the web site and that isnt on any of my CDs
Posted on: 20 March 2011 by Hook
Originally Posted by Jack:
Update:
I wasn't looking hard enough! Laptop no good for this sort of thing, much easier on a 24" wide screen
The first 43 bytes of the EAC file and the first 465 bytes of the Naim file are not consistent, I guess this is he difference between canonical and extended format of WAV. However, the rest of the data (i.e. from the relevant offset) is exactly same. Well almost.....there appears to be an extra 113 bytes at the end of the EAC file that isn't on the Naim file
I wasn't looking hard enough! Laptop no good for this sort of thing, much easier on a 24" wide screen
The first 43 bytes of the EAC file and the first 465 bytes of the Naim file are not consistent, I guess this is he difference between canonical and extended format of WAV. However, the rest of the data (i.e. from the relevant offset) is exactly same. Well almost.....there appears to be an extra 113 bytes at the end of the EAC file that isn't on the Naim file
Nice work Jack! So, given the data is the same, we are left to wonder what type of benefit, if any, a Naim decoder will derive from this extended information.
The other thing we are left to wonder is whether the Naim decoder (if using this information for some form of optimization), could use a similar scheme for FLAC or any other file structures. Do you know if the FLAC standard describes both canonical and extended format?
My guess is that Naim will not volunteer any info on this, but it would be fun to ask one of their designers these questions on an upcoming live chat!
Thanks again for your time and effort!
Hook
Posted on: 20 March 2011 by likesmusic
Jack - what I had in mind was .. rip a track of Naim cd using EAC. rip using UnitiServe. download same track from naim store. Compare the three files, and the checksums. See if there's any difference in the audio whatsoever.
Posted on: 20 March 2011 by Jack
I don't have the UnitiServe anymore I was just trying it out and kept some rips, however, I'm certain from the tests completed over the weekend that any file ripped via tthe UnitiServe would be different to that ripped from CD via EAC - different in as much as the wav header would be different - the PCM data would be the same.
Will try the download when I get some time.
Will try the download when I get some time.
Posted on: 20 March 2011 by likesmusic
I await an explanation from the deepest depths of voodoo and pseudo-science as to why minor differences in the WAV header might make an audio difference.
Posted on: 20 March 2011 by Simon-in-Suffolk
Hook, the so called canonical and extensible format, is specific to wave files. Effectively the extensible FMT extension and its associated Fact chunk was added to support hidef and av data within the wave file format. The FLAC file format is different and has a different internal file structure. I don't know if there are legacy versions of FLAC, however I doubt it as it's a newer file format., where as wave files go back 20 years or so.
Simon
Simon
Posted on: 20 March 2011 by Simon-in-Suffolk
Likemusic if the PCM wave data chunk is the same in the fiiles I can't really see how there can be any audible differences other than say if the software algorithm used by the decoder changes if it sees the extensible FMT header extension and the associated sample length fact chunk. Perhaps if it sees a traditional two chunk wave file (canonical) then a simplified algorithm is used. I can't really see how anything else could affect the 'sound' quality, but we have to be talking very subtle here. The difference with FLAC if there is going to a difference would be more obvious.
Simon
Simon
Posted on: 20 March 2011 by Tog
This obsession with the intricacies of wav could of course be a total red herring. You may be able to hear the boffins at Naim chuckling to themselves ..."we just tried lots of combinations of buffers, capacitors and beer until the wav file sounded great... We had such a good time we completely forgot to check flac ..... Now where did we put that copy of Vortexbox?"
I had some issues with wav chunks once but then I'd had an awful lot to drink and my extensible format got very cross and she got all canonical about it.
Keep going guys ... I have absolutely no idea what you are on about but it is very entertaining ... There was a thread on jitter over at CA that went on for six months .... the USB lead argument is still going on..
Tog
I had some issues with wav chunks once but then I'd had an awful lot to drink and my extensible format got very cross and she got all canonical about it.
Keep going guys ... I have absolutely no idea what you are on about but it is very entertaining ... There was a thread on jitter over at CA that went on for six months .... the USB lead argument is still going on..
Tog
Posted on: 20 March 2011 by Simon-in-Suffolk
Tog,
Remember some of us on this forum are also 'boffins' working in similar fields, just not for Naim...... I know what I've learned im this little foray could well be useful for my line of work at some point....
Just because you might not be an engineer doesn't stop those of us who are or have an engineering approach discussing this in a personal capacity..
Jack, thanks for your help on this as well... At least on this consumer forum we have helped managed to dispel some of the myths and snake oil purveyed by those that really have no idea what's going on and believe its all magic and can only be understood by some divine being...
Cheers
Simon
Remember some of us on this forum are also 'boffins' working in similar fields, just not for Naim...... I know what I've learned im this little foray could well be useful for my line of work at some point....
Just because you might not be an engineer doesn't stop those of us who are or have an engineering approach discussing this in a personal capacity..
Jack, thanks for your help on this as well... At least on this consumer forum we have helped managed to dispel some of the myths and snake oil purveyed by those that really have no idea what's going on and believe its all magic and can only be understood by some divine being...
Cheers
Simon
Posted on: 20 March 2011 by Tog
I used to love it in postgraduate seminars when people would be getting all technical and reading stuff into texts that were really quite straightforward. Even better when you had an author in front of an audience admitting that sometimes he just wrote stuff because it was the first thing that occurred to him. The most fun are the post- modernists .... Fantastic.
Anyway carry on Simon ... And thank you for helping us poor consumers understand the difference between science and magic .... Now if you could just tell us about fire we could start organising ourselves into small groups and build a civilisation maybe even develop hifi.
Tog :-) Second cave on the right
Anyway carry on Simon ... And thank you for helping us poor consumers understand the difference between science and magic .... Now if you could just tell us about fire we could start organising ourselves into small groups and build a civilisation maybe even develop hifi.
Tog :-) Second cave on the right
Posted on: 21 March 2011 by Jan-Erik Nordoen
Undesired clicks and pops in the thread signal can be removed by setting the Tog value to "slnt".
Posted on: 21 March 2011 by Tog
Originally Posted by Jan-Erik Nordoen:
Undesired clicks and pops in the thread signal can be removed by setting the Tog value to "slnt".
"Quot capites, tot rationes"
Tog
Posted on: 21 March 2011 by Jan-Erik Nordoen
Originally Posted by Tog:
Originally Posted by Jan-Erik Nordoen:
Undesired clicks and pops in the thread signal can be removed by setting the Tog value to "slnt".
"Quot capites, tot rationes"
Tog
Agreed, if the opinion is technically informed, otherwise it's just "sonitus in ratio".
Jan
Die dulci fruere !
Posted on: 21 March 2011 by Jan-Erik Nordoen
If anyone else is feeling, like me, a bit overwhelmed by the technical language, there's a good primer here, in addition to the links posted by Simon :
http://www.sonicspot.com/guide/wavefiles.html
http://www.sonicspot.com/guide/wavefiles.html
Posted on: 21 March 2011 by Tog
Originally Posted by Jan-Erik Nordoen:
Originally Posted by Tog:
Originally Posted by Jan-Erik Nordoen:
Undesired clicks and pops in the thread signal can be removed by setting the Tog value to "slnt".
"Quot capites, tot rationes"
Tog
Agreed, if the opinion is technically informed, otherwise it's just "sonitus in ratio".
Jan
Die dulci fruere !
"informed debate is a marvelous thing but in the meantime what do you think?"
Tog
Posted on: 21 March 2011 by Jan-Erik Nordoen
Well, I think that files ripped by the UnitiServe sound bloody marvellous. In fact, the simple gesture of inserting a CD into the Serve and watching the extraction progress has now taken on the aura of ritual usually associated with careful preparation of an LP for playback. Oh dear, I must get out more.
Jan
Jan
Posted on: 21 March 2011 by manicm
Originally Posted by DavidDever:
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)?
Which lends assertion to my thinking that, insofar as doing so from an existing CD, there is no such thing as a 'bit-perfect' rip. I like how that term has been thrown around everywhere.Posted on: 21 March 2011 by Jan-Erik Nordoen
David's explanation is that there is no way of tracing the origin of the copied file. I don't think he's suggesting that the bits are not identical. It's the packaging that changes, if I've understood this thread corrrectly !
If copies are not bit-perfect, then we have a slight problem...
Posted on: 21 March 2011 by likesmusic
So if there's no such thing as a bit perfect rip ... then the UnitiServe doesn't do a bit perfect rip .. really??!