Preservation-Grade Game Images: Dumps, Hashes, DATs, and Disc Formats Explained

Video game preservation means retaining enough authentic material and context for a work to be studied, identified, and—where lawful—experienced in the future. The binary is central, but it is not the whole record. Original media, dumping logs, serials, revisions, region, hashes, manuals, boxes, labels, PCB photographs, mastering information, and the tools used to read the medium can all explain what a file actually represents.

Preservation is not the same thing as emulation. Emulation recreates behavior of hardware or software so preserved code can run. Distribution is the act of transferring copies. Piracy is unauthorized copying or distribution that infringes applicable rights. A person can document and verify a dump without publishing it; an emulator can be lawful while a particular source of game files is not. This article explains archival technique, not how to obtain copyrighted games from third parties.

No-Intro catalogs cartridge and similar ROM-based releases through DAT-o-MATIC. Its records connect release metadata with hashes and dump evidence. A verified entry generally reflects independent trusted dumping evidence rather than a filename that happens to look plausible.

Redump concentrates on optical media and the complications that discs introduce: multiple tracks, audio, sector layouts, drive offsets, ring codes, copy protection, and platform-specific dumping procedures. Contributors submit metadata and logs; verification means another compliant read agrees, not that Redump distributes the copyrighted disc image.

The useful generalization is “No-Intro for cartridges, Redump for discs,” but always follow the current system-specific guide. Some platforms use encryption, headers, special drives, keys, or nonstandard areas that make a generic copy command insufficient.

Hashes identify bytes, not quality by themselves

A hash turns a byte sequence into a compact fingerprint. If two independently produced files have the same strong digest, they almost certainly contain the same bytes. That does not prove those bytes were acquired correctly; two people can hash the same bad source.

CRC32 is fast and good at detecting accidental transfer or storage errors. It is not collision-resistant and must not be treated as a security signature.
MD5 remains useful for matching historical preservation databases, but deliberate collisions are practical. It is not suitable for authenticity or adversarial integrity.
SHA-1 is also common in legacy DATs and is stronger than CRC32 for accidental identification, but its collision resistance is broken. Do not design a new trust system around it.
A modern archive can additionally record SHA-256 while retaining the legacy hashes needed to compare with established catalogs.

Compute hashes on the exact canonical object the project specifies. Removing a copier header, combining tracks, converting byte order, decrypting content, or scrubbing padding changes the digest even when an emulator still launches the game.

DAT files are machine-readable catalogs

A DAT file describes expected names, sizes, hashes, regions, revisions, and sometimes status or parent relationships. ROM managers compare a local collection against that reference and can report missing, unknown, or mismatched files. A DAT is not the game data and should not be confused with an archive download list. Preserve the DAT version and date used for an audit because catalogs improve as new evidence arrives.

Good, bad, modified, over-, and underdumps

A good dump is a repeatable acquisition matching the accepted method and evidence. A bad dump has known acquisition errors or does not match trusted verification. A corrupt dump may have changed later through media failure, transfer, or storage damage. A modified dump contains an intentional patch, translation, trainer, crack, or other alteration; it may be valuable, but it is not a pristine retail dump.

An overdump contains bytes beyond the logical capacity or repeated/mirrored data caused by an incorrect read size. An underdump stops early and omits expected bytes. Headered and headerless cartridge images can both be internally consistent, yet only one may be canonical for a particular DAT. Preserve the raw acquisition plus a documented normalized derivative rather than silently replacing one with the other.

ROM images and disc images

A cartridge ROM is usually a comparatively simple addressable byte array, sometimes with a copier header or platform-specific byte order. Optical media contain sectors and tracks. A disc may mix data with CD audio, include pregaps, subchannel information, error-correction bytes, unusual sector modes, or deliberately malformed structures used by copy protection. A filesystem-only ISO can therefore be an incomplete representation of a physical CD.

Cartridge extensions and byte order

