Why is the nDAC so cheap?

quote:

Originally posted by fatcat:
It only eliminates TIMING jitter. Any other jitter present in the audio data enters the memory and leaves the memory, although it does so at a very precice rate.

What other sort of jitter in the audio data is there

quote:

Originally posted by Joe Bibb:
You seem to be on your own with this, I accept you are reporting what you find. But plenty of people here have been through this with plenty of DACs. Benchmark made the same case for the DAC1 yonks ago.

Let me state that I'm not saying ALL DACs are source tolerant, just this one. Let me also ask - is my mate wrong (you know who you are John ) who decided that cheap PC USB card was equivalent to a CDS3? We have both had reasonable-high end Naim systems for 10-15 years - we "know" the sound and what different Naim components do. Both of us were blown away by how good the DAC was for its price (which, after all was my original point of the thread)...

quote:

There is plenty I would (and have) criticised Naim for, over-priced power supplies and CD players - you name it. Including making this claim (although I thought they said "minimised" in the white paper, but no matter). In practice it isn't what I or others have heard. I don't trust measurements - too many things that measure well don't sound like it.

You know... I wouldn't mind if someone could come up with a credible way the sound could be affected. I'll restate - I CAN easily hear differences between cables connecting the DAC to the 52. What I can't do is hear any differences between cheap sources and USB sticks. I'm not into measurements either. As I said, I'll try a high end source when I get my Burndy back, but if it makes a difference - Naim have done a bad implementation of a very good design

quote:

Originally posted by james n:

quote:

HTPC, cheap DVD, USB. No difference between any of them

Ok - so try a decent transport and then tell us if you can hear a difference between that and the cheap DVD player.

Given that some people claim USB is the "best" source - why doesn't that count in my trials?

quote:

Originally posted by fatcat:
I wonder if analogue aficionados are more sensitive to changes in the Naim Dac front end. After all, our brains are tuned to listen to the music not the sound.

Yessss... Defending a position based on clique. I must remember that and try it at my next project meeting....

Of course, the opposite position is that you might be more gullible... But I'd never accuse you of being that...

quote:

quote:
HTPC, cheap DVD, USB. No difference between any of them



Ok - so try a decent transport and then tell us if you can hear a difference between that and the cheap DVD player.

James, nDAC USB is a very good transport, possibly not the best -- but definitely on the top side.
If it does not make a difference to him then it's all done -- further tests will not change anything in his perception of transport value.

I don't agree with some of his (key) technical statements -- for example, he believes SPDIF receiver is never mistaken on reading the input bits.

But we obviously can't oppose his inability to discern the nuances in different transports. He honestly shares his observations and I treat them with trust and respect.

I like this thread

quote:

Originally posted by Joe Bibb:
You seem to be on your own with this, I accept you are reporting what you find.

Sorry, just to come back on this.

You know, I don't think I am. I think there are plenty of people who don't hear a difference, but probably feel intimidated about reporting that fact as they can easily be shouted down due to "jitter" or "losing bits" or "conversations with Naim engineers" or any of the other vague reasons that have been posted (and I believe discredited) on this thread. The mantra that transport matters (and it does with other less well designed DACs) just gets repeated until it is folklore such that it matters with this DAC too, and if you don't hear it too, then what can be wrong with your system/ears. Imagine if you didn't feel technically competent to argue your position. Perhaps it might just be easier to go with the flow........

Of course, they could all just be listening to the incredible sounds and not bothering with this thread at all

quote:

Originally posted by AMA:
for example, he believes SPDIF receiver is never mistaken on reading the input bits.

Please show me a credible technical reference where it loses bits. I'm prepared to eat humble pie and learn here... But I'd like you to have the same position...

Andy, I'm afraid I can't give you a technical argument here because I don't have the credentials to do so. What I do know is that I hear what I hear - as does everybody who has also listened in on the transport tests I undertook. I even did a blind test just to be sure that it definitely wasn't a placebo effect. The differences were obvious and clear. I cannot see how this result could be considered as "discredited".

I don't dispute that you may not hear any difference. Indeed, so far the poorer transports have sounded pretty similar and hard to tell apart. However, the best two were easy to spot (despite both having distinct differences between even each other!).

It would be nice to get some R&D input here, especially to clarify the discussion regarding how noise modulation/demodulation affects performance, but I also know they're always extremely busy, so don't hold your breath. My usual strategy has been to discuss such issues over a coffee break or at lunch, but as I'm not at Naim HQ any more, this is no longer possible. Which is a shame, but no doubt something of a relief for them all...

You mentioned earlier that you have an open mind, so let's all keep our minds open...

Andy,

lets bottom line it for you.

Possible options in lieu of "proof" you will accept.

1) Everyone who hears a difference is wrong or lying.
2) They are right but those who disagree neither have the ears nor the system to resolve it.
3) Naim is wrong about how their DAC works.
4) Naim is miscommunicating how the DAC works.
5) YOU are misinterpreting the white paper.


Lets just say for fun that Naim is wrong and their DAC does NOT reject all unwanted jitter, noise or whatever.....

Nevertheless, it is still an amazing DAC.

We are ALL agreeing here that we like the DAC right???? So whats to argue about.

You cant hear a difference. Others can. Why do you require those people to prove anything to you? Who cares?

Lastly, what exactly is written (yes ive read it) in the White Paper that leads you to believe ALL sources will sound identical? I dont think that is said, intimated or implied.

Is it possible (Occam's razor time!) that you are misunderstanding what the reclocking entails? Maybe you are not understanding the white paper?

How could Naim possibly say the source doesn't matter then go ahead and outfit two CDPs with digital output? Apparently they thought the CDX2 was a better transport than the CD5X? right?

quote:

Originally posted by Andy S:

quote:

Originally posted by AMA:
for example, he believes SPDIF receiver is never mistaken on reading the input bits.

Please show me a credible technical reference where it loses bits. I'm prepared to eat humble pie and learn here... But I'd like you to have the same position...

No problem. Cheap DVD clocking is poor (you can check this with oscilloscope). The pulsations often go too close or too far from each other which is called a "clock jitter".
Now it may clock one bit at due time but the next bit can be clocked too early so it makes up two consequent bits to travel with very small time-gap. If you run receiver at very high frequency it can tell them apart. But I would love to hear how are you going to explain nDAC receiver (which works with standard clocks only) can resolve them?

quote:

Originally posted by pcstockton:
Possible options in lieu of "proof" you will accept.

You miss my point. I don't need proof - all I'm doing is questioning HOW a difference could happen. Noone can explain that, and I'm sorry, it doesn't help when people explain their beliefs based on unscientific "facts" and misinterpretations they have of the information given to them.

quote:

1) Everyone who hears a difference is wrong or lying.
2) They are right but those who disagree neither have the ears nor the system to resolve it.
3) Naim is wrong about how their DAC works.
4) Naim is miscommunicating how the DAC works.
5) YOU are misinterpreting the white paper.

All are possible. All I'm doing is asking questions to try and narrow down which one is the case here.

quote:

Lets just say for fun that Naim is wrong and their DAC does NOT reject all unwanted jitter, noise or whatever.....

Nevertheless, it is still an amazing DAC.

We are ALL agreeing here that we like the DAC right???? So whats to argue about.

Yup. It is an amazing DAC. I was the original poster and posed the question "why is it so cheap?".

quote:

You cant hear a difference. Others can. Why do you require those people to prove anything to you? Who cares?

I don't care if people hear things differently to me. What I'd like to do is stop the "it does, but I can't explain it" or even worse the "it does, and I'm going to explain it on flawed science". I'd also like to learn what DOES make a difference. I learned a lot on the original Naim forum and have always been interested in how the sytems I use work. Why do they sound better - what makes the difference.

quote:

