Alter.Org.UA  
 << Back Home RU ru   Donate Donate www/www1/www2

About various CD-R/RW drives, disks and their manufacturers

I'm bored with it. Now I'll write a lot of good words about various CD/DVD (especially RW) devices, disks and their manufacturers. I love'em. All'em.

I will collect uglinesses of CD-devices implementations. Please, if you can tell me something outstanding about some CD-drive, mail me: Mail to alterX@alter.org.ua (remove X)  

A long time ago I was naive enough to believe, that existance of standards is a very good thing. I supposed, they were invented to make our life easier. Let's take for instance a fat hand-book. Then plug some new unknown device to computer and begin feeding it with commands. Of course, all the commands are harmless. Of course, they all and their parameters fully comply the standards from the hand-book.

We expect that receiving of STATUS_SUCCESS means that device understands the command sent. We also expect, that any error code returned points to the source of problem unambiguously. We would be able to rely on device responses for our commands. We would be able to determine capabilities of the device and set of commands those this device understands. At least, we come to this idea after reading specifications.

In practice, we have the following:

  1. There are many standards in our world. Some of them can be grouped to family (like MMC, MMC-2, MMC-3, MMC-4). Some others generate own families. Now we have a bush of interlaced and sometimes alternative spacifications. Perfectly.
  2. Some developers invent their own standards (like NEC and Plextor do). Some others - their own deviations from existing standards (of course, there is no place, whe you can read about it).
  3. Still one group of vendors cannot make friends with Quality Assurance department. As result we have many devices with unpredictable behaviour on unknown comamnds or on commands with unexpected parameters.
  4. Relatively new information - http://www.ixbt.com/optical/magia-chisel.shtml. This article is in Russian. It describes problem, that appears after recording magic sequence of bytes to the CD-R/RW. The sector containing this sequence becomes unreadable for most drives (e.g Sony (LiteOn), Teac).

Nevertheless, standard commities continue breeding. Looks like there more commities than objects to be standardized. My be we have to invent a commity for standartization of standard commities ?

Thus, it is impossible to write a programm, that can reliably determine capabilities of the device analysing responses on predefined set of commnds. For example, to read device parameters in some various ways, try to execute CD-RW specific commnds, issue commnads defined in different standards, etc. Unfortunately, such method of probing often simply hangs the device. We are to create database. Find my small database below and still one much greater database at http://www.cdrfaq.org/faq05.html.

CD-R/RW drives

Vendor Device Supported Media types
Sony CRX-xxxx CD-ROM, CD-R, CD-RW
  • Requires Full Blank for Packet-writing. Looks like it is a 'feature' of Sony family.
PS. In general they are rather good devices... Exept the one, described below.
Sony CRX-0811E CD-ROM, CD-R, CD-RW
  • They states, that it supports Packet-writing. They deceived me. None of CD-writing tools could format disk with this drive. Even mine one. I tried all possible combinations of recording parameters.
  • The device always reported SUCCESS when attempted to write in Packet-mode. But disks seemed to be empty after that. The main difference from normal blank disk was state of 1st track: It was reported as Fixed-Packet. Disk could be reverted to recordable stabe only by Blank.
  • Full Blank did nothing, if the device decided, that disk is empty. Status SUCCESS was reported immediately without any media access. The only way of making device to perform Full Blank was writing something to disk.
  • Device required disk to be Full Blank'ed in order to write to it in Packet-mode.
  • And finally, it didn't support GET_EVENT command, that is claimed as mandatory for such class of devices (MMC-2).
PS. People sold it to me and didn't want getting it back...
Sony DRU-500AX CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-R, DVD-RW, DVD+RW
  • They said, that it supports both DVD+RW and DVD-RW. They deceived me. None of DVD-RW disks was recognized by this device...
Sony DDU-1621 CD-ROM, DVD-ROM
Info from Alex Y. Matiash:
  • "Have upgraded firmware for zone unlocking. Before upgrade the device reported its capabilities properly. After it claims that is capable of writing DVD-RAM with unknown speed."
  • this firmware allows +RW reading...
  • ... and reportd speeds incorrectly. Previously, the following ones were available: 16/24/32/40, now - 4/8/16/20/28/32/40 but really 28=40, 20=4, and so on.
Toshiba SD-W2002 CD-ROM, CD-R, DVD-ROM, DVD-RAM
  • Dies immediately when receive STOP/START UNIT commands.
  • Randomly falls in a strange state when receives GET_EVENT command. It stops understanding DVD-RAM media. Other types of media are recognized normally. This can be cured with power-off with sequetial software reset. Under Windows 2000 it is rather unplesant procedure... it takes about 20 minutes. And the result is not guaranteed.
  • The divece often comes to the state described above on unexpected reboot (reset, power failure). It also does so on unrecognized commands. It does it randomly.
