DEV Community: Freqblog

Migrating from Spotify Audio Features: a Field-by-Field Threshold Guide

Freqblog — Mon, 11 May 2026 22:14:39 +0000

TL;DR: Spotify killed /audio-features on 2024-11-27. FreqBlog Music API offers a drop-in at api.freqblog.com/v1/audio-features/{id} — same path, same response shape. The numbers are ours (signal analysis via librosa + Essentia, not Spotifys ML classifiers), so a few field distributions shift. This is the field-by-field guide to re-tuning, with real distribution data from our ~57,000-track catalog.

This is a syndicated mirror — the canonical version with full formatting is at https://freqblog.com/blog/spotify-audio-features-migration-thresholds/ (where the table renders properly).

The migration shape

You swapped the host from api.spotify.com to api.freqblog.com. Your existing GET /v1/audio-features/{id} handler still parses the response unchanged, the unit tests pass. Then your downstream if features.danceability > 0.7 recommender starts surfacing weird tracks. Your acousticness > 0.5 rule fires on basically everything. Your liveness > 0.8 filter rejects the whole catalog.

The migration is byte-compatible at the shape level. Its directional at the value level. Spotify built their audio features by training ML classifiers on a labelled corpus; we compute ours from signal analysis. Same names, different beasts.

Threshold cheat sheet (catalog medians over ~8k tracks)

bpm / tempo — median 118.7 — drop-in. Plus bpm_alt corrects Spotifys known half-time bug.
key (0–11 / -1) — drop-in. Returned as key_int.
mode (0/1) — drop-in.
energy — median 0.73 — shifted up slightly; bump thresholds ~0.05–0.1.
valence — median 0.48 — closest to Spotifys distribution. Minimal re-tune.
danceability — median 0.74 — shifted up. Old 0.65 ≈ ours 0.80.
acousticness — median 0.98 — do not use as is-acoustic. Discriminates near 0.99.
instrumentalness — median 0.23 — signal-shape proxy, not a vocal classifier.
liveness — median 1.00 (saturated) — currently not diagnostic.
speechiness — median 0.45 — shifted up ~5–10×. Old 0.66 ≈ ours >0.85.
loudness — median -14 dB — 3–6 dB lower than Spotify (30s window vs full-track BS.1770); use relatively, not absolutely.
time_signature — always 4 in practice. Treat as informational, not as a filter.

Why `acousticness` is 0.98 for everything

Our formula is 1 - clip(spectral_flatness / 0.15, 0, 1). Low spectral flatness means the signal has strong tonal/harmonic peaks — which most music has, acoustic or electric. ~99% of our catalog scores >0.9. If your Spotify code said acousticness > 0.7 = acoustic track and triggered on ~20% of your library, the same threshold under FreqBlog will trigger on ~99% of it. The field is not a useless signal — it discriminates between tonal music and noise-floor content (white-noise tracks, pure ambient, recordings with heavy distortion) — but its useful threshold is up around 0.99.

Why `liveness` saturates

Formula: clip(noise_floor_ratio * 6.0, 0, 1) where noise_floor_ratio is the 5th-percentile RMS divided by the 95th-percentile RMS. The intuition is that live recordings have an elevated noise floor. The problem: modern mastered music has heavy dynamic-range compression, which compresses the RMS percentiles together — and the ×6 multiplier saturates at 1.0 almost immediately. Until we ship a better detector, drop the liveness filter.

What we get right

BPM + key/mode/key_int — Essentia is mature DSP; comparable to Spotifys ML for the common cases. Plus bpm_alt is a documented improvement over Spotifys known half-time detection bug (Blinding Lights: Spotify said 85; perceived is 171; we ship 85 in bpm and 171 in bpm_alt).
Camelot + Open Key — first-class fields, ready for harmonic-mixing tooling.
Identifier flexibility — /v1/audio-features/{id} accepts Spotify track IDs, ISRCs (with or without hyphens), spotify:track:… URIs, or open.spotify.com/track/… URLs. Pass whichever your data layer gives you.
Long-tail backfill — if a track isnt in the catalog, our backfill ingests it in 30s–2min and emails you when its ready. Spotifys API never had this.

