A few weeks ago I wrote about the math behind fitting 11 songs into 4MB — a claim someone made at a party, the numbers I ran when I got home, and what the science of audio compression actually says about what's possible. [You can read that here.] The short version: at standard song lengths, 4MB for 11 songs produces audio that sounds like music being described by someone who vaguely remembers it. The math doesn't lie.

But that piece assumed something I didn't examine until later: that a "song" is three minutes long.

In 2026, that assumption is losing ground fast — and when you let go of it, everything changes. Songs are getting shorter. That's documented, industry-wide, and accelerating. The average track length has been declining since streaming became dominant, because streaming rewards replays, not duration. Spotify pays per stream regardless of length (above a 30-second minimum threshold). TikTok and Reels conditioned listeners to expect a payoff in the first eight seconds or they're already gone. Entire genres — hyperpop, phonk, drill, bedroom pop — are built around tight, sub-two-minute structures where brevity isn't a compromise, it's the point.

So the question this piece is actually answering is: if songs are getting shorter anyway, and if file sizes shrink dramatically when songs are shorter, what does that open up — and should you be compressing smarter even when nobody's forcing you to?

The answer to that last question is yes. Here's why, and here's how.

At one minute and twenty seconds per song — which is a real, plausible track length in 2026 — eleven songs in 4MB produces audio at about 37 kbps. That's not comfortable, but it's no longer in "unrecognizable" territory, especially with Opus in mono. Tighten it to 47 seconds per song and you break 64 kbps, which is AM Radio quality — listenable, present, the notes are all there. Get to 23 seconds per song at 128 kbps and you have standard MP3 quality. That's good. No asterisks.

The constraint hasn't changed. What changed is the art form operating inside it.

File compression isn't just an emergency measure when you've run out of space. There are real professional contexts where understanding this is the difference between someone who's prepared and someone who's scrambling.

Mobile Games and Interactive Experiences

Game audio is one of the most aggressive compression environments in professional music. Apple's App Store recommends keeping apps under 200MB for cellular download — and that 200MB has to include the entire engine, art assets, UI, and code, not just audio. A composer scoring a mobile game is working with audio budgets that make "4MB for 11 songs" look generous. Short ambient loops, UI interaction sounds, and adaptive music layers all need to be small, load fast, and loop cleanly. Knowing how to get a 90-second ambient loop to 400KB without sounding hollow is a skill that gets you hired and re-hired. Developers remember composers who deliver to spec.

The same logic applies to browser-based experiences, WebXR, and interactive installations where audio needs to load over a network before a user's attention moves on.

NFT Platforms and On-Chain Audio

Different platforms have different file size caps and different formats they'll accept. Knowing how to get your audio to the right size without sacrificing what matters — before you pay a minting fee — is basic professional hygiene at this point. The platforms don't tell you how to do this. They just tell you the limit.

There's also a more interesting on-chain conversation happening around recursive ordinal inscriptions on Bitcoin, which is explored in [Part 3 of this series], but the short version is: audio that lives permanently on a blockchain needs to be small enough to be economically feasible to inscribe, and understanding compression is how you get there without your music sounding like a phone call from 2003.

Social Media Recompression: Know What Survives

This is one that almost nobody talks about and every musician should understand. When you upload audio or video to Instagram, TikTok, YouTube, or Twitter/X, the platform recompresses it. You don't get to opt out. Your 320kbps master hits their transcoding pipeline and comes out the other side at whatever bitrate their system decided. Instagram Reels audio is famously aggressive about this. Tracks with a lot of sub-bass and stereo width are the most vulnerable — the recompression tends to collapse the low end and narrow the image.

What survives? Clear mid-range. Strong transients. Arrangements that don't rely entirely on frequencies that compression artifacts destroy. Understanding what happens at low bitrates tells you what to protect in your mix for social delivery. That's not a compromise — that's knowing your medium.

Sync Licensing Libraries

Sync libraries — Artlist, Musicbed, Epidemic Sound, Musicbed, and dozens of others — have technical delivery specs. Wav files, specific sample rates, loudness targets. Some of them also have upload limits per submission or per account tier. The musicians who move through these pipelines quickly are the ones who've built a file management workflow that doesn't require reformatting everything from scratch every time they have a deadline.

