unitserve rips vs core rips

Posted by: French Rooster on 07 January 2017

this topic is not accessible anymore. unitserve rips are better than core rips and naim don't like it?

Posted on: 11 January 2017 by ChrisSU
David Hendon posted:

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.

Based on the rips examined so far, there is no change to any non-zero samples.

Posted on: 11 January 2017 by David Hendon

But have you seen non-zero leading samples?

Posted on: 11 January 2017 by Simon-in-Suffolk

OK -i will cut out my attempted simplification which seems to be causing more confusion  - here is a screen shot of the actual differences from the tool - note I have highlighted the files at the point of difference in the inspector window (highlighted yellow) -

FILE_A-FILE_B

There is no such thing as a leading sample as some sort of separate entity - a PCM sample is a PCM sample - what it represents in the music whether silence or a value will depend entirely on the media - hopefully the above makes clearer - anyway the above is the actual reality.. for the eagle eyed amongst you can see the left and right channels fade in at evers o slightly different times - perhaps the faders on the mastering desk were not dead centre.

Posted on: 11 January 2017 by ChrisSU
David Hendon posted:

But have you seen non-zero leading samples?

Yes, they are identical in the 4 pairs of files I have looked at.

Posted on: 11 January 2017 by nbpf
ChrisSU posted:
David Hendon posted:

But have you seen non-zero leading samples?

Yes, they are identical in the 4 pairs of files I have looked at.

Exactly and they are right at the beginning of the 4 pairs. These bits are what I referred to as "headers".

Posted on: 11 January 2017 by Simon-in-Suffolk

The DataChunk has 8 header hex values before the stereo sample structure - there are 4 bytes containing the ascii values 'data' and there is another 4 bytes containing the length in hexadecimal  of all the samples - and then you start the samples (at 3Ah bytes from the start of the wav file) in the above rips

My graphic above shows ..

Posted on: 11 January 2017 by French Rooster
Adam Zielinski posted:
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.

the ripping quality has for me no interest if it is not related to sound quality.  I have understood that the debate is about the ripping quality, but so than?   i read that recent debate as  intellectual masturbation. But the beginning of this debate was the sound of the core vs us and i don't think it is closed.

Posted on: 11 January 2017 by French Rooster
Keler Pierre posted:
Adam Zielinski posted:
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.

the ripping quality has for me no interest if it is not related to sound quality.  I have understood that the debate is about the ripping quality, but so than?   i read that recent debate as  intellectual masturbation. But the beginning of this debate was the sound of the core vs us and i don't think it is closed.

sorry guys and you Adam, i was perhaps a bit agressive.  But you can also compare two lps, one original pressing and the same album as today audiophile  remaster. The second is more  technically perfect , more dynamic and silent, better pressed.... but sometimes the original pressing is more musical. You can analyze the master processing and all you want,you will not find why the original pressing sounds better in some cases.  I think your tests on the different rips produced by serve and core are the same case.

Posted on: 11 January 2017 by nbpf
Keler Pierre posted:
Keler Pierre posted:
Adam Zielinski posted:
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.

the ripping quality has for me no interest if it is not related to sound quality.  I have understood that the debate is about the ripping quality, but so than?   i read that recent debate as  intellectual masturbation. But the beginning of this debate was the sound of the core vs us and i don't think it is closed.

sorry guys and you Adam, i was perhaps a bit agressive.  But you can also compare two lps, one original pressing and the same album as today audiophile  remaster. The second is more  technically perfect , more dynamic and silent, better pressed.... but sometimes the original pressing is more musical. You can analyze the master processing and all you want,you will not find why the original pressing sounds better in some cases.  I think your tests on the different rips produced by serve and core are the same case.

As Adam pointed out, you are misunderstanding what this thread is about, I believe.

The Core is, among others, a ripping station, a UPnP server, a SPDIF player and a storage system.

In this thread, we have been discussing the ripping capabilities of the Core. More specifically, we have been discussing the ripping capabilities of the Core as compared to the US.

The original thread started by Jan-Erik (and meanwhile deleted) was also meant to compare the ripping capabilities of the Core and of the US.

I am sure that there will be threads focussing on the Core as a SPDIF player or on the capabilities of the Core as a UPnP server. But these are not issues that have been discussed here so far. 

This is not a problem, however. If you are specifically interested in the Core as a SPDIF player, just open a thread with the title "The Core as a SPDIF player". If you want to discuss the Core as a UPnP server, open a "The Core as a UPnP server" thread. If you are interested in buying a Core, open a "The Core from the perspective of a potential user". It's up to you!

Posted on: 11 January 2017 by Simon-in-Suffolk

I have now compared the rips of a gapless wave file - i.e. there is no mastered lead in, the 'music' starts immediately - and now you can see samples are omitted from one of the rips compared to the other at the start. Again the offset is - that is the number of samples lost -  240 or approx 2.7mS of audio is dropped.

