"CUE file not found, using single track mode" when using chd images

[anderbubble]

It's my understanding that the chd image format replaces both bin/cue files; so when scanning a chd image, why does oxyromon need a cue file?

CUE file not found, using single track mode

[TylerVigario]

The DATs we are using doesn't verify CHDs (it's hard to find up-to-date CHD DATs). They actually validate against ISO, BIN/CUE, etc. Thus Oxyromon needs to reconstruct the original file(s) from the CHD to validate against the DAT. The reason you need the CUE file is so Oxyromon can understand how to put the original file(s) back together from the CHD.

[anderbubble]

But a chd contains all the information you need to build a cue, so you shouldn't need one aside from that, if you're already extracting the chd.

https://wiki.recalbox.com/en/tutorials/utilities/rom-conversion/chdman

edit: to be clear, I'm definitely not an expert, so maybe there's something I'm missing; but that's how it seems from what I'm reading.

[TylerVigario]

edit: to be clear, I'm definitely not an expert, so maybe there's something I'm missing; but that's how it seems from what I'm reading.

I totally agree with your position as I had the same understanding. I thought CHDMAN could convert CHD back to ISO, etc without a CUE (never tried this personally though). However, I am not an expert either. Hopefully @alucryd will chime in with some specifics why CHD -> X conversion requires a CUE file for Oxyromon.

[alucryd]

But a chd contains all the information you need to build a cue, so you shouldn't need one aside from that, if you're already extracting the chd.

https://wiki.recalbox.com/en/tutorials/utilities/rom-conversion/chdman

edit: to be clear, I'm definitely not an expert, so maybe there's something I'm missing; but that's how it seems from what I'm reading.

That's only partially true, sure extractcd is able to produce a CUE file, sadly the resulting file doesn't match the one from Redump, and extractcd doesn't have the option to split the resulting bin into all original ones as listed in the DAT. The CUE file only contains timestamps, I haven't found an easy way to split the bin going off of the timestamps alone. The CLI splitters I found are designed for music CDs, and the timestamp precision is only to the second, that's not nearly enough to get an exact size in bits, and I'm not even sure how timestamps would translate to DATA tracks. That's why I need the original CUE file from Redump so i can identify the game and split the bin according to the sizes in the DAT file.

alucryd in 🌐 server in Emulation/NEC - PC Engine CD & TurboGrafx CD/1G1R
❯ chdman extractcd -i Lords\ of\ Thunder\ \(USA\).chd -o test.cue
chdman - MAME Compressed Hunks of Data (CHD) manager 0.251 (unknown)
Output TOC:   test.cue
Output Data:  test.bin
Input CHD:    Lords of Thunder (USA).chd
Extraction complete                                    

alucryd in 🌐 server in Emulation/NEC - PC Engine CD & TurboGrafx CD/1G1R took 6s 
❯ md5sum test.cue 
1e35aac7c0b8668f17fa1beb1f8ec5b5  test.cue

alucryd in 🌐 server in Emulation/NEC - PC Engine CD & TurboGrafx CD/1G1R 
❯ md5sum Lords\ of\ Thunder\ \(USA\).cue 
6d3048fa92edbffb53fb278b3544000e  Lords of Thunder (USA).cue

Thus, without a CUE file to identify the correct game, I can only match the unsplit BIN, which only works when it has a single track.

[TylerVigario]

@alucryd Seems like they should have designed a better suited CUE file alternative for ROMs. Time (second) precision seems to be designed with only audio tracks in mind. I could be totally off base here as this could result of the extractcd limitations or from the way the compression (CHD) works, destroying the original file structure with no way of returning to original.

[anderbubble]

@alucryd thanks for that explanation. I think I see now: when you have bin/cue, each track is a separate file, so you have bit- (or maybe byte-)level granularity of what data is in what track. But when you extract a chd to bin/cue, as you said, I get one bin and then pointers into that bin from the cue, which only has second-level granularity.

So it it possible to verify a multi-track chd file, if you have the cue? What's the right way to do that? Do I just need to have the right cue placed alongside the chd with the same base name? If oxyromon renames the files, does it update the cue as well?

[TylerVigario]

Oxyromon will always base its ROM (and CUE) filename based on the DAT. You just need to have a CUE file for every multi-track CHD that is named the same as the expected ROM but with a .cue extension. For me, it's easiest to just keep a CUE file (pulling from http://redump.org/downloads/) with every CHD I have.

EDIT: @alucryd Does Oxyromon find ROM and/or CUE files based on hash/checksum?

[alucryd]

The CUE file should have the same name as the CHD and be placed alongside the CHD. You should import the CHD only, the CUE will be picked up automatically. I'll clarify that in the documentation.

Roms are always looked up by both their size and hash, I also try to match the game and/or rom name too, helps when there are a lot of dupes, like for arcade.

[Immersion95]

Would it be possible to import the CUE archive from redump with the DAT archive ? Or specify the archive containing the CUE files ?

verifydump actually use the archive as no one is keeping the CUE files alongside chd files.

[alucryd]

@Immersion95 I guess I could download them as they're public, but you would need to have your CHD already renamed to match the Redump name as I have no way of linking the CHD to the CUE otherwise :/

[Immersion95]

@Immersion95 I guess I could download them as they're public, but you would need to have your CHD already renamed to match the Redump name as I have no way of linking the CHD to the CUE otherwise :/

Yes of course

[alucryd]

I'll add it to the todo list.

Note that the smart import won't work here either, I will need to prompt for the system, fortunately I already have a map of system name and codes here. I may be able to circumvent the need to have the correct name if I prompt for the game as well (similarly to what I'm doing with PS3/IRD files already) using a distance lookup between the CHD name and CUE names.