Developing Markets and Low-Bandwidth Listeners

If your music reaches audiences in regions where mobile data is expensive and connection speeds are inconsistent — and if you're releasing independently with any kind of global ambition, it does — then the file size of your streaming deliverable matters to your actual listeners. Most DSPs handle this automatically with adaptive streaming, but for direct distribution, smart archives, and anything you're hosting yourself, smaller well-encoded files mean more people actually hear your music without buffering.

Radio and Broadcast Delivery

Broadcast specs vary by country and by station. Some require specific loudness levels (LUFS), specific bit depths, specific sample rates. Many broadcasters receive hundreds of submissions. Having files that are correctly formatted and appropriately sized is the basic table-stakes of professionalism in that space. Being the person who sends a 200MB WAV when a 7MB MP3 at 320kbps was what was needed doesn't make you seem serious — it makes you seem like you've never done this before.

Yes. With a structure.

Not "compress everything to the smallest possible size" — that's a different and wrong answer. The right answer is: keep your masters untouched and build a compression workflow into how you archive and distribute everything else.

Here's the philosophy: storage is cheap until it isn't, transfer is fast until you're on a plane, and the habit of file hygiene compounds across a career. A producer with ten years of work and no file management system is sitting on terabytes of session data, duplicate bounces, and full-quality files for demos that were rejected in 2019. A producer with a compression workflow is sitting on a navigable, affordable archive of everything they've made, formatted correctly for every use case they encounter.

The other reason to compress intelligently — even when you have space to spare — is that it forces a discipline of intentional delivery. Every file you send, post, or store has a purpose. The purpose determines the format. A reference mix going to a collaborator doesn't need to be a 50MB WAV. A preview clip for an A&R doesn't need to be lossless. A session archive for your own records needs to be complete but not bloated. Getting precise about what each file is for makes you a better-organized artist and a more professional collaborator.

Here's what the math looks like on Pinata — one of the most common IPFS pinning services used for music NFTs and on-chain storage. Their free tier is 1GB.

For session stems specifically, the difference is violent. A typical project bounce — ten stems, three minutes each — runs about 506MB as WAV files. The same ten stems as Opus at 96kbps runs about 21MB. Pinata's free tier holds two full WAV sessions or 48 full Opus sessions. Same account. Same storage limit. Different workflow.

The same math applies across every free-tier service you're using:

The actual workflow, step by step:

1. Keep your masters sacred. Your working session and your final WAV/AIFF mix stay in their original, uncompressed format. Non-negotiable. This is the original painting. Everything else is a print.

2. Bounce reference stems from every session before you close it. Bass, drums, vocals, everything else — separate stems, full quality WAV. These are your working archive. Store them locally on an external drive and don't touch them.

3. Create compressed Opus versions of everything for cloud/IPFS storage. Using FFmpeg (free, command line):

# High-quality archive version — you'd be comfortable sending this to anyone
ffmpeg -i mix.wav -c:a libopus -b:a 96k output_archive.opus

# Streaming/preview version
ffmpeg -i mix.wav -c:a libopus -b:a 64k output_preview.opus

# Batch process a whole folder
for f in *.wav; do ffmpeg -i "$f" -c:a libopus -b:a 96k "${f%.wav}.opus"; done

4. Pin the Opus versions to Pinata (or your IPFS service of choice). Name your pins clearly — artist name, project name, stem type, date. Pinata lets you add metadata to pins. Use it. Your future self will thank you when you're looking for a specific bass stem from 2024.

5. Keep a simple log. A spreadsheet with columns for: project name, session date, what's stored where, IPFS CID (the hash Pinata gives you), format, and notes. This takes five minutes when you're finishing a session and saves hours when you need something specific six months later.

Beyond the obvious:

Wearables and IoT. Smartwatch apps, interactive clothing, sensor-triggered audio installations — all of these have severe storage constraints. A wearable that plays music in response to biometric data needs audio that fits on an embedded processor. Short, compressed, designed for the constraint.

