Ping: John Curl. CDT/CDP transports

Status
Not open for further replies.
Hi TheGimp,
I'm sure it was in whatever state it existed in then. Don't forget that the Japanese were committing the design to silicon, and tons of them were working on the same thing, rushing to market. It would make sense to complete each subsection and hook it up later. Once they figured out what worked and what didn't, they did consolidate the design into fewer and fewer chips. Don't forget too, what working in the lab didn't in the field. They had problems and failures left, right and center. Motors were sticking, laser sleds were sticking. They went through hell because they just had to rush everything to market. Those early machines were the best examples of the mechanical transport ever. They were paranoid over the problems, so they made everything, and I mean everything, adjustable. Servos and mechanical assemblies were all new stuff combined in the consumer market. That is also why those early machines were so expensive. Now, if the Nakamichi mechanism were only coupled with today's electronics (and a magnetic clamp system), you would have the very best CD transport ever made. It's a pity that Nakamichi didn't make multi-track recording machines! They would have given Studer and Tascam a serious run for their money, and probably have won that race too. I worked on all that stuff, so I can say this with conviction.

Anyway, new technology that had problems. They built everything modular (from a manufacturing stand point). Each line had several different mechanisms and chip sets, and they watched each perform. Magnetic CD chucks were an obvious improvement as the pressure clamp stuff wore out quickly. Same for both disc (spindle) and feed motors as they wore out quickly. Even the sled geometry on the rails - and the rails had problems. Nylon injected around steel base plates cracked quickly and threw alignment out (no kidding). Why is this important from an electrical standpoint? Because, they didn't know what was at fault and tried to "fix" the servos as well before accepting that motors had the wrong bearings. Everything was looked at for every single failure. They used silicon to patch servo and mechanical issues also.

That was an interesting time in consumer electronics. Now when they mess up, there is no excuse as they made those mistakes already.

-Chris
 
I guess I've nudged this a little OT in discussing early 80 technology, considering the systems today ought to be orders of magnitude better in performance.

I think the issue can be confused by considering the D/A converter when the real issue is the transport which delivers the S/PDIF data stream.

In my mind the D/A converter can easily contribute to sonic differences due to filter selection, etc, so I'm not so much interested in discussing it.

I suggest leaving driver/receiver impedance miss-match out of the discussion as I believe it has been adequately addressed.

What I'm concerned with is whether or not the transport mechanism and associated control logic up to the S/PDIF output can make a difference when properly implemented.

This can be broken down further to two topics:

(1) decoding

(2) jitter

I'll address my opinion (and that is all it is) on jitter first.

The D/A converter is going to use it's own clock and Phase Lock Loop circuit to sync to the incoming data stream. Given that it uses a a high stability clock reference in the phase lock loop, and it uses the clock at a higher frequency (16x or greater) to determine the sampling position to recover the data, the resulting re-clocked data should not exhibit significant jitter. So jitter should not be an issue.

This leaves the original decoding circuit (R/S), microprocessor, buffer, and output circuitry.

What in this hardware is going to contribute to corruption of the data which can be perceived as a sonic difference?
 
Hi TheGimp,
Yes, the transport and servo sections are critical for recovering good data from the CD. I've seen this first hand over many years. Correct the alignment plus whatever mechanical issues there are with the transport (including the servos), and the sound quality goes up. Customers have reported this for years without any prodding from us.

Your data starts off as an RF waveform that we look at and see as an eye pattern. Impairments will usually stress the eye pattern, or cause shifting back and forth as flutter - jitter. The envelope may vary in strength or have gaps that you can also see on the tracking servo output. It all ties together. Servos <-----> Eye pattern. Problems in the eye pattern cause the wrong symbols to be decoded, even on a perfect disc that the player doesn't track well. This is more common than you might think. Thank god for error correction. But basically, garbage in, garbage out. It starts with the transport assembly pulling off a clear, steady RF signal that we see as an eye pattern. From that, your data is decoded.

-Chris

Edit: You can't separate jitter from decoding. Either a timing or level error will cause decoding problems.
 
Last edited:
TheGimp, that is the way I see it too. Every clock cycle just moves the one's and zero's through the logic. My guess is that the C1-C2 decoding is in the tens of clock cycles to process and the processing time is always the same.

The DSP has to analyze the data before and after an un-correctable, calculate new data and replace the bad. The kind of thing that you might want to do with a CPU process. Everything being good, the DSP will not be active at all.