The full doc (with worked examples + the formula per field) is here:

freqblog.com/blog/spotify-audio-features-migration-thresholds/

Free tier is 1,000 requests/month, no card. Comments / use-case feedback welcome — the caveated fields (acousticness/liveness etc.) are where concrete customer demand drives the next round of improvements.

AcousticBrainz Alternative in 2026: The Honest Insider's Guide

Freqblog — Fri, 08 May 2026 17:29:38 +0000

If you were one of the developers, researchers, or hobbyists who built on AcousticBrainz, you already know the story. The Music Technology Group at Universitat Pompeu Fabra announced the shutdown on 16 February 2022, took the live API offline, and published the entire dataset as a one-time public dump. Four years later, there's still nothing exactly like it.

This post is the honest insider's view of the post-AB landscape — written by a team that uses the frozen AcousticBrainz dump in production right now, as one of four fallback layers in our music-features API. We know what works in the dump, what doesn't, and what the realistic alternatives look like in 2026.

What you actually lost

AcousticBrainz had three things going for it that nothing has fully replaced:

Free, public, scriptable. No API key, no rate limit, no sign-up. GET /api/v1/<mbid>/low-level returned ~120 fields per recording. Researchers could pull millions of rows for a paper without negotiating commercial terms.
MBID-keyed. Every track was identified by its MusicBrainz ID, the open community-maintained identifier. That meant data from AcousticBrainz could be joined cleanly to MusicBrainz, Discogs, ListenBrainz, lyrics databases — the whole open-data ecosystem.
Crowd-contributed. Anyone could run the AcousticBrainz client on their own audio collection and submit features back. The dataset grew from real personal libraries, not a label-licensed catalog.

None of the commercial replacements has all three. Most have none.

The frozen dump — still extremely useful

This is the under-appreciated fact: the entire AcousticBrainz dataset is still freely downloadable. The official dump page hosts both the high-level (mood, genre, instrument-detection) and low-level (BPM, key, MFCCs, ~120 descriptors) tarballs as of June 2022, plus per-month deltas up to the shutdown.

What you get:

~7.5M unique recordings by MBID, with one or more contributed analyses each
~120 low-level descriptors per track — spectral centroid, MFCCs, rhythm features, tonal features, dynamic complexity, all the numbers Essentia's MusicExtractor outputs
11 high-level classifier outputs per track — genre, mood (happy/sad/aggressive/relaxed/party), instrumentalness, danceability, etc.
The AcousticBrainz JSON schema — same one the live API used, so existing client code works against the dump with zero changes if you stand up your own static endpoint

Practical setup: serve the dump as a local API

The dump is a giant tarball of one-JSON-per-MBID. The cleanest pattern is to extract it into SQLite and serve via a thin wrapper:

# Pseudocode for the loader
import json, sqlite3, tarfile

conn = sqlite3.connect("ab_features.db")
conn.execute("""
    CREATE TABLE ab_features (
        mbid TEXT PRIMARY KEY,
        bpm REAL,
        key TEXT,
        scale TEXT,
        danceability REAL,
        average_loudness REAL,
        dynamic_complexity REAL,
        onset_rate REAL,
        tuning_frequency REAL,
        mood_happy REAL,
        mood_sad REAL,
        mood_aggressive REAL,
        mood_relaxed REAL,
        mood_party REAL,
        genre TEXT,
        instrumentalness REAL,
        full_json TEXT
    )
""")

with tarfile.open("acousticbrainz-lowlevel-features-20220623.tar.zst") as tar:
    for member in tar:
        if not member.name.endswith(".json"):
            continue
        data = json.loads(tar.extractfile(member).read())
        mbid = member.name.split("/")[-1].replace(".json", "")
        conn.execute("INSERT OR IGNORE INTO ab_features ...", (mbid, ...))

