chdman: extractcd corrupting audio tracks when using wrong extension

[FoxhackDN]

MAME version

0.277

System information

Windows 11 Pro 64-bit 23H2 / 32 GB RAM / i5-8600K CPU

INI configuration details

Emulated system/software

chdman

Incorrect behaviour

CHDMAN corrupts data when using the wrong file extension in extractcd

Expected behaviour

CHDMAN canceling the extraction, or at least warning the user to not use the wrong extension.

Steps to reproduce

First, extract a standard CHD with the command chdman extractcd -sb -i "foobar.chd" -o "foobar.toc". In my original test case, I used kisuishou densetsu astal (japan) (4m).chd from the Saturn software list, which has two tracks.

The toc file will seem to extract correctly, and track 1 will have the correct data, but track 2 will have different data compared to extracting the chd to foobar.cue.

I then tried it with another chd that had several audio tracks: asuka120 [asuka 120pct burning fest limited (jpn) (dw0264).chd]. Track 1 extracted fine, but all the audio tracks were different from the extracted .cue.

Additional details

I originally found this because I used the wrong extension when extracting a CD - .bat. I inspected the CRCs on the two files to make sure they were good (using Redump's checksums) and track 1 was fine but track 2 was not. It was then that I realized I had extracted to "bat" instead of "cue" so I opened the file in notepad and noticed the data on it was in .toc format.

I thought the dump was bad but then I did it again by using a .cue extension, and the data extracted fine. I did it to .toc, and again, corrupted audio. So this issue is reproducible. This happened with both split tracks and a merged single track.

Neko May also suggested that I try this with a random extension (.ass, amusingly) and the issue persisted. So I suspect chdman is falling back on toc when it finds an extension it doesn't recognize, and it's somehow corrupting the audio files for some reason.

[p1pkin]

it works as expected, by default TOC format use bigendian (byte swapped) RAW CD-DA tracks

[FoxhackDN]

... then maybe there should be code that ensures this doesn't happen? Why is it even using TOC as the default way to extract a CHD instead of Bin/cue? Why is there no warning about the wrong extension / format being typed in?

[rb6502]

Because the support was originally written for Linux in 2007-ish, which was a time and place where bin/cue didn't exist (and largely still doesn't). Also, TOC/BIN is more tightly specified and can express more nuances than CUE/BIN. (For instance, CD audio tracks on the disc are big endian, so CUE/BIN is technically wrong).