ROM Matching
When igir scans ROM files in the input directory, it calculates a number of checksums to uniquely identify each file. These checksums are then matched to ones found in DATs.
By default, igir will use CRC32 + filesize to match input files to ROMs found in DATs. CRC32 checksums are fast to calculate, and many archive formats include them in their directory of files, which greatly speeds up scanning.
Note
The main drawback of CRC32 checksums are their small keyspace of 4.29 billion unique values (see below). This might seem like a lot, but it's sufficiently small enough that it is very possible for two different files to have the same CRC32. Chances of these "collisions" can be reduced by also comparing the filesize of the two different files.
Automatically using other checksum algorithms
Some DAT release groups do not include every checksum for every file. For example, MAME CHDs only include SHA1 checksums and nothing else, not even filesize information.
And some DAT release groups do not include filesize information for every file, preventing a safe use of CRC32. For example, not every Hardware Target Game Database SMDB includes file sizes, but they typically include all the normal checksums.
Success
For situations like these, igir will automatically detect what combination of checksums it needs to calculate for input files to be able to match them to DATs. This has the chance of greatly slowing down file scanning, especially with archives.
For example, if you provide all of these DATs at once with the --dat <path> option:
- No-Intro's Nintendo Game Boy DAT (which includes filesize, CRC32, MD5, and SHA1 information)
- Hardware Target Game Database's Atari Lynx SMBD (which includes CRC32, MD5, SHA1, and SHA256 information but not filesize)
- MAME ListXML (which only includes SHA1 information for CHD "disks")
...then igir will determine that SHA1 is necessary to calculate because not every ROM in every DAT includes CRC32 and filesize information.
Note
When generating a dir2dat with the igir dir2dat command, igir will calculate CRC32, MD5, and SHA1 information for every file. This helps ensure that the generated DAT has the most complete information it can. You can additionally add SHA256 information with the option igir [commands..] [options] --input-min-checksum SHA256 (below).
Manually using other checksum algorithms
Danger
Most people do not need to calculate checksums above CRC32. CRC32 + filesize is sufficient to match ROMs and test written files in the gross majority of cases. The below information is for people that truly know they need higher checksums.
You can specify higher checksum algorithms with the --input-min-checksum <algorithm> option like this:
igir [commands..] [options] --input-min-checksum MD5
igir [commands..] [options] --input-min-checksum SHA1
igir [commands..] [options] --input-min-checksum SHA256
This option defines the minimum checksum that will be used based on digest size (below). If not every ROM in every DAT provides the checksum you specify, igir may automatically calculate and match files based on a higher checksum (see above).
The reason you might want to do this is to have a higher confidence that found files exactly match ROMs in DATs. Just keep in mind that explicitly enabling non-CRC32 checksums will greatly slow down scanning of files within archives.
Here is a table that shows the keyspace for each checksum algorithm, where the higher number of bits reduces the chances of collisions:
| Algorithm | Digest size | Unique values | Example value |
|---|---|---|---|
| CRC32 | 32 bits | 2^32 = 4.29 billion | 30a184a7 |
| MD5 | 128 bits | 2^128 = 340.28 undecillion | 52bb8f12b27cebd672b1fd8a06145b1c |
| SHA1 | 160 bits | 2^160 = 1.46 quindecillion | 666d29a15d92f62750dd665a06ce01fbd09eb98a |
| SHA256 | 256 bits | 2^256 = 115.79 quattuorvigintillion | 1934e26cf69aa49978baac893ad5a890af35bdfb2c7a9393745f14dc89459137 |
When files are tested after being written, igir will use the highest checksum available from the scanned file to check the written file. This lets you have equal confidence that a file was written correctly as well as matched correctly.