Why is the nDAC so cheap?

Any one think it might be the level of recording detail and quality?? With so many recording digitally remastered, mixxed ,synthesized information flipped back and forth between the analog /digital domains that perhaps certain combination of transports/sources with the Ndacs are more adept in fault finding. The problem maybe intrinsic with the source material as the Ndac now preceives this in a new light, maybe flawed and flawed in such a way that(no) ther technology is not exposing it in the same fashion.
Like the difference in looking at an object through a microscope at 50x power versus 250x power, you see more of the good and the bad. Possibly different combinations of the NDac and "transport" bring this to light more than others all centered around the abilities of the Ndac. So what we are now perceiving in not just the system which we hold suspect, but we are finding, at times new faults with the recording.

This is why so many people have so many different results considering other variables such as power supplies, room accoustics etc etc.
The virtually new technology is exposing potential weakness previously there, but not yet unrevealed or magnified.

quote:

Can someone explain at a technical level why they might sound different?

Andy, I can. I think after numerous trials I found out how to plot this in a brief and clear way

First of all: Naim never claimed nDAC would remove jitter completely from the input bitstream. They are very accurate in wording: they say 1. nDAC will not introduce the new jitter and 2. nDAC will do a hard job to reject a significant part of input jitter. Both claims are correct.

The problem happens at nDAC SPDIF receiver. Once the next bit is received -- one can be sure it will be properly stored in RAM and then sent (in due time specified by super-fine clock) to D/A chip via I2S. This means nDAC does not introduce NEW jitter. But let's come back to the moment when the next bit was about to be received by nDAC SPDIF generator. If income bitstream jitter is high it looks as the anomalously high/low time gaps between the next bits. In both cases the nDAC SPDIF receiver may be mistaken and count 1 instead of 0 (or reverse). For example it may treat 11 pack of close-in-time bits as a single 1 bit and then after some time (when no new bit is not coming and the allocated waiting time is expired) it will set the second bit as 0 and finally get 10 instead of 11.
Since that moment the wrong bits will continue traveling through nDAC flawlessly.
All hi-end DAC manufacturers pay HUGE attention to intellectual SPDIF receivers which can identify bits reliably. Naim never liked SPDIF interface and still not uses standard SPDIF solution -- as far as I got it from white paper they developed their own SPDIF generator/receiver. I think there is a simple explanation of Naim HDX/CDX2-2 synergy with nDAC as they use the same SPDIF solution which minimize the jitter issue in the chain. But if any other transport has a low output jitter this will work with nDAC just fine -- and may outperform original Naim CD-transports -- why not?

The good point is that if two different transports produce very-low-jitter bitstream then they will sound the same through nDAC because every single bit will be resolved at the entrance.

The bad point is that we are talking about < 173 ps jitter transports (if we talk about 16/44 PCM) which we almost don't have on the market.

I believe that in near future computer-based solutions like streamers, USB/Firewire interface will manage to reach this point and make all the transports sound the same through the nDAC. These USB/Firewire interfaces should be decoupled from the noisy computer storage, they should be supplied with liner PS and use super-fine clocks. I would love to see jitter analysis of Weiss INT202 for example.

For Hi-Res the jitter threshold is much lower than 173 ps and I believe the transport games will run longer than for 16/44 -- but eventually they will do it as well.

quote:

Originally posted by Andy S:

quote:

Originally posted by fatcat:
The same rule applies to streamers as CD transport. There are both high and poor quality streamers.

True. But only if they mess with the data before output. For example, my XP machine won't output 44.1 over SPDIF but will via USB. It sounds a LOT better via USB than SPDIF. Bit perfect streamers should (will?) all sound the same... They should (will?) only sound different if they mess with the data and this will be a software/driver issue. It IS possible to get bit-perfect output cheaply. I';;d be quite happy to stack my £200 HTPC/nDAC with XPS against the highest end transport you care to provide/nDAC/XPS any day.

Just a question Andy.

Is what comes out of one end of a digital cable always exactly the same (in voltage levels, noice levels, timing, etc) as what went into the cable? Likewise for the SPDIF-encoder and SPDIF-decoder?

-
aleg

quote:

Originally posted by AMA:
First of all: Naim never claimed nDAC would remove jitter completely from the input bitstream. They are very accurate in wording: they say 1. nDAC will not introduce the new jitter

Yes - I agree with what you say here.

quote:

Originally posted by AMA:
and 2. nDAC will do a hard job to reject a significant part of input jitter.

Where have you read that? The mechanism in use rejects ALL jitter from the transmission medium.

Both claims are correct.

quote:

Originally posted by AMA:
The problem happens at nDAC SPDIF receiver. Once the next bit is received -- one can be sure it will be properly stored in RAM and then sent (in due time specified by super-fine clock) to D/A chip via I2S. This means nDAC does not introduce NEW jitter. But let's come back to the moment when the next bit was about to be received by nDAC SPDIF generator. If income bitstream jitter is high it looks as the anomalously high/low time gaps between the next bits. In both cases the nDAC SPDIF receiver may be mistaken and count 1 instead of 0 (or reverse).

No. This CANNOT happen as you would likely lose bits anywhere in the word and the incoming datastream would be full of pops and clicks. The SPDIF receiver will generate the correct bitstream if it is synced because it is pulling out the clock from the arriving data. Guaranteed.

quote:

Originally posted by AMA:
Since that moment the wrong bits will continue traveling through nDAC flawlessly.

No. The bits will be the correct bits. As I said above, if the receiver is sync'd on the incoming bitstream, the data is bit perfect.

quote:

Originally posted by AMA:
All hi-end DAC manufacturers pay HUGE attention to intellectual SPDIF receivers which can identify bits reliably.

They concentrating on reducing jitter. Getting the right data back out of the bitstream is relatively easy.

quote:

Originally posted by AMA:
Naim never liked SPDIF interface and still not uses standard SPDIF solution -- as far as I got it from white paper they developed their own SPDIF generator/receiver.

Yes, they did this as they believe it reduces RF interference, not because their solution can get more accurate bits out of the SPDIF.

quote:

Originally posted by AMA:
I think there is a simple explanation of Naim HDX/CDX2-2 synergy with nDAC as they use the same SPDIF solution which minimize the jitter issue in the chain.

Sorry, but with respect, the RAM reclocking zeros any chain jitter. You are mistaking inaccurate bit transmissions and confusing that for jitter. The two are NOT the same.

quote:

Originally posted by AMA:
...
The good point is that if two different transports produce very-low-jitter bitstream then they will sound the same through nDAC because every single bit will be resolved at the entrance.

The bad point is that we are talking about < 173 ps jitter transports (if we talk about 16/44 PCM) which we almost don't have on the market.

And where did you get that number from???? You would need to know the specs of Naims internal implementation to translate an external ps figure into something the DACs can lock onto and then utilise the internal RAM buffering.

Sorry, but you really are confusing jitter and data recovery. The two are two completely distinct (and orthogonal) problems. If the DAC can lock to the incoming signal and the DAC is working as advertised, it won't matter what is feeding it as long as it is a bit perfect copy of the stream.

quote:

Originally posted by Aleg:
Just a question Andy.

Is what comes out of one end of a digital cable always exactly the same (in voltage levels, noice levels, timing, etc) as what went into the cable? Likewise for the SPDIF-encoder and SPDIF-decoder?

-
aleg

As far as digital values are concerned (and assuming a reasonable cable) - yes. The problem is that the current implementations of DACs syunc to the stream and generate the DAC clock from it. This is bad and introduces jitter as cables aren't perfect. Because the analogue transmission (the SPDIF waveform can be considered analogue) isn't 100% accurate, this leads to instabilities in the CLOCK of the DAC.

Naim claim to have eliminated this with the RAM buffer/high precision clocks, so this clock instability is eliminated in the DAC replay chain. Effectively, as long as you can recover the bits from the interface and it's within their matched clock specs, the system won't care what is feeding it the info. This is why my mates cheapo USB->SPDIF card works as well as his CDS3 head end as a transport...

Just as an addendum. This is what Naim say from their white paper:

quote:

by Naim white paper:
How to overcome the problem of S/PDIF induced
jitter
In the Naim DAC the master clock is not recovered from
the S/PDIF signal as usual. Instead the audio data is
read from S/PDIF, stored in solid-state memory and then
clocked back out to the DAC chips using a fixed-frequency
local master clock. This eliminates jitter caused by S/PDIF.

quote:

Originally posted by Andy S:
Just as an addendum. This is what Naim say from their white paper:

quote:

by Naim white paper:
How to overcome the problem of S/PDIF induced
jitter
In the Naim DAC the master clock is not recovered from
the S/PDIF signal as usual. Instead the audio data is
read from S/PDIF, stored in solid-state memory and then
clocked back out to the DAC chips using a fixed-frequency
local master clock. This eliminates jitter caused by S/PDIF.

Transports sound different on it. Macs sound different on it. The bit perfect thing I don't buy. I can measure bit perfect using the same interface from a Mac for iTunes, Pure Music and Amarra - the latter two taking over the audio presentation from iTunes/OSX.

They all measure bit perfect and all sound different. You can go into these comparisons not believing they 'should' sound different but they do. Just as Richard as described in the transport thread.

Joe

How big is the RAM buffer on the Naim DAC - is their an appreciable delay after pressing play on the transport ?

Does the DAC indicate if it can't match a clock to the incoming data rate and has fallen back to using ASRC ?

James

