util/cdrom, machine/t10mmc: Add preliminary support for multisession CD-ROMs, indexes, and track flags

[987123879113]

All of the commits can be reviewed independently. Opening as a draft to get feedback because it's a lot of changes.

I won't be adding CHD support for these features. This is just to get the features somewhat functional within MAME and then in the future someone can figure out how to add CHD support. All of the features can be tested by loading a .cue/.bin through -cdrom.

• Did some refactoring of util/cdrom for readability since there was a lot of samey code doing the same initializations and checks in parse_metadata in particular
• Removed idx0offs and idx1offs in favor of an array of index values and added the code to read indexes from .cues
• Parsed out the FLAGS from .cue and made them readable through get_adr_control
• Added preliminary multisession support. Multisession support in cues seems to be a bit fragmented so I pulled samples from various dumper tools and made notes of the differences
• Filled out the code to return index, sessions, and full TOC for the T10MMC_CMD_READ_TOC_PMA_ATIP command
• Implemented T10MMC_CMD_MECHANISM_STATUS since it was used by cdrdao, which I was using for testing within MAME to easily check if things were reading properly
• Some other small cleanups to t10mmc

Multisession CDs can be tested using the pumpitup BIOS machine and manually specifying one of the multisession .cue games. I've tested "Pump it Up: The 2nd Dance Floor" and "Pump it Up The O.B.G: The 3rd Dance Floor" and they both are booting and playable with these changes. The later games after that are also multisession CD but need additional hardware emulation to boot.

It's possible to run cdrdao within MAME using shutms11 via a Knoppix live CD (enter knoppix 2 to boot without the X11 GUI) to do more thorough testing. Index detection probably won't work without CDDA scanning implemented, which I didn't include in this PR.

The generated full TOC and legacy TOC were checked against data dumped via Redumper and/or DiscImageCreator when possible. It isn't perfect (first lead-in area being hardcoded to 95:00:00 for example) but it mostly generates a matching full TOC and legacy TOC.

[happppp]

@987123879113 OT if you already saw the notification then nevermind, I left a note here about an array out of bounds issue in one of your devices: https://github.com/mamedev/mame/pull/11558#issuecomment-2027037394

[rb6502]

This looks really good. It's pretty much how I'd always envisioned multisession working in my head, plus some other useful fixes (keeping all of the track flags, allowing 99 indices, etc).

[zakk4223]

What would be needed to get at least multiple indices working in CHD? There a number of Sega Saturn games that rely on indices into individual tracks to play certain music bits/sound effects etc.

Would a new metadata tag that just contained something like TRACK:X INDEX:Y LOCATION:<FRAME NUMBER> be sufficient?

[cuavas]

If the index numbers are actually present in the subchannel data, all that’s needed is for the CD-ROM drive emulation to implement the index scan commands properly and actually, you know, scan for the requested index number.

[zakk4223]

They aren't. I'm specifically referring to the work in this PR which parses them out of the CUE file and adds them to the track_info structure. Unless you're suggesting the solution to this in chd is to generate fake subchannel data based on the indices?

[cuavas]

In real life, index markers are stored in subchannel data (X field in Mode 1 DATA-Q). If the .bin file uses a sector format that includes subchannel data, the index markers should be present in the subchannel data. The CD-ROM drive device should scan for the requested index marker in the subchannel data.

[zakk4223]

Yes I know. What I'm saying is this PR we're commenting on doesn't implement it that way. It parses it out of CUE file (INDEX XX MM::SS.FF) and puts the offsets into a idx array in the track info structure. Then has a way to lookup index based on frame number.

I was merely asking what the best way to implement carrying that info into chd metadata would be. If the real solution is to just throw away how this implementation does it and demand dumps all contain subchannel data (which many don't) then I guess my question is answered.

[cuavas]

If it has a way to look up index based on frame number, I would have thought it could, you know, generate the appropriate X field value for that frame.

[zakk4223]

I'm confused. This PR is merged. At least one cdrom implementation (machine/t10mmc) uses the index metadata from the cue file to handle track indices beyond 01.

Previous to this PR the mame cue parser completely ignored any INDEX entries beyond INDEX 00 and 01. Now it doesn't, and it stores that info in track_input_entry.idx[idx_num]. I assumed it would eventually be desirable to have that data survive conversion to chd and back to bin/cue, so I figured I'd ask what that metadata would look like. Is it not desirable to have that index data preserved in chd?