QR-linked physical art. An emerging practice — physical artwork, merch, or packaging with a QR code that triggers audio playback. The audio lives on IPFS or a CDN. Smaller files mean faster load on mobile networks, which means the person who scanned the QR doesn't put their phone away before the audio starts.

Interactive PDFs and ebooks. Yes, you can embed audio in PDFs. Publishers and educators do this regularly. Size limits are real. A 30-second highly compressed intro track is the difference between a document that attaches easily and one that bounces from every inbox.

Voice assistant skills. Alexa Skills and Google Assistant apps can serve audio. The response payload has size limits. Custom music experiences built into voice assistants work better when the audio assets are appropriately sized.

Archival donation and music libraries. If you're submitting music to academic archives, sample libraries, or any institution that catalogs audio, their ingest systems often have file size guidelines. Clean, correctly-formatted, compressed-but-high-quality files move through these pipelines faster and get accepted instead of flagged.

Your own direct fan distribution. Email lists, Substack attachments, Bandcamp previews, Patreon audio posts — all of these have limits that WAV files routinely exceed. A well-encoded Opus file at 96kbps is audibly indistinguishable from MP3 320kbps for most listeners and dramatically smaller. Sending your fans audio that actually loads is a basic service.

File compression is not a compromise. It's a skill set that belongs in the same category as knowing how to export at the right loudness level for streaming, or knowing the difference between 44.1kHz and 48kHz and when each is appropriate. It's the difference between an artist who understands their medium and one who is perpetually surprised by it.

The musicians who build this workflow now — before storage costs spike, before a platform changes its limits, before they have ten years of sessions in formats that are becoming obsolete — are the ones who own their catalog without friction. The ones who don't build it are the ones who will eventually be paying someone to help them figure out where everything went.

Compression as a policy isn't pessimism. It's architecture. And the people who think clearly about architecture rarely get caught by the walls.

This topic Premiered on GIRL BARS by Endodeca This is part of a series on audio compression and Bitcoin-native music.

GIRL BARS — Music Tech | Endodeca — Part 3

The article has actual working FFmpeg commands per stem type, a real functional Web Audio API implementation you can drop into an HTML inscription today, the demucs workflow for people working from finished masters without session files, and an honest section on where the tooling is still rough and why some developers aren't sharing it.

I keep hearing the word "recursion" in music and blockchain conversations. I hear it at showcases, in Discord servers, on panels. And here is what I've noticed: the people saying it most confidently are never the ones who built anything with it. They're amplifying something they were told by someone who was told by someone else, and somewhere back in that chain of telephone there was a developer who actually knew, and that developer has long since stopped talking to panels.

That ends here.

This is what recursion actually is, what it does for audio specifically, and a real workflow for doing it yourself — starting today.

Recursion in Bitcoin Ordinals is not magic. It's not a philosophical concept. It's a technical feature introduced to the Ordinals protocol that does exactly one thing: it lets one inscription reference the content of another inscription.

That's it.

When you inscribe something on Bitcoin, it gets a unique ID — something like a3f7bc...i0. That content is permanently retrievable at a path that looks like /content/a3f7bc...i0. A recursive inscription is simply one that calls that path, the same way a webpage calls an image from a server. Except the "server" is the Bitcoin blockchain, it never goes down, and nobody can delete it.

An HTML file on Bitcoin can load audio from another inscription. A JavaScript file on Bitcoin can combine multiple audio inscriptions and play them in sync. The entire composition lives on-chain — not hosted, not dependent on a company staying solvent — and the individual stems it references also live on-chain independently, permanently, reusably.

That is what recursion means. Now let's talk about why it matters for sound quality.

Parts 1 and 2 of this series established that compressing a full song to extreme bitrates sounds like music being described by someone who's never heard music. The reason is that a full mix contains everything at once — bass frequencies down at 30Hz, snare transients spiking at 5kHz, vocals sitting in the midrange, cymbals reaching toward 16kHz — and a codec trying to represent all of that at 16 kbps has to make brutal, destructive decisions about what to throw away.

Stems are different. A bass stem only contains content in roughly the 20–200Hz range. A vocal stem lives mostly in the 80Hz–8kHz window. A drum stem is percussive and transient but spectrally manageable in isolation. When you compress a single stem, you're asking the codec to represent a much simpler, narrower frequency picture — and codecs, particularly Opus, are dramatically better at this than they are at representing full mixes at the same bitrate.

Here's what the numbers look like when you allocate compression intelligently by stem:

Combined, that's 192 kbps of total information across four files — eleven and a half times the quality of cramming everything into a single 16.5 kbps file. Each stem, at its individually appropriate bitrate, will sound respectable. The bass stem at 32 kbps mono sounds far better than bass in a full mix at 32 kbps, because the codec isn't competing with seventeen other frequency ranges for the same budget.

This is the actual argument for recursive stems. Not mysticism. Frequency-specific compression at appropriate bitrates, assembled by a tiny HTML file that weighs almost nothing, pulling the elements together in real time on playback.

I'm going to be straight with you because this matters: the stem approach uses more total storage than stuffing everything into one file. Four stems for a 3-minute song at those bitrates adds up to roughly 4.3MB — more than the entire 4MB budget from Parts 1 and 2. Eleven songs with four stems each comes out around 46MB total.

So the recursion approach is not a compression hack. It is a quality architecture. You're spending more on-chain space to get dramatically better sound. That's a different trade-off than trying to minimize file size, and it's worth being clear about the distinction.

What recursion does give you that a single file cannot is this: shared stems cost nothing to reuse.

If you produce music with a consistent drum palette — and most producers do — that drum pattern, once inscribed, can be referenced by every composition that uses it without paying to inscribe it again. The same bass loop that runs through tracks 3, 6, and 9? Inscribed once. Referenced three times. You paid for it once and it lives in every song that needs it. The more prolific your catalog, the more efficiently it compounds. You're not storing music anymore. You're building a library that composes itself.

Here is how to do this. Not conceptually. Actually.

Step 1: Export Your Stems

From your DAW, export individual stems for each element. Standard practice is at minimum: bass, drums, vocals, everything else. Depending on your arrangement, you might go further — pads separate from leads, for instance. Export at full fidelity first (WAV, 44.1kHz or 48kHz, 24-bit). You'll compress them in the next step.

Step 2: Compress Each Stem Appropriately

Use FFmpeg, which is free, open-source, and runs from the command line. These commands give you the right compression profile per stem type:

bash

# Bass stem — mono, 24kHz, 32kbps Opus
ffmpeg -i bass.wav -c:a libopus -b:a 32k -ac 1 -ar 24000 bass.opus

# Drums — mono or stereo depending on room feel, 32kHz, 48kbps
ffmpeg -i drums.wav -c:a libopus -b:a 48k -ac 1 -ar 32000 drums.opus

# Vocals — mono, 24kHz, 48kbps
ffmpeg -i vocals.wav -c:a libopus -b:a 48k -ac 1 -ar 24000 vocals.opus

# Melody/Synth — can stay stereo if it matters, 44.1kHz, 64kbps
ffmpeg -i melody.wav -c:a libopus -b:a 64k -ar 44100 melody.opus

Listen to each output file before you proceed. If the bass sounds wrong at 32kbps, bump it to 40kbps. These are starting points, not gospel.

Step 3: Inscribe Each Stem Separately

Using the ord client or a service like Gamma.io or Hiro.so, inscribe each stem file as a separate ordinal. You'll receive an inscription ID for each one — something like a3f7bc8d2e1f...i0. Write these down. They are the addresses your composition will call.

Step 4: Write the Composition Inscription

This is the piece that pulls everything together. It's an HTML file with embedded JavaScript, and it uses the Web Audio API to fetch each stem, decode the audio, and start playback in precise synchronization. Here is a working structural example:

html

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Track Title</title>
  <style>
    body { background: #000; display: flex; align-items: center; 
           justify-content: center; height: 100vh; }
    button { color: #fff; background: none; border: 1px solid #fff; 
             padding: 12px 24px; cursor: pointer; font-size: 16px; }
  </style>
