1 (edited by scsi_wuzzy 2020-07-13 14:31:05)

I've got a copy of Tropico for PC that I'm having issues dumping. I believe it's a US copy, but it doesn't appear to match the copy in the database.

BurnOut says the disc has "Code Lock" copy protection. I couldn't find anything about that protection online, but it seems to be similar to SafeDisc in that there are a number of intentional bad sectors on the disc. One thing that is bizarre about this disc, that I've never seen with any of the other discs I've dumped, is that you can physically see where the error sectors are on the disc. There's a line, maybe about 2mm wide, where the silver is a completely different color. It's maybe 3-4mm from the start of the data on the disc. I've ripped tons of discs with SafeDisc, etc. and I've never seen one before where I could physically see the defects, so this is something new for me. It looks similar to...you know how some manufactured discs you can see a line where the data ends? It's like that, except in the data and very narrow. I know it sounds like some kind of disc rot or something, but I really don't think it is. The disc looks good and all the files can be copied without issue.

So far, I've tried to dump the disc with DiscImageCreator on a PX-760A and a PX-716AL and with Alcohol 120% on an ASUS BD drive and a LG BD drive. DIC reports that there is in fact a protected file, and the 716 and 760 both report C2 errors, though not with a consistent number of bits (in contrast to SafeDisc where you generally see 312 bit C2 errors). Here's what is in the C2 log from the 716AL: https://pastebin.com/DQntkqMr

Also note that this list of errors is different between rips. The number of C2 bits is different, but also the reported list of sectors is different (e.g., the above list includes LBA 10022, but other times I rip that sector won't be there). Here it is when I ripped with the 716AL again (at a different speed): https://pastebin.com/tvQnSVt9

The the list is also different between rips when I use the 760A -- neither can produce a consistent image.

The even bigger problem, though, is that the resulting image produced by DIC is unusable. Despite the fact that it looks like all the reported C2 errors are intentional, if I open the image with CDMage, it reports that the "Data track has errors in the file system" and none of the files are present. However, the disc itself is in fairly good shape, and, as I mentioned previously, I'm able to copy all the files off without issue.

Additionally, I was able to image the disc with Alcohol 120%, and it produced an image with no filesystem errors (just errors corresponding to the protection sectors). However, it looks like even Alcohol 120% probably won't be able to reliably image the disc. I've just started imaging on another drive (it takes like 16+ hours to image the disc due to the errors -- I started it one night before I went to bed, expecting to see the results in the morning, but it was still running when I got up and for most of the rest of the day), and so far the reported error sectors don't look like they map to what is present in the image I already made.

Does anyone have any experience / advice on how to properly dump this disc?

On another note, Alcohol sometimes reports "Disc read error" and sometimes reports "Read data examination error." Does anyone know the difference between these two errors?

Edit: I forgot to link the log files! Here are the logs from the 716AL ripping at 8x: https://www.dropbox.com/s/xjmwh5diirdkr … gs.7z?dl=0. ECCEDC reports a mix of bad MSF, user data doesn't match, and invalid sync for the protected sectors.

This seems like another ring protection similar to Laserlock and CD Ring Protect. Jackal or Reentrant will have to chime in here if they have ever dealt with that particular protection, and if there is a method of dumping it. I gave up trying to dump discs with these protections as the results are inconsistent and we have no way of knowing if the dump is good or not.

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

Nexy wrote:

I gave up trying to dump discs with these protections as the results are inconsistent and we have no way of knowing if the dump is good or not.

I don't know anything about Laserlock or CD Ring Protect, but I'm kinda getting the feeling that, for this disc, it would probably be best to just completely ignore every sector on which the protected file exists and replace those with 0x55 sectors in the image file. I'm not convinced there's any real data in that region at all. I may build such an image and see if it works to satisfy the CD check in a disc emulator. Such an image wouldn't be "archival" quality, I guess (although, if there's not any real data there anyway, maybe it is?).

