Menu
▾
▴
#33 GDI file support.
It would be nice because these files are reallly obnoxious. The only 'real' supported library for this is https://sourceforge.net/projects/dcisotools/?source=typ_redirect
Apparently the format requires a merge of different tracks to get the complete TOC:
class AppendedFiles():
"""
Two WormHoleFiles one after another.
Takes 1 or 2 dict(s) as arguments; they're passed to WormHoleFiles'
at the init.
This is aimed at merging the TOC track starting at LBA45000 with
the last one to mimic one big track at LBA0 with the files at the
same LBA than the GD-ROM.
The format looks simple enough and it's clearly in the domain of CDEmu. Assuming theres no surprises I don't mind adding support for it.
The image format itself is quite straightforward, but the GD-ROM discs themselves appear to be multi-session ones. I suspect the "WormHoleFiles" are due to lead-in and lead-out between the sessions.
From my cursory research, it is not yet clear whether we need to have only two sessions (first for the "shortened" data track and audio track with warning, and second for the rest, or are there multiple following sessions based on the number of data tracks...).
Also, there seem to be some specifics about how TOC is reported on GD-ROM discs (i.e., "regular" optical drives not being able to see sessions beyond the first one), and the question is, can we reproduce that and whether we should (i.e., what is the practical use of being able to load such images - could they be even used with Dreamcast emulator?)
I didn't notice the disc format is different too... that could be a problem. I don't think it's worth the effort to write code to emulate Yamaha GD-ROM. Thought the specification is available so it is possible, just not very useful as the hardware is pretty niche.
Question is if it's feasible to pretend it's a multisession CD-ROM and if an emulator is able to make use of that. The files contain markers (plural) for ISO 9660 filesystem, and that can be mounted on Linux (mount allows you to select session). The tool that was linked to basically extracts files from the image, and it seems to me to be more convenient if CDEmu could offer random-access to the same files.
The usecase i'm most interested ATM is creating a gd-rom patcher (much like patchy 98 for floppy/hard disks for the pc-98) https://46okumen.com/pachy98/
Translations and 'final rom' hashes for the dreamcast would get much easier to archive if their patches didn't lead to 400mb binary xdeltas and if hackers didn't insist in releasing complete images on outdated dumps or formats (cdi and alchool comes to mind), and a fileformat aware patcher could do that (because dreamcast games aren't in the habit of packing their files in a virtual filesystem). It would seem that libmirage would be ideal for the backbone of a fileformat aware patcher like this considering it can both read and write.
So in the interests of that usecase I'm not very enthusiastic about 'pretending a game is a multsession cd-rom' because that would ruin any chance of writing it out again after replacing or inserting files for a tool like this.
Last edit: i30817 2018-10-26