GD-R Dumping for Redump - Research & Discussion

Presenting the first GD-R submission (?) to Redump.

So a few things with this dump.

It's been suggested in the past that traditional methods of dumping GD-ROMs using DCDumper and the Audio trap disc swap trick didn't work for dumping GD-Rs. This isn't actually true, and we were able to dump an old prototype release of ours using these methods, but with a drive that wasn't known to be supported before - a Plextor PX-4012TA connected using a UGREEN adapter.

A couple things to note though - we dumped this prototype before using Dreamcast SD Rip on two separate authentic copies of the same prototype. The hashes matched, and were the basis of determining this dump as well. We performed the same dumping procedure as laid out by the wiki's dumping guide, however we used DiscImageCreator's ability to dump GD discs over DCDumper. Even though DCDumper worked, it's prone to issues during the dumping procedure because of the way it compares against the individual sections it creates. DCDumper also doesn't utilize EDC/ECC, C2 error correction, the ability to control the read speed, or per sector retrying. DIC, however, does and was able to function as intended. We were able to dump this disc in less than half an hour, where it might've taken longer with DCDumper.

We first attempted to dump the disc using a TSST TS-H353A flashed with Kreon firmware. While dumping GD-ROMs worked okay, the drive locked up when inserting a GD-R. However, even though it wasn't known to be supported before, we were able to get the drive to start reading the GD-R by using a Plextr PX-4012TA updated to the latest firmware. The drive was disassembled to remove the top so that the audio trap disc method would work.

We used the following procedures to make the dumps, as per sarami's instructions on his Github page:

Insert the audio trap disc to a supported drive.

Run below. (stop spinning disc)

DiscImageCreator.exe stop [DriveLetter]
Use a pin to press the escape eject button, so the tray will eject (or remove the drive cover).

Insert the gdrom and run below (or gently push the tray back or put the drive cover back on).

DiscImageCreator.exe close [DriveLetter]
Run below. (start dumping the GD-ROM)

DiscImageCreator.exe gd [DriveLetter] foo.bin [DriveSpeed(0-72)]

We appended a /c2 parameter with 1000 retries since we assumed that reading these discs would be a bit flimsier. To dump the LD, we dumped it to a separate folder than the HD. Then after the two dumps were completed, we took the dumps and compared them to our original DC SD rip dump and almost every track matched except track02.raw, which had more data in the DIC redump than the original dump we made.

Finally, we took the two individual CUE files for the LD and HD portions of the disc and combined them into one. The cue layout matched the final perfectly.

We only encountered one small issue dumping the disc - initially, possibly due to drive error, DIC underdumped the first sector by half and didn't analyze the GD-ROM contents/header. But upon running it again, it dumped everything correctly.

Then we dumped the disc with DCDumper and got the same results for Track 3 in comparison to DIC. I attached the results of both attempts.

The Plextor PX-708a also works well for GD-Rs. It actually can read GD-ROMs too. This is possibly because this particular model has GigaRec support, which was introduced starting in 2003 for Plextor drives.:

https://www.mediafire.com/file/lr7x4sh1 … ic.7z/file

Current list of supported drives for GD-Rs:
Plextor PX-708A (GD-Rs and GD-ROMs)
Plextor PX-4012TA (GD-Rs only)

Current list of partially supported drives for GD-Rs. These read, but can possibly fail past a certain point near the end. Might just need a laser alignment (forcing the drive to read at a certain sector, with something like CDRwin).
Plextor PX-760A (GD-Rs only)

