I'm not him, but one way the input signal jitter can affect the output one is if the output oscillator tracks the frequency of the input signal.
In this case it is conceivable that the higher input jitter would cause higher output jitter.
However, for well designed systems, the output jitter will still have a higher bound even in the worst case. The question then is: is the jitter of a well designed system audible ?
IF it does, it will have a PLL which takes care of that. This is electronic design 101.
Jan
Jan
We really aren't communicating.
Jitter doesn't travel well to me means as you copy CDs the jitter doesn't pass.
Now what I expected to see looking at the jitter on multiple generations of a CD is that they all would have different jitter. (The actual jitter recorded not the error corrected recovered audio). The amount of jitter would bounce around not because of degradation but because of issues like exactly how it fit in the tray.
In addition I would expect the recorded files on a server to have uniform and less jitter.
Where I think we weren't communicating is the difference between just jitter and recovered data. As noted there is robust data correction and for a recorded file it requires significant corruption before it is only partially recoverable.
Now on data files the practice is to read after write to ensure lack of significant corruption. Every so often on data discs you get a failure report.
We really aren't communicating.
Jitter doesn't travel well to me means as you copy CDs the jitter doesn't pass.
Now what I expected to see looking at the jitter on multiple generations of a CD is that they all would have different jitter. (The actual jitter recorded not the error corrected recovered audio). The amount of jitter would bounce around not because of degradation but because of issues like exactly how it fit in the tray.
In addition I would expect the recorded files on a server to have uniform and less jitter.
Where I think we weren't communicating is the difference between just jitter and recovered data. As noted there is robust data correction and for a recorded file it requires significant corruption before it is only partially recoverable.
Now on data files the practice is to read after write to ensure lack of significant corruption. Every so often on data discs you get a failure report.
Last edited:
Ed, jitter DOES NOT reside on the CD, or on the hard drive, or whatever. Jitter is CREATED by a reading process, due to unprecise and fluctuating transitions of digital levels. It is nonsensical to talk about 'jitter of different generations CDs'. You might talk about 'jitter differences at different reads' but whether it is the same CD or different generations doesn't make any differences to the jitter.
'Bouncing around in the tray' could presumably effect the error correction, but has no bearing on jitter.
Jan
Last edited:
I was looking for a analogy.
Think about a couple of barracks with solders. They have to line themselves up in nice rows and columns on the parade field for a parade.
It is easy to see that the final performance during the parade depends ONLY on how well they can synchronize their steps during the parade, but is does NOT depend on how synchronized (or not) they got from the barracks into the lines and rows at the start of the parade.
Jitter performance depends on how well the data is clocked during the DA conversion, NOT how well they got into the FIFO.
Jan
Think about a couple of barracks with solders. They have to line themselves up in nice rows and columns on the parade field for a parade.
It is easy to see that the final performance during the parade depends ONLY on how well they can synchronize their steps during the parade, but is does NOT depend on how synchronized (or not) they got from the barracks into the lines and rows at the start of the parade.
Jitter performance depends on how well the data is clocked during the DA conversion, NOT how well they got into the FIFO.
Jan
Last edited:
DOH! Jitter effects could cumulate only if multiple A/D-D/A-A/D-D/A-... would occur. I suspect the jitter effects would add pretty much like uncorrelated noise sources. Phase noise, after all...
Good hint.
Recording chain jitter DOES NOT accumulate as long as the data is in the digital realm.
Every time a track is saved in memory or written to a hard disk or WiFi-ed to the tablet in the next room, it is jitter-free - or rather, the concept of jitter does not apply.
But as soon as that tablet starts to DA that track to the analog phone output, THEN the concept of jitter does apply, and the jitter performance is determined by the DA conversion in that tablet.
But in contrast to Ed, you knew this. Right?
Edit: it even gets better. Every time a jittered analog signal is AD-ed to storage, the jitter is gone. The signal is jitter-free, or rather, the concept of jitter does not apply. Until the next DA.
That's why re-sampling without changing the sample rate can be a great way to decrease jitter.
Jan
Last edited:
No! Everytime you AD an analog signal all jitter it might have had is gone! Think it through!
In its digital incarnation, the signal is just a bunch of numbers sitting there. How can a number 'encode' or 'remember' jitter?
an
Last edited:
No! Think it through. Each time you D/A convert a digital source, the analog output would include the jitter effect. Convert it back A/D, the new digital for will contain the jitter effect; this new digital imagine is not identical with the original digital source. Convert it D/A again. New jitter effect would add to the analog output. Etc...
P.S. Jitter is random.
It is not true that jitter (playback) is not on the actual disc. Glass-mastering, moulding and coating all contribute to the jitter.
Only if the jitter is high enough to cause E32 errors would there be a problem with making a copy or playback and if you made a copy of a disc with high jitter but no E32 then the jitter would not be transferred to the new disc. The copy would have its own jitter.
Only if the jitter is high enough to cause E32 errors would there be a problem with making a copy or playback and if you made a copy of a disc with high jitter but no E32 then the jitter would not be transferred to the new disc. The copy would have its own jitter.
It doesn't encode jitter per se, but it does encode amplitude error due to jitter, and that error is passed on (i.e., indistinguishable from the actual data).
Jan
We should talk about what is jitter. When you have a digital signal it has binary states. But the timing can be analog or digital.
The threshold of a circuit where it decides which state is being received is one aspect that leads to jitter. As the rise time of a signal is finite when the change is recorded (clocked in) will affect the read data.
The design goal is to look at a bit stream in what should be the middle of any data transistions. If the send clock and receive clock are not perfectly synchronized this determination may occur at a non optimal time.
That is why eye patterns are so useful. As long as the eye is open no data is being sampled in a transistion state.
Now on a disc the data is stored as a physical change with a three to one ratio. Jitter would be a slight shift in exactly where a bit stops or starts. The signal is recovered with a PLL that smooths out the data signal to extract the clock signal. As long as no edge data is clocked in you will not have errors. But since the edge definition does have some variance that is jitter.
Jitter on the marching field would show up as slight changes in distance between the soldiers and the exact time their feet left or touched the ground. They actually would vary their pace size and timing to remain in sync. But there are always small differences.
Now when you store data in RAM the clock and data are digital so in that case when the clock signal is in the middle enough there are no settling issues you do not have jitter.
We should talk about what is jitter. When you have a digital signal it has binary states. But the timing can be analog or digital.
The threshold of a circuit where it decides which state is being received is one aspect that leads to jitter. As the rise time of a signal is finite when the change is recorded (clocked in) will affect the read data.
The design goal is to look at a bit stream in what should be the middle of any data transistions. If the send clock and receive clock are not perfectly synchronized this determination may occur at a non optimal time.
That is why eye patterns are so useful. As long as the eye is open no data is being sampled in a transistion state.
Now on a disc the data is stored as a physical change with a three to one ratio. Jitter would be a slight shift in exactly where a bit stops or starts. The signal is recovered with a PLL that smooths out the data signal to extract the clock signal. As long as no edge data is clocked in you will not have errors. But since the edge definition does have some variance that is jitter.
Jitter on the marching field would show up as slight changes in distance between the soldiers and the exact time their feet left or touched the ground. They actually would vary their pace size and timing to remain in sync. But there are always small differences.
Now when you store data in RAM the clock and data are digital so in that case when the clock signal is in the middle enough there are no settling issues you do not have jitter.
Last edited:
But if the data is recovered without errors and read into FIFO or whatever intermediate memory, any jitter it might have had when read off the disc is no longer there.
If it had previously been jittered in it's analog state which has lead to slight changes in the analog data values as SY noted, those slight changes are present in the digital encoding on the disc, and are still, unaltered, present in the digital data off the disc, before being DA'd.
The reading of the data off the disc (or hHDD or SSD) into an intermediate storage will not cause jitter.
Jan
Ah
Now we are getting to the difference between jitter and errors. In a robust system (and most are) jitter does not lead to errors.
Jitter is an issue when the clock is extracted from the data or analog timing. When the clock is either recorded with or controls the data jitter is not an issue.
Now there can be errors in data streams with a digital timing system. But they are noise related. Think 1/f noise occasionally gets high enough to flip a bit. The lower the system voltage level and the larger the memory the more often it occurs. But I wouldn't loose any sleep over loosing a bit a month or so from that issue. Parity works well enough on error rates that low.
So in my opinion things such as how you place a disc in the tray and the recording speed should affect jitter but in a robust system not error rates.
Now optimum record speed may not be the slowest due to mechanical resonances. Jitter may affect sound quality in systems with poor mechanical stability or inadequate error correction.
To me the real issue is calling discrete level continuous time systems digital.
Now we are getting to the difference between jitter and errors. In a robust system (and most are) jitter does not lead to errors.
Jitter is an issue when the clock is extracted from the data or analog timing. When the clock is either recorded with or controls the data jitter is not an issue.
Now there can be errors in data streams with a digital timing system. But they are noise related. Think 1/f noise occasionally gets high enough to flip a bit. The lower the system voltage level and the larger the memory the more often it occurs. But I wouldn't loose any sleep over loosing a bit a month or so from that issue. Parity works well enough on error rates that low.
So in my opinion things such as how you place a disc in the tray and the recording speed should affect jitter but in a robust system not error rates.
Now optimum record speed may not be the slowest due to mechanical resonances. Jitter may affect sound quality in systems with poor mechanical stability or inadequate error correction.
To me the real issue is calling discrete level continuous time systems digital.
- Status
- Not open for further replies.