Chapter 15 — Shipping It
The album renders. The stems null. There’s a folder on your drive that sounds like a record. The last mile — getting it onto the platforms where music lives — is the least technical chapter in this book and the one where code-first production quietly hands you a few last advantages. It’s also where expectations need calibrating, so let’s do both.
Prepare the release like a build artifact
Treat “the release” as one more deterministic output: a folder your script assembles, complete and self-describing.
Audio. Distributors want WAV or FLAC, 16-bit/44.1 kHz minimum — which is exactly what the pipeline writes. Two checks worth automating into an export script, since you’ll release more than once:
assert peak_db(track) <= -0.9, "leave true-peak headroom for lossy encoding"
assert abs(rms_db(track) - album_target) < 1.0, "album loudness consistency"
Streaming platforms normalize loudness on playback (turning hot masters down), so the war is over; don’t crush your dynamics chasing volume. Chapter 12’s RMS-matched masters land comfortably in the modern norm.
Metadata is data — your favorite kind. Title, artist, track numbers,
year, genre, cover art: embed it in the files themselves rather than
trusting web forms. The mutagen library tags WAV/FLAC/MP3 in a dozen
lines, driven by the same specs list that rendered the album — one
source of truth from TRACKS[5]["title"] all the way to the phone
screen. Cover art wants 3000×3000 JPEG/PNG, RGB, under platform size
caps; text must be legible at thumbnail size (the covers this book’s
albums use were themselves rendered by script — of course they were).
Provenance. Chapter 14’s receipts, plus the git tag of the exact
commit that rendered the shipped masters: git tag album-sign-off-v1.
A year from now, “which code made the record” has one answer.
Where to put it
Three channels, three jobs — do all three:
A distributor (DistroKid, TuneCore, CD Baby and similar) is the toll booth to Spotify, Apple Music, and every other streaming service. Costs are modest (annual-fee or per-release models); upload the folder you just assembled, and allow a week or two of lead time before your release date. This is the discoverability channel — expect streams, not income; per-stream rates are fractions of a cent.
Bandcamp is the income and audience channel: fans pay real money for downloads, you set prices, and buyers become an email list you own. Instrumental niche genres — exactly what this pipeline makes — do disproportionately well there. Upload lossless; offer the full album at a fair price and let singles float.
Your own site is the sovereignty channel. You already run one (if you’ve been following the blog thread of this book’s story): a page per album, streaming embeds, a link to Bandcamp. Platforms change terms; your domain doesn’t.
The AI question, at upload time. Distributors and platforms increasingly ask whether AI was involved, and some stores flag or filter accordingly. Answer truthfully per Chapter 14’s disclosure line. A pipeline like this book’s — composed by you, performed by code, with at most a generated texture bed — sits firmly on the “made by a person with tools” side of every current policy, and saying exactly that, plainly, is both honest and good positioning.
Calibrating expectations (the kind part)
Releasing instrumental music with no audience is planting a tree: the first season’s numbers are compost. Streams will be small; that’s not a verdict on the music. The realistic assets a release creates are:
- A finished, public body of work — the difference between “I have scripts” and “I make records,” visible to anyone you ever show.
- A Bandcamp page where the first fifty true fans can pay you.
- Proof of pipeline — the next record costs a fraction of this one, and the one after that less still. Catalogs compound; singles don’t.
Release on a cadence the pipeline makes almost free (a single every few weeks beats an album-shaped silence), put each one somewhere a human might hear it — a subreddit that matches the genre, a newsletter, the blog — and let the catalog do the slow work catalogs do.
The last render
Here’s the whole system, one final time, as a shipping checklist:
compose specs + hooks in git (Chapters 8, 13)
perform seeded humanized events (Chapter 9)
sound six loaders, six rigs (Chapters 2–7, 10)
place one shared room (Chapter 11)
prove stems null at -87 dB (Chapter 12)
package tagged, loudness-matched WAVs (this chapter)
ship distributor + Bandcamp + site
tag git tag album-vN — the record IS the commit
Every line is a script you now have. The first time through, this list took me months of lost afternoons — that was the tuition this book refunds. The second time through, it’s an evening’s work surrounding the only part that was ever the point: writing the songs.
Somewhere back in Chapter 1, I promised that once a song is a program, everything composes. Here’s the compounding truth that promise matures into: a catalog is a codebase. Every rig you build, every room you measure, every form you name is available to every future record, and each album teaches the next one. DAW projects end; codebases grow.
Go write track thirteen. The band’s already warmed up.
— end of Part III —
Appendices: A — per-OS setup; B — the EXS binary format reference; C — VST3 preset chunk anatomy; D — General MIDI program numbers; E — free resources (soundfonts, amp captures, IRs, drum machines).