unitserve rips vs core rips

Ah right yeah, I skimmed a bit and saw a contretemps about the previous thread, so skipped a bit.

Have to say, the investigation has thus far left me even more skeptical about there being any objective differences in SQ, despite the perceived differences that kicked it all off. It'll definitely be interesting if any explanation which supports a difference in SQ emerges.

Dave***t posted:

Is there a way of editing the offset manually within a ripped (copyright free) file?

...

Yes, I did that for sample 02, please see my post above. After you have deleted enough zeroes in the B sample to have the first significant non-zero character of the B sample at the same position of the first significant non-zero character of the A sample, the files are cmp identical until EOF of the trimmed B sample. This is now a little bit shorter than the original A sample which has some more trailing zeroes. If you convert the original A sample and the trimmed B sample to .flac and run "metaflac --show-max-framesize", you should now obtain the same result: 12363.  By contrast, the max-framesize value of the original B sample was 12376 because of the extra zeroes in the first record. There should be no difference in the sound quality of the A sample and of the trimmed B sample. You should be able to trim the file with any decent text editor (but beware, the file is large!). I used emacs. Best, nbpf

Dave***t posted:

...

Just thinking that if the offset might be doing something weird, then it should be possible to do the listening test again with equalised offsets to confirm/disconfirm other reasons for any differences.

I do not think that the offset should have an impact on the sound quality. It is in principle conceivable for a player to behave differently upon reading first records of different length, but that would be really weird and anyway player-specific. I myself could not hear any differences between the original samples A and B but that might be due to my hearing, to my system, etc.

Putting system/data block possible coupling issues to one side - they only material sound difference such an offset could cause is potentially with gapless rips and playback - where a tiny part of the track containing musical samples would be potentially truncated.. and indeed if the observations made are caused by offset errors I have indeed previously seen and measured this affect.

So if a device is said to support gapless playback, does that mean that all it does is ignore the 0s at both ends of the track? If so, it seems unlikely to me that the small amount of work involved would affect the sound.

The zeros  were part of the track - it would have been put in at mastering time as the lead in to the music and the lead out. With gapless there is no lead in and is instant music so there will effectively be no zeros.

Back to basics a bit....so when ripper software detects the specific hardware you're using to rip, that is somehow used to determine or correct for "offset" I've read.  Is that relevant to this discussion?

Simon-in-Suffolk posted:

Putting system/data block possible coupling issues to one side - they only material sound difference such an offset could cause is potentially with gapless rips and playback - where a tiny part of the track containing musical samples would be potentially truncated.. and indeed if the observations made are caused by offset errors I have indeed previously seen and measured this affect.

That sounds very plausible. Still, if the US and the Core are not designed to produce identical ripping results (modulo metadata, of course), I would expect Naim to provide reference samples of the expected outcomes of ripping a few reference albums or tracks with the two devices. This would establish a minimum of transparency and give owners a straightforward way to check that their devices operate according to their respective specifications.   

Bart posted:

Back to basics a bit....so when ripper software detects the specific hardware you're using to rip, that is somehow used to determine or correct for "offset" I've read.  Is that relevant to this discussion?

I think so. Therefore my original conjecture that the Core might produce different rips from the US because of a wrong drive offset setting in the Core's ripping software. This seems a plausible conjecture given the metrics provided by SiS, the fact that the Core's CD drive is not listed on http://www.accuraterip.com/driveoffsets.htm and the fact that, modulo leading and trailing zeroes, the US and the Core rips are identical.

ChrisSU posted:

So if a device is said to support gapless playback, does that mean that all it does is ignore the 0s at both ends of the track? If so, it seems unlikely to me that the small amount of work involved would affect the sound.

I think that, technically, support for gapless playback might imply a little bit more than the capability of skipping certain blocks of zero. Still, I think that your interpretation is "morally" correct. At the same time, I am not sure that the work needed to skip the right amount of zeroes is necessarily negligible. Ripping software does not need to account for real-time constraints. But replay software does. Thus, when we consider tasks to be accomplished at replay time, we have to put them in the contest of the time that is actually available for accomplishing that task. I have too little understanding of the problems of gapless playback be able to judge how challenging is actually the task of skipping the right amount of zeroes at playback time, I'm afraid.

nbpf posted:

Simon-in-Suffolk posted:

Putting system/data block possible coupling issues to one side - they only material sound difference such an offset could cause is potentially with gapless rips and playback - where a tiny part of the track containing musical samples would be potentially truncated.. and indeed if the observations made are caused by offset errors I have indeed previously seen and measured this affect.

That sounds very plausible. Still, if the US and the Core are not designed to produce identical ripping results (modulo metadata, of course), I would expect Naim to provide reference samples of the expected outcomes of ripping a few reference albums or tracks with the two devices. This would establish a minimum of transparency and give owners a straightforward way to check that their devices operate according to their respective specifications.   

I'd expect US/HDX and Core to produce the same files in WAV format though. And I'd expect this to have been checked as part of R&D.

