Naim rip vs PC rip

Just do the demo–if you can't hear any difference, then (in your experience) there is none–end of process.

If you can hear a marked difference–buy it.

If a difference exists but the scale of the difference is, relatively speaking, not worth the price of admission, then say so. That's where the debate begins in many situations, here and on other forums.

And–if you haven't done the comparison yourself–it would be better not to say anything except to admit that one hasn't done an actual A-B.

We know just enough as an industry about digital audio to know we actually know very little about what happens between the bits, so to speak. We also know that we will soon be free (within a generation) of optical discs as a delivery media.

As for network services–we also know that we cannot know when in time a specific event will occur as regards transmission, collision, and re-aggregation. The best that one can do is to insure that data transmission is secure, sufficient, and a sensible use of resources.

All of these factor into the equation–and, as digital audio poses its own problems, we still must subject a process (that we think should, really, be simply a measure of flinging 0s and 1s around, a purely deterministic process) to our ears.

What comes out of the process had BETTER resemble what we think had gone into it.

To add to Vector's remark above–the HDX / UnitiServe models provide a high-performance, pre-configured UPnP™/DLNA™ streaming server, for use with network media players manufactured by Naim and by others.

Personally, I am motivated something very simple, and I think, very innocent:  I am curious to know how things work.   If we have reached the point where no explanation is possible, and as Dave suggests, the science hasn't caught up to what we are hearing, then we'll just have to agree (or agree to disagree).  There is simply no further place to take this discussion.

I do understand Dave's point -- try it for yourself, and then make your own purchase decision.  But even if I do, and even if I hear that a US rip sent to the NDX is much better than an EAC rip, I would still very much appreciate knowing why that is the case. And again, I will draw the analogy to the "do sources for the DAC sound the same" discussion because, after a similar amount of angst, that wound up at this exact same conclusion (or lack thereof).  

Unless there is some proprietary secrets that cannot be discussed, I think a few words from Naim development would be very helpful.  Or maybe these questions can be asked at an upcoming live chat event?

Hook

David

You are telling us to buy digital audio equipment like we buy amplifiers....

If amp #1 sounds better than amp #2 than buy it.

Fair enough..... I liked Naim amps better and thought they sounded better in my systems, so I bought them.

But Naim also tries to tell (convince?) me, in their marketing literature, why Naim Amps sound better...

"Many designs were explored for the NAC 252 and a complete review of the circuit topology and components took place in accordance with the developments pioneered in preamplifiers such as the NAC52. Hundreds of hours were spent listening to various designs, ensuring that the harmony between music and technology was always maintained.

Precision rotary potentiometers with precious metal wipers are used to preserve music integrity and ensure long-term stability."   and so on..........

So is it unreasonable for us to expect Naim to highlight/explain/trumpet through marketing literature the reason for their digital audio superiority?

Seems like a smart Marketing move as well 

+1, digital streaming certainly is not straightforward. For example, when reviewing Marantz's new streamer What HiFi stated that the very same rips soundes better through its USB than streamed via Ethernet/NAS. They also were nonplussed by Rotel's new streamer when streaming.

There are variants of streaming too, I'm not saying theirs is better but Linn's streaming transmission is different to many others as well.

So I agree with you that in the end, whether logic and common wisdom apply or are totally ignored, your ears should give the yay or nay.

Right now they have said 'I will' to each other on with the checks.

File 1: 04_-_Jazzy_Kinda_Sum_n

File 2: 1-04_Jazzy_Kinda_Sum_n

• File 1: The header chunk is two bytes longer than neccessary. It contains two undefined bytes at the end of the header fmt chunk both containing the values 0.
• File 1 contains the Fact chunk, which although not invalid, is not neccessary for PCM, as it simply repeats the BlockAlign and sample length paramters that appear in the fmt chunk and data chunk respectively.

• File 2: Optimised header, no undefined 0 value bytes (padding / unutilised space). Does not contain the uneccessary PCM sample  fact chunk.

All other details between the two files are *identical*. Ie the fmt header encoding paramters, and the sample data and the sample data length. There is no difference at all through the whole of the Data chunk.

ie the sample data in both  is 36B2E68 (Hex) bytes long and is identical byte by byte.

Sample format paramters:

short wFormatTag 1

unsigned short wChannels 2

unsigned long dwAvgBytesPerSec 176400 

unsigned short wBlockAlign 4 

unsigned short wBitsPerSample 16 

So in summary - although there will be no difference in SQ derived from the Wave file, the structure of the fmt chunk in file 1 is non optimal in as far as it contains uneccessary padding in the form of two 0 bytes and the fact chunk that is not neccessary for PCM.

In terms of sample accuracy both files are the same, in terms of efficiency/optimization File 2 is the better file.

Happy to compare any other files.There is no magic to this, it is all *very* straighforward.

Regards

