Glad to hear people have reached out to help, but the sad thing is for every project like this there are a hundred more that die a quiet death every year.
CDROM is a terrible way to store data. Any frontend to dd could back the CDROM up 1:1. That should be the first and primary focus. After that and an upload of however long (depending on internet connection), the wisdom of the crowd could be utilized. Even if the requirement of Windows 98 is correct, any VM (perhaps even ReactOS) could access it.
IIRC, there used to be a dd-like tool, maybe cdrescue? (a Linux command-line tool), that would recheck the data extracted, and then do a "best of n" check on any spurious sectors of the disc.
It's been at least 10 years since I had a CD/DVD drive though, so it might have been a mode of one of the dd_rescue/ddrescue/dd-rescue programs??
Comments
CDROM is a terrible way to store data. Any frontend to dd could back the CDROM up 1:1. That should be the first and primary focus. After that and an upload of however long (depending on internet connection), the wisdom of the crowd could be utilized. Even if the requirement of Windows 98 is correct, any VM (perhaps even ReactOS) could access it.
IIRC, there used to be a dd-like tool, maybe cdrescue? (a Linux command-line tool), that would recheck the data extracted, and then do a "best of n" check on any spurious sectors of the disc.
It's been at least 10 years since I had a CD/DVD drive though, so it might have been a mode of one of the dd_rescue/ddrescue/dd-rescue programs??
Probably just ddrescue by GNU, which can also be used on CD drives.
For audio CDs, I've always used EAC [1] with secure mode. I believe I even used it within Wine. It yielded better results than cdrecord.
Morgoth, FlashFXP, Preee, hkSFV, DCPP, and all that beautiful Windows software also worked in Wine.
[1] https://www.exactaudiocopy.de/