how can digital be different

[PeteH]

Originally posted by wadia-miester

But so far in this thread a the conclution seems to be that read bit errors are almost improbable?

Certainly improbable, almost impossible - unless the disc is really mangled. And AFAICT there's no other reasonable way to interpret the evidence we've already examined, so unless you want to dispute the validity of the experimental results (or I've completely missed something ) I think we're stuck with it.

 

[dat19]

PeteH and GrahamN,

My comment was in response to this (incorrect) piece of analysis:

Originally posted by PeteH
In the absolute worst-case example in the link you posted there are 30 uncorrectable errors, which AFAICT would correspond to something in the region of 600 microseconds of interpolation being necessary if the CD is to continue playing.

Unrecoverable errors in the RS code will cause considerably more interpolation, because a BLOCK (protected by the code) is longer than a sample...

I think everyone agrees that disc read errors are not a significant problem in the sense that the data is correctly recovered (after error correction etc) from the disc.

HOWEVER, if people do want to go back and forth on the problems caused by read errors from the disc, and whether these can bubble up to the interpolation layer, then discussing average error rates isn't going to get you very far, especially when for example surface scratches are the source of correlated errors, which you are currently treating as "random" processes.

That said, if you want to address why transports and cables sound different, you need to stop thrashing on the "non-existant" disc read problem, and look elsewhere for how the differences might arise...

 

[GrahamN]

Originally posted by dat19
I think everyone agrees that disc read errors are not a significant problem in the sense that the data is correctly recovered (after error correction etc) from the disc.

The whole reason for this disc read error discussion is that it was raised by Julian - with similar additional input from Lowrider - and it's taken 3 pages or so to get that point through to him.

And the whole point of the Interleaving in the CIRC is to disperse the correlated burst errors generated by a scratch (in that paper I linked, up to 2.4mm) to enable enought local information for accurate correction.

you need to stop thrashing on the "non-existant" disc read problem, and look elsewhere for how the differences might arise...

I thoroughly agree that we need to stop talking about bit errors - but while people keep on making false assertions they need correcting.

As I'm equally happy for any falsehoods I perpetrate to be corrected - here's an opportunity to have a go. As I've said many times, the only differences can lie in the propagation of timing errors TO THE DAC CLOCK. In essence, word timing errors cause convolution of the desired spectrum with a distortion transfer function, which is essentially the spectrum of the jitter (and Bessel functions get involved somewhere). Peak timing error is largely irrelevant in itself - the important thing are the peaks in the jitter spectrum. There are differences in implementations of extracting the clock for the DAC from the input data stream: some use all the bit transitions; better ones use just the frame sync bits; even better ones actually slave the transport output clock to an independent clock suplied close to the DAC, and so don't use any clock extracted from the data stream. I would love more information on the degree and nature of their effects in practice.

 

[PeteH]

Originally posted by dat19
PeteH and GrahamN,

My comment was in response to this (incorrect) piece of analysis:

OK, it's a fair cop, I wasn't entirely sure how exactly to work out how much interpolation would occur, but as it was basically irrelevant to the argument anyway I figured I'd wing it and hope noone noticed So if a read error occurs does the entire block get thrown out, or the frame that contained the error, or does it depend on the particular case?

Originally posted by dat19
HOWEVER, if people do want to go back and forth on the problems caused by read errors from the disc, and whether these can bubble up to the interpolation layer, then discussing average error rates isn't going to get you very far, especially when for example surface scratches are the source of correlated errors, which you are currently treating as "random" processes.

I don't think anyone besides yourself has actually been discussing average bit error rates. There was no need to once we established that even once the regions of peak bit-error count were taken into consideration, net total data errors were zero.

But yes, I think we've done error correction now, time to move on Unless you'd like to expand on what you meant by the quotation marks in

Originally posted by dat19
the "non-existant" disc read problem

 

[wadia-miester]

He, he just back to read bit errors for moment gents
So in the general concenous on this issue, you'll pretty well conviced, that NO MATTER what transport mechanism or suppiled power or laser diode emitter (what ever biasing used) that NO READ ERRORS CAN POSSIBLY OCCUR (or at an infitessimal variable), it's all after that pick up point?, can we just clarify this please.

 

[GrahamN]

Originally posted by wadia-miester
can we just clarify this please.

From the information linked here so far:
a) Normal operation does result in read errors directly off the disc of maybe up to 1-200 per second. The CIRC process corrects ALL off these so the net result out of the transport is ZERO errors total.
b) This result is to be expected in all but pathological cases: brillo-padding the CD and dropping the transport from a great height would be considered pathological cases (but since that latter problem is intermittent, "anti-jog" mechanisms in "discmen" solve even this by specifically allowing rereads)
c) any transport not achieving such performance (whether that be through laser biasing or whatever) is given a special designation...BROKEN!

 

