How to build real-time music recognition for radio stations

Radio stations need accurate, automated airplay data — for royalty reporting, “now playing” displays, and programming analytics. This guide shows how to build a real-time recognition system around AudD’s stream recognition, from capturing the broadcast to producing airplay reports.

Why radio stations need real-time recognition

Manual logging is slow and error-prone, and royalty reporting keeps getting more demanding. Real-time recognition solves several problems at once: it produces accurate airplay data for royalty calculations, drives instant “now playing” displays on web and mobile, and feeds analytics for programming decisions.

Modern fingerprinting handles the realities of broadcast audio — DJ talk-overs, compression, and varying quality — well enough to be the system of record for airplay.

Core requirements

Continuous stream processing. The system must monitor a live audio feed around the clock without interruption.

Low latency. Identification should land within seconds of a song starting so “now playing” stays current.

Complete metadata. Beyond title and artist, you want album, label, release date, and streaming links to support reporting and listener-facing features.

Reliability. Radio runs 24/7, so recognition has to keep going without manual intervention; gaps become gaps in your airplay data.

Architecture overview

A radio recognition system has four parts:

Audio source — the live stream URL for the station (an HLS or Icecast feed).
Recognition — AudD’s stream recognition, which fingerprints the live audio and reports each match.
Data pipeline — receives results, filters duplicates, enriches, and stores them.
Storage and reporting — persists plays and exposes them to dashboards and reports.

The key design choice for radio is to use stream recognition, not file-by-file recognition. You register the station’s stream once with AudD; AudD recognizes continuously and pushes results to you.

Step-by-step implementation

Setting up stream capture

You don’t capture and forward audio yourself — you give AudD a URL it can pull. Most stations already publish an HLS or Icecast stream; that URL is what you register.

Streaming feed (recommended). Use the station’s existing HLS or Icecast URL. It’s already online and clean.
Over-the-air, if needed. If you only have an FM signal, run it through an encoder to produce a stream URL first.

Registering the stream with AudD

Add each station as a stream and tell AudD where to send results. You can receive matches two ways: a webhook callback (AudD POSTs each result to your URL) or longpoll (your backend holds a request open and AudD returns matches as they happen). Longpoll is the pull-based alternative to callbacks — use it when you’d rather not expose a public endpoint.

# Register a station's live stream; results are POSTed to your callback URL
curl https://api.audd.io/setCallbackUrl/ \
  -F api_token=your-token \
  -F url=https://your-server.example/webhook

Each stream gets its own id, so you know which station a match came from. Request the metadata you need (for example Apple Music and Spotify links) so each result arrives report-ready.

Receiving results

Stand up an endpoint to receive matches. Parse leniently — any field can be null — and never throw on a missing field.

from flask import Flask, request

app = Flask(__name__)

@app.route("/webhook", methods=["POST"])
def on_match():
    data = request.json or {}
    result = data.get("result")
    if result:
        record_play(
            stream_id=data.get("stream_id"),
            title=result.get("title"),
            artist=result.get("artist"),
            played_at=result.get("timestamp"),
        )
    return "", 200

Building the data pipeline

Deduplicate. Stations repeat songs and a track spans multiple recognitions; collapse consecutive matches of the same song into one play (or increment a count) rather than logging each fingerprint hit.

Enrich. Join recognitions to your internal music library, chart data, or genre tags as needed.

Process asynchronously. Put incoming matches on a queue so a slow downstream write never blocks ingestion during busy programming.

Dashboards and reporting

Now playing. Push the latest match to your website, app, and social feeds within seconds.

Airplay reports. Aggregate plays with timestamps and full metadata for royalty organizations, labels, and internal analytics.

Health monitoring. Watch recognition volume, callback delivery, and uptime; alert when a stream stops producing matches, which usually means the feed dropped.

Handling edge cases

DJ talk-overs and jingles. Confidence drops when speech sits over a song intro. Lean on the data pipeline to smooth this — a brief unrecognized gap between two matches of the same track is still one play.

Commercials and silence. Ad breaks and dead air won’t match music; treat unrecognized stretches as non-music rather than errors.

Feed quality. Network hiccups can interrupt a stream. Monitor for a stream going quiet and make sure the underlying feed URL reconnects.

Station IDs and local content. The public catalog covers commercial releases. To recognize your own jingles, idents, or locally produced content, upload them to a custom catalog (special access): you assign each track an integer audio_id that comes back on future matches. This is how you recognize station-specific audio that isn’t in the public database.

Cost considerations

Stream recognition is billed per stream, so cost scales with the number of stations you monitor, not with how many songs play. Budget separately for your own infrastructure — the server running the pipeline, storage for the play log, and bandwidth. Those are typically modest next to the value of automated, accurate airplay data, which removes manual logging and reduces royalty disputes.

For exact pricing, see audd.io — we won’t quote a number here that might go stale.

Common challenges

Feed reliability. Build in monitoring and reconnection so a dropped feed is detected and recovered automatically.

Imperfect matches. Plan a light manual-review path for ambiguous stretches and a way to handle genuinely unrecognized content.

Integration work. Wiring recognition results into existing station systems is real engineering; budget time for the pipeline and database integration.

New releases. Brand-new tracks may not be in the catalog for a short window after release. For your own pre-release audio, the custom catalog covers the gap immediately.

Keeping the system maintainable

Keep the pipeline modular so recognition is one replaceable component. Use scalable infrastructure if you plan to monitor many stations. Export airplay data in standard formats so your history stays portable and integrates with downstream royalty systems.

FAQ

How accurate is recognition on radio streams? High on clean feeds. Accuracy dips with heavy talk-overs, poor audio, or very new releases not yet in the catalog — your dedup logic absorbs most of the rough edges.

Can it identify music behind talk segments? Music at low volume under speech is harder to match. It works best with music at normal broadcast levels.

What if the feed drops? Monitor for a stream going silent and ensure the feed URL reconnects. Webhook callbacks resume as soon as recognition does.

How fast are new releases added? Commercial releases are typically added to the catalog within a short window. Your own pre-release content can be recognized immediately via a custom catalog.

Can I recognize station IDs and local productions? Yes — upload them to a custom catalog and AudD returns the audio_id you assigned when they air.

What metadata comes with each match? Artist, title, album, label, release date, and a universal song_link, plus optional provider links (Apple Music, Spotify, and more). isrc, upc, and score require a Startup plan or higher.

Conclusion

Automated radio recognition replaces manual logging with continuous, accurate airplay data. The recipe is straightforward: register each station’s stream, receive matches by webhook or longpoll, deduplicate and enrich in a pipeline, and surface the results in dashboards and reports. Start with one stream to validate the flow, then scale to your full station list.

Get a token at dashboard.audd.io and read the reference at docs.audd.io.

Related