In any case, right now I'm just dumping for my own purposes and not submitting my dumps to the database, so "working" is probably good enough. I've come across a few of my personal discs where I couldn't get "archival" quality dumps, but I think this is the first one that's due to the copy protection and not just due to the disc being damaged.

4 (edited by LoStraniero91 2020-07-13 22:14:08)

I've only dealt with CodeLock once, and I can tell you it's a weird one: it's a mixture of both LaserLock (due of the rings) and SafeDisc (due of the errors being in a pattern instead of all bunched up together like your everyday ring protection).
Your best bet to dump a CodeLock protected game is to use CloneCD with a non-Plextor drive.

I think Jackal will be able to assist you even better.

Salviamo la cultura videoludica italiana.

LoStraniero91 wrote:

I've only dealt with CodeLock once, and I can tell you it's a weird one: it's a mixture of both LaserLock (due of the rings) and SafeDisc (due of the errors being in a pattern instead of all bunched up together like your everyday ring protection).
Your best bet to dump a CodeLock protected game is to use CloneCD with a non-Plextor drive.

I think Jackal will be able to assist you even better.

Thanks, this is helpful! It turns out there are actually some details I missed in the redump Wiki about CodeLock as well. I think I must've searched for "Code Lock" (with a space) previously, since that's what Burnout calls it, but the Wiki has some details buried in an article on CodeLock.

Indeed, based on what the Wiki says, Plextors are known to have issues with this protection. I've ordered a cheap Optiarc drive, since it sounds like maybe they're a good bet for this type of protection. Hopefully it won't still take 18 hours of reading to work like my LG did, lol!

http://forum.redump.org/post/54050/#p54050
be opcode replaces the original data to 0x55. I think it's not correct.

7 (edited by Jackal 2020-07-16 17:03:22)

Try clonecd with a non-plextor drive. It should read single errors and the error sectors are 5 sectors apart, or a multiple of 5 sectors IIRC. That's how you'll know if the dump is correct.

8 (edited by scsi_wuzzy 2020-07-21 04:42:18)

Jackal wrote:

Try clonecd with a non-plextor drive. It should read single errors and the error sectors are 5 sectors apart, or a multiple of 5 sectors IIRC. That's how you'll know if the dump is correct.

I got hold of an Optiarc drive, and I'm currently dumping the disc with that. Right now I'm using Alcohol, but I plan to try CloneCD and probably CD Manipulator as well.

Right now it looks there's...kind of a pattern? Maybe multiple patterns separated by larger groups of good sectors? It starts off with 3 bad sectors, 8 good sectors, 3 bad sectors.

But then there're 23 good sectors and a pattern starts with 3 good, 3 bad, 3 good.

Then 23 good sectors and a pattern of 3 bad, 13 good, 3 bad, 8 good, 3 bad, 3 good...

There's definitely some kinda pattern. I'll look at it in more detail once it's done and post an update. And, as I said, I'll dump in other software as well.

Edit: The Alcohol read got done. Errors look like they're always groups of three, and lots of sectors that were reported as "bad" by my Asus weren't reported bad here. Based on the description here, though, it sounds like maybe the Asus rip is good? At initial glance, it looks like all the Asus errors are in groups of 5, 10, or 15 sectors. So, if they're meant to be a multiple of 5, that sounds right. But then the Optiarc has substantially fewer errors...all groups of 3 with varying distances between them.

Edit 2: Here is the list of bad sectors from CDMage for both the Asus and the Optiarc: https://www.dropbox.com/s/8eu918bz0jg07 … 20.7z?dl=0. The Asus has 3779 bad sectors, in groups of 5, 10, or 15. The Optiarc has 2281 bad sectors, in groups of 3.

Edit 3: If I look at one of the sectors that the Asus errors on but the Optiarc doesn't, like sector 2464 for example, the data section is all 0. If I look at one near there that they both read successfully, like 2466, it's all 0 also.

