Keep a listening history that outlives the service it came from.

Services close. Accounts lapse. Exports go stale the day they are made. Here is what it actually takes to keep years of listening somewhere durable.

What to keep ↓

A listening history is more fragile than it feels.

It rarely disappears all at once. It thins out one failure at a time: changing service, moving platform, stopping a tracking source, relying on a single account, or keeping only a one-off export instead of an ongoing one.

A library transfer and a listening-history transfer are different jobs. Moving playlists or saved music does not by itself preserve a play-by-play record of when you listened. The history of when you actually listened stays behind.

An export solves the moment it is made, then starts going stale immediately. Everything you listen to the day after exporting is not in the file, and most people do not remember to export a second time.

Local files rot quietly too: a CSV on a laptop that gets replaced, a drive that outlives its warranty, a backup nobody has opened in years.

What people do about it today.

None of the following are wrong. Each solves a real, narrower job than the one a durable archive needs to solve.

A one-off library or scrobble export

Where a service or tool offers an export, often as a CSV or an XML file, saving one is the simplest way to keep an independent snapshot of what it holds at that point. It stops recording the moment you download it.

Scrobble-export scripts and tools

Small tools built by other listeners, such as lastfm-to-csv-style utilities, pull a full scrobble history out of Last.fm into rows you can keep. Good for a complete, dated download of everything Last.fm has recorded, run whenever you remember to run it.

ListenBrainz

An open listening-history system that keeps a separate record of your listens, with its own statistics and other tools built on top of that data. A genuinely useful second copy of your listening events, independent of any one streaming service.

A personal spreadsheet or database

Some listeners keep their own table, built from an export or entered by hand, so they can add fields or run their own queries. A spreadsheet update is usually manual; a database can be scripted to update itself. Full control over the shape of the data, built and maintained by hand.

Backing up on a schedule

Downloading a fresh export every few months, and keeping the old ones, turns a single snapshot into a small series: independent points in time instead of one file frozen at one date.

Each of these keeps rows safe. None of them, on its own, keeps what the rows meant.

A backup keeps the events. A listening archive adds context.

A CSV or an export is a backup: it preserves rows, a timestamp, an artist, a track. That much is real, and worth having.

By itself, it does not preserve what any of it meant.

Which album you kept returning to. What rose while something else quietly faded. What stayed constant across years while everything around it changed. None of that is expressed by the row alone. It emerges when the record is read across time, and a static backup does not read itself. Someone, or something, has to keep reading it.

That is not a mark against the backup. It solves the problem it was built for: getting the events out safely. A listening archive solves the next one, turning those events into a record of a listening life, read and re-read as it grows.

What a durable archive actually needs.

Not features. Principles an export alone does not meet.

1. Continuity of capture. Listening has to keep arriving after the day you started caring about keeping it, not stop at the date of the last export.
2. Stable identity across sources. The same album has to stay the same album whether a play came from Last.fm today or an Apple Music export years from now.
3. Dated evidence, never invented. Movement over time is only real if the dates behind it are real. A record with a guessed timestamp is worse than no record at all.
4. Preserved historical states. What a ranking looked like a year ago should still be checkable a year from now, unchanged by anything that happened since.
5. Change over time, not just a total. A total tells you how much. Only a history read across points in time tells you what changed, and when.
6. Portability beyond one source. An archive tied to a single service inherits that service's risk. Keeping history is supposed to remove that dependence, not relocate it.

How Multiplicity keeps it.

Multiplicity turns preserved listening evidence into a living archive, not a static export.

Connect Last.fm and it builds from the scrobble history already there: exact, dated, and still recording afterwards. Spotify, Tidal, Deezer, YouTube Music, Qobuz and local players can all reach Multiplicity through Last.fm. Bring your Apple Music library in too, then keep it growing with native listening capture on iPhone and Mac, no export required for either.

CAИON holds the lifetime ranking. AИNUAL reads the year. ROTATIOИ reads the month. Across them, Albums, Artists and Tracks become a held, dated, source-neutral record, not just a file of rows.

What a kept history becomes.

A durable history is not the destination. It is what makes anything built from it trustworthy, including a ranking that holds its position because the evidence behind it is real.

See what a kept history becomes. Or capture new Apple Music listening on iPhone and Mac.

Free to build. Private by default. No card required.