Redump Forum

The best route might be to find a CodeLock game that's already dumped on eBay US and see if you can verify that. The drive that can verify another dump should also produce a correct dump of the US Tropico. If the error count is the same as your current dump (and twice that of the Europe release) then it could be explained by different mastering.

https://redump.info/discs/quicksearch/cod … ction/only

Surely there's some cheap ones on medimops.de also if you search for the barcodes there (without spaces), but I don't know if they're shipping again to the US (they restricted it because of COVID).

I reported this protection before. /viewtopic.php?p=37722#p37722
0xd8 dumping can get the string that is recorded in the disc. But redump db adopts the result of the 0xbe dumping less error count.

sarami wrote:I reported this protection before. /viewtopic.php?p=37722#p37722
0xd8 dumping can get the string that is recorded in the disc. But redump db adopts the result of the 0xbe dumping less error count.

Are there C2 errors when dumping this protection?
And what's the explanation for the lower error count? Is the drive correcting bytes in 1 sector when using 0xbe?

Logs. https://www.mediafire.com/file/js0a6rkd … 29.7z/file
C2 errors: 1445. vs your dump https://redump.info/disc/31708/ is 722

sarami wrote:Logs. https://www.mediafire.com/file/js0a6rkd … 29.7z/file
C2 errors: 1445. vs your dump https://redump.info/disc/31708/ is 722

Yeah but 1 of the 2 sectors is always just 22-23 bits.. do C2 errors take into account offset correction?

For intentional C2 errors like here we always fill with 0x55 pattern.

Jackal wrote:do C2 errors take into account offset correction?

I'm not sure...

BTW, I got the same result as your dump using ASUS BW-16D1HT (FW:3.10)
https://www.mediafire.com/file/c1c53cvy … HT.7z/file

I found it difficult to dump the Code Lock for plextor 0xd8, while scm file is important because meaningful string (beware the jabberwock my son ....) is replaced by 0x55 for img/bin file.

I guess we need to do more research.. maybe the SafeDisc scrambled data is also meaningful.. but I always assumed that there could be no good/reliable data hidden behind a C2 error.

I did test dumping (via DIC) this Tropico disc on my BH14NS40 cross flashed to BW-16D1HT 3.02. It gets way too many errors (7700 bad sectors) compared to the other drives. I can post the logs if anyone wants to see, but I'm not sure there's much useful there.

Is there an option in DIC to retry reads due to C2 errors even if the sector contains a protected file? I'd noticed in reading this disc with another drive that sometimes, with a sufficient number of retries, a few errors went away. But DIC doesn't retry these sectors because of the presence of a protected file.

I've placed an order for a Code Lock game that's already in the database. Once that arrives, I should be able to test my setup. I'm also on the fence about ordering another Optiarc drive just for the hell of it. They're nice drives, and my purchase of a cheap AD-7290 is probably the best thing that's come from the ordeal of trying to rip this disc.

My Tropico matched the db https://redump.info/disc/53929/ Mould SID Code is IFPI 8725 and others are the same.

Logs: https://www.mediafire.com/file/igd353s5 … e).7z/file

scsi_wuzzy wrote:Is there an option in DIC to retry reads due to C2 errors even if the sector contains a protected file?

No.

Jackal wrote:I guess we need to do more research.. maybe the SafeDisc scrambled data is also meaningful..

I think so from the viewpoint of data preservation.

sarami wrote:My Tropico matched the db https://redump.info/disc/53929/ Mould SID Code is IFPI 8725 and others are the same.

Hopefully that's what I'll see when my European disc arrives. As it stands, I don't have any Code Lock discs that are identical pressings to those in the database. My Tropico disc is the North American version, and, while I suspect the errors are in the same locations (or nearly the same locations) as the European release in the database, it's definitely a different pressing. The sector count differs, etc.

So, my question is if I just haven't found the right drive to read my NA release with single errors, or if the error count is doubled compared to the European pressing. Hopefully, if I can verify that one or more of my drives will read the European disc with correct results, such a drive can be trusted to submit this NA release to the database, and we'll (sort of) know how many errors this damn disc is supposed to have.

Edit: I'm just realized I'm using the FW 3.02 on my BW-16D1HT (the one recommended by the Wiki). Sarami is using 3.10. It seems unlikely this explains the different behavior, right? I feel it's more likely the disc, but we are running different FW revisions... Does 3.10 have all the features that 3.02 does in terms of 0xF1, 0xBE on data sectors, lead-in, lead-out, etc?