[wadia-miester]

All righty then he's the punch................

so if we take ANY 25 transports mechanisms, and give them the same feed power etc, and the same output stages dac's etc, by YOUR reckoning they'll all be indentical then in sound and measurement, or I'm just playing at being thick for the benefit of the tape my'lud ?

 

[GrahamN]

Originally posted by wadia-miester
so if we take ANY 25 transports mechanisms, and give them the same feed power etc, and the same output stages dac's etc, by YOUR reckoning they'll all be indentical then in sound and measurement, or I'm just playing at being thick for the benefit of the tape my'lud ?

I never said that (and whether I think so or not, I'm keeping stumm from the moment). They should though (unless you come up with some evidence that contradicts everything that's been found related to this thread so far) generate the same sequence of 1s and 0s.

As I keep on saying...and I refer the honorable gent to my earlier reply...any differences will appear in when those 1s and 0s get to the DAC (convolution with jitter spectrum etc).

If it's the same DAC and feed power, then variations can only be seen dependent on how the DAC gets its clock (and propagation of noise). The sensitivity to the inherent jitter spectrum of the transport output will be a factor of how well the DAC input circuitry is designed.

 

[wadia-miester]

But the answer is not what was asked
I'm not talking after generation of data corruption (some of which I know a little) <> I'm specificaly asking during the transport phase, as if this is the 100% 'as is ' so to speak, then every transport section ever made should be unequivicably equal, absolutely no errors regardless of construction (S/R code permitting), then it's just down to the transmission/psu/dac etc errors. thoughts please

 

[PeteH]

Originally posted by wadia-miester
But the answer is not what was asked

The question was: based on the evidence contained in this thread, can we conclude that all transports will sound exactly the same? And the answer is: no.

Can't see what the problem is with that

 

[wadia-miester]

Pete, the questions wasn't transports (in the whole part) I mean the mech's and data transfer before it gets to the messy bit, as if the answer is no, then this opens up a whole new pandoras box oh the joys of theories

 

[dat19]

Originally posted by GrahamN
The whole reason for this disc read error discussion is that it was raised by Julian - with similar additional input from Lowrider - and it's taken 3 pages or so to get that point through to him.

And the whole point of the Interleaving in the CIRC is to disperse the correlated burst errors generated by a scratch (in that paper I linked, up to 2.4mm) to enable enought local information for accurate correction.

Well, upto this point very little evidence of low error rates are has been properly presented. The pointer to the CDR site, ignores the fact that CDR's are made by a very different process to CD's. On the other hand Altman's analysis provide no real insight - a CD that looks badly scratched to YOU, might not be an issue for a laser following a .5micron wide track

Also, the "paper" you provided (which looks like a link to an undergraduate assignment) discusses the robustness of the code, but again provides no insight into the number of errors that happen during real playback.

As I'm equally happy for any falsehoods I perpetrate to be corrected - here's an opportunity to have a go. As I've said many times, the only differences can lie in the propagation of timing errors TO THE DAC CLOCK. In essence, word timing errors cause convolution of the desired spectrum with a distortion transfer function, which is essentially the spectrum of the jitter (and Bessel functions get involved somewhere).

The first step here is to characterize the jitter and then you need to show that jitter shows up in the audio output of the DAC and that it isn't perceptually masked by the signal (ie, that it can be heard.)

This was addressed in these papers (ie proper peer-reviewed papers published by a recognized professional body..)

"Jitter specification and assessment in digital audio equipment", J. Dunn, 93rd AES convention 1992.

"Theoretical and Audible effects of Jitter on Digital Audio Quality", Benjamin and Gannon, 105th AES Convention 1998.

Peak timing error is largely irrelevant in itself - the important thing are the peaks in the jitter spectrum.

