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.