Where is bit perfect data measured to be considered bit perfect

[joelha]

I've just read an interesting review of the Laufer Teknik Memory Player in Stereo Times Welcome to the Stereo Times

 

The following quote from the developer of the Memory Player, Mark Porzilli, was interesting to me.

 

Maybe this point has been discussed elsewhere on this site, but I've always wondered when data is considered to be bit perfect . . . from what point to what point in the digital chain of events is data considered to be bit perfect?

 

And from what point to what point should it be bit perfect in order for the listener to get the best sound?

 

"I think that in early stages, before the stream of data is in 16/44 or 24/192 formats, the bits can be severely jittered BUT it is never measured at the streams. It's always measured at the output. Early Jitter or Early Stage Jitter is when bits scramble during a laser read or an Internet download or the like. Time periods distort but there is no opportunity to measure it. The problem is that if the data is jittered at the early point of being a simple stream of data, a point where it is the jittered data becomes part of the newly formatted data and so it becomes part of the "original" as the DAC sees it and so there is no jitter to correct by the time it reaches the DAC."

 

Thoughts?

 

Joel

[Audio_ELF]

It's always been my understanding that the term "Bit Perfect" means that there is no sample rate conversion nor other processing carried out between the file and the input of the DAC.

 

It shouldn't be thought of that "bit perfect is required for best sound quality" only that a player should be capable of bit perfect output - if the listener chooses to use processing that's all well and good but this shouldn't be hidden.

 

Eloise

[Jud]

Very nice topic and one I'm interested in, as you can see from the loosely related thread I started.

 

Let me run a little thought experiment. Let's say we take the output from a digital recording session and print out the 1s and 0s. You read me the printed output, I write it down. (Yes, there would be gazillions of ones and zeroes, but for purposes of this thought experiment, let's say either that we have lots of time, we can do this very, very fast, or both.) There would be differences easily up to tenths of seconds in the time it takes me to write down individual numbers. So "jitter" at this point would be through the roof.

 

Then I take the numbers I've written down and feed them into an OCR reader, which converts them into computer file information, 1s and 0s, but electronic now. That file is fed into a buffer in a DAC. A very, very good clock in the DAC then pulls the 1s and 0s out of the buffer and into the digital-to-analog conversion process with a jitter level measured in the tens of picoseconds. So the actual conversion is done on a bitstream with almost vanishingly low jitter.

 

Summing up: If you govern the process of feeding the data into the actual digital-to-analog conversion with a very good clock in the DAC, timing between digits in the process prior to that pretty well doesn't matter. I think as a concept this is somewhat along the lines of the idea Gordon Rankin had in developing the asynchronous USB Audio interface with its potential for very good jitter specs - "asynchronous" because the clock in the DAC is not time-synchronized to previous points in the reproduction chain.

 

If you do synchronize the bits coming out of the DAC's buffer to a previous point in the chain by one of the common methods like a phase-locked loop, though, then yes, the timing of bits at that previous point will affect jitter at the DAC.

 

By the way - this really doesn't have much to do with "bit perfect," because in both examples, asynchronous and phase-locked loop, we haven't assumed any sample rate conversion. "Bit perfect" means there are the same numbers of ones and zeroes as in the original digitized recording, in the same order - 01101101 and 01101101, for example - and has nothing to do with jitter, which is timing between the bits. (Think Lawrence Welk - "And a-one, and a-zero, and a-one....")

[moko]

very good post Jud.....but i was wondering are you sure the jitter is only effecting the timing of ones and zeros......and that the jitter is not mixing up the sequence of ones and zeros.......thanks

[Jud]

very good post Jud.....but i was wondering are you sure the jitter is only effecting the timing of ones and zeros......and that the jitter is not mixing up the sequence of ones and zeros.......thanks

 

Hi, moko. Let's say the sequence of ones and zeroes *does* get mixed up. That will be *very* apparent as an extremely brief out of place silence or burst of noise sounding like a "tick" - like a scratch on a record but shorter. Most folks, thankfully, have systems that at least work well enough that such audible dropouts won't occur. But jitter is usually more subtle. Errors in timing short of dropouts cause a couple of forms of distortion that aren't obvious "ticks" but make the music sound more harsh, or raise the overall noise floor, losing subtle details. So there's an effort to minimize jitter in order to eliminate such distortions as much as possible.

[moko]

thanks....im really interested in all of this....still pretty new to it all...but love reading here on the forums : )

 

i want the very best original audio coming out my speakers....as if i was standing in the concert....at the optimum spot : ) .....even if my ears cant pick it up...i know my soul can....and he will let me know how he feels about.....hello : )

[ringenesherre]

Let me run a little thought experiment. Let's say we take the output from a digital recording session and print out the 1s and 0s. You read me the printed output, I write it down. (Yes, there would be gazillions of ones and zeroes, but for purposes of this thought experiment, let's say either that we have lots of time, we can do this very, very fast, or both.) There would be differences easily up to tenths of seconds in the time it takes me to write down individual numbers. So "jitter" at this point would be through the roof.

 

