How to Verify Game Dumps Against a DAT Without Renaming Away the Evidence
A provenance-first ROM audit workflow using hashes and DAT metadata, with immutable originals, header rules, set semantics, tool logs, and exception review.
A preservation DAT describes expected file identities—usually names, sizes, CRC32, SHA-1, and sometimes MD5—within releases or machine sets. Verification should answer whether your lawfully acquired dump’s bytes match a documented entry. Renaming first destroys the distinction between “the bytes matched” and “the filename looked right.”
Freeze originals and record provenance
Copy dumps from the acquisition workstation into a read-only originals directory. Record source hardware, dumping tool and version, date, cartridge/disc markings, any read errors, and hashes calculated before transformations:
sha256sum originals/* > manifest.sha256
find originals -type f -exec chmod a-w {} +
SHA-256 is useful for your manifest even if the target DAT uses CRC32/SHA-1. A DAT match is an identity comparison to that database, not proof that a copyright license permits distribution. Keep the collection private and comply with applicable law.
Obtain the DAT from the preservation project’s official channel and record its filename, release timestamp/version, and hash. DATs change when better dumps, naming, regions, or metadata are discovered. Without DAT identity, “verified” cannot be reproduced later.
Understand normalization rules
Some cartridge formats contain a copier header that preservation databases intentionally exclude; some arcade sets consist of several chips; some disc DATs hash tracks or sectors rather than a container. Do not strip a fixed number of bytes because a forum post says so. Follow the DAT project’s documented format rule and keep any derived normalized file separate with a transformation manifest.
Archives add another layer. Tools may hash members after decompression and then rebuild/rename archives. Preserve the original container if its provenance matters, and decide whether your objective is byte-identical acquisition, normalized content, emulator-ready layout, or a managed set. These are related but different artifacts.
Audit in a disposable working copy
Use a current ROM-management or hash-audit tool that can read the DAT format. Point it at a copy, disable automatic deletion, and begin in report-only mode. Capture tool version, selected DAT, merge mode, and complete log.
Classify outcomes explicitly:
- matched: size and strong hash correspond to an expected entry;
- missing: DAT expects content absent from the working set;
- unknown: content hash has no entry in this DAT;
- bad/partial: size/hash or set members disagree;
- duplicate: identical bytes appear more than once;
- name-only mismatch: bytes match but the current name differs.
Only after a strong-hash match should the tool rename or rebuild a working set. Keep a mapping from original path/hash to normalized name. Never let a filename match override a hash mismatch, and never delete “unknown” files automatically; they may be bad dumps, personal data, a different revision, or material awaiting research.
Arcade parent/clone and split/merged/non-merged modes change which member files are expected in each archive. Select the mode required by the emulator and document it. A correct non-merged set can look redundant under a merged-set assumption.
Independently verify the result
Re-run the audit from a fresh work directory and confirm zero unexplained missing, bad, or unknown entries within the declared scope. Manually hash a sample and compare it to the DAT XML/metadata. Validate a sample in the target emulator, but do not use successful boot as hash proof; emulators often tolerate overdumps or patched content.
Publish only the manifest, process, and lawful metadata—not proprietary images. The durable product is a chain from acquisition hash to DAT version to normalized working name, with every transformation reproducible and the originals untouched.
Related:
- How to Preserve Optical Games with Data, Audio Tracks, and Subchannel Evidence
- Sprite Limits and Scanlines: Why Accurate Emulators Preserve Flicker and Dropout
Sources: