Why I Built MeloData for Music Audio Feature Lookups

Updated September 9, 2026 to clarify Spotify access, preview analysis limits and current name lookup support.

In November 2024, Spotify restricted Audio Features and Audio Analysis for new Web API use cases. That left developers whose apps were ineligible needing another source of music feature data.

I built MeloData to provide music feature lookups using archive data and audio preview analysis. You can request a recording by ISRC or resolve its title and artist first. Cached results can return immediately; uncached recordings may need analysis, and some won't have enough data.

The 202 Pattern

I needed to handle recordings that hadn't been analyzed yet without keeping the HTTP request open while the worker processed them.

The solution: return HTTP 202 (Accepted) for cache misses.

GET /api/v1/tracks/USUM71507009/features

A completed cache hit returns HTTP 200 with recording metadata, available features, the source and analysis version. Values differ by source, and a missing feature is null. The documentation shows the response shapes and field coverage.

If it hasn't been analyzed, you get a 202 with a Retry-After header:

{
  "data": {
    "isrc": "USUM71507009",
    "status": "analyzing",
    "estimated_seconds": 30
  }
}

The client waits for the interval in Retry-After and retries with a bounded retry policy. Thirty seconds is not a completion guarantee. A later response may contain features, partial metadata or an unavailable result. HTTP 202 is not billed. Successful HTTP 200 responses, including partial or unavailable results, can count toward lookup usage. For higher volume or latency-sensitive applications, webhook support is available to avoid polling.

Completed analyses are cached so later lookups can reuse the result.

How the Analysis Works

The analysis worker uses Essentia, an open-source audio analysis library from the Music Technology Group at Universitat Pompeu Fabra in Barcelona. It's the same library used in academic music information retrieval research.

For BPM, the worker runs three algorithms and picks the most confident result:

RhythmExtractor2013 with two different methods (multifeature and degara)
PercivalBpmEstimator as a third opinion

The worker compares candidate tempos and uses confidence to select a result after normalizing octave differences. It also cross-references against catalog BPM data from Deezer when available and applies octave correction (a common BPM detection error where the algorithm reports half or double the actual tempo).

For key detection, it runs Essentia's KeyExtractor with three different tonal profiles (EDMA, Krumhansl, Temperley) and picks the result with the highest confidence.

The worker attempts integrated LUFS with Essentia's LoudnessEBUR128, but falls back to RMS-derived dB if that calculation fails. The response does not identify that fallback separately, so do not treat its loudness field as a guaranteed LUFS measurement. Energy is a perceptual proxy mapped from dB loudness into a 0..1 scale. It is useful for relative comparison across tracks but not equivalent to Spotify's trained classifier. Speechiness comes from spectral analysis of the 300-3400 Hz vocal band, and danceability is Essentia's Streich metric normalized to 0..1.

How Audio Sourcing Works

A common question: where does the audio come from?

MeloData uses publicly available 30-second audio previews that streaming services provide for discovery purposes (the same clips you hear when you hover over a track in a music store). No full tracks are downloaded or stored. The worker downloads a preview, runs analysis in memory, extracts numeric features, and deletes the audio file. Only the derived metadata (BPM, key, energy, etc.) is stored.

The API returns metadata and measurements, not the audio itself.

The tradeoff is coverage. MeloData depends on previews being available, and not every track has one. Some recordings return partial metadata or an unavailable result. The database starts with 51K pre-analyzed tracks from AcousticBrainz and grows as users query new ISRCs.

The Stack

The API is a Next.js app deployed on Vercel. The analysis worker is a Python service running on Railway in a Docker container with Essentia and FFmpeg installed.

They communicate through internal API endpoints. The worker polls for jobs, claims them atomically (PostgreSQL function to prevent double-processing), downloads a 30-second audio preview, runs the analysis, and posts the results back.

The database is PostgreSQL on Supabase with about 51,000 tracks pre-seeded from AcousticBrainz archives. Redis on Upstash handles rate limiting, API key caching, and quota tracking.

Authentication is Bearer token based. API keys are SHA-256 hashed before storage. Rate limits and monthly lookup quotas are enforced per account, so creating another key does not create another allowance.

What I Learned

Starting with archive data. The now-defunct AcousticBrainz project archived millions of crowd-sourced audio analyses. I seeded the database with 51K tracks from their dumps, mapped to ISRCs via MusicBrainz. This means many popular tracks already have features without needing on-demand analysis.

Audio preview availability is the bottleneck. The worker looks for previews through iTunes and Deezer. Some tracks, especially from smaller labels or region-locked releases, don't have previews available. Those can return partial metadata or an unavailable result. Preview availability limits which recordings MeloData can analyze.

Retries need a limit. HTTP 202 lets the client separate queued work from completed data. It still needs to handle timeouts, errors and recordings that never receive a full analysis.

Limitations

Accuracy. Tempo and key detection can be wrong, including half-time or double-time BPM results and ambiguous keys. Confidence fields vary by source and may be null. Test recordings you know before relying on the measurements.

Coverage. MeloData began with an AcousticBrainz seed dataset and adds analyses when suitable previews are available. It does not guarantee a result for every recording. Archive and live results have different field coverage; no source supplies every feature for every track.

Preview windows. A short preview can differ from the rest of a recording in tempo, key, loudness and instrumentation. Live measurements describe the available preview, not necessarily the full track. They should not be treated as full-track mastering or loudness compliance measurements.

Name lookup. You don't need to obtain an ISRC elsewhere first. Use GET /api/v1/tracks/resolve with a title and artist, check the matched recording, confidence and warning, then request features for the returned ISRC. A name match is not a guarantee that audio features are available. The resolve documentation covers the response.

Try It

The free tier is 1,000 lookups per month, no credit card. The first 50 users get an extra 500 lookups as an early adopter bonus.

The API is live. If you find a bug or have feedback, reach out at support@voltenworks.com.

Related: Spotify Audio Features API Alternative: What Actually Works in 2026. A comparison of the landscape and what to watch out for.