.nes commonly uses the iNES/NES 2.0 container: a header describes mapper and memory properties before PRG/CHR data. The header is metadata required by many emulators, not bytes from the cartridge ROM itself.
.sfc and .smc are used for Super Nintendo images. .smc historically often indicates a copier header, but extensions are not proof; inspect size and header evidence.
.gb, .gbc, and .gba conventionally map to Game Boy, Game Boy Color, and Game Boy Advance images.
.n64, .z64, and .v64 often identify different Nintendo 64 byte orders. Conversion can be lossless when the source is valid, but hashes differ between orderings.
.md, .gen, and .bin are common for Mega Drive/Genesis data. .bin is generic and cannot identify a platform without context.

Other cartridge ecosystems use extensions such as .a26, .pce, .gg, .sms, .ws, or .wsc; again, an extension is a convention, not validation.

Optical-disc and container formats

.iso usually represents one data track or filesystem-oriented sector stream. It is appropriate for many DVD/data-disc cases but may omit CD audio tracks, subchannels, or raw sector details.
.cue plus one or more .bin files describes track order, types, indexes, and binary track data. For mixed-mode CDs, the cue sheet is essential; keeping only the largest BIN can discard audio.
.ccd, .img, and .sub form CloneCD-style sets: control metadata, main-channel sectors, and subchannel data. Separating the files makes losing one component easy.
.chd is MAME’s Compressed Hunks of Data container. chdman can create, verify, extract, and inspect media images. CD-oriented compression can preserve audio and subchannel data represented by the source while saving space. Verification still depends on starting from a faithful image and retaining conversion logs.
.gdi describes Dreamcast GD-ROM track layout. .cdi is a DiscJuggler image often seen in Dreamcast workflows, but self-boot conversions or layout changes may make a CDI unsuitable as the archival master.
.rvz and .wia are Dolphin formats for GameCube/Wii images. RVZ is designed for lossless compression and real-time use and can convert back to a verifiable ISO when created without destructive scrubbing. Compatibility depends on sufficiently recent Dolphin versions.
.wbfs is a Wii-focused format historically used to remove unused disc areas. Dolphin documents WBFS as lossy; keep a verified lossless master rather than treating WBFS as preservation-grade.
.xiso commonly describes an Xbox game-partition image, not necessarily a raw image of every sector on the original disc. Record how it was produced and which preservation target it satisfies.

Formats such as .mdf/.mds, .nrg, .cso, .gcz, .nkit, or compressed archives may be useful derivatives. Their suitability depends on whether conversion is reversible and whether the original medium’s relevant structures survive.

Raw, compressed, container, and emulation-optimized are not synonyms

A raw image tries to retain the medium’s sector representation. A container records data plus structure or metadata. Lossless compression reduces storage while permitting exact reconstruction of the defined input. A format optimized for emulation may rearrange, decrypt, or omit data for fast access. “The game boots” is therefore a functional test, not proof of archival fidelity.

Ask specifically whether conversion preserves data tracks, CD audio, pregaps, subchannels, raw sector headers, error-correction bytes, encrypted partitions, update partitions, mastering anomalies, and protection-relevant information. No single format preserves information that the dumping process never captured.

A defensible preservation workflow

Clean and photograph the physical item; record labels, serials, revision marks, region, and condition.
Use the current platform-specific No-Intro or Redump guide and a supported dumper/drive.
Keep acquisition logs and tool/firmware versions. Dump more than once where the guide requires it.
Hash the canonical raw outputs and compare them with the appropriate, dated DAT or database record.
Store the raw verified master read-only. Create emulation-friendly derivatives separately and document every conversion.
Keep at least three copies on two media types with one geographically separate; periodically verify modern hashes and media readability.
Preserve manuals and artwork at documented scan settings, but retain physical originals when possible.

Legal and ethical limits

Copyright exceptions, private-copy rules, anti-circumvention law, and library exemptions vary by jurisdiction. Ownership of a cartridge does not automatically grant permission to upload its contents. Do not distribute copyrighted dumps or bypass access controls without a lawful basis. Preservation organizations should document provenance, access policy, retention, and takedown procedures and obtain legal advice appropriate to their location and role.

Sources: No-Intro DAT-o-MATIC guide, Redump getting started guide, MAME chdman documentation, Dolphin’s RVZ format report, Dolphin FAQ on supported dump formats

No-Intro and Redump solve related but different problems