Expect the resulting SQLite to land around 2.2 GB once you've extracted the columns you actually use. Full-JSON-per-row blows it up to ~50 GB; only do that if you need every descriptor.

The dump is frozen at June 2022. Nothing released after that has values. For 2024-2026 releases, you'll need a live source. Use the dump as the historical layer of a tiered system — check it first, fall back to live analysis on miss.

The MBID problem

The dump is keyed by MBID, but most of your queries will arrive with artist + title strings, not MBIDs. Resolution is a separate problem:

Hit the live MusicBrainz API: GET /ws/2/recording/?query=artist:"<artist>" AND recording:"<title>"
Score the candidates — usually the first hit is right but featured-artist strings ("Mark Ronson featuring Bruno Mars") and remixes/covers cause noise
If you find a match, take the MBID and look it up in your AB dump table

Realistic hit rate from name-only resolution to AB-dump features: ~50%. Half your tracks will resolve cleanly, the other half will be misses for one of: no MBID assigned, MBID exists but track not in AB, featured-artist confusing the resolver, or a release after June 2022.

The live alternatives

Five categories, ranked from "closest to AB's spirit" to "closest in functionality":

1. Build your own with Essentia

AcousticBrainz was Essentia + crowd contributions. The same toolkit is open-source, actively maintained, and runs on a VPS. MusicExtractor takes a 30-second audio clip and returns the same ~120 fields AB stored. Caveat: you need the audio. The dump worked because users contributed local libraries; your replacement needs an audio source — iTunes 30-second previews work but rate-limit hard, full-track licenses cost money.

2. Self-host with the dump as primary, Essentia as fallback

This is what we do at FreqBlog. ab_features.db covers ~50% of inbound name-based queries via the MBID resolution path; for misses we run Essentia on iTunes preview clips and cache the result. The two layers complement each other — the dump catches anything pre-2022 that has an MBID; Essentia catches everything else with a commercial preview. Coverage hits ~85% in practice. The remaining 15% is bootlegs, demos, and obscurities with no preview anywhere.

3. Hosted music-feature APIs

The post-AB market split into two camps:

Spotify-shim APIs — Musicae and similar, designed to feel like the deprecated Spotify audio_features endpoint. Field names match Spotify's vocabulary. Useful if you're a Spotify-deprecation refugee, but they don't expose AB's ~120 low-level descriptors — just the ~11 Spotify-style high-level fields.
Catalog-style APIs — including FreqBlog (full disclosure: ours). Pass artist + title, get back BPM, key, energy, mood-vector, the four AB low-level descriptors we backfilled (onset_rate, dynamic_complexity, tuning_frequency, average_loudness), and standard cross-link IDs. Different ergonomics from AB but covers most practical use cases.

4. Apple Music API

Apple's catalog API exposes tempo, key, timeSignature, and a few mood/genre tags. Free for developer accounts ($99/year to ship). Doesn't expose danceability, energy, valence, or anything below the high-level surface — closer to AB's high-level layer than its low-level descriptors.

5. Re-run the analysis on labelled academic datasets

For research/non-commercial work where licensing matters, the FMA, Million Song Dataset, GTZAN, and similar academic corpora ship with audio that you can run Essentia on yourself. None match AB's coverage but all are legally clean for paper-publishing.

Field-mapping table

For migrating code that previously called the AcousticBrainz live API, here's roughly how the field names translate:

AcousticBrainz field	Frozen dump	FreqBlog	Essentia (DIY)
`rhythm.bpm`	✓	`bpm`	`RhythmExtractor2013.bpm`
`tonal.key_key`	✓	`key`	`KeyExtractor.key`
`tonal.key_scale`	✓	`mode`	`KeyExtractor.scale`
`highlevel.danceability`	✓	`danceability`	SVM model, deprecated
`highlevel.mood_happy`	✓	`mood_vector.happy`	SVM model, deprecated
`lowlevel.average_loudness`	✓	`average_loudness`	`Loudness`
`lowlevel.dynamic_complexity`	✓	`dynamic_complexity`	`DynamicComplexity`
`rhythm.onset_rate`	✓	`onset_rate`	`OnsetRate`
`tonal.tuning_frequency`	✓	`tuning_frequency`	`TuningFrequency`
`highlevel.genre_*` (multiple)	✓	`genre` (single)	SVM models, deprecated
`lowlevel.mfcc.mean[0..12]`	✓	not exposed	`MFCC`
`lowlevel.spectral_*` (~30 fields)	✓	not exposed	various spectral algorithms

