I know that there's been a debate for some time about crc's sometimes not checking out with CMP, but passing with goodtools. Scanning NES games with CMP produces particularly ugly scan results.

From what I understand- isn't this largely to do with headers being artificialy added? I was thinking that maybe CMP could include a feature whereby it removes the headers so that the ROM is in its purest form, and thereby passes both good & CMP auditing.

I know that there are other header tools out there anyway, but I think integrating it into CMP would be especially practical- allowing the roms to be 'fixed' during scanning.

I alao feel it's important for the two auditing mechanisms (good & ClrMame) to agree as much as possible as to what a 'good rom' actually is, purely for credibility, I guess.

Is this possible/ likely to happen?

Thanks for reading!

> From what I understand- isn't this largely to do with headers being artificialy
> added?

I usually get all crc32 values directly from the goodutilities binary via a hidden export function. So the crc32 values in the dats are 100% identical to the ones in the goodtools. Goodtools have a lot (and I mean A LOT) code to detect various headers in files. They skip the header data and calculate the crc32 of the rest. That's the difference to CMPro which takes the full file. So basically you have to remove headers from the files if they should be recognized by ClrMamePro. Another thing is handling of [b*] dumps. A lot of such baddumps are padded with 0x00 or truncated to some 2^x-limit and the crc32 is calculated over that new area...so these roms are usually difficult to get the right crc32 if you do it manually.
Now the exceptions: Some sets (e.g. NES) require the header information to work correctly. But the imported crc32 is still for the headerless data. That's why some dats were created on existing collections and not on a direct database import. You need to find the exact files then...


> I was thinking that maybe CMP could include a feature whereby it removes
> the headers so that the ROM is in its purest form, and thereby passes both good
> & CMP auditing.

This won't happen. As I mentioned, Cowering did a lot brainstorming and got thousand of codelines for headerdetection for the different systems. It's not just a simply 10 line detect header routine. And it's not that easy to add to the current ClrMamePro core.

If you want to check "Good" collections, use the goodtools...or manually (or use a different tool) to remove the headers.

Roman Scherzer
ClrMamePro

Thanks for the reply Roman- just noticed this feature in the new GoodSnes 2.04:

"Option "convert" will now deinterleave and strip the header from EVERY ROM in the database"

If this were applied to the next GoodNES tool- and activated- would it meet CMP's scanning criteria and give good crc's?

> If this were applied to the next GoodNES tool- and activated- would it meet
> CMP's scanning criteria and give good crc's?

since cowering forgot to add the database export function in his latest goodsnes, I'm not able to do a dat....
but his converting routines will definetly help to match the checksums...

Roman Scherzer
ClrMamePro