Guess, you can try to extract all the sectors with cdtoimg_d8 and descramble them in software.

i think i'll stick this topic for now
since there could be quite a lot people with Plextor drives
hence affected with this issue

worst thing is that, since it's masking erroneous data,
theoretically there could be CDs in DB that pass as good on e.g. CDMage,
i.e. look absolutely ordinary, but actually were affected

though AFAIR all of such CDs i checked still had some mastering artifacts present
as does yours

I checked the headers that were previously nulled and they were intact in this read.

I don't seem to get the luxury of error detection in this raw read mode, so it didn't perfectly match up, but at least I know now that the Plextor was actually damaging the data rather than "getting 350 good sectors".

resulting file 'rawdata.scr' will have 128 bytes missing from the end
(corresponging to offset)
but should match to image extracted with other drives up to that point, so
fc /b rawdata.scr "Track 01.bin" |more
should result in:

it's a strange coincidence with motherboards and i would use IDE2USB converter too
but i've just tried it on older Gigabyte GA-8I915ME with almost clean XP SP3 (through USB)
and AFAIR this problem initially occured when drive was connected to internal IDE controller
yet symptoms remain - must be Plextor's firmware after all
but still it would be really great if you could check this CD on a different system - to be absolutely certain

cdtoimg seems to be outputting garbage data, even reading at 1x :\

How can I read from the buffer? I can try swapping later, but I'd prefer something that didn't involve manually ejecting the tray.

My motherboard is coincidentally an ASUS P5Q Pro, but I'm using the drive through an IDE>USB interface.

thank you for reporting this

i had this same problem with Plextor Premium in the past
and i thought it's a specific of my model
so i guess this is issue affecting Plextor drives in general then

reading CD with D8 command, swapping audio CD or fetching data directly from buffer
should yield correct output

edit:
what motherboard do you have, btw?
mine is ASUSTeK P5QL-E

I dumped the disc on my GH20NS15 and LH-20A1H with matching results. I also matched this to an image I found on the Internet. The disc has 1,916 sector errors, all in the ASOCCER speech files, like so:

So far so good. Matching in two drives + an internet source = good dump, right?

The problem I have is that my Plextor PX-760A gives a different result. More specifically, it dumps with fewer sector errors. When I dumped twice yesterday (without recycling), the resulting dumps had only 1,556 sector errors and matched. Today I dumped the disc twice again in the Plextor, recycling the drive each time, and came up with non-matching dumps with 1,557 sector errors.

So my question is, what can I do from here? If I didn't have the Plextor to begin with, I'd have reasonable grounds to call a good dump. The Plextor isn't giving off consistent results, making it not a reliable indicator, but it still stands that it's getting 350 good sectors that my other drives can't.

GH20NS15 (1,916 sector errors):
SHA-160     : 63F828EC7BB0A8317E10E934D434560475DBE8BB
MD5         : ACFA22E8B9018B16B3BB82009A3EC886
CRC-32      : 1A138846

LH-20A1H (1,916 sector errors):
SHA-160     : 63F828EC7BB0A8317E10E934D434560475DBE8BB
MD5         : ACFA22E8B9018B16B3BB82009A3EC886
CRC-32      : 1A138846

Web-sourced track 1 with last sector fixed with psxt001z.exe (1,916 sector errors):
SHA-160     : 63F828EC7BB0A8317E10E934D434560475DBE8BB
MD5         : ACFA22E8B9018B16B3BB82009A3EC886
CRC-32      : 1A138846

Plextor PX-760A two dumps with no recycle inbetween (1,556 sector errors):
SHA-160     : 4450E22CA8739BC713A3C5C39F7F50024D7063F0
MD5         : AC9EF9042F722C909398C803283EAA40
CRC-32      : E7D8181A

Plextor PX-760A dump 1/2 with recycle (1,557 sector errors):
SHA-160     : 1A533DAE98B15B2168911949463FB94ECFBE4E44
MD5         : EB7CD639F58C212B5B4B28A93B4F4D79
CRC-32      : C6F9D9FB

Plextor PX-760 dump 2/2 with recycle (1,557 sector errors):
SHA-160     : 14D652DB6272DA981B4463971F8AEAB9E9244EFD
MD5         : 94D5819ACE0E280B58A32EF4486117F5
CRC-32      : F34DA670

For the sake of curiosity, I dumped a length of sectors which differed in the two drives and looked at them in HexCmp2. The only differences between the two drives is that the GH+LH have 5 bytes of data in each sector, while the dumps from the PX do not, like so:

This 5 byte string goes like this:
01 0C 64 04 01
01 0D 64 04 01
...
01 1F 64 04 01

After which it resets to 0C and starts again.