Dreamcast GDI files #26
Comments
|
https://en.wikipedia.org/wiki/GD-ROM#Regions Basically, second data area (not tracks, gd-rom has '3' data areas with different 'tracks' inside it) is 'copy protection' with some copyright text. The hashes of that are probably not unique. First data area is a mixed 'std cd-rom' area and the first 'actual track' inside that 'redump/TOSEC track' is the famous warning not to play a gd-rom in cd players, and the rest is binary data, or any other crap the devs wanted to make visible on a windows filesystem. It's quite possible the set is full of duplicates for this 'redump track' also. The code seems to think that the 'thing to hash' is the third. Rightfully in my opinion since doing otherwise would make the 'hash' useless to identify romhacks, like the shemue retranslation for example. I suspect that the sega header is right at the start of 'track 1' (if it doesn't interfere with the audio warning) or 'track 3' from redump but i didn't actually check it). If this is true, there is good reason to suppose that hashing the first 256 bytes of track3 would serve as a 'serial' but i didn't check where the SEGA header actually is. Extracting the 'actual serial' from the SEGA header seems to be kind of awkward especially on earlier consoles since fixed offsets seem not to be enough, but maybe i just don't understand the format and it has index pointers and base64 encoding or something. Or maybe it's another case of 'what counts is what's painted on the disc&manual, not what's in the data'. Retroarch already has too many cases of false positives due to using 'serials' instead of allowing me to force hashes checks. The situation gets ridiculous if all platforms with a serial identify games that were hacked as the original game. Why am i even contributing cd hacks hashes if they won't display the right name and info? That's a different problem though, fast serial checks also have their uses. I just wish the scanner was much much smarter. Preferred Scanner mode if possible = |hash|serial|mixed¹| would be very useful imo. ¹ first check if serial exists on hack database only hash to check if so. This increases the 'hash costs' for games with hacks, but prevents games without hacks from waiting to hash gigabytes at the minor minor cost of a extra serial check for all games into a separate 'hack database'. If calculated hashes and serials were what is saved on playlists (instead of database hashes and serials), it would also allow the creation of two levels of 'configurations' for games, one that applies to all with the same serial (hacks included) one that applies to exact hash checks only after a scan. Dolphin goes even further and allows 'region duplicates' for configurations (ie: even looser than serials), but i think that depends on a predictable serial format. There also needs to be a system to override factory print errors with a hacks that force a different check for a 'serial' (ie: urban chaos and threads of fate have the same serial in disc even if they have 'different' serials on the - corrected - database, so the right match may not succeed) |
@bkoropoff I did a test of scanning Redump files. Here's the output from the console....
Unsure why it referenced
767da1a0, as that's the CRC for Track 3 in Redump...Do you know what logic it uses to select the "first data track"?
The text was updated successfully, but these errors were encountered: