Peter Daniel said:
anatech said:
Both of you are correct.
Due to error correction and redundancy, errors may not affect the sound quality unduly, until muting occurs.
Of course, it is always desirable to have no errors at all.
It often seems misunderstood that a cd-player is analog reproduction followed by digital processing followed by an analog output stage.
Andy
Hi Andy,
Well, C2 errors are uncorrectable. The error may be then handled by doing one of the following. Nothing, flag the data and pass it. Muting for that interval (digital zero). Reinsert previous value or interpolate value from surrounding values.
This is before a major mute event occurs. Let's agree then that having accurate data is high fidelity and most desirable. The way the DSP section handles an error affects how we perceive it (If we perceive it at all). Perception will be the large variable, so let's ignore than sticky mess.
The chain of events for a CD player is analog RF signal, digital extraction (slice level, etc.), error detection and correction (Mr. Reed & Mr. Soloman and their code), whatever DSP is applied, then finally analog representation. We do, in fact, begin with an analog signal that represents digital information. The very first processes are analog in nature until the digital signal is extracted.
-Chris
Well, C2 errors are uncorrectable. The error may be then handled by doing one of the following. Nothing, flag the data and pass it. Muting for that interval (digital zero). Reinsert previous value or interpolate value from surrounding values.
This is before a major mute event occurs. Let's agree then that having accurate data is high fidelity and most desirable. The way the DSP section handles an error affects how we perceive it (If we perceive it at all). Perception will be the large variable, so let's ignore than sticky mess.
The chain of events for a CD player is analog RF signal, digital extraction (slice level, etc.), error detection and correction (Mr. Reed & Mr. Soloman and their code), whatever DSP is applied, then finally analog representation. We do, in fact, begin with an analog signal that represents digital information. The very first processes are analog in nature until the digital signal is extracted.
-Chris
anatech said:
Hi Chris
I am afraid we disagree here. I assume errors are corrected by the error corrector. If that ain't possible, it is time to throw the drive in the garbage can.
Truly, sonical differences, assumed data is identical (we checked that among various drives and copies) the only difference rem,aining is jitter.
best
Guido
Peter Daniel said:
I agree.
As digital supply I installed a gyrator "pre-regulated" ALWSR, from this work:
http://www.pinkfishmedia.net/forum/showthread.php?t=29501&highlight=capacitance+multiplier
...I copied like a monkey I recognize, but it works and sounds better than the PS offered by Daisy-laser or whatever the name.
I agree.
As digital supply I installed a gyrator "pre-regulated" ALWSR, from this work:
http://www.pinkfishmedia.net/forum/showthread.php?t=29501&highlight=capacitance+multiplier
...I copied like a monkey I recognize, but it works and sounds better than the PS offered by Daisy-laser or whatever the name.
QSerraTico_Tico said:
No, I wish it would be that easy
Don't ignore various crosstalk mechanisms (power supply, to mention one) that make part of the jitter to ripple through to the output (be it I2S or SPDIF).
Reclocking, separating powersupplies and decent layout are the route to "transparent" drives
best
Guido
Hi Guido,
Most CD's have inherent defects and a block error rate. Sometimes those errors can not be repaired because too many continuous blocks had errors. There is a chart that will tell you how many errors are correctable compared to the number of bit errors somewhere.
If all CD's could be read perfectly, they never would have had to flag the final data as good or bad. They would not have had to invent measures to deal with uncorrectable errors. Interpolation would never had been required.
But they are.
Every disc has uncorrectable errors that some transports make worse. This is a fact of life. Did you know that access to the C1 and C2 flags has not been possible for a while now? You would need to decode the data stream from the DSP to decode the C2 flag. The C1 flag is buried inside the chip, so forget it. The C2 flag = all is lost, or "I give up". 😀 Guido, this is a fact of life. I don't know how you are getting bit perfect reports. Possibly lots of DSP action to insert plausible digital values.
Anyway, there are lot's of errors in all good transports. The bad ones have more. Computer CDROMs just reread until it passes the CRC flag. That does not fill me with confidence, it just means the truth is well hidden. Maybe you couldn't know this unless you started CD servicing from the start.
Did you know that the Nakamichi OMS-5/7 servos were designed to play redbook only and reject CD's outside of this? There was a massive rework of the servo board to enable these machines to play the lesser CD's without ejecting the disc. Pretty funny if you ask me. All other machines have a pretty wide tolerance for what you try to play. Even recordable CD's were a problem The reflectivity is very different and this threw off the slice level. It's been a servo for a long, long time now. I guess what you don't know won't hurt you.
Guido, you do need to know these things in your line of work. Mind you, there is nothing you can do once the signal is presented to the DSP chip. Just don't assume all the errors have been corrected. I will accept that all errors have been dealt with in some manner.
-Chris 😉
Well then, throw them all out!
Most CD's have inherent defects and a block error rate. Sometimes those errors can not be repaired because too many continuous blocks had errors. There is a chart that will tell you how many errors are correctable compared to the number of bit errors somewhere.
If all CD's could be read perfectly, they never would have had to flag the final data as good or bad. They would not have had to invent measures to deal with uncorrectable errors. Interpolation would never had been required.
But they are.
Every disc has uncorrectable errors that some transports make worse. This is a fact of life. Did you know that access to the C1 and C2 flags has not been possible for a while now? You would need to decode the data stream from the DSP to decode the C2 flag. The C1 flag is buried inside the chip, so forget it. The C2 flag = all is lost, or "I give up". 😀 Guido, this is a fact of life. I don't know how you are getting bit perfect reports. Possibly lots of DSP action to insert plausible digital values.
Anyway, there are lot's of errors in all good transports. The bad ones have more. Computer CDROMs just reread until it passes the CRC flag. That does not fill me with confidence, it just means the truth is well hidden. Maybe you couldn't know this unless you started CD servicing from the start.
Did you know that the Nakamichi OMS-5/7 servos were designed to play redbook only and reject CD's outside of this? There was a massive rework of the servo board to enable these machines to play the lesser CD's without ejecting the disc. Pretty funny if you ask me. All other machines have a pretty wide tolerance for what you try to play. Even recordable CD's were a problem The reflectivity is very different and this threw off the slice level. It's been a servo for a long, long time now. I guess what you don't know won't hurt you.
Guido, you do need to know these things in your line of work. Mind you, there is nothing you can do once the signal is presented to the DSP chip. Just don't assume all the errors have been corrected. I will accept that all errors have been dealt with in some manner.
-Chris 😉
Here is a question in regard to error correction:
In the early CD-years, I heard that some of the cheap players, including some portables, didd'nt implement error correction or did only a simplified, partial implementation in order to save cost.
Is the interleaved Reed-Solomon error correction really fully implemented on all relvant chips used in the players of the last 10 years or so? Actually, this requires quite a lot signal processing.
Kurt
In the early CD-years, I heard that some of the cheap players, including some portables, didd'nt implement error correction or did only a simplified, partial implementation in order to save cost.
Is the interleaved Reed-Solomon error correction really fully implemented on all relvant chips used in the players of the last 10 years or so? Actually, this requires quite a lot signal processing.
Kurt
Hi Kurt,
You wouldn't.
-Chris
Correct. Some were reported to have only used 12 and 14 bit DACs also. I'm sure they could get away with it easily enough. Also, often the DSP simply passed the bad data with a flag or muted that sample(s).
Yes, they have to in order to get the information off the CD. They had no choice with that. Besides, if your were a chip manufacturer, why would you attempt to sell DSP chips that got the audio out but didn't take the extra small step to do the rest of the error correction?
You wouldn't.
It's part of the spec. and only requires a bit of memory. The processing is already known so it isn't really that hard for the chip makers.
-Chris
Oh no. I was trying to stay out of this thread.
Just thought I'd put my findings/experiences into the melting pot.
I have a CDM9 based Philips player that I have stripped down to basically just the CDM9, the decoder, and a transmitter for the I2S data to go to an external DAC.
The master clock is in the external DAC and I feed it back to the 'transport'.
I do fully intend to do this with a proper BNC connection one day, but at the moment, its rather tastefully done using 18 inches of twisted pair and a few screw terminal 'choc blocks'. In fact Martin Clark saw it a few weeks ago and I got the impression he was thoroughly amused by my current implementation 😉.
I suspect the clock at the decoder end is particularly shoddy. However, it works absolutely fine! I was impressed that it worked at all. It definitely responds to the 'digital cliff' where, if the signal gets too bad (below a certain threshold) it suddenly doesn't work at all. I know that, because of the problems I'm currently having implementing my 50 ohm BNC driver. However, just above the threshold, with the poor BNC link, or with the better twisted pair (may not be perfect, but it never drops out), I see my error light behave the same. Typically the best test I can easily do is with a CD that doesn't light the error LED at all - and with either clock link, it simply doesn't light.
Not very scientific, I could use a TTL counter of some form instead, but I believe that the clock to the decoder can be pretty crude compared to that at the DAC.
Having said that, I am synchronously reclocking the I2S after the digital filter, before it goes into the DAC, so I might be masking stuff.
I think the most important thing for a transport is that it delivers the data as error free as possible (hopefully completely error free, but that depends on the condition of the disc), and that it doesn't pollute power rails etc - which can influence the performance of other parts of the circuit.
The next mod I'll do to my transport (if I ever get round to it) is to clean up the regulation and filtering on its power rails, and loads of bitumen-esque dampening on the enclosure (hopefully to cut down on vibrations and make the life of the servos and respective PSUs easier).
Guido, I've heard you mention pit-jitter. What exactly do you mean by it? Its something I haven't directly come across as a term and would like to investigate it. I currently think that jitter is most important at the DAC end - unless it can lead to erroneous data in a transport?
Just thought I'd put my findings/experiences into the melting pot.
I have a CDM9 based Philips player that I have stripped down to basically just the CDM9, the decoder, and a transmitter for the I2S data to go to an external DAC.
The master clock is in the external DAC and I feed it back to the 'transport'.
I do fully intend to do this with a proper BNC connection one day, but at the moment, its rather tastefully done using 18 inches of twisted pair and a few screw terminal 'choc blocks'. In fact Martin Clark saw it a few weeks ago and I got the impression he was thoroughly amused by my current implementation 😉.
I suspect the clock at the decoder end is particularly shoddy. However, it works absolutely fine! I was impressed that it worked at all. It definitely responds to the 'digital cliff' where, if the signal gets too bad (below a certain threshold) it suddenly doesn't work at all. I know that, because of the problems I'm currently having implementing my 50 ohm BNC driver. However, just above the threshold, with the poor BNC link, or with the better twisted pair (may not be perfect, but it never drops out), I see my error light behave the same. Typically the best test I can easily do is with a CD that doesn't light the error LED at all - and with either clock link, it simply doesn't light.
Not very scientific, I could use a TTL counter of some form instead, but I believe that the clock to the decoder can be pretty crude compared to that at the DAC.
Having said that, I am synchronously reclocking the I2S after the digital filter, before it goes into the DAC, so I might be masking stuff.
I think the most important thing for a transport is that it delivers the data as error free as possible (hopefully completely error free, but that depends on the condition of the disc), and that it doesn't pollute power rails etc - which can influence the performance of other parts of the circuit.
The next mod I'll do to my transport (if I ever get round to it) is to clean up the regulation and filtering on its power rails, and loads of bitumen-esque dampening on the enclosure (hopefully to cut down on vibrations and make the life of the servos and respective PSUs easier).
Guido, I've heard you mention pit-jitter. What exactly do you mean by it? Its something I haven't directly come across as a term and would like to investigate it. I currently think that jitter is most important at the DAC end - unless it can lead to erroneous data in a transport?
Also, I'm going to express my ignorance (if I haven't done already 🙂 )...
How do you look at the eye pattern?
Can it be done with just an oscilloscope?
(I assume its the data stream out of the RF amplifier on an oscilloscope, maybe without triggering so that it overlays itself on the screen to make the pattern?)
How do you look at the eye pattern?
Can it be done with just an oscilloscope?
(I assume its the data stream out of the RF amplifier on an oscilloscope, maybe without triggering so that it overlays itself on the screen to make the pattern?)
Could someone explain exactly how a magnetic clamping device affects reproduction as opposed to a non-magnetic clamp (eg brass) ??
Andy
Andy
Hi Andy,
You know the answer, you're fishing for entertainment now! 😀
I didn't feel like poking that bee hive. Next thing you know this will go downhill like a cable thread.
Thanks rfbrw,
The only comment I'll make is that the amplitude can vary from design to design. To see this, you simply connect your oscilloscope the the test point marked "RF" or "eye". Set your 'scope for 0.5uS/div for time and start at 0.5 V/div for amplitude. Normal triggering.
Now this diagram shows what I actually see on a Nakamichi OMS 5 or OMS 7. Most other machines have more noise and some jitter side to side. So don't expect most other players to have this nice sharp example of an eye pattern. I have attached a shot of a real eye pattern. This one is an excellent example (better than average) from a VAM 1202 on the RF board. The make will remain nameless. At any rate, this is much better than I usually see on these. Normally, a KSS-210A type will have a cleaner looking eye pattern.
-Chris
LOL!
You know the answer, you're fishing for entertainment now! 😀
I didn't feel like poking that bee hive. Next thing you know this will go downhill like a cable thread.
Thanks rfbrw,
The only comment I'll make is that the amplitude can vary from design to design. To see this, you simply connect your oscilloscope the the test point marked "RF" or "eye". Set your 'scope for 0.5uS/div for time and start at 0.5 V/div for amplitude. Normal triggering.
Now this diagram shows what I actually see on a Nakamichi OMS 5 or OMS 7. Most other machines have more noise and some jitter side to side. So don't expect most other players to have this nice sharp example of an eye pattern. I have attached a shot of a real eye pattern. This one is an excellent example (better than average) from a VAM 1202 on the RF board. The make will remain nameless. At any rate, this is much better than I usually see on these. Normally, a KSS-210A type will have a cleaner looking eye pattern.
-Chris
Attachments
Hi maxlorenz,
Almost all CD players use a magnetic clamp these days. There were some manual "screw down" types. People will pay more to get less you know.
Do you know what manufacturers have discovered about customers? You can't trust them to place the CD properly in the tray! One Nakamichi 7 disc stacker was so plagued by this problem that they created new software to shake the tray as it went back in. We called it the "shaky-shaky" mechanism. That was the first 7 CD units they made, like the MB-1S. Alpine went through heck with the first 6 CD changers meant for car trunks. You have no idea how many customers jammed the CD's in the cartridge. This is beyond what happens when changing CD's while driving over washboard.
-Chris
Sadly .............. yes.
Almost all CD players use a magnetic clamp these days. There were some manual "screw down" types. People will pay more to get less you know.
Do you know what manufacturers have discovered about customers? You can't trust them to place the CD properly in the tray! One Nakamichi 7 disc stacker was so plagued by this problem that they created new software to shake the tray as it went back in. We called it the "shaky-shaky" mechanism. That was the first 7 CD units they made, like the MB-1S. Alpine went through heck with the first 6 CD changers meant for car trunks. You have no idea how many customers jammed the CD's in the cartridge. This is beyond what happens when changing CD's while driving over washboard.
-Chris
Hi Chris
Displaying the eye pattern:
"To see this, you simply connect your oscilloscope the the test point marked "RF" or "eye". Set your 'scope for 0.5uS/div for time and start at 0.5 V/div for amplitude. Normal triggering."
To get an even better view, you might want to use external triggering with the sampling clock. I'm not sure though, if it easily possible to locate the clock which is used to sample the eye pattern and then apply this as an external trigger. And maybe a trigger buffer might be required to avoid capacitive loading by the trigger cable and scope sync input?
Kurt
Displaying the eye pattern:
"To see this, you simply connect your oscilloscope the the test point marked "RF" or "eye". Set your 'scope for 0.5uS/div for time and start at 0.5 V/div for amplitude. Normal triggering."
To get an even better view, you might want to use external triggering with the sampling clock. I'm not sure though, if it easily possible to locate the clock which is used to sample the eye pattern and then apply this as an external trigger. And maybe a trigger buffer might be required to avoid capacitive loading by the trigger cable and scope sync input?
Kurt
anatech said:Hi Andy,
LOL!
You know the answer, you're fishing for entertainment now! 😀
I didn't feel like poking that bee hive. Next thing you know this will go downhill like a cable thread.
-Chris
Honestly ! It was a serious question.! 😉 😉
I will have to start another thread, now !
Andy
Hi Andy,
Hi Kurt,
Normal triggering has always worked well for me on every single CD player I've run across so far. Now, thinking about it a bit... A trigger from an internal clock may give a "messier" looking pattern (high jitter). The clock is not directly locked to the data rate of the CD. To get around this problem, the data is clocked into ram using a PLL and clocked out using the system clock. The difference between the PLL and system clock generates the disc motor correction signal for speed. So if you use anything but the actual eye pattern you will not be synced properly. Therefore there will be lots of time scale errors.
Hi maxlorenz,
Who? Me? 🙂
-Chris
Okay, I dare you! 😉
Hi Kurt,
That isn't necessary. The normal triggering works great. Doing anything else would only make the measurements more of a pain. If you need to go that far, the eye pattern is not stable enough anyway (so all is lost).
Normal triggering has always worked well for me on every single CD player I've run across so far. Now, thinking about it a bit... A trigger from an internal clock may give a "messier" looking pattern (high jitter). The clock is not directly locked to the data rate of the CD. To get around this problem, the data is clocked into ram using a PLL and clocked out using the system clock. The difference between the PLL and system clock generates the disc motor correction signal for speed. So if you use anything but the actual eye pattern you will not be synced properly. Therefore there will be lots of time scale errors.
Hi maxlorenz,
Who? Me? 🙂
-Chris