Groan..

The distribution of the timing error and the time scale of the error is very significant, and impacts different DAC architectures in very different ways. This was covered by Robert Adams (of Analog Devices) in

"Clock Jitter, D/A converters and sample rate conversion", 95th AES Convention

 

[GrahamN]

Originally posted by dat19
Well, upto this point very little evidence of low error rates are has been properly presented....but again provides no insight into the number of errors that happen during real playback.

Agreed CDR and CD are different, but the same result (although with little detail on how extensive the test) was found for CD by Altman. BTW: The main point of the link I posted was to explain CIRC in readily understandable terms (because the concepts are clearly not understood here). I guess there is a high probability it is an undergraduate exercise, as it's from a US miltary site (or was that what you were getting at) - but it does have a Prof.'s name at the top!

Since you clearly know more than you're posting..then POST IT! Also, simply quoting references to papers that are not generally available to people here is not tremendously helpful - any links or summaries would be most welcome.

The first step here is to characterize the jitter and then you need to show that jitter shows up in the audio output of the DAC and that it isn't perceptually masked by the signal (ie, that it can be heard.)

Absolutely no disagreement here whatsoever.

The distribution of the timing error and the time scale of the error is very significant, and impacts different DAC architectures in very different ways.

Groan...
"distribution of the timing error and the time scale" = "jitter spectrum".

Surprised you've not made any reference to the differences between correlated and uncorrelated effects...or were you saving that for a later round?

 

[GrahamN]

Originally posted by wadia-miester
Pete, the questions wasn't transports (in the whole part) I mean the mech's and data transfer before it gets to the messy bit, as if the answer is no, then this opens up a whole new pandoras box oh the joys of theories

As Pete said...but IF the data stream is presented to the DAC with the same timing and same interfering noise, then I see no way it can sound different. That is a huge IF though, and I have no evidence to the side-effects of different mechanics on the output devices. There may be many effects that do get through to the output too, but have no effect on the sound.

As someone who's spent 20 years working around digital control and data acquisition systems at 10-100 times the frequencies used here, though, I find it surprising the audio industry has so much trouble with this (if it actually does).

(And now the discussion has move on to the more interesting aspects of characteristing the timing errors...don't bother coming back with simplistic statements of peak jitter values - I'm sure they make sense in marketing literature, but doubt they're of tremendous use elsewhere)

 

[wadia-miester]

Originally posted by GrahamN
As Pete said...but IF the data stream is presented to the DAC with the same timing and same interfering noise, then I see no way it can sound different. That is a huge IF though, and I have no evidence to the side-effects of different mechanics on the output devices. There may be many effects that do get through to the output too, but have no effect on the sound.

(And now the discussion has move on to the more interesting aspects of characteristing the timing errors...don't bother coming back with simplistic statements of peak jitter values - I'm sure they make sense in marketing literature, but doubt they're of tremendous use elsewhere)

Graham, as expected on point one thanks
point 2, 'Transmission errors' more of my area, unlike the data generation stuff
Simple enough theroy really, totaly isolate the incoming data stream from ALL FORMS of interfernce, until it reaches the output phono's on the cdp/dac, then just carry that on down the rest of the chain until it comes out the cones/panaels or horns
If you can do that, I'll buy into the company
Seriously for a moment now, where do feel the main contamination paths for the data stream lie ? electromatic/radio/microphonic and power supply induced, dependant on specific design? of a combination of some or all.
Having modified a few players of the same model and preformed different methods (clock/outside psu/dual diffing the dac chips/d/filter mods/sheilding/isolation/damping amonst others) on a few, the results often threw up quite different, but none the less enjoyable beneifits, have made a few notes along the way, would be intereted to see if any of the theriores fits the results, and coralations thus gleened. Wm

 

[GrahamN]

Originally posted by wadia-miester
Graham, as expected on point one thanks

Well you shouldn't have been surprised as it's not anything I've not said many times before.

Simple enough theroy really, totaly isolate the incoming data stream from ALL FORMS of interfernce, until it reaches the output phono's on the cdp/dac, then just carry that on down the rest of the chain until it comes out the cones/panaels or horns
If you can do that, I'll buy into the company

Well sticking with the digital->DAC bit for the moment (which is what this thread is about after all)...that's certainly one approach. Seems much better to me to make the DAC clock insensitive to any of the upstream interference. Obvious approaches are either:
a) smooth out variations in the input clock (shades of DAC64) -extract clock from least data-sensitive part of data stream, i.e. frame sync bits + PLL + FIFO with enough buffer memory to accommodate maximum possible deviation from nominal - depends on TC of the PLL. Not sure of the parts cost of this, doubt it's high, could possibly check with our electronics engineer if necessary. (Ah, he just phoned me anyway...logic could probably all fit in one smallish FPGA, cost probably £100 max, £50 in volume).
b) make data stream demand led (i.e. sync/clock-link type solution)
(Opto-isolation may be helpful if any residual noise is a problem)