Edit 4: Using CD Manipulator, I got 2,274 errors. I think each error is a three sector block. 2,274 / 3 = 758, which is the number of errors for one of the European releases of Tropico: http://redump.org/disc/53929/. Is that just a coincidence, though?

After spending some time with this, it looks like my Optiarc 7290H reads blocks of 3 bad sectors. Most other drives read blocks of 5 or more.

Whether the Optiarc is "right" or not I can't say, but I was able to get two reads from it with the same number of bad sectors: 2274. One of those dumps was with CDManipulator, and one with Aaru. The CloneCD dump was very similar, but it had two extra sectors that were marked as bad (for a total of 2276).

Using CD Tool, though, I was able to read the two extra sectors that CloneCD marked as bad. I can understand how CloneCD ended up marking these two bad, though -- it took a number of retries and at one point I had to eject and reinsert the disc to wipe the drive cache (or some kind of cache -- it kept erroring and then read it immediately upon reinsertion).

I suspect Aaru is a good dumper for these discs. For bad sectors, it (by default) makes 5 passes at reading each one, and each pass consists of one forward read and one backward read. I think that approach might help avoid the drive getting "stuck" on marking a sector bad that isn't. I haven't verified this is the case, though. This approach also makes Aaru take ages to read a disc. The log says it took 50422 seconds, or about 14 hours I guess.

One issue with Aaru, at least in terms of getting its dump to match the ones produced by other software, is that it doesn't replace bad sectors with 0x55. It instead zeroes out the whole sector, including the sync, header, etc. That should be a relatively easy software fix for such images, though. For now, I used CDMage and imported the bad sectors from the CDManipulator rip. The dumps then matched. I haven't bothered to make sure that the bad sector list matches between the two, but I suspect it does. I'll check that next.

So, I think maybe I have a good rip?

10 (edited by Jackal 2020-07-23 15:57:44)

I think CodeLock is always single errors. If it reads in blocks of 2 or more errors then something is wrong with your drive or drivers or the read mode that is used. The correct error count is most likely 758 for your disc, just like the Europe one. Do you have any other drives that you could try? And no point in retrying sectors. Either the drive reads them or it doesn't. Plextors are unable to read single errors.

11 (edited by scsi_wuzzy 2020-07-23 18:37:31)

Jackal wrote:

I think CodeLock is always single errors. If it reads in blocks of 2 or more errors then something is wrong with your drive or drivers or the read mode that is used. The correct error count is most likely 758 for your disc, just like the Europe one. Do you have any other drives that you could try?

Do you know which drives might be best to try next? I've tried so far an Asus BW-12D1S (a rebadged Pioneer, I think), multiple Plextors (Premium, PX-760, PX-716), two different LG drives (BP50NB40 and GP60N), an Optiarc (AD-7290H), and a LiteOn (iHAS124). So far, the fewest errors were given by the Optiarc (3 in a row) (Edit: Fewest as in "smallest groups". I think by raw error count, the LiteOn was lower.). Most drives gave 4 or 5 errors in a row. There might be some hope from the LiteOn if I read a bunch of times and combine rips, though, because it sometimes only has 2 in a row (and sometimes 4, but usually 3).

I'm currently trying the Panasonic in my old laptop (UJ260AF), but so far it's reading errors in groups of 5 or more.

