Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
We're currently trying to dump GD-ROMs using the audio trap disc method using a drive that is capable of C2 error correction and scramble read opcode 0xd8 (a Plextor PX-708A). We're noticing that the drive experiences issues. when retrying C2 errors possibly due to seeking issues because of the altered TOC caused by either the audio trap disc or the GD-ROM itself. Even if DIC says that its correcting errors, it doesn't seem to be. This might be caused by seeking issues on the drive because it doesn't know where to align the laser when going back to retry C2 errors.
Describe the solution you'd like
A clear and concise description of what you want to happen.
It would be cool if there was a third option for var2 with the /c2 command (/c2 var1 2) that will retry c2 errors as they're discovered when dumping the .scm, rather than waiting for the .scm to be made before C2 retries can be done.
This way, the drive will never need to seek back to a random location, causing issues with rereads. DIC will take care of what it can per sector without needing to seek back.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
I can't think of any alternative to this feature.
Additional context
Add any other context or screenshots about the feature request here.
Refer to the GD-ROM /c2 issue that might stem from this one.
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] We're currently trying to dump GD-ROMs using the audio trap disc method using a drive that is capable of C2 error correction and scramble read opcode 0xd8 (a Plextor PX-708A). We're noticing that the drive experiences issues. when retrying C2 errors possibly due to seeking issues because of the altered TOC caused by either the audio trap disc or the GD-ROM itself. Even if DIC says that its correcting errors, it doesn't seem to be. This might be caused by seeking issues on the drive because it doesn't know where to align the laser when going back to retry C2 errors.
Describe the solution you'd like A clear and concise description of what you want to happen. It would be cool if there was a third option for var2 with the /c2 command (/c2 var1 2) that will retry c2 errors as they're discovered when dumping the .scm, rather than waiting for the .scm to be made before C2 retries can be done.
This way, the drive will never need to seek back to a random location, causing issues with rereads. DIC will take care of what it can per sector without needing to seek back.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. I can't think of any alternative to this feature.
Additional context Add any other context or screenshots about the feature request here. Refer to the GD-ROM /c2 issue that might stem from this one.