---
title: "How to detect copyrighted music in user-generated content"
description: "A practical guide to detecting copyrighted music in user uploads and live streams: how audio fingerprinting works, where to run detection in your pipeline, and how to wire it up with the AudD API."
slug: "/resources/articles/detect-copyrighted-music-in-user-generated-content"
section: "articles"
keywords: [audd, copyright detection, ugc moderation, audio fingerprinting, dmca, music recognition api]
---

# How to detect copyrighted music in user-generated content

If you run a platform where users upload videos, audio clips, or live streams,
you already know this problem. Someone posts a workout video with a popular
track in the background. A cooking tutorial has a playlist drifting in from
off-screen. A gaming highlight reel is cut to a licensed song. None of these
users think they are doing anything wrong — and from their perspective, they
are not. But your platform is now hosting copyrighted music without a license,
and that exposure grows with every upload.

The DMCA safe harbor exists, but it comes with conditions. "We did not know"
stops being a workable position once you are operating at any real volume. This
guide is for platform builders who want to understand how music copyright
detection works, what the technical options are, and how to build
something practical and defensible.

## Why UGC music detection is a hard problem

The challenge is not identifying music in a clean environment. It is
identifying music reliably, at scale, in noisy, compressed, user-generated
audio — fast enough to be useful.

**The signal is rarely clean.** User-generated content is messy by nature.
Music might be playing from a phone speaker while someone talks over it. It
might be compressed twice — once by the recording device and again by your
transcoding pipeline. There may be crowd noise, ambient sound, or several audio
layers competing at once. Any detection system has to handle degraded signals,
not just pristine studio recordings.

**Scale makes manual review impossible.** If your platform processes thousands
of uploads a day, listening to every clip is not a strategy. Detection has to
be automated, and accurate enough that false positives do not turn into a
support burden.

**The catalog is enormous.** There are well over a hundred million recorded
songs in commercial circulation, spread across major labels, independents,
publishers, and individual artists — each with different licensing terms and
regional rights. A song freely licensed in one country may be strictly
controlled in another. Any detection system needs to work against a database
large enough to matter. AudD recognizes against a catalog of
160 million songs.

## How music copyright detection works

At its core, music detection is a fingerprinting problem. The process has three
stages:

1. **Audio fingerprinting.** A short audio segment is converted into a compact
   digital fingerprint — a representation of its acoustic characteristics,
   designed to survive noise, compression, and minor pitch or tempo shifts.
   AudD builds these fingerprints with a neural network.

2. **Database matching.** That fingerprint is compared against a reference
   database of known songs. If a match clears a confidence threshold, the
   system returns metadata about the matched track.

3. **Metadata delivery.** The result includes artist, title, album, and label.
   On a Startup plan or higher you also get the ISRC and a match score, plus —
   when you ask for it — links to the song on Apple Music, Spotify, Deezer, and
   other providers.

This is the same family of technology behind consumer apps like Shazam, applied
at infrastructure scale with API access.

### What fingerprinting can and cannot do

Fingerprinting is excellent at identifying exact or near-exact matches: the
original recording, remixes that reuse the same master, or covers that closely
replicate the original arrangement. It is less reliable when the performance
diverges significantly — a solo piano cover of a pop song may not match the
original recording's fingerprint.

For most UGC compliance use cases, fingerprinting against master recordings is
the right approach. It catches the most common violation pattern: a user taking
a commercial recording and dropping it directly into their content.

If you also need to detect *your own* material — leaked unreleased tracks, or
reuse of audio you control — you are not limited to the public catalog. AudD
supports a custom catalog: upload your own recordings, and matches against them
come back carrying the integer `audio_id` you assigned, so you can tell a
custom-catalog hit from a public-catalog hit.

## Your technical options

Platforms generally take one of three approaches.

**Build your own fingerprinting system.** This gives you full control, but it is
a serious engineering investment: a fingerprinting algorithm, an indexed
reference database of millions of songs, matching infrastructure, and ongoing
ingestion of new releases. Unless music detection is a core competency of your
business, this is rarely the right path.

**Use a major platform's Content ID system.** YouTube's Content ID is the
best-known example, but these systems are closed. You cannot plug Content ID
into your own platform; if you are building outside that ecosystem, the option
simply does not apply.

**Use a music recognition API.** For most platform builders this is the
practical choice. You send audio to an external service and get back structured
match data; the provider handles the fingerprinting, database, and matching.
The advantages are fast time to production, no database maintenance, broad
catalog coverage, and scalable infrastructure. The tradeoff is a dependency on
a third-party service, which makes provider choice matter.

## Implementing detection with the AudD API

### Step 1: Decide where in your pipeline detection runs

You have two main options.

**Pre-publication detection** is cleaner from a compliance standpoint. Content
with detected copyrighted music can be held for review, muted, or rejected
before it ever goes live. The cost is added latency in the upload flow.

**Post-publication detection** is faster for users but leaves potentially
infringing content live for some window. You can still act on matches — muting,
removing, notifying the uploader — but the exposure exists.

Many platforms run a hybrid: a fast pre-publication check for obvious matches,
plus a more thorough post-publication sweep running asynchronously.

