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?

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?

reentrant wrote:

I have few discs which have misaligned audio data. You see it because Plextor with help of D8 command can detect data offset within disc (remember that all cds are just audio with "pasted" data + ecc on top of it) and it properly aligns audio data following data track.

For non Plextor drives depending on read offset you might see it or not. Drives with bigger / smaller read offets can mask it so you won't see it.

Anyway looks like "mastering issue"...

Thanks, I kinda suspected something along those lines. I ended up comparing the audio by concatenating all the raw files from CUERipper and offsetting it to where the audio is located in the .img file. That made the track offset problem disappear.

It turned out the audio matched except for a couple bits at the very end, and I suspect that's a drive offset issue (probably one of the drives dropped off the last few samples due to the sample offset). So, looks like it's a good dump.

The disc itself definitely seems like it's not the highest quality master. The mastering ring doesn't have anything except the text "IFPI.CO-02" -- strangest ring I've seen.

I'm doing some troubleshooting on a disc that for some reason is nearly unreadable on all my Plextor drives (despite it being in what appears to be perfectly fine condition). It dumps just fine with Alcohol on my LG drives, but the PX-760A and both the PX-716AL drives just rattle and can't read it. The Premium can read it, but it struggles a lot and often crashes DIC.

The disc is a copy of the PC game "Rollcage." I found it second hand ages ago, and I don't even know what region it is. It indicates on the disc that it's in English, so it's probably not a North American release (most of my CDs are), but it also doesn't seem to match the Europe copies in the database. It has 9 tracks like the ASUS OEM release, and the data track matches, but none of the audio tracks match and the mastering ring / serial is different.

I was finally able to get a dump from the Premium. Since it struggled severely, I wanted to be paranoid and check the dumped audio against what the LG dumped using CUERipper. So, I converted the first audio track from CUERipper to raw signed 16 bit audio (via ffmpeg), and I opened up both the DIC bin output of the first audio track and my converted file in HxD. Based on the leading zeroes in both files (as seen in HxD), I used the hex editor to manually adjust the offset in the CUERipper track to match the DIC one. I also truncated the CUERipper track to the length of the track output by DIC (the lengths of the tracks were different both before and after padding to correct the offset). After that, the files matched (compared with fc.exe).