Seriously for a moment now, where do feel the main contamination paths for the data stream lie ?

Nothing I have any experience of...so that's for others to say. Maybe it's in those papers dat19 refererred to...so it would be nice to see what they say. (There's also some simplified stuff..not sure how helpful...in that Altman link, although I've not read it all.

 

[PeteH]

Originally posted by dat19

Also, the "paper" you provided (which looks like a link to an undergraduate assignment) discusses the robustness of the code, but again provides no insight into the number of errors that happen during real playback.

Maybe if you know something about that you could share it with us rather than dropping mysterious hints about it Likewise if you want to dispute anything in the sites already cited, you could just come out and say it - and maybe we could get this discussion sorted before it runs to 50 pages Regarding the CDR thing, there was an implicit assumption through this discussion that CDRs were at least as error-prone as normally pressed CDs, and hence the fact that there were zero data recovery errors under normal conditions in that particular study could reasonably be applied to this discussion. As similar results had been found elsewhere with normal audio CDs, whether or not that assumption is well-founded wasn't really relevant.

Originally posted by dat19
The distribution of the timing error and the time scale of the error is very significant

That's exactly what Graham and I have been saying throughout this thread since the issue of data loss first reared its ugly head

 

[GrahamN]

Pete, don't forget that CD-ROMs have a second level of error correction above the C1/C2 parts of the basic CIRC, that reduce the error rate further. Not sure that this is was dat19 was referring to though. Certainly wasn't relevant to Altman's tests (which were on a CD-Audio drive).

 

[technobear]

Originally posted by GrahamN
Pete, don't forget that CD-ROMs have a second level of error correction above the C1/C2 parts of the basic CIRC

Don't confuse CD-ROM with CD-R. An Audio CD written on CD-R media is still an Audio CD, not a CD-ROM. So it will still only contain the same amount of redundancy as a manufactured CD.

 

[dat19]

Originally posted by GrahamN
Agreed CDR and CD are different, but the same result

No, CDR's and CD's are produced by very different processes and the distribution of errors cannot be assumed to be the same even though the protection is the same. This "nit-picking" comes into play because CDR writing (at home) isn't nearly as repeatable as the stamping used for CD production.

Since you clearly know more than you're posting..then POST IT! Also, simply quoting references to papers that are not generally available to people here is not tremendously helpful - any links or summaries would be most welcome.

The rough summary of the papers is this:

Adams: Jitter is a problem that has been widely mis-represented in the popular audio press (a dig at Stereophile, who made jitter their hobbyhorse); jitter cannot simpy be measured by hooking up a scope to the clock input on a DAC - it's way more complicated than that because some jitter immunity can be in the DAC itself; even if you somehow knew the jitter then that doesn't translate directly into an effect on the ouput, but affects different dacs in different ways (resistive ladder is different to mash is different to delta sigma).

Dunn: Even with worst case scenarios, the jitter is still 40dB below the signal, and is covered by auditory masking (and that was using DAC etc technology available before 1992..)

Benjamin and Gannon: "for nearly all program material no audible degradation was heard for any amount of jitter added below the level at which the DIR (Digital Interface Receiver) lost lock". [Note, they used several different DAC's, and this comment is important as it relates to the initial question about cables and transports..]

Groan...
"distribution of the timing error and the time scale" = "jitter spectrum".

The reasons I wrote "Groan" and then corrected you with "distribution of timing errors"
is because you seemed to want to ignore at least part of the distribution when YOU wrote this Peak timing error is largely irrelevant in itself !!!!