Project, API and platform documentation checked through 2026-07-11. Stack and workflow details describe the repository snapshot reviewed for this post; live service behaviour, regional catalogue results and platform terms can change.

Saturday was the Deftones at the Westfalenhalle in Dortmund. One of those concerts where the setlist is part of the experience — where you register, with something close to physical relief, that the arc landed exactly right, and you spend the Uber home mentally replaying the order.

Sunday I built a playlist from it. It took about forty minutes.

This is the post about why that number is already too low, and also possibly too high.

The Ritual

There is a specific kind of concert listening that happens in the days after a show. You go home, you look up the setlist — setlist.fm is the canonical archive, maintained with an almost academic precision by people who care — and you build a playlist from it in whatever streaming app you use. Then you play it through, in order, and what comes back is not just the music but the spatial memory of the room, the sound mix, the moment the lights dropped for that particular song.

I have been doing this for years. It is a ritual, and like most rituals, part of its meaning is in the doing. The forty minutes of searching song by song, the occasional discovery that a deep cut is on Apple Music in one version but not another, the fiddling with live versus studio — that friction is not purely annoying. It is part of the processing.

And yet. The pile of unprocessed setlists sits in a folder. Shows I attended and never got around to. Setlists I meant to build into playlists and didn’t, because the forty minutes were not available that week, and then the moment passed. The ritual unrealised is just a list of song titles.

This is the dilemma, and it is not entirely trivial.

Why This Is Harder Than It Should Be

The setlist.fm API 1.0 returns structured set, song, artist, venue and version data. It is wiki-derived and mutable, requires an API key, and its documented free use is limited to non-commercial projects. It does not supply Apple Music catalogue identifiers, whose availability and versions vary by storefront.

Matching a title to the intended recording is ambiguous: covers, editions, punctuation and regional catalogues matter. The article did not benchmark a corpus, so it makes no claim about how often a title matches correctly.

The relative size and permissiveness of Spotify and Apple tool ecosystems was not measured here. Apple documents MusicKit user authorisation, catalogue search, playlist creation and developer tokens signed with a Media Services private key; those requirements shaped this implementation.

This is partly why I built Showtape (originally published as setlist-to-playlist and since renamed) as a web app rather than reaching for an existing tool.

How It Works

The app is a web application you can open on your phone in the taxi home from a show. It ships a web manifest, but the README states that it needs network access and has no service worker or offline mode, so it is not an offline-capable PWA. It is built on Next.js in a pnpm workspace (no Turbo). The architecture is in three phases:

Import. You paste a setlist.fm URL or ID. The app queries setlist.fm through a server-side proxy — the API key lives on the server and never touches the client — and returns the structured setlist data: songs in order, with metadata about covers, medleys, and notes.

Preview and matching. The core package runs a matching algorithm against the Apple Music catalog, using the MusicKit JS API for browser-based catalog search. For each song title, it searches Apple Music and presents the best candidate, giving you the chance to confirm or swap before anything is written. This is the step where the ambiguity problem is addressed manually — the app handles the obvious cases automatically and surfaces the ambiguous ones for human judgement.

Export. Once you are happy with the track list, the app creates a playlist in your Apple Music library. MusicKit handles the authentication in-browser; the backend generates the JWT tokens using credentials from Apple Developer, signing with the private key server-side so it stays off the client.

The design aims to minimise application-side retention: user authorisation occurs through MusicKit, while the server proxies setlist.fm requests and signs developer tokens. “No stored data” also depends on hosting logs, telemetry, caches and Apple/setlist.fm processing; no live deployment was audited in this review.

The Actual Experience

After the Deftones show: opened the app on the phone, pasted the setlist.fm URL, had the playlist in Apple Music in about four minutes. Three tracks needed manual confirmation — two because of live-versus-studio ambiguity, one because a cover required a search adjustment, the kind of edge case where the name setlist.fm records differs from what appears in regional streaming catalogs.

Four minutes instead of forty in this one personal run—not a benchmark or a guarantee for another setlist, storefront or network.

And yet.

I noticed, processing the setlist that quickly, that something was missing. Not the music — the music was all there, in order, correct. What was missing was the time spent inside the setlist. The forty minutes of handling each song is also forty minutes of thinking about each song, of remembering where in the set it fell, of deciding which album version you want to hear. The automation removed the friction and also removed the processing.

I am not sure this is a problem. It is probably more accurate to say that it is a trade-off, and that what trade-off you want depends on what you are doing with the ritual. If the backlog is the problem — the pile of unprocessed shows — the automation solves it cleanly. If the processing itself is the point, you probably should not automate it, and the tool is there for when you want it.

That is the correct relationship to automation, I think. Not “this should always be automated” or “this should never be automated”, but “here is a tool that removes the mechanical part; use it when the mechanical part is not the point”.

A Note on the Tech Stack

The current repository (checked 2026-10-03) uses Next.js 16, a pnpm 9 workspace with core, api, shared and ui packages, MusicKit JS, setlist.fm API 1.0 and jose token signing. The core package separates matching logic for tests and possible reuse. These are repository claims; the app was not installed or executed during this editorial review.

The repo is at github.com/sebastianspicker/showtape, and a static, simulated click-through demo shows the workflow without calling setlist.fm or Apple Music. PRs welcome, particularly around the matching heuristics — that is the part where there is the most room for improvement.

The Deftones were exceptional, for the record. The Westfalenhalle was loud in the way that only a concrete hall that size can be loud, which is to say: correctly loud.

The playlist is good. I am glad it took four minutes and not forty.

I am also glad I know what I gave up.

Changelog

  • 2026-07-11: Removed an unmeasured 80/20 matching rate and platform- ecosystem comparison; dated the stack; added setlist.fm usage limits and qualified privacy, retention and four-minute workflow claims.
  • 2026-10-03: Removed the leftover “20% problem” and “former 80/20 split” wording that still referred to the matching rate deleted on 2026-07-11. Refreshed the project description against the current repository: it is now Showtape (renamed from setlist-to-playlist), runs on Next.js 16 in a pnpm workspace without Turbo, and has a web manifest but no service worker or offline mode, so it is no longer called a PWA; added the link to the static demo.