unitserve rips vs core rips

Hi, the odd error in that amount of data is probably statistically appropriate, but what will a sound like? A single tick or minuscule  silence one every 100 GBytes or so?

Simon

Hungryhalibut posted:

Jan-Erik Nordoen posted:

I thought music was supposed to be fun...

Jan

It is. Might I suggest that it is this comparison exercise that is preventing it being so? Perhaps I'm a bit simple, but I'm quite happy to rip with dbpoweramp and put the files on a nas. Listening to them now, they sound bloody good. There are so many variables in reproduction, from equipment to leads to switches and to the room itself, that any microscopic ripping differences surely pale into insignificance? 

Hi Nigel,

Well, the problem for me is that the microscopic ripping differences are making all the difference between music that moves me and music that doesn't. I got hooked on Naim 35 years ago and despite my best efforts to explore other brands, Naim creep has exerted its insidious effect and I'm now up to four Naim systems. Why? Because, as a good friend puts it 'Naim is audio marijuana'.

When Naim comes out with something new, I push my way to the front of the line to get a sample for review and I've only been disappointed once. That was the 272, where I felt that Naim had dialed back the DNA of the DAC section (my reference being the nDAC). I approached the Core review expecting that I would encounter something at least as good as the UnitiServe. After all, the Core is an updated Serve, but with fewer functions. So it is only reasonable to expect that its core (sorry) functions would be augmented compared to its predecessor. 

I had not intended to compare rips, but the lack of an internal drive lead to that outcome. When I listen to the rips, I feel that once again, Naim have dialed back their DNA. That I cannot fathom. It has to be a software issue. I hope.

Jan

Simon-in-Suffolk posted:

nbpf posted:

Hungryhalibut posted:

Jan-Erik Nordoen posted:

I thought music was supposed to be fun...

Jan

It is. Might I suggest that it is this comparison exercise that is preventing it being so? Perhaps I'm a bit simple, but I'm quite happy to rip with dbpoweramp and put the files on a nas. Listening to them now, they sound bloody good. There are so many variables in reproduction, from equipment to leads to switches and to the room itself, that any microscopic ripping differences surely pale into insignificance? 

Perhaps. Still, I find it a bit worring when two systems which are allegedly "bit perfect" deliver truly different files that sound quite differently to some of us. Best, nbpf

They didn't measure bit perfect at all.. I have posted the differences twice now, but Richard asked that such differences are removed for the time being... it's Naim's shout... I have the details between the two rips of the same source  should anyone be interested..

Thanks Simon! I have your posts in mind and I have sent to Jan-Erik the results of my listening tests. I have the impression that Naim is over reacting on this issue but let's wait and see. Hopefully we'll get the thread back online next Monday. Best, nbpf

Simon-in-Suffolk posted:

Hi, the odd error in that amount of data is probably statistically appropriate, but what will a sound like? A single tick or minuscule  silence one every 100 GBytes or so?

Simon

In the specific case the impact was severe: a very noticeable stuttering every 5 seconds or so. Quite unenjoyable. Re-running rsync with the --checksum option immediately solved the problem. I have the impression tha the errors tend to occur more frequently when one is editing small bits of metadata on large datasets. But I do not have enough empirical data to support this conjecture. Best, nbpf

ChrisSU posted:

Jan-Erik Nordoen posted:

My bad. Naim does not want to play host to any music file sharing, so the thread was pulled.