</head>
<body>
  <button onclick="play()">PLAY</button>
  <script>
    // Replace these with your actual inscription IDs
    const stems = [
      '/content/BASS_INSCRIPTION_ID_HERE',
      '/content/DRUMS_INSCRIPTION_ID_HERE',
      '/content/VOCALS_INSCRIPTION_ID_HERE',
      '/content/MELODY_INSCRIPTION_ID_HERE'
    ];

    async function play() {
      const ctx = new AudioContext();
      const buffers = await Promise.all(
        stems.map(url =>
          fetch(url)
            .then(r => r.arrayBuffer())
            .then(ab => ctx.decodeAudioData(ab))
        )
      );
      // Schedule all stems to start at the same moment
      const startTime = ctx.currentTime + 0.1;
      buffers.forEach(buffer => {
        const source = ctx.createBufferSource();
        source.buffer = buffer;
        source.connect(ctx.destination);
        source.start(startTime);
      });
    }
  </script>
</body>
</html>

This HTML file is about 2–3KB. Inscribe it last. When someone opens this inscription in an Ordinals-compatible viewer, it fetches each stem from the chain, decodes them in the browser's audio engine, and starts them simultaneously. The listener hears the full composition — bass, drums, vocals, melody — assembled in real time from four separate on-chain files.