The bitperfect thing seems to me a kind of audio myth, I was attracted to computer audio just because of it, following the idea of "with a few tweaks any cheap PC can output bitperfect digital audio and then all you need is a good DAC". Well IMO this is not true, there is a never ending list of tweaks, everything matters in the long computer audio chain (even defragmenting the hard disk!)... but it is also true that a standard digital output through both a PC/Mac can give outstanding results and makes any expensive CDP offer poor vfm.

The zero jitter Naim nDAC can't be interpreted as total inmunity to source used, IMO these marketing claims can induce to wrong beliefs, not because Naim could be blamed of deceptive advertising but just because these digital audio topics are very confusing per se.

hi, my 2 cents...
i think the Ndac is the "entry" system... a bigger could (maybe) follow .....reference class + integrated streamer?
but right now, the Ndac is already superb :-)
ralf

quote:

Originally posted by james n:
...
Does the DAC indicate if it can't match a clock to the incoming data rate and has fallen back to using ASRC ?

James

Yes, the sync light will turn off, indicating none of its fixed clocks match the incoming signal.

Well, I've just spent 40 minutes playing with my htpc with ripped audio from the CD (accurate rip says the rips were accurate) and a cheapo DVD player into the nDAC with a variety of different source material. One connected via Optical, the other via SPDIF.

Side by side, same track at the same time, I can't tell them apart. At ALL.... No difference to me, nada, nothing.

If the price of the transport is that much of an indicator, then these should sound different - after all, a £130 PC motherboard (incl processor and graphics chip and wi-fi) and a 5 year old cheap Sony DVD player are very unlikely to have the same jitter/noise characteristics (especially since they are connected through different physical mediums) so should sound different according to all that has been said in this thread.

I'll get my dealer to bring over a reference transport (he is bringing back my modded burndy when it arrives from Naim). I'll prepare myself for the "biased/cloth eared/you don't know what you are talking about" after the dem.

The nDAC really does change things for cheap sources/streaming audio IMHO.

quote:

No. The bits will be the correct bits. As I said above, if the receiver is sync'd on the incoming bitstream, the data is bit perfect.

Andy, no it's not.

I shall not go far in this discussion -- as I have already put many different words on this subject during the last year. You can search the forum.

Or better check this with digital engineers whom you trust. You may wish to pay visit to Naim factory and ask the same question directly.
Then re-read my post again

And YES -- today I clearly hear the difference between transports on nDAC.

But I shall not be surprised to see future generation of PC-based transports will sound the same.

quote:

Originally posted by T38.45:
hi, my 2 cents...
i think the Ndac is the "entry" system... a bigger could (maybe) follow .....reference class + integrated streamer?
but right now, the Ndac is already superb :-)
ralf

Hi Ralf,

Yes, I totally agree. The marketing blurb from Naim is very careful. They say the nDAC uses the same DACs as the 555 CD player. They don't say that they are used in the same configuration as the 555

quote:

And where did you get that number from????

Andy, with my full respect: if you never heard this number -- I don't think you are a professional digital engineer -- at least in the area of digital audio. Just go to pfm or many others digital forums. There are many white papers on 173 ps. It takes one minute to calculate this figure -- you can find it here on Naim forum as well -- just do a search with "173" Or go this link.

quote:

Originally posted by AMA:
Or better check this with digital engineers whom you trust.

I am a digital engineer who I trust.

Building a/v consumer electronics - both at a hardware and software level is my day-to-day job and has been for the last 15 years....

Andy

quote:

Originally posted by AMA:

quote:

And where did you get that number from????

Andy, with my full respect: if you never heard this number -- I don't think you are a professional digital engineer -- at least in the area of digital audio. Just go to pfm or many others digital forums. There are many white papers on 173 ps. It takes one minute to calculate this figure -- you can find it here on Naim forum as well -- just do a search with "173" Or go this link.

Sorry AMA... That's the maximum jitter you want in the incoming data stream when you are syncing to it with a PLL. It does NOT relate to the ability to pull bits out of the bitstream. You can get the bits out 100% accurately - google "biphase mark code" for an explanation of how SPDIF works at the encoding level. It doesn't even need to be that accurately clocked to get the data out!

It does not relate to anything meaningful to a DAC that claims to completely eliminate jitter at the SPDIF interface.

quote:

Originally posted by AMA:
Or go this link.

AMA, with respect, that post you just pointed me at essentially says the same thing I am saying.... SPDIF will get the data correctly, it just may not get it at the right time (which is jitter).

I'd suggest rethinking your position - as you appear confused with the processes that are going on here. What you appear to be saying contradicts most peoples understanding of the mechanisms going on here. And if you aren't going to question your stance, there is little more that I can add to your understanding.

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.

