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

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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

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

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.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

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

"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. 

"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.

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

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

"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.