Could the DSP also be used for other tasks like FR?
 
Hi Scott,
You're going to hurt your old noodle thinking this stuff up. If you can get to C2 TP, just monitor it. A good frequency counter in add the pulses mode might give you an idea of what's going on and when. The early CD players did have that as a test point.

This is like pulling teeth, I still don't think that the meaning of the pins on the old IC's has been definitively determined. At this point I doubt even my old observations, after all I got the pin to go high by putting my finger on the disk which would include muting due to loss of tracking. Simply put my hypothesis is interpolations in normal use with a decent player by someone that takes at least reasonable care of their CD's is 0 to 10 or so for an entire CD.

Two people on the hydrogenaudio forum have done the experiment of SPDIF recording and alignment of the data with NO errors i.e. bit perfect. But of course one could say this is a fortuitous accident.
 
Hi Scott,
I agree, you're probably correct in how many hard C2 errors one should expect. That hardware pin is the C2 flag in the older players. Monitoring this test point left an impression on me, and that impression was that all was not alright in the world of indestructible CDs. I'll argue that "bit perfect", while possible, isn't to be relied on.

Ever hear the phrase "fat, dumb and happy"? That's what goes through my mind when I hear the phrase "bit perfect". Maybe yes, and maybe no. With concealment, it is highly improbable that C2 errors will be noticed by anyone enjoying music on their CD, but that doesn't mean that playback was "bit perfect", not by a long shot.

My only issue is with that phrase, because I don't believe for a minute that the average playback situation is "bit perfect". Does it matter? Nope, not a bit. Enjoy the music, but the assumption that music CDs are "bit perfect" is a pretty big leap.

Remember when the accepted value of the Volt was changed? For all practical purposes, it's still the same old Volt we know and love - but way down in the decimals, the value changed. It doesn't affect my work, but that doesn't mean it didn't happen. Don't ask me the details, those memories are lost to time. I just remember the event occurred.

I wouldn't lose sleep over these things. But the record should set straight, then go on living and enjoy the music. For those of you who do like to worry, there is an error rate for data in memory, on hard drives and other types of data storage. Ain't nothing perfect in this world, and at some point, that one bit might matter. 🙂

-Chris
 
Got any of the older chip references please, i want to have a look for some data sheets...
Found this that was interesting regarding master disc quality.
Explaining Common CD Errors

From further reading I tend to err on the side of bit perfect with a decent CD, this was discussed in detail a few years ago, probably on another thread, I will try and find the info as someone involved with CD production mastering etc gave some views as did others, again the conclusion was bit perfect.
 
Well, some CDs may not be bit perfect even after both stages of error processing. But the rate of errors, unless the drive is very badly aligned, or faulty, will be so low as to be most likely inaudible - and certainly would not create the sort of repeatable differences in sound across whole pieces of music that some say are the result of the transport.
 
Remember when the accepted value of the Volt was changed? For all practical purposes, it's still the same old Volt we know and love - but way down in the decimals, the value changed. It doesn't affect my work, but that doesn't mean it didn't happen. Don't ask me the details, those memories are lost to time. I just remember the event occurred.

Internet to our rescue 🙂
The definition of Volt (a derived unit) remains the same.
Between 1987- 1990 the National Metrology & Primary Labs started to adopt the Array of Josephson Voltage Standard as the accepted realization of the unit.
There isn’t an accepted value of Volt that has changed .
What you are referring to is that there are Voltage values accurate to many decimal places that is realized in and agreed upon all National Metrology Labs
Now, the achieved measured differences btn the primary metrology labs is less than 1 part in 10E9

https://en.wikipedia.org/wiki/Volt
https://en.wikipedia.org/wiki/Josephson_voltage_standard
https://web.archive.org/web/20160611071455/http://www.nist.gov/pml/history-volt/
http://nvlpubs.nist.gov/nistpubs/jres/095/jresv95n3p237_A1b.pdf
https://www.nist.gov/news-events/news/2013/04/primary-voltage-standard-whole-world
George
 

Attachments

  • Volt unit.PNG
    Volt unit.PNG
    241.3 KB · Views: 112
  • decimals.PNG
    decimals.PNG
    50.9 KB · Views: 111
  • Uncertainties.PNG
    Uncertainties.PNG
    22.3 KB · Views: 111
