AudD for PROs and rights organizations

If you allocate royalties or administer rights on behalf of members, your work runs on usage data: what was played, on which broadcast or stream, when, and which registered work it corresponds to. This page is about getting that usage data out of AudD — for performing-rights organizations and collection societies specifically.

AudD is a music-recognition HTTP API over a database of 160 million recordings. It can watch live broadcast and stream audio continuously, identify works inside large content archives, and return the identifiers — ISRC and UPC — that connect a recognition to a registered work.

What you can do

Monitor broadcast and stream airplay for royalty allocation

Royalty allocation needs a continuous, timestamped record of what played where. The streams surface is built for exactly this: register the broadcast and stream sources you cover, and AudD recognizes songs off them around the clock and reports each recognition back to you.

addStream registers each source you cover with its own radio_id, and setCallbackUrl or GET /longpoll/ delivers each recognition as it happens — an independent, continuous log of plays across many sources. Stream URLs accept direct HLS, Icecast, and m3u/m3u8 URLs.
callbacks="before" delivers a recognition at song start, so each row reflects the moment a play began rather than mid-song.
To keep only the registered works you administer, match stream recognitions against a private custom catalog and drop the rest.

Identify works in large content archives

Beyond live monitoring, you often have to identify what’s inside archived content — recorded broadcasts, submitted programs, long-form audio and video. The enterprise endpoint (POST https://enterprise.audd.io/) chunks long files server-side and returns one match per recognized segment, so a multi-hour recording yields a full list of identified works.

recognize_enterprise returns every recognized segment in a long recording — not just the first — each with artist, title, label, and a timecode marking the position within the matched recording.
The endpoint bills per 12 seconds of audio processed; limit, every, and skip_first_seconds bound what you process per file, which keeps an archive-wide scan’s metered cost under control.
For thousands of files, batch the archive through recognition and write one row per identified work to your own log or database.

Capture ISRC and UPC for cue-sheet-style logging

A usage log is only useful if each row ties to a registered work. The standard artist/title pair is a starting point; the recording and release identifiers are what let you match a play to your repertoire database.

Artist + title alone is ambiguous against a large repertoire; enterprise responses include isrc (the recording’s International Standard Recording Code) and upc (the release’s Universal Product Code) on a Startup plan or higher — the keys you join on.
Each match also carries song_link, a universal URL on lis.tn for the recognized recording — a stable, shareable reference per play in a cue-sheet-style record.
If every match comes back with a null ISRC/UPC, check the plan tier: the identifiers are gated, and appear on Startup or above.

Where to start

Monitor radio airplay for your music catalog — the streams workflow end to end: register many sources, record every recognition via callback or longpoll, and aggregate the rows. The same pattern drives royalty-allocation monitoring.
Scan an archive of audio files and write metadata back — walk a directory of recordings, identify each, and write artist, title, album, and ISRC to a resumable log — the basis of archive-wide work identification.
Standard, enterprise, or streams: how to choose — when to reach for live streams versus enterprise archive scanning for a given source.
Recognition result fields — the exact fields a recognition returns, including timecode, song_link, and the provider metadata blocks, for building your log schema.

Log a recognition off a stream

Streams recognition delivers each play to your callback URL or via longpoll. The shape below pulls one batch of recognitions with longpoll and logs each as a cue-sheet-style row.

from audd import AudD

audd = AudD("your-api-token")  # token from dashboard.audd.io

# Pull recognitions delivered for one registered stream. longpoll() returns
# a poll handle; iterate its `matches` for each play as it arrives.
with audd.streams.longpoll(radio_id=101) as poll:
    for m in poll.matches:
        song = m.song
        if song is None:
            continue  # a notification, not a recognized play
        print(f"{m.timestamp}  radio={m.radio_id}")
        print(f"   {song.artist} — {song.title}  ISRC={song.isrc}  {song.song_link}")

Each event is one play on one registered source: the source’s radio_id, the recognized work, its identifiers, and a song_link you can store as a stable reference. Filtering these events against a custom catalog of the works you administer turns a generic now-playing log into a royalty-allocation feed.

Streams and enterprise require a real token. The public test token works only on the standard endpoint (10 requests/day) — not on enterprise, not on streams. Get an account token at dashboard.audd.io before building the monitoring or archive flow.

For archive identification rather than live monitoring, send each recorded file to the enterprise endpoint and log every returned match:

matches = audd.recognize_enterprise(
    "https://audd.tech/example.mp3",
    limit=50,  # bound metered audio per file during development
)

for m in matches:
    print(f"{m.timecode}  {m.artist} — {m.title}  ISRC={m.isrc}")

Related