Lastly, what exactly is written (yes ive read it) in the White Paper that leads you to believe ALL sources will sound identical? I dont think that is said, intimated or implied.

The difference in transports is in how accurately they can deliver the data (assuming bit perfect reading). The ONLY interaction that can happen with an optically coupled system (i.e. toslink) is the jitter in the data. The Naim DAC claims to remove the jitter - what other conclusion can you have that different transports will sound the same? Naim themselves will NEVER claim that different sources sound the same. It's bad marketing to do so.

quote:

Is it possible (Occam's razor time!) that you are misunderstanding what the reclocking entails? Maybe you are not understanding the white paper?

Yes, clearly. But I've been asking for mechanisms as to how it could sound different and no one can explain it to me.

quote:

How could Naim possibly say the source doesn't matter then go ahead and outfit two CDPs with digital output? Apparently they thought the CDX2 was a better transport than the CD5X? right?

The other way of looking at it is that the nDAC is better than both the CDX2 and CD5X. Consequently, the nDAC is an UPGRADE to either. You start with a good CD player and can upgrade it. What they don't tell you is that it would sound just as good (IMHO of course ) with the cheap CD transport and the nDAC - AND it's cheaper. Not really a good marketing ploy is it?

quote:

Originally posted by AMA:
No problem. Cheap DVD clocking is poor (you can check this with oscilloscope). The pulsations often go too close or too far from each other which is called a "clock jitter".

No. Clock jitter is where the edges of the clock cannot be resolved exactly. This is because it takes time for the signal to go from 0 to 1 and depending on the electronics, this can be slow or fast. What you are missing is that this doesn't displace the bit, it displaces the point at which the clock is registered at going from 0 to 1. Let's put this in perspective. A 44.1kHz 16 bit stream has 44100 x 16 x 2 bits of data per second. Let's double this for the control information overhead. That is a data stream of around 3Mbits/second. At 3 Mbits/second, that's about 300ns (1/3000000) per bit. Now, the level of jitter you mention a couple of times in this thread is 176ps. That is about 0.05% of the bit being sent. We are talking tiny, tiny differences - nowhere near enough to misread bits.

The problem is that a "normal" DAC syncs to this incoming signal by something known as a phase locked loop. This is a system that keeps two very close frequencies in lock but is prone to changing the receiving frequency slightly. This is what causes jitter to be apparent in the DAC clocks.

quote:

Now it may clock one bit at due time but the next bit can be clocked too early so it makes up two consequent bits to travel with very small time-gap. If you run receiver at very high frequency it can tell them apart. But I would love to hear how are you going to explain nDAC receiver (which works with standard clocks only) can resolve them?

I'm sorry, but you really aren't understanding how the system works - and you haven't given me a reference to a credible (i.e. external) source which supports your claim.

Really, I suggest you read and re-read what I've writen above. I'm not trying to be clever or rude, but unless I was in front of you with some paper, I don't see how I could explain to you more clearly how flawed your assumptions are.

Well this is just about as boring as it gets.... Cheers Andy! It's your thread so i suppose you can ruin it.

Im done reading about this. No amount of white papers or your proclamations will convince my ears (or others') otherwise. (please do keep in mind that I cannot hear a diff in my sources).

Just as no one will be able to explain to you what you want to hear.

You are asking a bunch of music lovers to explain to you how complex electronics work. It isnt going to happen. You can simply sit back and smugly know you are right and all others are halluncinating, lying or self deceived.

But I hardly see a point in your quest. Are you trying to get everyone to proclaim that they were in fact lying or wrong? Do you want to be exalted as the master of DAC arguments?

Good luck on your tireless (tiring) quest to rid the world of bad science.

I feel that there should be no difference between FLAC and WAV replay. I dont think different levels of FLAC compression makes an audible difference. Yet MANY do. At first I took your same stance on that. Now I just assume I dont have to worry about that portion of replay. I have listened (yes through the Naim DAC) to every codec I would consider and once again found the results to be the same. I cant hear a difference.

But you will no longer find me arguing endlessly about the subject. no one is going to convince anybody with words when it does comes to the perception of sound. Never.

It's not like any ANY SINGLE PERSON who reads this thread will stop thinking the USB input sounds better.

Instead why dont you use your experience and wisdom to help the people get the best from what they are using and the methods and processes attached, rather than constantly question their experiences.

Clearly you feel that no one knows as much as you do about this subject. So why are you discussing it with us?

You are starting to remind me of an aquiantence of mine. I watched him beat a 5 year old at a child's game (connect 4) repeatedly as if it was a serious event with titles, fame and money on the line.

We get it. there are people who think one way, and a group that feels otherwise. It isn't going to be proven by any science (flawed or sound), from us mere digital mortals.

Out,
Patrick

quote:

Originally posted by pcstockton:
Instead why dont you use your experience and wisdom to help the people get the best from what they are using and the methods and processes attached, rather than constantly question their experiences.

Because I feel the way of getting the best out of your system is understanding how it works and then questioning how can I make it better.

It's a shame you feel so resigned. Perhaps the fact I haven't been around here for a number of years and I'm so enthused by the nDAC goes some way to accounting for my posts

Very interesting thread.

When the white paper first came out, my interpretation was that the DAC would be a great leveler of transports, with perhaps a few exceptions.

First, there was Naim's recommendation that the BNC inputs would sound better than either S/PDIF or Toslink.

Second, there was the warning about using computers as transports. Toslink was recommended to avoid injecting electrical noise into the DAC's sensitive circuitry.

Third, there was Dave Dever's comment (I believe shared by some others -- JS perhaps?) that BNC input #1 sounded better than the other inputs.

Still, given what the white paper said about buffering and re-clocking, it did seem like most transports should sound (if not the same, then) very good.

Then came the Naim public demos and a consensus among attendees that Naim CD transports sounded much better than iPods when connected to the DAC. This was followed by almost every early DAC owner posting that they heard differences between their transports.

So then I bought the DAC, and an XPS, and hooked up three different transports. And heard differences. To confirm what I heard, I asked my wife and her girlfriend to be blind testers. They heard the same differences that I did (and no, I did not coach them).

Now fast forward to the present, where Andy has made a very persuasive argument that seems to refute what I, and many others, are hearing. Of course, the foundation of his argument is the design as described in the white paper. So now I am wondering if the white paper perhaps does not tell the entire story. Could there be undocumented details in the design, or limitations in the components, or processor edge conditions that could perhaps explain why theory and reality (for most) do not seem to be matching up? Is it possible that different transports can generate varying degrees of noise such that when connected via digital coax, they (like a computer) could be effecting the DAC's ability to produce uniform (i.e., it's best) sound?

Would hate to see this issue go unresolved. Hopefully we do hear from Naim R&D. Am not so cynical as to think Naim is knowingly selling a $5600 CD player that, when used as a transport to the DAC, offers no sound quality advantage over a $300 DVD player. Would be very disappointing to learn otherwise....

Hook

quote:

At 3 Mbits/second, that's about 300ns (1/3000000) per bit. Now, the level of jitter you mention a couple of times in this thread is 176ps. That is about 0.05% of the bit being sent. We are talking tiny, tiny differences - nowhere near enough to misread bits.

Andy, 300 ns is correct figure -- but it's a HUGE time gap in a bitstream.
16/44 specifies that a bit front should not drift for more than 173 ps -- in order to secure that every bit will be resolved. If SPDIF-generator clock is not good enough then bits will float which result in SPDIF receivers (working on standard PCM frequencies) to make mistakes constantly. Those bits which were not too close or too far can be resolved through "PLL tracking mechanism", more cases can be resolved through "re-clocking mechanism" (like nDAC) as it does not "track in average" but addresses eahc and every input bit individually. Re-cloking idea is clever -- it splits the pre-D/A processing into two stages: 1 receiving a bit and storing in into memory, 2. clocking the bit with nDAC super-fine clock to D/A. The second is obviously superb -- as someone mentioned it runs below 15 ps (which is still not enough to resolve 24/192). But the first stage is the key: nDAC SPDIF does make mistakes for high jitter bitstreams. The "unlucky" flipped bit can be synchro, low/high level, left/right channel -- everywhere. This all creates a mud which is audible. It's not that dangerous as you suggested in the previous posts -- it does not ruin the sound completely -- it just sounds as a mud and harshness.

That's why transports which clock data precisely sound fantastic through nDAC and those who make lot's of sporadic time-shifts sound muddy through nDAC.

But if you don't hear a difference between cheap DVD tosslink and nDAC's USB source -- then I have no words left -- because to my ears they sound as very different.
Try some tracks with classic guitar (with fast attacks) -- nDAC USB will excel on them.

quote:

Originally posted by AMA:

quote:

At 3 Mbits/second, that's about 300ns (1/3000000) per bit. Now, the level of jitter you mention a couple of times in this thread is 176ps. That is about 0.05% of the bit being sent. We are talking tiny, tiny differences - nowhere near enough to misread bits.

Andy, 300 ns is correct figure -- but it's a HUGE time gap in a bitstream.
16/44 specifies that a bit front should not drift for more than 173 ps -- in order to secure that every bit will be resolved. If SPDIF-generator clock is not good enough then bits will float which result in SPDIF receivers (working on standard PCM frequencies) to make mistakes constantly. Those bits which were not too close or too far can be resolved through "PLL tracking mechanism", more cases can be resolved through "re-clocking mechanism" (like nDAC) as it does not "track in average" but addresses eahc and every input bit individually. Re-cloking idea is clever -- it splits the pre-D/A processing into two stages: 1 receiving a bit and storing in into memory, 2. clocking the bit with nDAC super-fine clock to D/A. The second is obviously superb -- as someone mentioned it runs below 15 ps (which is still not enough to resolve 24/192). But the first stage is the key: nDAC SPDIF does make mistakes for high jitter bitstreams. The "unlucky" flipped bit can be synchro, low/high level, left/right channel -- everywhere. This all creates a mud which is audible. It's not that dangerous as you suggested in the previous posts -- it does not ruin the sound completely -- it just sounds as a mud and harshness.

I'm sorry, but you are mixing two completely different things and coming up with a theory to suit your perceptions. It is a completely incorrect theory, but for some reason you seem to be clinging on to it. I'll say this once more: there is a difference as to resolving the bits (i.e.converting them to analogue with enough resolution) and recovering the bits out of the bitstream. SPDIF is a secure transmission medium - period. What you put in one end, you will get out the other - period. What you won't be able to do is recover the timing information 100% accurately - and it's that problem the reclocking overcomes.

You have to think of the data stream as a collection of 16 bit words NOT as single bits. The process is something along the lines of:

For channel = 1 to 2
For bit = 1 to 16
capture bit
put bit in correct place in 16 bit word
End (for bit)
write 16 bit word to buffer
End (for channel)

The "capture bit" line is the place where jitter is seen - there is no concept of bits moving a little bit and being unable to be captured correctly. Go and read up on Manchester Encoding or bi-phase encoding (which is used in SPDIF) and see why. The data stream is ALWAYS reliably recovered as it is DESIGNED to be able to be recovered through the encoding mechanism without reference to the original clock. I'll say it once more: the ONLY thing that can't be reliably recovered from the datastream is the precise clock. The nDAC replaces this clock recovery with a complete reclock of the data with a clock that is decoupled from the transports clock before it is put into the DAC chain - in other words it removes the effects of upstream jitter. Period.

quote:

That's why transports which clock data precisely sound fantastic through nDAC and those who make lot's of sporadic time-shifts sound muddy through nDAC.

Bzzt... nope. You're coming up with theories that don't fit real life - and using them to justify your perceptions. If you'd like to point me at a credible external reference that supports your thinking, then please do. If you can't (and I suspect you won't since it isn't how jitter affects sound in other DACs which don't reclock the data - you're close, but you still have some key misunderstandings ) please stop using this argument as to why the nDAC sounds different to you. You are confusing people and, more importantly, spreading misinformation which may become internet fact just through being repeated often enough.

quote:

Originally posted by ghook2020:
Then came the Naim public demos and a consensus among attendees that Naim CD transports sounded much better than iPods when connected to the DAC.

To be honest, I'm not surprised. Music on iPods is generally lossily compressed. Unless you have bit equivalent playback things will sound different.

quote:

So then I bought the DAC, and an XPS, and hooked up three different transports. And heard differences. To confirm what I heard, I asked my wife and her girlfriend to be blind testers. They heard the same differences that I did (and no, I did not coach them).

Now fast forward to the present, where Andy has made a very persuasive argument that seems to refute what I, and many others, are hearing. Of course, the foundation of his argument is the design as described in the white paper. So now I am wondering if the white paper perhaps does not tell the entire story. Could there be undocumented details in the design, or limitations in the components, or processor edge conditions that could perhaps explain why theory and reality (for most) do not seem to be matching up? Is it possible that different transports can generate varying degrees of noise such that when connected via digital coax, they (like a computer) could be effecting the DAC's ability to produce uniform (i.e., it's best) sound?

