Search options (Page 2 of 4)

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.

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.

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.

Thank you very much!

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.

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

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