Can jitter be fixed in advance?

[andrew_whitham]

hi blackcat

the basics of a syncronous system is what I'm stuggling with a bit. I *know* that you can get jitter in that process (how significant it is, well i dont know)

So you have, for instance, 16 bits coming on the falling edge of each clock pulse on the 16th pulse the latch changes = end of word. does it matter if the 5th MSB arrives a bit late? so long as it arrives before the falling edge of the relevant clock pulse?

Am I taking a particularly pessimistic view here of the performance of digital electronics? Particularly if the input swings 0-5v when switching occurs at 2v?, the more I think about this the less I'm worrying about jitter at all

BUT youre mis-interpreting windows as whats on your HDD or CDRom - you'd need to get at the 0's and 1's on the platter & delete one of those, changing the data in a file, essentially means you meant it - its not the same level of corruption. Think changing a whole note in audio. Incidentally you can do the same test on an image file which I thought would be more tolerant no no no. surprising that.

Heres my test though - take a copied cdrom put it data down on your desk move it in circles - you just destroyed data on it the pits definately got obliterated - Can it still be read? - I have lots of disks like this

BTW have a look at this page on Jitter: hxxp://www.altmann.haan.de/jitter/english/engc_navfr.html
the definition of jitter is very funny - next time I'm late...

[BlackCatSound]

Yes you can 'guess' the missing sample, a very simple FIR filter will do the job. But surely the holy grail here is 'perfect' reproduction, ie zero errors.

You could read at 2 or 4x which isn't that noisy and is still fast enough to keep a modest buffer full.

Anyway, we're going off track as data errors and jitter are two different things

[anatech]

Hi Andrew,
Try this ...
http://www.altmann.haan.de/jitter/en...ngc_navfr.html

Now it works!

[andrew_whitham]

Sorry , Didn't know if you were allowed to hotlink

Thanks

[anatech]

Hi Andrew,
On that web site, when they refer to the error flag, they mean the C2 flag (DSP gives up = uncorrectable error).

They are correct about the transport. The current crop of Philips transports are terrible. Not a bad site to understand the issues that jitter can cause.

-Chris

[janneman]

Originally posted by anatech
Hi BlackCatSound,
Consider this. The 1X unit does not read the contents of the CD into a large memory. The particular pit on a track is accessed once only. You have but one shot at getting it right and that doesn't happen all the time. There are always read errors (called the BLER rate). Better transports have fewer errors, and as a result they sound better.

CD tranpsports have better power supplies and DAC sections. I'll assume we are talking about good units. They last a whole lot longer and run with less noise. The transport is isolated from the chassis in most cases.

I'll take a good (more expensive) CD player any day over a CDR drive. I hate paying the money, but I know exactly what I'm getting. There are no free rides in life. BTW, loads of errors coming off the scratched disc in the CDR, don't kid yourself. I'm amazed that stuff even works.

-Chris

I think his point is that the digital stream coming from the cheap PC CD transport is identical in code as the one from the expensive CD transport.

Read errors occur in both cases but are automatically *perfectly* corrected (that's why they call it error correction) unless the CD is so damaged that the correction fails, at which time the system goes into interpolation and/or mute. When that happens, it is VERY easy to hear, not pretty!

So, assuming that the damage is not so great to cause concealment or muting, the bit streams in any case are *code perfect*. It is then up to the DAC how it will sound in the end, and it is then when the jitter starts to rear its ugly head.

Jan Didden

[anatech]

Hi Jan,
I see your point. I have serious reservations about the error rate being that low with the CDR drive. I don't believe error correction is optimized for audio.

Hey, I don't know. I just do not trust small, cheap lightweight drives. History has supported this thus far.

Jitter is another thing again. The noise in the electrical environment will have a say in this as well. (not for the better either).

-Chris

[BlackCatSound]

If you clock the DAC from its own clean local clock then noise, transport quality etc.. become (almost) non-issues. You won't be using the transport to create the clock any more.

Doesn't matter what you're doing, having a clock track snake half way around the board is never a good idea And add in the awful 'build to a cost' single sided PCBs you find in so many CD players....

[darkfenriz]

Men
CDs use heavy Reed_Solomon encoding, which can correct 1 byte per every 2 byte added to original data. So this doesn't seem to me any case.
Considering jitter, it is different thing, correct date in non-perfect time. This can be highly reduced using a long FIFO and PLLs with adequate frequency filtering, even a cascade of PLLs (which I am planning to implement in my future jitter-eater).
All SONET/SDH networks engeneers know it very well, but there time lattency is the case, in audio DACs it isnt.
The problem is cheap digital systems dont care much and worse, some interfaces induce jitter from dispersion.
To fix in advance, I dont know... maybe manchester coding?
what do you think?
regards