You are correct that TOC is stored in q-channel within the lead-in. Pretty sure the cd ripper programs that extract subchannel data don't even include this, but that info is stored in the cue file to be recreated.
So then as I presume the Mega CD BIOS expects to be able to read the raw TOC data, it would be nice to be able to recreate it, even if presently we have to HLE the CDD that reports on what it says. I don't know the format, though.
The only CD image format I've found for the PC that even supports storing mode 1 sectors in their original, scrambled form is the clonecd image format with a flag in the ccd file, but most programs that use ccd images don't support this flag.
Well, you know me (probably, anyway.) I've already dealt with this and the unacceptable way Famicom Disk Images are currently stored, I'll handle this the same way.
I'll support a new image format that contains all data: lead-in, pregap, postgap, lead-out, subchannel data, etc in scrambled form.
Understandably we can't yet (or possibly ever) create images in this format, but like with FDS, I can write code that "imports" a Mega CD image from a variety of lossier formats by trying to parse cue sheets, rescramble data, etc. I'll store data at 2448-bytes/sector. The raw channel frames is kind of pushing it.
I get that the data won't be guaranteed to be accurate when it's not truly ripped from the original CD, but in this way, I can *support* a proper rip in the event that it ever becomes possible now, and the emulation core only has to implement one format instead of 30 formats.
Conversely, people are going to lose it when they find out higan expects them to import entire CDs to play their games. But I think it's too complex to have the emulation core have to support every image format on the planet and to generate the data dynamically.
It sounds like you know what you're doing, so if I can get the Mega CD emulated, I'll defer to your advice on a Laserdisc image format to support.
I'd strongly advise you ignore the abomination that is iso+mp3 though, and never support it.
I have zero plans to support lossy audio formats, no worries.
I'm gonna laugh if we end up redumping every single CD from scratch using a Mega CD/LD simply because it's capable of dumping all that.
That's gonna get real expensive, real quick with the high and rapid failure rate of Sega CD hardware.
Nonetheless, I'm here in Akihabara for another two years so if folks want, I can start buying up all the Japan-market Mega CD games I can get my hands on. It's already very hard to find the games here, though. Usually only ~10-20 games per shop and almost all of them are the same exact ones (HKB, Sangokushi, etc.)
There's no way to instruct a PC drive to seek to the lead-in area, just the pre-gap. You can read into the lead-out on a lot of drives though.
If nothing can read it, is the TOC binary format encoded in the lead-in Q-channel even known at this point? ._.
...
As to the wobble, yeah I have no idea how one would preserve that. I kind of feel like we should give in at that point and just store whatever data can be extracted from the wobble sections as a separate file. Or worst case, just fake it out in the emulation of the BIOS / drive controller emulation. It's just getting to be too much to try and encode the physical properties of the disc spiral.
A raw channel frame CD is already bordering on 2.1 to 2.5 gigabytes of information.