NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/next/programm/7242

Internet Message Format | 1992-11-15 | 5.3 KB

Path: sparky!uunet!dtix!darwin.sura.net!sgiblab!sgigate!sgi!fido!zola!zuni!anchor!olson
From: [e-mail] (Dave Olson)
Newsgroups: comp.sys.next.programmer
Subject: Re: (failing to) read Audio Data from CDROM [not failing]
Message-ID: <[e-mail]>
Date: 16 Nov 92 04:24:40 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail] (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 82

In <[e-mail]> [e-mail] (Brian Willoughby) writes:

| Sean T. Lamont writes
| | In article <[e-mail]> [e-mail] writes:
| | >constantly failed working when I inserted audio CDs. However, it works fine
| | >with data CDs although the "music" isn't too enjoyable...
| |
| | There is a fundamental problem with your entire strategy.  CD disks are
| | built with an encoding written onto the disk which specifies whether you
| | can read data off the disk in digital format or not.  on CD-rom disks are
| | obviously set to "true", with audio CDs having the bit set to "false"
| |
| | The implementor of the drive, of course, is free to ignore this
| | specification.  However, the only one I've heard of that does is the one
| | shipped by SGI.

We eval'ed drives from both Sony and Toshiba.  We went with Toshiba
for various reasons, but both offered the same interface.  Both said they
would eventually sell this feature on future drives, and I'm pretty sure
both have announced it on their new dual speed drives (others may have
also).  The new dual speed drive is the one that Apple is using.  I
*assume* (but haven't yet seen the docs to know for sure) that they
are keeping the same scsi cmd and data interface that they developed
with us in the new drives.

| An audio Block on a CD contains 2352 bytes of audio data.  The exact same block
| only provides 2048 bytes of computer data on a CD-ROM; the additional 304 bytes
| are "wasted" as sync, header and aux data.  So, when you read a "block" from an
Not to mention a *lot* of bytes dedicated to ECC.  You can't just use
interpolation on data the way you can on audio, at least, not if you
want to avoid very unhappy customers!

| audio CD, you are missing 13% of the data.  The manufacturers aren't really
| going out of their way to prevent reading of audio data, they're actually just
| using off-the-shelf chips which either interpret CD audio or CD-ROM data.  Most
| manufacturers connect the output of the CD audio chip to the audio circuitry
| and connect the output of CD-ROM chip to the computer interface.  SGI (or the
| maker of their drive) has taken special measures to make the CD audio data
| available on the computer interface as well.  They probably have some
| proprietary way of sending the entire 2352 bytes instead of only 2048.

Not proprietary (at any time), and available on other drives now.  There
were some chip changes required (unlike the situation on DAT) and a fair
amount of new firmware.  The issue was that some of the data was split
off by the chips fairly early on, and there was no sync info to bring
it back into the correct data stream before delivering it over the SCSI
bus.  For similar reasons, one *must* be able to sustain the data rate
over the scsi bus (with ondrive RAM buffer allowing some speed matching),
since there is no way to do precise positioning (+/- aprox 10 ms, if
I remember right) with audio data, and if the drive had to reposition
during a track you would drop data, or even get the same data twice.

| There are 6 stereo 16-bit samples (24 bytes) in a Frame on a CD.  Each Frame
| has an extra byte for subcode.  It takes 98 Frames to make a Block (which has
| the time in seconds encoded into the 98 subcode bytes).  You can't really seek
| on a CD except to a block address because you are technically seeking to a
| specific second (there are 75 Blocks per second).  CD audio was designed first,
| and then CD-ROM came around as an afterthought.  Since there were already Block
| limitations in the audio design, I guess they thought it would make sense to
| throw away 288 auxiliary bytes with every block to keep things aligned.


| There are subcode bits in each Block which indicate whether the data is audio
| or computer and whether it is copy protected or not.  But, you can see that it
| doesn't do much good to enable a computer to read audio blocks unless all 2352
| bytes are sent across the interface instead of just 2048.

The most amazing thing to those of us at SGI involved with the project
was that it seems that nobody else had ever (seriously) asked the CD-ROM
drive vendors for this feature before (there was a very brief interest
from IBM at about the same time we decided to do it, but they dropped it).
After we did it, it seems that there were a lot of people who wanted it
all along, but somehow that never seems to have gotten back to the
corporate headquarters of the drive vendors ;)

The interface is pretty straight forward, it is just a few modeselects,
and then agreeing on the format in which data comes back over the SCSI
bus.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   [e-mail]