AudD tells you which recordings it found in an upload, where they play, and how confident the match is. It doesn’t decide whether the upload may go live. That decision depends on things only your platform knows: which music you’ve licensed, who uploaded the file, where it will be shown, and how much a wrong call costs you. This page lists the inputs an AudD result gives you, shows how to turn enterprise results into numbers a policy can use, and works through a decision table with code.
This page describes engineering patterns, not legal requirements. It is not legal advice. Notice-and-takedown, Article 17, and DSA obligations differ by service and country; check them with counsel. As of October 12, 2026.
This page describes engineering patterns, not legal requirements. It is not legal advice. Notice-and-takedown, Article 17, and DSA obligations differ by service and country; check them with counsel. As of October 12, 2026.
TL;DR
- Separate the two steps: recognition produces facts (matches, scores, offsets); a versioned policy turns facts plus your own context into an action.
- From one enterprise scan you can compute, per matched track, how many seconds play, and for the whole upload, what share of it is matched music.
- Check your allow list first: licensed tracks, by ISRC or by custom-catalog audio_id.
- Typical actions: allow, record only, mute a segment, send to review, block.
- Every number on this page is illustrative. Calibrate on your own labeled uploads before you automate anything.
- No match means unknown, not cleared. See What music recognition matches.
Policy inputs from an AudD result
Your own data completes the picture: the uploader’s account history, whether the upload is monetized, the regions it will be shown in, and any license the uploader has on file with you.
The enterprise endpoint splits the file into 12-second chunks and returns a match for each chunk where it recognized something. With accurate_offsets (the Python SDK requests it by default), each match carries start_seconds and end_seconds: where the matched audio starts and ends in your file. A track that plays for two minutes comes back as a run of consecutive matches; merge their intervals to get the seconds it plays.
Notes on the numbers:
- Duration comes from you. Enterprise results don’t include the file’s length. Read it at ingest, for example with ffprobe -v error -show_entries format=duration -of csv=p=0 upload.mp4.
- Matched share needs every chunk. If you thin the scan with skip and every to save requests (see enterprise cost control), the unscanned chunks count as unmatched and the share comes out low. Thin scans are fine for a yes/no screen; use a full scan, with a limit that covers the file, when the share drives the decision.
- Seconds are approximate. Each match covers the part of a 12-second chunk that was recognized, so a continuous play can show small gaps at chunk boundaries. Treat matched seconds as a measurement with a margin, not an exact figure.
- The overall share uses the union of intervals, so two tracks overlapping in a transition aren’t counted twice.
Without the SDK
If you call the HTTP API yourself, request offsets and compute the file position from the chunk’s offset plus the song’s start_offset and end_offset, which are milliseconds within that 12-second chunk:
The enterprise match fields reference documents the full response shape.
A worked decision table
This example is for a video platform that has licensed a library of tracks for creators to use, takes reference files from some rights holders into its custom catalog, and doesn’t want to block uploads with a few seconds of background music. The numbers are placeholders.
Two adjustments that platforms commonly add: send to review instead of blocking when the uploader is new or has a clean history, and block instead of muting when the uploader has repeated violations (see Repeat uploaders).
The policy as code
The mute spans feed straight into ffmpeg’s volume filter; the live-recording recipe shows the command. The padding covers the approximate edges of each match.
Building the allow list
You have two ways to say “this music is fine here”:
- By identifier. Keep the ISRCs (Startup plan or higher) of the tracks you have licensed. List every version the license covers, since a remaster or edit can come back with a different ISRC. A match on artist and title can serve as a second check that sends near-misses to review.
- By custom catalog. Upload the licensed files themselves (or music your creators own) to your custom catalog and allow those audio_ids. This works for music that isn’t in the public database, such as a production library. If the same recording is also in the public database, a match may come back from either, so allow both the audio_id and the ISRC.
Review queues
Give reviewers what they need to decide quickly: the track name and song_link, the spans in the upload (as clock times they can jump to), the timecode in the matched track, the score, and the uploader’s history. Record the reviewer’s decision and reason next to the automated one. Review outcomes are your best calibration data: a high rate of “this was fine” at some score range means the act score is too low.
Appeals and disputes
Uploaders will dispute decisions, and some will be right: they licensed the track, they are the artist, or the match was another version of a recording they own. Plan for it:
- Show the uploader which track was found and where, so they can respond to something specific.
- Let them attach a license or explanation, and route it to a person.
- When an appeal succeeds because of a license, add an allow-list entry scoped to that uploader (and that track), not a global one.
- Re-run the policy, not the scan, when only the policy or the allow list changed. That’s why the raw matches are logged.
- Rights holders file disputes too, about uploads that didn’t match. Those go to review, and if they hold the recording, a custom-catalog upload of it can catch future re-uploads.
Logging decisions
Store enough to explain any decision later and to re-run it under a new policy:
Keep the policy version on every decision. When you change a threshold, you can then tell which decisions the old rule made and re-evaluate them. If your service has to give users a statement of reasons or run an internal complaint process (the EU Digital Services Act requires both from many platforms), these records are where that information comes from.
Repeat uploaders
AudD has no notion of your users; repeat-infringer handling lives in your database. Count confirmed violations (automated blocks that weren’t overturned, plus reviewer confirmations) per account within a time window, and let the count change the outcome: more review for a first offense, blocking instead of muting after repeated ones, account-level action after that. Remove a strike when an appeal succeeds.
Regional policy
Licenses are often territorial, and the laws on platform liability differ between countries. AudD returns the same result wherever the request comes from, and doesn’t know where the content will be shown or which territories a license covers. Model region in your policy: evaluate the decision per region using the licenses valid there, and restrict visibility by region where your platform supports it.
Calibrate before you automate
- Scan a few hundred real uploads and have people label the right action for each.
- Run your policy over the logged matches and compare.
- Adjust ACT_SCORE, REVIEW_SCORE, BLOCK_SHARE, and MUTE_MAX_SECONDS until automated blocks are almost never overturned, then bump the policy version.
- Start with “review” where you plan to “block”, watch the overturn rate, and switch to automatic action when the numbers support it.
Interpreting the recognition score covers the score part of this in more detail.
- What music recognition matches, and what it doesn’t
- Interpreting the recognition score
- Build a copyright scanner for user-uploaded content
- AudD for video platforms and UGC moderation
- Generate DMCA takedown evidence
- Enterprise response and match fields
- Music rights and recognition glossary