unitserve rips vs core rips

David Hendon posted:

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

But if US and Core rips were identical modulo metadata (which seems to be what most contributors to this thread expect that should be the case if the two devices work according to specifications) than there would be no point in comparing the two rips, right? You would compare things that you know to be identical.

Thus, it seems that your test would only make sense under the assumption that either the Core or the US (or, in fact, both) do not operate according to specifications (again, according to what most contributors seem to expect). But then you would be comparing results of misbehavious which you should expect Naim would try to eliminate.

Simon-in-Suffolk posted:

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.

In this case there is a problem either with the Core, with the US or with both devices, I would say. If we assume that Jan's US rips according to specifications, then there is a problem with his Core. Perhaps Naim could confirm or confute this argument? Best, nbpf

I read it all but This is far too needy for me 

So is the core a lemon? Or What? 

nbpf posted:

David Hendon posted:

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

But if US and Core rips were identical modulo metadata (which seems to be what most contributors to this thread expect that should be the case if the two devices work according to specifications) than there would be no point in comparing the two rips, right? You would compare things that you know to be identical.

Thus, it seems that your test would only make sense under the assumption that either the Core or the US (or, in fact, both) do not operate according to specifications (again, according to what most contributors seem to expect). But then you would be comparing results of misbehavious which you should expect Naim would try to eliminate.

I'm trying to be ironic again.....

Please refrain from all the quoting.  You are only hogging bandwidth! 

David Hendon posted:

nbpf posted:

David Hendon posted:

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.

...

The discussion in this thread, and the previous closed one, is about one person's specific findings ...

I do not understand your ...

I'm looking forward to comparing SQ on ...

...

I'm trying to be ironic again.....

I'll probably have to give up here: italian origin plus 20 years of german habits are perhaps less than ideal pre-conditions for grasping english humor. No matter: if the PCM files of the Core and of the US shall be identical, than the situation seems to be pretty clear to me: Naim will have to fix a likely minor ripping issue in the Core ripping software and, until this has been done, assessments of the sound quality of the Core and comparison with the sound quality of the US should be meaningully done on the basis of US rips, not of Core rips. Is this an acceptable temporary conclusion?

There is some empirical evidence to suggest that two identical files ripped using different methods can sound different. I do not understand the reasons, and conceptually there is no reason why they should. However I do not discount the empirical evidence. I treat it as an as yet unexplained phenomenon. 

It's difficult to partially quote if you are on an iPhone and if there are a couple of conversations going on, some quoting is necessary. But I agree that it is all very untidy and wasteful of storage space (but I doubt the bandwidth demand is significant.

best

David

Oh my, what have I started 

Yesterday, I received a Seagate 2TB HDD for the Core. Installation was a snap. After rebooting (also snappy), the Core formatted the drive and ripping began. I then copied several UnitiServe rips onto the 'Downloads' partition of the Seagate drive for some A/B comparisons. As the Naim app does not identify where a file is playing from (which nServe app does), I replaced the cover image of all the UnitiServe rips by a photo of the Serve, to know which was which (after listening).

Using the Core, I then made a playlist of three albums (ripped once by the Core and once by the Serve), and set playback to random, with the phone turned over so that I could not see which was playing. After a brief listen to a track , I noted my choice and turned the phone over to see if I'd guessed correctly.

In five trials of 10 random tracks I guessed correctly in 5, 6, 5, 5, 5 instances, so no better than average (mean correct guesses 5.2). From these trials, it was clear that I could not distinguish rips from the Core and Serve, on short listens of random tracks from six albums (three albums ripped twice). But could I do better focusing on fewer tracks?

I ran a random trial using two tracks from Leonard Cohen's Darker album. In this trial, I guessed correctly 8 times out of 10. Not bad. I'll run this trial again a few more times to check repeatability, once the Naim app stops acting up (refuses to respond to the 'advance track' button). Perhaps it's a message...

My conclusion so far is that the audible differences between the rips are very, very slight and easy to miss. 

Oh, and the Core is definitely not a lemon. 

Jan

Jan-Erik Nordoen posted:

 As the Naim app does not identify where a file is playing from (which nServe app does), I replaced the cover image of all the UnitiServe rips by a photo of the Serve, to know which was which (after listening). 

That's cheating, they are bound to sound better with the improved artwork you've given them! 

Jan-Erik Nordoen posted:

...

My conclusion so far is that the audible differences between the rips are very, very slight and easy to miss. 

Still, there should be no whatsoever differences between US rips and Core rips right? Thus, no matter how small the audible differences actually are (have you checked gapless playback?) I would expect Naim to fix the issue. Or, alternatively, to come up with a convincing explanation of why they would not want to fix the issue. Best, nbpf