marce, according to the datasheets I have the following Sanyo controllers have various flags.
LC78622E (1997) has a C2 flag out, but not a C1 flag out.
LC78620E (1999) has EFLG which combines C1 and C2.
LC78626K (1999) EFLG out.
LC78601E (1998) EFLG output, but only for test mode. Muted during normal operation.
 
Two people on the hydrogenaudio forum have done the experiment of SPDIF recording and alignment of the data with NO errors i.e. bit perfect. But of course one could say this is a fortuitous accident.
And of course MY experiments doing the exact same thing with various signals and music are also a fortuitous accident. The experiments that I have offered, several times, to help anyone here reproduce.

But my offers continue to fall on deaf ears. No one really wants to do the work.
 
Yes, I read that. And I agree.

My test is more for the bloody-minded pedant, who wants to see if things really, really match sample by sample, and who will not rely on the error pins. The file recorded from a device really can be compared to the original file, bit by bit. Either with checksum, or by nulling.

Getting the files lined up exactly is the tedious part. Bill Waslo could probably do it with software.
 
I would do it but having worked on so many digital interfaces that use a variety of transmit coding's (many phase encoding) over the years I have to put myself in the "bit perfect transmission" and "bits are bits" corner.
I have to wonder whether some in the hobby are masochistic, why use an old fashioned medium when for far less than a "high end" CD transport you can buy a PC, rip your CD's and stream the data,even wireless to every room if you want...
Anyway here's hoping as I press send that I am blessed with a fortuitous accident and the data arrives in a timely and readable manner.
 
My test is more for the bloody-minded pedant

He can do his own test. And maybe a miracle will occur and he'll describe it and the results in sufficient detail and disclosure for replication. I'm not holding my breath, though.

I'm frankly through with exerting any effort to prove that electrons are negative and that gravity follows an inverse square law just to please flat-earthers or secretive commercial guys who have a financial stake (and will then move the goalposts or kick up dust even more creatively).
 
Yes, I read that. And I agree.

My test is more for the bloody-minded pedant, who wants to see if things really, really match sample by sample, and who will not rely on the error pins. The file recorded from a device really can be compared to the original file, bit by bit. Either with checksum, or by nulling.

Getting the files lined up exactly is the tedious part. Bill Waslo could probably do it with software.

The Beatles boxed set of mono CD's (for example) has bit exact left and right channels, since there is no recognition of mono in Redbook I would assume it would self align. Anyone with an SPDIF input can do the test with Audacity, etc. I have a friend with a set maybe I'll get on it. I might have some old folk CD's that were not enhanced for some fake stereo too.
 
Last edited:
I would do it but having worked on so many digital interfaces that use a variety of transmit coding's (many phase encoding) over the years I have to put myself in the "bit perfect transmission" and "bits are bits" corner.
I have to wonder whether some in the hobby are masochistic, why use an old fashioned medium when for far less than a "high end" CD transport you can buy a PC, rip your CD's and stream the data,even wireless to every room if you want...
Anyway here's hoping as I press send that I am blessed with a fortuitous accident and the data arrives in a timely and readable manner.

Exactly. Bits are bits. Who uses CD players any more anyway?
And - miraculously, your post arrived in a fully readable state....
 
marce, according to the datasheets I have the following Sanyo controllers have various flags.
LC78622E (1997) has a C2 flag out, but not a C1 flag out.
LC78620E (1999) has EFLG which combines C1 and C2.
LC78626K (1999) EFLG out.
LC78601E (1998) EFLG output, but only for test mode. Muted during normal operation.

Thank you, from the fine print all is clear. Both C1 and C2 can correct EXACTLY up to two symbols and there is a distinctly different code for failure. Who would have thought it was in the manual all along. This was the LC78622E, you just need to go through the whole DS to find it.
 

Attachments

  • ef.jpg
    ef.jpg
    23.4 KB · Views: 106
Last edited:
I'm frankly through with exerting any effort to prove that electrons are negative and that gravity follows an inverse square law just to please flat-earthers or secretive commercial guys who have a financial stake (and will then move the goalposts or kick up dust even more creatively).

People who hold certain beliefs as sacred are unlikely to change those beliefs. Commercial guys who are psychopaths aren't going to care if they are lying and it hurts other people. In either case, people usually aren't pleased with efforts to educate them into changing. Maybe it pleases them if you stop trying?
 
Status
Not open for further replies.