Howdy folks, I'm writing a fuse plugin that'll let me mount track 3 from my gdi dumps and see what's inside. I know I can't be the first person who's done this, so I was wondering if anybody here has any tips or pointers to docs The information I've been able to find on this subject from googling is pretty sparse. Thinking out loud: Looking into the hex dumps I have, it seems that (what ISO9660 would see as) the root-directory doesn't actually have anything in it, but there's always an ISO-9660 directory record at 0xb814 which has a lot of files (including 1ST_READ.BIN)...except the block-addresses of the extents in this record don't point to anything (or if they do point to anything then the way you translate a block number to a byte address is different from the way you'd do it on ISO9660). EDIT: although now that I think of it, my earlier statement that the root-directory record doesn't have anything in it is only true if I'm interpreting the root-directory record correctly...
I might misunderstand your post, but if I understand correctly you're planning on writing an application so that you can explore GDI-images on your computer and see it's contents? If so, you might want to postpone that project, seeing fellow member @japanese_cake already made an beautiful application for this (link).
Yes, that is similar what I'm looking to implement. Unfortunately I can't run it on my PC because I don't have Windows (and I'm having no luck running it through wine, either) and the source code doesn't appear to be publicly available.
Ah ok, I didn't get that part sorry . Hopefully you can find the information you're looking for overhere!
You might wanna look inside my gditools.py code https://sourceforge.net/projects/dcisotools More info and usage examples here http://assemblergames.com/l/threads/gditools-py-a-python-program-library-to-handle-gdi-files.55022/ You can either use it to extract all files or browse interactively and extract what your want. The ip.bin and sorttxt.txt can also be retrieved. It uses directory records/path tables to parse the FS. Basically, the gdrom FS is simply iso9660 starting a LBA45000. For games with 5+ tracks, the TOC is in track03, with some zero padding and the data it points to is in the last track, there's audio tracks in between effectively padding the data at the end of the disc. In a way the TOC "jumps" over the audio tracks. What gditools does is to wrap around an iso9660 library to present it with an object that looks like a single huge 122min track in 2048bytes/sector, but is in fact simply the gdi dump converted on the fly. It's kind of an on-the-fly/per-sector/on-demand isofix with support for >3 tracks and transparent bin2iso. Feel free to use/inspire yourself from gditools, it's licensed under GPLv3 and the iso9660 library it uses is licensed under BSD. If you got any other question, feel free to ask.
Ah, I understand now. I mistakenly thought the block addresses started from the beginning of each track Thanks a million, FamilyGuy!
