ttcp is a simple, possibly too simple, speed test utility.
pchar is another one people cite a lot, I've had bad luck with it, personally.
Here's how I'd use ttcp. You need two machines, each with ttcp (http://playground.sun.com/pub/tcp-impl/ttcp/ttcp.c) compiled on them.
HostA % ./ttcp -r -s -p 9401
...
HostB % ./ttcp -s -p 9401 < /boot/vmlinuz
Once you've figured out how to get it to run, try different length files to see how speed varies. Use UDP (-u flag on both reader and sender command line) for even more fun!
Quick introduction into CD formats:
A CD-R can record multiple sessions. Each session must be complete and "closed" before it can be read. Each session contains a lead-in, a lead-out and a number of tracks. You can write all the tracks in one session (disk at once, option -dao) or each track in turn from different files (conceptually) with pauses in between (track at once, option -tao), but you must write all tracks and close the session.
The data format for CDs (CD-ROM, "yellow book") was designed on top of the audio format (CD-DA, "red book"), and properly separates the continous digital audio stream into sectors. For this, it needs some header information, and that's why you have 2352 bytes in an audio "sector", but only 2336 bytes for data. On top of that, the error correction on audio CDs is good enough for audio, where you can tolerate a few wrong bits, but not good enough for data. Therefore each sector gets additional error correction bits, leaving 2048 bytes of user data. This is also called "Mode 1". This is the default in cdrecord, and I don't recommend using any other mode to write data. The available "raw" modes allow writing subchannel data, but you have no need for that.
You will need to pad your tracks to proper blocksize before writing, however. And no, 4512 bytes is not a multiple of 2048 bytes. So for backup, something like
tar -c --record-size=2048 -f track.tar
and then something like
cdrecord -multi dev=0,0,0 -data track.tar
to make a multi-session CD with a single track. If the CD is not full, you can append another session.
DVDs have a different format, different blocksizes and different restrictions, and I haven't personally tried this on a DVD yet, so I'd rather not try to give details, but in principle it works similarly.
Edit:
If the goal is to make frequent backups on DVD+RW or DVD-RW (the + or - is important, these are different formats), you can tolerate failures, so you might actually try streaming from tar. You also probably don't need multiple sessions.
You can also stream from mkisofs, which is even better because there won't be trouble mounting it, and man cdrecord has an example:
mkisofs -R /master/tree | cdrecord -v -dao fs=6m speed=2 dev=2,0 -
The last - is for "read data from stdin". You may want to fiddle with the speed, FIFO size, I/O priorities (that's another can of worms), driveropts=burnfree if supported, etc.
For permanent backups on write-once media, I'd always recommend doing it the safe way, without streaming.
Best Answer
To simply see if a drive can be read, you can use dd(1). This will read in the contents of the CDROM and will ignore/discard the data (note that the CDROM device may have another name on your system):
It is also possible to compare this to an ISO image:
This will print a checksum for the CD and for the ISO file. If the checksums match, the CD contents match the ISO image.