Move along, nothing to see here........

SJB

Jan-Erik Nordoen posted:

Oh my, what have I started 

Yesterday, I received a Seagate 2TB HDD for the Core. Installation was a snap. After rebooting (also snappy), the Core formatted the drive and ripping began. I then copied several UnitiServe rips onto the 'Downloads' partition of the Seagate drive for some A/B comparisons. As the Naim app does not identify where a file is playing from (which nServe app does), I replaced the cover image of all the UnitiServe rips by a photo of the Serve, to know which was which (after listening).

Using the Core, I then made a playlist of three albums (ripped once by the Core and once by the Serve), and set playback to random, with the phone turned over so that I could not see which was playing. After a brief listen to a track , I noted my choice and turned the phone over to see if I'd guessed correctly.

In five trials of 10 random tracks I guessed correctly in 5, 6, 5, 5, 5 instances, so no better than average (mean correct guesses 5.2). From these trials, it was clear that I could not distinguish rips from the Core and Serve, on short listens of random tracks from six albums (three albums ripped twice). But could I do better focusing on fewer tracks?

I ran a random trial using two tracks from Leonard Cohen's Darker album. In this trial, I guessed correctly 8 times out of 10. Not bad. I'll run this trial again a few more times to check repeatability, once the Naim app stops acting up (refuses to respond to the 'advance track' button). Perhaps it's a message...

My conclusion so far is that the audible differences between the rips are very, very slight and easy to miss. 

Oh, and the Core is definitely not a lemon. 

Jan

 

 

so, if i have understood correctly, rips from core and us sound quiet similar ?  but it does not prove that core and us sound the same, because you have not yet tested the differences in a systemic point of view of this two servers.( core/ndac vs us/ndac  and core/ naim streamer vs  us/naim streamer). ?

Keler Pierre posted:

Jan-Erik Nordoen posted:

 

so, if i have understood correctly, rips from core and us sound quiet similar ?  but it does not prove that core and us sound the same, because you have not yet tested the differences in a systemic point of view of this two servers.( core/ndac vs us/ndac  and core/ naim streamer vs  us/naim streamer). ?

Piotrek - you have COMPLETELY misunderstood the test.

The test was how Core and UnitiServe rip CDs not how how they sound via their digital outputs. It's the ripping quality was a subject of the debate.

Sloop John B posted:

Move along, nothing to see here........

SJB

Right, the problem is now well understood and hopefully it will not take too long for Naim to solve it. It was a very interesting thread and I have learned a lot about .wav files and file comparisons.

nbpf posted:

Sloop John B posted:

Move along, nothing to see here........

SJB

Right, the problem is now well understood and hopefully it will not take too long for Naim to solve it. It was a very interesting thread and I have learned a lot about .wav files and file comparisons.

Errr....... not by me.

I am now unclear again as to whether 0000abcdefghijklmnop000000000000000 represents a "chunk" of music that lasts for (say) 5 minutes (300 secs) or a "chunk" of music that lasts for a fraction of a second. I think that I understand the 0000's represent "silence" and the abcdef.... represents "music"

Does it represent 5 minutes, and the first 0000's represent the "run-in" to a track or the next movement of a symphony, and the trailing 0000's represent the "run-out" ? or

Does it represent (say) 1/100th of a second, and the 0000's control the "timing" at which the next "chunk" of music it rendered ? or

Does it represent something else ?

As I said before, this is not a criticism of Simon, just a lack of understanding on my part......and might I respectfully suggest, a lack of understanding by one or two others on this forum ?

Don, the 0000abc0000 illustration Simon used represents a single track from a ripped album.

It's a vanishingly small difference in the length of silence before the music starts. Like putting the stylus into not quite the same point on the silent run in groove on an LP. The point is that the rips should be identical and they aren't quite, but it says nothing about SQ and in practical terms nothing about gapless playing either.

best

David

Don Atkinson posted:

I am now unclear again as to whether 0000abcdefghijklmnop000000000000000 represents a "chunk" of music that lasts for (say) 5 minutes (300 secs) or a "chunk" of music that lasts for a fraction of a second. I think that I understand the 0000's represent "silence" and the abcdef.... represents "music"

Does it represent 5 minutes, and the first 0000's represent the "run-in" to a track or the next movement of a symphony, and the trailing 0000's represent the "run-out" ? or

 

the run in and run out would be  added to the track by the mastering engineer. This is part of the silence we hear between consecutive tracks on streaming playback of an album  - or like in some albums where it is gapless - there is no silence and the sound is continuous. 

So if the track is quoted at 5 minutes - that will typically include the lead in and lead out - which may only be a couple of tenths of seconds.