Simon

Allen, I agree, that is where the issues / challanges lie, and here we are back in the world of standard electronics and physics. The streaming or file serving element per say has little bearing if any. Its the renderer,  the use SPDIF to carry a bit stream, the loading of data in to the DAC(s) etc that introduces many of the issues - with reflections, earthloops, inter bit jitter, charactersitic impedance mismatches, RF bleeding into analogue audio electronics, power line noise through digital switching loads (CPUs/microcontrollers ) and other factors and grounding earth loops affecting clock stability etc. All of these can affect the sonic picture, and again all is to do with standard electronics that has been around for decades and this is where I would expect Naim (and others) know how and practical expiereinces to shine.

Simon

It's not good enough to say "Just do the demo". You have made a specific technical claim that a dBpoweramp rip has a flawed header, causing it to play back incorrectly on Naim and Linn streamers.

Despite many requests you have not specified what this flaw is. It is an absolutely deterministic, objective  technical issue. There is a specification for the header; dbPoweramp rips either meet it or do not. You claim they do not.Tell us how. Give us an example. Give us a dump of a dBpoweramp header and show us all what it should be. Let us all see what technical competence is behind your technical claim.

And as for "we also know that we cannot know when in time a specific event will occur as regards transmission, collision, and re-aggregation", this is surely true, but what on earth does it mean? Can you demonstrate such things, or is this just more cod-technical gobbledegook?

I did not suggest that there was a specific issue with dBpoweramp file headers–go back and read my post. That was suggested by others ("which I also doubt")–and subsequently de-bunked (in theory).

What I did say is that any issues relating to data formatting should, in general, be addressed by the file creator, not the renderer (this applies also to other metadata-related processes including poorly-formatted EXIF headers, color space profiles, etc.), if the error creates a differential that can be independently confirmed using different renderers. (Note the use of the term "if"–it is not absolute.)

It is, has been, and must be sufficient to say, "Do the demo".

Network transmission over Ethernet is a stochastic process, and we honestly can't determine at any one time the location of an individual packet on the network. (No worries–let the packet arrive on its own accord, line it up, buffer it and spool it for conversion.) As mentioned above, this is not solely 0s and 1s.

I think you're afraid to walk into a retailer and do the dem, honestly.

Likesmusic,

The curiosity got the better of me and I have just done a  detailed breakdown dBPoweramp ripped wave file demo.

1. Header (FMT ) correctly specified, no padding or blank bytes in the fmt chunk. Sample paramaters appear correctly specified.

2. The Data chunk appears correctly specified, and no anomolies in the sample data.

3. dBpoweramp uses a LIST chunk with 6 LISTSUBCHUNKs which contain meta data / tagging about the CD that produced the RIP. All structured validly

4.  dBPoweramps uses its own private defined chunk called (id3 ) which is 2048 bytes long and contains other meta data that appears specific to dBPoweramp. Again the private chunk is validly specified.

The overall wav file is correctly specified with correct chunk lengths. The SQ is derived from the FMT and DATA chnuks and are correctly specified.

Cheers

Simon

Dave

 Network transmission over Ethernet is a stochastic process, and we honestly can't determine at any one time the location of an individual packet on the network. (No worries–let the packet arrive on its own accord, line it up, buffer it and spool it for conversion.)

No this is incorrect, actually we can do to within network segments where it matters, and on industrial networks it often does, but this has abosolutely ZERO to do with what we are talking about - so why mention it????

Simon

Maybe this is why the Linn DS's are proving so popular, because you take out many of these variables, for better or worse, but you buy into the 'sound' of that particular box. No add-ons, no external upgrades. It makes you think, doesn't it? 

That's a breakthrough step in your considerations, Allen. Did you already schedule the purchase of KDS? 

Allen,

Just to clarify, you mean bit perfect rips of the same file format created by different ripping engines but not necessarily accurate rips in different file formats, right? I seem to recall that you did find slight acoustic nuances between some of the various formats such as AIFF, WAV, FLAC, etc.

Thanks

tp 

Allen

