Posted by glen herrmannsfeldt May 14, 20082008-05-14
Steve Underwood wrote:
(snip)

> Actually 2k of RAM was not cheap in 1982, but neither were any of the > other components in a CD player. They were quite expensive machines.
CDs are limited to 99 tracks because the number is stored in 8 bit BCD instead of binary to save the cost of the binary to BCD decoder in CD players. -- glen
Posted by Jerry Avins May 11, 20082008-05-11
Piergiorgio Sartor wrote:
> Jerry Avins wrote: > >> Not instantaneously, but we need to control only the sum over 1/150 >> sec. That isn't difficult. > > The problem is that there is a disc inside, > which is unknown (except for music on it). > One of the points claimed was that the printing of > the disc was not good enough, i.e. the clock in the > data was jittering at the source. > Note that, again, this was a claim. > In other words, in theory a disc should generate, at > a given tangential speed, a fixed clock. > The claim was that, due to imperfections in pressing, > the disc, at a given tangential speed, generates an > unstable, or jittering, clock. > >> ?? The pickup is a photodiode. The excitation is a laser diode. It >> either sees the pits or it doesn't. The instantaneous data rate is set >> by the disc speed, not the pickup. What model do you have in mind? > > I'm sorry, with pick-up I meant the optics and the > motor, all the block which physically holds the disc, > including the pre/post signal amplifiers. > >> The input "clock" is the disc itself, not the pickup. There is no >> feedback directly from the output clock. The feedback is from how full >> the buffer is. > > And the buffer size is a function on how much > this clock can change. > So, if you want to minimize the size (not below > the minimum necessary), you can think to allow > some clock variation in the output of the FIFO. > Of course, such clock variations can be also > caused by poor crystals, instead of design choices. > >> That buffering is usually look-ahead, so the block can be read again >> if errors can't be corrected the first time around. > > Not on a CD, you could not read the buffer again. > The data was streamed from the disc without real > possibilities of re-reading. > Or you meant something else? > Nowadays is different, but at that time the concept > was to have a stream of bits. > >> The clock is crystal controlled; no compromise there. "Pickup" and >> "stability" (timing stability, anyway) don't belong in the same sentence. > > As I wrote above, sorry for the confusion, with pickup > I meant the complete mechanics, including optics and > the first signal processing.
My vibration-resistant player read well ahead, keeping two copies of each chunk. When the head was jatted by a bump, it simply read the chunk again. There was rarely an audible skip. No CD player buily into a car radio I used has ever audibly skipped that I know. Vibration-isolating mounting accounts for only a small part of that. Buffering accounts for the rest and is what made the Walkman CD player possible. I know a little about turntable vibration. I once built an LP phonograph for a sound truck that didn't produce audible wow when cornering fast or skip the tonearm when slamming into potholes. (I proofed it for the customer in a jeep with two wheels on the ballast and two wheels on the cross ties of a railroad spur. Rossini's William Tell overture never sounded so sweet!) Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Posted by Piergiorgio Sartor May 11, 20082008-05-11
Jerry Avins wrote:

