unitserve rips vs core rips
Posted by: French Rooster on 07 January 2017
this topic is not accessible anymore. unitserve rips are better than core rips and naim don't like it?
Simon-in-Suffolk posted:NBPF Who is looking at 4 pairs of samples - what is that all about then? Have I missed another thread on the subject?
We all are missing a thread, I'm afraid: in the beginning it was 4 pairs, the wavs and the WAVs. The wavs had short necks and long tails and felt ugly. They were shy and sad. The WAVs were gorgeous and proudly sang and praised the unity of the spheres. And Naim came and said: so the wavs will be WAVs and the WAVs will be wavs and the distinguishables will become equal. And the wavs grew tall and beutiful and the wavs and the WAVs sang with the same voice and that was the voice of Naim. Or something like that.
Remember that an opera will often have 60 or so "tracks", some only a few seconds long. Any kind of click or audible discontinuity would be insufferable. Throwing away samples is just incompetent imo. And this from a company that repeatedly claimed its own rips were superior to dBpoweramps!
As far as I know, these 'clicks' are just hypothetical at the moment. Has anyone ripping with a Core actually heard one yet?
likesmusic posted:Remember that an opera will often have 60 or so "tracks", some only a few seconds long. Any kind of click or audible discontinuity would be insufferable. Throwing away samples is just incompetent imo. And this from a company that repeatedly claimed its own rips were superior to dBpoweramps!
That's what I had in mind when I posted my comments above. However, I am not clear whether this situation does arise or might arise with Core or any other ripping device.
I get no dropped sample data from my rips with dBPoweramp under Windows or OSX
ChrisSU posted:As far as I know, these 'clicks' are just hypothetical at the moment. Has anyone ripping with a Core actually heard one yet?
Considering that one can easily and cheaply produce rips which are provably bit perfect and produce no playback artifacts with certainty, I am sure that Naim is very much concerned about rips which are not bit perfect and about artifacts that do not have to be audible but that could be audible, perhaps under conditions difficult to reproduce.
In other words, I am sure that Naim is very concerned about artifacts that cannot be ruled out with certainty or, at least, a very high degree of probability. Such artifacts could indeed lead to error-prone diagnoses and higher future support costs, expecially if users start ripping large CD collections. Do not forget that not all those who have ordered a Core are crazy enough to read (let apart make sense of) our contributions to this thread: just think of my posts with editing tips a few pages upstream!
At this point, I doubt that anyone can reliably estimate the probability that Core rips lead to audible artifacts. Thus, it makes a lot of sense for Naim to play safe and fix the problem before investigating its possible consequences in detail. This is particularly true if the Core's ripping software can be set up to produce bit perfect rips with moderate efforts. I think that this is the case and the fact that Naim plans to resume shipping the Cores next week seems to support this opinion.
Don Atkinson posted:likesmusic posted:Remember that an opera will often have 60 or so "tracks", some only a few seconds long. Any kind of click or audible discontinuity would be insufferable. Throwing away samples is just incompetent imo. And this from a company that repeatedly claimed its own rips were superior to dBpoweramps!
That's what I had in mind when I posted my comments above. However, I am not clear whether this situation does arise or might arise with Core or any other ripping device.
I tested dBpoweramp against foobar and iTunes; they all produce bit identical rips when you take drive offset into account. iirc Simon showed some time ago they were also the same as Naims earlier rips and downloads. Of course it is possible all these ripping solutions, including Naims own, are wrong and the Core is right. But I doubt it.
likesmusic posted:Remember that an opera will often have 60 or so "tracks", some only a few seconds long. Any kind of click or audible discontinuity would be insufferable. Throwing away samples is just incompetent imo. And this from a company that repeatedly claimed its own rips were superior to dBpoweramps!
I fully agree that flawless gapless playback is essential, expecially for opera. I also find it very difficult to understand how Naim might have failed to spot the ripping errors before starting shipping the Cores. On the other hand, we know that shit happens. It happens at Samsung, at Apple, at Google. And it also happens to us and at Naim. I am more concerned with the way companies react to well documented error reports (more than one year after they have thrown at the market a tablet computer with a miserable wireless performance, Coogle has still not managed to acknowledge their mistakes) and serious reviews. In the specific case of the Core, I am more concerned about the lack of detailed technical documentation and about the lack of support for software that I consider to be essential for a music server.
(Edit: and, even more annoying: why do they keep on calling the Core "revolutionary"? It's designed to do what the US was designed to do 7 years ago. And we meanwhile know that it is not even already there)
nbpf posted:likesmusic posted:Remember that an opera will often have 60 or so "tracks", some only a few seconds long. Any kind of click or audible discontinuity would be insufferable. Throwing away samples is just incompetent imo. And this from a company that repeatedly claimed its own rips were superior to dBpoweramps!
I fully agree that flawless gapless playback is essential, expecially for opera. I also find it very difficult to understand how Naim might have failed to spot the ripping errors before starting shipping the Cores. On the other hand, we know that shit happens. It happens at Samsung, at Apple, at Google. And it also happens to us and at Naim. I am more concerned with the way companies react to well documented error reports (more than one year after they have thrown at the market a tablet computer with a miserable wireless performance, Coogle has still not managed to acknowledge their mistakes) and serious reviews. In the specific case of the Core, I am more concerned about the lack of detailed technical documentation and about the lack of support for software that I consider to be essential for a music server.
nbpf, it is particularly ironic since Paul Stephenson claimed on 23/03/11 that naim rips sounded better than dBpoweramp/EAC rips:
"Easy naim rip via our server easy db and eac good but our rip and our drive choice usually outperforms"
and
"its the combination of hardware and software, the files will look identical from,db,eac or itunes but from the experiences we have had here the sound is not."
I repeatedly challenged him to produce a such naim rip so that we could all listen to the comparison, and compare the data, but he never did.
likesmusic posted:nbpf, it is particularly ironic since Paul Stephenson claimed on 23/03/11 that naim rips sounded better than dBpoweramp/EAC rips
I don't know what Naim's position is today, but that was a lowlight and I think we've all moved past it, or at least the vast majority of Naim ripper owners and non-Naim ripper owners alike here.
The standard seems to be 'bit perfect accounting for drive offset' and all I can glean from 4+pages of forum posts is that perhaps drive offset hasn't been accounted for properly in the unit that was tested. If this is the case, it's certainly an easy software fix.
Bart posted:...perhaps drive offset hasn't been accounted for properly in the unit that was tested...
Can drive offset vary within different units of an identical model?
likesmusic posted:nbpf posted:likesmusic posted:Remember that an opera will often have 60 or so "tracks", some only a few seconds long. Any kind of click or audible discontinuity would be insufferable. Throwing away samples is just incompetent imo. And this from a company that repeatedly claimed its own rips were superior to dBpoweramps!
I fully agree that flawless gapless playback is essential, expecially for opera. I also find it very difficult to understand how Naim might have failed to spot the ripping errors before starting shipping the Cores. On the other hand, we know that shit happens. It happens at Samsung, at Apple, at Google. And it also happens to us and at Naim. I am more concerned with the way companies react to well documented error reports (more than one year after they have thrown at the market a tablet computer with a miserable wireless performance, Coogle has still not managed to acknowledge their mistakes) and serious reviews. In the specific case of the Core, I am more concerned about the lack of detailed technical documentation and about the lack of support for software that I consider to be essential for a music server.
nbpf, it is particularly ironic since Paul Stephenson claimed on 23/03/11 that naim rips sounded better than dBpoweramp/EAC rips:
"Easy naim rip via our server easy db and eac good but our rip and our drive choice usually outperforms"
and
"its the combination of hardware and software, the files will look identical from,db,eac or itunes but from the experiences we have had here the sound is not."
I repeatedly challenged him to produce a such naim rip so that we could all listen to the comparison, and compare the data, but he never did.
Awkward. On the 23rd of March, my wife's birthday! Paul, son of Stephen: non isperate mai veder lo cielo!
Jan-Erik Nordoen posted:Bart posted:...perhaps drive offset hasn't been accounted for properly in the unit that was tested...Can drive offset vary within different units of an identical model?
"A small number of drives have [Purged] as the offset, these drives were found not to have a constant drive offset (perhaps different manufacturing batches, or firmwares), as such they have been removed from AccurateRip's drive database"
from http://www.accuraterip.com/driveoffsets.htm
Jan-Erik Nordoen posted:Bart posted:...perhaps drive offset hasn't been accounted for properly in the unit that was tested...Can drive offset vary within different units of an identical model?
I don't know. My unfounded speculation was that perhaps the offset simply had not been accounted for accurately in the embedded ripper software; someone forgot, typed in the wrong value, etc etc. Totally unfounded speculation, but such is rampant these days 
I've seen ripper software that detects or asks for the model, so as to adjust offset. Are there rippers that "test" offset for one's specific drive and then adjust accordingly? I have no idea whether this is possible, or even needed . . . just pondering!
Bart posted:Jan-Erik Nordoen posted:Bart posted:...perhaps drive offset hasn't been accounted for properly in the unit that was tested...Can drive offset vary within different units of an identical model?
...
I've seen ripper software that detects or asks for the model, so as to adjust offset. Are there rippers that "test" offset for one's specific drive and then adjust accordingly? I have no idea whether this is possible, or even needed . . . just pondering!
I seem to remember that Rubyripper (cdparanioa frontend) tries to compute a drive offset if no specific value is given by users. But I have not used Rubyripper since a while and I have a bad memory. I should be able to check it out, though. Best, nbpf
iirc from an online exchange with Mr Spoon, the author of dBpoweramp, drive offset only affects the very first track on a cd. So, if failing to deal with drive offset correctly is the cause of this problem with the Core's rips then it should only be an issue on the first track of a cd. Is this the case, or are there missing bytes on every track? Simon - was the track you looked at track 1?
likesmusic posted:iirc from an online exchange with Mr Spoon, the author of dBpoweramp, drive offset only affects the very first track on a cd. So, if failing to deal with drive offset correctly is the cause of this problem with the Core's rips then it should only be an issue on the first track of a cd. Is this the case, or are there missing bytes on every track? Simon - was the track you looked at track 1?
Not sure about this. If the issue is caused by the software misreading the offset, then all the tracks might be slightly "out" of bitperfect. If the offset value is too high then there could be samples missed on track 1 but if it is too low would samples be missed at the end of the last track? Less of an issue perhaps if one is ripping and playing back a whole CD but maybe more of an issue if selecting individual tracks to rip?
On the Core you can't select tracks to rip. It's the whole CD or nothing!
best
David
Thanks for the clarification, David. Presumably you can then delete any "unfavourite" tracks after ripping?
Steve
sjbabbey posted:likesmusic posted:iirc from an online exchange with Mr Spoon, the author of dBpoweramp, drive offset only affects the very first track on a cd. So, if failing to deal with drive offset correctly is the cause of this problem with the Core's rips then it should only be an issue on the first track of a cd. Is this the case, or are there missing bytes on every track? Simon - was the track you looked at track 1?
Not sure about this. If the issue is caused by the software misreading the offset, then all the tracks might be slightly "out" of bitperfect. If the offset value is too high then there could be samples missed on track 1 but if it is too low would samples be missed at the end of the last track? Less of an issue perhaps if one is ripping and playing back a whole CD but maybe more of an issue if selecting individual tracks to rip?
If I were to tell you that none of the 4 tracks involved were track 1 of the album they came from, that might imply that file sharing of those albums had been done. So I won't 
sjbabbey posted:Thanks for the clarification, David. Presumably you can then delete any "unfavourite" tracks after ripping?
Steve
no - there is no editing, or metadata editing as yet
jon honeyball posted:sjbabbey posted:Thanks for the clarification, David. Presumably you can then delete any "unfavourite" tracks after ripping?
Steve
no - there is no editing, or metadata editing as yet
This leads to the question - What happens to other functions of GUI and DTC eg. encoding, rescanning, backing up playlists etc? Will they be in the app?
You choose encode format at time of rip
there is no recode to MP3/320 in parallel as is in hdx
If you can't edit metadata yet, then IMO the product (by which I mean the device and the user experience lumped together) is not ready for release. Some automated metadata is rubbish, and some is OK but not how you'd want it yourself.
If I couldn't correct metadata in both of those cases, I'd find that a deal breaker. Not that I'm in the market for a Core at the moment, but if I were.
jon honeyball posted:sjbabbey posted:Thanks for the clarification, David. Presumably you can then delete any "unfavourite" tracks after ripping?
Steve
no - there is no editing, or metadata editing as yet
How can Naim imagine that people will use the Core for ripping their CD collections if they cannot edit metadata on the Core? This does not make any sense to me: if one has to transfer the Core rips to another system for editing and then back to the Core, one is better off ripping on an external system from the very beginning.