simias
commented
6 years ago Looking at the source code it looks like beetle expects a subtype of "NONE".
I'm not sure what RW_RAW means but looking at mednafen's cuesheet parser I see (in the TRACK cue parser):
So my guess in that in RW_RAW the subchannel data is appended to the track data. So I expect that it means that you ripped you CHD with subchannel data (which is not necessarily a bad thing).
To support that in mednafen I expect that at a basic level you should just ignore the 96 bytes of subchannel data at the end of the sector and I expect it'll behave like NONE. See for instance:
Of course it'd be better to actually use that subchannel data for games that require it (libcrypt copy-protection in particular makes use of it) but that could be done later.
I did a convoluted process to convert some ISOs to CHD, involving cdemu (for loading the ISO into a virtual cdrom), cdrdao (to dump the virtual cdrom) and sdlMAME's chdman (0.191).
Here's the cdrdao command which I used with the hopes of preserving everything from the original ISO file: cdrdao read-cd --read-raw --read-subchan rw_raw --datafile "dump.dao" --device /dev/yourcdromdevice "dump.toc"
The chdman command: chdman createcd -i "dump.toc" -o "dump.chd"
But I guess I got it wrong, at least for having retroarch compatibility, because it crashes with: [libretro ERROR] chd_parse track subtype RW_RAW unsupported [libretro INFO] chd_read_toc: finished [libretro ERROR] TOC first(99)/last(0) track numbers bad. Attempt to read LBA 16, >= LBA 0 CDIF Raw Read error terminate called after throwing an instance of 'MDFN_Error' [1] 32360 abort (core dumped) retroarch
Just in case, from the chdman info command, you can see this in each track: TRACK:1 TYPE:MODE2_RAW SUBTYPE:RW_RAW
I guess it's all reduced to support the RW_RAW subtype.
Note: I don't think this is a specific issue of this core only, since with other cores with CHD support (genesis-plus?), maybe a user could still try to run a CHD of this subtype, but still...
Thanks.