The dump is the only option if you need the deep low-level vector (~120 fields). Hosted APIs typically expose the ~10-15 fields that map cleanly to product use cases.

What no replacement gives you back

The crowd contribution loop. AB grew because users ran the client on their personal libraries and submitted back. No commercial replacement has that bottom-up data flow — it's all top-down catalog ingestion.
The high-level mood/genre classifiers. MTG's own shutdown post acknowledged the high-level model quality wasn't reliable enough — that's part of why they killed AB. Essentia's documentation now flags those SVM models as deprecated. Reproducing them locally reproduces a known-broken system. If you need genre/mood at production-grade quality, the modern path is the Essentia Labs MusiCNN models (TensorFlow-based, much better trained), not the deprecated SVMs.
The MBID-keyed open-data ecosystem. AB joined cleanly to MusicBrainz/Discogs/ListenBrainz because everyone shared the MBID identifier. Commercial APIs key on their own internal IDs (or Spotify track IDs, which are now deprecated for new apps). Cross-linking is harder.

How to choose

Academic / research / one-shot dataset analysis → download the dump. It's free, complete through June 2022, and citable.
Building a product that needs MIR data on current releases → tier the dump under a live source (Essentia self-hosted, or a hosted API). Use the dump as the cheap-and-deep layer.
Building a quick app that just needs BPM/key/energy → a hosted catalog API (FreqBlog, Musicae, or Apple Music) is faster to integrate than running Essentia yourself.
Need the deep low-level vector (MFCCs, spectral centroid, etc.) on every track → only the dump or your own Essentia worker will give you those. No hosted API exposes them at retail prices.

Originally published at freqblog.com. If you've got a specific MIR migration question (resolver issues, dataset licensing, etc.), drop it in the comments.

BPM API: Get BPM and Key From a Track Name (No Audio File Required)

Freqblog — Fri, 08 May 2026 17:29:37 +0000

Most "music analysis" APIs want a 30-second audio clip and a multipart upload. That's fine if you're building a DJ app where the user is dragging files in. It's a wall if you're building a fitness app trying to match treadmill cadence to a Spotify playlist, a music recommender that takes a track URL and returns "more like this," or honestly, any app where the user types Blinding Lights and expects the BPM back.

This is the architectural split nobody talks about: upload-based analysis APIs vs catalog-based lookup APIs. They look superficially similar (both return BPM, key, energy, etc.), but the failure modes are completely different and the right one for your app depends on what your user actually has in their hand.

The two architectures, in one paragraph each

Upload-based

You POST audio bytes; the API runs Essentia or librosa on them server-side; you get features back. Examples: AudD, Cyanite, AI Mastering. Hit rate is 100% (any audio works) but the user must have the file. No file means no answer. Pricing is usually per-call and on the higher end (compute-bound).

Catalog-based

You GET with ?track=Blinding+Lights&artist=The+Weeknd; the API looks the track up in a pre-analyzed library and returns the cached features. Hit rate is <100% (only works for tracks already in the catalog) but no audio file required, the response is fast (typically <100 ms), and pricing is usually per-lookup and lower (no per-call compute). When the catalog misses, the better APIs queue an on-demand analysis and email the user when it lands.

Spotify's audio_features endpoint was a catalog-based API: you passed a Spotify track ID, you got the features. It died in November 2024, which is why this post exists at all.

What "name-based lookup" actually does

The pattern, in code:

import requests

