Article View: net.arch
Article #3108Re: Why optical disks are slow to seek; an idea for higher capacity disks
From: Colin Plumb
Date: Thu, 06 Nov 1986 04:34
Date: Thu, 06 Nov 1986 04:34
79 lines
5266 bytes
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!ccplumbReferences:
<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