Again I agree, your mention renderer algorithms - I was covering that by the switching noise caused by the CPU/microcontrollers in the power lines. This really can have an affect as the logic gates in the shift registers etc are enabled you will see noise on the line (it can be seen as high frequency hash with a scope, but get the CPU doing NOPs (No Operations) repeatedly you can see a cyclic pattern on the lines. Of course lines are decoupled to ground, but this is not 100% perfect and  of course as more energy is coupled to ground, the ground relative to star earth ground raises - all of these starts to have an affect when we are working to keep the stability and accuracy. It is the clocks in the devices that are so sensitive to this noise.

Its funny at this level - as discussed on another forum recently - its hard to say these symptoms degrade sound quality, as all audio replay devices are a compromise, but they more affect the overall sonic character of a device or a file format such as wav or flac.

You mention SPDIF - I must admit this is one of my bug bears, it can cause so many complications that have to be mitigated. The main ones being reflections and ringing/ harmonic attenuation in the connection (source/lead/sink) and the fact it is asynchronous, ie the clock has to be recovered from the signal.

When people say its all 1 or 0, they alas should have paid more attention at school. The world of digital electronics is ultimately analogue. The only difference between a square wave and a triangle wave is the rate of attenuation of the harmonics. A triangle wave would be undeterminsitic at the SPDIF level, ie the signal would be completely corrupted. So any reflections caused by characteristic impedance mis matches can filter harmonics. Filtered harmonics change the shape or phase of the square wave. This itself can cause bit errors. This is even before the bytes are buffered and reclocked to mitigate regular sample jitter for the DAC. Also you see RCA connectors (thankfully not with Naim) for SPDIF - this is just silly. Most RCA sockets have a characteristic impedance od 25 to 30 ohms - the SPDIF connection is designed for 75 ohm characteristic impedance. Therefore some horrible reflections / ringing are going to be caused if you use RCA. Of course most don't notice this until they start using transparent system such as those provided by Naim and others - and then we can start to hear the differences.

Also the RF electrical energy of the SPDIF signal with its harmonics is non trivial  and so care has to be taken to manage this away from the analogue electronics.

I must admit I thought it was these kind of issues that prompted Naim to shy away from standalone DACs with thier CDPs for so long - and yes I wonder if some of this has been behind Linn's thinking.

Simon

Me too. I would like to try NDS/555PS against the new KDS and make a proper step in accordance with my way of conceiving a music.  The bad point is that nobody knows when NDS will come up (could be tomorrow, could be in two years). The other bad point is that here in Dubai we shall hardly get a sample unit for demo -- unlike Linn stuff which is easily available (including the full-spec Klimax setup).

I expect NDS will target at CDS3 price point (around 10 K$ + PS).

I don't really like to spend that much without a home demo 

I have listened for KDS in my home system against nDAC/XPS and I was not totally convinced to make a swap. But what I liked is that KDS is extremely fluid, soft and natural on red books -- definitely closer to vinyl than nDAC. Possibly 552 will make KDS shine and outperform nDAC in all other aspects but again Dubai Audio does not offer 552 for demo... Needless to say that I hate the idea of buying 25 K$ stuff on trust 

Oh, yes -- that's on surface. Naim can definitely pull out a lot from the past CDP experience.

In hi-fi terms I'm sure NDS will outperform nDAC with whatever transport you may use. It's not the performance which bothers me -- it's a Naim philosophy of the House Sound. Where do they move. This could be away from my understanding of music qualities. I like some trends of nDAC (very fast transients) and didn't like the others (too bright for me). I still adore the way my LP12 portray the music -- spacious, holographic, soft and sharp in transients. Both nDAC and KDS lack this magic on red book (but KDS is closer).

Hi Allen and thanks

Firstly I played the two files and could hear no obvious difference. 

Then I used XLD to convert both files to AIFF and then ran a Unix diff command and it reported both files were identical. 

I played both AIFFs and could hear no difference. 

I've deleted the files from my computer. 

I'm maybe not the best person to test as I've achieved exactly the results I expected - rips of two identical tracks are the same in terms of SQ and music data. 

Simon has done a much more thorough job and I believe reached the same conclusion. 

It'll be interesting to hear if anybody thinks one sounds better than the other. 

All the best, Guy

That's playback - I don't think anybody is disputing the same file played back in two different ways can sound different. It is the creation of the file that is causing much discussion: it seems that an iTunes rip and UnitiServe rip have identical musical content and sound the same - at least for the test file. 

All the best, Guy

Ah i see - the Chorus App was a major selling point for me (and why i 'needed' an iPad  . When the DS players came out the control point software was rather clunky. The only time its slow is in the first 10 seconds of starting up if the library has to be reloaded.. My Mac and NAS power on and off at set times so i have a daily reload - after that its very responsive. Real estate usage on the iPad is good too - see screenshot (not mine by the way) but its the only one i have whilst i'm away.

If i wanted to go for an NDX solution then it would need to run with the Mac as a UPnP server. If that means a clunky n-Stream then its probably not for me at the moment  

Cheers

James

Confused, as I don't recall mentioning Linn - they do make exceedingly good record players though. 

All the best, Guy

Hi Allen,

Thanks for the clarification. I guess I somewhat confused things, although I am quite sure it was your post. Seems my recollection regarding your findings was a bit off though because I thought that in one of your posts, where you shared your experience with AIFF files into your Weiss dac, you mentioned that you slightly preferred their sonic character but that there was not much in it between AIFF and WAV. FLAC probably wasn't mentioned then. Well, good to know that you did not find there to be a difference as I have chosen AIFF for my rips. 

Br

tp