FILE_C-FILE_D

Posted on: 11 January 2017 by French Rooster
nbpf posted:
Keler Pierre posted:
Keler Pierre posted:
Adam Zielinski posted:
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.

the ripping quality has for me no interest if it is not related to sound quality.  I have understood that the debate is about the ripping quality, but so than?   i read that recent debate as  intellectual masturbation. But the beginning of this debate was the sound of the core vs us and i don't think it is closed.

sorry guys and you Adam, i was perhaps a bit agressive.  But you can also compare two lps, one original pressing and the same album as today audiophile  remaster. The second is more  technically perfect , more dynamic and silent, better pressed.... but sometimes the original pressing is more musical. You can analyze the master processing and all you want,you will not find why the original pressing sounds better in some cases.  I think your tests on the different rips produced by serve and core are the same case.

As Adam pointed out, you are misunderstanding what this thread is about, I believe.

The Core is, among others, a ripping station, a UPnP server, a SPDIF player and a storage system.

In this thread, we have been discussing the ripping capabilities of the Core. More specifically, we have been discussing the ripping capabilities of the Core as compared to the US.

The original thread started by Jan-Erik (and meanwhile deleted) was also meant to compare the ripping capabilities of the Core and of the US.

I am sure that there will be threads focussing on the Core as a SPDIF player or on the capabilities of the Core as a UPnP server. But these are not issues that have been discussed here so far. 

This is not a problem, however. If you are specifically interested in the Core as a SPDIF player, just open a thread with the title "The Core as a SPDIF player". If you want to discuss the Core as a UPnP server, open a "The Core as a UPnP server" thread. If you are interested in buying a Core, open a "The Core from the perspective of a potential user". It's up to you!

you are right, i was searching an information that this topic is not for. I was hoping it would transform itself in what is my interest now. 

Posted on: 11 January 2017 by ChrisSU
Simon-in-Suffolk posted:

I have now compared the rips of a gapless wave file - i.e. there is no mastered lead in, the 'music' starts immediately - and now you can see samples are omitted from one of the rips compared to the other at the start. Again the offset is - that is the number of samples lost -  240 or approx 2.7mS of audio is dropped.

FILE_C-FILE_D

The plot thickens! Does this produce an edible effect, a click or whatever, when listening? I'm guessing maybe not, just a tiny bit of music missing??

Posted on: 11 January 2017 by nbpf
Simon-in-Suffolk posted:

I have now compared the rips of a gapless wave file - i.e. there is no mastered lead in, the 'music' starts immediately - and now you can see samples are omitted from one of the rips compared to the other at the start. Again the offset is - that is the number of samples lost -  240 or approx 2.7mS of audio is dropped.

FILE_C-FILE_D

That sucks. We can now be sure that Naim will have to fix this problem. I hope that this is easily done and that, at the end of the day, they'll give you a free beer for each of those 240 missing bits. Ende gut alles gut. Well done! Best, nbpf

Posted on: 11 January 2017 by nbpf
Keler Pierre posted:
nbpf posted:
Keler Pierre posted:
Keler Pierre posted:
Adam Zielinski posted:
Keler Pierre posted:
Jan-Erik Nordoen posted:
 

...

...

...

...

...

you are right, i was searching an information that this topic is not for. I was hoping it would transform itself in what is my interest now. 

That might happen, of course. But, for the sake of clarity, understandability and self-consistency, I think that, if you are specifically interested in the Core as a player or as a server, it would be better to open another thread. I would be interested in such a thread. Best, nbpf

Posted on: 11 January 2017 by nbpf
ChrisSU posted:
Simon-in-Suffolk posted:

I have now compared the rips of a gapless wave file - i.e. there is no mastered lead in, the 'music' starts immediately - and now you can see samples are omitted from one of the rips compared to the other at the start. Again the offset is - that is the number of samples lost -  240 or approx 2.7mS of audio is dropped.

FILE_C-FILE_D

The plot thickens! Does this produce an edible effect, a click or whatever, when listening? I'm guessing maybe not, just a tiny bit of music missing??

Does this really matter? Would you rip 2000 CDs with a 2348 EUR device that might o might not throw away tiny bits of your music when you can do a better job with a 60 EUR external drive? As I wrote in another thread, I find the Core potentially interesting but, as it is now, very disappointing. Still, I acknowledge that, for certain users, it could be a valuable replacement for their US devices. For this, however, it has to deliver bit perfect rips. At this point, it does not seem to do so.

Posted on: 11 January 2017 by Simon-in-Suffolk

I think it does matter - but almost certainly this will be fixed relatively quickly. I understand Jan has shared some of my analysis with Naim support and I suspect they will be looking at this as it straightforward to do. I think the relevance of posting here is to perhaps inform Core customers so they can decide or not whether to  potentially hold off mass ripping until resolved or otherwise advised by Naim. 