Step 5: AI Stem Separation (If You Don't Have Session Files)

If you're working with finished masters and don't have the original sessions, Meta's open-source tool demucs can separate a stereo mix into stems automatically. It runs locally, it's free, and it's genuinely good — not perfect, but good enough for this workflow as a starting point.

bash

It outputs bass, drums, vocals, and other as separate files. Use them as your source material for Step 2.

The storage math expands. The creative math gets interesting.

Because every stem is a discrete on-chain asset, you can treat your stems as building blocks across your entire catalog. A drum stem from one song can be pulled into a remix without the original artist having to send you anything — the address is public. A bass line you inscribed in 2024 can appear in a 2027 composition. Collaborative arrangements can be assembled from stems inscribed by multiple artists, each credited at the inscription level.

It also means the conversation about "fitting music onto Bitcoin" has been slightly wrong this whole time. The frame of "how small can I make a full song" is the old frame. The new frame is "what is the smallest meaningful unit of my music, and what can I build from units that already exist on chain?"

That's recursion. Not a buzzword. A different way of thinking about what a music file is.

Because I'm not here to hype, I'll say this too: recursive ordinal audio is not yet standardized. Viewer support varies — some ordinal explorers render the HTML cleanly, others strip JavaScript, others don't load cross-inscription fetches. This is an early, actively developing space. The code above will work in compliant environments and may not render in others.

The tooling is also still rough. There's no drag-and-drop interface for this workflow. You will need to be comfortable with the command line, with FFmpeg, with the ord client or a third-party inscription service, and with enough JavaScript to debug a Web Audio API implementation when something doesn't start in sync. That learning curve is real.

What is also real: some developers know exactly how to do all of this, have done it, and are not publishing tutorials because first-mover advantage is a thing. I understand the strategic logic. I also think music moves faster when more people know how to build with it.

So there it is.

GIRL BARS | Endodeca — Part 3 of 3 in the compression series. Part 1: An entire album. 4MB. I Did the Math So You Don't Have To. Part 2: Devil's Advocate: What If the Songs Are Only 1:20?

Yesterday I did the math on 11 songs in 4MB and the math told me: impossible, without sounding like someone left music in the rain. I stood by that. I still stand by that.

But then I kept thinking about it. Because the calculation I ran assumed something I didn't even question — that a song is 3 minutes long.

What if it isn't?

This is not a hot take. This is a documented, multi-year trend that the music industry has been watching in real-time. Since streaming became the dominant delivery format, average song length has been in a slow, steady decline. Spotify pays per stream, not per minute. Algorithms reward replay count. TikTok trained an entire generation's ears to expect the hook in the first eight seconds or they're already swiping.

By 2026, sub-two-minute tracks are not a novelty. They're a strategy. Some of the most-streamed records of the last several years clock in under 2:30. Hyperpop, drill, phonk, bedroom pop — entire genres are built around tight, punchy, get-in-get-out structures. A minute twenty isn't a demo. It might just be the song.

So let's run it back. Let's give the person at the party the benefit of the doubt they probably don't deserve, and see what happens to our math when we change one variable.

Here's what the numbers actually look like when you stop assuming 3-minute songs:

At a minute twenty per song, you're sitting at 37.2 kbps. That is — let me be precise here — 58% of AM Radio quality. With Opus, in mono, at a 32 kHz sample rate.

That's not nothing. That's not the "metallic shimmer in a blender" scenario I described last week. That's survivable. Whether it's good depends entirely on what the music is doing.

Drone music? Ambient textures? Lo-fi beats that already have vinyl crackle baked in as an aesthetic choice? 37 kbps might not even be audibly offensive to the average listener in those genres. The compression artifacts can almost pass as intentional warmth if the source material is sparse enough.

A dense orchestral arrangement with dynamic range, a gospel choir, a trap record with 808s that go down to 30 Hz and a hi-hat pattern that lives at 16kHz simultaneously? 37 kbps will end you. The codec will make decisions you did not authorize about what frequencies matter, and it will be wrong every single time.

The breakeven where things get genuinely listenable — as in, you wouldn't be embarrassed to play it for someone — is 47 seconds at 64 kbps. That's AM Radio quality. Not premium. Not hi-fi. But the notes are there, the rhythm is there, the song is recognizable and present.

Thirty-one seconds per song gets you to 96 kbps. That's respectable. That's the quality level a lot of podcast audio lives at. Twenty-three seconds per song gets you to 128 kbps — standard MP3, actually good, no asterisks needed.

Twenty-three seconds. Eleven of them. In 4MB. With quality.

Here's the thing I can't shake: a 23-second song is not new. Hardcore punk has been releasing sub-30-second tracks since the early '80s. Grindcore made brevity an ideology. Chopped interludes, skits, transitional tracks on concept albums — these aren't songs that failed to be longer. They're exactly as long as they need to be.

The streaming era is creating a new version of this by economic pressure rather than artistic intention, which is a different and more complicated conversation. But the format itself — short, tight, punchy — is not inherently less musical. The constraint is not the problem. The constraint is the canvas.

Which brings us back around to Bitcoin.

When you inscribe audio onto Bitcoin as an ordinal, you're working within a block size limit. That limit is not going away. The technology is not designed to eventually accommodate your 48kHz stereo master at full fidelity. The compression tradeoff is structural.

But here's what the math just told us: if you're releasing music that runs 23 seconds at 128 kbps, you have a standard-quality audio file that fits comfortably in that constraint. If you're creating ambient pieces, generative loops, sonic textures — the kinds of things that exist as experiences rather than traditional songs — the compression ceiling might not even be a ceiling for you. It might just be the room you're working in.

The artists who are going to do interesting things with on-chain audio are not the ones trying to force a 4-minute record into a 200KB container. They're the ones who understand the container first and build the work to live inside it. Same as every constrained format that preceded it — vinyl's 20-minute side limit, the 74-minute CD, the 10MB MP3 file cap on early digital distribution platforms. The constraint shapes the art. Always has.

So: can we fit 11 good-sounding songs onto an ordinal?

Yes. If each song is 47 seconds or shorter, you clear 64 kbps and it's listenable. If each song is 23 seconds or shorter, you hit 128 kbps and it sounds genuinely good. If your songs are 1:20 you're at 37 kbps, which is rough but not indefensible depending on genre and intent.

As the creator and marketer of your music, operating inside a completely different definition of what a song is is your prerogative— and in 2026, that definition is legitimately in motion.

I went in on the numbers to extract a point of reference. The math revealed new ideas.

That's sometimes how it goes.

GIRL BARS | Endodeca — Part 2 in the music technology series.
Part 1: [An Entire Album on 4MB. I Did the Math So You Don't Have To.]