Which drives lack error scanning, which support it?



HL-DT-ST is the infamous error-scanning-excluder, chronically.
The only drive I know to support error scanning partially is the BE14NU40:

  • Only C2 support, C1 graph stays blank.
  • First CU or POF error aborts the error scanning.

HL-DT-ST drives sometimes instantly finish error scanning without any scanning, sometimes give an SCSI error code. And when trying to retract the tray of a slim drive, which is mechanically only possible manually, TSST gives SCSi sense error 0x052000 while HL gives back nothing.

But what about new Panasonic and Pioneer drives? And other manufacturers?


Hmmm …

If C1 is completely absent, this suggests the drive might only be producing C2 data with the generic read cd type commands. One of the modes of the read cd command will append the C2 data in the returned data (along with the sector data). This is nothing special.


But it happens with Nero DiscSpeed error scanning, where TSST reads C1 and C2.


Does Panasonic support C1C2?.


The hard part is figuring out exactly how discspeed is getting that data. I don’t have any insight into how these scanning programs function.

Though if I had to guess, most likely they would try out various known read commands and see whether any valid data is produced. If the first or second methods fails to produce any valid data, they’ll go down the list of possible read commands until they find a command which works.

The c2-only data on some LG manufactured drives, suggests it is using a generic read cd type command to get the c2 data.

I wouldn’t be surprised if the first thing scanning programs do, is to see whether the drive’s reading/error behavior can be changed with a scsi mode select (10) type of command.


QpxTools for Linux is open-sourced.


Thanks for mentioning this. I wasn’t aware of it.

As far as I can tell from skimming the code, a lot of the read commands appear to be undocumented vendor specific type stuff.


Just as I suspected. The qpxtools code even includes a “generic c2” case which gets c2 data via a generic read cd command.

Most of the qpxtools code dates back to drives from the 2000s era, where many are not manufactured anymore (ie. benq, non-mediatek pioneer, nec, sanyo plextor, etc …). Older versions of the qpxtools code reflects this.

QpxTools doesn’t seem to have any LG drives listed at all, whether original or rebadged.

So if LG (or vinpower) has a special firmware which can reveal more data for dvd/bluray drive scanning, the scsi opcodes are currently undocumented.


CD-scanning is since long time a problem. Most recommend DVD-RW-drives are old Benq (not all), Plextor, some old Plextor and LiteOn CD-RW-drives, maybe also some NECs. Somer newer LiteOn 24x DVD-RW-drives can also scan with C1/C2, but I would not trust em.

Actual drives with C1/C2-support I don´t know

Panasonic-drives can not scan, Pioneers QSI-clones also not


Wonder if this is specific to the design of Panasonic MN* chips.

I noticed on my pata LG drive with a Panasonic MN* chipset, it does not give back c2 data. In order to read the audio cd sector data, I had to modify the read cd command parameters such that it doesn’t return back any c2 information. Otherwise I keep on getting a read error.


You’re welcome.
You could modify the code anytime you like.

Very interesting. You know many details. We are glad to have you on the forums. Unfortunately, @Ceym6464, another excellent member who provided insights, vanished without any trace.

Probably very rare.
They also support PCAV/ZCLV setting for reading by firmware.

Wow, that’s terrible news. Now, TSST is dead and we are ditched with drives without scanning?.

How about C1?

And how about only returning C2 without any sector content reading? What SCSI sense/response code does it reply with?


My Panasonic-drives are much newer than LGs with Panasonic chipsets. I guess my old GSA-H22L have a Panasonic chipset, also my Benq 1670.

But I don´t know whether these drives can scan CD or DVD, maybe I tried it as I bought it, but can´t remember.


Benq 1640, 1650, 1620 are to recommend, can be found at Ebay. But you never knew in which condition are these old drives. IMHO these are the ultimate drives for CD-scans, also because it can scan more than C1 and C2

P-CAV is correct, but Z-CLV-scans I´m not sure. However, P-CAV is great and fast, much better than 8x CAV of the competitors.

Other good CD-scanners like LiteOn CD-RW are more rare, Plextor also and mostly very expensive. I don´t used Plextor often for scans because it is very slow and and I don´t like the graphs of Plextor-Software

I´m not sure about Panasonic-drives, my newest is made in 2013, maybe Panasonic don´t próduce it anymore?

