SHA-1 of fpr23905c.ic36 in segadimm is incorrect

ROM fpr23905c.ic36 in segadimm in currentroms is incorrect; it has the correct crc32 but the wrong sha-1.

This is the correct one: https://bda.retroroms.info:82/downloads/mame/update-packs/mame-0267/segadimm.zip

I've noticed this happening in FBA & its clones where only size and crc32 are available, hash collisions are becoming much more common, and RV will set the earliest instance as the correct one with freshly created sha1 & md5 checksums.

Even if you put the correct ROM in your ToSort path or dir, it will still be ignored. And even if you delete the incorrect ROM it still will not scan correctly.

You have to have the bad rom removed & have it removed from the cache data entirely then rescaning then reloading dat with only the crc32 present & the good ROM present & then rescanned. 

If you integrate large collectioms that has ridiculously large number of files, and mix it up with a collection that has only size and crc32, then you are bound to have several hash collisions, where incorrect ROMs are incorrectly bundled into the crc32 only dats.

I wish the author of all DATs include SHA1 hashes of all its ROMs.

The Mame dat includes the sha-1 so this shouldn't happen, unless when you use Level-1 fixing in RV instead of the default Level-2.

You're right about FBA/FBN only using crc32; that's asking for problems.

Replaced, thanks for reporting it.