I am hoping to be able  to analyse gapless files to see what happens with the offset there - where I would expect actual non zero samples to be lost- albeit just over 2mS worth which might be hard to hear other than a slight 'tick' sound.

The term chunk is simply the term used in RIFF files (wav, aiff etc) to define a self contained part of the file  - and in wav files, all the pcm samples, whether they be silence or loudness,  are put into a single 'chunk' as a single block of sequential sample data. It was this sample block I analysed - and i tried to simplify using the

[0000abcdefghijklmnop000000000000000]

illustration....

I would expect a gapless sample chunk in a wav file to appear as

[abcdefghijklmnop]

Don Atkinson posted:

nbpf posted:

Sloop John B posted:

Move along, nothing to see here........

SJB

Right, the problem is now well understood and hopefully it will not take too long for Naim to solve it. It was a very interesting thread and I have learned a lot about .wav files and file comparisons.

Errr....... not by me.

I am now unclear again as to whether 0000abcdefghijklmnop000000000000000 represents a "chunk" of music that lasts for (say) 5 minutes (300 secs) or a "chunk" of music that lasts for a fraction of a second. I think that I understand the 0000's represent "silence" and the abcdef.... represents "music"

Does it represent 5 minutes, and the first 0000's represent the "run-in" to a track or the next movement of a symphony, and the trailing 0000's represent the "run-out" ? or

Does it represent (say) 1/100th of a second, and the 0000's control the "timing" at which the next "chunk" of music it rendered ? or ...

In Simon's sketch,

  0000abcdefghijklmnop000000000000000

represents a whole A .wav file and

  0000000abcdefghijklmnop000000000000

a whole corresponding B .WAV file. It is of course an idealized representation because, in fact, both files start with a short non-zero header which is identical in both files.

The important observation here is that the sections of the two files that code the musical content, represented by "abcdefghijklmnop" in the sketch, are identical. It goes without saying that "abcdefghijklmnop"  might contain intervals of silence which, in turn, are perhaps coded by zeroes or perhaps by other values.

I do not know what could be the impact of the differences in the sizes of the sections before and after the relevant "abcdefghijklmnop" section on the sound quality or on gapless playback capabilities and, frankly, I do not care.

For me, the important point is that we have understood 1) that the two samples are different and 2) in which sense they are different.

You can easily verify by yourself that the samples are different in the sense explained above by opening the files in a text editor.

From my point of view, the only open question which is left is whether we should expect the US and Core samples to be identical tout court or only to be identical in their relevant sections.

On this point (and in absence of any clarification from Naim and following Simon's arguments and experience and empirical evidence from previous tests) it seems to me very reasonable to assume that the samples should be identical tout court and that therefore, as stated above, there is an issue with the Core ripping software, with the US rippin software or with the ripping software of both devices.

(Edit: Simon was faster in answering your question, sorry for the noise)

But abcdefghijklmnop would be massively longer in a real wav music file  of course. So one or two zeros at the beginning is very short, less than a millisecond.

best

David

If it helps to be able to see the full track in all its digital glory, view it in something like Hex Fiend, which is a little free app which you can use to open a file. Open a .wav file using this, and you will see lots of zeros if there is a lead in (in this case, 53000 or so) followed by lots of bytes of music, then some more zeros. You will also see that Simon's 000abc000 is quite a good representation of what is happening, but saves an awful lot of scrolling down. (You will need to open an uncompressed track to see this, I think a FLAC would look completely different.)

David Hendon posted:

But abcdefghijklmnop would be massively longer in a real wav music file  of course. So one or two zeros at the beginning is very short, less than a millisecond.

best

David

Agree. But whitespace can carry information. Thus, for instance, if gapless playback relied on skipping certain fixed amounts of "zeroes", extra amounts could cause troubles, in principle. As I wrote, I'm completely ignorant on this subject and all I can do is to rely on the opinions of those who know more and/or have more experience in this area. Of course, everything would be easier if Naim would provide some clarification and clear specifications for their devices.

David Hendon posted:

But abcdefghijklmnop would be massively longer in a real wav music file  of course. So one or two zeros at the beginning is very short, less than a millisecond.

best

David

Dave in the rips I measured it was 240 samples offset difference or missing from the start  - which equates to approx 2.7mS - still very short in time - but the task was confirm whether the ripped PCM wav files were bit perfect with each other - and they were not.

S

Simon

Yes I understand. Prompted by Don's question earlier today I was trying to explain to non-technical readers that this whole discussion isn't something that should worry them too much. But I agree that the fact there is a difference needs explaining and we don't actually know yet that the ripping doesn't lose leading non-zero samples.

best

David