Hello List,
I'm reading this list for quite a long time now, but never
had anything special to contribute.
But now I saw this Posting about CD-DA and it is
definitively full of errors.
Oh, if my english may contain some mistakes, you are asked
to excuse this. I am from germany, you know. ;-)
> * "Timothy P. Stockman" <[EMAIL PROTECTED]> on Tue, 22 Aug 2000
> | CDDA is *not* analog! It is as digital as CDROM, your computer hard drive,
> | etc.
>
> CD-DA is Compact Disc Digital Audio. That means Linear PCM (pulse code
> modulation) 16 bits wide at a sampling frequency of 44.1KHz, which is a
> digital signal. The ones and zeros are coded on the disc media as ones
> (light reflects one way) and zeros (light reflects another way).
Nearly. The digital one is coded as transition from pit to land or vice versa.
A remaining pit or land is zero. The amount of zeroes is counted by timing
and there is a run length limitation. ie. After a certain amount of zeroes
there must be at least one (digital) one. To reach this goal, they do a code
translation. If I remember it right, the 16Bit PCM Data is converted to 20Bit
CD-Data.
> But the
> media itself is analog in that the intensity of a given "one" -- that is,
> the ammount of light reflected from a given pit representing that bit of
> data -- is variable within a given tolerance.
Ok, you could say that the media is analog in this way:
You can measure the depths of pits and lands in an analogue unit of
measurement.
But:
The information contained is and remains digital.
>
> | CDs use a sprial track (similar to an LP) that was originally designed
> | to be played continuously, not random accessed.
>
> No. The Compact Disc has always been concentric tracks (rings) divided
> into sectors, intended for random access, just like analog LaserDisc from
> which it descends.
CDs have one spiral track. Full stop.
It was not intended for full random access.
Unless you count track skipping as random access.
> | Unlike computer disks, which have a header on each sector containing the
> | sector number so the drive can be 100% certain which sector it just read,
> | CDDA contains no such identifying information in each frame.
>
> Wrong again. Each sector of a CD has a numerical sector count, which can
> be used by the playback mechanism.
No, he nearly is right. CDDA has sector information.
CDDA has blocks with a length of 1/75sec. The specification allows drives to
seek to a block with an accuracy of +-3 _Blocks_.
Oh, excuse me, I took the words from my previous poster. So replace blocks
with frames. ;-)
Really good computer CD-Rom drives are doing this with 100% accuracy, when
ripping DA. example: Plextor. But not all of them. ;-)
>
> | As long as you play CDDA continuously (like an audio CD player does)
> | there's no problem. Since the frames are in order on the disc, the data
> | in the resulting audio stream will be in order. The problem comes in
> | when one is extracting the digital audio information to a WAV file.
>
> The problem with "ripping" audio tracks is that CD-ROM (CD data) has three
> layers of inherent error checking, whereas CD-DA requires only two. That
> extra layer is what makes CD-ROM useful as a data storage system. The lack
> of that extra layer makes it difficult for CD-ROM mechanisms to read CD-DA
> as data because the frequency of "soft" errors exceeds the mechanism's
> threshold.
ok, this comes near to it.
The continous problem: When ripping CDDA, the reading problem is buffering the
data, then stops reading, writes the data to disk, and then restarts reading.
When it restarts it can not be sure where the laser starts reading. Why? See above.
So the program starts reading a bit before the point it stopped reading and compares
it
with its previously saved data to find the point the new data begins.
Error Correction:
The Error Correction implemented in CD-Data is just more complex.
It is able to even cope with a certain amount of successive bit errors.
You can easily see this when looking at a disk frame:
CDDA uses 2304Bytes of raw data +Header +ErrorCorrection which add up
to....bytes. damn, I forgot, I have to look it up. ;-)
CD-Data just 2048 Bytes of raw data +Header +Errorcorrection +the remaining
256 Bytes which add up the same framesize as above.
>
> | In this case, the player does not read continuously but instead reads the
> | data in "chunks".
>
> Those chunks are called "blocks". Each block is a single sector of data on
> the disc, or two sectors for some operating systems.
No frame. There are just frames on CDDA.
To clearly point it out.
You can address a CD-DA disk in a maenner of
hours:mins:sek:hundreds which is translated into a frame number.
As you can easily imagine, the time index you require might be in
the middle of a frame plus you have to cope with inaccurate seeking,
as described above.
> | After each "chunk" it has to seek back to where it left off before
> | reading the next "chunk". Since there is no header to unambiguously
> | identify the frame,
>
> There is no header to identify the PCM frame because it is a data stream,
> not block I/O. But there is the sector index counter of the disc itself,
> and the ripper uses that to gauge it's progress.
The ripper doesn't see the index information at all. It says: "Hey, drive.
Gimme frame number XY, please" Drive says: "here you are"
and gives back raw data. And if the program is lucky it gets the frame it
requested. But it might also be in the +-3 frames allowed error range.
There is a header, which uniquely identifies the frame.
They nearly didn't touch it for cd-data.
>
> | it seeks back to *approximately* the same place, reading some overlapping
> | data. It then compares the data and discards the overlapping data.
not the drive itself, but the ripping program does. see above.
>
> Rippers re-read blocks to ensure that the lack of error correction does not
> cause the ripper to get incorrect information. The player has little to do
> with this aspect of the ripping process.
Ack, to second sentence.
First sentence: it rereads cause of inaccurate seeking.
>
> | Some CDROM drives are better at this than others.
>
> Some CD-ROM drives are better at compensating for the lesser error
> correction required by CD-DA.
*grr*, see above.
>
> | A few are very bad, causing the program to give up,
>
> Which is ultimately a flaw in the program. Paranoia does not give up.
>
> | but a few are perfect.
>
> Plextor.
Ack.
>
> | Most are somewhere in the middle. But as long as the program can
> | identify the overlap, the resulting WAV file will be a perfect copy of
> | the audio data.
>
> As long a) the disc is not excessively damaged and b) the CD-ROM mechanism
> isn't a piece of shit, you can get a PCM data stream that is a copy of what
> is on the disc. You can then swap the byte order and wrap inside a WAV
> container.
Ack, if you use overlapping transfers. If you don't, you have to have a very
good CD-ROM drive. Plextor as you noted.
CD-Data on the other hand has to seek perfekt. it is in the specs.
And after all: Isn't this all Off-Topic?;-)
Just my 2 cents
Marc
Horstmann
-----------------------------------------------------------------
To stop getting this list send a message containing just the word
"unsubscribe" to [EMAIL PROTECTED]