r = requests.get(
    "https://api.freqblog.com/lookup",
    params={"track": "Blinding Lights", "artist": "The Weeknd"},
    headers={"X-Api-Key": api_key},
)
data = r.json()
# {
#   "track_name": "Blinding Lights",
#   "artist_name": "The Weeknd",
#   "audio_features": {
#     "bpm": 171.0,
#     "bpm_alt": 85.5,           # half-time variant
#     "key": "C#-Minor",
#     "camelot": "12A",
#     "open_key": "5m",
#     "energy": 0.91,
#     "danceability": 0.85,
#     ...
#   }
# }

What's actually happening behind the request:

Catalog hit — the lookup matches by name and returns within ~10 ms. Most popular tracks are pre-analyzed and live here.
Catalog miss but reachable — the API can't find the track, but it can find the iTunes preview for it. It returns HTTP 202 ("queued"), kicks off a background analysis (download preview → run Essentia → cache result), and emails the user when the data is ready (typically 30 seconds to 2 minutes later). Subsequent calls hit the cache.
Genuinely unfindable — demos, bootlegs, alternate-takes that have no commercial release. The API returns 404 or an empty object. Plan for this in your UX.

The 202 path is the differentiator. Most catalog APIs return 404 on miss and leave you to figure it out. The "queue and email" pattern means a track that's missing today is in the catalog tomorrow — the catalog grows toward the long tail of what your users actually search for, instead of being frozen to whatever was popular when the dataset was built.

What you can ask for by name

The full set of fields a good name-based BPM API should return:

Field	Example	Why it matters
`bpm`	`171.0`	Tempo for sync/cadence/sorting
`bpm_alt`	`85.5`	Half-time variant when the detector reports the wrong octave
`key`	`"C#-Minor"`	Musical key (12 pitches × major/minor)
`camelot`	`"12A"`	DJ-friendly key notation for harmonic mixing
`open_key`	`"5m"`	Alternative DJ notation
`energy`	`0.91`	0-1 normalised intensity
`danceability`	`0.85`	0-1 rhythmic groove score
`valence`	`0.50`	0-1 musical positivity
`loudness`	`-5.2`	dB FS reference
`time_signature`	`4`	Beats per bar
`genre`	`"pop"`	Coarse Last.fm-style tag
`isrc` + `mbid`	`"USUM72003867"`	Cross-link IDs to other catalogs

The hit rate is the metric that matters

The single most important question to ask any catalog-based API: what fraction of the tracks my users will search for are actually in your catalog? Vendors will quote you a top-line track count ("10M tracks!") which is meaningless unless you know the distribution.

Three honest signals to look for:

Charts coverage — if the catalog has the current Apple Music / Spotify global top-200, you'll hit on most pop tracks people search for.
Decade depth — if 80% of the catalog is 2020+, anything pre-2010 will miss. Music apps that surface throwback tracks need 60s/70s/80s coverage too.
On-demand backfill — "we'll fetch and analyze if it's missing" turns a hard miss into a slow hit. Bigger long-term win than headline catalog size.

When the catalog misses, what do you do?

Three patterns work:

Pattern 1: Queue + notify

The 202-pattern. Show "Analyzing… we'll email you" in your UX. Comes back via webhook or the user re-querying. Best when users care about that specific track and will wait.

r = requests.get("https://api.freqblog.com/lookup",
                 params={"track": track, "artist": artist},
                 headers={"X-Api-Key": api_key})
if r.status_code == 202:
    # Queued. Show a "checking..." UI. Re-poll in 30s, or wire a webhook.
    return {"status": "queued"}
elif r.status_code == 200:
    return r.json()
else:
    return {"status": "unavailable"}

Pattern 2: Bulk pre-warm

If you know the user's library upfront (e.g. they uploaded a CSV of their playlist), POST the whole list to /bulk. The API returns immediately with a mix of hits + queued items, and the queued ones land via email/webhook over the next few minutes.

Pattern 3: Graceful degradation

