GD-ROM and libredrive

[AffSeda]

Excellent. They are quite something. Although, I use a Dreamcast with a broadband adapter for GD-ROM dumping. Slow as hell, but pretty reliable.

Yeah, I got the BBA later on (I'm in Australia, and they weren't sold here directly); but even after that I was torturing my poor GGW-H20N. There were some discs that got a little scratched the Dreamcast wouldn't read, but the GGW-H20N would.

I've been wondering about this while reading the LibreDrive sticky, actually. A GD-ROM is effectively a CD with a high density area completely readable in a normal CD drive, but a CD drive won't go to that area because the Table of Contents (ToC) says nothing is present. While obviously well outside the scope of MakeMKV, I'm wondering if some other application could use the LibreDrive access method to make it possible to finally easily backup GDs without having to either use the Dreamcasts (often failing) drive, or opening an internal desktop drive.

[mike admin]

So, theoretically, if LibreDrive would export a command for you, something like "update TOC in drive memory", do you think this will be enough? Another option (already available) is "read sector by physical address" command.
Both of these can easily damage seek mechanism. I almost killed one drive by repeatedly trying to seek into leadin area...

[AffSeda]

I assume you moved this and I didn't somehow create a new topic while trying to reply..?

So, theoretically, if LibreDrive would export a command for you, something like "update TOC in drive memory", do you think this will be enough? Another option (already available) is "read sector by physical address" command.

Linux (booted on the actual Dreamcast) did not see the first areas of the disc when creating an image. It saw only the high density region. So it's quite possible that "update toc in drive memory" might do the trick as I could simply update it with the TOC from an image of a 99min trap disc or a known full-size GD. However, I would prefer some way to have it perhaps ignore the first TOC - if thats possible on command.

The "read sector by physical address" command - I assume you mean 'physically start here with the laser aimed at this distance from the centre'? That sounds more efficient, as it would then seek straight to the TOC... but do all drives interpret commands like that the same way?

Both of these can easily damage seek mechanism. I almost killed one drive by repeatedly trying to seek into leadin area...

Or is that what happened here?

The track separator on the disc is visible to the naked eye;


The inner ring is the low density / standard CD area. The second ring is a separator track - this contains no data. The outer area is the high density area, and that's what we need to read.

(Image mainly included for anyone else wondering wtf we are talking about)

[icourt]

http://www.stc.hacking-cult.org/gd-rom_ ... c%20v1.pdf

[AffSeda]

I'm really glad I'm not the only one with fond memories of that console. It's a shame really, as there are so many optical-based devices that will be lost to disc rot over time. It would be nice to rescue one.

Interesting how that guide specifies a 112 minute track. I wonder if that's the maximum size of a disc, and I just got lucky that none of the ones I used exceeded a 99min value.

[RibShark]

So, theoretically, if LibreDrive would export a command for you, something like "update TOC in drive memory", do you think this will be enough? Another option (already available) is "read sector by physical address" command.
Both of these can easily damage seek mechanism. I almost killed one drive by repeatedly trying to seek into leadin area...

This sounds intriguing. Could you give some details about the CDB for this "read sector by physical address" command? I'd be very interested to try and use it.

[mike admin]

This sounds intriguing. Could you give some details about the CDB for this "read sector by physical address" command? I'd be very interested to try and use it.

There is no such CDB. I'm talking about LibreDrive command, aka "SDFW entrypoint". Please see the architecture overview at viewtopic.php?f=19&t=18856#p72110 . For details, pls email me.

[RibShark]

I did some testing via the standard 122-min TOC "trap disc" and my BW-16D1HT, and it looks like the drive cannot seek into the high-density area. Whether this is an issue with the seeking algorithm or just the drive not being calibrated to read the higher density data I'm not sure, but being able to read out of the bounds of the disc will not be enough to dump GD-ROMs.