I would, however, like to post a summary of the results (when they're all in), but I'm waiting for Richard's approval. If it's a no, well, I do have an email address.

Jan

I think Naim have to play safe here, and are probably right to cover themselves by pulling this thread. Whatever I might think about the recording industry, their heavy handed and counterproductive attempts to enforce copy protection and prevent file sharing, is largely irrelevant. Naim could end up in trouble if they are seen to condone or host file sharing, however innocent the purpose may appear to be.

If I were Naim I'd first be fascinated by the research and then immediately worried that we've found differences in the rips - both from the files analysis and from listening.

Adam Zielinski posted:

ChrisSU posted:

Jan-Erik Nordoen posted:

My bad. Naim does not want to play host to any music file sharing, so the thread was pulled.

I would, however, like to post a summary of the results (when they're all in), but I'm waiting for Richard's approval. If it's a no, well, I do have an email address.

Jan

I think Naim have to play safe here, and are probably right to cover themselves by pulling this thread. Whatever I might think about the recording industry, their heavy handed and counterproductive attempts to enforce copy protection and prevent file sharing, is largely irrelevant. Naim could end up in trouble if they are seen to condone or host file sharing, however innocent the purpose may appear to be.

If I were Naim I'd first be fascinated by the research and then immediately worried that we've found differences in the rips - both from the files analysis and from listening.

You have a point! Nonetheless, I can see that they need to watch their backs. 

your tests indicates that core may sound less musical than the serve in the spdif mode, if i have understood enough. 

So the next step is ethernet mode. Maybe the core rips will sound different ?   we will see

Keler Pierre posted:

your tests indicates that core may sound less musical than the serve in the spdif mode, if i have understood enough. 

So the next step is ethernet mode. Maybe the core rips will sound different ?   we will see

Nope - it doesn't imply that at all I'm afraid.

Adam Zielinski posted:

Keler Pierre posted:

your tests indicates that core may sound less musical than the serve in the spdif mode, if i have understood enough. 

So the next step is ethernet mode. Maybe the core rips will sound different ?   we will see

Nope - it doesn't imply that at all I'm afraid.

No SPDIF here 

if you are sufficiently worried about this issue, then ask naim for permission to rip a naim label CD....

ChrisSU posted:

Adam Zielinski posted:

Keler Pierre posted:

your tests indicates that core may sound less musical than the serve in the spdif mode, if i have understood enough. 

So the next step is ethernet mode. Maybe the core rips will sound different ?   we will see

Nope - it doesn't imply that at all I'm afraid.

No SPDIF here 

but in the beginning test of the comparaison of core rips vs serve rips, the conclusion was that the core rips are less musically involving. It was the forum "core meets the unitserve ", which is closed by naim. The next was to compare technically the two rips, and find why they are different from each other, no? But all begun when serve and core were linked to 2 different dacs, by bnc or spdif. It was the beginning of your interrogations.  Am i wrong?

My take on this is that Naim are more concerned about copyright issues than protectionism of a new product and the implication that it might, just might, be inferior to it's predecessor.

Naim have always shown a magnanimous approach to this forum, often allowing competitor products to be described by some as superior to the natural Naim alternative. Naim have a strong presence in their core (sorry) market and they know they have nothing to fear, particularly from a 'competitor' from their own factory that they have taken years to develop. I have, in the past, praised Naim for their generous and confident approach to many of the threads that might be seen by some as critical. Such tolerance is a sign of a mature and confident company and should be applauded.

There is no way IMHO that Naim would launch a new product unless they had successfully completed extensive listening tests (we know they will have done) and were convinced the said new product was a significant advance forward in SQ terms. This, of corse, should not stop us and the press from conducting exhaustive listening tests for ourselves. 

I say all of this as a (long-suffering but satisfied) UnitiServe owner and absolutely no experience of the Core.

Let's stop the mild paranoia and wait for some detailed feedback on the Core before we write it off as a lesser successor to the US.

Guys, it's easy to rip non copyright material. There is a huge amount of it about and you can even create your own tracks on your CDs using a CD writer of your voice, your dog barking, your cat meowing or you playing the kazoo. The media itself and what is encoded is quite irrelevant...  getting hooked up in copyright files is a complete side line, irrelevance and a distraction to the real observations. Also it's worth pointing out  the observed differences I measured should not create any SQ differences per se, but when coupled with real system of disk reads or UPnP transfers these offset differences may result in a slightly different end sound on some systems. Now what constitutes best SQ  may simply represent  the presentation you are most used to and be entirely subjective. The relative timing, length  and absolute values as well as the headers are 100% identical between the rips .. i.e. there is no difference there at all. It's the absolute timing or offset of the samples within the rip file itself which are different 

Simon

jon honeyball posted:

if you are sufficiently worried about this issue, then ask naim for permission to rip a naim label CD....

Jon, brilliant suggestion.

nigelb posted:

My take on this is that Naim are more concerned about copyright issues than protectionism of a new product and the implication that it might, just might, be inferior to it's predecessor.

Naim have always shown a magnanimous approach to this forum, often allowing competitor products to be described by some as superior to the natural Naim alternative. Naim have a strong presence in their core (sorry) market and they know they have nothing to fear, particularly from a 'competitor' from their own factory that they have taken years to develop. I have, in the past, praised Naim for their generous and confident approach to many of the threads that might be seen by some as critical. Such tolerance is a sign of a mature and confident company and should be applauded.

There is no way IMHO that Naim would launch a new product unless they had successfully completed extensive listening tests (we know they will have done) and were convinced the said new product was a significant advance forward in SQ terms. This, of corse, should not stop us and the press from conducting exhaustive listening tests for ourselves. 

I say all of this as a (long-suffering but satisfied) UnitiServe owner and absolutely no experience of the Core.

Let's stop the mild paranoia and wait for some detailed feedback on the Core before we write it off as a lesser successor to the US.

I agree with your assessment but I have to add that the comparisons reported in the "core meets the unitserve" thread were actually the first detailed feedback on the Core I had came across so far!

I might have missed some important piece of information, of course. But, to the best of my knowledge, Naim has so far provided very little and certainly not very detailed technical information on the new device. For example, we do not know which sound card is used for the SPDIF output and which player and, by large, audio software is running on the Core.

I do not doubt that Naim have made their homework carefully and ensured that they are not breaking any copyleft licence. Still, I do believe that a company that decides to take advantage of open source software for building a device has some moral obligations. One is to provide detailed technical information on the software running on that device to the interested community and to support detailed comparisons of the results of running that software.

In the specific case, I would have expected Naim to pro-actively provide samples of the expected results of ripping specific albums or tracks with the US and with the Core instead of just shutting down the thread.

This would have allowed US and Core owners to attempt at independently reproducing those results on their own devices. Interested enthusiasts or Core perspective buyers would have been able to compare the results of ripping with USs and Cores on their own replay systems and without any concern of infringing whatsoever copyright or copyleft agreement.

jon honeyball posted:

if you are sufficiently worried about this issue, then ask naim for permission to rip a naim label CD....

I think this is thebest way forward.

And if Naim is not afraid of a user comparison, I suggest we do that test again.

@  Jan-Erik: do you have access to a Naim sampler CD that you could use?

Adam Zielinski posted:

jon honeyball posted:

if you are sufficiently worried about this issue, then ask naim for permission to rip a naim label CD....

I think this is the best way forward.

And if Naim is not afraid of a user comparison, I suggest we do that test again.

@  Jan-Erik: do you have access to a Naim sampler CD that you could use?

[@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

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

Have a look here http://www.accuraterip.com/driveoffsets.htm. In the deleted thread I was suggesting that the rips could be identical mudulo drive offsets. It should not be terribly difficult to verify whether this conjecture is true or false, perhaps Naim could provide some explanation. Best, nbpf

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

I'll repeat this again. No, I am not going to do comparisons between my HDX and "my" Core because my Core is preproduction prototype made and delivered to me months ago. 

Even so, I am not going to do the comparison when my shop-bought Core arrives, because it is highly likely that there are tweaks to the firmware to come over the next month or two. Any of which could change/improve/make more purple the sound quality, if you think that the issue matters, is real and relevant anyway

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

I know waaaay more biology than I know this technology, but the similarities to the way DNA (and RNA) encode are quite striking when thought of this way.  No wonder both are termed "encoding" as that's exactly what they do.  

With DNA (RNA), the info that encodes the amino acid sequence of a protein (abcdefghijklmnop in your example) also is but a part of the total contents of the 'container' ("gene").  Something we continue to learn more and more about over time is the true role of those 0's ("non-coding regions") in biology; while 40 years ago most of the 0's were thought to be rather meaningless, we are finding more and more roles and meaning to them as research progresses.

Sorry for the diversion!

Bart posted:

Sorry for the diversion!

Not at all. I'm a biologist by training and currently reading Richard Dawkin's The Blind Watchmaker. Don't miss it (along with The Selfish Gene).

Jan

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

Bart posted:

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

I know waaaay more biology than I know this technology, but the similarities to the way DNA (and RNA) encode are quite striking when thought of this way.  No wonder both are termed "encoding" as that's exactly what they do.  

With DNA (RNA), the info that encodes the amino acid sequence of a protein (abcdefghijklmnop in your example) also is but a part of the total contents of the 'container' ("gene").  Something we continue to learn more and more about over time is the true role of those 0's ("non-coding regions") in biology; while 40 years ago most of the 0's were thought to be rather meaningless, we are finding more and more roles and meaning to them as research progresses.

Sorry for the diversion!

Bart, not at all - having listened to my dear middle brother for hours, he is the senior rheumatologist  doctor for a large UK hospital, talking to me about cells and DNA - the best I can come up with is the CD rips are the cell proteins and the device thats reads the rip into the media data to be streamed etc is the Mitochondria - gets the proteins slightly different or differently sequenced - and the output of the Mitochondria may well be different... if I am talking rubbish I do apologise - biology was never my thing...