### Step 2: Pick the right recognition surface

AudD exposes three surfaces, and the choice follows from your input:

- For a **short clip** (the standard endpoint analyzes up to about 12 seconds
  of audio, within a ~10 MB upload) where you want a single best match, use the
  standard endpoint via `recognize()`.
- For a **full upload** — arbitrary length, possibly several songs, and you
  want *every* track with timestamps — use the enterprise endpoint via
  `recognize_enterprise()`. It chunks the file server-side and returns one
  match per recognized segment. Enterprise bills per 12 seconds of audio
  processed, so always cap it during development.
- For **live streams** that never end, register the source once with
  `addStream` and receive results via callbacks or longpoll as songs play.

For UGC uploads, the enterprise endpoint is almost always the right choice:
uploads are arbitrary length, and you want the full set of matched tracks, not
just the first one.

### Step 3: Scan an upload and read the matches

The SDK accepts a URL, a file path, or raw bytes, so you can forward uploaded
bytes straight through:

```python
from audd import AudD

audd = AudD("your-api-token")  # get a token at dashboard.audd.io

matches = audd.recognize_enterprise(
    "https://audd.tech/example.mp3",
    return_metadata=["apple_music"],  # optional; adds streaming links
    limit=10,                          # always cap metered chunks in dev
)

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

A clean file returns an empty list — not an error. Your application logic then
decides what to do with each match: flag for review, auto-mute, block
publication, notify the uploader, or log for reporting.

> **Always set `limit` during development.** The enterprise endpoint bills per
> 12 seconds of audio processed. An unbounded call on a multi-hour upload can
> meter hundreds of matches. Start small and raise it only once you understand
> the cost on your real inputs.

### Step 4: Apply confidence thresholds

Not every match is equally reliable. On a Startup plan or higher each match
carries a `score`; a non-null `label` is a strong signal that the track is a
commercial release. High-confidence matches can trigger automated actions;
lower-confidence ones can route to human review:

```python
def decide(matches):
    if not matches:
        return "publish"          # nothing recognized
    if any(m.label for m in matches):
        return "block"            # a labelled (commercial) track
    return "review"               # recognized but ambiguous
```

A system that auto-removes content on weak matches generates complaints; one
that acts only on perfect matches misses real violations. Build with that
tension in mind.

### Step 5: Build an appeals flow

Users will dispute matches — because the detection was wrong, because they
believe they hold a license, or because they think the content is fair use. You
need a process that does not pull in engineering every time: a simple form that
captures the user's explanation, routes to a moderation queue, and lets a human
make the final call is enough for most platforms starting out.

## What to look for in a detection API

- **Database coverage.** A larger, more current database means fewer missed
  matches. AudD covers 160 million songs.
- **Accuracy in both directions.** False negatives create compliance exposure;
  false positives create user-experience problems. Both matter.
- **Latency and throughput.** Pre-publication detection puts recognition time
  directly in the upload path, and high-volume platforms need to scale.
- **Stream support.** If you handle live video or audio, you need real-time
  stream analysis, not just file uploads.
- **Metadata quality.** The match is only as useful as what it returns. ISRC,
  label information, and streaming links matter for rights-holder reporting,
  user-facing attribution, and internal auditing.

## Reading undocumented or beta fields

The AudD response carries more than the typed properties the SDK models. Any
field the API returns that does not have a dedicated property — including newer
or beta fields — is available on the result. In Python it comes through the
model's `model_extra` map; in Node it is on `extras`. If a future field matters
to your verdict, you can read it without waiting for an SDK update.

## Compliance considerations beyond detection

Detection is necessary but not sufficient.

**DMCA safe harbor requires more than technology.** It protects platforms from
liability for user-uploaded infringing content only under specific conditions —
a registered DMCA agent, prompt response to takedown notices, and action on
infringement you have actual knowledge of. Detection supports your position; it
does not replace the legal and procedural requirements. Involve legal counsel
in how you design your program.

**Licensing is a different problem than detection.** Detecting copyrighted music
tells you what is there; it does not give you the right to host it. Some
platforms license catalogs directly and check detected matches against their
licensed set, flagging only the unlicensed ones.

**Regional rights are complex.** Music rights are licensed territorially. If you
operate globally, the same match may call for different actions in different
markets.

## Where to start

Detecting copyrighted music in UGC is a solvable problem, but it is an
engineering and operational challenge, not only a legal one. The platforms that
handle it well build detection into the upload pipeline early, choose an API
with real catalog coverage and reliable matching, and pair automated detection
with a sensible human-review process for edge cases.

If you are building a UGC platform and need a reliable way to identify
copyrighted music in uploaded content, get a token at
[dashboard.audd.io](https://dashboard.audd.io) and start with the recipe below.

---

**Related**

- [Build a copyright scanner for user-uploaded content](/resources/recipes/ugc-copyright-scanner)
- [Standard, enterprise, or streams: how to choose](/resources/concepts/standard-vs-enterprise-vs-streams)
- [Generate DMCA takedown evidence](/resources/recipes/dmca-takedown-evidence)
- [API reference](https://docs.audd.io)