Would hate to see this issue go unresolved. Hopefully we do hear from Naim R&D. Am not so cynical as to think Naim is knowingly selling a $5600 CD player that, when used as a transport to the DAC, offers no sound quality advantage over a $300 DVD player. Would be very disappointing to learn otherwise....

Hook

With you 100% there - if there is another mechanism at play, I'd be interested in understanding it - if only to be able to optimise my system better (actually, I'm always after understanding how these things work - it's the geek in me).

Still say I hear NO difference between USB and streamed from my htpc. I've just spent the last half an hour redoing the comparison on a downloaded 44.1/16 sample (so I KNOW it is bit perfect) and can't tell the difference. Or - at times I think I can, then go back and fore and it's the other way around <shrug>. Talk about your mind playing tricks....

AMA - i have to agree with Andy here - the method of encoding the SPDIF data ensures the integrity of the data (although the recovered clock can be polluted by the data) - but we're not worrying about recovering clock as it's decoupled in the nDAC design and to get a bit error caused by excessive timing errors would be way beyond the Red book spec.

One thought though. If the nDAC is (supposedly) so good at rejecting transport related nasties then why bother with a nice impeadance matched, transfomer coupled BNC input. Toslink would have done quite nicely and dealt with any ground coupling issues in the process. Whilst from an electrical perspective, the BNC / Transformer coupling is a very nicely engineered solution, if the nDAC isn't concerned about data quality (apart from it being bit perfect) then this is surely over engineering on Naims part ?

