Consequently, I don't believe there're any issues with my setup. I believe this US release is just a lot trickier to dump compared to the EU release. After trying however many drives I've tried, I'm reasonably confident that probably no drive will have fewer than 1516 errors when reading the US disc. That's the best I've seen from any drive, and that's exactly two errors for each location where there EU release has a single error. I've only found one drive capable of reading the disc with that few of errors -- most drives have 3+ (and often 5 or more) errors at each location.

Edit: Also, using CloneCD, my Optiarc 7290H5 and hp TS-H653R, two drives that I previously tried to dump the US disc with, are both able to create dumps of the EU disc that match the one in the database.

Also, that note is my "ASUS_ODD_FW_Changer_(Modified) (24.08.2019)" and so that tool was used. I think "MK" comes from Mike the guy that make 3.10 downgrade firmware and "DE" is stands for Downgrade-Enabler or something like that...So, yeah, it seems the files in my other note match perfectly this one.

There's also the flashing tool that comes with MakeMKV as well. I've only used it for a couple of tasks, but it's worked well. Okay, I actually was lazy and used the GUI tool (sdftool_flasher). In any case, it's worked well for me. I haven't tried flashing an ASUS firmware with it, though, but I'm thinking I might upgrade my ripper to 3.10 just for the hell of it.

Edit: Just upgraded to 3.10 MK via sftool_flasher. Looks like it went fine -- even with me being too lazy to take it out of the USB enclosure it's in.

Edit2: My Tropico disc still has an absolute ton of C2 errors around the region in question, so I don't think this is something that is just a difference between 3.02 and 3.10 firmware versions. Hopefully it won't be too long before my Tropico disc arrives and I can test my setup.

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?

Rune and Tropico is a negative offset disc. BW-16D1HT (FW 3.10) can dump it.

========== Offset (Drive offset referes to http://www.accuraterip.com) ==========
     Combined Offset(Byte)    -24, (Samples)    -6
    -   Drive Offset(Byte)     24, (Samples)     6
    ----------------------------------------------
           CD Offset(Byte)    -48, (Samples)   -12
    Overread sector: -1

FW 3.02 uses to dump a positive offset disc. (Of course, it's also able to use for a negative offset.)

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

I don't know, if you know, but it's now possible to go from 3.02 to 3.10 and back safely - before it was very hard (and risky) to downgrade as the downgrade is not allowed with those drives, because of their UHD/BD support - it requires manual patching of the firmware and easy to brick the drive. So, the new way for downgrade is a lot like PS3 downgrade, if you're familiar with PS3 HFW (Hybrid Firmware) downgrade procedure. It has additional advantage that contrary to the previous methods, this one keeps the individual calibration data of your particular drive - it's done entirely in software. So, from your 3.02 you can update to 3.10, then to go back, you need to flash it to another firmware 3.10DE, i.e. 3.10 Downgrade-Enabled firmware and then flash it to 3.02. I can give you better details, but I did it over few months ago and I am searching for my notes - I recall write down small txt file for myself...

[EDIT] I cannot find the notes I had in mind, but found another notes that say:

I am giving those just as clues, maybe there are now newer vesions of the above files and they are no longer the latest.

[EDIT2] I found the note I made to myself 4 months ago, literally it says:

Also, that note is my "ASUS_ODD_FW_Changer_(Modified) (24.08.2019)" and so that tool was used. I think "MK" comes from Mike the guy that make 3.10 downgrade firmware and "DE" is stands for Downgrade-Enabler or something like that...So, yeah, it seems the files in my other note match perfectly this one.

My Tropico matched the db http://redump.org/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?

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

No.

I think so from the viewpoint of data preservation.

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.

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.

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.

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?

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

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

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

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

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:

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