When I browsed through the original thread (the one that was withdrawn following Adam's intervention) and the start of this thread, I thought I was reading about significant corruption of data that was driving the musical content of a CD that had been ripped.

I assumed that the ripped copy on a Unitiserve and/or a Core was considered to be significantly different to the original and different to each other. The research seemed to be aimed at identifying the extent of data corruption (courtesy of Simon-in-Suffolk) and "Blind" listening tests of the music by a statistically sufficient number of listeners to determine what if any, differences could be heard.

Data analysis and listening results would then be correlated and some sort of conclusion reached about how this affected the sound quality on playback.

It now appears that the musical data is not corrupted. The only corruption is the loss of a teeny, weeny, little bit of music when trying to get music to playback without any gaps in between separate songs.

Or am I completely mis-understanding this thread ?

Don Atkinson posted:

It now appears that the musical data is not corrupted. The only corruption is the loss of a teeny, weeny, little bit of music when trying to get music to playback without any gaps in between separate songs.

It's not even that - the only missing data was some zeros at the start of the track, with the same number of extra zeros added at the end. The actual musical data was identical.

i hope you will now test the streaming corner of this topic: compare us/core in ethernet mode.

Perhaps your findings related to sound quality will be reversed. I hope no, because i bought a unitserve 6 months ago. But the unitserve don't take dsd and it software is 7 years old. So if the core is better, i doubt it, i will sold my unitserve.

Keler Pierre posted:

i hope you will now test the streaming corner of this topic: compare us/core in ethernet mode.

Perhaps your findings related to sound quality will be reversed. I hope no, because i bought a unitserve 6 months ago. But the unitserve don't take dsd and it software is 7 years old. So if the core is better, i doubt it, i will sold my unitserve.

The discussion in this thread, and the previous closed one, is about one person's specific findings regarding the ripping abilities of the two devices. I doubt this is going to have much bearing on the overall sound quality of the two units (although Jan-Erik mat disagree!)  

Don Atkinson posted:

It now appears that the musical data is not corrupted. The only corruption is the loss of a teeny, weeny, little bit of music when trying to get music to playback without any gaps in between separate songs.

Or am I completely mis-understanding this thread ?

No - that about sums it up in my book other than I might call a truncation or a glitch sound at the start of a musical track that wasn't silent a small data corruption or alternatively it is (slightly) not bit perfect to the original - BUT on gapless playback you MAY get small glitches between tracks which might become more annoying - it would certainly annoy me - but a slight glitch between gapless tracks such as on The Wall is not the greatest challenge that affects mankind right now...

jon honeyball posted:

nbpf posted:

Simon-in-Suffolk posted:

Putting system/data block possible coupling issues to one side - they only material sound difference such an offset could cause is potentially with gapless rips and playback - where a tiny part of the track containing musical samples would be potentially truncated.. and indeed if the observations made are caused by offset errors I have indeed previously seen and measured this affect.

That sounds very plausible. Still, if the US and the Core are not designed to produce identical ripping results (modulo metadata, of course), I would expect Naim to provide reference samples of the expected outcomes of ripping a few reference albums or tracks with the two devices. This would establish a minimum of transparency and give owners a straightforward way to check that their devices operate according to their respective specifications.   

I'd expect US/HDX and Core to produce the same files in WAV format though. And I'd expect this to have been checked as part of R&D.

But, as a matter of fact, the US and the Core tested by Jan-Erik produce different .WAV files for which we meanwhile know that the differences are limited to the amount of leading and trailing zeroes. Perhaps this is the expected behavior, perhaps not. In either case, I think that it is time for Naim to come up with a clear statement. Best, nbpf 

For people who listen to opera, perfect gapless playback is  essential and any kind of glitch unacceptable. A typical opera will be over 100 tracks, but these tracks are really only to aid navigation, the work itself will be in two or three acts an hour or so long. Some "tracks" might only be 20 seconds long, any kind of glitch would dement even the most patient person. I know this because in the early days of streaming I used PlugPlayer which couldn't do gapless playback and glitched between each track. Utterly hopeless.

nbpf posted:

But, as a matter of fact, the US and the Core tested by Jan-Erik produce different .WAV files for which we meanwhile know that the differences are limited to the amount of leading and trailing zeroes. Perhaps this is the expected behavior, perhaps not. In either case, I think that it is time for Naim to come up with a clear statement. Best, nbpf 

I seriously doubt truncated WAV files is expected behaviour even if its just over 2mS of truncation. Remember the so called 'zeros' I measured were part of the track itself from the master...

I honestly think this will be fixed by a software update - its just those with the Core might want to hold off doing mass rips until the issue is resolved or at least clarified by Naim.

S

nbpf posted:

jon honeyball posted:

nbpf posted:

Simon-in-Suffolk posted:

Putting system/data block possible coupling issues to one side - they only material sound difference such an offset could cause is potentially with gapless rips and playback - where a tiny part of the track containing musical samples would be potentially truncated.. and indeed if the observations made are caused by offset errors I have indeed previously seen and measured this affect.

That sounds very plausible. Still, if the US and the Core are not designed to produce identical ripping results (modulo metadata, of course), I would expect Naim to provide reference samples of the expected outcomes of ripping a few reference albums or tracks with the two devices. This would establish a minimum of transparency and give owners a straightforward way to check that their devices operate according to their respective specifications.   

I'd expect US/HDX and Core to produce the same files in WAV format though. And I'd expect this to have been checked as part of R&D.

But, as a matter of fact, the US and the Core tested by Jan-Erik produce different .WAV files for which we meanwhile know that the differences are limited to the amount of leading and trailing zeroes. Perhaps this is the expected behavior, perhaps not. In either case, I think that it is time for Naim to come up with a clear statement. Best, nbpf 

As a side note: sample A came with .wav extention, sample B came with .WAV extention. Difference? UnitiServe produces .WAV (with capital letters). 

ChrisSU posted:

Keler Pierre posted:

i hope you will now test the streaming corner of this topic: compare us/core in ethernet mode.

Perhaps your findings related to sound quality will be reversed. I hope no, because i bought a unitserve 6 months ago. But the unitserve don't take dsd and it software is 7 years old. So if the core is better, i doubt it, i will sold my unitserve.

The discussion in this thread, and the previous closed one, is about one person's specific findings regarding the ripping abilities of the two devices. I doubt this is going to have much bearing on the overall sound quality of the two units (although Jan-Erik mat disagree!)  

I do not understand your point, I'm afraid: How can you conceive that findings regarding the ripping capability of the US and of the Core (no matter whether these findings come from Jan-Erik or from anyone else) could have any bearing on the sound quality of the two devices? I am confused ...

Adam Zielinski posted:

As a side note: sample A came with .wav extention, sample B came with .WAV extention. Difference? UnitiServe produces .WAV (with capital letters). 

Let the "Does .WAV Sound Better Than .wav" debacle begin!

nbpf posted:

ChrisSU posted:

Keler Pierre posted:

i hope you will now test the streaming corner of this topic: compare us/core in ethernet mode.

Perhaps your findings related to sound quality will be reversed. I hope no, because i bought a unitserve 6 months ago. But the unitserve don't take dsd and it software is 7 years old. So if the core is better, i doubt it, i will sold my unitserve.

The discussion in this thread, and the previous closed one, is about one person's specific findings regarding the ripping abilities of the two devices. I doubt this is going to have much bearing on the overall sound quality of the two units (although Jan-Erik mat disagree!)  

I do not understand your point, I'm afraid: How can you conceive that findings regarding the ripping capability of the US and of the Core (no matter whether these findings come from Jan-Erik or from anyone else) could have any bearing on the sound quality of the two devices? I am confused ...

 

   

I'm looking forward to comparing SQ on playback of a rip made by the Core with  a rip of the same disc made by the US, in both cases streamed by the Core. The potential for endless forum threads about nothing of any consequence is clear.

best

David

Adam Zielinski posted:

nbpf posted:

jon honeyball posted:

nbpf posted:

Simon-in-Suffolk posted:

Putting system/data block possible coupling issues to one side - they only material sound difference such an offset could cause is potentially with gapless rips and playback - where a tiny part of the track containing musical samples would be potentially truncated.. and indeed if the observations made are caused by offset errors I have indeed previously seen and measured this affect.

That sounds very plausible. Still, if the US and the Core are not designed to produce identical ripping results (modulo metadata, of course), I would expect Naim to provide reference samples of the expected outcomes of ripping a few reference albums or tracks with the two devices. This would establish a minimum of transparency and give owners a straightforward way to check that their devices operate according to their respective specifications.   

I'd expect US/HDX and Core to produce the same files in WAV format though. And I'd expect this to have been checked as part of R&D.

But, as a matter of fact, the US and the Core tested by Jan-Erik produce different .WAV files for which we meanwhile know that the differences are limited to the amount of leading and trailing zeroes. Perhaps this is the expected behavior, perhaps not. In either case, I think that it is time for Naim to come up with a clear statement. Best, nbpf 

As a side note: sample A came with .wav extention, sample B came with .WAV extention. Difference? UnitiServe produces .WAV (with capital letters). 

The first thing that came to my mind when I saw the files was: .WAV files come from Windows and .wav files come from Unix! Then I thought that Jan-Erik might have mixed-up things a little bit on purpose. I do not know. Perhaps it would have been better to use the same file extension.

No matter: it seems to me that what we know so far is more or less what I have reported above. This is valuable but far too little: we do not even know whether different Cores produce the same results. Or, indeed, whether the same Core produces the same results for different rips of the same album. I would expect this to be the case but, so far, we do not have any empirical evidence that this is the case. And, frankly, I am not even sure that my expectations are reasonable: if the amounts of zeroes depends (among others) on the CD drive offset and if the ripping software attempts at finding a new offset at every rip, expecting consistency of rips throughout devices and time would be perhaps too much.

i'll say again  the zeroes in the files I analysed are part of the track - nothing less - i.e. they are  part of the PCM file .. period.. the PCM file should be same however they are extracted. The idea that an OS can acceptably truncate a PCM file is none sensical.