QSI maybe also stopped production, Original QSI-drives are not to found in Germany, the Pioneer-QSI-drives getting rare, my DVR-221 is produced in 2014.


I don’t know offhand.

I don’t remember which sense data it gave back. I didn’t check for the additional sense data in that particular case.

If I’m repeatedly getting all zeros in the data buffer allocated for the sector data when it should not be all zeros, then that’s usually a sign that something is wrong an in error. So I changed the read cd command parameters slightly, where it didn’t ask for any extra c2 data, and then it was returning the correct audio cd sector data.

I don’t know if it is possible to just return back c2 alone, using only the generic read cd commands. One would have to read the spec more closely.


I have no idea how the qpxtool guys got all that undocumented vendor specific information.

If I didn’t know any better, one tedious way would be the disassemble the executable binary of a scanning program and seeing what scsi opcodes are used. A slightly less tedious way would be run the scanning program inside a debugger (possibly kernel level), and watching for which scsi commands are executed.


I understand.
Undocumented is annoying.

There was somewhere a SE-218 and a Pioneer SCSi documentary.


I ran some of the undocumented scsi opcodes which only did reading, to see what data is returned.

The ASUS specific section in qpxtool asserts that it is for mediatek drives from around 2007-2009, where they use some undocumented scsi mode sense pages to read scanner specific data. On a few mediatek drives I have (ie. LG, QSI/Panasonic, etc …) this particular mode sense page is entirely absent.

Doing some googling for these particular asus models (ie. DRW 1612, 1814, 2014, etc …), there is an assertion that these mediatek drives were possibly designed in-house by ASUS. Pioneer models DVR-112N, 113NP, etc … might possibly be rebadges of these short-lived ASUS designed mediatek drives.


For the LiteOn and Samsung/TSST mediatek drives, the dvd section of the qpxtool code asserts they have the same scsi opcode for handling pi type data. (The cd specific sections are drastically different).

So I ran this undocumented LiteOn/TSST opcode specific to dvds, on an LG mediatek drive. It gives back 10 bytes of data which I don’t know how to interpret. The Samsung/TSST and LiteOn specific qdx code asserts bytes 2-4 might represent an “lba” of some sort, bytes 5-6 might represent PIE, and bytes 7-8 might represent PIF. No idea what bytes 9 and 10 represent.


If one were to take this interpretation ^ literally on faith, the returned data I got from an LG mediatek drive would assert that a particular sector(s) read had a PIE = 2 and PIF = 0.

If you’ve been following the discussion of error correction on PO data on another thread, I came across a textbook theoretical bound which asserts that the maximum number of correctable erroneous bytes in a reed-solomon error correction block is equal to half of the number of extra error correction bytes tacked on to the data block.

In the case of PO it has 16 extra error correction bytes tacked on to a 192 bytes data block, where the theoretical bound asserts at most eight erroneous data bytes can be corrected by the reed-solomon decoding algorithm. In practice only four erroneous bytes could be automatically corrected, while 5-8 erroneous bytes could only be corrected in some special cases.

If something similar is happening for PI error correction, then the theoretical bound would assert that at most 5 erroneous bytes could be corrected by the reed-solomon decoding algorithm. A PI data dock is 172 bytes with 10 extra error correction bytes tacked on. I wouldn’t be surprised if the reed-solomon error correction can only automatically fix two or three erroneous bytes in a PI block, while correcting four or five erroneous bytes would require a special configuration.

If the above PIE = 2 with PIF = 0 data I got from that undocumented scsi command running on an LG mediatek drive is actually for real (and not random junk data), then this might support the notion that reed-solomon decoding can automatically correct two erroneous bytes in a PI block of 172 bytes. So far I haven’t seen any data which suggests it can automatically correct three erroneous bytes (ie. PIE = 3 with PIF = 0).


More generally.

At this point, I have no idea how exactly PIE is measuring errors.

For any one ecc block of 16 consecutive sectors on a dvd, it has 208 blocks of 172 data bytes + 10 extra error correction bytes tacked on for each sequential 172 data bytes.

If PIE is measuring anything, is it counting the number of non-zero syndrome calculations on each batch of thirteen PI blocks per sector or over an entire ecc block of 16 sectors? (A calculation of a non-zero syndrome means there is an error in a particular PI 182 bytes block).