[Andlabs]

I tried a variety of Google searches but the closest I got was this blog post by the author of gcfuse/xbfuse which merely confirmed that the Dreamcast game data track (track 3) uses a custom ISO9660. I can't get any files out of this data track on Linux with standard ISO9660 tools (trying with simple ISO extraction in both p7zip and The Unarchiver, mount, and cdemu). What is this format, so a proper mounter can be written? Thanks.

This post has been edited by Andlabs: 06 February 2013 - 06:28 PM

[sonicblur]

I thought I read at some point that they were standard RAW Mode 2 Form 2 data tracks, but that doesn't appear to be correct after looking at one. The sector headers are too big to be Form 2.

They are definitely 2352 byte sectors, which matches both Raw Mode 1, Raw Mode 2 Form 1 and Raw Mode 2 Form 2. Every sector begins with a 16 byte header, followed by 2048 bytes of data, followed by 288 bytes of EDC+ECC and whatever else is there. In other words, at least in a hex editor, it looks like standard redbook data.

I think the reason tools are confused by it is because the LBA starts at 45000 instead of 0. ISO tools have no way of knowing it's not the actual beginning of the ISO.

Edit: Yes, that's it. It's standard redbook, but nothing can read it because all of the LBA locations are shifted by 45000 since that's where Track 3 starts on a normal GD-ROM.

This post has been edited by sonicblur: 06 February 2013 - 09:03 PM

[Andlabs]

Ok, thanks! I just wrote a quickie tool to fix this in a hacky way (write the first 45000 blocks twice, then the rest of the file). There's probably better but I gave up trying to figure out how to edit some existing ISO programs and got frustrated with the standard when I tried to make my own :/ Code: http://pastie.org/6090224 Thanks again!

[sonicblur]

Why twice? And why do you write 2048 byte sectors instead of 2352? Is your original track rip stripped down from 2352 to 2048? I'm just surprised that what you did works.

[Andlabs]

Yes, I did the 2352->2048 conversion before trying anything else. I write the top part twice first to get the primary volume descriptor in the right place, then again to get whatever data follows it in the right place (87MB is a lot =P ). I know there are better ways to do them, but this required the least effort. Perhaps one day I'll write (or find) a proper ISO mounter or exractor for this.

This post has been edited by Andlabs: 08 February 2013 - 10:44 PM