Anyone who claims that all transports will sound the same through the nDAC, should have a read of the thread I started regarding some tests on the various CD & DVD players I had around the house. I'm still experimenting, but so far there are clear and unequivocal differences. In fact, right now I have a DVD5 and a Meridian CD hooked up and the difference between them is far from subtle. If you don't believe me, I'd love to say, come and listen for yourself!

Thinking it may just be the very high resolution of the pre/power I normally use, I replaced them with a NAC62 and NAP110 from another system. Same result (and shockingly good into my SL2s, I must say).

Please don't ask me to explain why. However, a clue may be in a post I made a couple of days back regarding a conversation I had some years ago with one of the engineers at Naim where they tried to explain about noise modulation into the signal bitstream. Who knows? All I do know for sure is that the differences are clearly there, and the better two transports (the Meridian and DVD5) are clearly better than the others. Optical connection may change this and level the field, but I have yet to try this out. I have also only used the nDAC with signal ground connected - as recommended for single source operation.

Richard,

Many people have reported similar findings. Clearly transports do have an effect.

quote:

Originally posted by Andy S:

quote:

Originally posted by AMA:
Or better check this with digital engineers whom you trust.

I am a digital engineer who I trust.

Building a/v consumer electronics - both at a hardware and software level is my day-to-day job and has been for the last 15 years....

Andy

And clearly you lack humility. I doubt you know it all and clearly you dont uderstand so why not just keep an open mind and try and learn something new...

quote:

Originally posted by Richard Dane:
If you don't believe me, I'd love to say, come and listen for yourself!

I live in Trowbridge, West Wiltshire and if you live anywhere close, I'm sure this could be arranged if you are serious. You could come up here too with whatever transport you want to bring and compare it against a bit-perfect htpc...

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. 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.

quote:

Originally posted by positive_energy:
And clearly you lack humility. I doubt you know it all and clearly you dont uderstand so why not just keep an open mind and try and learn something new...

I'm totally open to learning something new, but there has to be more behind it other than "it does".

quote:

Originally posted by Steve O:
I have yet to achieve a bit perfect EAC rip - my EAC rips always show some errors.

This is what I have for a rip on Dark Side of the Moon at 15x read:

quote:

Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 5. May 2010, 11:31

Pink Floyd / The Dark Side Of The Moon

Used drive : _NEC DVD_RW ND-3520A Adapter: 3 ID: 0

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : No
Make use of C2 pointers : Yes

Read offset correction : 48
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : No
Used interface : Native Win32 interface for Win NT & 2000

Used output format : User Defined Encoder
Selected bitrate : 768 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Program Files\REACT2\REACT.exe
Additional command line options : REACT %o %s %d "%a" "%g" "%t" "%n" "%x" "%y" "%m" "%e" "%f" "%b" %r


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.33 | 3:57.60 | 33 | 17867
2 | 3:58.18 | 3:35.00 | 17868 | 33992
3 | 7:33.18 | 7:04.60 | 33993 | 65852
4 | 14:38.03 | 4:47.05 | 65853 | 87382
5 | 19:25.08 | 6:22.35 | 87383 | 116067
6 | 25:47.43 | 7:50.20 | 116068 | 151337
7 | 33:37.63 | 3:25.50 | 151338 | 166762
8 | 37:03.38 | 3:50.37 | 166763 | 184049
9 | 40:54.00 | 2:01.18 | 184050 | 193142


Range status and errors

Selected range

Filename C:\Documents and Settings\Andy\My Documents\My Music\Pink Floyd - The Dark Side Of The Moon.wav

Peak level 100.0 %
Range quality 100.0 %
Copy CRC A7A3F757
Copy OK

No errors occurred


AccurateRip summary

Track 1 accurately ripped (confidence 200) [1BA21A87]
Track 2 accurately ripped (confidence 200) [76FFD972]
Track 3 accurately ripped (confidence 200) [B999E41B]
Track 4 accurately ripped (confidence 200) [86FED59C]
Track 5 accurately ripped (confidence 200) [296A9C2B]
Track 6 accurately ripped (confidence 200) [166151D2]
Track 7 accurately ripped (confidence 200) [7745D608]
Track 8 accurately ripped (confidence 200) [5B7408C2]
Track 9 accurately ripped (confidence 200) [3AF089E0]

All tracks accurately ripped

End of status report

I'm ripping the whole CD into a single file and then using the generated cue sheets to drive the HTPC. This way, with files that are live albums or continuous music, you don't get breaks across the tracks.

The AccurateRip statistics at the bottom show that at least 200 other people have ripped this CD and got exactly the same checksum I have for that track therefore it is highly likely that I have a completely bit perfect rip of the CD.

As to what's causing your problems, I really have no idea and would need to be in front of the computer to help out I think... Note: the settings to use on EAC for the drive will be completely drive dependant, so don't just blindly follow my settings!

You are using the latest EAC aren't you....