AudD for music distributors

If you run a distribution service, every track that comes through your ingestion pipeline is a liability until you know what’s in it. A delivered “single” might contain an uncleared sample, a full third-party recording under a different filename, or a re-upload of something already in your own catalog. This page shows how to screen for each of those cases with AudD, with working recipes to start from.

AudD is a music-recognition HTTP API over a database of 160 million commercial recordings. You send audio (a file, raw bytes, or a URL); it fingerprints the audio and returns the recordings it matches, with artist, title, label, and — on the right plan — ISRC and UPC. You can also upload your own catalog and match incoming deliveries against it.

What you can do

Screen incoming releases for third-party copyrighted material

Before a delivery goes out to stores, run it through recognition to see whether it contains commercial music that isn’t the artist’s own. A delivered file is arbitrary length and may contain more than one recording, so this is a job for the enterprise endpoint (POST https://enterprise.audd.io/), not the standard one. The enterprise endpoint chunks the file server-side and returns one match per recognized segment, so you catch a sample buried at 2:30 as readily as a wholesale re-upload.

When a “new” release is actually (or partly) someone else’s recording, recognize_enterprise over the full file returns every recognized track, each with artist, title, label, and timecode (the position within the matched recording where the overlap occurred).
The enterprise endpoint bills per 12 seconds of audio processed, so a large delivery queue can run up cost; set limit=N and use every=N to sample chunks when you only need a yes/no verdict rather than a complete tracklist.
A non-null label plus a present isrc/upc distinguishes a real commercial release from an ambiguous match — the signal to act on, rather than just “some audio matched.”

Match deliveries against your own catalog

If you already distribute a catalog, you want to catch duplicates and re-uploads of material you handle. Upload your masters to a custom catalog (POST api.audd.io/upload/, special access required — email [email protected]) and recognition calls can match incoming audio against your tracks instead of, or in addition to, the public database.

When an artist re-delivers a track you already distribute under a new title, custom-catalog matching returns an audio_id identifying the exact uploaded master that matched.
The audio_id is also how you tell a catalog match from a public-database match: it appears only on custom-catalog matches, and on those artist/title may be null, since they come from what you uploaded. See the concept page below for how to disambiguate.

Capture ISRC and UPC for every recognized track

Identifiers are what make a recognition result actionable downstream — for rights checks, for matching against your metadata, for an audit trail.

“Artist + title” isn’t enough to cross-reference a recording against a licensing system; 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.
If the identifiers come back null on every match, check the plan tier: ISRC/UPC are gated, and appear on Startup or above.

Where to start

Two recipes and two concept pages cover the distributor workflow end to end:

Build a copyright scanner for user-uploaded content — the canonical screening flow: accept a file, send it to the enterprise endpoint, get back a verdict with labels, ISRC, and UPC per match. The same pattern applies whether the “user” is an artist delivering a release or a member of the public.
Detect samples and reuse of your own tracks — upload your catalog, then identify when an incoming delivery reuses one of your recordings. This is the duplicate-and-re-upload check.
Public database vs your custom catalog — when a match comes from the 160-million-song public database versus a private catalog you uploaded, and how to tell the two apart in a response.
Enterprise cost optimization — limit, every, and skip_first_seconds, and how they keep a high-volume screening queue affordable.

Screen one delivery

A minimal screen against a delivered file. Always set limit while you’re developing — the enterprise endpoint bills per 12 seconds of audio, and an unbounded call on a long delivery can ingest far more than you expect.

from audd import AudD

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

# In production this is the delivered file's bytes or a URL;
# the example file confirms the happy path.
matches = audd.recognize_enterprise(
    "https://audd.tech/example.mp3",
    limit=25,  # cap matches while developing
)

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

if not matches:
    print("clean: no commercial recordings detected")

A delivery that contains a third-party recording prints one line per recognized segment, each with the label and identifiers you need to decide whether to hold it for review. A clean delivery returns an empty list — not an error.

{
  "timecode": "00:31",
  "artist": "Imagine Dragons",
  "title": "Warriors",
  "album": "Smoke + Mirrors (Deluxe)",
  "label": "KIDinaKORNER/Interscope Records",
  "isrc": "USUM71414163",
  "upc": "00602547623805"
}

Set limit on every enterprise call during development. The enterprise endpoint bills per 12 seconds of audio processed. A delivery queue without a limit can quietly meter hours of audio. Start at limit=25 and raise it only once you understand the cost on your real deliveries.

A label/isrc/upc combination on a match is your “this is a commercial release, hold it” signal. Wire the match list into whatever policy you run: publish on no match, hold on a commercial-release match, queue ambiguous cases for a human.

Related