Unityqute vs NS01
Posted by: stfr on 13 September 2010
Hi
Im going to do a test to see if the Unityqute is as good or better than the NS01?
I have the Naim DAC today and because NS01 only have Digital out with RCA (That is what im using today)
while the Unity have BNC digital out
Can it be that the Unityqute have the better output?
The signal still go through the DAC
Im going to do a test to see if the Unityqute is as good or better than the NS01?
I have the Naim DAC today and because NS01 only have Digital out with RCA (That is what im using today)
while the Unity have BNC digital out
Can it be that the Unityqute have the better output?
The signal still go through the DAC
Posted on: 13 September 2010 by Occean
I would really hope they all produce low jitter bitperfect digital streams, so sound the same...
but I could be wrong
but I could be wrong
Posted on: 13 September 2010 by Richard Dane
Well, one of them is a streamer and one is a server so I guess there may be a difference depending upon the file source...
Posted on: 13 September 2010 by stfr
File source or quality of rip, what do you mean?
What software do Naim recommend to use to rip a CD for using with the Unityqute?
What software do Naim recommend to use to rip a CD for using with the Unityqute?
Posted on: 13 September 2010 by Frank Abela
An HDX, UnitiServe or NS01...
Posted on: 13 September 2010 by Richard Dane
Frank beat me to it! Naim's ripping devices are recommended because they are the only way where Naim have total control over the type of drive, drive optimisation, and software.
Any other ripping method, drive or software is an unknown - possibly great, possibly less-so...
Without wishing to get into a debate that is raging elsewhere both on this forum and pretty much everywhere else, it seems that even where two different rips are theoretically the same and "perfect", people can hear differences. I've done a bit of my own testing here but feel I have only scratched the surface.
If I rip the same disc via both EAC and DBpoweramp, for example, and both rips check out with the Accuraterip database as "accurate", they should surely sound the same...? And what of the same disc ripped via a Naim HDX? That too should theoretically be the same, but some claim there are differences between all these, whether down to hardware or software. I'm open minded and am finding out for myself. What's great is that anyone can do the same quite easily.
Great fun...
Any other ripping method, drive or software is an unknown - possibly great, possibly less-so...
Without wishing to get into a debate that is raging elsewhere both on this forum and pretty much everywhere else, it seems that even where two different rips are theoretically the same and "perfect", people can hear differences. I've done a bit of my own testing here but feel I have only scratched the surface.
If I rip the same disc via both EAC and DBpoweramp, for example, and both rips check out with the Accuraterip database as "accurate", they should surely sound the same...? And what of the same disc ripped via a Naim HDX? That too should theoretically be the same, but some claim there are differences between all these, whether down to hardware or software. I'm open minded and am finding out for myself. What's great is that anyone can do the same quite easily.
Great fun...
Posted on: 13 September 2010 by Simon-in-Suffolk
quote:Originally posted by Richard Dane:
If I rip the same disc via both EAC and DBpoweramp, for example, and both rips check out with the Accuraterip database as "accurate", they should surely sound the same...? . What's great is that anyone can do the same quite easily.
Great fun...
Well I have done the same with these two apps - and also confirmed the CRC is identical in both files. I have played the 'different' files via the same streamer application and platform and I can't detect any difference - however I have streamed the files from the same streamer app on differnt platforms - a PC and a Linux NAS - and I can hear a difference between identical files. Now I can think of possible reasons for this but I haven't had the time to investigate. My most likely theory is the UDP stream is queued differently on the (Network Interface card) NIC and TCP/IP stack for each server so the inter datagram timing (packet jitter) of the UDP is different entering the LAN segment - and as UPnP uses UDP for the media stream then the datagrams are unconfirmed and could be occasionally dropped at the NIC and cause jitter or interpolation errors in the receiver. Of course if this was the case then you would ideally want to have a dedicated switched subnet for the streamer receiver to keep other network traffic and broadcast / multicast traffic at bay - which otherwsie would be keeping your NICs and TCP/IP stacks busy.
Simon
Posted on: 14 September 2010 by ferenc
quote:Originally posted by Simon-in-Suffolk:quote:Originally posted by Richard Dane:
If I rip the same disc via both EAC and DBpoweramp, for example, and both rips check out with the Accuraterip database as "accurate", they should surely sound the same...? . What's great is that anyone can do the same quite easily.
Great fun...
Well I have done the same with these two apps - and also confirmed the CRC is identical in both files. I have played the 'different' files via the same streamer application and platform and I can't detect any difference - however I have streamed the files from the same streamer app on differnt platforms - a PC and a Linux NAS - and I can hear a difference between identical files. Now I can think of possible reasons for this but I haven't had the time to investigate. My most likely theory is the UDP stream is queued differently on the (Network Interface card) NIC and TCP/IP stack for each server so the inter datagram timing (packet jitter) of the UDP is different entering the LAN segment - and as UPnP uses UDP for the media stream then the datagrams are unconfirmed and could be occasionally dropped at the NIC and cause jitter or interpolation errors in the receiver. Of course if this was the case then you would ideally want to have a dedicated switched subnet for the streamer receiver to keep other network traffic and broadcast / multicast traffic at bay - which otherwsie would be keeping your NICs and TCP/IP stacks busy.
Simon
Sounds good to me, quite believable explanation.