Years of streaming leave an archive: past broadcasts, highlights, clips, the “starting soon” loop with whatever playlist was on that night. If you want to know which recorded songs are in that archive and where, this recipe scans it with AudD and gives you a list per file: timestamp, artist, title, label. From that list you decide what to mute, trim, or delete, and you keep a record of the decision.
What this does and doesn’t tell you. AudD matches audio against its own database of about 160 million commercially released songs. Streaming platforms run their own detection against their own reference files and rules. AudD’s results don’t predict what a platform will flag, and a file with no AudD match can still be flagged (and the other way round). Use the scan to learn what’s in your archive. Whether a given use is licensed or allowed is a separate question; this page is not legal advice (as of 2026-10-12).
What this does and doesn’t tell you. AudD matches audio against its own database of about 160 million commercially released songs. Streaming platforms run their own detection against their own reference files and rules. AudD’s results don’t predict what a platform will flag, and a file with no AudD match can still be flagged (and the other way round). Use the scan to learn what’s in your archive. Whether a given use is licensed or allowed is a separate question; this page is not legal advice (as of 2026-10-12).
What you’ll build
- A scan of a folder of VODs and clips, sampled to keep cost down.
- archive-music.csv: one row per music segment per file, with start and end times in the file and the track details.
- A decision column you fill in (keep, mute, trim, delete), and an append-only log of what was scanned, with which settings, and what you did about it.
There are two ways to run the scan: the AudD CLI, with no code, or a short Python script when you want the segment list and the log built for you. Both use the enterprise endpoint, which takes files of any length and returns every match with its position in the file.
Prerequisites
- An API token. Get your own token at dashboard.audd.io. ISRC and UPC in results require a Startup plan or higher; artist, title, album, and label come back without them.
- For the CLI path: the AudD CLI (brew install auddmusic/tap/audd, npm install -g @audd/cli, pipx install audd-cli, or another option on that page).
- For the script path: Python 3.10+ with pip install audd, and ffmpeg / ffprobe on your PATH.
Step 1: Get the files
Download your own past broadcasts and clips with the download or export option in your platform’s creator dashboard. Most platforms keep past broadcasts for a limited time, so download what you want to keep before it expires. Only scan content you own or manage for the channel.
Video files are large, and AudD only needs the audio. Extracting the audio track first makes uploads much smaller and faster:
Timestamps in the audio file are the same as in the video, so results map straight back. The CLI and the SDK also accept video files directly if you’d rather skip this step.
Step 2: Budget the scan
The enterprise endpoint is billed one request per 12 seconds of audio it processes. One hour of audio is 300 chunks. every and skip let you recognize some chunks and skip the rest: every=1, skip=4 recognizes 12 seconds out of each minute.
Clips are short, so full coverage is cheap: a 45-second clip is 4 chunks, and 500 of them cost about 2,000 requests.
Sampling finds music that plays for a while: a playlist under gameplay, a DJ segment, the “starting soon” loop. It can miss anything shorter than the gap between probes, such as an alert sound or a song someone played for 20 seconds. A practical plan for VODs is a sampled first pass over everything, then a full-coverage rescan only around the places where the first pass found music (Step 4). For clips, use full coverage.
Don’t use skip_first_seconds to skip the “starting soon” screen. Music under a waiting screen is one of the most common things you’ll find.
Step 3: Scan with the CLI
Preview the plan and the request estimate first. --dry-run sends nothing.
--limit is the most chunks recognized per file. With --skip 4 a 6-hour VOD needs about 360 recognized chunks, so --limit 400 covers it with a little room. --max-files caps how many files the batch takes. Then run it and write CSV:
--max-requests stops the run before it spends more than that. The batch is saved after each file, so if it stops (budget reached, Ctrl-C, dropped connection), audd jobs list shows it and audd jobs resume <id> continues with the files that are left. Results are cached by file contents, so re-running the same file doesn’t spend requests again.
The CSV has one row per match, with input, status, artist, title, album, label, isrc, upc, song_link, score, start_seconds, and end_seconds (positions in the file). Files with no match get a no_match row, so you can tell “scanned, nothing found” from “not scanned”.
For clips, drop the sampling:
To look at one VOD in detail, --tracklist merges consecutive matches into tracks with start and end times:
Step 4: Scan with Python and build segments
The script does the same sampled scan, merges probes of the same track into segments, and then rescans a window around each segment at full coverage to get its real start and end.
start_seconds and end_seconds are positions in your file, in seconds. The SDK requests accurate offsets by default and works them out from the chunk position and the offset inside the chunk.
After a sampled pass, a segment’s edges are only known to within one probe gap: the song may have started up to a minute before the first probe that caught it. To find the real edges, cut a window around the segment locally and scan that window at full coverage:
Refining a 3-minute song costs about 25 chunks: the song plus a minute on either side. On a 4-hour VOD that is mostly talk and gameplay, the sampled pass (240 chunks) plus a few refinements stays well under full coverage (1,200 chunks).
The refined pass can also find a different song in the window (the playlist moved on); that comes back as its own segment.
Step 5: Write the per-file list
Two segments of the same song can overlap after refinement when their windows overlap; drop exact duplicates before review, or merge rows of the same file and isrc whose times overlap.
Step 6: Decide what to do
Fill in decision per row. Common choices:
For muting or cutting locally, Flag and remove music in a live-event recording builds the ffmpeg mute filter and cut list from the same kind of segment list. Add a second or two of margin on each side of a segment before muting.
Step 7: Keep a record
Append one line per file to a log each time you scan or act on it. Months later, it tells you what was checked, with what settings, and what you did.
Record the sampling settings with every scan. A sampled scan with no match means “nothing found at the probed points”, not “no music in the file”.
Limits to keep in mind
- AudD identifies recordings. It doesn’t recognize a song you sang or played live, a cover, or a remix that isn’t itself a released recording.
- Music quiet under loud voice or game audio may not match.
- Matches come from AudD’s catalog only; tracks not in it come back as no match.
Handling errors
- AudDAuthenticationError: bad token. Stop and fix it.
- AudDQuotaError: out of requests. Top up, then rerun; with the CLI, audd jobs resume <id>.
- AudDInvalidAudioError: a file couldn’t be decoded. Re-download or re-extract its audio.
- AudDConnectionError: transient; retry that file. Cancelling a request mid-flight might still consume requests.
- Flag and remove music in a live-event recording
- AudD for Twitch streamers
- Identify music from the command line with the AudD CLI
- Controlling enterprise endpoint cost
- Enterprise response and match fields
- AudD CLI reference