If your UX doesn't need every field, the API returns what it has and nulls the rest. Render BPM and key when present; hide the energy/valence chips when null. Users don't know what they're missing if you don't show empty boxes.

BPM accuracy: a footnote that matters

BPM detectors get confused on roughly 20% of dance tracks. The Weeknd's Blinding Lights is the textbook example: the actual tempo is 171 BPM, but Spotify (and most DSP-based detectors) returns ~85.5 because the algorithm latches onto the half-time pulse. The fix: expose both the detected BPM and the half/double-time alternate, and let your app decide which to display based on the genre context.

Any BPM API you evaluate should either fix the half-time issue automatically or expose enough context (the alternate value, a confidence score, or both) for you to fix it client-side. Spotify's old audio_features didn't, which created a long tail of "this app says my song is 85 BPM" UX problems.

What no name-based API will give you

Per-bar/per-beat timing. Catalog APIs return whole-track features. If you need beat-level timing for visuals or sync, you need an upload-based API or you'll have to run a beat tracker on the audio yourself.
Tracks below a popularity floor. Bootlegs, demos, edit-only releases, and most non-commercial music isn't in any catalog. If your app routes around obscure music, you'll need either upload-based fallback or to live with the gap.
Real-time analysis of this microphone input. That's a DSP problem, not an API one. Use librosa or Essentia client-side.

How to choose

Users have audio files in hand? Upload-based API. Pay per call, accept the higher latency, get 100% coverage.
Users type a track name or paste a URL? Catalog-based. Fast, cheap, plan for ~80-95% hit rate plus a graceful "queued" path for the misses.
Both, sometimes? Most apps end up here. Use a catalog API as the fast path and an upload API (or your own Essentia worker) as the fallback for misses + obscure content.

Originally published at freqblog.com. The FreqBlog Music API has a free tier — no card required.

Got a specific catalog-vs-upload architecture question for your app? Drop it in the comments.

Spotify's audio_features API died in 2024. Here's what to use in 2026.

Freqblog — Sat, 11 Apr 2026 18:06:40 +0000

If you maintain anything that ever called GET /v1/audio-features/{id}, you already know how this story starts. On November 27, 2024, Spotify quietly killed audio_features, audio_analysis, recommendations, related artists, and featured playlists in a single developer-blog post. New apps got 403 the same day. Eighteen months later there's still no official replacement, and the February 2026 changes made the rest of the Web API harder to use, not easier.

This post is the honest version of "what now?" — the real options, where they fall short, and a Python migration example.

What actually died

Endpoint	What it gave you	Status (May 2026)
`/audio-features/{id}`	BPM, key, mode, danceability, energy, valence, acousticness, instrumentalness, liveness, loudness, speechiness, time_signature	`403` for new apps
`/audio-analysis/{id}`	Per-bar / per-beat / per-segment timing	`403` for new apps
`/recommendations`	Genre-seed and feature-seed recommendations	`403` for new apps
`/artists/{id}/related-artists`	Up to 20 related artists	`403` for new apps
`/browse/featured-playlists`	Editorial curation lists	`403` for new apps
`/me/top/{tracks\	artists}`	User listening history

Apps that already had a quota extension in flight on Nov 27 2024 are still live. Everyone else gets 403. There's no waitlist, no path forward, and no public statement that this will change.

Why Spotify isn't bringing it back

The audio_features endpoint was a thin wrapper around analysis Spotify acquired when they bought The Echo Nest in 2014, plus features derived from the AcousticBrainz dataset (which itself shut down in 2022 for similar "we don't want to host this anymore" reasons). Returning eleven floats per track in a 100M-track catalog costs Spotify infrastructure for zero strategic value.

The recommendations endpoint was worse for them — letting any third-party build a Spotify-quality recommender by spamming seed_genres=house&target_energy=0.8 undermined the whole "premium algorithm" pitch.

Stop asking "will Spotify bring this back?" The right question is "what's the smallest dependency I can rebuild this on so I'm never one PR-merge away from being broken again?"

The realistic options

Five categories, ranked by how quickly you can ship the migration:

1. Apple Music API

Apple exposes tempo, key, timeSignature, contentRating, plus mood/genre tags. Free for dev accounts, $99/year to ship. Missing: danceability, energy, valence, acousticness, instrumentalness, liveness — six of the eleven Spotify fields gone. Best if you only need BPM + key from a major catalog and don't mind paying Apple.

2. Build your own with Essentia

Essentia is the open-source MIR toolkit Spotify itself used to derive most of the deprecated values. MusicExtractor takes a 30-second audio clip and returns BPM, key, danceability, average loudness, dynamic complexity, tuning frequency, onset rate. Compute cost only — but you need the audio. Spotify never let you download it; iTunes 30-second previews work but rate-limit hard (~25 RPM). Plan for a multi-week backfill on any catalog over 10k tracks.

3. AcousticBrainz public dump (free, frozen)

The MusicBrainz folks did exactly what Spotify won't: published the entire AcousticBrainz dataset (7.5M tracks, 11 high-level features and ~120 low-level descriptors per track) as a one-time public dump in July 2022 before shutting the live service down. Catch: frozen in time — nothing released after July 2022 has values. Coverage on tracks with a MusicBrainz ID is ~60% of recent commercial releases; without an MBID, nothing. Useful as a baseline layer.

4. Musicae API

Built specifically as a Spotify shim — same field names, same value ranges, similar ergonomics. The closest drop-in if minimising migration diff matters more than anything else.

5. FreqBlog Music API (full disclosure: ours)

Different design choice: a catalog first, not a wrap-an-id service. Pass a track-name + artist string, get back BPM, key, Camelot, energy, loudness, danceability, valence, mood, time signature, ISRC, MBID, genre. From £0.17 per 1,000 requests, free tier with no card. We backfill missing tracks via a queue (returns 202 Accepted; the next call has the data). Doesn't cover per-segment analysis or speechiness/instrumentalness.

Migration walkthrough: Spotify → FreqBlog

Most apps that depended on audio_features were doing one of two things:

Look up known tracks — user pastes a Spotify URL, app shows BPM/key/energy
Filter by feature ranges — "give me upbeat tracks above 120 BPM in a major key"

Pattern 1: Single-track lookup

Before:

import requests

def get_features(spotify_id, token):
    r = requests.get(
        f"https://api.spotify.com/v1/audio-features/{spotify_id}",
        headers={"Authorization": f"Bearer {token}"},
    )
    r.raise_for_status()
    return r.json()

# >>> get_features("0VjIjW4GlUZAMYd2vXMi3b", token)
# {"danceability": 0.514, "energy": 0.730, "key": 1, "tempo": 171.005, ...}

After:

import requests

def get_features(track_name, artist, api_key):
    r = requests.get(
        "https://api.freqblog.com/lookup",
        params={"track": track_name, "artist": artist},
        headers={"X-Api-Key": api_key},
    )
    r.raise_for_status()
    return r.json()

# >>> get_features("Blinding Lights", "The Weeknd", api_key)
# {"audio_features": {"bpm": 171.0, "key": "C#-Minor", "camelot": "12A",
#                     "energy": 0.91, "danceability": 0.85, ...}}

The shape of the request changes — name+artist instead of a Spotify ID, because we're a catalog not a Spotify-wrapper. The response shape is similar enough that a 5-line adapter handles it.

Field mapping

For the 11 Spotify fields, here's how they map to the replacement landscape:

Spotify field	Apple Music	Essentia (build-your-own)	FreqBlog
`tempo`	`tempo`	`bpm`	`bpm`
`key`	`key`	`key.key`	`key` + `camelot` + `open_key`
`mode`	— (in `key`)	`key.scale`	`mode`
`time_signature`	`timeSignature`	—	`time_signature`
`danceability`	—	`danceability`	`danceability`
`energy`	—	derived from RMS	`energy`
`valence`	—	via SVM model	`valence` (where available)
`loudness`	—	`average_loudness`	`loudness`
`acousticness`	—	via SVM model	—
`instrumentalness`	—	via SVM model	—
`liveness`	—	via SVM model	—
`speechiness`	—	via SVM model	—