I've got some other drives in storage, and I'm willing to buy some more cheap drives (I already bought a cheap Optiarc to see how it'd perform). The obvious thing would be to try a drive with a different chipset, but I think I've tried most chipsets (IIRC, the Plextors have Sanyo, probably at least one of the LGs is a Renesas, LiteOn is probably Mediatek, Optiarc is NEC, etc.) at this point, though, so I'm not sure where to go next. I haven't tried any of my old SCSI drives yet -- maybe they'll behave differently? It'll be a while before I can get any of them out of storage to try, though. Maybe the smaller cache might help...

Jackal wrote:

And no point in retrying sectors. Either the drive reads them or it doesn't.

That's what I thought, too, but Aaru was actually able to read two more sectors after a *ton* of retries on the Optiarc. Unfortunately, that just made it match the CD Manipulator dump and didn't really provide anything new compared to my other dumps. I think the LiteOn was able to read a few sectors that the Optiarc wasn't, though, so maybe I can dump the disc a few more times and narrow down which sectors are "supposed" to be bad.

Maybe I should try Aaru on the LiteOn just for the hell of it. It seems like maybe it has the most promise in terms of the number of errors. Last time I dumped with CloneCD. What's another 14 hours, lol.

On another note...is it possible to get a list of which sectors have errors for the European version of Tropico? I'm curious how it maps. I also wonder what drive(s) it was dumped on.

Edit: I gave up on the Panasonic -- it was showing errors in groups of as many as 10. I remembered I had a TSST that wasn't in storage (SH-224). So far it's erroring only in groups of 2, so maybe TSST is the winner.

12 (edited by Jackal 2020-07-23 19:11:05)

It's probably a driver issue. Most drives such as that Optiarc should be able to read single errors with CloneCD.

Jackal wrote:

It's probably a driver issue. Most drives such as that Optiarc should be able to read single errors with CloneCD.

I'll look into that possibility. I've only tried three different machines so far (a Windows 10 desktop with the LiteOn drive connected via onboard SATA, a Windows 7 laptop with the Panasonic drive connected via onboard SATA, and then my "main" ripper which is an Intel NUC running Windows 10 with a USB -> (P/S)ATA adapter plugged into it, where I tested all the other drives), but I've got more machines I can try. I pulled the TSST from my old (Windows 10) desktop, and I reckon I can try switching in different drives in that machine to get a dump from yet another SATA controller and avoid the SATA -> USB adapter (in case that's causing problems).

I feel like it's possible some of the emulation layers or other drivers installed by Alcohol / CloneCD could possibly mess with things, but one of the machines I tried didn't have either of those programs installed (the desktop machine with the LiteOn drive, where I just dumped using CDManipulator).

I also might try dumping in Linux, but I dunno if any software there will handle bad sectors the way CloneCD / CDManipulator / Alcohol do. It looks like there are Aaru builds for Linux, so I might try that -- I can manually replace the bad sectors with 0x55 later on if I can get a good dump from it. I know there are DIC builds on Linux too, but I dunno what DIC does with bad sectors when you use the regular "data" command for non-Plextor / 0xbe drives. (I assume it replaces then with 0x55 since that's probably what happens when the data command is used to read the ring on an Optiarc and merge later.)

Thanks for the input. I'll try at least one more machine with a mix of different drives and see if I get the same results.

Could you post a scan or picture of the disc? I guess I could look for a copy, if it's a different release from the one that's dumped.

15 (edited by scsi_wuzzy 2020-07-24 00:30:11)

Jackal wrote:

Could you post a scan or picture of the disc? I guess I could look for a copy, if it's a different release from the one that's dumped.

I've attached scans of the front and back. I'm fairly certain it's a different version of Tropico than the existing CodeLock one in the database. CloneCD gives an image of size 776,559,840 for this one -- smaller than http://redump.org/disc/53929/. The mastering ring is different too (though they're both Disctronics). I wouldn't wish the frustration of this disc upon anyone, so obtain at your own risk!

On a completely random note, I think this is the only disc I have where the mould SID is directly on top of the mastering SID.

Regarding the drivers: I just put the Optiarc drive in an old Windows 7 desktop machine I forgot existed (like Core 2 Quad era old). This machine has an older generation of SATA controller than the other machines I tried, and so likely has different drivers as well. It's dumping with CDManipulator on that machine right now, and so far it's still getting errors in sets of 3 in the same pattern as seen on the other machine when the Optiarc was used. I plan to cycle various SATA drives (TSST, Optiarc, maybe LiteOn) through this machine just to see what happens with it, but right now it's looking like it'll probably be mostly the same outcome based on the Optiarc.