Then I take the numbers I've written down and feed them into an OCR reader, which converts them into computer file information, 1s and 0s, but electronic now.

 

... at which time all information about jitter is lost (unless you swapped bits), as there is no way to store this information.

 

Cheers,

Peter

[audiventory]

Momental levels of signal (as example):

 

- To input ADC: 0.1V - 0.2V - 0.4V

 

- From output DAC: 0.11V - 0.19V - 0.42V

 

DAC make oversampling for better filration of output signal also.

 

We have bit-perfect, but we have level error any way

[joelha]

Hi Audiventory,

 

To those of us (namely me) who don't understand electrical engineering, can you explain the implication of line level differences between input and output as they relate to what we'll hear in our system?

 

Thanks,

 

Joel

[RobbieC]

For clarification of something that has kind of already been said above, I'd like to reword the claim:

 

Jitter manifests as audible ONLY at conversion points meaning ADC or DAC only.

 

Think about it. At these points any cumulative jitter is either irreversibly encoded (ADC) or now irreversibly part of the reconstructed analog signal (DAC). Until those stages jitter can be dealt with much like in the example Jud gave of transporting data from point A to point B by printing out the stream by hand with its terrible, terrible jitter spec and then scanning the printed bitstream with an OpticalCharacterRecognition scanner that can read off the data and output it as the exact same bitstream but now with vanishing low jitter.

[Jud]

... at which time all information about jitter is lost (unless you swapped bits), as there is no way to store this information.

 

Cheers,

Peter

 

Yes, absolutely true. But that doesn't mean no jitter might result from what happens after this point in the process. Let's first take the adaptive case, then the asynchronous case.

 

In the adaptive case, one has potential jitter at the computer output resulting from data being taken off a spinning hard drive, and whatever timing error might come from the CPU. If there's an SSD, let's assume negligible timing errors from data I/O, leaving timing error from the CPU. (Note that a timing error in the CPU of 10 seconds per month is very roughly equivalent to jitter of 100 picoseconds, if my math is right - about 2.6 million seconds per month, about 23 million picoseconds per sample at a 44.1kHz sample rate. Folks who use the time sync utilities available in Unix-like OSs will recognize that time corrections of 10 seconds per month are not completely out of line.) Then there is whatever timing error might be introduced in the propagation of the signal through a cable, and finally the error in the PLL or whatever other mechanism is used to lock the timing of data out of the DAC's buffer to data output from the source.

 

Regarding the asynchronous case, in terms of errors from timers one only has to be concerned about the error in the "clock" at the DAC that times the data out of the DAC's buffer. But there are at least two other potential sources of jitter one ought to look at in my opinion in order to be thorough. One is whatever effect electrical noise or interference may have on the DAC's clock (which one can attempt to minimize insofar as possible with shielding, good power supplies, filtering, and galvanic isolation). The other is the effect on the signal's zero crossing point of electrical noise, fluctuations, or interference. See for example Figure 1 in this paper: http://www.amr-audio.co.uk/large_image/MAC%20OSX%20audio%20players%20&%20Integer%20Mode.pdf , and discussion of the external voltage reference under the heading "The Analog DAC" in this paper: www.esstech.com/PDF/sabrewp.pdf

[Jud]

For clarification of something that has kind of already been said above, I'd like to reword the claim:

 

Jitter manifests as audible ONLY at conversion points meaning ADC or DAC only.

 

Think about it. At these points any cumulative jitter is either irreversibly encoded (ADC) or now irreversibly part of the reconstructed analog signal (DAC). Until those stages jitter can be dealt with much like in the example Jud gave of transporting data from point A to point B by printing out the stream by hand with its terrible, terrible jitter spec and then scanning the printed bitstream with an OpticalCharacterRecognition scanner that can read off the data and output it as the exact same bitstream but now with vanishing low jitter.

 

Right, *but* - an adaptive input, by locking the timing at the DAC point to a previous point in the process, will in effect "import" the jitter at that previous point to the DAC point (plus whatever inherent jitter exists in the locking mechanism).

[RobbieC]

Right, *but* - an adaptive input, by locking the timing at the DAC point to a previous point in the process, will in effect "import" the jitter at that previous point to the DAC point (plus whatever inherent jitter exists in the locking mechanism).

 

Sure will.

[audiventory]

Hi Audiventory,

 

To those of us (namely me) who don't understand electrical engineering, can you explain the implication of line level differences between input and output as they relate to what we'll hear in our system?

 

Thanks,

 

Joel

 

Hi Joel,

 

Inaccuracy of technology produsing and tuning of AtoD an DtoA converters is reason of audio level errors. Main reason is dispersion of electronic component's characteristics.

 

Consequences is non-linear distortions, which we can't envisage and compensate.

 

Yuri