I have always wondered why people keep blaming hard-drives for causing buffer underruns when burning a CD or DVD. I’ve read many people saying to use a faster hard-drive or to make sure to defragment it or some such before burning.

That makes no sense to me. I don’t care how fast you burn a disc, the speed and data throughput of a hard-drive is always going to be faster than any optical drive. (I’m talking about spinning drives, we won’t even bother with SSD!)

For example, burning a CD at 52x would need a data stream of 7.6MBps. Even a slow hard-drive (PIO2) should be able to keep up (8.3MBps), let alone any UDMA drive (UDMA0 can manage 16.7MBps) which can handily supply a steady stream.

Burning a DVD at even the current fastest 24x would need only about 32MBps, yet a system that has such a drive would certainly have a hard-drive that is orders of magnitude faster (SATA1 can do up to 150MBps, so even a ridiculously fragmented drive should be fast enough).

Even a Blu-ray disc needs only 54MBps which even a measly ATA66 IDE hard-drive can supply.

And those optical-drive speeds are the optimal, reading speeds; the actual, burning speeds are usually somewhat slower!

Okay, I’ll admit that seek times play a role, and fragmentation increases access times, but even then, unless the drive is rated for barely above the speed of the disc being burned (eg a PIO2’s 8.3MBps over a 52x CD-R’s 7.6MPbs = only 716.8KBps faster), then the differences should be large enough to make even access times irrelevant (eg a SATA1 drive’s 150MPbs over a 24x DVD’s 32MPbs = 118MBps faster!)

So what’s the deal? Why do people keep implying that hard-drives are the bottleneck when burning optical discs? What could be causing the problem and why is it that the drive-activity LED always goes solid once the burning software starts reading the hard-drive even though transferring a giant file normally only causes it to flicker?

3 Answers 3


There are a number of key things that mean that a hard drive can be the reason behind a buffer under-run.

  1. The hard drive used to use IDE cables, which could mean that on one cable you have data being copied from the hard drive and then written to the CD/DVD drive. This would effectively halve the available bandwidth to or from each device. While this has changed with SATA there is still contention in the SATA bus controller. This leads into my second point

  2. There may be programs trying to do things at the same time, another program reading or writing any substantial amount of data can again limit the bandwidth to either of the devices in a similar way to the first point. An excessively large sequential read could well completely block hard drive I/O for seconds or longer.

  3. The operating system being low on memory will mean that it needing to page other programs in from or out to disk, causing large sequential reads or writes to the page file that can block I/O as in point 2.

All these things mean that whatever theoretical peak bandwidth you think you have is not available all the time.

The problem comes when your CD-writer absolutely has to have guaranteed bandwidth between the hard drive and CD-ROM, if that bandwidth is starved for more than a second or two (the typical buffer size on a CD-writer) then a buffer underflow will occur. Programs or the operating system demanding use of the hard drive is enough to interrupt the flow of data to the CD-writer for long enough to cause this to happen.

The main reason that we recommend substantially faster hard drives to prevent buffer under-runs is because a faster drive will be able to get past the blocking I/O much faster and back to the task of reading the data to be sent to the CD-writer.


You are right that a lot of inexperienced users would have a large number of "helper" applications (RealPlayer, quickstarters and other assorted near-malware applications) which meant that there was less memory available. Older home user systems generally only had enough memory available for the OS and a program or two to be run comfortably, add in all the useless garbage programs and the CD-writing software needing a large buffer of its own and "comfortable" amounts of memory become decidedly uncomfortable.

Also note that anti-virus software can also have an impact on hard disk bandwidth as they have to scan every bit of data coming from the hard disk. Freeing up resources by closing those programs and clearing the system generally allowed the CD-writer to get on with its job.

The main thing that makes an underrun actually a thing to avoid at all costs though was the way the CD-writer actually writes to the drive. The laser, while writing, is dumb: "I have data in buffer, I write data".

