Suno Closed Its Public MP3. The Only Audio Left Won't Identify Itself.

On 24 August I found that Suno was publishing two addresses for every song and withholding the contents of one of them. I had a control: the plain MP3, which played. The control is gone. What is left is the address I could never read.

This is the record of how that happened, dated to the day, from instruments that were running before anyone knew there was something to watch.

The August finding, briefly#

Suno's public API — the same anonymous requests your browser makes when it opens a song page — started attaching a new field to every clip in August: media_urls, a small manifest listing where that clip's audio can be fetched.

It listed two entries.

The first was the MP3 on cdn1.suno.ai that Suno has always published. The second was on a host I had never seen, labelled m4a-opus.

What I measured on 24 August:

• 149 of 149 clips sampled carried the manifest, across six endpoints — a single clip, two pages of a public profile, a playlist, both editorial shelves, and the abandoned 2024 Explore object.
• On 120 of 120 clips, both URLs were derivable from the clip's own id. Neither address was really news.
• Against a fixed corpus of 26 clips spanning every model era, the old static CDN served an Opus rendition for 17 and refused 9 — the same nine it had refused in July. The new host answered for all 26.
• The new host did not behave like a bucket. Its origin identified as a Python application server, errors came back as structured validation messages, and an unknown clip id returned a not-found. Something was looking.

Then I fetched the payload itself, and it would not identify itself. Chrome reported the codec as supported and still refused to play it — from its URL, and again re-wrapped with the declared type. The first four kilobytes of three clips from three different years carried no container header I know of, at 7.949, 7.959 and 7.962 bits per byte out of a possible eight. That is what compressed or encrypted data looks like, and I cannot tell you which.

As a control, the MP3 from the same clip loaded and played in the same harness.

I stopped there. I tried to identify the format. I did not try to decode it, and I will not. m4a-opus is Suno's label, not my finding.

I held the write-up back. That turned out to be the right call for the wrong reason: the part of the story that changed was the part I had treated as fixed.

What happened next#

Every day, at about 04:00 UTC, my observatory stores each clip's raw audio_url and — since 24 August — the list of tiers its manifest advertises. A separate research probe checks a handful of fixed CDN URLs once a day. Nobody set these up to watch an MP3 close. They watched it anyway.

Keep those three dates apart. They come from different instruments measuring different things, and they are only a timeline because they happen to agree on the order.

The detail I keep coming back to is the second row. Suno did not remove the audio_url field. It is still there, on every clip. It now contains an address whose only purpose is to be refused.

Not a glitch on my side#

On 17 September I re-sampled 119 clips: the 48 records on the abandoned Explore object, 22 on Staff Picks, 29 on Best of v5.5, and 20 on a public profile page.

• 119 of 119 listed exactly one manifest entry: the m4a-opus lane.
• 119 of 119 carried the /api/forbidden placeholder as their audio_url.

Then I fetched the first kilobyte of 10 clips across three model eras and a human upload:

• The public MP3 address: 403 on 10 of 10. So did the placeholder itself.
• The m4a-opus lane: 206 Partial Content on 10 of 10.
• Cover art: 206 on 10 of 10. The video file: 206 on all 8 clips that had one.

Suno is not refusing me in general. It is refusing the MP3.

Finally, I asked for the same shelf under four identities: my observatory's own declared User-Agent, Suno/1.0, curl/8.0, and a desktop Chrome. All four got the placeholder and the single-entry manifest on every clip.

That matters because Suno does vary its responses by User-Agent — one badge field is filtered for clients whose name begins with "suno". In those same four requests, that field still varied exactly as it always has. The mechanism is live. It just has nothing to do with this. No client identity I tried gets the MP3 back.

In August the finding was that Suno publishes the address to everyone and withholds the contents from everyone. In September it still does — and the address it publishes is now the only one.

What I can and cannot say#

I can say the plain MP3 is closed to anonymous readers, on the dates above, for every client I tried.

I can say the m4a-opus lane still answers for every clip I tried, and that on 24 August its payload could not be identified or played. I have not re-examined those bytes since. Nothing here depends on what they are.

I cannot say why. I don't know whether the lane is meant only for Suno's own player, whether the payload is encrypted, or whether anything outside Suno will ever be able to play it. I did not test what a logged-in user receives, so none of this is a claim about paying subscribers or downloads inside the app. It is a claim about what the public API hands to anyone who asks.

It changes nothing about the fossil. Suno's old /api/trending route is still a removed route over an object that is still public; its membership is still frozen at 2024 and its play counts still move. I wrote about that feed in July.

The part where my own tools broke#

This would be a tidier story if my instruments had been perfect. They were not, and the ways they failed are worth writing down.

My play button played nothing for three weeks. Seismophone's song cards had a small preview button. It played the public MP3, the only audio I could play. From 29 August it played nothing, and nothing told me. I removed it rather than point it at the lane I cannot read.

A second change took my collectors down for six days. Around 10 September, Suno also stopped publishing the background and border colours of its model badges, and added a gradient to the V6 badge. A trivial cosmetic change — except that every parser I maintain treated those colours as required. From 11 to 16 September my daily captures of the Explore object and the editorial shelves wrote nothing. Those days are missing from the record, not interpolated.

The research probe's daily smoke test caught the badge change first — it went red on 10 September, between 04:10 UTC, when the observatory's last good capture landed, and 08:57 UTC. It then stayed red for eight days, because a failed scheduled job is a red X that nobody is looking at. The weekly drift report flagged it on 13 September. Two of my production jobs spent the whole week recording "ok" while every item inside them failed.

My open-source cards broke in public. The Suno cards for GitHub READMEs I maintain started rendering "Suno error" on profile and stack cards, with the message clipped mid-URL. The song card was worse, because it failed quietly: it fell back to a thin embed with zero plays, no tags and a creation date of 1 January 1970.

All of it is fixed now:

• The parsers accept badges without colours.
• The alert that fired on 5 September treats the single m4a-opus lane as normal, so a returning MP3 would show up as a new tier.
• A single malformed song no longer takes down a whole profile card.
• Collection resumed on 17 September.
• Jobs that fail item by item now fail out loud.

I keep storing the raw audio_url. The placeholder is an observation too, and it is the only reason the timeline above could be dated at all.

What would change my mind#

• An MP3 tier reappearing in the manifest, or audio_url returning to a real address. The alert would fire, and I would say so here.
• A logged-in or first-party measurement showing the MP3 is still served somewhere to someone. That would narrow this from "closed" to "closed to anonymous readers" — which is already how I have tried to phrase it.
• Suno documenting the m4a-opus format. Then "cannot be identified" becomes "was not documented", which is a smaller and fairer claim.

Method#

Every Suno read above is an anonymous, unauthenticated GET against public endpoints that Suno itself advertises through W3C oEmbed discovery. No login, no cookies, no HTML scraping, no headless browser driving Suno's site.

The August figures come from a controlled probe on 24 August. The September figures come from a controlled probe on 17 September. The 403 date comes from a daily availability check against a small fixed set of clips. The placeholder and manifest dates are the first and last daily captures in which the stored values changed. Captures run at 04:00–04:10 UTC, so each change happened at some point in the preceding day.

On the payload, I stopped at identification: container markers in the leading bytes, byte entropy, and playback in a browser media element. I did not attempt to decode, unwrap, decrypt or work around the format.

Everything here is reproducible by anyone with a terminal. Fetch a public Suno song, read its audio_url, and request it.

I run Seismophone, an independent observatory for AI music. It publishes what the platforms don't. Numbers over adjectives.

— Chan Meng, Aotearoa New Zealand