Thanks Guys, finally getting there.

Very strange how DiC and my plextor drives don't match that.

Maybe time to order a new Plextor.

Here are my hashes of the data track of T-15913H-50, dumped with a non Plaxtor drive with IsoBuster

rom ( name dbtrack1.iso size 322113456 crc a41d7727 md5 18419a0a9ace416e8f0ef384fc70f7f0 sha1 0eef922b201a1a639854a55af97b5c45cab2e8c6 )

cdmage error count?

rom ( name dbtrack1.iso size 322113456 crc a41d7727 md5 18419a0a9ace416e8f0ef384fc70f7f0 sha1 0eef922b201a1a639854a55af97b5c45cab2e8c6 )

The first error sector probably yes, because ECC/EDC is intact. It's possible that normal reading of the sector will give the correct(ed) output. Repairing the current dumps will will yield the correct sector with the same user data as the (Germany) region dump.

The second error sector has the user data intact, but ECC/EDC area has modified bytes in the last last 144 bytes. This maybe the result of the way that DIC reads the discs. Anyway, with only the last 144 bytes corrupt, cdmage still manages to repair this sector correctly, and different drives might also be able to read this sector correctly.

The last error sector (29669) is the real problem. DIC doesn't seem to produce any correct data and the sector is fully scrambled. We need to compare outputs of non-plextor drives to a plextor 'ECC off' read from cdtool and look for consistent bytes.

You can't trust DIC output if there are C2 errors. The output that it creates is unique to plextor drives and should not be included in the final dump. Repairing the first 2 errors is the most sensible approach, because this should be consistent with the output of other drives, and also better than replacing the entire sector contents with a dummy (0x55) pattern (this is how we deal with intentional C2 errors that are part of copy protections), because here it would mean losing valid data.
As for the last error sector, if no drive produces a valid data sector, then the only sensible approach would be to replace it with dummy contents.

I'm hoping someone can shed some light on this one.

Background:

I am trying to dump a Euro copy of a Sega Saturn game, Blazing Dragons

I have two physical copies of this disc.

both of them encounter 2 C2 errors at exactly the same places

Both dumps turn out identical CRCs

The C2 error log is identical for both :

LBA[001895, 0x00767], BytePos[4457040-4459391, 0x440250-0x440b7f] C2 error exists. Error byte num: 24
LBA[029670, 0x073e6], BytePos[69783840-69786191, 0x428d120-0x428da4f] C2 error exists. Error byte num: 312
LBA[001894, 0x00766], C2 error doesn't exist. Next check 2352 byte.
LBA[001895, 0x00767], BytePos[4457040-4459391, 0x440250-0x440b7f] C2 error exists. Error byte num: 24
LBA[029669, 0x073e5], C2 error doesn't exist. Next check 2352 byte.
LBA[029670, 0x073e6], BytePos[69783840-69786191, 0x428d120-0x428da4f] C2 error exists. Error byte num: 312
LBA[001894, 0x00766], BytePos[4454688-4457039, 0x43f920-0x44024f] Reread data matched. Rewrote from [4454224, 0x43f750] to [4456575, 0x44007f]
LBA[001895, 0x00767], BytePos[4457040-4459391, 0x440250-0x440b7f] C2 error exists. Error byte num: 24
LBA[029669, 0x073e5], BytePos[69781488-69783839, 0x428c7f0-0x428d11f] Reread data matched. Rewrote from [69781024, 0x428c620] to [69783375, 0x428cf4f]
LBA[029670, 0x073e6], BytePos[69783840-69786191, 0x428d120-0x428da4f] C2 error exists. Error byte num: 312
LBA[001895, 0x00767], BytePos[4457040-4459391, 0x440250-0x440b7f] C2 error exists. Error byte num: 24
LBA[029670, 0x073e6], BytePos[69783840-69786191, 0x428d120-0x428da4f] C2 error exists. Error byte num: 312
LBA[001895, 0x00767], BytePos[4457040-4459391, 0x440250-0x440b7f] C2 error exists. Error byte num: 24
etc
etc

as is the Mainerror.txt file

LBA[029669, 0x073e5], Track[01]: This sector is data, but the header doesn't exist

Both full DIC logs are here along with the subdump (-quick)

https://www.dropbox.com/sh/6zyarsrm33td … zyWEa?dl=0

Next steps please?

* EDIT * Files removed as requested