Posted on: 11 January 2017 by ChrisSU

I was just curious as to weather or not the missing bytes produced an audible effect. If not, who cares from a consumer point of view - I couldn't care two hoots weather or not my rips are technically bit perfect if the only imperfections are inaudible. As a manufacturer/designer, maybe it's different, I guess neglecting these details could be the start of a slippery slope to mediocrity, but that's not my problem right now!

Posted on: 11 January 2017 by Simon-in-Suffolk

Chris - I have not played the files - but I'd be surprised if they didn't - I would expect a 2.7mS loss of info  and a discontinuity - i.e. a sudden jump in sample values  to come across as a click or tick, possibly faint,  when replayed by your DAC

Posted on: 11 January 2017 by ChrisSU
Simon-in-Suffolk posted:

Chris - I have not played the files - but I'd be surprised if they didn't - I would expect a 2.7mS loss of info  and a discontinuity - i.e. a sudden jump in sample values  to come across as a click or tick, possibly faint,  when replayed by your DAC

Hmmmm, just like the DSD firmware again!? I think I'll retreat into my (Unitiserve) shell and let Naim sort this one out.

Posted on: 11 January 2017 by Don Atkinson
Simon-in-Suffolk posted:

Chris - I have not played the files - but I'd be surprised if they didn't - I would expect a 2.7mS gap and a discontinuity - i.e. a sudden jump in values  to come across as a click or tick, possibly faint,  when replayed by your DAC

Ok, if that's the only effect, and it only occurred just after the end of one track or just before the start of the next track, I could live with that. I mean, having lived with LPs for 50 years, the occasional click is neither here nor there.

However, I rather suspect that some pieces of music have no "silent" interludes between "tracks". In fact, i'm not at all sure whether I fully understand how a 5 minute piece of music is stored on a cd and how a Ripping device attempts to distinguish between a deliberate run-in between tracks and (say) a singer taking a silent breath or (say) an abrupt silence in a symphony followed immediately by an equally abrupt and dynamic continuation a moment later. If the ripper screws up these essential aspects of a piece of music by dropping a few micro-secs, I would be a bit choked, even if they only manifested themselves as "micro-clicks "

Posted on: 11 January 2017 by nbpf
ChrisSU posted:

I was just curious as to weather or not the missing bytes produced an audible effect. If not, who cares from a consumer point of view - I couldn't care two hoots weather or not my rips are technically bit perfect if the only imperfections are inaudible. As a manufacturer/designer, maybe it's different, I guess neglecting these details could be the start of a slippery slope to mediocrity, but that's not my problem right now!

I understand your point but the problem is that, knowing that the missing bytes do not produce any audible effect in the specific case of Jan's rips, does not imply that they will not produce audible effects in other cases. So far, we have been looking at just 4 pairs of samples! Thus, I personally would not take the risk of ripping a large collection of CDs knowing that the ripping software has deficiencies that do not produce audible effects in certain specific cases. I am confident that Naim will readily ensure consistency of ripping results and I would wait until they have fixed the issue. But, of course, I do not mind at all if others want to go ahead right now!

Posted on: 11 January 2017 by ChrisSU
nbpf posted:
ChrisSU posted:

I was just curious as to weather or not the missing bytes produced an audible effect. If not, who cares from a consumer point of view - I couldn't care two hoots weather or not my rips are technically bit perfect if the only imperfections are inaudible. As a manufacturer/designer, maybe it's different, I guess neglecting these details could be the start of a slippery slope to mediocrity, but that's not my problem right now!

I understand your point but the problem is that, knowing that the missing bytes do not produce any audible effect in the specific case of Jan's rips, does not imply that they will not produce audible effects in other cases. So far, we have been looking at just 4 pairs of samples! Thus, I personally would not take the risk of ripping a large collection of CDs knowing that the ripping software has deficiencies that do not produce audible effects in certain specific cases. I am confident that Naim will readily ensure consistency of ripping results and I would wait until they have fixed the issue. But, of course, I do not mind at all if others want to go ahead right now!

Indeed, in the unlikely event of me stumbling across a Core any time soon, I'll carry on ripping on my US for now!

Posted on: 11 January 2017 by sjbabbey

My understanding has been that each CD has a Table Of Contents {TOC) which is read by a CD player to determine where each track starts and ends thus allowing for such features as programmable playback. I'd expect that any DAE (ripping) software would also use the TOC making allowances for the CD drive's offset setting to produce accurate rips.

Posted on: 11 January 2017 by Simon-in-Suffolk

NBPF Who is looking at 4 pairs of samples - what is that all about then? Have I missed another thread on the subject?

Posted on: 11 January 2017 by ChrisSU
Simon-in-Suffolk posted:

NBPF Who is looking at 4 pairs of samples - what is that all about then? Have I missed another thread on the subject?

What samples? Must be your imagination!