Sega/Mega CD headers have incorrect serials

[hizzlekizzle]

As discussed in this reddit thread: https://www.reddit.com/r/RetroArch/comments/17860mt/comment/k52yvgo/?context=3

It appears Sega CD games semi-frequently have the wrong serial number in their headers, leading to incorrect matching when we scan them. Some examples:

Tomcat Alley (USA) - Appears as Wonder Dog (Europe)
Sol-Feace (USA) - Appears as Wolfchild (Europe)
Silpheed (USA) - Appears as Double Switch (USA)
Prize Fighter (USA) (Disc 1) - Appears as Prize Fighter (Europe) (Disc 1)

In each of these cases, the actual game's header includes the serial of the "appears as" game, and the "appears as" game also has that same serial in its header. This unfortunately indicates that checking headers is unreliable, at least for these games.

Would it be possible to have a list of games where we "if X serial, do a manual checksum to verify"?

I believe this issue started following this still-excellent and much-appreciated PR: libretro/RetroArch#11719

If that's indeed the case, would it make sense to revert Sega/Mega CD back to the old method?

[RobLoach]

Wonder Dog: http://redump.org/disc/53290/
Tomcat Alley: http://redump.org/disc/24405/

Looks like the serials are brought into the .dat files correctly. Something definitely is up.

[9p6]

What about the games without a serial like Snatcher (USA)? I've noticed they're being filtered out entirely from rdb

https://github.com/libretro/libretro-database/blob/master/metadat/redump/Sega%20-%20Mega-CD%20-%20Sega%20CD.dat#L3219

[RobLoach]

Without a serial there is no way to identify them against the DB. Best way to handle that is the manual scan.

[9p6]

Maybe a redump entry can be edited to add serial field since it's visible in the header dump below. I'll try to register account there.

[RobLoach]

The redump forums are active. Definitely post it up in the Additions and Fixes section.

[c0d3h4x0r]

I just made a highly-related discovery... this repros with stable RetroArch 1.19.1 on both Windows x64 (Windows 11 Pro) and Android (AYN Odin 2 Pro).

I have set of redump.org-DAT-verified SegaCD/MegaCD CUE/BIN sets. They have been validated by ClearMamePro, and I have also manually spot-checked their names and checksums against the latest libretro-database DATs to ensure they are correct.

RetroArch's content import function fails to detect nearly ALL of these legitimate CUE/BIN sets.

After manual examination of several checksum-verified BIN files using a hex editor, and careful examination of the RetroArch source code, I suspect the cause is an oversight or mismatch between the function detect_scd_game (in task_database_cue.c) and libretro-database. Specifically, they do not treat leading zeroes in the serial number (after the T-) the same.

For example, the serial number of Make My Video - Kris Kross (USA).bin will get read in as T-06202 -0. Whitespace will then be removed, changing it to T-06202-0. Then the final hyphen and everything after it will get truncated, yielding T-06202. But the serial number for this title in libretro-database is listed as T-6202 (no leading zero), so it does not match.

This discrepancy (leading zero difference) holds true for all unrecognized (but checksum-correct) SegaCD CUE/BIN sets that I've manually examined.

[c0d3h4x0r]

I'm going to try adding a leading 0 after every T- for every serial in the DAT file, figure out which titles that enables RetroArch to recognize, and then revert all the others. That should cure at least a good chunk of the problem.

[RobLoach]

Could it be over of the legacy dats? https://github.com/libretro/libretro-database/tree/master/metadat/serial

[c0d3h4x0r]

@RobLoach - I don't understand your question. There are no DATs for Sega-CD/Mega-CD in that location you linked. It only contains DATs for Genesis/MegaDrive cartridges, afaict.