How to Organize a ROM Collection with Proper Metadata and Artwork

A clean filename and attractive cover do not prove that a game image is complete, correctly dumped, or even the intended revision. Organization should improve usability without destroying preservation evidence.

Keep immutable masters, derive a separate play collection, identify files by hashes and documented media attributes, and treat every scraper result as a proposal that requires review.

Step 1: define the legal and preservation boundary

Inventory only content you are authorized to possess under applicable law: personal dumps, licensed downloads, freely redistributable homebrew, or other clearly permitted material. Record source, acquisition/dump date, hardware/tool version, license where relevant, and original filename.

Do not use “complete set” torrents, preloaded drives, firmware packs, or scraper sites as content sources. No-Intro and Redump publish identification metadata; their databases are not authorization to download the copyrighted files they describe.

Step 2: isolate preservation masters

Place the original dumps in a read-only master tree. Generate a manifest with relative path, byte size, system, media type, region, revision, language, dump provenance, and multiple hashes supported by the reference data. Store the manifest separately and back it up.

Never normalize, patch, recompress, trim, header-edit, or rename the only copy. Perform all frontend-facing work on a derived play tree. A transformation should produce a new file while the master and its identity remain recoverable.

Step 3: hash with a reproducible tool

Use a maintained hashing utility available on the platform and capture its version. Hash files individually rather than trusting an archive filename. For a multi-track disc, preserve the descriptor and every referenced track; one hash of a directory listing cannot validate their byte content.

sha256sum "path/to/file" >> collection-sha256.txt

SHA-256 is useful for the local integrity manifest, but external catalogs may identify content by CRC32, MD5, SHA-1, disc serial, or system-specific rules. Compute the exact field the authoritative reference requires; do not relabel one algorithm’s output as another.

Step 4: compare against the correct reference

Use No-Intro’s official DAT-o-MATIC data and documentation for covered cartridge/digital systems, and Redump’s official database and dumping guides for covered optical media. Select the exact system and a dated database revision.

Match hash plus size and inspect region/revision/status. “Not found” is a question, not proof of corruption: it may be a header variant, translation, homebrew release, newly dumped revision, unsupported format, or bad image. Quarantine it for research rather than deleting or force-renaming it.

Step 5: distinguish verified, transformed, and unknown content

Assign an explicit status in the manifest:

verified master: matches the selected reference and provenance is retained;
verified homebrew/licensed release: validated against its publisher’s hash or signature;
derived play copy: transformation has documented input/output hashes and tool command;
unknown/unverified: preserved separately and excluded from automatic claims;
known bad: retained only when research requires it, clearly labeled and never offered as a good dump.

This prevents artwork and frontend metadata from laundering an uncertain file into an apparently verified title.

Step 6: apply names from evidence, not aesthetics

Use the current reference name for verified play copies if that improves scraper matching, but retain the original filename in the manifest. Region, version, language, disc number, and distinguishing status tags should remain visible when they prevent ambiguity.

Do not bulk-remove parenthetical text or merge similarly titled entries. Two revisions can have different code and compatibility. Case-only renames also need care when the collection moves between case-sensitive and case-insensitive filesystems.

Step 7: build a system-oriented play tree

One directory per platform is practical, although RetroArch does not require a specific layout. Separate firmware, emulator binaries, patches, artwork, saves, and logs from content. Avoid embedding credentials or personal names in paths that will be exported in playlists.

Use stable relative structure where the target frontend supports it. If multiple devices cannot share the same path semantics, generate device-specific playlists from the same manifest instead of manually editing one master playlist back and forth.

Step 8: preserve multi-file and multi-disc relationships

Do not discard cue sheets or merge tracks without system-specific evidence. Validate that every descriptor references the correct filename and track order. For a core that officially supports .m3u, create a text playlist listing each disc descriptor or supported disc image in order, then launch through the .m3u and test disc control.

Keep individual disc hashes and one logical game identifier in the manifest. Hide duplicate disc entries in the frontend only after proving that the .m3u handles native saves and disc switching correctly.

Step 9: convert formats only for a documented target

CHD can be a useful lossless play format for cores that support it, but support and source requirements vary. Use the official MAME chdman documentation and a recorded tool version. Validate the cue/track source first, create a new output, run chdman verify, and retain input/output hashes and the master.

Do not publish a universal compression percentage; audio layout and compression method change the result. Never delete sources until the transformed copy has launched, switched discs where applicable, saved, restored, and been independently verified.

Step 10: import with the strict scanner first

Update RetroArch Core Info Files and Databases through the installation’s supported channel, restart, then scan one system. The official strict scanner uses database CRC or disc serial matching and deliberately rejects unknown content. That rejection is part of validation, not a scanner defect.

Use loose/manual scanning only for identified homebrew, translations, hacks, or other known exceptions. Mark every manual entry in the external manifest. A manual playlist entry is not a checksum validation.

Step 11: audit playlists and core associations

RetroArch .lpl files can include content path, label, core path/name, CRC, and database name. Back up the generated playlist, validate its JSON, and check duplicate paths, duplicate normalized labels, missing files, unexpected system assignments, and broad core associations.

Arcade data sets require particular caution because core family/version compatibility matters. Do not rename an incompatible set or assign a newer core to make the frontend entry look current.

Step 12: scrape metadata as untrusted input

Use a scraper that documents its data providers, authentication handling, rate limits, cache, output format, and licensing. Prefer checksum/serial matches over filename-only guesses. Start with a small sample and review title, platform, region, revision, release date, developer, publisher, rating, and description.

Never run an unknown scraper binary against a writable master collection or give it unrelated filesystem access. Protect API credentials and strip tokens from logs. Cache provider identifiers and retrieval dates so future corrections can be traced.

Step 13: curate artwork without confusing it for evidence

Store box art, title screens, and gameplay snapshots in separate types. Verify that region, revision, orientation, and language match the entry. Record source, license/usage basis, retrieval date, and any crop or resize.

RetroArch thumbnail lookup depends on playlist and entry naming rules. Back up custom images before using the Playlist Thumbnails Updater because official documentation warns it may overwrite custom thumbnails. Artwork quality never changes the verification status of content.

Step 14: detect duplicates by identity and intent

Find exact byte duplicates by hash, then review them rather than deleting automatically. The same file may intentionally appear in separate device trees or archives. Find near-duplicates using reference identity, region, revision, and transformation lineage—not fuzzy filenames alone.

Define the policy explicitly: keep all verified revisions, one preferred regional play copy, translations beside their required base hash, or another documented rule. A “duplicate” is a collection decision only after identity is established.

Step 15: test backup and regeneration

Back up manifests, reference database versions, playlists, scraper cache/IDs, custom artwork, patch files, transformation logs, native saves, and the scripts or documented steps used to generate the play tree. Keep protected game content out of public metadata repositories.

Test restoration into an empty directory. Regenerate one system’s playlist from the manifest and launch samples including an archive, disc title, multi-disc title, manual exception, and two revisions. The collection is organized when every visible entry traces to a known file, every derived file traces to a master, unknown items remain honestly labeled, and the catalog can be rebuilt without guesswork.

Related:

Sources: