1 Topic by wiggy2k (edited by wiggy2k 2017-06-05 10:35:08)

  • From: North East UK
  • Registered: 2016-06-15
  • Posts: 1,063

Guys,

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.
https://s15.postimg.org/ws8g3i89j/Discs.jpg

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

https://s15.postimg.org/csin7plqv/cmds.png

Both dumps turn out identical CRCs

https://s15.postimg.org/b4jht27vb/crcs.png

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

2 Reply by Jackal (edited by Jackal 2016-08-27 10:22:26)

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

The first thing to check is how a non-plextor drive deals with these sectors. Can they be read at all?

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.

  • From: Portugal
  • Registered: 2009-05-13
  • Posts: 865

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 )

"Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath a clear blue sky?"
  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

RetroGamer wrote:

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?

  • From: Portugal
  • Registered: 2009-05-13
  • Posts: 865

Sorry, already checked but i forgot to include in the original post... 0 errors

"Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath a clear blue sky?"

6 Reply by Jackal (edited by Jackal 2016-08-27 16:39:29)

  • Jackal
  • Moderator (Retired)
  • Offline
  • Registered: 2006-12-23
  • Posts: 4,132

Got the same hashes after fixing all 3 errors (for the last sector I imported the user data from the Germany dump and rebuilt ECC/EDC). I think we can conclude then that DIC/plextor is messing up here. Hopefully wiggy2k can get the same hashes with a non-plextor drive.

  • From: North East UK
  • Registered: 2016-06-15
  • Posts: 1,063

Affirmative

Thanks Guys, finally getting there.

https://s9.postimg.org/vnwntoucr/finally.png

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

Maybe time to order a new Plextor.