ROM, ISO information (hashes)

[puzzledude]

While this is a very usefull idea to be implemented, it doesn't solve the patching problems entirely, specially for rookies.

The first thing is that the SHA-256 hash is really not necessary (the code is too long to be checked and there's already MD5 and SHA-1... and CRC32).

The second thing is the existing paradoxes. The example is the Super Metroid hack, Stardust. The hashes suggest it is the standard JU rom with no header, since that's the CRC32 D63ED5F8. But the patching info on the left is: header (SNES).

Ironically the game starts if you patch it to the headered or unheadered original, while the hex examination show, that the patched files are not identical (for obvious reasons).

There are two solutions for this. First: include CRC32 and MD5 only but for original rom, and a correctly patched rom (that's the vital hash actually). Second solution: accept only UPS files (since the UPS patch would disallow the false patching - in the upper case it would patch only one file, headered or unheadered, but not both like now).



One other thing is that rookies just want to play the game, and have no clue (god's honest truth) what a hex editor or a hash is. They don't know how to calculate a hash (certainly not something like SHA-256). And they do Not read any txt files or your very detailed info on how the hash is calculated (specially the ones who's native language is not English - we are dealing with young people). 80 percent of young players, who's language is not English are having severe problems with this language and its (no so friendly) spelling.


Despite the fact that this looks very professional, half of it is not usefull in practice (we know which file it is just from CRC32 and MD5):
Super Metroid (JU) [!].smc - GOODSNES 2.04
CRC32: D63ED5F8
MD5: 21F3E98DF4780EE1C667B84E57D88675
SHA-1: DA957F0D63D14CB441D215462904C4FA8519C613
SHA-256: 12B77C4BC9C1832CEE8881244659065EE1D84C70C3D29E6EAF92E6798CC2CA72


Having the game filesize is a much better choice (no programs needed). For instance non-headered Super Metroid is 3.072 KB, headered one is 3.073 KB.

For instance:
Super Metroid (JU) [!]
3.072 KB
no header
CRC32 original: D63ED5F8
MD5 original: 21F3E98DF4780EE1C667B84E57D88675
CRC32 hacked: 20D56B9
MD5 hacked: 57F3E32BF4580EE1C558B84E99C77352

is a much better and efficient solution. This is very practical since the 3.072 means no header automatically. The 3.073 means with header.



But this:
CRC32: D63ED5F8
Patching info: Header (SNES)

for Stardust Super Metroid is certainly a wrong info. This paradox would be clear, if the info also had a
CRC32 hacked: 20D56B9
MD5 hacked: 57F3E32BF4580EE1C558B84E99C77352
like above.

[KingMike]

Yes, SNES emulators don't take the header into consideration when calculating the CRC. We can't help that, but that is why we have the special field to indicate header. Taking both the CRC and the header information together, one should be able to tell.
We allow the user to decide how much information is useful, as long as they at least give us one identifiable piece of information. If you don't think SHA-256 is useful, then you can choose to not include it. If the filesize is useful, then include it.