unitserve rips vs core rips

jon honeyball posted:

oh and naim could do the rips and provide them to beta testers if they think it is significant etc etc etc

I think we can put the rip issue to bed:

• Four out of six listeners tend to prefer rip B over A, and two listeners can pick out B as preferable over A in a blind test;
• A technical difference is found between the rips, that could explain what we're hearing;
• A FW update (that will presumably fix the issue) seems imminent.

Simon-in-Suffolk posted:

Sloop John B posted:

[@mention:1566878603876589]

in laypersons terms, what is

 

 the absolute timing or offset of the samples within the rip file itself ?

i'm finding this difficult to understand, I thought that once ripped, checked off the accurate database, a rip is a rip is a rip 

 

SJB

SJB

Here goes; [ ] is the container of the cd rip samples; 0  is a zero sample that precede and post-cede the info samples in the observed rips; abcdefg... are the info samples i.e. musical samples

So the sample list looks like:

File X

[00000000000abcdefghijklmnop00000000]

File Y

[0000abcdefghijklmnop000000000000000]

 

You can see the musical info samples are bit perfectly the same - however their absolute position in the ripped file is different so the overall container of all the samples is not bit perfect between the two files.

S

Thanks Simon, even I understand that.  3 questions spring to mind- 

Is this a random process or is one of the above samples correct and the other not?

Would both the samples above get an accurate rip correct identification or only one of them?

is this to do with the ripping process or media being written to?

thanks again for sharing your scientific understanding.

SJB

Hi I can't answer the top two questions - as these were test files and I hadn't ripped them - but the last query is that it is entirely down to the ripping process

I dont know the sound of the serve But i am really impressed by the core. The first 200 hours of playing it was really DIssapointing. I could not believe that a harddrive unit would need burn in. But somehowe in my case it did.  I stil have Some serieus problems. If i put rips from my nas on in the download folder of the core, it only shows about 20 rips of the 300. As woon as i remove the rips out of the download folder of the core everything is normal again.

HoistTec posted:

I dont know the sound of the serve But i am really impressed by the core. The first 200 hours of playing it was really DIssapointing. I could not believe that a harddrive unit would need burn in. But somehowe in my case it did.  I stil have Some serieus problems. If i put rips from my nas on in the download folder of the core, it only shows about 20 rips of the 300. As woon as i remove the rips out of the download folder of the core everything is normal again.

Naim are still sorting it all out, so I expect this issue will be fixed too. And once a few more forum members have got their hands on the Core and played with it, I expect normal service of us being able to suggest what to try will be resumed! In the meantime you could drop Naim Support an email and ask for advice on your downloads folder is due.

best

David

Simon-in-Suffolk posted:

Hi I can't answer the top two questions - as these were test files and I hadn't ripped them - but the last query is that it is entirely down to the ripping process

I wasn't referring to the rips mentioned here as I missed that whole thread, what I'm asking is

is there a correct place for the zeros to be?

If they are in the correct place is this something accuraterip checks or would any sample with the abcdefghijklmnop no matter where the zeros were show up as accurate?

 

thanks, John

.SJB

Jan-Erik Nordoen posted:

jon honeyball posted:

oh and naim could do the rips and provide them to beta testers if they think it is significant etc etc etc

I think we can put the rip issue to bed:

• Four out of six listeners tend to prefer rip B over A, and two listeners can pick out B as preferable over A in a blind test;
• A technical difference is found between the rips, that could explain what we're hearing;
• A FW update (that will presumably fix the issue) seems imminent.

I'm skeptical whether the conclusion that there is an issue is quite accurate.  You hear what you hear, no argument there, but the little experiment was to get at something more objective.  But such results will always be bell curves, there will be false positives, etc.  I'm no statistician but one result off from a draw (i.e. 4v2 versus 3v3) in such a small sample doesn't seem very conclusive about anything at all.  With respect, the previous 6 out of 11 and 5 out of 6 results (or similar - I think that's what they were?) you found could still be random, too - there just isn't enough data.

I'm not saying there is no SQ difference, for all that the reasons would be poorly understood if there were.  I'm just saying that the test isn't very conclusive.  The rip issue hasn't even sipped its Horlicks.

The data offset that Simon found is more concrete, though.  It's beyond me to see why or how it might have an impact on SQ.  But it's an interesting thought that it might.

I also very much doubt that the outcome of the tests allows drawing any definitive conclusion.

At this point, the crucial question is whether the samples obtained by ripping on the US and on the Core are identical modulo offset (see posts by SiS above) or not. There are only two possible answers:

1) That the samples are not identical modulo offset. In this case there is a problem no matter how the samples do sound.

2) That the samples are identical modulo offset. In this case there is a problem only if the samples are found to sound differently by empirical tests. This would imply that the replay system used in the empirical tests treats files with different offsets differently. This is likely not the intended behavior and certainly not the expected one.

Just for completeness: I was among those that could not hear any difference between the A and B samples. This experience (or, in fact, lack thereof) might bias my interpretation of the outcome of the test.

