|
Digital Drive Upsamplers, DACs, jitter, shakes and analogue withdrawals, this is it. |
|
|
|
Digital Drive Upsamplers, DACs, jitter, shakes and analogue withdrawals, this is it. |
|
In Reply to: I Don't Think It's Jitter... posted by Todd Krieger on June 10, 2003 at 22:33:08:
I experimented briefly with the Pioneer DV-S755Ai and VSX-A10i combination using the IEEE1394 connector between them. The Pioneer combo is supposedly using data buffer memory and reclocking technique at the Receiver's DAC that is said to be able to reduce this problem. No dice, I can still hear the problem. Discussing with Dr1394 at the Audiobahn who claim to be an IEEE1394 software developer led to further experiments. He completed some tests that we agreed upon. Test disc was CCR Cosmo Factory, CD layer of the SACD. Test track was track 9, Who'll Stop the Rain.He made 3 captures from the 1394 link of the DV-47ai:
1) From the stop state, hit button 9 on the remote. Capture 8
megabytes or about 47 seconds of bitstream.2) From the stop state, hit button 9 on the remote, then wait
11 seconds and hit track repeat.3) From the stop state, hit button 8 and let this track play.
Then start capture at the last 7 seconds of track 8 and the
first 40 seconds of track 9.Results:
Same bits every time.
His contention was that if his "fc /b" program in a DOS window is showing that the same bits are delivered for each iteration in a captured bitream data, the bitstream was exactly the same each time, irregardless of how the tracks were being sequenced, then for all intend and purposes, it would be jitter free and there should be no audible differences.
That still doesn't explain why I am still hearing the problem in the Pioneer combo though. Frankly, the measurements made should not surprise anyone and least of all yourself. Jitter does not usually change the data. It only corrupts the clock or timing of the data. So it will not show up on absolute measurements of bits. The timing information must be viewed, either through a specific jitter measurement or capture the data stream (and clock) on a digital oscilloscope.
The reason jitter causes sonic problems is not because of changed data. It is because DACs can be negatively affected by jitter, causing compromised performance or data CONVERSION errors. A DAC's analog output can be degraded by jitter in terms of added noise, distortion or in extreme cases, conversion errors.
I am asking him to repeat the measurements using a high speed digital storage oscilloscope and compare the amplitude versus time data (waveform). Perhaps we might see differences. Note this is the same way an analog signal is being measured, just much, much faster. If the differences in the waveforms are significant, you will get differing sound out of the DAC. Bit for bit measurements would show only huge data errors, unlikely to be caused by jitter. Hopefully Dr1394 will put aside company's interest to explore this jitter issue fully, even though it puts the IEEE1394's technology in a bad light. Regarding 1394. Some designers like Ed Meitner have decided against using it for several reasons:
1. the clock is integrated within the data stream and is NOT discrete.
2. recovering the signal and clock from 1394 is a VERY difficult and complicated process where there is ample opportunity to screw it up
If digital transmission to the DAC uses an embedded clock the only way to deal with the Jitter issue would be to throw away the clock and re-clock the data using a newly generated clock signal.
This last information was confirmed by a speaker designer friend and according to him, he is now using a modified SCD-1, but as a transport only. The digital data for CD is upsampled, reclocked and converted to SDIF2 via a dCS 972 processor and then sent to a dCS Elgar at 24 bit/88.2 kHz. According to him, there is no jitter possible after this. Even though he is awared of this problem with digital players, and have often noticed it with many CD players, he said he can hear no such problem right now with the current set-up. SACD is also sent out via SDIF2 to an outboard Meitner converter.
He further described that in this set-up, the clock or timing info becomes irrelevant if it’s stripped off and discarded. The SDIF2 format dedicates a separate cable for the clock signal, which is never multiplexed with the data signals. In the case of the dCS, the clock is stripped off, L and R data are separated and stored in memory. Then a new clock signal is generated which is used to reclock the output. Three dedicated outputs carry L data, R data and clock to the DAC.
Regarding the issue of embedded jitter, I am beginnning to suspect that the jitter problem may be correlated with the encoded non-audio signal on every discs, and not just because of the inherent digital transport design flaws as I thought earlier.
According to HDCD® developer Pacific Microsonics—who has done extensive research into jitter audibility — the jitter's frequency and spectral distribution largely determine a transport's sonic signature. Jitter at one frequency may produce a certain sonic characteristic, while jitter at another frequency will create a very different subjective effect. In other words, the jitter's characteristics probably determine each transport's sound. In contrast, the track-repeat procedure produces changes with very similar sonic characteristics all the time with different players and transports.
If you look up Stereophile's archives, and look at some of the jitter measurement plots, there is always large peaks seen between 7kHz and 8kHz which correlates with the subcode carried in the S/PDIF data stream. Subcode is non-audio data such as track time, track number, and whether the data have been pre-emphasized. The data rate for each subcode channel is 7.35kHz, producing jitter at 7.35kHz. That might explain why the same sonic character changes can be heard in every digital player I tested so far. That would also explain why Methos can still hear this jitter problem even after installing the Superclock II.
Repeat tracking removes some sonic blemishes that bear similar characteristics in all the 50 or more players that I have tried. This indicate that it could be a software issue other than just transport design flaws. Different tranport design flaws produces different sonic characteristics. Embedded within the digital data extracted from discs are jitter created during the encoding stage and the subcode. Since jitter at different frequencies produce different subjective effects, due to different problems that can occur during production, this leaves the subcode as one likely suspect. But as to why the track-repeat procedure will reduce the effects of subcode jitter, I really have no answer. I find it strange that the SKIP BACKWARD key will reduce the jitter, but not the numerical keys.
This post is made possible by the generous support of people like you and our sponsors:
Follow Ups
- Dr1394 made a test and concluded the same bits every time. - jeromelang 06/10/0323:24:09 06/10/03 (2)
- I Guess the Next Thing to Do is Compare Jitter Spectra... - Todd Krieger 23:29:55 06/10/03 (1)
- I didn't know you are a guru in these parts. - jeromelang 23:40:00 06/10/03 (0)
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2026, Audio Asylum, all rights reserved ]
