Building a digital music collection you will still have in twenty years

A digital music collection is not a folder. It is four separate practices that happen to share a disk.

Acquisition is how files arrive and what state they arrive in. Standards are the handful of decisions you make once and then stop relitigating. Maintenance is the small continuous work that keeps entropy out. Succession is the part almost nobody writes about: whether the collection is legible to anyone other than you, including future you.

Twenty years is long enough for the software to change, the hardware to fail, the shops to close and the formats to fall in and out of fashion. The only part of the arrangement you actually control is the files and what you know about them, so the whole practice reduces to one instruction: keep an open, lossless master with its metadata inside it, in more than one place, and be able to prove it is still the same as it was.

Everything below is that sentence, expanded.

What a twenty-year collection is made of

The master

One lossless copy per release, in an open format Ripped or bought once, verified where verification was possible, and never edited again except to correct its metadata. This is the irreplaceable object; everything else is derived from it.

Tags and artwork written into the files themselves

The description

Metadata that travels with the audio Album artist, album, track and disc numbers, date, artwork — inside the file, not in a player database. A tag survives changing software; a database row does not.

Indexed, played, browsed — and never written to

The working library

What you actually use, and any convenience copies A player pointed at the masters, plus disposable lossy versions for phones and cars. Nothing here is precious: it is either the master itself or something regenerable from it.

Copied, on a schedule, without you thinking about it

The copies

Three in total, two kinds of device, one off-site Plus a checksum manifest, so a copy can be proved good rather than assumed good. A restore you have never tested is a hypothesis.

Every few years, deliberately

The migration

New media, new machine, sometimes a new tool Storage is replaced on age rather than on failure, and the collection moves as one thing because it lives in one place and depends on nothing proprietary.

The direction of dependency is the whole design. The master depends on nothing. The library depends on the master. The copies depend on the library. Nothing depends on a particular player, a particular company or a particular disk — which is precisely why any of them can be replaced without the collection noticing.

What actually threatens a collection over twenty years

Not the things people plan for. A collector who has been at this a while has usually survived a dead drive; almost nobody has a plan for the other five.

Threat	What it looks like	The practice that answers it
Hardware failure	A drive stops mounting	Backups, on a schedule, tested
Silent corruption	A file still plays but a few seconds are wrong	Checksums, verified periodically
Software death	The player you organised everything in is discontinued	Metadata in the files; no proprietary library format
Format drift	Half the collection is in something nothing reads comfortably	One open lossless master format, applied consistently
Entropy	Four copies of an album, six spellings of an artist, an inbox folder with 1,400 files	Standards decided once, and ten minutes a month
Loss of context	You no longer know which pressing this is or where it came from	Provenance, written down at the point of acquisition
Succession	It is all still there and nobody else can make sense of it	Documentation, in plain text, next to the collection

The middle three are the ones that get collections. They are slow, they produce no alert, and by the time they are obvious the work to reverse them is measured in weekends.

Acquisition: get it right once, at the point of entry

Every durability problem is cheapest to solve at the moment a file arrives, and most expensive to solve in bulk three years later.

Buy files you are allowed to keep. A download you hold is a different kind of object from a licence to stream, and the distinction only becomes obvious on the day the licence changes. That is not an argument against streaming, which is genuinely better at discovery and at breadth; it is an argument for knowing which of the two things you are doing at any given moment — what each of them actually gets you, including the ten-year cost of both is a comparison worth doing once, honestly, before you commit to either.

Rip your own discs properly, once. Verification, correct metadata and lossless output at rip time cost seconds each; fixing them afterwards costs the whole job again. A CD you already own is also the one source of high-quality files that no shop can withdraw.

Keep the master, discard the packaging. The archival copy is the lossless audio plus its tags and artwork. The delivered ZIP is worth keeping only if it contains something the master does not — a booklet, a different mastering, a higher bit depth than you extracted. Keeping every original download “just in case” is how people end up with a second unindexed collection.

Record where it came from while you still know. Not for everything — for the things that will otherwise become mysteries. A bootleg, a vinyl rip, a Bandcamp-only release, a disc that failed verification and was accepted anyway. One line in a plain text file next to the album is enough, and it is the only form of provenance that is guaranteed to still be readable in twenty years.

Standards: decide four things once

The point of a standard is not that it is optimal. It is that it removes a decision from every future import, and a decision you make forty thousand times will not be made consistently.

One archive format. Lossless, open, well implemented: FLAC unless your working life runs through Apple’s own applications, in which case ALAC. Both decode to identical audio, so the choice is about tooling rather than sound. The Library of Congress’s personal-archiving guidance for audio says to save recordings in an open format precisely because it gives “the greatest flexibility for future use”, and that is the durability argument in one line.

One folder shape. Artist/Album (Year)/01 - Track.flac, keyed on the album artist. It is not the best imaginable structure; it is the one every ripper, tagger and player already assumes, and deviating costs you every time you introduce a new tool.

One set of tagging rules. Which fields you fill, how you spell an artist, and what you do with compilations. Tags belong in the files: embedded metadata is what survives changing software, and a rating held only in a player database is a rating you will lose.

One canonical location. Everything else is either a backup or garbage. There is no third category, and pretending otherwise is how a collection becomes four partial collections.

Four decisions. Write them down somewhere you will find them, because the failure mode is not disagreeing with your past self — it is not remembering what your past self decided.

Masters and convenience copies are different objects

This is the distinction that makes everything else tractable, and it is the one most collections never make explicitly.

The master is the lossless file. It is irreplaceable, it is what gets backed up, and it is never modified except to correct its metadata.