I also dropped the Optiarc drive like 2 feet onto the ground what I was installing it. I dunno if that invalidated the experiment, though, lol. It looks like the drive still works the same way it did.

Edit: It got done using the Optiarc on the other machine with 2276 errors. I'll try the TSST next.

Post's attachments

TropicoBack.jpg 1.02 mb, 13 downloads since 2020-07-23 

TropicoFront.jpg 1.51 mb, 13 downloads since 2020-07-23 

You don't have the permssions to download the attachments of this post.

I think the bottom line on this is gonna be that we can't verify that the dump is good or bad unless you buy a disc that's already dumped and verify that. It's possible that due to different mastering, the USA disc has more errors.

Here are some places to buy Tropico (Europe):
https://www.medimops.de/tropico-pc-von- … 5AM6R.html (3 EUR shipping to US)
https://www.ebay.com/itm/Tropico-pc-gam … SwWxNYuH-S

Your disc is clearly the US version according to the rating system printed on the disc.
I dumped my copy without problems with CDmanipulator and DDump in 2 different LG drives.
Maybe the US version has a different protection since i don't see the ring on the disc that you saw on yours...

"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?"

18 (edited by scsi_wuzzy 2020-07-24 21:04:58)

Jackal wrote:

I think the bottom line on this is gonna be that we can't verify that the dump is good or bad unless you buy a disc that's already dumped and verify that. It's possible that due to different mastering, the USA disc has more errors.

I may pick up a copy of the European version just to verify that my setup will dump the Europe copy with identical results to what's in the database. Unfortunately, if anyone in Europe wants to try their hand at the US copy, it looks like it'll be expensive. The game itself can be bought for ~$5 US, but the sellers I saw all wanted huge amounts ($20+ US) to ship anywhere outside of North America.

RetroGamer wrote:

Your disc is clearly the US version according to the rating system printed on the disc.
I dumped my copy without problems with CDmanipulator and DDump in 2 different LG drives.
Maybe the US version has a different protection since i don't see the ring on the disc that you saw on yours...

I'm so used to seeing the US ratings on discs I didn't think about it!

Thanks for that information about the lack of a ring on the Europe version -- that makes it sound like maybe I should expect different behavior on my US copy. The ring itself is also visible (slightly, mostly to the left and right of the center hole) in the scan of the disc I attached above, for anyone curious about its appearance. Am I curious, though, do you happen to still have the log of the error locations? I dunno if it would be useful information, but if they happen to "line up" it might provide some insight.

The way the disc acts is as if there are just bad spots on it. Not even just intentionally bad sectors -- just bad spots. It reports a wild number of C2 errors if dumped with a Plextor, different drives can read different sectors, and sometimes retrying enables a drive to read more sectors. It's as if they just damaged the data layer such that there's not even anything to track, and the drives just don't know what to do. Some drives find 5 sectors of errors, or 10, or 15, and some drives find 2 or 3. None of them I've tried, and I this point I've tried I think 6-7 drives, find single errors at any of the error positions on the disc.

The "best" rip I've been able to get so far is from a TSST drive, where it only had 1516 errors. I made that rip with Aaru, and I had the drive dump all night retrying forward and backward over and over. Unlike the Optiarc, it was not able to read any more sectors on the re-reading passes.

I think I agree with Nexy's post earlier in the thread -- it sounds like dumping these discs, unfortunately, isn't worth the effort. It's very time consuming, and it's impossible to tell if a rip is "good."

