CHD Explained: Lossless Compression, Parent Images, Metadata, and Verification

MAME’s Compressed Hunks of Data (CHD) format stores block-oriented media such as hard disks and optical discs with lossless compression, checksums, and metadata. A CHD can reduce storage and provide internal integrity checks without changing the logical media presented to an emulator. It does not certify that the original acquisition was accurate or lawful; provenance begins before conversion.

Hunks separate logical data from compressed storage

CHD divides the logical image into fixed-size hunks. Each hunk can be compressed with an appropriate lossless codec, stored uncompressed, represented as repeated data, or referenced from a parent where the format/version permits. The header records logical size, hunk geometry, version information, and cryptographic hashes used by tools to identify content.

Compression ratio depends on media. Empty hard-disk regions compress well; already compressed video or random encrypted data may not. Converting to CHD must preserve every logical byte and required track/property metadata, not merely produce a smaller file that one game boots.

For optical discs, data and audio tracks, pregaps, indexes, and track modes matter. chdman createcd consumes a supported descriptor such as CUE/GDI/TOC and associated track data. A single cooked ISO can already have discarded subchannel or raw-sector information, which CHD cannot recreate.

Parent-child images reduce duplication with dependency

A differential CHD can reference a parent and store only changed hunks. This is useful for writable emulator disks or related images, but the child is not standalone. The correct parent hash and content must remain available. Moving one file without its dependency or attaching the wrong parent produces failure or, worse, misunderstood state.

Document the chain, keep parents immutable, and periodically flatten critical writable state into a verified standalone image. A parent-child hierarchy is storage deduplication, not backup versioning by itself.

Create and verify reproducibly

Keep the original dump and descriptor read-only with hashes. Use the chdman shipped with the emulator release that will consume the output and capture its version:

chdman createcd -i game.cue -o game.chd
chdman info -i game.chd
chdman verify -i game.chd

For a hard disk, use the matching createhd workflow and supply geometry only from authoritative metadata. Guessing cylinders/heads/sectors can change what guest software sees even when byte count matches.

chdman verify recomputes internal content hashes and detects storage corruption. Also hash the CHD file for transport, record source hashes, command line, tool version, metadata, and output logical hash in a manifest. Internal verification proves the CHD decodes consistently; comparison to a preservation database addresses source identity.

Round-trip extraction is a strong test. Extract to the appropriate raw/descriptor representation and compare logical data and track layout with the original using format-aware tools. File-byte equality is not always expected for regenerated descriptors, so define which sectors, audio samples, and metadata must match.

Treat format versions as operational state

Modern MAME tools may read older CHDs and can convert them, while older emulators may not read newer versions or codecs. Do not mass-upgrade the only copy. Convert into a new file, verify, test on target emulator versions, then update the manifest. Retain originals until recovery is demonstrated.

CHD is valuable because it combines lossless representation, compression, identity, and media metadata. Preservation quality still depends on the dump, descriptor, parent chain, tool version, and a round-trip verification process outside the fact that the .chd opens.

Related:

Sources:

Hunks separate logical data from compressed storage

Parent-child images reduce duplication with dependency

Create and verify reproducibly

Treat format versions as operational state

Comments