James

quote:

AMA - i have to agree with Andy here - the method of encoding the SPDIF data ensures the integrity of the data (although the recovered clock can be polluted by the data)

James, Andy -- I don't argue that SPDIF is theoretically a flawless transmission protocol. It's been designed to transmit data with 0 losses.
The same we can say for I2S -- it's also flawless (if the clock is perfect).
But this theory -- if you look closely -- silently assumes that all bits are SEPARABLE.

Now try to follow my SIMPLE logic -- which is very general and applicable to any transmission protocols. I don't care of what mathematics one is going to use in encoding the bitstream. It could be 100% excessive code or whatever.
But if during the physical implementation of bitstream-generator the clock is not good enough and allows for a good number of consequent bits to come closer to each other than specified by bistream-receiver frequency this will make the whole transmission chain (say SPDIF->SPDIF) fail. The difference with HDD, CD etc -- is that you don't have a SECOND chance to read the buffer and try to recover the bits again.
The Manchester code (which is widely used in downhole logging where I work) or biphase encoding (which is used in SPDIF) have nothing to do with my story. They regulate the way the bit is captured based on the analogue shape of the waveform. If recover works at 3 MHz and two bits come close as <1 ns they will be captured as 1 and 0 -- not as 1 and 1 (let it be Manchester or bi-phase or whatever).

