redump.info Forum

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.

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.

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 https://redump.info/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.

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...

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.

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).