There's one last thing I'm debating trying, just to see what happens. I'm thinking I might throw together a program to just try reading sectors over and over using 0xd8 on one of my Plextor drives, and just see if, ignoring C2, the ECC/EDC ever matches on any of the reads of a given sector. I'm curious if, since the error locations vary between rips on the Plextor, maybe the Plextor could narrow down the "true" error location this way after enough reading passes. I haven't actually tried to put this program together at all yet, though, but I think it should theoretically be possible with a mix of various descrambling / ECC/EDC checking code that's available out there (even without me knowing all the technical details about the checksums or scrambling).

Actually, such a feature might be useful in general. I've had multiple rips in the past where the Plextor didn't report any C2 errors when reading via 0xd8, but it had not correctly read data on 3-4 sectors. If ECC/EDC was checked while ripping, it would be possible to re-read not just based on C2 information, but also based on whether the sector appears to be in error. I think this should be possible, right? I haven't really started looking into it, but I don't think I'm talking crazy with an idea like this. But I remember there was one disc in particular where my PX-760 always had 3 error sectors despite no C2 errors, and I finally used my old beaten up (barely working) PX-716 and it reported C2 errors in those locations and the sectors worked on re-reads.

Edit: I managed to find some details about the European version elsewhere on the internet. It looks like probably the errors are in the same location on the US copy. For example, on my copy, my Optiarc has errors at 2461, 2462, and 2463. The European copy has one error at 2462. My Optiarc has errors at 8741, 8742, and 8743. The European copy has one error at 8742.

I wonder if this all has something to do with Sarami's observation that there appears to actually be valid data in some of sectors that are marked bad and replaced with 0x55. I didn't see anything obvious glancing through the descrambled data from my disc, but he noticed that one CodeLock disc has a line from Jabberwocky when you unscramble the data. Thus, some of these sectors might actually have data in them, but they may be corrupted in various ways so they appear to be invalid.

19 (edited by scsi_wuzzy 2020-07-27 18:37:48)

I've started writing some code to play around with this disc using my Plextor. On a "good" sector, I see an offset of 72 bytes from the start of the data stream to the sync pattern (reading via 0xd8 on my Premium).