Andy, you put absolutely right picture of PCM encoding except that you state that
"there is no concept of bits moving a little bit and being unable to be captured correctly".

I believe this is a CRUCIAL point in our discussion. I claim that poor clocking will lead a bistream to have such "close" and "far" bits -- and this is irrecoverable.
You say that this never happens and all bits are secured with a good spacing -- and you did not yet put a single word to justify this.

You just say: "it does not happen -- period".
Well -- this is something what I can not address.
Possibly you have never seen the stock DVD clock on oscilloscope?

And also -- bitstream is essentially a BIT STREAM. I mean that at low (physical) level this is just a sequence of bits (with some average time-gaps which sometimes go very high and sometimes go very low -- depending on the time-quality of bistream). The "words" is the way we CODE the bits before sending to SPDIF and then DECODE the bits after receiving the bits from SPDIF. If a good number of bits are mistaken -- you get a wrong "word" -- whatever high-level code you use.

Andy, AMA - Stereophile "bits is bits" article online is a useful reference (and i wish i had time to read it all this afternoon)


James

Just read through the white paper...again.

Was looking for any hints about what may cause transports to sound different, and found three comments.

1. As with all Naim designs, the influence of vibration-induced microphonic noise has been minimised in the Naim DAC

Minimized, but not eliminated. So perhaps different transports have different vibration characteristics?

2. CD, DVD player – connect via S/PDIF (watch out for the switch mode power supplies of cheap digital players and the quality of S/PDIF, which may suffer RF noise)

Different transports have different power supplies, so couldn't they contribute different amounts of RF?

3. Coax can sound better but optical has the advantage that it prevents ground loops and isolates the ground system of the source, which may be noisy, from that of the Naim DAC.

If different transports have different ground schemes, could not some be more effective than others at preventing noise from traveling through digital coax connections?

So while the white paper does suggest that there are differences when connected via BNC and/or RCA S/PDIF, I did not see anything to suggest why different transports connected via Toslink could sound different. But even this contradicts my own experience...

Anyway, if we accept (as the white paper says) that transports connected via digital coax can sound better than those connected via Toslink, then must we not also accept that vibration and/or RF noise via digital coax may have a role in perceived sound quality? If so, then could this help to explain why different transports may not all sound alike?

Hook

quote:

Originally posted by AMA:

AMA - I give up. SPDIF is a self clocked system. The encoder encodes the clock within the stream and the receiver syncs to it. The transitions between low and high are of the order of hundreds of nanoseconds apart. It is easy to recover the data from this.

The ONLY possible link in the chain whereby data can be lost is when it is read off the disc. I agree, a better transport may be able to read data better, but then if the disc has already been ripped...

Richard - why was my link removed - i cant see what rule it broke ?

James, while not a commercial link or a link to another forum, links to hifi magazines and reviews in the Hifi Room are generally moderated. I did consider whether I would leave this one, especially considering the current discussion, but felt consistency to be the fairest course of action. I tried to make it easy enough to find should anyone wish to read it.

Ah ok - fair enough

quote:

Originally posted by james n:
Andy, AMA - Stereophile "bits is bits" article online is a useful reference (and i wish i had time to read it all this afternoon)


James

Oooh... no linking...

Well that article is from 1996 and things will have come a long wauy since then...

I had a quick read through and it had this to say about losing bits in the bitstream:

quote:

Stereophile:
In this section we have shown that bit errors in the received subframe occur when transitions in the interface signal are incorrectly latched. This will not occur in most interface receivers for interface time constants of <100ns. Bit errors that do occur will most likely be in the preamble, and will usually result in the receiver failing to lock onto the incoming signal.

Basically, if you lose bits, it's likely you'll lose bits in the framing signals and then the DAC won't lock onto it..... but this is of the order of hundreds of nanoseconds...