It is not written block by block, even though a CD is written in sectors, the writing process is done as one long track and the laser simply outputs what is in the buffer to the sectors on the disk. If the buffer on the CD-writer suddenly is not getting updated with new data (as the system is doing something else) then the same data in the buffer will be written numerous times, without any sign from the controlling software that it should have stopped writing data long ago, and you end up with garbage on the disk. It could be several hundred megabytes of garbage or it could just be a few kilobytes, either way that disk is now worthless as it is impossible to tell where the good data ended and the bad data started.

Recovering from the garbage being written is difficult, as you have no way to tell just how much of the data written really was garbage and how much of it really was meant to be repeated. It would be much better if we could prevent the garbage being written in the first place and this is what the under-run protection is doing, it watches the buffer and when it gets near to being empty it will tell the laser to stop writing and wait for fresh data to appear before continuing on.

  • 1
    So basically it is a problem of the past because RAM was smaller and hard-drives were slower (but then so were the burn speeds). In other words, buffer underruns are not nearly as much an issue as they used to be?
    – Synetech
    Jun 12, 2011 at 0:05
  • 1
    Effectively, yes. Buffer underruns are still possible as large data transfers could still starve the write buffers on a cd-writer, but is is much less likely than it used to be and almost every drive for the last few years has been able to detect, guard against and recover from buffer underruns. See en.wikipedia.org/wiki/…
    – Mokubai
    Jun 12, 2011 at 0:12
  • I’m familiar with buffer underrun avoidance techniques, but shouldn’t they be getting less necessary in the first place. And even then, while older hard-drives may have been slower and used for pagefiles and so on, older OSes needed less memory anyway, so swapping would have been less of an issue anyway. Could it just be that people tend to have a bunch of junk running that sucks CPU and I/O while burning, and that getting the system as idle as possible and freeing up as many resources as possible would have prevented buffer underruns?
    – Synetech
    Jun 12, 2011 at 0:31
  • I just can’t wrap my head around the optical burner getting ahead of the hard-drive. I suppose I could conceive of a scenario where the burner has a really small or no buffer at all, and the hard-drive gets so bogged down from some apps and paging and such that the burner eventually runs out of data, but so what? When a hard-drive is writing a file and the system blocks, the drive waits on the data from the system until it’s ready. Is there something inherent about CD/DVDs that makes (or rather originally made) them require to be burned continuously in one rapid block without pausing?
    – Synetech
    Jun 12, 2011 at 0:35
  • I've updated my answer @Synetech
    – Mokubai
    Jun 12, 2011 at 10:14

Seek time, and if the HDD is on the same channel as the burner. Also, as you mentioned, those are MAX SPEEDS, not minimum. Software could slow it down too, and the CD needs constant data being written to them, unless you're using it like a floppy. If the hard drive is more than double, then it can stand taking a break for wahtever reason


If you have a lot of small files getting burned, your CD burner will be faster than your HDD because the files will (probably) not be contiguously located on the disk, whereas the CD will be burning contiguously. So you'd be comparing HDD random reads vs. CD sequential write, the latter of which is quite often faster.

  • I suppose that’s not a bad thought. Naturally, I use a dedicated 4.5GB partition (used to be NTFS, but changed it to FAT32) for disc burning so that all the files are indeed contiguous. I have no information/data/statistics on how likely burning a coaster is from a defragged drive.
    – Synetech
    Dec 29, 2011 at 20:31
  • @Synetechinc.: Note that I'm not talking about each file being defragged -- I'm talking about multiple files being laid out contiguously, and in the same order that they will be burned. That's not something that happens naturally, so in most cases defragmentation doesn't help much.
    – user541686
    Dec 30, 2011 at 10:21
  • Yes, I know what you mean; that’s what I said: the drive being defragged, not individual files being contiguous.
    – Synetech
    Dec 30, 2011 at 17:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .