Re: CHD Disk Image Format (MAME)
Posted: October 26th, 2022, 3:43 am
Yes, that's one of the basic flaws. The CHD format as such could store them in the subchannel data, but CHDMAN is just ignoring most of the CUE Index values.
One could convert CUE/BIN to TOC/BIN (the BIN with 990h-byte sectors) and then to CHD. If there's no tool that can do that: Convert CUE/BIN to CCD/IMG/SUB and then to TOC/BIN (maybe such tools exist) and then to CHD. That kind of toolchains are likely to imply conversion errors, but it should work in theory (except that CHD will then happily erase all Index 0 sectors).
CHD is a rather lossy compression format, and it's a bit silly to use lossless FLAC audio compression without properly preserving the more basic subchannel data. And it's totally overcomplicated with the metadata stuff with different sector sizes. It would have been easier to store all sectors always in 930h+60h byte format (and to store the TOC also in that same format instead of coming up with metadata stuff).
Anyways, I've experimented with a few more sector sizes... and checked how they are stored in the old CHCD metadata format... that should be fully solved now:
Code: Select all
CHCD Metadata (94Ch bytes, plus 10h-byte metadata header)
000h 4 Number of tracks (N) (1..99)
004h N*18h Track entries
... .. Zeropadding to 94Ch-byte size (when less than 99 tracks)
Track entries:
000h 4 Track Type (0..7, CHCD=# in table below) (eg. 6=MODE2_RAW)
004h 4 Subchannel Type (0=RW, 1=RW_RAW, 2=None)
008h 4 Sector Size (800h, 914h, 920h or 930h)
00Ch 4 Subchannel Size (0 or 60h)
010h 4 Number of Frames (aka number of sectors)
014h 4 Padding Frames (0..3) (to make Total Frames a multiple of 4)
Code: Select all
For TYPE and PGTYPE (and CHCD numeric type 0..7):
"MODE1/2048" or "MODE1" CHCD=0 800h-byte ;\Data Mode1
"MODE1/2352" or "MODE1_RAW" CHCD=1 930h-byte ;/
"MODE2/2336" or "MODE2" ;\dupe? CHCD=2 920h-byte ;\.
"MODE2/2336" or "MODE2_FORM_MIX" ;/ CHCD=5 920h-byte ;
"MODE2/2048" or "MODE2_FORM1" CHCD=3 800h-byte ; Data Mode2
"MODE2/2324" or "MODE2_FORM2" CHCD=4 914h-byte ;
"MODE2/2352" or "MODE2_RAW" or "CDI/2352" CHCD=6 930h-byte ;/
"AUDIO" (stored as big-endian samples!!!) CHCD=7 930h-byte ;-Audio CD-DA
For tracks, is there a difference between "MODE2" and "MODE2_FORM_MIX"?
For subchannels, what exactly is "RW" versus "RW_RAW"?
There are two common ways for storing subchannels in 60h bytes, with differently arranged/interleaved bits (or "cooked" bits as they are called in CHD, whatever "cooking" means in that context").
In the CLAYS sample that I had uploaded some days ago, I've marked the subchannels as "RW" and stored them as 60h-byte array in this format:
Code: Select all
00 00 00 00 00 00 00 00 00 00 00 00 ;P
01 01 01 00 00 00 00 00 02 00 5A 28 ;Q (for first sector at 00:02:00)
00 00 00 00 00 00 00 00 00 00 00 00 ;R
00 00 00 00 00 00 00 00 00 00 00 00 ;S
00 00 00 00 00 00 00 00 00 00 00 00 ;T
00 00 00 00 00 00 00 00 00 00 00 00 ;U
00 00 00 00 00 00 00 00 00 00 00 00 ;V
00 00 00 00 00 00 00 00 00 00 00 00 ;W
Quick question: Do you know a way to create or test CHD files with subchannel data?
The problem is that CHDMAN doesn't check if RW or RW_RAW contain the expected data format. If you feed it with wrong data then it will just create a compressed file with that data. One could test a CHD with subchannel data with emulators that do support and use and require subchannel data (eg. for libcrypted games). And then hope that the emulator is actually distinguising RW and RW_RAW correctly as it was originally intended by the CHD developer.
To unravel what was intended:
CHD is just adopting the format/names RW and RW_RAW from CDRDAO's TOC files.
CDRDAO has apparently adopted the format/names RW and RW_RAW from SCSI, ATAPI, or ASPI drivers.
CHD defines RW and RW_RAW as so:
Code: Select all
"RW" normal "cooked" 96 bytes per sector
"RW_RAW" raw uninterleaved 96 bytes per sector
Code: Select all
RW: packed R-W sub-channel data (96 bytes, L-EC data will be generated if required),
RW_RAW: raw R-W sub-channel data (interleaved and L-EC data already calculated, 96 bytes).