search

j68k / verifydump

A tool for verifying that .chd/.rvz disc images match Redump Datfiles
MIT License
51 stars 7 forks source link

Problem verifying Neo Geo CD games #11

Open j68k opened 2 years ago

j68k commented 2 years ago

This was mentioned by @Immersion95 in issue #10.

Immersion95 commented 2 years ago

Yes 3/4 of my NCD images have a problem with the tool even if they are 100% correct.

I tried this tool on PSX, PS1, PS2, MCD, DC, SATURN, GC, WII and it worked perfectly though.

Please try verifying this one http://redump.org/disc/32722/

j68k commented 2 years ago

Ah, it looks like they use an unusual system with lots of INDEX lines in the .cue file. I'll have to see if I can figure out if that can be recreated. Thanks very much!

i30817 commented 2 years ago

Cue/Toc/gdi files, are in certain sense 'metadata'. I mean, sure, the games won't work without the 'correct' ones, so maybe verifying them is valuable - but they're not part of the game, so much so that dumping groups actually distribute them.

I'm saying that it's not absolutely necessary to 'validate' them for dumps, except if the 'dumping group' only changed the cue/names from another one, and you want to provide to recognize that. A whole lot of your 'recreation' of cue files from the toc output of chdman looks uncessessary to me, even if it's a clever hack for sure.

But i'm not one to speak, i'm 'verifying' cd cue games by only checking the first binary file in the assumption that it's the track with the game executable, and no other tracks. Well, the aim of the tool is renames on DAT names updates, so it's not a big deal, but i could be more exhaustive. And yet, it seems like busy work (unless there is a console with more than one binary track where the first one isn't the one with the game executable, that might be a bug). Should code up .gdi too. Hard to feel enthusiastic about it.

j68k commented 2 years ago

I wondered along those lines when I was writing the code.

In a previous version of the program, if a .cue was provided with the --extra-cue-source option then I would just verify that it was correct according to the Datfile and ignore the converted .cue from chdman. But I decided that wasn't adequate because some of that metadata is actually in the .chd file, and if it's wrong then the game might not work. So I didn't want to be in the position where I said the .chd was verified correctly but actually something critical was wrong in the metadata that broke the game.

I would admit that maybe that's a bit pedantic, though, because I'm not 100% sure if you could even intentionally mess with the metadata in such a way that a game would break but the .bin files would still come out right from chdman/binmerge. But since I was uncertain about it, I thought it best to be overcautious rather than undercautious.