Starting at post #28 on page 3 there is a lot of information for several pages on disc reading, eye patterns and error correction. Pay lot of attention to Anatech's posts.
http://www.diyaudio.com/forums/digi...s-long-gone-let-us-build-one-ourselves-3.html
Error correction does what it says. I know that in this age of post-factual advertising we are expecting words not to mean what they seem to mean, but in this case they mean literally what they say. Error corrected data is identical to the original data.
Jan
Jan
Good idea. Those of us who have looked for interpolated errors find perhaps one in several hours of playing. That's 1/44,100 of a second of error (and interpolated) in several hours, hardly something that will change the sound.
No. Jitter is unrelated to error correction. It might be worth taking a bit of time learning about digital audio. Books and papers by people like Ken Poehlman and Bob Adams are good starting points and will allow you to quickly become more knowledgeable than audio magazine chimps.
I understand that most of this work came after 1968.
Complete nonsense. I wondered how long it would be before someone came up with this myth.stvnharr said:
To clarify: a CD player does not read data, check it for errors, use the raw data if it is OK, or use an error-corrected version when necessary; that is the way a human would do it. No, it merely feeds the raw data into the decoding logic and perfect data pops out the other side. It does no extra work, consumes no extra electricity, spends no more time 'thinking'. As far as the decoding logic is concerned, any input data pattern which results in a particular output pattern is as good as any other input pattern giving the same output.
It is only when this process fails (which it rarely does) that interpolation is used - maybe once an hour or so? It knows it has failed when an input pattern does not correspond to any output pattern. Then the error flag is raised and interpolation takes place.
The error corrected data is never the same as the disc data - it has been decoded! It is almost always the same as the original data before encoding and recording took place.
You now understand why this is a daft thing to say?
People really ought to do some reading about CD. It is a very clever system. Then they might realise that their concerns are based on myths and ignorance.
Indeed. Bits is bits 
and bits don't have jitter as such. They just sit there being 0 or 1 and having a ball.
It's when you start to send them over a wire that they may get the shakes and, err, become jittery. 😎
Edit: I believe that a lot of the confusion appearing here is caused by the fact that for an 'audio guy' it is not obvious that there's no audio on a CD. There's a bunch of bits and bytes and frames and blocks and preambles and what have you that needs to be stored, read, decoded and D-A converted to be turned into audio. So as long as the data can be recovered intact, with whatever process used, you're home free.
I'm sure there are many possible methods to code the audio and to store it on a CD and do error correction and redundancy etc. They just chose, for whatever reason, for this particular method. And it ONLY worries about getting the bits restored at the end. During this process, nobody cares about 'audio' because there's nowhere audio in sight!
Edit2: If you understand this, and think about it a bit, you realize how nonsensical a claim is that 'this transport sounds warmer than that'; or that 'this transport has more treble that the other'. Try to understand what needs to be done to the data to get more 'warmth' or 'sparkle' - the mind boggles and such a claim only exposes the ignorance of whoever makes it.
Jan
and bits don't have jitter as such. They just sit there being 0 or 1 and having a ball.It's when you start to send them over a wire that they may get the shakes and, err, become jittery. 😎
Edit: I believe that a lot of the confusion appearing here is caused by the fact that for an 'audio guy' it is not obvious that there's no audio on a CD. There's a bunch of bits and bytes and frames and blocks and preambles and what have you that needs to be stored, read, decoded and D-A converted to be turned into audio. So as long as the data can be recovered intact, with whatever process used, you're home free.
I'm sure there are many possible methods to code the audio and to store it on a CD and do error correction and redundancy etc. They just chose, for whatever reason, for this particular method. And it ONLY worries about getting the bits restored at the end. During this process, nobody cares about 'audio' because there's nowhere audio in sight!
Edit2: If you understand this, and think about it a bit, you realize how nonsensical a claim is that 'this transport sounds warmer than that'; or that 'this transport has more treble that the other'. Try to understand what needs to be done to the data to get more 'warmth' or 'sparkle' - the mind boggles and such a claim only exposes the ignorance of whoever makes it.
Jan
Last edited:
To add coals to this fire I offer this. Mark Porzilli along with George Bischoff (RIP) introduced the Memory Player about a decade ago. I can't locate Mark's original writings on this but I recall he showed that the CD error correction process was implicated in some of the perceived shortcomings of CD replay. Anyway the product these days can be found here... http://www.thememoryplayer.net/about-usIndeed. Bits is bits
It's when you start to send them over a wire that they may get the shakes and, err, become jittery. 😎
Edit: I believe that a lot of the confusion appearing here is caused by the fact that for an 'audio guy' it is not obvious that there's no audio on a CD. There's a bunch of bits and bytes and frames and blocks and preambles and what have you that needs to be stored, read, decoded and D-A converted to be turned into audio. So as long as the data can be recovered intact, with whatever process used, you're home free.
I'm sure there are many possible methods to code the audio and to store it on a CD and do error correction and redundancy etc. They just chose, for whatever reason, for this particular method. And it ONLY worries about getting the bits restored at the end. During this process, nobody cares about 'audio' because there's nowhere audio in sight!
Edit2: If you understand this, and think about it a bit, you realize how nonsensical a claim is that 'this transport sounds warmer than that'; or that 'this transport has more treble that the other'. Try to understand what needs to be done to the data to get more 'warmth' or 'sparkle' - the mind boggles and such a claim only exposes the ignorance of whoever makes it.
Jan
Sent from my Nexus 7 using Tapatalk
One more while I'm at it. Most CD players show time remaining and/or track title while playing. Where do you think that info comes from? Just a bunch of bits on the CD, and these bits are read and extracted exactly the same way as the ones that get eventually turned into music. They are processed and decoded in a different way because hey, they're not encoded audio, they are encoded text and numbers.
So they are susceptible to the same read errors, and the same error correction as any other bit. Sooo, if there are these errors that everybody worries about, how come I never saw a title on a display saying '11 CC'? Or 'Maria Cbllas'?
Think about that for a while. 😉
Jan
So they are susceptible to the same read errors, and the same error correction as any other bit. Sooo, if there are these errors that everybody worries about, how come I never saw a title on a display saying '11 CC'? Or 'Maria Cbllas'?
Think about that for a while. 😉
Jan
Indeed. Bits is bits
It's when you start to send them over a wire that they may get the shakes and, err, become jittery. 😎
Which is at the same time correct and nevertheless a bit misleading, as the retrieved bitstream quite often will be not only stored but processed for real time analog audio output. And this analog output might indeed be different if additional error correction was needed, although i´d consider it to be more likely if inside a cd player.
Not necessarily so, normal wisdom says what is possible will happen even if it shouldn´t......
According to Philips both Sony and Philips had in the beginning different coding and correction schemes providing different strengths and weak points, so both together developed in a couple of months a newer strategy which combined the advantages was used in the end for encoding and distributing the data.
Which is circular logic (or maybe something like a plausibility fallacy); the premise "data has to be changed to provoke a warmer sound" isn´t true so the conclusion isn´t either. 🙂
Please explain. When Stereophile (or any other reviewer) presents the fact that a CD player successfully negotiated a test CD simulating holes and scratches, what do you think they mean?
Last edited:
No. The result of decoding/error correction is either correct data or a flag saying the data could not be recovered. There is no extra error correction to be done, so the analogue output cannot be different whether the bit pattern read from the disc is the intended pattern or a different pattern which decodes to the same music data. It is extremely unlikely that the pattern will decode to different music data - maybe this happens once every few weeks of playing?Jakob2 said:
On the contrary, it is necessarily so. The player does not read data, decode it, then decide whether it had an error and so has to apply error correction. The decoding does the error correction too.
No circular logic. All the reading and decoding stuff has to do is recover the data (in the right order, of course!). Then it is clocked out to a DAC. Any change in sound must come from either the data or the timing as there is nothing else (assuming competent design).
Alfred Jarry would wholeheartedly agree.
Now, if only you would care to read and understand the Solomon Reed error correction mechanism.
What would be interesting if for Chris to misadjust a CD player to the point where its 'on the limit' of failing to correctly read the disk and compare the DAC output against another which he has adjusted to the best of his ability. sure he wouldn't need too many beer tokens to do that...
I don´t know exactly what _they_ mean (in most cases such presentations are not accompanied by thoroughful measurments), but _i_ meant that the analog output - if processed in real time - _can_ be different even if the data is correct (i.e. successfully corrected), which is a well known fact, isn´t it?
If the disc is compromised then nearly inevitebly the control circuitry will have to work harder to track/retrack/focus and will do some additional work to provide corrected data. All that might have an impact to the analog signal at the output.
In your case of a typical test CD with defects on the surface and in the information layer this will be quite obvious...
In fact, your quite similar assertion in #347 :
" No, it merely feeds the raw data into the decoding logic and perfect data pops out the other side. It does no extra work, consumes no extra electricity, spends no more time 'thinking'."
was one motivation of my post.
As before, i have to ask, if that what you´ve asserted is really ensured?
Because the ICs do indeed something different dependent on data integrity.
For the second reason see my answer to scott wurcer above.
Freshman´s hybris.... 😎
- Status
- Not open for further replies.