CHDs converted from Redump MIL-CD dumps were rejected with "Unsupported
subtype or pre/postgap": the audio tracks of the first session carry their
pregap inside their own .bin file, which chdman records as PREGAP:n
PGTYPE:V<type> in the CDROM_TRACK_METADATA2 entry.
Handle these tracks the way MAME does:
- when PGTYPE is prefixed with 'V', the pregap sectors are part of the track
data and counted in FRAMES, so INDEX 01 sits `pregap` frames after the
previous track and the track data starts `pregap` frames into the CHD
- otherwise the pregap only takes up space on the disc
- subcode data doesn't change the sector layout, and postgap sectors are
never stored: warn about both instead of bailing out
Also:
- audio tracks of CD-ROM CHDs are stored big-endian, just like the ones of
GD-ROM CHDs using the CHGD metadata tag. Not byte-swapping them was the
cause of the audio distortion reported with CHD MIL-CDs
- the 11400 frame session gap includes the pregap of the second session's
first track. Don't count those sectors twice when they're in the image
- only treat a multi-track disc as a MIL-CD when its last track is a data
track. A mixed mode CD is a single session disc and its data track is the
first one
- report the lead-out as the first FAD after the last sector, like the CUE
and GDI loaders do, instead of one frame earlier
Tested on a dozen homebrew MIL-CDs, from 2 to 17 tracks: the CUE and CHD
loaders now return the same tracks, sessions and sector data for each of
them, and they all boot.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01NfFd8rJc9aTQB7au8yLrqG
* cue: don't count the session pregap twice in MIL-CDs
The 11400 frame gap added at REM SESSION 02 is the lead-out of the first
session (01:30:00), the lead-in of the second one (01:00:00) and the pregap
of its first track (00:02:00). When that track has an INDEX 00 of its own,
its pregap sectors are stored in the image and were counted a second time,
placing the data track 150 frames after the session start reported in the
TOC, i.e. after the FAD the boot file is looked up at.
Redump lays MIL-CDs out with no INDEX 00 on the second session's track, so
none of the images I have hits this. It only shows up with images written by
other tools, and is included here because the CHD loader needs the same
adjustment to agree with this one.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01NfFd8rJc9aTQB7au8yLrqG
Use end FAD +1 of track 2 as start of lead-out for single density area.
gdi: set track end FAD based on track size, not start of next track
chd: ignore pad frames when calculating end FAD
cdi: end FAD was one off
Issue #1386
* core: cleanup include headers
* dx11: remove unimplemented function
* core: annotate destructors with override
* aica: use range-based for loop
* bm: use const reference/structured bindings with blkmap
introduce Storage abstraction interfaces
use Storage i/f to load zip and 7z archives, cdi/cue/gdi/chd media,
cheats and to find custom textures.
Use android file picker to add storage. Request persisted access perms.
jni helper classes.
Issue #813
gd cart: load first .bin if the specified one isn't found. Fix loading
of main directory for mj1. Don't update progress too often when
decrypting.
chd: allow loading of 1-track CD-ROMs
Use 2 jvs boards for mj1
Issue #985
Verify md5 of flash, eeprom, vmus if no savestate used
Use chd header SHA1 as digest
Load .state.net state file at start
Force real BIOS for some games
If the frame count is not dividable by 4, there are extra frames added to keep a padding.
This is true for F355 (450 frames -> 2 extra frames) and others.
Also move CD_TRACK_PADDING to chd.cpp to work around problems with including from C and C++.
