Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: 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> Reply-To: ccplumb@watnot.UUCP (Colin Plumb) Organization: U of Waterloo, Ontario Lines: 79 Xref: mnetor net.arch:3344 net.periphs:599 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."