A convenience copy is a lossy version made from the master for a phone, a car or a cycling computer. It is regenerable in an afternoon, it does not need a backup, and it should live in its own tree so that nothing ever confuses the two.

Two rules follow, and both are load-bearing:

• Derive downward, never upward. A lossy file re-encoded to FLAC is a large file containing exactly the damaged audio the lossy file already contained — nothing is recovered, and the loss is permanent.
• Never let a convenience copy become the only copy. The commonest way this happens is a phone sync that ran the wrong direction, or a “space saving” clean-up that kept the smaller file.

If you can answer “which of these two files would I be upset to lose?” instantly for every file in the collection, this part is working.

Maintenance: the continuous half

Standards stop entropy arriving. Maintenance removes what got in anyway.

The monthly version is small and genuinely sufficient: empty the inbox folder, look for missing artwork, look for unknown artist and unknown album, look for duplicates, and confirm the backup ran. Ten minutes a month keeps a 50,000-track library from ever needing a rebuild.

The annual version is the one that matters for a twenty-year horizon, and it is the Library of Congress’s advice almost verbatim: check your recordings at least once a year to confirm you can still read them, and create new media copies every five years or when necessary to avoid data loss. Storage is consumable. Planning to replace it on a schedule is much cheaper than discovering the schedule the hard way.

Integrity: proving a copy is still good

A file can be damaged in a way that no part of a backup scheme notices, because a backup copies whatever is there. Bit rot, a bad cable, a marginal drive — and the damage propagates to every copy at the next run.

The defence is fixity: a record of what each file’s contents hashed to when you knew it was good, re-checked periodically. Two levels of it are available without buying anything:

• Per file, for free, if you chose FLAC. The FLAC specification puts an MD5 checksum of the unencoded audio in every file’s STREAMINFO block, specifically so that a decoder can determine an error exists in the audio “even when, despite the error, the bitstream itself is valid”. Any FLAC tool can test this. An uncompressed WAV cannot tell you anything of the kind.
• Across the collection, a checksum manifest: a list of every file and a hash of its contents, generated once and re-verified on a schedule. When a hash stops matching, you know which file changed without you changing it, and you know to restore that one from a version predating the damage.

Where those copies live, and how to test a restore, is the other half of this and has its own article. The part to internalise here is the distinction: a backup answers “is there another copy?”, fixity answers “is the copy still the same thing?”, and only one of them is checked by the backup software’s green tick.

Migration: assume every tool you use will be replaced

Over twenty years you will change machine several times, change storage several times, and change music software at least once. A collection that survives that is one where the changes are boring.

Depend on the filesystem, not on an application. If the audio files, the tags and the artwork are complete on disk, any player can be pointed at them and will work. If the artist spellings live in one program’s database, migrating means exporting, mapping and reimporting — and something is always lost.

Prefer formats other things read. This is the same argument as the archive format, applied to everything else: playlists as M3U8 with relative paths rather than a proprietary container, artwork as ordinary JPEGs, notes as plain text.

Move the collection as one object. This is the practical payoff of the single canonical location: a migration is a copy operation and a verification, not an archaeology project.

Test the exit before you need it. Point a second, different player at your library for an afternoon. What it fails to display is precisely what you have stored somewhere it cannot see.

Succession: the practice nobody writes about

A collection that only you can navigate is a collection with a fixed lifespan.

This is not only about inheritance, though it is about that too. It is also about you in fifteen years, opening a drive you have not touched since the last migration, with no memory of what the _vinyl-2019 folder was for or why one album has two versions.

The whole practice is one plain-text file, kept with the collection and updated when something changes:

• What this is, and where the canonical copy lives.
• How it is organised — the four decisions above, in a paragraph.
• Where the backups are, which software makes them, and what a full restore would involve, in order.
• Anything unusual — the albums with a story, the rips that were imperfect, the material that exists nowhere else.
• Any passphrase somebody would need, and where it is kept. Not in the file.

It takes twenty minutes. It is the difference between a collection and several terabytes of files somebody eventually deletes because nobody could tell what they were.

Where a player fits

Very little of the above is a software problem, which is worth saying plainly on a website that makes software.

A player’s job in a twenty-year collection is to be a good lens and a bad dependency: to read your files without changing them, to keep its own data disposable, and to be easy to leave. Digr’s design follows that fairly literally — the scanner opens audio files to read tags and artwork and never writes to them, the SQLite index is a cache that a rescan rebuilds exactly, and there is no account, so there is nothing to lose access to. Deleting it costs you an index, not a library.

That is the property to look for in any player you commit a collection to, and it is testable in about a minute: find out where its database lives, delete it, and see whether your music is still there.

The version that fits on a card

• One lossless master per release, in an open format, with tags inside the files.
• One canonical location. Everything else is a backup or garbage.
• Three copies, two kinds of device, one off-site, and a restore tested once a year.
• Checksums, generated when the library is good and re-verified on a schedule.
• Convenience copies derived downward and treated as disposable.
• Provenance for anything unusual, written at the point of acquisition.
• One plain-text document that would let somebody else — including you in fifteen years — understand the whole arrangement.

None of it is difficult. All of it is much easier to start than to retrofit, which is the only real argument for doing it now.

Sources

• Library of Congress — Personal Archiving: Audio — save recordings in an open format; at least two copies stored in locations as physically far apart as practical; check recordings at least once a year; create new media copies every five years
• RFC 9639 §8.2 — the FLAC STREAMINFO block — the MD5 checksum of the unencoded audio, and its stated purpose of detecting an error in the audio even where the bitstream is valid
• The 3-2-1 backup rule — the rule’s formulation, and its origin in Peter Krogh’s The DAM Book
• Digr — features and roadmap — files opened read-only, the SQLite index as a derived cache, and no account