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
Originally Posted by likesmusic:
Originally Posted by DavidDever:
Taking that skepticism further–how do you ultimately know that AccurateRIP is in fact correct? Statistically normal, perhaps–but correct?
Taking that skepticism further ... how do you know that Naim don't deliberately degrade third party rips in order to sound better in a dem?If the audio bits in the rip are the same, then they should be served up the same and sound the same.
If the audio bits in the rips are different, then it is an absolutely objective matter which, if any, is correct.
Which is it?
@likesmusic - get a grip this is getting ridiculous. Next you will have us believing Naim is being run by communists.
Tog
Originally Posted by Hook:
Originally Posted by DavidDever:
...
I've had this discussion with clients who have had, based on discussions with their retailer or custom integrator, their entire Compact Disc collections ripped by a third-party ripping service. You would be surprised how angry one client became when they discovered that the disc rip generated by their HDX was sonically superior to the disc ripped by their ripping service–so much so that it created a very uncomfortable situation for the retailer (and, therefore, for me).
I do not understand what a 3rd-party ripping service has to do with this conversation. I have already stated multiple times that I am willing to believe that Naim can deliver improved sound quality on playback. The reason I have not demo'ed the UnitiServe isn't philosophical -- it is that I do not want to expend the effort of re-ripping. Others may, but I don't.
And I disagree with your contention that this is as much about the computer business as audio–it's too naïve and data-centric an approach, and has been heartily re-buffed by many audio manufacturers over the last two decades or so–not just Naim, nor just with Compact Disc.
Are you disagreeing that the PCM data in Naim and non-Naim rips is the same? Yes, this is a data-centric view, but hardly naïve. Naïve would be a blind acceptance that there was some magic in all of this. Again, have already stated that I am willing to accept that the Naim software and hardware can deliver better sound quality, even with the same PCM data. The argument here is why re-ripping is the only way to get there when, at least on the surface, it would appear that an import facility would make good sense.
This is not being "objectivist". This is not the old bits-are-bits argument. This is simply a constructive suggestion for making a Naim product easier to buy into. If it was a stupid suggestion that showed a complete lack of understanding for the unique demands of software development in the audio world (as opposed to the rest of the software development world), then I apologize. Geez, twenty-five years ago when I was modifying kernel code to port SVR3 UNIX to a new supercomputer architecture, things weren't even this complicated!
It's not good enough that an audio company would take the time to find the best-sounding ripping algorithm for their servers–why is that?
You are acting like I have said something bad about the product. I don't get it.
Is this a skepticism based on an objectivist view of data? Or is it a knee-jerk reaction to the notion that, in the audio world, there are some things that require more than a superficial level of understanding from an engineering standpoint? Or, even more challenging–that there are parameters relating to these processes that shouldn't have any effect, but do nonetheless?
Sigh. Ok, now I do get it. Importing would be too hard to implement. No problem. It was a stupid suggestion. Sorry, will try to not make such such stupid suggestions in the future.
Taking that skepticism further–how do you ultimately know that AccurateRIP is in fact correct? Statistically normal, perhaps–but correct?
You asked a question -- how do we do this? I simply tossed out an idea. I never claimed it was a great idea, or even doable. It was a simple suggestion that you have, for whatever reasons, decided to overreact to.
Naim took a stand on ripping quality, developed a server, developed a streamer, and developed the applications to control them. If you feel that this exercise prohibits you from migrating to a Naim server based on objectivist data principles or other forms of orthodoxy, then maybe you're missing the point–to provide the best possible sound quality (from data acquisition to conversion to analogue).
I do not disagree on any "objectivist data principles". I am not that complex. The obstacle for me is the amount of time and effort to re-rip. If there are insurmountable technical challenges to taking the identical PCM data from non-Naim rips and putting a Naim header and trailer around them, then so be it.
Also, I never said that controlling the process from rip to playback was bad idea. I am not missing the point. I was simply suggesting that having an alternative data acquisition strategy might be a good thing for Naim to consider.
Much of this would be obvious during a demo–but, inasmuch as your retailer lives halfway across the country, this is not an easy or obvious exercise, and I suspect you've probably never had the opportunity to do the demo.
Wow, what a surprising for you to say.
Are you referring to the same remote dealer who took me from not knowing who Naim was to a DAC/555PS/252/SC/300/Superline, all Poweline'd and Hiline'd, in a little over two years? The same dealer who has invested a countless number of hours into the business relationship, and without whom I would have zero interest in Naim? You mean that guy? Yeah, you're right, he doesn't live next door. But that doesn't mean that the option for me to home demo an HDX or UnitiServe hasn't always been there -- a phone call or email away. By the way, I would rather do business with the best, not the closet Naim representation. In my opinion (and in this case, Dave, my opinion really *is* the only one that counts), I have done exactly that. We can have a discussion about local options if you want, but I doubt you would find that to be a very pleasant conversation.
This all started with me saying that I thought that an import facility would help make the UnitiServe a better product, and it ends with this? You obviously have no clue why I am financially and emotionally invested in Naim. How disappointing!
Hook (out)
I've had this discussion with clients who have had, based on discussions with their retailer or custom integrator, their entire Compact Disc collections ripped by a third-party ripping service. You would be surprised how angry one client became when they discovered that the disc rip generated by their HDX was sonically superior to the disc ripped by their ripping service–so much so that it created a very uncomfortable situation for the retailer (and, therefore, for me).
I do not understand what a 3rd-party ripping service has to do with this conversation. I have already stated multiple times that I am willing to believe that Naim can deliver improved sound quality on playback. The reason I have not demo'ed the UnitiServe isn't philosophical -- it is that I do not want to expend the effort of re-ripping. Others may, but I don't.
And I disagree with your contention that this is as much about the computer business as audio–it's too naïve and data-centric an approach, and has been heartily re-buffed by many audio manufacturers over the last two decades or so–not just Naim, nor just with Compact Disc.
Are you disagreeing that the PCM data in Naim and non-Naim rips is the same? Yes, this is a data-centric view, but hardly naïve. Naïve would be a blind acceptance that there was some magic in all of this. Again, have already stated that I am willing to accept that the Naim software and hardware can deliver better sound quality, even with the same PCM data. The argument here is why re-ripping is the only way to get there when, at least on the surface, it would appear that an import facility would make good sense.
This is not being "objectivist". This is not the old bits-are-bits argument. This is simply a constructive suggestion for making a Naim product easier to buy into. If it was a stupid suggestion that showed a complete lack of understanding for the unique demands of software development in the audio world (as opposed to the rest of the software development world), then I apologize. Geez, twenty-five years ago when I was modifying kernel code to port SVR3 UNIX to a new supercomputer architecture, things weren't even this complicated!
It's not good enough that an audio company would take the time to find the best-sounding ripping algorithm for their servers–why is that?
You are acting like I have said something bad about the product. I don't get it.
Is this a skepticism based on an objectivist view of data? Or is it a knee-jerk reaction to the notion that, in the audio world, there are some things that require more than a superficial level of understanding from an engineering standpoint? Or, even more challenging–that there are parameters relating to these processes that shouldn't have any effect, but do nonetheless?
Sigh. Ok, now I do get it. Importing would be too hard to implement. No problem. It was a stupid suggestion. Sorry, will try to not make such such stupid suggestions in the future.
Taking that skepticism further–how do you ultimately know that AccurateRIP is in fact correct? Statistically normal, perhaps–but correct?
You asked a question -- how do we do this? I simply tossed out an idea. I never claimed it was a great idea, or even doable. It was a simple suggestion that you have, for whatever reasons, decided to overreact to.
Naim took a stand on ripping quality, developed a server, developed a streamer, and developed the applications to control them. If you feel that this exercise prohibits you from migrating to a Naim server based on objectivist data principles or other forms of orthodoxy, then maybe you're missing the point–to provide the best possible sound quality (from data acquisition to conversion to analogue).
I do not disagree on any "objectivist data principles". I am not that complex.
The obstacle for me is the amount of time and effort to re-rip. If there are insurmountable technical challenges to taking the identical PCM data from non-Naim rips and putting a Naim header and trailer around them, then so be it.Also, I never said that controlling the process from rip to playback was bad idea. I am not missing the point. I was simply suggesting that having an alternative data acquisition strategy might be a good thing for Naim to consider.
Much of this would be obvious during a demo–but, inasmuch as your retailer lives halfway across the country, this is not an easy or obvious exercise, and I suspect you've probably never had the opportunity to do the demo.
Wow, what a surprising for you to say.
Are you referring to the same remote dealer who took me from not knowing who Naim was to a DAC/555PS/252/SC/300/Superline, all Poweline'd and Hiline'd, in a little over two years? The same dealer who has invested a countless number of hours into the business relationship, and without whom I would have zero interest in Naim? You mean that guy? Yeah, you're right, he doesn't live next door. But that doesn't mean that the option for me to home demo an HDX or UnitiServe hasn't always been there -- a phone call or email away. By the way, I would rather do business with the best, not the closet Naim representation. In my opinion (and in this case, Dave, my opinion really *is* the only one that counts), I have done exactly that. We can have a discussion about local options if you want, but I doubt you would find that to be a very pleasant conversation.
This all started with me saying that I thought that an import facility would help make the UnitiServe a better product, and it ends with this? You obviously have no clue why I am financially and emotionally invested in Naim. How disappointing!
Hook (out)
Originally Posted by Tog:
I think the psychological impact of spending £2000 on a UnitiServe can be blamed here - me a bottle of Chablis has a similar effect and somewhat cheaper. :-)
Tog
Tog
You might be correct. But my ears say you are wrong. So who am I to believe, you or my ears? 
One thing I have noticed is the UnityServe, certainly the SSD model does not do a simple iTunes-type rip. In iTunes as soon as it is finished, there is the ripped album.
With my UnityServe, despite taking rather longer to actually do the rip, even after the CD has been ejected and packed away, I see data continues to flow up to the NAS. As long as another 10 minutes. Whatever it is doing during this time must be something helpful, else why bother?
Obviously there is no sign of the album on the DTC until this data flow ceases.
BTW, I only noticed this effect tonight. So my comments regarding SQ were not some subliminal encouragement to believe it must be better because it takes so long to complete. 
Richard
Originally Posted by Richard Lord:
Originally Posted by Tog:
I think the psychological impact of spending £2000 on a UnitiServe can be blamed here - me a bottle of Chablis has a similar effect and somewhat cheaper. :-)
Tog
Tog
You might be correct. But my ears say you are wrong. So who am I to believe, you or my ears?
One thing I have noticed is the UnityServe, certainly the SSD model does not do a simple iTunes-type rip. In iTunes as soon as it is finished, there is the ripped album.
With my UnityServe, despite taking rather longer to actually do the rip, even after the CD has been ejected and packed away, I see data continues to flow up to the NAS. As long as another 10 minutes. Whatever it is doing during this time must be something helpful, else why bother?
Obviously there is no sign of the album on the DTC until this data flow ceases.
BTW, I only noticed this effect tonight. So my comments regarding SQ were not some subliminal encouragement to believe it must be better because it takes so long to complete.
Richard
The album is copied to its final destination after ripping–this protects against data errors caused by network faults (i.e., taking the Ethernet cable out of the rear of the server).