Why is the nDAC so cheap?
Posted by: Andy S on 04 May 2010
Serious question.
Have Naim scored an own goal? Using a cheap PC and optical to DAC on it's own is such a massive boost over my old CDS1 it just isn't funny and a mate is selling his CDS3 head end as the PC/DAC/XPS is as close as you could get to a CDS3. Not only that, I can connect up a number of sources and get benefit - the TV sounds SO much better through it.
Don't get me wrong, I'm not complaining since I've just bought one (the demo only lasted 5 minutes in all honesty - the distance was that big), just curious...
Have Naim scored an own goal? Using a cheap PC and optical to DAC on it's own is such a massive boost over my old CDS1 it just isn't funny and a mate is selling his CDS3 head end as the PC/DAC/XPS is as close as you could get to a CDS3. Not only that, I can connect up a number of sources and get benefit - the TV sounds SO much better through it.
Don't get me wrong, I'm not complaining since I've just bought one (the demo only lasted 5 minutes in all honesty - the distance was that big), just curious...
quote:Originally posted by Steve O:quote:Originally posted by Andy S:
BUT with computer audio, you rip once (and with EAC and AccurateRip you nearly always know if you have bit-perfect rips), and the replay would be the same every time and equivalent to a perfect transport.
Conclusion -> the best transport is a streaming player. How many who have different transports have tried them against a streaming player with confirmed bit-perfect rips from EAC?
Andy, I bow to your obvious superior technical knowledge.
I have yet to achieve a bit perfect EAC rip - my EAC rips always show some errors. This happens on my ancient desktop and with my shiny new Acer laptop. I have run the various diagnostics and set ups to establish the optimum read and write speeds but still have errors. Two or three tracks per disc will read as 98.x% or 99.y% accurate, the rest as 100%. I assume this is down to the transports reading of the disc and not the software (though I half expect to be corrected on this). My guess is if I could slow the transports read speed down I would get "perfect" rips but I don't know how to get past the defaults and the lowest read speed I can get is x8 - even though the program tells me the optimum speed is x16, which doesn't give perfect results either.
Could you please explain, as simply as possible, why this is happening or what it is I am doing wrong.
regards,
Steve.
Steve
Have found and set the correct read offset for your brand and make cd-drive?
That is one of most important things to get right. Further you would need to turn of the C2-error correctionand also bypass the audio cache. There are very good and detailed setup guides on the internet but Richard won't let me post any links (oooh did I say that
).-
aleg
My understanding is the following. Jitter is only important when you convert between digital and analogue (and vice versa) as it is distortion that is introduced by mistiming the conversion ever so slightly.quote:Originally posted by fatcat:
Andy
I think you are misunderstanding the capabilities of the Niam Dac
From white paper
"This eliminates jitter CAUSED by S/PDIF".
It doesn’t ELIMINATE jitter at the S/PDIF
Assuming only a single A/D process at the studio/mixing/mastering, the source material is converted between analogue and digital twice.
Once is at the studio and the second time is at the DAC stage. Jitter timing matters at only those two points. There is jitter in the source material depending on the accuracy of the sampling clock. Once captured, this cannot be removed unless you know the precise jitter of each individual conversion clock. This is not practical to measure, nor can it be stored on any current consumer media. This is the jitter that Naim (very cleverly) say they can't remove.
In terms of playback, you can delay any bit, byte, word, track, whatever by any amount and by any amount relative to each other at any point in between capture and conversion but as long as they all arrive at the DAC in the same order, the timing accuracy (hence jitter) they will be converted to analogue again is totally determined by the accuracy of the D to A clock.
Now what Naim say is that they totally eliminate any jitter introduced between A->D conversion (which has jitter in it) and the reading out of the RAM buffer by the clock. Yup, they are reclocking the data with a precision clock - it will remove all upstream jitter - wherever it has come from - SPDIF, transport, you name it. Assuming the DAC is sync'd to the incoming transport and can use one of it's high precision clocks, the ONLY jitter is in the readout of the RAM buffer and how much jitter is at the D->A converter due to the design of the DAC stage. There will be jitter in the final stage of conversion. You cannot eliminate it entirely - you can design a system to minimise it, but not eliminate it completely, but this jitter is inherent in the DAC, NOT the transport attached to it.
The key thing is that the jitter in the conversion is ONLY down to Naims implementation of RAM readout to analogue outputs. It is TOTALLY decorrelated to the SPDIF jitter - by design (in fact, the comms between the processor and DAC is done by optoisolators precisely to decouple the two sections electrically).
If transports do sound different the only explanation that can I can sensibly derive is that they are not bit perfect. This is entirely possible depending on how good the mechanisms are at reading correct data the first time. CD has a multi level error system where you can completely correct some errors but if you need to do what is known as "C2 error correction" you have to start interpolating data which will lead to variations. I'm willing to believe
Also, beware, just because it is on a PC/Mac doesn't mean you are streaming bit perfect. As I mentioned elsewhere, my Windows PC will only stream bit perfect 44.1kHz out of the USB port. Straight out of the SPDIF it is at 48kHz which means it has been processed before being output and is no longer bit perfect (i.e. exactly the same as what was placed on the CD).
There - glad I got that off my chest...
Ahh... Yes, a bit further trek than I was expecting..quote:Originally posted by Richard Dane:
Andy, once upon a time, when I worked at Naim HQ you would have been just down the road. However, these days, I'm located on the Kent/Sussex border, so a fair trek.
Still, I'll get my dealer to bring a transport of his choice over when he comes over Hi James,
I don't think jitter is the issue here. Jitter is about picoseconds of timing inaccuracies either side of the nominal frequency. Sometimes the data is early, sometimes it is late - but only by a miniscule margin. This would be avoided by having a 3 word buffer (perhaps this is all Naim do!!) whereby you would always be 1 word behind the input stream.
I don't know the tolerances involved in SPDIF clocks, but what is true is that they won't be EXACTLY 44.1kHz. I'm not going to second guess Naims engineering department on their clock implementation, as I'd need to sit down and redo their design and I'm far better at digital over analogue, but let me quote this from the white paper:
I think the thing that is bugging me is that people associate different sounds on the nDAC with jitter performance. I could understand this if the two were in any way coupled, but Naim claim they aren't. Whilst I couldn't hear ANY difference in my test, I'll request my dealer brings a high end transport with him when he comes down. People seem to hear a difference and the only options I can see for that is:
- Placebo effect
- Data isn't bit perfect (i.e. what was put on the disc) from the CD entering the DAC
On the other hand, I am hearing a difference between DIN and RCA - and preferring RCA at the moment
Just need to do some more listening tests when I have time...
I don't think jitter is the issue here. Jitter is about picoseconds of timing inaccuracies either side of the nominal frequency. Sometimes the data is early, sometimes it is late - but only by a miniscule margin. This would be avoided by having a 3 word buffer (perhaps this is all Naim do!!) whereby you would always be 1 word behind the input stream.
I don't know the tolerances involved in SPDIF clocks, but what is true is that they won't be EXACTLY 44.1kHz. I'm not going to second guess Naims engineering department on their clock implementation, as I'd need to sit down and redo their design and I'm far better at digital over analogue, but let me quote this from the white paper:
quote:
Naim white paper:
RAM buffer jitter removal
Naim’s buffer or memory method of jitter removal relies on a simple concept: the audio data is clocked into the memory at the incoming, inconsistently timed rate and is then clocked out of the memory and into the DAC chips using a precise clock. The rate at which the memory fills and empties is controlled by selecting the master clock that best matches the average incoming clock frequency. In this way the data entering the DAC chips is completely isolated from the incoming jitter. Only in rare cases will none of the Naim DAC’s selectable master clocks be closely enough matched to the incoming data rate. To cope with this eventuality we have also implemented, as a backup, an asynchronous sample rate converter (ASRC).
I think the thing that is bugging me is that people associate different sounds on the nDAC with jitter performance. I could understand this if the two were in any way coupled, but Naim claim they aren't. Whilst I couldn't hear ANY difference in my test, I'll request my dealer brings a high end transport with him when he comes down. People seem to hear a difference and the only options I can see for that is:
- Placebo effect
- Data isn't bit perfect (i.e. what was put on the disc) from the CD entering the DAC
On the other hand, I am hearing a difference between DIN and RCA - and preferring RCA at the moment
Just need to do some more listening tests when I have time...LOL... Whilst it is obvious, I think it's the first reference to source jitter I've seen anywhere in hi-fi. You've just added another thing that people can misunderstand, and has nothing to do with the replay chain, into the mix...quote:Originally posted by Adam Meredith:
If stating the, logically, obvious rates "very clever" status.
It's OK
I'm technical and prone over elaborating on things (see posts above 
)Who is splitting upquote:Originally posted by pcstockton:
Why are you ripping to one file then splitting up?
...
-Patrick
What I do is rip the whole to a single FLAC file. EAC generates a .cue sheet with it (see below) which my htpc software reads and presents me with the track listing. Clicking on the track the software jumps to that point in the file and begins playing from there. My cue file looks like:
quote:
REM DISCNUMBER 1
REM TOTALDISCS 1
REM GENRE Rock
REM DATE 1998
REM DISCID AD0CB40C
REM COMMENT "ExactAudioCopy v0.99pb5"
PERFORMER "Gomez"
TITLE "Bring It On "
FILE "Gomez - Bring It On.flac" WAVE
TRACK 01 AUDIO
TITLE "Get Miles"
PERFORMER "Gomez"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Whippin' Piccadilly"
PERFORMER "Gomez"
INDEX 01 05:15:55
TRACK 03 AUDIO
TITLE "Make No Sound"
PERFORMER "Gomez"
INDEX 00 08:26:50
INDEX 01 08:27:72
TRACK 04 AUDIO
TITLE "78 Stone Wobble"
PERFORMER "Gomez"
INDEX 00 11:52:25
INDEX 01 11:54:00
...
TRACK 12 AUDIO
TITLE "The Comeback"
PERFORMER "Gomez"
INDEX 00 53:22:00
INDEX 01 53:27:47
and my HTPC software presents this as:
<track #>. <performer> - <title>
so I get a list like:
1. Gomez - Get Miles
2. Gomez - Whippin' Picadilly
3. Gomez - Make No Sound
4. Gomez - 78 Stone Wobble
...
12. Gomez - The Comeback
The advantage of doing this is I get perfect reproduction of continuous CDs (e.g. live albums with crowd noise or more experimental music which meanders from track to track. Gaps where there are gaps, no gaps where there are none.
.cue sheets really are VERY powerful methods of managing your music.
PS. If you're using EAC, I highly recommend REACT which is a wrapper for EAC. I can rip, tag, file and generate a whole set of mp3s for the mp3 player with the following input:
- Insert CD
- Press F10
- Select cover art from the choices presented
- Wait until CD ripped.
I'm doing this for my CDs (about 1/3rd the way through) and it really is a breeze (although it does take a little configuring to start...
quote:The problem I'm having is no one can put one ounce of credible evidence up as to why they should sound different with a DAC designed to eliminate the source of jitter.
Andy, you are currently enchanted by the nDAC design and overestimate it's abilities.
Time will pass and you will definitely re-think your ideas.
A real bitstream is not a sequence of clearly defined lumps & troughs -- its quite a noisy waveform.
It's not only that peaks are not the same height -- the waveform itself is distorted in time-line.
Some neighboring bits get very close to each other and none of the decoding algorithms will tell them apart.
Some neighboring bits have a huge gap between them.
Some neighboring bits get a false lump between them as a result of sporadic noise or echo -- which looks pretty much the same as a real bit.
The high quality transport and cable can sort this out -- but no way stock DVD player comes close to this. If you are a digital engineer just check up the clock from a DVD player on your oscilloscope -- and you will be shocked -- there will be no square pulse waveform as you may expect.
quote:If transports do sound different the only explanation that can I can sensibly derive is that they are not bit perfect.
No. A simple objection is the digital cables. They don't flip the bits and in that sense they should sound all the same through nDAC which is again not the case. Some cables contaminate the original bitstream with noise which can extend the bit slope and mistaken the S/PDIF receiver. The RCA cables contaminate the bitstream with multiple echoes from reflections on resistivity barriers -- and that's why BNC is recommended.
quote:That's the maximum jitter you want in the incoming data stream when you are syncing to it with a PLL.
No, 173 ps has nothing to do with PLL. 173 ps is the maximum jitter which SECURES that all 16 bit can be theoretically resolved. In fact, many CDPs have higher jitter (like 240 ps in CD555) but they run out of the audible band. It works like this: Bitstream 1 has a lot of the sporadically (delayed bits) and Bistream 2 has small amount of "stacked" bits. The total jitter in Bistream 1 is higher than in Bistream 2. But Bistream 1 will sound much clearer than Bistream 2 for a man's ear. In terms of jitter spectrum one can say that Bistream 1 jitter is out of the audio band.
quote:I'd suggest rethinking your position - as you appear confused with the processes that are going on here.
Andy, I'm afraid I clearly understand the difference between bit-perfect and time-perfect processes.
The mistakes which SPDIF receiver makes on input are JITTER-related -- and have nothing to do with bit-perfectness of input bistream. The input bitstream can be BIT-PERFECT -- meaning that all the bits which orginally form the bistream -- are all correct. But due to the imperfection of S/PDIF generator, connector impedance mismathcing, cables effect, noise this leads to overruns and delays in bits and sporadic bit-looking lumps and finally makes nDAC SPDIF receiver MISTAKEN.
Very rarely -- say once in thousand times -- but it's quite audible
quote:Either the CD players aren't reading the discs correctly and covering up the errors differently (hence the source is not perfect in which case bit-perfect rips are the answer) or there is snake oil going on somewhere.
Andy, if CD-reading mistakes is the only explanation for you -- so what about streamers which also sound VERY different through the nDAC? For example, SB3 and TP and HDX and Linn Majik?
Some of what you say is true (you need to treat high speed digital circuits as analogue), some not (bits getting close together/far apart and the system not being able to tell them apart). A SPDIF interface WILL recover all the data correctly. PERIOD If it did NOT do this, the chance of bit flipping would be random and you would equally lose bits in the most significant bits - making HUGE dropouts. We're not talking nuances in sound, we're talking huge dropouts - occurring regularly.quote:Originally posted by AMA:
A real bitstream is not a sequence of clearly defined lumps & troughs -- its quite a noisy waveform.
It's not only that peaks are not the same height -- the waveform itself is distorted in time-line.
Some neighboring bits get very close to each other and none of the decoding algorithms will tell them apart.
Some neighboring bits have a huge gap between them.
Some neighboring bits get a false lump between them as a result of sporadic noise or echo -- which looks pretty much the same as a real bit.
The high quality transport and cable can sort this out -- but no way stock DVD player comes close to this. If you are a digital engineer just check up the clock from a DVD player on your oscilloscope -- and you will be shocked -- there will be no square pulse waveform as you may expect.
The whole point of the DAC is that it gets rid of the jitter induced by the replay system - including the SPDIF interface.
<sigh> What has this to do with the fact the nDAC reclocks the datastream?quote:quote:If transports do sound different the only explanation that can I can sensibly derive is that they are not bit perfect.
No. A simple objection is the digital cables. They don't flip the bits and in that sense they should sound all the same through nDAC which is again not the case. Some cables contaminate the original bitstream with noise which can extend the bit slope and mistaken the S/PDIF receiver. The RCA cables contaminate the bitstream with multiple echoes from reflections on resistivity barriers -- and that's why BNC is recommended.
Nope... There is no point in thinking of BITS here, CD is 16 bit values. They are either right or wrong, and you either convert them to analogue at the right or wrong time. That is the only (I'll say that again - loudly) ONLY time jitter is an issue - when you do the conversion. You should be asking what the jitter at the DAC stage is. That's what matters to the sound, not the jitter of the incoming bitstream.quote:quote:That's the maximum jitter you want in the incoming data stream when you are syncing to it with a PLL.
No, 173 ps has nothing to do with PLL. 173 ps is the maximum jitter which SECURES that all 16 bit can be theoretically resolved. In fact, many CDPs have higher jitter (like 240 ps in CD555) but they run out of the audible band. It works like this: Bitstream 1 has a lot of the sporadically (delayed bits) and Bistream 2 has small amount of "stacked" bits. The total jitter in Bistream 1 is higher than in Bistream 2. But Bistream 1 will sound much clearer than Bistream 2 for a man's ear. In terms of jitter spectrum one can say that Bistream 1 jitter is out of the audio band.
The problem is most DACs sync their DAC clock to this incoming bitstream. The whole point of the Naim DAC is that it decouples the two.
Err... if you do, you aren't applying them properly here..quote:Andy, I'm afraid I clearly understand the difference between bit-perfect and time-perfect processes.
Nope. You don't lose bits across the SPDIF interface. If you did, the system wouldn't work at all as you'd also lose sync bits and information bits carried in the bitstream.quote:The mistakes which SPDIF receiver makes on input are JITTER-related -- and have nothing to do with bit-perfectness of input bistream. The input bitstream can be BIT-PERFECT -- meaning that all the bits which orginally form the bistream -- are all correct. But due to the imperfection of S/PDIF generator, connector impedance mismathcing, cables effect, noise this leads to overruns and delays in bits and sporadic bit-looking lumps and finally makes nDAC SPDIF receiver MISTAKEN.
Very rarely -- say once in thousand times -- but it's quite audible
The mistake other DACs make isn't bit related, but generating the DAC clock from the incoming bitstream in some way. Which bit of the Naim blurb are you finding difficult to understand - they RECLOCK the data - removing jitter. That's why Naim make 1 box CD players - they can control the jitter.
IMHO Naim made the nDAC as they could effectively hook anything up to it and it will sound essentially "the same".
Some streamers aren't bit perfect. If they are, it's the Placebo effect.quote:Andy, if CD-reading mistakes is the only explanation for you -- so what about streamers which also sound VERY different through the nDAC? For example, SB3 and TP and HDX and Linn Majik?
You're the kind of guy who buys an expensive HDMI cable and claims you get a better picture aren't you (serious question)?
Andy S, i am very glad that you did drop by and share youre knowledge about this subject, "hi-end" transports vs cheap dvd-players, alot of people need to know this.
I am sorry to say but Placebo is very very strong on this forum, as you might see
For all of you, do serius blindtests before buying any gear, it might save you alot of cash, especially when talking about digital transports.
I am sorry to say but Placebo is very very strong on this forum, as you might see
For all of you, do serius blindtests before buying any gear, it might save you alot of cash, especially when talking about digital transports.
Thank you.quote:Originally posted by Alive:
Andy S, i am very glad that you did drop by and share youre knowledge about this subject, "hi-end" transports vs cheap dvd-players, alot of people need to know this.
Actually, that's very true - none of these have been blind tests as far as I can tell (although the one I did on my g/f was when we tested the DAC - the DAC won by a country mile - so much so we listened to music all night rediscovering our CD collectionquote:I am sorry to say but Placebo is very very strong on this forum, as you might see
For all of you, do serius blindtests before buying any gear, it might save you alot of cash, especially when talking about digital transports.
)