Get Firefox! Viewable with any browser! Valid HTML 4.01! Valid CSS!
Text size: 

CD Writing Howto


The "Red Book" CD as we know it today was originally developed for digital playback of music, so it's a little ironic that we're dealing with the audio side of things after the data side in this howto. Only well after it was established as an audio medium did people think: "Hey, the audio is stored as digital data, so why can't we use this medium for file storage?".

Bingo! Out popped the Yellow Book in 1984.

See for more information on the various "coloured" Book standards.

The key point here is that the audio data on a Red Book CD is already digital. So, there must be some way of grabbing that digital data and reproducing it bit for bit (i.e. without loss of quality) on another CD instead of having to play it back and re-digitize the analog signal, right? That's precisely what a CDDA ripper is for.

The "original" CDDA ripper, which happens to be part of the cdrtools package, is cdda2wav. I have, however, chosen cdparanoia over cdda2wav for two reasons:

  1. It's easier to use IMO. There are less command line parameters to type and default settings seem to be pretty reliable.
  2. cdparanoia provides better visual feedback on what it's doing.

Rippers can save the audio data to your hard disk using any one of several formats such as .au or .wav, or even as raw, unformatted audio data. The trouble with many of these formats is that they are system-dependent in that some will want the byte order reversed for 16-bit samples, others won't. The .wav format commonly used on Microsoft™ systems has the advantage of being strictly defined regardless of what system is being used, so that's the audio format we'll be using here. Whether your CD writer needs the byte order reversed or not is cdrecord's problem, not yours.

The only headache you might have when dealing with audio tracks is when you edit and record them yourself. A CDDA is played back on a frame-by-frame basis at a rate of 75 frames per second, and one frame fits precisely into one sector of the CD.

A CDDA is sampled at 44100 16-bit samples per second. One frame is therefore 44100/75 samples, i.e. 588 samples. At 16 bits per sample and with 2 tracks (stereo), that's 4 bytes per sample. One frame therefore holds 588 x 4 = 2352 bytes.

All of this is to say that anything you produce must be a whole number of frames long, and therefore fill an exact number of sectors. Each frame is 13.333ms long, which isn't easy to calculate with. On the other hand, if you calculate with groups of 3 sectors, each group is 40ms long. That's easier. Better still, work with groups of 15 sectors and make your audio files multiples of 200ms in length. If you edit your audio files so that they are always a multiple of 40ms (or 200ms) in length, then you will have no problems. You don't have to worry about this with files you rip off a CDDA because the data already meets this requirement.

Extracting audio data from a CDDA

Obviously, start by inserting a CDDA into a CD drive and 'su' to root. cdparanoia addresses the device directly and therefore needs root privileges. Once the CD has been accepted, type this command to get a printout of the CD's TOC:

# cdparanoia -Q

If you get a message like this:

cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty @> and Xiphophorus

Report bugs to paranoia @

004: Unable to read table of contents header

Unable to open disc.  Is there an audio CD in the drive?

the chances are that you don't have a /dev/cdrom symlink pointing to the device where the CDDA is, or that it is pointing to another device. You can get round this by using the -d command line parameter with which you tell cdparanoia exactly where to look, in my case it's either /dev/scd0 or /dev/cdrw (which is a symlink to /dev/scd0 anyway):

# cdparanoia -Q -d /dev/scd0
cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty @> and Xiphophorus

Report bugs to paranoia @

Table of contents (audio tracks only):
track        length               begin        copy pre ch
  1.    11270 [02:30.20]        0 [00:00.00]    no   no  2
  2.    11520 [02:33.45]    11270 [02:30.20]    no   no  2
  3.    17095 [03:47.70]    22790 [05:03.65]    no   no  2
  4.    30495 [06:46.45]    39885 [08:51.60]    no   no  2
  5.    26400 [05:52.00]    70380 [15:38.30]    no   no  2
  6.    40062 [08:54.12]    96780 [21:30.30]    no   no  2
  7.    31345 [06:57.70]   136842 [30:24.42]    no   no  2
  8.    15080 [03:21.05]   168187 [37:22.37]    no   no  2
  9.    16948 [03:45.73]   183267 [40:43.42]    no   no  2
 10.    11820 [02:37.45]   200215 [44:29.40]    no   no  2
 11.    29625 [06:35.00]   212035 [47:07.10]    no   no  2
 12.    42695 [09:29.20]   241660 [53:42.10]    no   no  2
 13.    38742 [08:36.42]   284355 [63:11.30]    no   no  2
TOTAL  323097 [71:47.72]    (audio only)

That's more like it...

The exact output you have will obviously be different from this unless you happen to have exactly the same CD in your drive (Pink Floyd: Pulse - Disc 2. One of my favourites :o) ).

Okay. Let's rip the 8th track, for example, and save it in a file called track08.wav:

# cdparanoia -d /dev/scd0 -w 8 track08.wav
cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty @> and Xiphophorus

Report bugs to paranoia @

Ripping from sector  168187 (track  8 [0:00.00])
          to sector  183266 (track  8 [3:21.04])

outputting to track08.wav

 (== PROGRESS == [                              | 183266 00 ] == :^D * ==)


The -w command line option tells cdparanoia to output the audio data into a .wav file. track08.wav is the name of that file.

If the appropriate audio software and hardware is installed on your machine, you can now play the .wav file back:

# play track08.wav

That's all very well for grabbing one audio track. What about a group of tracks? For example, let's rip tracks 10 to 13:

# cdparanoia -d /dev/scd0 -w -B 10-13 wav
cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty @> and Xiphophorus

Report bugs to paranoia @

Ripping from sector  200215 (track 10 [0:00.00])
          to sector  323096 (track 13 [8:36.41])

outputting to track10.wav

 (== PROGRESS == [                              | 212034 00 ] == :^D * ==)

outputting to track11.wav

 (== PROGRESS == [                              | 241659 00 ] == :^D * ==)

outputting to track12.wav

 (== PROGRESS == [                              | 284354 00 ] == :^D * ==)

outputting to track13.wav

 (== PROGRESS == [                              | 323096 00 ] == :^D * ==)


The -B command line parameter means that we're putting cdparanoia in batch mode. 10-13 is the range of tracks we want to rip.

When in batch mode, the individual files generated by cdparanoia are named "track#.", where "#" is the number of the track on the CD. Anything which comes after the range of tracks to rip on the command line is appended to the filename. In our case the files will therefore be track10.wav, track11.wav, track12.wav and track13.wav.

Additional notes: The default output format for cdparanoia is .wav, so the -w is in fact superfluous. You can also batch output the entire CD into individual audio files by using just the -B command line parameter (and any device specification needed):

# cdparanoia -d /dev/scd0 -B

The tracks will be output to files called track01.cdda.wav, track02.cdda.wav etc...

The significance of the various smileys output by cdparanoia and more information on other command line parameters can be found by typing man cdparanoia at the command line prompt.

Burning the audio tracks to the CD

This is the easy bit - much easier than ripping the audio data. All you have to do is use the -audio command line parameter of cdrecord, and all the files mentioned thereafter will be written as audio tracks.

Assuming you're in a directory where you ripped the entire content of a CDDA of, for example, 18 tracks, there will be 18 files named from track01.cdda.wav to track18.cdda.wav. All we have to do now if we want to burn them to a CD is this:

# cdrecord dev=0,0 speed=4 fs=4m -v -eject -audio track*wav

A smaller than usual FIFO is all that's needed for writing a CDDA because we have to stick to a low write speed. Some audio CD decks have difficulty tracking CDDA's which have been written at high speed.

Also, the use of the track*wav glob avoids us having to type out all the track filenames individually - the shell's expansion functions replace the glob with an ordered list of all the files it references.

Finally, note that practically no audio CD decks (as opposed to computer CD-ROM drives) will be able to read your new CDDA if you burned it onto a CDRW. An audio CD Recorder might, however, be able to read a CDRW.

Track At Once or Disc At Once

Burning a CDDA as above will do so in "Track At Once" mode. The first audio track is written, the laser is switched off, data for the next track is buffered, then the laser is switched on again to write the track, etc... This will introduce a 2 second pause between tracks, which may be undesirable in some circumstances such as when transcribing a live recording, where a pause between tracks definitely will be noticed.

The solution is to write the CD in what is known as "Disc At Once" (or "DAO") mode in which, as its name suggests, the disc is written in one fell swoop with no pause between tracks. The "-dao" command line option of cdrecord achieves this, so the command line used above to burn those 18 audio tracks to the CD in DAO mode would be:

# cdrecord dev=0,0 speed=4 fs=4m -v -eject -dao -audio track*wav

The trouble is, not all CD writers support DAO mode, so what you need to do is find out what your CD writer is capable of. The empirical way I found of doing this is to attempt to start burning a CD, abort the process by hitting Ctrl-C before the 10 second grace period is up, and looking at what cdrecord found. Note the line in red and underlined:

# cdrecord dev=2,0,0 speed=4 blank=fast -v
Cdrecord 2.00.3 (i386-unknown-freebsd5.3) Copyright (C) 1995-2002 Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '2,0,0'
scsibus: 2 target: 0 lun: 0
Using libscg version 'schily-0.7'
atapi: 0
Device type    : Removable CD-ROM
Version        : 0
Response Format: 1
Vendor_info    : 'IDE-CD  '
Identifikation : 'R/RW 12x8x32    '
Revision       : ' 3.0'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc_cdr).
Supported modes: TAO PACKET RAW/R16 RAW/R96R
Drive buf size : 3244032 = 3168 KB
Current Secsize: 2048
ATIP info from disk:
  Indicated writing power: 5
  Reference speed: 2
  Is not unrestricted
  Is erasable
  ATIP start of lead in:  -11615 (97:27/10)
  ATIP start of lead out: 335925 (74:41/00)
  1T speed low:  0 (reserved val  0) 1T speed high:  4
  2T speed low:  0 (reserved val  5) 2T speed high:  0 (reserved val 12)
  power mult factor: 4 5
  recommended erase/write power: 3
  A1 values: 02 4A B0
  A2 values: 5C C6 26
Disk type:    Phase change
Manuf. index: 18
Manufacturer: Plasmon Data systems Ltd.
Blocks total: 335925 Blocks current: 210475 Blocks remaining: 210625
Starting to write CD/DVD at speed 4 in real BLANK mode for single session.
Last chance to quit, starting real write in 9 seconds.^C

This shows that my CD writer supports TAO (Track At Once), packet and two different raw modes. Refer to the cdrecord man page for further explanations about each mode, how to use them and in which order you should try them if your drive, like mine, doesn't support DAO mode.


<< 9) If you're running low on disk space... 11) Mixing audio and data on a CD >>

Back to the howto title page
Back to