> 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