> Not instantaneously, but we need to control only the sum over 1/150 sec. > That isn't difficult.
The problem is that there is a disc inside, which is unknown (except for music on it). One of the points claimed was that the printing of the disc was not good enough, i.e. the clock in the data was jittering at the source. Note that, again, this was a claim. In other words, in theory a disc should generate, at a given tangential speed, a fixed clock. The claim was that, due to imperfections in pressing, the disc, at a given tangential speed, generates an unstable, or jittering, clock.
> ?? The pickup is a photodiode. The excitation is a laser diode. It > either sees the pits or it doesn't. The instantaneous data rate is set > by the disc speed, not the pickup. What model do you have in mind?
I'm sorry, with pick-up I meant the optics and the motor, all the block which physically holds the disc, including the pre/post signal amplifiers.
> The input "clock" is the disc itself, not the pickup. There is no > feedback directly from the output clock. The feedback is from how full > the buffer is.
And the buffer size is a function on how much this clock can change. So, if you want to minimize the size (not below the minimum necessary), you can think to allow some clock variation in the output of the FIFO. Of course, such clock variations can be also caused by poor crystals, instead of design choices.
> That buffering is usually look-ahead, so the block can be read again if > errors can't be corrected the first time around.
Not on a CD, you could not read the buffer again. The data was streamed from the disc without real possibilities of re-reading. Or you meant something else? Nowadays is different, but at that time the concept was to have a stream of bits.
> The clock is crystal controlled; no compromise there. "Pickup" and > "stability" (timing stability, anyway) don't belong in the same sentence.
As I wrote above, sorry for the confusion, with pickup I meant the complete mechanics, including optics and the first signal processing. bye, -- piergiorgio
Posted by Jerry Avins May 11, 20082008-05-11
Piergiorgio Sartor wrote:
> Jerry Avins wrote: > >> CDs are different. There is no data separator that I know of (but >> there might be). Since the data go into a buffer, it is relatively >> simple to > > I think the data is streamed, but there is block > concept, so I guess there is some separation. > >> do proportional control on the disk motor. The error signal is the >> amount and deviation from a half-full (circular) buffer. It is the >> integral of the speed error, and half the buffer size is available for >> headroom. Ihe control need is not stringent, but I don't think the >> model below captures its essence. Bed is waiting. Bye for now. > > OK, let's do some other math. > > A block in an audio CD is, in total, around 3.5KiB. > This includes the P/Q/R/W/whatever channels, carrying > the timestamps, track info, index, manufacture code, > date, an so on. > Then there is the audio part, with 2 ECC layers, if I > remember correctly, which, after the ECC oprations, is > 2352 bytes (and not 2KiB). > This is *exactly* 1/75 of second. > > Without further buffering, this is somehow the tolerance > to data rate variations.
Half that, if it's +/-.
> Can the pick-up (i.e. optics, motor and PLL) keep the > data rate within this accuracy (or precision? I always > confuse the two)?
Not instantaneously, but we need to control only the sum over 1/150 sec. That isn't difficult.
> In the good old times, I guess it could, so there was > no problem at all. > > Later, in the '90s, the manufactures started to reduce > the cost of the pick-up, thus causing a less stable > data rate as before.
?? The pickup is a photodiode. The excitation is a laser diode. It either sees the pits or it doesn't. The instantaneous data rate is set by the disc speed, not the pickup. What model do you have in mind?
> To compensate this, they introduced further buffering, > which was cheaper that having an expensive pick-up. > > This was done by, at least conceptually, adding a FIFO > somewhere in the chain, I guess after the pick-up, > having the unstable clock as input and the reference > clock as output, of course with proper feedback.
The input "clock" is the disc itself, not the pickup. There is no feedback directly from the output clock. The feedback is from how full the buffer is.
> Nowadays the CD player are massively buffered, so also > there is no problem.
That buffering is usually look-ahead, so the block can be read again if errors can't be corrected the first time around.
> In the '90s, the manufacturers started to compromise > between buffering, pick-up and clock stability. > So they were able to classify high and low end on > this means, and introducing some *alleged* problems.
The clock is crystal controlled; no compromise there. "Pickup" and "stability" (timing stability, anyway) don't belong in the same sentence.
> This was the story, and on this story was build the > *claim* that CDs (carrying the basic clock information) > can have different performances, due to some difference > in the production. > > As I said at the beginning, the CD manufacturing people > not only did not support this, but they even rejected it.
Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Posted by Piergiorgio Sartor May 11, 20082008-05-11
Arny Krueger wrote:

> Name a modern CD player with a 16 byte FIFO, and document that fact with an > independent reference.
How many witness I'm allowed to call to testify?
> 16 bytes is a rediculously small FIFO for this application, the smallest > I've ever heard of was 2 K byte.
That was only an example... bye, -- piergiorgio
Posted by Arny Krueger May 11, 20082008-05-11
"Piergiorgio Sartor"
<piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de>
wrote in message news:2uhgf5-b94.ln1@lazy.lzy
> Mr.T wrote: > >> No, the *input* rate is changed by varying the speed of >> the disk motor. > > Yes, that's the close part of the PLL and it is > where the problem lies, since the motor cannot, > or is not designed for, change speed immediately. > It has a momentum, friction, and so on. > Due to cost reasons, it does not react in zero > time to the changes, also because of the disk > (balance, weight, again friction). > > Of course, it would be possible to put also > an high end motor, but we're talking about > cheap old low end devices.
If the FIFO is overrun or underrun, then there would be lost data and very obvious tics and pops. Obviously, that has never happened in well-designed products.
Posted by Arny Krueger May 11, 20082008-05-11
"Piergiorgio Sartor"
<piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de>
wrote in message news:naref5-us2.ln1@lazy.lzy

> Steve Underwood wrote:
>> They all have FIFOs. The data isn't played directly from >> the disk. It is
> Uhm, this is a misconception of CD player.
> One thing is to have a 8KB FIFO, one is to have a > 16Bytes FIFO.
Name a modern CD player with a 16 byte FIFO, and document that fact with an independent reference. 16 bytes is a rediculously small FIFO for this application, the smallest I've ever heard of was 2 K byte.
Posted by Piergiorgio Sartor May 11, 20082008-05-11
Jerry Avins wrote:

> CDs are different. There is no data separator that I know of (but there > might be). Since the data go into a buffer, it is relatively simple to
I think the data is streamed, but there is block concept, so I guess there is some separation.
> do proportional control on the disk motor. The error signal is the > amount and deviation from a half-full (circular) buffer. It is the > integral of the speed error, and half the buffer size is available for > headroom. Ihe control need is not stringent, but I don't think the model > below captures its essence. Bed is waiting. Bye for now.
OK, let's do some other math. A block in an audio CD is, in total, around 3.5KiB. This includes the P/Q/R/W/whatever channels, carrying the timestamps, track info, index, manufacture code, date, an so on. Then there is the audio part, with 2 ECC layers, if I remember correctly, which, after the ECC oprations, is 2352 bytes (and not 2KiB). This is *exactly* 1/75 of second. Without further buffering, this is somehow the tolerance to data rate variations. Can the pick-up (i.e. optics, motor and PLL) keep the data rate within this accuracy (or precision? I always confuse the two)? In the good old times, I guess it could, so there was no problem at all. Later, in the '90s, the manufactures started to reduce the cost of the pick-up, thus causing a less stable data rate as before. To compensate this, they introduced further buffering, which was cheaper that having an expensive pick-up. This was done by, at least conceptually, adding a FIFO somewhere in the chain, I guess after the pick-up, having the unstable clock as input and the reference clock as output, of course with proper feedback. Nowadays the CD player are massively buffered, so also there is no problem. In the '90s, the manufacturers started to compromise between buffering, pick-up and clock stability. So they were able to classify high and low end on this means, and introducing some *alleged* problems. This was the story, and on this story was build the *claim* that CDs (carrying the basic clock information) can have different performances, due to some difference in the production. As I said at the beginning, the CD manufacturing people not only did not support this, but they even rejected it. bye, -- piergiorgio
Posted by Piergiorgio Sartor May 11, 20082008-05-11
Mr.T wrote:

> Or not thinking at all.
Well, I knew you were thinking for both.
> You still haven't named one commercial player from ANY date.
As I said, I really do not remember names from that time.
> No, buffer size does not affect jitter. > (hint, it's not called jitter if the buffer underflows)
That's clear.
> You are at least.
Look, I'm trying to be supportive, if you want to lead this discussion into a flame, do not count me in. I close it here. bye, -- piergiorgio
Posted by Mr.T May 11, 20082008-05-11
"Piergiorgio Sartor"
<piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> wrote in
message news:d61hf5-b94.ln1@lazy.lzy...
> Randy Yates wrote: > > > So we've ruled out jitter from buffering. Perhaps it's from bad clock > > sources in the player? > > Yes, yes, yes, finally someone thinking instead > of blindly counter-arguing.
Pity you didn't do that days ago, insteading of continuing to claim total crap was fact. MrT.