Some of the following is adapted from a post to AdaptecCDR by Dick Langley, DickLTech@WWDB.org My thanks to him for permission to modify and to use his material. And since I modified it substantially, don't blame him for the mistakes - they're mine!
Let's start with an audio CD, just as the developers of CD-ROM did. CD-DA tracks are made up of blocks. There are 75 blocks per second of music. There are 588 samples per block; each has 16 bits for each of the two channels, so it takes 4 bytes for each sample or 2352 bytes per block. Now, the accuracy of reading from a CD is not nearly as high as from a hard drive or RAM. For audio, that's not much of a problem, but when the disc is used for data (as a CD-ROM), drop a bit or two and there goes the whole program. To reduce the rate of data errors and to prove that we're computer types and think in powers of two, they decided to use the same block to hold 2K (2048) bytes of data and to take the remaining 304 bytes for error correction. So a block on a CD-R is 2352 bytes long and can hold either 1/75th of a second of redbook (CD-DA) audio or 2K of data.
In documentation of audio and video processing, the word 'sector' is used for a chunk of information. By default, that chunk occupies 1/75th of a second and fits into one block. Because sector comes up later, I'll stick to blocks, thank you - and you can translate when you read about audio editors and such. And you are also now prepared to do your own arithmetic to see why 74 minutes of audio fills the same blank that holds 650 MB of data, or to understand why, when you extract a CD-DA to your hard drive, it won't fit into 650 MB. And all that neglects the cost of the header on a WAV file. On a CD-DA, there is no header. The information is in a continuous stream of bytes from one block to the next. There's a TOC to tell the player at which block each track begins, but there's no audio file on a CD-DA. (The .CDA you see with Explorer is a fiction.) To create a WAV file from the data stream, a drive capable of Digital Audio Extraction (DAE) supplies the byte stream to your software. That software converts the stream into WAV format, complete with header. DAE is done by dedicated programs (see the Files and URL pages at this site) or by your CD-R authoring program. Converting from WAV for CD-R is done by the authoring program.
If the information in a wave file is not an exact multiple of 588 samples, software pads to a complete block with nulls - silence.If you're recording a concert (for instance) and you want your selections to be addressable as different tracks via the TOC, those tracks should be multiples of a whole block. As you slam two tracks together, the sound (crowd noise for instance) should be constant when transitioning from one track to the next. If you don't have a true multiple of sectors, the last sector of a track will be padded with nulls or no sound. (In some older editors, the padding is not done with zeroes and whatever bytes were lying around will be read onto your disc). As you play your new CD and you transition from one track to the next, you may hear a click (where the sound you hear goes to nothing or to random bytes, then back again). It becomes annoying to hear these clicks between tracks. To solve this situation, software offers quantization. When you're cuttin', pastin', and slicin' tracks apart or together, it will do it in multiples of 588 samples to give you whole blocks. So if you have that concert that you've broken up in tracks, it sounds like one continuous track when played. Mike Looijmans' CDWAV (on the links page) was designed to cut on block boundaries. As you look for software that manipulates wave files, you should look for this "feature". Of course, that means your split may be moved. If you can hear the difference when it's shifted no more than 1/150th of a second, try analogue recording.
Now for data blocks. Again, there is a problem stemming from the fact that there's no File Allocation Table on a CD-ROM. There is a TOC and most of what a FAT needs is contained in the TOC. So OS extensions are used to translate the TOC to a FAT - on a PC, to a FAT which looks like the one you would have on a 650 MB hard drive. Information on a FAT16 hard drive is stored in up to 64K sectors; the size of each sector is the total size of the drive divided by 64K, then bumped up as necessary to the nearest power of two. So a 650-MB hard drive would have sectors of 16K bytes each. Since each file must begin on a sector boundary, it will waste whatever space is left unused in the last 16K sector.
Ah, but things are better on a CD-ROM with its 2K blocks, right? No - that would be too simple. Since the OS extension must address the CD-ROM as though it had a FAT, it must look for the file to begin on a 16K-sector boundary. A 4K file wastes 12K on a 650-MB hard drive or a CD-ROM. On average, each CD-ROM file wastes half a sector or 8K. When you add up the file sizes for a disc you are about to burn, you must remember to allow for that wasted space. If you are writing from a drive which has 16K sectors - such as a Jaz or a FAT16 hard drive with at least 512 MB but less than 1 GB - you can use Explorer and Properties to determine exactly how much of your blank will be needed. If your source drive has a different sector size, you will have to do your own arithmetic or approximate using 8K wasted per file - and a little more just in case. There's more on this subject in the page on Packet writing.
E-mail me at cdrecording@mrichter.com
Return to Mike's home page