Search options (Page 1 of 4)

I was curious about this myself, so I've dumped a game using both my Dreamcast and a TSST drive. I haven't had time to sort out all the details yet, but it looks like the pregap / offsets are not the same. So it's probably mostly a matter of shifting the bytes in the DC rips so that they have the same offset as in the rips from the TSST (and maybe also adding zero padding since, IIRC, the DC can't read some of the gaps).

I may put together some notes if I ever have time to go through it in detail.

I think for data only discs the DC rips should match the TSST rips, though, since there's no offset / gap issue.

Did the pins actually break or just bend? Some of the IDE to USB adapters have an IDE connector that's narrow, making it possible to accidentally plug in the connector when it's shifted one row to the left or right. The result is that it will bend two pins in one row, either the leftmost or rightmost set of pins on the connector. In that case, though, you typically can bend them back without breaking anything.

I made a post some time back asking for the source. sarami was kind enough to share it. The post is at http://forum.redump.org/topic/40014/sou … -dcdumper/.

As of when I'm posting this, the Mediafire links that sarami posted then are still working.

I looked at doing some improvements, including checking ECC/EDC error as the dump occurs and retrying as necessary (i.e., instead of just doing a check at the end of each section, retry every sector that has any ECC/EDC errors as it's read), but I ultimately found that my particular drive sucked too much to ever make any use of it and gave up.

There's definitely a lot of room for these types of improvements that could making DC dumping a lot easier, though.

I don't know any specific models right off the bat that are generally believed to be great with damaged discs, but you might take a look at cdrinfo.pl. Over the years, they did some pretty extensive tests of how different drives perform on various types of damaged media. Most of the content is in Polish (which I don't speak), but Google Translate does a reasonable job with it. Their benchmarks are how I learned that my Plextor drives that are awful at reading damaged discs are actually probably performing normally... (at https://www.cdrinfo.pl/artykuly/Plextor … rona14.php) And their summary of the BenQ 5224W indicates that they found it to be good at error correction (at least for audio discs -- I believe they're saying it's not good for data, but I couldn't get that chart to load and the translation isn't quite clear) (https://www.cdrinfo.pl/artykuly/Benq-5224W/strona8.php), so that matches up with what you were told.

I can say from my own experiences that, when I have a damaged disc, I have pretty good luck with LG BD-RE drives (like the WH14NS40 or similar). Optiarc and TSST/Samsung DVD+/-RW drives have also done quite well.

You've probably already observed this yourself, but it seems to be the case that drives perform differently depending on the type of damage present on the disc (or maybe even the specific manufacturer of the disc or some other variables?). Some discs my LG BD-RE can read fine, but the TSST/Samsung drives struggle, and for others, the TSST is best, or the Optiarc. Basically, if you're dealing with damaged discs, it seems like the best plan of attack is just to get a bunch of drives and start trying them all. IsoBuster has some functionality that makes this pretty convenient, where you can save an incomplete image (i.e., one where not all sectors could be read) and then try to complete the image using different drives.

It would be nice if we could ultimately end up with CD images like the ones Near described. Near's article about the CD format hypothesizes about a CD format that just stores all the lead-in sectors (including subchannels) so that we could have a single file raw image format that embedded the TOC the same way the real disc does. Such an image format would handle multisession discs easily.

Of course, it'd be really nice if we could hack some model of drive to just give us the CIRC data (or some other low level data from every sector) directly. I guess it would be akin to the Greaseweazle and similar hardware for dumping raw flux from floppy disks.

I didn't mean a delta between unscrambled and scrambled. What I meant is that it's not necessarily guaranteed that a re-scrambled data track will match the original scrambled one read from the disc. Specifically, error sectors in the descrambled image are replaced with dummy data, so, when those sectors are re-scrambled, you won't get the original scrambled data back.

Because of this, I was thinking of using deltas between the original scrambled data and the rescrambled data. For most any unprotected disc, the files will match exactly. For discs with errors, the rescrambled data for error sectors won't match the data returned by the drive, so the delta will just have to store the differences for these sectors.

I was thinking this would be a better solution than just storing both the unscrambled and scrambled data, as it would be much smaller. For many discs, it would basically eliminate the storage of the scrambled data altogether, since you can recreate it. For other discs, it would require just storing a delta large enough to reconstruct those sectors that don't rescramble to the original data, which, for most discs, is only a few hundred sectors at most.

Regarding the TOC concerns, I was thinking maybe something even simpler than that. I don't necessarily care if I know exactly which sectors, according to the TOC, are data or not. I just want to have a compact way to recreate the original scrambled data from the drive while storing the more useful unscrambled image for day-to-day use. I was thinking it should be possible to just go through the unscrambled image looking for the 00 FF ... FF 00 sync pattern at each sector offset and then doing the XOR with the scrambling table for all the sectors found that way. If there's no sync, just write out the sector as-is. Then, after having done that, compare this rescrambled image with the original scrambled image that DIC read in from the drive. If the images matche, nothing new needs to be stored except a note that the scrambled image can be trivially recreated from the unscrambled image, and we can delete the scrambled image. If it doesn't match, make a delta between the rescrambled image and the original scrambled one read in from the drive, and then delete the original one. Then, we can in the future recreate the original by rescrambling the unscrambled image and then applying the delta.

My real hope, though, was that Aaru or some other package would have the option to simultaneously store both unscrambled and scrambled using some kind of internal representation like I've described in order to save space. I don't think such package exists, though.

I've thought about doing it this way and then just storing deltas for when the scrambled data doesn't match exactly (since the deltas would allow creation of the scrambled data from the unscrambled data and would typically be much smaller than the entire scrambled image). That's probably what I'll end up doing, but I also may look into adding metadata to an archival format like Aaru if it's possible.

I wanted to make sure there wasn't a better way to do it using some existing, standardized approach before I came up with my own solution. It sounds like there's not, unfortunately.

It looks like the laser in the PX-712 was used in various drives from NEC (and possibly Lite-On as well). If you've got any other drives kicking around, you might check the PDFs linked from another thread (http://forum.redump.org/topic/42360/hel … -a-px755a/) to see if any of those models have the same / compatible OPU.

Regarding cross-flashing an LG / ASUS drive, I have a couple notes that may or may not be helpful. One, it seems like the cross-flashing process is pretty reliable at this point, assuming you verify that the drive you have has the proper model / SVC code / manufacturing date. The old-style cross-flashing involved flashing from DOS or using a hacked LG / ASUS flasher, but, most recently, I've cross-flashed a couple drives using a frontend to the flasher that comes included with MakeMKV, and I've yet to have any issues with it. It's certainly not without risk, though. If something happens and the drive calibration data gets wiped, you might be out of luck. Two, even a cross-flashed LG / ASUS probably won't be able to dump all the discs the Plextor would be able to if it's made working again. I've been using my BW-16D1HT for most CDs that don't have audio tracks (to avoid wearing out the Plextor), and, every once in a while, I still have to use the Plextor for such discs. The BW-16D1HT has to use a trick to read the lead-out sectors from the drive cache, but certain discs exhibit an issue where the lead-out sector isn't present in the cache, and DiscImageCreator is unable to dump such discs.

So, even if you cross-flash your LG, you may find you need a Plextor for some discs. Thus, even if you opt to cross-flash the LG drive for dumping, I think you'd be wise to be on the lookout for replacement parts / a replacement drive for the Plextor.

Has the SF-DS10 supply dried up? I haven't done a laser on one of these drives, but I recall a thread on MyCE from maybe 5-6 years ago where someone discussed replacing the SF-DS10K OPU with SF-DS10L and SF-DS10N OPUs.

Actually, I guess maybe they were just sourcing those parts from other drives, and not purchasing new OPUs. It looks like the thread is here at https://club.myce.com/t/replacement-for … a/314376/4, and they mention the L and N variants are in various Lite-On, Sanyo, and NEC drives.

I can't recall if this was the same error that my drives threw, but I've had a couple of Xbox discs, in great condition by all appearances, that wouldn't read. I suspect there was some manufacturing error that might have resulted in some discs having a short life. I know that at least one of the discs worked when it was new, but it no longer does. I also noticed that, when I scanned the disc in my flatbed scanner, the scan had lots of tiny little black spots, as if maybe the reflective layer has oxidized in some spots?

I guess that explains why it's only listed as supported on 3.00 and 3.02. In any case, I had only updated to 3.10 as an experiment to see if a protected disc that failed on 3.02 would dump on 3.10. It didn't. So, 3.02 it is.

On a somewhat related note, has anyone done any experiments to see if any of the undumpable discs (due to lead-out issues) are dumpable on 3.00 vs 3.02? I assume it won't have any impact, but I guess it's possible that the cache structure was somehow changed between the two in a way that might have somehow alter when the /mr option fails...

Edit: This got me going on a side project. It looks like the Vinpower variant of of the WH16NS48 firmware (v. 1.D3), a firmware variant that's notable because it adds the ability to do Blu-ray quality scanning on SVC code NS40 LG drives, also supports 0xF1. Once I patched DIC to flag it as an 0xF1 capable model, it worked fine (at least for this test disc):

StartTime: 2021-11-17T17:44:46-0600
CurrentDriveSize
        Total: 255402758144 bytes
         Used:  95840133120 bytes
        --------------------------
        Space: 159562625024 bytes
         => There is enough disk space for dumping
Set the drive speed: 1411KB/sec
This drive doesn't define in driveOffset.txt
Please input drive offset(Samples): 6
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 0]
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 1]
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 2]
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 4]
LBA[297678, 0x48ace]: [F:ReadCDForCheckingReadInOut][L:801]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: be, 04, 00, 04, 8a, ce, 00, 00, 01, f8, 00, 00
dwBufSize: 2352
This drive can't read the lead-out
But 0xF1 opcode is supported
========== Reading 297657 - 297677 INTO CACHE ==========
01 Cache LBA 297657, SubQ Trk 01, AMSF 66:10:57
02 Cache LBA 297658, SubQ Trk 01, AMSF 66:10:58
03 Cache LBA 297659, SubQ Trk 01, AMSF 66:10:59
04 Cache LBA 297660, SubQ Trk 01, AMSF 66:10:60
05 Cache LBA 297661, SubQ Trk 01, AMSF 66:10:61
06 Cache LBA 297662, SubQ Trk 01, AMSF 66:10:62
07 Cache LBA 297663, SubQ Trk 01, AMSF 66:10:63
08 Cache LBA 297664, SubQ Trk 01, AMSF 66:10:64
09 Cache LBA 297665, SubQ Trk 01, AMSF 66:10:65
10 Cache LBA 297666, SubQ Trk 01, AMSF 66:10:66
11 Cache LBA 297667, SubQ Trk 01, AMSF 66:10:67
12 Cache LBA 297668, SubQ Trk 01, AMSF 66:10:68
13 Cache LBA 297669, SubQ Trk 01, AMSF 66:10:69
14 Cache LBA 297670, SubQ Trk 01, AMSF 66:10:70
15 Cache LBA 297671, SubQ Trk 01, AMSF 66:10:71
16 Cache LBA 297672, SubQ Trk 01, AMSF 66:10:72
17 Cache LBA 297673, SubQ Trk 01, AMSF 66:10:73
18 Cache LBA 297674, SubQ Trk 01, AMSF 66:10:74
19 Cache LBA 297675, SubQ Trk 01, AMSF 66:11:00
20 Cache LBA 297676, SubQ Trk 01, AMSF 66:11:01
21 Cache LBA 297677, SubQ Trk 01, AMSF 66:11:02
22 Cache LBA 297678, SubQ Trk aa, AMSF 66:11:03 [Lead-out]
23 Cache LBA 297679, SubQ Trk aa, AMSF 66:11:04 [Lead-out]
24 Cache LBA 297680, SubQ Trk aa, AMSF 66:11:05 [Lead-out]
25 Cache LBA 297681, SubQ Trk aa, AMSF 66:11:06 [Lead-out]
26 Cache LBA 297682, SubQ Trk aa, AMSF 66:11:07 [Lead-out]
27 Cache LBA 297683, SubQ Trk aa, AMSF 66:11:08 [Lead-out]
28 Cache LBA 297684, SubQ Trk aa, AMSF 66:11:09 [Lead-out]
29 Cache LBA 297685, SubQ Trk aa, AMSF 66:11:10 [Lead-out]
30 Cache LBA 297686, SubQ Trk aa, AMSF 66:11:11 [Lead-out]
31 Cache LBA 297687, SubQ Trk aa, AMSF 66:11:12 [Lead-out]
-----------------------------------------------------
Cache SIZE: 31 (This size is different every running)
-----------------------------------------------------

Neat.

Has anyone tried the Vinpower version of the WH16NS58 firmware? If it supports 0xF1, I might switch my svc code NS50 drive over to that firmware so that it can do both Blu-ray scanning and scrambled rips.

Edit2: The Vinpower firmware for svc code NS50 drives (WH16NS58 v. 1.V5) does not support 0xF1. It just throws check conditions for "ILLEGAL_REQUEST - INVALID FIELD IN CDB." Bummer -- can't have a firmware on the newer version of the drives that will do both 0xF1 and quality scans.

I've been doing experiments in switching between using my Plextors and my WH14NS40 crossflashed to a BW-16D1HT for various rips. One thing that periodically comes up is the inability for the BW-16D1HT drive to dump some discs due to a "this drive can't read into lead out" message from DIC. I thought the /mr switch was meant to resolve this error by reading into the lead out by reading from the cache? However, for this zero offset disc I just recently tried to dump, even /mr wouldn't allow the disc to be dumped due to the "can't read into lead out" error.

Is there some other steps I'm supposed to be doing to dump such discs?