Cool, looks like probably the first audio track was dumped correctly despite the Plextor's struggles. So I move on to the second, expecting to go through the same set of steps. However, when I load up the second audio track from DIC in HxD, there's obviously samples from the first audio track at the beginning of the second one, before the 2 second silence. Importing the raw audio in Audacity shows that, indeed, there's a very short click of audio on the track before the 2 second silence. The CUERipper files don't seem to have any of this overlap (but it looks like there's instead overlap of the pregap).

I expected the offsets to be different between CUERipper and DIC (though, honestly, I'm not sure why except I gather it has something to do with offsetting the audio relative to the data track, whereas CUERipper is just concerned with offsetting the audio samples so that it matches other drives when dumping audio data). However, I didn't expect to find samples from the end of the previous audio track at the beginning of the next. Is this normal? Is it something I need to investigate further, or is it maybe just a common mastering error where some number of samples are misaligned?

Forgive me if this is an extremely obvious question to the more experienced rippers, but I've been dumping PC games and relatively few of them have been "enhanced" CDs, so I haven't looked into it previously. I may try to follow the old dumping guide to see if I get the same results as DIC (http://wiki.redump.org/index.php?title= … acks_(Old)), but all the images in the guide are dead so some of it isn't entirely clear to me.

This actually helped me out when I was curious about the second-hand Plextor I got a while back. I didn't know QPxTool had this information. FYI, it looks like the "discs loaded" counter stops at 100,000. Either that or it was just coincidentally the 100,000 disc, but I doubt it.

Is there any rule of thumb for how many hours the OPU should last? I think the drive is at only about 500 hours of reading or so, IIRC (don't have it in front of me right now), despite having been fed so many discs.

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!

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.

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.

Nextria wrote:


If you can open up Your 716, and look at the laser head. There should be a part number.
Maybe it’s the same as for the 708.

Unfortunately, it's not. Nobody seems to even know with certainty who made the laser for the 716. The part number is SRU 3541. There's a brief discussion about it on Myce https://club.myce.com/t/replacement-for … a/314376/8, and the basically the verdict at that time was that if your 716 needs a laser, throw it in the trash or keep in the closet in hopes somebody, someday, finds a source for them.

I've been avoiding 716 units ever since I learned that, as even if they have some advantages, I'd rather have units that have parts available. They're apparently also quite fragile -- lots of complaints online about how short the life of the 716 is. It was apparently even an issue back when they were new -- one person on Myce or somewhere else went through multiple warranty replacements on his new unit, as the lasers kept dying. That could be an outlier case, of course, but it seems like they're pretty unreliable.

wiggy2k wrote:

I finally got around to testing my pile of plextors. (like ~25 drives) the other day.

by far the biggest failure rate was from the PX-708A and PX-716A drives that i had piled up.
100% failure from the PX-708A   (1/1 drives faulty)
50% failure rate from the PX-716A (3 of 6 were completely knackered)

but then again the one PX-716UF I have has been a really stable drive.

I'm, unfortunately, not surprised. I wasn't familiar with the durability issues of the 700-series drives until I purchased my troubled PX-716AL drives, but it's apparently a somewhat known issue. I noticed that someone added a warning to the Redump Wiki about these drives:

The Plextors in the 700 range that can read DVDs have firmware bugs and the lasers can go bad easily.

It's a shame, because the 716 was quite well received in its day, AFAIK. Even now, my barely working 716AL sometimes has more accurate C2 reporting than the 760 I use as my main ripper. I had multiple discs recently that exhibited no C2 errors but had defective sectors from the 760. The 716 reported C2 errors on the same sectors and successfully re-read. But, I think replacement lasers for the 755/760 are widely available, while nobody seems to be able to source one for the 716.

I've on-and-off thought for some time about the possibility of modifying firmwares to enable scrambled reads on other models of drives.

It seems like it should be possible in theory, as a number of drives don't have any kind of firmware signature and can seemingly be freely modified (e.g., all the RPC-1 hacks, riplock removal hacks, etc. for a bunch of TSST and other MediaTek drives). Hell, there might be some firmware out there in some drive that has the scramble table easily accessible in the firmware, in which case it might be possible to just zero out the table and have a drive that can only do scrambled reads.

I'm curious if anyone is looking into this / has looked into this in the past? I've been going through a lot of Plextor drives, so I'm mostly wondering aloud if anyone feels like an alternative might one day exist. It's neat that some newer drives (like the BW-16D1HT) can do scrambled reads, but it seems as though they still pale in comparison compared to the Plextor drives (issues finding offset, etc.).

Nextria wrote:


I know you looking for a fix in the UK, but for the PX-708(UF) i bought
a new laser aliexpress https://nl.aliexpress.com/item/32964380 … 4c4dT8bKnV

I can confirm they working great, i bought my 708 and it came with a dead laser,
Replaced it and it is working great again!

for 10 euro you can not go wrong.

Does anyone know if a replacement laser / OPU is available for the 716 anywhere? I recall a thread on MyCE some years back where several were lamenting being unable to find 716 parts, but I haven't kept up to see if anything has changed in recent times. I've two 716AL that are working except the OPU seems to be nearly dead and (more and more frequently) they decide they'd rather just not read anymore.

Also, what the hell happened to Plextor with the 700 series drives? It seems like my Ultraplex 40 will last until the end of days, but it seems like I'm going to have a bin of dead 716 and 760 drives by the time I'm done with my dumping.


(1 replies, posted in Guests & account requests)

I'm requesting a Wiki account. I'm submitting games from the "Undumped Games" lists, and I'd like to be able to remove them as I go.

Thanks. Let me know if you need anything else.

F1ReB4LL wrote:

It is different, hence the "R" (reprint/revised/whatever).

wiggy2k wrote:

they might have actually fixed the issue with cold booting the console with BUG! in the drive.

I've compared both images before and, IIRC, the only thing that was fixed is the serial number in the header (GM-81004 was fixed to MK-81004). But it's still quite an interesting change to be preserved smile

Yeah, I converted both versions into 2048 sector images, and a binary compare indicates only two bytes different, and it is in fact a G changing to an M and a M changing to a K. Just as you remembered.

In any case, I'll hopefully get a change to submit it later in the week.

iR0b0t wrote:

It is supposed to make 5 loops and will finish reading at some point for sure.

F1ReB4LL wrote:

It reads the disc subs 5 times, then combines the results and tries to reread the damaged sectors. You can open the logfile with Far Manager or similar and watch the process in real time.

Thanks for the responses! Sure enough, I was just impatient. It stopped after 5 passes.

On another note, it looks like the SATURN81004R version of Bug! is actually different from the variant in the database. Track 1 is same size, but CRC differs. Track 2 and many others are a different size. However, build date and version number match http://redump.org/disc/20332/ I'm gonna do some additional checking before I submit, though, so I don't make an ass of myself.

I've got a couple of the undumped NA discs that I want to dump (Bug! with the SATURN81004R ring code, Gridrunner, etc.)

So far I've tried dumping two discs, both in what appears to be good condition. While DIC reports "No C2 errors" for both, DICUI launches subdump.exe after DIC, and subdump.exe seems to run forever, dumping the subs over and over again. I end up with a number of "[title]_subdump_1.sub", "[title]_subdump_2.sub", "[title]_subdump_3.sub", etc files all the same size (but not with matching hashes).

Is this normal? Looking at the log, it looks like subdump is convinced there are some reading errors, and it's re-reading over and over. But, like I said, these discs are in quite good condition, and DIC reports no C2 errors, so I find this a bit odd.

Drive: PX-760A
Subdump Log (for Bug!): https://www.dropbox.com/s/o7nftgipf184j … p.log?dl=0
Other logs (for Bug!): https://www.dropbox.com/s/6ojbd8b42ijtiqj/BUG.7z?dl=0

Subdump was actually still running when I copied its log file.

Sorry for the triple post, but it appears to have been a bug with DIC. I copied the new DIC executable over top of the version included in DICUI, and the hash for disc 1 now matches what's in the DB.

Now I gotta go see what else I need to redump.

Edit: If anyone wants to see the logs for the new dumps and compare with the old, let me know. I can upload them.

Landcross wrote:

A few days ago I had some problems with SecuROM and my Plextor 760A. Jackal posted about it here: http://forum.redump.org/post/62811/#p62811

I don't know very much about this stuff, but maybe it was the same problem as you have. The issue has been fixed (at least in my case) in the newest DIC. Try updating DIC to the newest version and see if that fixes the issue. The newest version can be downloaded here: https://github.com/saramibreak/DiscImag … g/20180828

If you're already on that version, than you need someone with actual knowledge about this stuff, not me wink

Thanks for the heads up. I'll drop in the new DIC into the DICIUI folder. Hopefully I don't have to go back and redump a bunch of stuff.

Edit: Apparently dropping in the newest CSS / DiscImageCreator / EDCECC causes DICUI to now crash after the dump, when it's collecting data for the submissioninfo file. Interesting.

Edit2: Looks like the crash is probably unrelated to the change in DIC. I think DICUI just crashes with that disc. Just installed VS Community to troubleshoot.

user7 wrote:

Can you post your logs for the example you referred to: http://redump.org/disc/12832/

I've compressed everything from the dump except the actual data. I was just going to post on Pastebin or similar, but some logs (like the EdcEcc output) are huge. https://www.dropbox.com/s/578x418z8712h … _1.7z?dl=0

reentrant wrote:

ECC checker should not replace sectors for such discs with 0x55. For most cases it's just different mode sector perfectly readable by optical drive. Are you sure the differences stem from that single sector near the end of the disc?

It's possible I was getting some parts of SafeDisc and SecuROM confused in my discussion. However, there are in fact sectors getting replaced with 0x55 in this dump. I dumped it again, and the hashes for both the raw scrambled data and descrambled data matched. Initially I thought maybe that, if there are read errors (though I would expect C2 errors if that was the case, and there aren't any), maybe the hashes were just matching because the error sectors were being replaced with identical data between reads. However, since the raw scrambled data matches, I believe this means that the reads are consistent.

The disc looks good, in terms of condition. I'm wondering if there are some weird mastering/manufacturing errors, perhaps.

I've been going through and dumping all my PC games, and I've noticed that a number of SecuROM protected discs don't end up with hashes matching the ones in the database. For multi-disc games, this often only happens for the SecuROM protected discs. For example, I just dumped Aliens Versus Predator 2, and my Disc 1 (which has SecuROM) has a matching size but not a matching hash when compared with http://redump.org/disc/12832/. Disc 2 (which doesn't have SecuROM) has a matching size and hash. While it's certainly possible it's just a pressing difference (my Disc 1 is manufactured by TECHNICOLOR just like the one in the database, and has the same IFPI number, but some parts of the mastering ring differ), I've seen this with several discs so I wanted to inquire. I know that the current DICUI releases run the ECC checker and it replaces the bad sectors (SecuROM sectors) with dummy data. Is it possible that some entries predate this dummy data replacement, or that maybe some other dummy data was used? Or is this definitely a pressing difference?

My setup: Dumping with DICUI and a Plextor PX-760A. I've tried redumping discs that don't match, and I've always gotten identical hashes between the two dumps. No unintentional C2 errors reported by the drive. When checking hashes, I'm using the "!submissioninfo" file generated by DICUI. I've also hashed with 7-ZIP and got the same thing.

Edit: I think this was a bug with DIC. I updated to the newest release and got a matching hash.