PS. This piece of iron taken me for a long time each working day. I don't know what I'll do to author of firmware if I ever see that person...
Matshusita CW-7xxx CD-ROM, CD-R, CD-RW
  • When internal write buffer becomes full, the device hangs. All data is lost. According to standards, data must be written down to media automatically, without Writing Software intervention. This can be cured with sending SYNC_CACHE from time to time.
PS. In general it is good device...
IDE CDR RW CD-ROM, CD-R, CD-RW
  • Hangs on SYNC_CACHE command
PS. In general it is good device...
Lite-ON LTR-123 CD-ROM, CD-R, CD-RW/MRW
  • After recording some data to disk it randomly stops reporting user's Eject Requests via GET_EVENT.
Yamaha CRW2100E CD-ROM, CD-R, CD-RW
  • Sometimes it dies on read command after multiple packet writes when write buffer is full.
  • It required complete matching of Fixed-packet track parameters and Write parameters. This leads to inconvenience when formatting blank CDRW.
TEAC W54E CD-ROM, CD-R, CD-RW
  • There is HighSpeed logo on the front panel. If I'm not mistaken, this means that in can write to high-speed disks. Rather strange, the device is 4x4x32. Really, it cannot write to such disks.
  • Ignores mismatches of Copy, CopyProtect bits in Write Parameters and in Track Parameters (on Packet tracks).
PS. In general, it is perfect device. It almost fully complies MMC specification. (Except one thing, that doesn't make any inconvenience).
Pioneer DVD-RW DVR-105 CD-ROM, CD-R, CD-RW, DVD-ROM, DRV-R, DVD-RW
  • Requires SYNC_CACHE command after each WRITE command when writing using Fixed Packet (UDF). Otherwise reports LONG WRITE IN PROGRESS.
  • Understands both MODE_SENSE/SELECT_6 and MODE_SENSE/SELECT_10. But returns incorrect WRITE_PARAMETERS page when MODE_SENSE/SELECT_6 is used. Also, MODE_SENSE/SELECT_6 cannot change WRITE_PARAMETERS.
NEC DVD_RW ND-2510A CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-R, DVD-RW, DVD+RW, DVD+R DoubleLayer
Perfect device. Reads even plates from tea set ;). Complies main part of MMC specification. At least my driver did't detect any deviations and worked well with it.
NEC DVD_RW ND-1300A CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-R, DVD-RW, DVD+RW
  • Have problems with reading scratched disks and old CD-RW disks.
  • Sometimes requires SYNC_CACHE command after WRITE command when writing using Fixed Packet (UDF). Otherwise reports LONG WRITE IN PROGRESS.
PS. Not bad device.
BENQ DVD DD 1620 CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-R, DVD-RW, DVD+RW, DVD+R DoubleLayer
ATAPI DVD DD 2X16X4X16 CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-R, DVD-RW, DVD+RW, DVD+R DoubleLayer
  • After VERIFY_10 and VERIFY_12 falls into interesting mode: all READ requests actually perform VERIFY operation. So, drive checks if the requested block is readable and returns appropriate status. But it returns zero-filled data buffer. This can be cured with hard reset.
  • Cannot correctly mount DVD-RW in background formatting state. If such disk was not turned into compatible (with DVD-ROM) state (with closed session), the following happens: the disk is recognized as DVD-ROM, its size reported as for fully formatted DVD, read attempts beyond actually formatted area fail with error and 2-3 seconds delay. I understand, that according to MMC-5 mounting of such disk optional, but...
  • If during disk recognition operation neither programm send any command (even such harmless ones as TEST_UNIT_READY or GET_EVENT), sometimes the disk of described above format is mounted properly. But only sometimes. If any command was issued, the bug is reproduced.
  • Have greate problems with reading scratched disks and used for a long time CD/DVD-RW disks.
HL-DT-ST (LG) DVDRAM GSA-4081B CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-R, DVD-RW, DVD+RW, DVD+R, DVD-RAM
  • Slows down (10 times) when sending WRITE_PARAMETERS during DVD recording. No errors reported, but devices thinks about something.
PS. Not bad device. Reads old and scratched disks normally. Doesn't make long delays on read errors. Complies main part of MMC specification. At least my driver did't detect any deviations and worked well with it.
<< Back designed by Alter aka Alexander A. Telyatnikov powered by Apache+PHP under FBSD © 2002-2017