Still, I believe that an interpretation of the test is only meaningful after the question of the identity modulo offset of the samples has been sorted out. If I have understood SiS correctly, this takes some time but luckily can be done by inspection.

So the sample list looks like:

File X

[00000000000abcdefghijklmnop00000000]

File Y

[0000abcdefghijklmnop000000000000000]

Simon, I have been following this thread and its predecessor.  I don't quite understand your sampling explanation above, although it does appear to be very helpful.

In a piece of music, which lasts (say) for 5 minutes (300 seconds), does your sample above,

represent the entire 300 seconds, in which case File Y starts playing music a little bit sooner than File X, but otherwise there is no difference, or

represent the first "note", (let's assume this is 1 second long) in which case there are a further 299 [ ]s. If so,

are there always the same number of 0000's in File X and File Y between the end of one note at bit "p", and the start of the next note at bit "a".

Presumably the number of 0000's can vary between notes as defined by the music and is not always 19 "zeros" long.

Sloop John B posted:

Simon-in-Suffolk posted:

Hi I can't answer the top two questions - as these were test files and I hadn't ripped them - but the last query is that it is entirely down to the ripping process

I wasn't referring to the rips mentioned here as I missed that whole thread, what I'm asking is

is there a correct place for the zeros to be?

If they are in the correct place is this something accuraterip checks or would any sample with the abcdefghijklmnop no matter where the zeros were show up as accurate?

 

 

thanks, John

 

.SJB

The zeros can be anywhere, it should be extracted from the CD track and perhaps indicate lead in pure silence before a track starts. To my mind these zeros before and after should be consistent on all rips and if different I would have though accuratrip would flag it up... This is likely to be software related with the ripper/cd driver and I expect such differences to disappear with software updates etc.

Don Atkinson posted:

In a piece of music, which lasts (say) for 5 minutes (300 seconds), does your sample above,

represent the entire 300 seconds, in which case File Y starts playing music a little bit sooner than File X, but otherwise there is no difference, or

represent the first "note", (let's assume this is 1 second long) in which case there are a further 299 [ ]s. If so,

are there always the same number of 0000's in File X and File Y between the end of one note at bit "p", and the start of the next note at bit "a".

Presumably the number of 0000's can vary between notes as defined by the music and is not always 19 "zeros" long.

In the WAV rip examples I measured there appeared to a lead in and lead out in the track with zero samples. The number of the lead in and lout out samples differed between the two rips but the overall number of samples was consistent and the lengths remained at consistent - in your example 300 seconds on both rips

So with one rip with lead in and lead out - one would play in terms of music sample material ever so slightly before the other if played back .. the numbers shown are purely illustrative - when I measured the rips there was actually 240 decimal sample offset (i.e. number of lead in and lead out zero samples) between the two rips. I do think a track that is a continuous track - i.e. there is no silence at the start or end could be slightly problematic here.

As I said above this is I suspect an error that will be fixed with a software update.

Simon

Okay, but what does this tell us about the differences in sound quality?

Simon-in-Suffolk posted:

Sloop John B posted:

Simon-in-Suffolk posted:

Hi I can't answer the top two questions - as these were test files and I hadn't ripped them - but the last query is that it is entirely down to the ripping process

I wasn't referring to the rips mentioned here as I missed that whole thread, what I'm asking is

is there a correct place for the zeros to be?

If they are in the correct place is this something accuraterip checks or would any sample with the abcdefghijklmnop no matter where the zeros were show up as accurate?

 

 

thanks, John

 

.SJB

...

To my mind these zeros before and after should be consistent on all rips and if different I would have though accuratrip would flag it up...

...

I am not sure that the offsets should be identical on rips on different drives, please see

 "Under certain conditions the tested drives and tools deliver 100% identical results. From that perspective there    shouldn't be any difference on SQ. If you'd don't use Accurate Rip drive-offsets, every rip will be different on every drive. And that might be an issue."

and

"...all CD Ripping programs, all brands of DVD and CD drive will rip bit perfect (drive offset accounted for, BTW the offset is not audible past the first micro-seconds of a track) on the majority (over 95%) of undamaged discs. The differences in CD ripping software: ability to detect errors, potentially correct errors (by re-reading) and eventually report errors if they cannot be corrected."

from http://thewelltemperedcomputer.com/KB/Ripping.htm. But it would be nice if it was so, of course. If we assume that bit perfect rips have to be identical, then the results of Jan-Erik seem to show that either the US rips or the Core rips or both are not bit perfect.

Klout10 posted:

Okay, but what does this tell us about the differences in sound quality?

While this question is what in the end matters, I'm afraid that it can be meaningfully discussed only after it has been understood what it means for the results of ripping an album on two different devices to be equivalent and after it has been established whether the results of ripping on the Core and on the US are equivalent or not.

NBPF, previous checks a few years back between Unitiserve, dbpoweramp and EAC have shown identical offsets... 

Simon-in-Suffolk posted:

NBPF, previous checks a few years back between Unitiserve, dbpoweramp and EAC have shown identical offsets... 

I see, thanks for the information. This suggests that, assuming that the rips of UnitiServe, dbpoweramp and EAC are identical and bit perfect, the Core rips are not bit perfect or that bit perfect rips are not unique. Do we have a precise notion of bit perfectness or is this just a marketing buzzword? Best, nbpf

That I don't know.. all I tried to evaluate was what the differences if any between Jan's two different rip files were. Other than stating the observed differences, I guess anything else should come from Naim.

nbpf posted:

Richard, I very much doubt that Jan-Erik has technically distributed anything. My understanding is that, in the specific case, Dropbox could have been forced to take down certain files but not Naim to close a thread.  

I've not read this thread through but it was I who reported the original (no longer being a moderator).

Years ago we had a forum member who circulated a 'Sampler' CD with, among others, a Naim track on it. A lot of spurious reasons were put forward by him to be an exception and, to be fair, he seemed more obsessed with counting 'tings'  than the music itself.

I'd not previously read the words that appear in the 'Report this Post' box but they turn out to be remarkably relevant to this case.

It would seem forum hosts avoid hosting links to breaches of copyright. Naim would not wish it and other forums that you may visit have asked members to avoid similar (needle drops) as Google AdSense accounts can be disabled if such infringements are found.

Inconvenient here but good to see that some measures are in place to at least try to preserve something for artists.

Cue - long, tedious justifications of theft - not germane to this situation where the offence was innocent and rectified. Unlike the petabytes of music some claim to 'own'.

from http://www.head-fi.org/t/53214...erfect-cd-ripping/45.

Nbpf, are you not addressing something different? That is the mapping of a file to CD-R and then ripping that CD-R... as opposed to consistently comparing rips from that CD-R?

As far as copyright issue, this should be irrelevant to the task in hand.. copyright free media should be used, or otherwise I have some of my own material where I own the copyright which I am quite happy to be used for this task and this task alone if required by forum participants wanting to explore ripping differences.

Simon

Jan-Erik Nordoen posted:

jon honeyball posted:

oh and naim could do the rips and provide them to beta testers if they think it is significant etc etc etc

I think we can put the rip issue to bed:

• Four out of six listeners tend to prefer rip B over A, and two listeners can pick out B as preferable over A in a blind test;
• A technical difference is found between the rips, that could explain what we're hearing;
• A FW update (that will presumably fix the issue) seems imminent.

Jan, do we know which CD drive is used in the Core? If so, is it listed in http://www.accuraterip.com/driveoffsets.htm? My guess at this point is that the ripping software in the Core is simply using a wrong drive offset. It's just a guess, of course! Best, nbpf

I think it might be drive offset.. the 240 offset samples I measured equals 2.72mS offset using stereo samples. I don't think this will be noticeable other than possibly continuous playback of sequential rips where there could be a minor glitch or 'tick' sound - but without more copyright free material providing this as an example I can't verify.

Simon-in-Suffolk posted:

Nbpf, are you not addressing something different? That is the mapping of a file to CD-R and then ripping that CD-R... as opposed to consistently comparing rips from that CD-R?

As far as copyright issue, this should be irrelevant to the task in hand.. copyright free media should be used, or otherwise I have some of my own material where I own the copyright which I am quite happy to be used for this task and this task alone if required by forum participants wanting to explore ripping differences.

Simon

You are right, the picture is perhaps a bit confusing. But assuming that burning to CD is bit perfect and replacing "my computer" with Jan's pair of devices -- the Core and the US -- yields Jan's problem.

I would be happy to contribute finding an explanation for the results reported by Jan. I do not have a US or a Core and I am not very good at making sound quality comparisons. But I can compare files and read log files.

There seem to be a strong expectation that ripping on the US and on the Core should yield cmp identical files. I am quite sure that US and Core users also do expect their devices to produce the same results when ripping the same data at different times.

The empirical evidence shows that the first expectation is not fulfilled. What about the second one? Would it be possible for Core owners to rip the same album two or three times and check whether the results are the same? This is a crucial corner case: if the results turn out to be different, any discussion about the differences between the US samples and the Core samples is immaterial.

Another question is whether Core users have access to ripping logs. I would expect the ripping software on the Core to rely on established tools like cdparanoia and rubyripper. These tools can write very useful logs. The logs allow a deeper understanding of the rip process and contain valuable information, for instance, of the drive offset value.

Best, nbpf

Simon-in-Suffolk posted:

I think it might be drive offset.. the 240 offset samples I measured equals 2.72mS offset using stereo samples. I don't think this will be noticeable other than possibly continuous playback of sequential rips where there could be a minor glitch or 'tick' sound - but without more copyright free material providing this as an example I can't verify.

 

It should be possible to identify the Core's CD drive from https://andreweverarddotcom.fi...re_inside1.jpg?w=640 and check whether 240 is the right value for the drive. I'm travelling and I do not have my magnifying glass with me right now ...

It looks like it's a TEAC CD-SN250 which unfortunately is not listed in the accuraterip offset database:

http://www.accuraterip.com/driveoffsets.htm