Rip your files the NAIM way...or else???

Posted by: Geoff P on 01 August 2012

On another thread here which discussed limitations to file transfer and storage on the UnitiServe outside of ripping in the box (and by reference also the HDX/NS0x series swell)  the following responses were given to questions suggesting bit perfect rips by commercial software such as dB Poweramp or EAC should be accessible and transferrable with the same results as the internal Naim controlled rips.


Paul Stephenson:-


"Easy naim rip via our server easy db and eac good but our rip and our drive choice usually outperforms"


Phil Harris:-


"The point here is that the UnitiServe (and HDX / NS0x) are designed as a hardware and software combination that gives a good set of results without the end user having to work out and put together their own combinations of hardware - i.e. the rips should be as good as it is possible for them to be - bit perfect.

EAC or db *CAN* also achieve bit perfect rips but EAC or db are only part of the solution - there's hardware that they sit on top of and that too has to support the process. Just throwing EAC or db at a CD on its own does not guarantee a bit perfect rip if the hardware tey're running on doesn't support that.

If there are differences in the rip then there *WILL* be differences in the payback of those rips and if a rip produced by EAC or db isn't bit perfect then there's nothing that any utility written by anyone can do to make them so...


Paul Again:-


"....as Phil replies its the combination of hardware and software, the files will look identical from,db,eac or itunes but from the experiences we have had here the sound is not."


The issues for the larger digital ripping community that this raises should be answered if the above statements are taken to be correct.

 

1) By implication the US has a hard disk /hardware chain inside it that confers some quality of performance that is specific to Naim. Does this also apply to the SSD version and if so that MUST eliminate the HDD inside the US from this argument.

 

2) If the statements above are correct then by inference the use of a NAS will change the situation. Naim apparently does not say to get the best results with a digital audio chain that includes the US ( or HDX etc) a specific make of NAS hardware is required to preserve the 'Naimness' of rips made on the US. Does this mean that Naim does not include the wider field of NAS hardware in their claim.

 

3) Does this mean that the ripping process in a Naim server box is necessary to obtain the full benefit of the Naim rip strategy and that therefore systems without a Naim ripper in them are compromised in some fashion.

 

4) When it is stated the EAC or dB CAN produce bit perfect rips, but only if the hardware there running on allows it, by implication the manufacture of some CD Rom drives is so unusual that the Accurate rip database can be cheated by them and that whole section of the data storage industry happily accepts non-bit perfect archiving of files may occur.

 

5) How does the Naim label create its download files and are they also going to sound the same as ostensibly the same music files ripped off CDs on a US. For that matter when we download audio files from other respected sources are we missing out again.

 

I find it hard to believe the above is true. But if it is then it implies the wider world of ripping/storage and transfer of audio is inferior in some way.

 

Posted on: 09 August 2012 by thebiglebowski

One was a CD rip and the other was a vinyl rip. 

Posted on: 09 August 2012 by James L
Originally Posted by thebiglebowski:

One was a CD rip and the other was a vinyl rip. 

Dude

 

OK, it's getting clearer.

 

Sorry to ask but I'm trying to understand what you're comparing.

Vinyl and CD rips of the same song isn't really apples with apples but I think what you are saying is your vinyl rip at 24/96 sound better than your CD rip? 

Posted on: 10 August 2012 by Geoff P

I have done quite a bit of Vinyl ripping. I use an audio chain that can capture to Mac Core Audio at 192/32 and then export to WAV at a frequency/bit rate of your choice.

 

This I have done comparing 44.1/16 with 44.1/24, 48/24 with 96/24 and 96/24 with 192/24 on multiple LP recordings.

 

In common with the general view among enthusiasts the biggest jump in perceived audio playback quality comes consistently from 24 bit over 16 bit.

 

44.1/24 vs 48/24 has virtually no audio difference.

 

Going up 96/24 adds a sense of space and air to the audio that I find attractive and steps closer to the replay of that Vinyl on my TT.

 

Going to 192/24 does very little that I can perceive, except double the file size. Obviously the extended audio frequency range of Vinyl while it goes up into the 25 KHz range ( and the associated lower harmonics) is unlikely to have any benefit other than signal/noise gain form 192/24.

 

The upshot is that I now rip Vinyl to 96/24.

 

On the other hand HiDef studio masters from Linn and Naim at 192/24 sound superb. I don't have any that can be compared at 96/24 but feel there is some extra presence particularly in the classical perfomances captured at 192/24

 

 

Geoff

Posted on: 10 August 2012 by Peter_RN
Originally Posted by Simon-in-Suffolk:

Hook

 

I have just set to the TcpWindowsSize to 2097120 dec.

 

This is in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

 

I have created the DWORD value TcpWindowSize and entered the value 2097120 dec then restarted the machine (WHS).

 

This overrides the autosizing alogorithm and sets the send max windows size to 2M - subject to the NDX.  I will be listening shortly to the differneces - but my listening room is in use right now :-o

 

Simon

 

 

Hi Simon

 

This is interesting stuff, thanks for your effort. I am running Windows XP and have installed the key you mention but am wondering if it is necessary to also install the “Tcp1323Opts" & "GlobalMaxTcpWindowSize" Keys. I do not have WHS so don’t know if either or both of these keys are already installed on your system, or just not required for our needs.

 

I have tried reading up on this but it is inconclusive to me as to whether or not the "TcpWindowSize" key will function without these keys.

 

Would be grateful if you could advise

 

Regards,

Peter

Posted on: 10 August 2012 by Simon-in-Suffolk

Hi Peter - I am no expert on MS latest TCPIP stack, but I understand using the TcpWindowSize disables the autoscaling (RFC 1323)  function which is used by default so you don't need to activate if i understand correctly  on the later MS OS systems. However the settings I provided are for WHS (Server 2003) and may be different for other later OS.

 

I did have a listen last night in the end - and as usual my system sounded fantastic  (NDX -> NDAC/555PS + tweaks) and so its hard to say if it has improved the sound - as it tends to sound just right anyway...  So in the end I just ended up listening to my tunes Enjoying the remasters of Mike Oldfields work at present that has just been released. (Olympic opening ceremony spin off methinks!)

 

I will try and run wireshark when I get a chance to see what is happening down at the TCP level and what the NDX is letting the WHS machine expand to.

 

Simon

 

Posted on: 10 August 2012 by Peter_RN

Thanks very much Simon, would be interested if you learn anything from Wireshark which is a program I have never looked at as I think it would be beyond my capability to understand.

 

I know exactly what you mean about becoming immersed in the music, for me it’s been an afternoon of Mozart followed by Ann Sophie Mutter playing various Adagios; fantastic.

 

I did encounter a small issue when I set the key to 2097120 decimal, so reduced it and made it an exact multiple of my MSS – that sorted the issue but I am wondering if I gave it a fair trial so may change it back and see if the issue returns. If only the music didn’t keep getting in the way!

 

Regards

Peter