Some fields don't exist anywhere except Spotify's frozen-in-time models (speechiness, instrumentalness). Be honest with users about which you actually need vs which were nice-to-haves.

Pattern 2: Feature-range filtering

If you were doing the recommendations-with-target-features dance:

# Spotify (deprecated)
GET /v1/recommendations?seed_genres=house&target_energy=0.8&min_tempo=120

# FreqBlog
GET /charts?genre=house&min_energy=0.8&min_bpm=120&n=20

Same shape, different host. We also expose a similarity-based recommender (/similar?seed_track_id=...) that doesn't require seed-genre tuning — pass a track you like, get back the 10 acoustically nearest neighbours by cosine similarity over an 18-feature embedding.

What no replacement gives you

Be realistic about the gaps. None of the alternatives — including ours — replicate Spotify's old offering one-for-one:

Per-segment analysis with timestamps. Replicating /audio-analysis requires you to run a beat-tracker on the audio yourself. librosa.beat.beat_track or Essentia's RhythmExtractor2013 get you most of the way.
Speechiness, instrumentalness, liveness. Spotify trained these on internal labelled data nobody else has. Open-source Essentia models exist but Essentia's own docs flag them as deprecated due to data-quality concerns — reproducing them locally reproduces a known-noisy system.
Coverage of obscure tracks. Spotify had every track in their catalog. Every alternative has a coverage gap on long-tail releases. Plan for a "no data yet, queue for analysis" path in your UX.

How to choose

Already on Apple Music? Use their API, accept the field reduction.
Need a 1:1 Spotify shim? Musicae is closest by design.
Have audio files already? Build with Essentia, pay only compute.
Need a queryable catalog by name+artist with BPM, key, Camelot, similarity, charts? Try FreqBlog — free tier, no card.
Building research/non-commercial work? AcousticBrainz dump is free and large enough.

Originally published at freqblog.com. If you found this useful, the FreqBlog Music API has a free tier — no card required.

Got questions about a specific migration scenario? Drop them in the comments and I'll do my best.

DEV Community: Freqblog

Migrating from Spotify Audio Features: a Field-by-Field Threshold Guide

The migration shape

Threshold cheat sheet (catalog medians over ~8k tracks)

Why acousticness is 0.98 for everything

Why liveness saturates

What we get right

The full doc (with worked examples + the formula per field) is here:

AcousticBrainz Alternative in 2026: The Honest Insider's Guide

What you actually lost

The frozen dump — still extremely useful

Practical setup: serve the dump as a local API

The MBID problem

The live alternatives

1. Build your own with Essentia

2. Self-host with the dump as primary, Essentia as fallback

3. Hosted music-feature APIs

4. Apple Music API

5. Re-run the analysis on labelled academic datasets

Field-mapping table

What no replacement gives you back

How to choose

BPM API: Get BPM and Key From a Track Name (No Audio File Required)

The two architectures, in one paragraph each

Upload-based

Catalog-based

What "name-based lookup" actually does

What you can ask for by name

The hit rate is the metric that matters

When the catalog misses, what do you do?

Pattern 1: Queue + notify

Pattern 2: Bulk pre-warm

Pattern 3: Graceful degradation

BPM accuracy: a footnote that matters

What no name-based API will give you

How to choose

Spotify's audio_features API died in 2024. Here's what to use in 2026.

What actually died

Why Spotify isn't bringing it back

The realistic options

1. Apple Music API

2. Build your own with Essentia

3. AcousticBrainz public dump (free, frozen)

4. Musicae API

5. FreqBlog Music API (full disclosure: ours)

Migration walkthrough: Spotify → FreqBlog

Pattern 1: Single-track lookup

Field mapping

Pattern 2: Feature-range filtering

What no replacement gives you

How to choose

Why `acousticness` is 0.98 for everything

Why `liveness` saturates