26

(6 replies, posted in General discussion)

EmuGuru wrote:

That is what I gathered as well, it appears from pics on eBay that it’s just the internal inside a usb enclosure. I thought maybe the usb controller inside it may produce better results than say the ugreen or kingwin but I’ve not come across anything talking about that yet. Thanks so much for the reply.

I recall seeing a post from some years back over on MyCE where someone stated that Plextors are fussy about external cases / USB to PATA adapters. That's not been my experience, though. Despite the Redump Wiki recommending otherwise, I've just been using whatever cheap no-name USB to PATA / SATA adapters I had laying around when I started dumping, and the Plextors have been fine with it. I've even able to use Plextools to control drive settings when the drives are connected via these cheap adapters. That being said, if I was buying an adapter today instead of just using what I happen to have on hand, I'd go with a Ugreen or Kingwin or similar, as going that route probably minimizes the chance of issues compared to the generic ones I ended up using. (Especially since, IIRC, there used to be warning in the Wiki stating that some of the crappy generic adapters may brick drives. I didn't see that warning until after I'd been using my cheap adapters for a year already, or I probably would've ordered some nicer adapters when I was starting off. At that point, I just stuck with my crappy adapters, because I kinda figured if they were gonna brick the drives it woulda happened by then.)

Not directly related here, but I have had issues with some SATA to USB adapters in the past. I had an issue with a drive would work fine for reading via my generic SATA to USB adapter, but, if trying to burn a disc, the adapter would stop communicating with the drive in the middle of the burn until I unplugged and replugged the adapter. A nicer adapter solved that problem. In any case, that was with a newer LG drive and not a Plextor.

27

(6 replies, posted in General discussion)

I don't know for sure with those specific models, but I would guess that there's not really any tangible difference. My experience with the behavior of other Plextor drives makes me think that the U model is probably just the internal drive inside of a USB enclosure.

For example, I have a Plextor Premium internal drive. However, I only use it as an external drive over USB, as it's connected to a machine with no PATA ports. When I run Plextools Professional XL, it identifies the drive as a Premium-U (despite the label on the drive showing the model as just a regular Premium).

My European copy of Tropico arrived today. I was able to use DIC to dump the disc with my BW-16D1HT (F/W 3.10) and match the European release in the database.

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.

It turns out there's a note about the H353B in the Wiki. It's considered more trouble than it's worth. After acquiring one, I have to agree. I was able to get a few sections dumped, but it was taking an eternity and I'm not convinced the other sections were ever going to work. Anyway, I bought that model partly because it can also be flashed over to Kreon, so that drive is happily dumping Xbox discs now.


matura713 wrote:

I don't where you located, but I bought on Ebay "SH-D162C" recently for a buck. I've just checked and there is one more auction that ends in an hour - again for a buck. So, the trick is not to search for "SH-D162C", but for "SH-D162" and look the label on the pictures, that it's "Revision C".

That's good advice leaving off the last character. Unfortunately for me, it looks like the SH-D162 version must not have been common in North America -- most results are way overpriced (including shipping) to get them to the States. I'm eyeballing a SH-T352C, but they still hover around $20 (including shipping). Not an extremely expensive drive by any means, but that seems like plenty for an otherwise unremarkable DVD-ROM drive from over 10 years ago.

matura713 wrote:

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.

sarami wrote:

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?

32

(4 replies, posted in General discussion)

sarami wrote:

Sorry, I uploaded the original that the author uploaded.
0.4a: https://www.mediafire.com/file/aml5562a … 9.zip/file
0.42a: https://www.mediafire.com/file/f663844k … 9.zip/file

Thank you very much!

33

(4 replies, posted in General discussion)

I feel I'm missing something. I downloaded the DCdumper_(0.42a).7z, but I don't see any source code there.

From reading the old forum, I see that some archives of the binary also include a src folder, but I'm not seeing it in that archive.

34

(4 replies, posted in General discussion)

Does anyone still have a copy of the source code for DCDumper? I know the binary is available via both a link in the Wiki and a link in the original forum post (at http://forum.redump.org/topic/9436/new- … st-please/), but neither of those includes the source. The download from the Wiki includes a link to a Github repository that at first glance might appear to be the source, but that repository is actually the source of a completely different Python program also called DCDumper.

Regarding the failure of the Plextor drives, as someone who was far too frugal to purchase a Plextor during their heyday (and my CD burning days), I always felt like maybe I was missing something. I had my cheap LiteOn or AOpen drive (or whatever drive I found cheap at a local retailer), and there were legends about the great Plextors that cost however many times what I was paying for my drives.

Having since acquired some Plextor equipment, I feel like it's...not that great. At first, I thought it was just because of the age. For example, I splurged and bought a used Premium some time back. The Premium is absolutely awful at reading damaged data discs. I thought it was just because it's 15+ years old. However, I went back and looked at the review of the Premium on cdrinfo.pl. They reviewed it back in 2003 and found it was among the worst of all the drives they tested for reading damaged data discs. (It was essentially tied with another Plextor drive, the PX-W4824A, for last place.)

On the flip side, the same review acknowledges the Plextor as a good audio reader. In fact, the review claims that the Premium can read CDS200-protected discs. However, I'm not sure they actually test such a disc in the review. I didn't go through the whole thing (and I'm reading it through a machine translator, so some details are iffy in any case), though.

Then there's the fact that it's nearly impossible to find a fully working Plextor DVD drive, which I also attributed to age. However, from reading about that, it sounds like PX-716s were dropping dead shortly after they were made too.

Anyway, my apologies that this rant isn't directly on topic, but I've been dealing with some damaged data discs (actual scratches -- not manufactured errors), and I was amazed to see how much better almost every drive I own is at reading damaged discs compared to the Premium. I'm still happy with the drive just to have another drive for dumping with DIC, though. And, I guess Plextors were really famous for their writing quality more than their reading prowess, so maybe in some ways my frustrations aren't fair.

More on topic, I think I might hunt around some at a local shop and see if I can spot any CDS discs. If I end up with one, I'll add my experiences here in trying to rip it.

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.

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

matura713 wrote:

just to add another not working drive to the list:

* LiteOn DH-20A3P

After seeing what a struggle CDS can be, I kinda wish I had some CDS protected discs to do my own experiments on. However, I've almost completed ripping my audio CD collection, and I haven't found one yet. Most of my discs are North American releases, and I think that's why I've unwittingly avoided CDS. From reading about it, it sounds like it was more common in Europe compared to the Americas or Asia.

Do you know if there's a comprehensive list of CDS discs anywhere? MusicBrainz has about a handful of discs tagged as "Cactus Data Shield" (~8 discs), but there are obviously many more than that. That was the most extensive list I found in my searches so far, though.

I can't speak to the compatibility for crossflashing those specific drives, but I have previously crossflashed a Creative branded drive (which was actually just a rebadged Plextor) with the Plextor firmware.

It's been some years since I did it, but I'm pretty sure all I did to crossflash was just (1) locate the drive model string in the Plextor flasher, and (2) hex edit that string to contain the model of the Creative drive instead.

I don't have that drive hooked up anymore, but I think I remember it still identifying itself as the Creative model, but I think it was running the Plextor firmware? I don't recall if / how I was able to verify that, as it's been years since I've played with that drive. It was an old 12x CD-RW. I crossflashed it back when I first started dumping, hoping that maybe the Plextor firmware had lead-in / lead-out dumping ability that the Creative firmware didn't. I never could get it to do lead-in / lead-out, so I gave up on that drive.

You might try asking over on Myce or CDRinfo.pl. Must of CDRinfo is in Polish (which I don't speak), but there's absolute tons of great info on there to be found using a machine translator. In a brief search, I did see that people had done work on renaming Plextor drives. Apparently it's possible to rename my old Creative into a Plextor. Maybe I should take a look...

matura713 wrote:

@scsi_wuzzy
So, using things like CUERipper/CUETools is not an option, because the whole goal is to have 100% rip, not approximations.

I assume by 100% rip you're referring to having a "proper" DIC image of the disc as opposed to just audio tracks, and I definitely agree that it would be preferable to have a proper DIC image of the disc for archival. But, just in case I was unclear in what I said about CUETools, I want to say that, when CUETools corrects an audio disc, it makes the audio samples on the disc bit-for-bit identical to a existing rip of that disc. It's not like with record albums where there's software that just tries to find pops and clicks based on audio signature and mindlessly smooth them out. The database used by CUETools (CTDB) is, in part, a big database of data parity information that can be used to correct rips such that they match other known rips of the same disc. Essentially, you can go from a bad rip to a perfect one by correcting the bad audio samples in your rip to match an existing exact rip that someone else made of the disc. It doesn't simply clean up the audio to mask any audio artifacts that might be present -- it makes the audio samples match another known (presumably good) rip.

But, yes, it's definitely not as "archival" as getting a proper rip with DIC -- especially since it doesn't archive the data session. (Though CUERipper might record the existence of the data session in the CUE sheet -- I can't recall.) Fortunately, I don't think any of my audio discs have this protection. In fact, very few of my audio discs have any data tracks present at all, so I've mostly just been using CUERipper for audio discs (so I can use AccurateRip / CTDB to verify my rips) and DIC for anything that has data.

On another note, I kind of wish we had a parity database for the Redump rips. I have some discs I've acquired over the years that have a few bad sectors. I could have perfect rips of those discs with probably just a few KB of parity data...

I agree that BW-16D1HT is a very useful drive. I've found it has much better ability to read damaged discs compared to some of the Plextors. Just recently, I was going to do a comparison in dumping a zero offset disc between my Plextor Premium and my LG WH14NS40 (cross flashed over to BW-16D1HT). Unfortunately, there are several sectors that the Premium can't read (i.e., have ECC/EDC errors) even after several hundred retries. In contrast, the BW-16D1HT doesn't even report any C2 errors, and the ECC/EDC match after the first try.

I hope for that reason alone we can get all the kinks worked out with the ASUS / LG drives. They seem to be better readers. That might just be because they're less aged and worn, but I suspect it's also just because they're newer technology.

I have had a similar experience with dumping a PC disc on the PX-760A in the past. Unfortunately, I can't recall the game, but I had a disc that would report no C2 errors when dumped on the 760A, but it had 2-3 ECC/EDC errors when checking sectors after the rip was done. I later used a PX-716A to dump the same disc, and it was free of ECC/EDC errors (and, IIRC, it reported C2 errors in the spot where the ECC/EDC errors were present in the 760 dump, but DIC re-read successfully).

I think the C2 reporting on the PX-760A must have some limitations, and I wonder if there are certain data patterns that are problematic. I think it would be nice if DIC had an option to re-read in cases where there's no evidence the sector is protected (e.g., not part of a protected file and no 312 bit C2 errors or similar) but the ECC/EDC data doesn't match, because there are definitely instances where the 760 (and maybe other models of Plextor drives) will claim no C2 errors but still have errors. And, it's not just a "rip it again and it'll work" situation, either. I ripped that disc probably 4-5 times with the 760A, and it never had C2 errors, but it always had ECC/EDC errors. In contrast, the 716A reported C2 errors in the same spot (IIRC) and successfully re-read.

I guess this is kind of in-line with opinions on the 716 vs 760. Lots of people from back when the 760 came out claimed the 716 was a much better drive than the 760. However, it seems like the 716 drives have reliability problems. The 716 I used to dump the disc that the 760 failed to dump only works when it's feeling up to it. The rest of the time, it just goes into some kinda laser focusing frenzy and rattles the laser lens up and down like it's dancing. It happened to work fine to dump that disc, though.

I want to bother to dump all my GD-ROMs. I don't think I have anything that's undumped, but, just as a exercise, I figured I might as well give it a shot. As it turns out, I don't currently have a drive that works to dump GD-ROM discs, though. I spent a good part of the day today taking drives apart to do the swap trick, and none of them seemed to work.

So, the next step is to track down a drive that does work to dump GD-ROMs. One drive that I'm seeing a lot of availability for on the second-hand market is the TS-H353. However, most TS-H353 drives I'm seeing are not the TS-H353A that's in the compatibility list, but instead the TS-H353B or TS-H353C models. Has anyone verified if the B or C versions do or do not work for GD-ROM dumping? Also, does anyone know if it might be possible to cross-flash a B or C to the firmware of an A and do GD-ROM dumping then? I'm unable to find any details online about if the hardware is different between these models. I'm wondering if they're just all versions of the same drive with slightly different firmwares depending on what the OEM asked for...

I wasn't familiar with this protection until I saw this thread, and I'm a bit intrigued now.

Have you tried ripping the audio tracks in CUERipper and then repairing the rip with CUETools? Assuming the disc is present the the CTDB that CUERipper / CUETools uses, you can correct your rip if it's "close enough" (i.e., there aren't too many audio samples that are corrupted). I've not dealt with this protection before, as I said, but I've been able to rip some really terrible condition discs that were close enough to be corrected with CUETools. If the disc doesn't return consistent results on re-reads, though, you'll probably find that CUERipper takes a long time. If the results are consistent but the drive reports C2 errors, I'm honestly not sure how CUERipper handles that. Might be interesting to find out?

It should also be possible to repair audio tracks ripped with DIC in CUETools IIRC, but it's not very straightforward. CUETools doesn't deal with raw CDDA, so you have to use something like ffmpeg to go from the raw audio to WAV or FLAC.

This doesn't really help in terms of finding a drive to image the data, though, and instead more relies on other people having been able to image the disc in the past. In any case, though, it's saved my ass many times when I had an audio disc with a defect or damage.

One other thought -- have you tried using Plextools Professional XL to rip the audio? It has some options like hiding the second session on the disc. I wonder if that allows reading the last track on one of the Plextor drives? I think the only reputable place to get Plextools Professional XL these days is via the Internet Archive's mirror of the Plextor files: https://web.archive.org/web/20101219101 … w.download

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.

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.

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.

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.

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.

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?