Handle hash collisions
Miss-Inputs opened this issue · 1 comments
So, with the inclusion of CD stuff, we've noticed a problem.
It is in fact entirely possible that a given hash may in fact refer to two different things. Currently, ROMniscience just makes the assumption that the first hash it finds is correct.
Mainly seen with audio tracks, but it's possible that there are hash collisions anywhere else.
For example, 3B-C6-D1-19-C8-83-35-04-31-6E-B4-37-82-DC-1B-2B refers to not only an audio track on Pac-Man World: 20th Anniversary (USA), but also Pac-Man World: 20th Anniversary (France), and also something called Euro Demo 54.
The question is, what do we really do about that? It'll probably have a nasty performance hit to keep going through every datfile after a match is found to find more matches. As far as displaying it goes I guess the first match would show up in "Datfile game name / Datfile ROM name" / etc and have more columns "Datfile ROM name 2" and whatnot.
Okay, so according to actually profiling the thing like I damn well should have before I said words, hashing the files tends to take longer than identifying them. So maybe it won't hurt that much. DatfileCollection.identify still takes a while though...