Text size:  Microscopic Small Normal Large Giant

CD Writing Howto

7) BURNING THE CD

The time has finally come to burn your CD-ROM - well, almost... A bit of preparation and possibly a dummy run or two won't come amiss.

cdrecord is what you'll be using to burn the ISO image you created (and possibly previewed, see "Previewing the CD") earlier, and it needs to know at least two things:

1. The device to which you want to write the ISO image.
   
   
2. The filename of the ISO image on your hard disk.

This is the strict minimum. However, we'll be giving cdrecord a bit more information in order to make it work more efficiently. We'll be telling cdrecord what speed to work at, what size FIFO to use, to be verbose so we know what's going on, to eject the CD-ROM once it's cut, and to do a test run the first time.

Recording speed: cdrecord will interrogate your CD writer in order to find out the highest allowable writing speed for the device with the media present in it. This speed may be faster than your system can cope with - eg. 16x (2400KB/s) on a Pentium class box which can't handle the data throughput  - so we might need to tell cdrecord to ease off the pedal. Adding speed=n to the command line, where 'n' is the desired recording speed, tells cdrecord to use that speed. If the combination of your CD writer and the media only allows slower speeds then the highest possible speed will be used - eg. using speed=8 when you have in your drive a blank CD-RW which only goes up to 4x speed, in which case cdrecord will work at 4x despite your request for 8x.

FIFO size: Size matters. Data is read off your hard disk and temporarily stored in a "First-In-First-Out" buffer, aka "Ring buffer", in RAM to ensure a constant throughput of data to the CD writer. If the hard disk becomes more sluggish due to demands from concurrent processes such as an updatedb going on at the same time, there will be sufficient data in RAM to carry on supplying cdrecord until the hard disk becomes more available. Basically, the bigger the better, up to a reasonable limit. If you have the RAM available in your machine then don't hesitate to use a 16MB or even 32MB FIFO. A 32MB FIFO means that your disk can grind to a halt for up to nearly 30 seconds if you're writing at 8x and there'll still be data for the CD writer to work with. The size of the FIFO is set with the fs=size command line option, where "size" is a number followed by a multiplier, like fs=800k for an 800KB buffer (hardly worth the trouble...) or fs=16m for a 16MB buffer (that's what I often use). If cdrecord objects because there isn't enough shared memory available to the system, then you can make more available (provided you have sufficient physical RAM in the computer) by storing the required amount (in bytes) in /proc/sys/kernel/shmmax. For example, if you're going to use a 32MB FIFO then you're going to want AT LEAST that amount of shared memory for the system:

# echo "35000000" > /proc/sys/kernel/shmmax

Verbosity: If we use the -v command line option, cdrecord will inform us about each step taken during the process. We will be informed when the OPC is being performed (Optimum Power Check - the laser writes data into a reserved section of the CD in order to ascertain what the optimum power of the beam should be), when it starts writing the data, how much of the data has been written, how long it took to write the data, when it starts fixating the CD, and how long the fixating process took.

Eject: The -eject command line option gets cdrecord to eject the CD once it has been written. This isn't just because we're lazy and don't want to have to press the eject button on the drive, it also ensures that the media is reloaded because some CD writers with buggy firmware require this before being able to read the disc they've just burned.

Test run: We can get cdrecord to go through all the motions of writing a CD, including making sure the CPU can handle the data throughput, but without actually switching the laser on, by using the "-dummy" command line option. This is useful for testing how fast your machine can work without creating a magnificent pile of screwed up CD-Rs because of buffer underruns. If the recording cycle passed with the -dummy option, it will work without it, ie. for real, barring a faulty blank CD or writer. The use of the -v option also allows us to see how full the FIFO is during the writing process. If the level keeps dropping below half full then either the FIFO is too small or you're trying to write too fast.

Target device: dev=[a,]d,l with a=adapter (optional if 0), d=DeviceID, l=LUN. Tells cdrecord to use the SCSI device with the given ID and LUN connected to the given host adapter. For example, my Traxdata is on adapter 0, DeviceID 0, LUN 0, so I would use dev=0,0,0, or just dev=0,0 since the adapter is optional if zero. If you're using cdrecord version 2.0 or later on an IDE drive without IDE-SCSI emulation then you'll be using "dev=ATAPI:0,0,0", obviously replacing 0,0,0 with the real values you found in the "Locating your (re)writer" section.

ISO image filename: In our instance, the ISO image is in the file /root/pictures.iso.

Let's say that our CD writer can record data at 12x. Let's also say that we want a 16MB FIFO. We can now give cdrecord this information and do a test run in order to make sure that the machine can sustain the high data throughput required at 12x. Make sure you have a blank CD-R in the drive and type this command line:

# cdrecord dev=0,0 speed=12 fs=16m -v -eject -dummy /root/pictures.iso

First of all you'll get a bunch of information on your CD writer. You need only take any notice of this if you can't write CDs properly :)

Next you'll be presented with a countdown of 10 seconds during which you can always hit Ctrl-C in order to abort the whole thing. If you don't abort, cdrecord will go through the whole writing cycle. However, this being a dummy run, nothing will be written to the CD.

While writing, you will be kept informed of what's going on by messages like this:

105 of 641 MB written, FIFO (98%)

This tells us how much of the data has been written, and the percentage in parentheses tells us how full the FIFO is. If this figure drops consistently below 50% then you're not using cdrecord optimally for your system and you'll have to adjust some of the parameters and try another dummy run. Start by allocating a larger FIFO. If the percentage still drops then you'll have no other choice but to use a lower recording speed.

Let's say for argument's sake that I was getting consistent buffer underruns at 12x and using a larger FIFO didn't solve the problem. I tried writing at 8x instead of 12x and went back to my 16MB FIFO. This worked, so now I can write the CD for real, knowing that I have to restrict myself to 8x:

# cdrecord dev=0,0 speed=8 fs=16m -v -eject /root/pictures.iso

Once the data has been written to the CD, cdrecord will attempt to "fixate" the media. Basically, what this means is that the session on the CD is being closed, and what's known as the "lead-out" is being written afterwards, thus making it impossible to write further data. The lead-out can also be written in a way which leaves room for another TOC (Table Of Contents), thus making it possible to write multisession CD-ROMs.

You should be informed how long it took to write the CD and how long it took to fixate it, and then the CD should be ejected.

Leave it to cool for a couple of minutes. The dye layer in the CD is vaporized by the laser beam, which means that we're talking about some serious heat. The substrate can require a short period of time to re-polymerize. Skipping this short wait can lead to read errors.

Back to the howto title page
Back to howto-pages.org