Current list of unsupported drives:
Plextor PX-4824TA (doesn't read anything despite reports, could be just our drive)

We have a ASUS BW-16D1HT and a Plextor PlexWriter PX-W5224TA on the way for more testing. Will keep you informed (this might go in another topic once this submission is cleared).

Plextor PX-760a can work as well thanks to @sarami.. The drives we were using sometimes encountered drive cache flushing issues, so experimenting with the /f parameter and setting a value for when to flush the cache seems to get PX-760a over the bar with no issues as well. The PX-760a can even read our test GD-ROM (Sega Bass Fishing) with the /f parameter, something that either it didn't do before because of the cache or we just forgot to test it, lol. But we couldn't get the 760a to work with other GD-ROMs that might read fine in other drives, so we're not sure if it''ll work for every GD-ROM.

We're thinking it might depend on when the GD-ROM was manufactured. I'm not sure if this was ever looked at. But when the Dreamcast launched, some games had issues in the early days I think due to printing issues with the GD-ROMs. This might be why?

Status update. We're still working on this actively. We have tested about 80 drives so far with GD-ROM and GD-R dumping with DIC/DCDumper. We have a few GD-Rs to try and about 40 on their way for further testing (yes, these will be submitted). We have a list of drives that seem to be key to dumping them, with more drives on the way. Plextor is looking mighty good for GD-Rs. Some support GD-ROMs as well.

There are currently some bugs with DIC that should be addressed first however. We posted about them here:

DiscImageCreator doesn't retry C2 errors properly when dumping GD-ROMS with /c2 (var1) 0 or /c2 (var1) 1 using a compatible drive:
https://github.com/saramibreak/DiscImag … issues/146

Feature Request - New var2 setting for /c2 that corrects c2 errors as the scm is being created, not after (/c2 var1 2)
https://github.com/saramibreak/DiscImag … issues/147

GD-ROM dumping does not support some directory record sizes (fixed? needs testing)
https://github.com/saramibreak/DiscImag … issues/149

Feature Request - Create a Redump GD-ROM .cue when GD mode is used.
https://github.com/saramibreak/DiscImag … issues/150

Feature Request - Discard .img(/.sub) files when using GD mode.
https://github.com/saramibreak/DiscImag … issues/151

Ideally DIC needs a solution for retrying/rereading sectors, kinda similar to what DCDumper does with fake reads but maybe there's a better solution. Doing any kind of seeking back and forth seems to cause a few issues.

I do want to point out. I like redumper, a lot. So I took a part of an article I was writing and gave it to superg in the form of an issue request. This goes into A LOT of detail about what we found out when dumping GD-R/GD-ROMs. I'd suggest taking it a look.

https://github.com/superg/redumper/issues/21

Ideally, going forward, unless the owner of libredrive opens up a bit more, one of the better solutions that we might be able to use is using certain Plextor drives and the D8 command by patching the firmware to read beyond MSF 79:59:74. That would take care of the need of a trap disc, and we could read some more data too (maybe even the security ring). The issue at that point is what to do about problematic discs, in which case we need a solution like superg's redumper that lets you refine discs with different drives. This way, even hard to read discs in one drive can eventually be dumped using a combination of different drives.

Keep in mind, not all GD-ROMs are created equal either. Some GD-ROMs are just hard to read in certain drives. Sega Bass Fishing is an example of a GD-ROM that read in pretty much any drive that supported them, but two copies of Flag to Flag (which was also resurfaced), is really hard to read. GD-Rs can be read more reliably since they're all 'mastered' the same way. But GD-ROMs can vary from where they were manufactured and when, I think.

The type of disc you use for your audio trap disc can matter too. At least for some drives.

user7 wrote:

ehw wrote:

unless the owner of libredrive opens up a bit more

What's needed, is that software closed source? Has anyone reached out to the dev (or know how to contact them)?

The libredrive firmware and all the payloads it uses are closed source. There was apparently going to be a library at some point to interface with, but currently libredrive can only be used with MakeMKV, which is also closed source. RibShark was working on cracking it so you could use it, but I'm not sure if it's still being worked on.

libredrive would be ideal for pretty much everything. Most of the problems with these atypical discs are caused by the firmware. libredrive would enable anyone to have full control of the drive's laser at a very low level, so we could use it to read formats that normal firmwares would otherwise reject. It would also help get us farther away from having to use ancient Plextor drives, and open up support for a gigantic ocean of drives.

Basically we just need open source disc drive firmware.