However, if I read one of the bad sectors (or at least, one of the sectors the Plextor can't read but is *probably* actually a good sector), the sync pattern is suddenly at the wrong offset. For example, for sector number 2314, the sync shows up offset 1560 bytes from the start of the data stream, instead of 72 bytes. Interestingly, if I manually move the sync to the correct place, descramble the sector, and check the ECC/EDC, I get what appears to be a valid sector (ECC/EDC match) with an address of 00:32:64 (2314). So, the Plextor *can* read sector 2314, but it's somehow lost tracking when it reads it, so the sector data is in a different location within the stream. Note that this isn't a particularly amazing achievement -- the Optiarc and TSST drives were able to read that sector without all the fuss. But, this implies that it's sometimes possible to read sectors by manually adjusting the offset in software when the hardware seems to somehow lose tracking, so that's a pretty neat trick I didn't know was possible.

Is it possible the Plextor can read all the other sectors the same way? Probably not, but I'm going to keep playing with it to see what I find out.

I was doing some tidying and found this Tropico disc from when I'd set it aside a year ago. I've done some additional experiments expanding on what I mentioned in my last post, and I think I know a way to identify where the bad sectors are using a Plextor drive. I'll have to play around some more to see if we can actually read the good sectors this way, though.

First, a little background. I never bothered to get a European copy of Tropico in order to test my setup. I'll probably look into it now that I'm looking into this again. However, I did find (via Internet Archive) an image of the European disc that matches the CodeLock version in the database (CRC-32 of 72AAB3E6). That image has 758 errors. The best I've been able to get dumping this American disc is 1516 errors, or exactly twice the number of errors in the European release. I've lost track of exactly which drives I've tried to read this disc, but it's at least 12+ drives across 3-4 different computers at this point. The best performer is an HP-badged TS-H653 drive -- that's the drive that gave the image with 1516 errors. I've also tried an Optiarc, various LG / Hitachi-LG, at least one TSST, a LiteOn, various Plextors, a Pioneer, etc. I can get the model numbers for most of the drives if anyone wants to know.

Anyway, the fact that the European image has exactly half as many errors as my image leads me to believe that, probably, the actual number of errors on the American disc is the same as the European version. In fact, loading up the European image in CDMage shows me that its first few errors are at sectors 2462, 2472, 2482, and 2507. In contrast, my image's first errors are 2461, 2462, 2471, 2472, 2481, 2482, 2506, 2507. Thus, both images have errors at 2462, 2472, 2482, and 2507, but my image also has errors on the preceding sector for each of those. Sure, it's possible that the US release has errors in groups of two, but that just doesn't sit right with me. It seems like it should be single errors.

But, if they are single errors, where are they? Is the error in sector 2461 or 2462? After all, there's no reason the error couldn't have moved from 2462 on the European release to 2461 on the American release. So, how can we get any insight into whether the error is at 2461 or 2462?

Well, here's what I found out. If we convert CDMage's sector numbers to sector numbers compatible with the px_d8 utility (i.e., subtract 150 from the CDMage sector numbers because px_d8 maps MSF 00:02:00 to sector number 0 instead of 150), we see some interesting results.

For example, here's what happens if we try to read sector 2311 via px_d8 (equivalent to 2461 in CDMage):

.\px_d8.exe j 2311
Sector: 2311
MSF: 00:32:61
Combined offset: +72 bytes / +18 samples

Interestingly, the Plextor can read that sector (or, more specifically, it sees that it exists -- it actually can't read it, at least not via CloneCD), so it doesn't seem like there's an error there. What about 2312 (equivalent to 2462 in CDMage):

.\px_d8.exe j 2312
Error searching for sync!

That sector definitely seems to be in error -- not even a sync. How about 2313?

.\px_d8.exe j 2313
Sector: 2313
MSF: 00:32:64
Combined offset: +1416 bytes / +354 samples.

The Plextor at least finds the sync for sectors 2313, but notice that all the sudden the offset is completely different. I think for every sector that's not adjacent to a bad sector, the offset is 18 samples on the Premium. For sectors that are adjacent to errors, though, the offset goes crazy. But, the sync is there, so that seems to imply that the error should be just at 2462, like in the European image.

I haven't checked every single sector, but we see a similar pattern everywhere I've looked. For example, here's trying to read the last error and its neighbors:

.\px_d8.exe j 10015
Sector: 10015
MSF: 02:15:40
Combined offset: +72 bytes / +18 samples
.\px_d8.exe j 10016
Sector: 10016
MSF: 02:15:41
Combined offset: +72 bytes / +18 samples
.\px_d8.exe j 10017
Error searching for sync!
.\px_d8.exe j 10018
Sector: 10018
MSF: 02:15:44
Combined offset: +1512 bytes / +378 samples
.\px_d8.exe j 10019
Sector: 10019
MSF: 02:15:44
Combined offset: +1512 bytes / +378 samples

So, it looks like the last error should be at CDMage sector number 10167. In fact, that's where the last error is in the European image.

Anyway, long story short, I'm pretty sure that the American release is supposed to have exactly 758 errors in the exact same places as the European release that's already in the database. However, I've yet to find a drive capable of reading this disc with only 758 error sectors (despite having tried a ton of drives on various computers).

21 (edited by Jackal 2021-09-22 07:37:46)

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.

http://redump.org/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. http://forum.redump.org/post/54050/#p54050
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. http://forum.redump.org/post/54050/#p54050
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 http://redump.org/disc/31708/ is 722

25 (edited by Jackal 2021-09-22 18:46:28)

sarami wrote:

Logs. https://www.mediafire.com/file/js0a6rkd … 29.7z/file
C2 errors: 1445. vs your dump http://redump.org/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.