🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.arch
Article #3108

Re: Why optical disks are slow to seek; an idea for higher capacity disks

#3108
From: Colin Plumb
Date: Thu, 06 Nov 1986 04:34
79 lines
5266 bytes
In article <573@cubsvax.UUCP> peters@cubsvax.UUCP (Peter S. Shenkin) writes:
>
[Quotes of earlier articles deleted]
>
>Real-time audio output probably doesn't require constant bit-rates either.
>I believe that CD players read bits into a buffer asynchronously, and then
>put the bits out to the D-to-A at a precisely clocked rate.  At least that's
>how I would do it.  That would avoid the need for an extremely accurate drive
>motor.  Variable bit density on the disk would only affect the rate at which 
>program material enters the buffer.   As other contributors to this discussion
>have noted, variable bit rates would involve some computational overhead, and
>it's not clear how much this would slow things down.  In addition, it may be
>that for audio CD's the nominal bit-rate on the rotating medium is closely
>tuned to the bandwidth of the channel to the buffer, so that doubling the
>bit-rate might require some redesign.  For audio applications there's no
>incentive for anyone to do this.  (If you could double the amount of program
>material on a CD, do you think people would be willing to pay $30 each instead
>of $15?  Most people think CD's are overpriced anyway.)  For information
>storage there probably would be;  if for a relatively small additional cost an
>optical drive could store 2Gbyte instead of 1Gbyte per platter, I'd buy that
>machine..  For audio applications the bucks are in selling disks;  for data 
>processing, the bucks are in selling machines.
>
>Peter S. Shenkin	 Columbia Univ. Biology Dept., NY, NY  10027
>{philabs,rna}!cubsvax!peters		cubsvax!peters@columbia.ARPA
------
You're right that CD's don't have fantastically accurate drive motors, and they
do work rather as you suppose, but there is a servomechanism that adjusts the
speed of the motor to keep the buffer about half-full.  If it was possible to
buffer a significant part of a CD, we wouldn't need secondary storage!  Thus,
CD's do maintain constant bit rates.
------
A bit of background in disk drive design...

I'm no expert in the field, but when I used to play with C-64's, I had a good
look at how the machine worked at the hardware level:

On the disk, a '1' was encoded as a change in the polarity of the magnetic field
on the disk.  A '0' was encoded as no change.
To prevent long blank regions, nybbles were expressed in a 5-bit code which
ensured that there would never be more than 2 0's in a row.
When reading data, a bit clock would run at the expected data rate on the disk.
If a full cycle of the clock passed without a polarity change sensed by the
read head, a '0' was shifted into the serial-to-parallel converter.
If a polarity change *was* sensed, a '1' was shifted in, and the bit clock was
reset to sync up with the pulse, ensuring it would never drift far.
When the serial-to-parallel was full, the byte was latched into an I/O port,
and a signal was sent to the CPU to read the byte.

Before reading the track, the CPU would adjust the frequency divider used to
take the system clock down to the bit rate, to allow higher bit rates on
the outer tracks.

If the CPU in this example was a DMA controller, there would be _no_ processor
overhead needed to allow variable bit-rates, besides looking up the appropriate
divider ratio for the given track, which is absolutely trivial.  Of course, on
a CD, where the bit rate changes continuously, you can just use a PLL instead of
a fixed-frequency clock.  If this takes too long to sync up, you can prepare it
with an expected bit-rate from a variable oscillator while the head seeks.
(I don't know if this is actually feasable - it seems reasonable.)

I know that MFM recording (which is how most disk drives these days work) is
different, but it should give you some idea of how these gizmos operate.
------
About higher-capacity optical disks...

This may be just unsubstantiated rumour, but I heard that one of the design
goals was to fit Beethoven's 74-minute nth symphony on a disc. (n=5 or 9, I
forget which.)  Thus only 44,000 +/- samples/second were taken, because they
couldn't fit more on a side.  Trying to filter out the noise this creates above
the Nyquist limit (22,000 Hz) while letting through audio information all the
way up to 20,000 Hz gives CD-player designers some serious headaches.  Filters
with cutoffs that steep induce serious phase distortion.  If they could have
increased the information content without sending prices through the roof, I'm
sure the standards team would have done it.
------
        -Colin Plumb (ccplumb@watnot.UUCP)

"Bugs:  This man page is confusing."
Technical Details
Message-ID: <12160@watnot.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!rutgers!clyde!watmath!watnot!ccplumb
References: <1128@tekig5.UUCP> <5100141@ccvaxa> <amdcad.13214>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!rutgers!clyde!watmath!watnot!ccplumb
From: ccplumb@watnot.UUCP (Colin Plumb)
Newsgroups: net.arch,net.periphs
Subject: Re: Why optical disks are slow to seek; an idea for higher capacity disks
Message-ID: <12160@watnot.UUCP>
Date: Wed, 5-Nov-86 23:34:24 EST
Article-I.D.: watnot.12160
Posted: Wed Nov  5 23:34:24 1986
Date-Received: Thu, 6-Nov-86 21:40:41 EST
References: <1128@tekig5.UUCP> <5100141@ccvaxa> <amdcad.13214>
Reply-To: ccplumb@watnot.UUCP (Colin Plumb)
Organization: U of Waterloo, Ontario
Lines: 79