superg / redumper

Low level CD dumper utility
GNU General Public License v3.0
179 stars 16 forks source link

Program closes prematurely if disc has read errors, even if REFINE step completes #145

Closed SlyCooperReloadCoded closed 2 months ago

SlyCooperReloadCoded commented 2 months ago

I'm attempting to use redumper with the MPF frontend (which keeps all its components up to date, zero chance it doesn't have the latest version of anything) to preserve two undumped PlayStation 2 CD-ROM-based discs. One is a preview copy of a game and the other is an assets disc you put into your PC and view like a normal Data CD. The issue only occurs with Redumper and MPF is just a GUI, so I'm opening an issue here.

Dumping the assets disc (normal data CD) works fine, outputting the correct files, logs, etc.

However, people in preservation communities have helped me figure out that the last 5-7% of the sectors on the preview copy are littered with read errors, the damage being invisible to the naked eye. Consumer-oriented dumping programs that have the ability to continue after disc read errors (i.e. CloneCD) have no issues with the disc.

If I attempt to use the same PLEXTOR PX-760A drive with the same disc with Redump, it reads the sectors, detects the read errors like it should, does its REFINE step which reduces the amount of read errors by quite a bit, however it prematurely closes right before it gets to the "Writing tracks..." step, and MPF's output window, which I presume contains Redumper's output, says this:

https://imgur.com/a/yRzaAls

Indeed, it does not produce a bin/cue pair, instead dumping a bunch of unreadable files that normally don't get dumped:

https://imgur.com/a/twlb7jw

It also fails to produce a log file. As a test, I tried the dump again, and I got a repeat performance. It read the sectors, ran into the read errors, ran the REFINE step which corrected a lot of them, and prematurely closed right before it got to the "Writing tracks..." step, just like before. Here's a short clip of the issue, as it crashes before it can produce a log:

https://github.com/superg/redumper/assets/58268914/d77a7e73-49b8-4c52-bc62-a75d52dd6ade

According to the .bin produced by CloneCD, the damage should only affect one or two cutscene audio tracks on the disc, nothing critical to function. In fact, the produced image works and the game plays, so it's not damaged to the point of not being able to produce a bin/cue pair.

I looked around to see if there was a --force-dump-anyways launch parameter, but Google strangely gives me very few search results for anything Redumper-related other than the GitHub page. I also don't have any other damaged PlayStation 2 CD-ROM-based games, so I can't test whether it's the damage causing this or a programming edge-case. Considering other software can produce a bin/cue pair just fine, I'm assuming it is a software bug.

PC Specs:

Windows 10 x64 Build 19045.3803 Intel Core i9-10900K NVIDIA RTX 2080 SUPER 64 GB DDR4 Memory PLEXTOR PX-760A as the dumping drive

superg commented 2 months ago

First of all, PX-760 drive has an issue where for some discs it outputs mass errors for the late sectors. If your disc looks visually intact, reduce your dump speed to 16 and try again. Next, MPF usecase is different as it doesn't support incremental refines. Under the hood, MPF just runs redumper executable. If you run that executable from the console with --help, you will see available options. I'm quite sure reducing speed will help your dump, but if not and you want to always force the cue/bin output, there is an option --force-split.

I also recommend reading README first.

SlyCooperReloadCoded commented 2 months ago

I lowered the read speed to 4 out of precaution and recommendation because I know the disc actually has read errors there, and all CD/DVD drives reflect this. There's a field for parameters, I'm attempting another dump with that added.

SlyCooperReloadCoded commented 2 months ago

This unfortunately does not work. I added the parameter, it accepted the parameter, it got past that step and wrote the bin/cue pair, and I can open it and view all its files. Unfortunately, unlike the CloneCD dump which was fully playable, this dump refuses to boot. The reason for this is that this specific game is EXTREMELY LBA-sensitive. If even one of the files on the disc is off by 1 byte, the game's hardcoded list of sectors to read files from (because it can't read from filenames alone) is inaccurate and it fails to find any files, so it can't boot.

Apparently, --force-split does something that shifts LBA which CloneCD does not.

Any ideas as to what went wrong? @superg

superg commented 2 months ago

If it's not a speed issue, a lot of things could go wrong.

You're basically trying to read the disc with protection errors and genuine errors. How this is usually done is that you run redumper dump --image-name=blabla once to get a base set of files (.scram .subcode etc). Then you run multiple passes of redumper protection refine --retries=<some number> --image-name=blabla to re-read your erroneous sectors while skipping protection errors (no way to fix those). After you managed to refine all errors, you should be able to split with redumper protection split --image-name=blabla

As you asked about how to generate .cue/.bin split no matter the errors, --force-split is the option.

Lastly, CloneCD reading mode is unscrambled. redumper reading mode is scrambled by default. Usually we want to read data scrambled because there is more flexibility there. If disc is read without the errors using scrambled mode it means that drive is fixing them.

SlyCooperReloadCoded commented 2 months ago

I just can't make a Redump submission if it's less usable than a CloneCD dump, that doesn't seem like the right thing to do. I'll gladly do it if I find some evidence online they'd accept it, but I can't find any info relating to this specific topic at all.