unitserve rips vs core rips

I would not jump to conclusions.  The issue was likely of copyrighted material.  Lets be patient for follow-up.

Charlie

Naim have always been VERY tolerant of discussions of the pro's and con's of their products.  They do not censor this forum when people report on the performance of their products.  

Indeed. They seem quite happy when a few of us say that a £400 nas sounds better than a £2,400 UnitiServe. I really don't understand why everyone is getting in a tizzy about the Core, which seems a largely pointless product. 

I'm sure it's the hope and prayer that SOMETHING can sound better than a £400 nas.  The £400 nas certainly is THE value in our systems; most of us are paying more than that for a single ethernet cable!  So there must be something wrong with it . . . 

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 have shared some test results with full redaction of any potential copyrighted material - although the media itself was irrelevant 

There were two special test files that Jan provided - Test Rip A and Test B -

Jan which ripper did which as they were differences in the  data chunk..

Edit - my post with the test summary has disappeared again... something fishy is going on on the forum... perhaps it doesn't like hexadecimal text..

Any discussion based around ripped music that has been distributed by a member who does not own the copyright or have permission from the copyright holder to do so, is not permitted here. Sorry. 

Richard - I believe the rips were test files - I had suggested we use copyright free material and far as I concerned it was as there was no flag/or meta value to say the material was copyrighted in the file - which would normally be used for copyrighted material - as it was irrelevant and not listened to - it could have been a kettle boiling as far as I am concerned or a 1950s copyright free recording - I have no idea what they sounded like - as I say it is a complete irrelevance and as I said i'd let others confirm on SQ etc - I was  examining the containers - and the samples chunks in A and B were different...

Simon, I have been in contact with Jan-Erik and this being Naims forum, it's their call on this one. I'm sure he will be in touch with Naim on Monday.

Richard - ok I understand thanks

S

I should be receiving a hard disk to slot into the Core, which will allow me to compare rips to hard disk with those that I've made to USB and to the UnitiServe's downloads section. While I can't tell the difference between Core rips made to USB or to the Serve, I can (generally) tell that they were made on the Core. The question that is bugging me is how, or why, would Core rips made to its internal HD be any different? 

Can something happen to a ripped file when it is transported over a network and reassembled on another hard disk, that would not occur by ripping it directly to an internal drive?

I thought music was supposed to be fun...

Jan

Jan - i have sent you an email on this - I am not sure its appropriate to discuss such differences on the forum at this time

The possible differences I'm discussing do not refer to 'ripped music that has been distributed by a member', but music that I will be ripping on the Core (and not distributing). Thanks for your email (I've replied) which points to playback as the possible issue. My question above was 'Is there any reason to expect that ripping to an internal HD would produce anything different than ripping to USB or a network drive?'

If that's a definite 'no', then any differences would have to occur during playback, on which you've just enlightened me.

Thanks

Jan

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? 

Richard Dane posted:

Any discussion based around ripped music that has been distributed by a member who does not own the copyright or have permission from the copyright holder to do so, is not permitted here. Sorry. 

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. Also, notice that the vast majority of the contributions to the thread were discussions about the Core which were completely unrelated to whatsoever comparisons of ripped data. If Naim has not been explicitly asked to take down the whole thread by copyright owners, closing the whole thread seems indeed a very unfortunate overreaction to me. Best, nbpf   

i am happy to join you all on this discussion.  I think this is important because the core or unitserve are not mirror products, but "transports" that serve streaming dac as ndx or nds.

They are better as common nas and we all know today that nds/ or ndx....with unitserve or core sound better than nds/ ndx with nas.  You will not put a naim dac with a transport cd that costs 100 eur. 

So core and unitserve are the best digital transports for naim streamers, even better than melco or innuos( not for every one). The comparaison of unitserve vs core is not a marginal question.

Keler Pierre posted:

 

So core and unitserve are the best digital transports for naim streamers, even better than melco or innuos( not for every one). The comparaison of unitserve vs core is not a marginal question.

I don't think there are any grounds you can say this at all. The Unitiserve and the Core are effective transports providing fantastic Naim usability benefits. Many use different transports - and some of us have even found what we believe are 'better sounding' UPnP media transports than the UnitiServe for our Naim streamers - jury out on the Core at present.

Keler Pierre posted:

They are better as common nas and we all know today that nds/ or ndx....with unitserve or core sound better than nds/ ndx with nas.  

Who is this 'we' then? There are a good number on here who have tried the comparison and found the nas better. I certainly have. 

Hungryhalibut posted:

Keler Pierre posted:

They are better as common nas and we all know today that nds/ or ndx....with unitserve or core sound better than nds/ ndx with nas.  

Who is this 'we' then? There are a good number on here who have tried the comparison and found the nas better. I certainly have. 

it is what i think and what i have often read on naim forums . But perhaps it is not the truth and maybe i am wrong.   But if nas were better, then there would be no market for melco, cad, innuos and sound galleries....which cost ten to thirty times the cost of a nas.

But you are right, it is only my opinion and the opinion of some.   My point was to explain why the core/ unitserve discussion is not marginal .

Jan-Erik Nordoen posted:

...

My question above was 'Is there any reason to expect that ripping to an internal HD would produce anything different than ripping to USB or a network drive?'

...

In principle yes ...

when you rip to an internal HD the ripping software usually makes a checksum test to make sure that the original data and the HD data are not obviously different. This ensures identity with a (relatively high) degree of probability.

When you rip to a network drive, the file transfer protocol usually makes a checksum test to make sure that the original data and the received data are not obviously different. However, checking the identity (again, in a statistical sense) between the received data and the data written to the remote HD is often delegated to the remote OS which does not necessarily make a checksum test.

This is the reason why verifying the result of data transfer over the network is not completely trivial. Thus, for instance, a common strategy for ensuring the (statistical) identity of source and target upon data transfer across a network is to repeat an `rsync` command two times. The first time to actually copy the data. The second time, with the `-c` options to enforce MD5 checksum comparison between source and data, to assess that the results of the first step are (statistically) correct.

In practice though ...

if you observe systematic differences between ripping to internal HD and ripping to NAS, random transmission errors can hardly be an explanation.

In this case, I would first check whether the file systems of the internal HD and of the NAS are the same or not and whether the differences are still there when you rip to drives with the same FS.

The next test would be to swap drives. What happens if you move the internal HD to the NAS device and replace it with the NAS drive?

Best, nbpf

I don't think there any transmission errors occuring, however there is inter process and system coupling which can effect things as some of us, and not least Naim so I now understand,  are quite familiar with ... examples include Tidal vs local media playback, transport jitter, and FLAC vs WAV.

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

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.

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.. I have posted the differences twice now, but Richard asked that such differences are removed for the time being... it's Naim's shout on their forum... I have the details between the two rips of the same source  should anyone be interested..

Simon-in-Suffolk posted:

I don't think there any transmission errors occuring, however there is inter process and system coupling which can effect things as some of us, and not least Naim so I now understand,  are quite familiar with ... examples include Tidal vs local media playback, transport jitter, and FLAC vs WAV.

I never cared about checksum testing the results of mirroring my music collection via rsync until I came across a file that was stuttering on my main system but not when replaying from my master source. As it turned out, the two files had the same size but were different. Since then, I regularly check the results of data transfers by re-running rsync with the `-c` option. Every few months I get a positive feedback from the check on a 400GB collection. Best. nbpf