Doomulation said:
I understand THAT.
But generally, what I don't understand is how to calculate the code.
And about the DLL, it can call c/c++ dlls. Just needn't do much trouble like saying FileP for argument of something that can do as a long...
icepir8 said:Hacktarux:
Great Idea. who is going to build the list of MD5s for good roms?
Yeah, well, I was wondering 'cuz there was no explanation.rob in london said:doomulation i think you need to buffer it instead of calling it with the filename, as unless you byte-swap it so they're all in the same file format, the same rom will generate different codes depending on how the data is arranged
I've also thought about caching it, though, it still takes forever to load. And that must be changed.StrmnNrmn said:Calculating an nd5 digest of each rom seems like an excellent method or verifying good and bad dumps to me. True, it's slow (especially over a full set of roms), but you can be quite clever and cache the results in a database, so you only need to calculate the results once (or until the rom changes on disk).
Doomulation said:
I've also thought about caching it, though, it still takes forever to load. And that must be changed.
Just loading an application and you have wait hours before you can use it? No thanks.
Hacktarux: I did it all with your tool. And yoshi's story was (J) [!], which means a good dump.
Actually, dave gave me a c++-compiled DLL of which can perform the same thing to compare the whole file in a speed of about 40 roms in 2 seconds when unzipped.StrmnNrmn said:Why can't you just calculate the md5 digest when you need it - i.e. when the user starts to run the rom? The interface could just show "n/a" for roms that had not been checked. You could then add an option to scan all roms ("Warning, this operation may take several minutes"..), or check them using a lower-priority thread in the background.
But really, if you want to know for sure whether a rom is a good or bad dump, I don't see any option but performing a hash of every single byte of the file. What's going to take the time is the reading from disk (and decompression if zipped) - not the choice of hash function (md5, crc64 or whatever).
Dave reported this. I haven't tested myself. Ask dave.Hacktarux said:I need some explanation about your dll ! For me such performances are impossible.
proof:
to execute a hash algorithm whatever it is and how much you optimize it, it needs to read all the bytes of each roms.
If we consider that each roms have 16 Mb length on average. Then 40 roms * 16 = 640 Mb : nearly the size of a cdrom.
And you say that you read a whole cdrom in 2 seconds !!!!!!!
Congratulation doom, your hard drive is able to burn a cdrom at 1083x
Try to calculate the maximum speed in nero and you'll see that it is impossible....