Audio formats and quality for music recognition

Music recognition works by fingerprinting the audio you send and matching that fingerprint against AudD’s database of 160 million songs. This page covers which formats AudD accepts, the file-size limits on each endpoint, and how clip length, sample rate, channels, and compression affect whether a clip matches. It’s for anyone preparing audio — a microphone recording, an uploaded file, or a captured stream — before sending it to the API.

TL;DR

The standard endpoint (api.audd.io) takes a short audio clip — a few seconds is typically enough — and answers in under 2 seconds. The file must be 10 MB or smaller.
Accepted audio formats: MP3, WAV, FLAC, M4A, OGG, AAC, WMA, AIFF.
For longer audio (full songs, podcasts, broadcasts, DJ sets) or for video, use the enterprise endpoint (enterprise.audd.io). It accepts the same audio formats plus video — MP4, AVI, MOV, MKV, WebM — and has no practical file-size cap.
The fingerprinting is tolerant of lossy compression and background noise. It is not magic: a very short clip, or one buried in noise, may not match.
Send the cleanest few seconds you have. You don’t need to upsample, convert to lossless, or strip the file down first.

Why this matters

Recognition either returns a match or it doesn’t, and the quality of the audio you send is one of the things you control. The database, the fingerprint algorithm, and the endpoint are fixed; the clip is yours to prepare. Two clips of the same song can produce different outcomes — one clean and a few seconds long, the other a one-second snippet under heavy crowd noise — and the difference is entirely in the input.

The good news is that you rarely need to do much. The fingerprint is built to survive the things that happen to audio in the real world: MP3 compression, phone-speaker playback, room reverb, and moderate background noise. You do not need studio-quality audio. What you do need to avoid is the opposite extreme — a clip so short or so degraded that there isn’t enough signal to fingerprint.

The second thing that matters is picking the right endpoint. The standard endpoint is built around a short clip and enforces a 10 MB cap. If you try to push a full-length song or a video file through it, you’ll either exceed the cap or send far more audio than a single recognition needs. That’s what the enterprise endpoint is for.

Accepted formats

Audio

The standard and enterprise endpoints both accept these audio formats:

Format	Typical extension
MP3	`.mp3`
WAV	`.wav`
FLAC	`.flac`
M4A	`.m4a`
OGG	`.ogg`
AAC	`.aac`
WMA	`.wma`
AIFF	`.aiff`, `.aif`

You do not need to convert between these before sending. If you have a FLAC file and an MP3 of the same recording, either one works — sending the FLAC does not meaningfully improve the match, and converting a lossy MP3 up to FLAC adds nothing, because the information lost in compression is already gone.

Video (enterprise endpoint)

The enterprise endpoint additionally accepts video files and extracts the audio track server-side:

Format	Typical extension
MP4	`.mp4`
AVI	`.avi`
MOV	`.mov`
MKV	`.mkv`
WebM	`.webm`

This is what makes the enterprise endpoint the right tool for scanning user-uploaded videos or short-form clips: you send the video as-is and don’t have to demux the audio yourself. Video goes to enterprise.audd.io, not the standard endpoint.

File size and the 10 MB cap

The standard endpoint caps each request at 10 MB. That’s a clip limit, not a song limit — it’s sized for the short clip the standard endpoint is designed around, not a full track.

For a short clip this is rarely a constraint. As a rough sense of scale, a few seconds of MP3 audio is well under a megabyte; even a minute of CD-quality WAV is a few megabytes. You hit the cap when you try to send something the standard endpoint isn’t meant for — a whole song as uncompressed WAV, or a video file.

When you have more audio than fits, you have two options:

Trim to a short clip and send it to the standard endpoint. A few seconds from the middle of the song is plenty.
Use the enterprise endpoint, which has no practical file-size cap, chunks the file server-side, and can return a match per recognized segment. Choose this when you genuinely need to process the whole file (a podcast, a DJ set, a long upload) rather than identify one song from a snippet.

The 10 MB cap is a standard-endpoint limit, not an enterprise one. If a long file is bumping into the cap, that’s usually a signal you want the enterprise endpoint instead of trimming. The enterprise endpoint bills per 12 seconds of audio processed, so always set limit during development.

Clip length

For the standard endpoint, a few seconds is typically enough. The fingerprint matcher needs enough of the recording to lock onto, and a short clip of clean audio usually provides it.

Two practical points:

Very short clips may not match. A one-second fragment may not contain enough distinctive signal, especially if it lands on a quiet intro, a breakdown, or a section that sounds like many other songs. If a very short clip comes back with result: null, sending a slightly longer clip is the first thing to try.
Longer is not always better on the standard endpoint. Once you’ve sent enough audio to identify the song, adding more doesn’t improve the result — and a long clip risks the 10 MB cap. Send a representative few seconds, not the whole track.

Capture the clip from a part of the song with clear musical content rather than silence, an a-cappella whisper, or pure ambient noise. The middle of a song is usually a safe bet.

result: null means “no match,” not “error.” On the standard endpoint, a clip that doesn’t match returns result: null with a success status. Treat that as a distinct, expected outcome — for example, prompt the user to record a longer or cleaner clip — rather than as a failure.

Sample rate, channels, and compression

These are the input characteristics people most often worry about. In practice none of them require special handling.

Sample rate

You don’t need to upsample. Recordings at common rates — phone, laptop, and CD-quality sources — carry enough of the frequency range the fingerprint relies on. Converting a low-rate recording to a higher sample rate doesn’t add information that wasn’t captured, so it won’t rescue a clip that was recorded badly. Send the audio at whatever rate it was captured.

Mono vs stereo

Mono is fine. The fingerprint does not depend on a stereo image, so a single-channel microphone recording works as well as a stereo file. If your capture pipeline gives you mono (most microphone inputs do), there’s no need to fake a second channel.

Lossy compression

Lossy formats — MP3, AAC, M4A, OGG, WMA — are fully supported and are the common case. The fingerprint is built to tolerate the artifacts lossy codecs introduce. You do not need to convert to a lossless format before sending; re-encoding a lossy file to FLAC or WAV cannot restore detail the original encoding discarded, so it only makes the file bigger.

Where compression starts to matter is at the extremes: audio that has been encoded at a very low bitrate, re-compressed several times, or run through aggressive noise reduction can lose enough detail that the fingerprint weakens. If you have a choice between a heavily re-compressed copy and a cleaner source, use the cleaner one — but ordinary compression is not a problem.

Background noise

Recognition tolerates a fair amount of background noise — talking, traffic, room ambience — because the fingerprint keys on the music’s structure rather than on a pristine signal. That tolerance has limits: heavy background noise reduces match confidence, and a clip where the music is buried under louder noise may not match at all. When you control the capture, get the source music as loud and clear in the recording as you reasonably can.

Worked example

Two common situations: a live microphone recording, and a file you already have on disk.

Preparing a microphone recording

You’re capturing a few seconds from a microphone — a phone, a laptop mic, a USB input — and sending it to the standard endpoint.

Record a few seconds, not one. Aim for a short clip with clear musical content rather than the briefest possible snippet. If the first attempt returns result: null, record a slightly longer clip before assuming the song isn’t in the database.
Don’t fight the format. Mono is fine, the device’s native sample rate is fine, and a compressed format (M4A, AAC, MP3) is fine. Save the conversion work.
Favor a clean moment. Capture while the music is playing clearly, not over a gap or under a sudden burst of crowd noise.
Send it. A few seconds of typical microphone audio is well under the 10 MB cap, so the standard endpoint is the right endpoint.

from audd import AudD

audd = AudD("test")  # 10 requests/day; get your own token at dashboard.audd.io

# A few seconds captured from a mic, saved in any accepted format.
result = audd.recognize("clip.m4a")

if result is None:
    print("No match — try a longer or cleaner clip.")
else:
    print(f"{result.artist} — {result.title}")

Preparing a file upload

You have an audio file on disk and want to identify it.

If it’s a short clip and under 10 MB, send it to the standard endpoint as-is, in whatever format it already is.
```
result = audd.recognize("https://audd.tech/example.mp3")
print(result.title if result else "No match")
```
If it’s a full-length song, a podcast, a broadcast, or a video — or it’s over 10 MB — send it to the enterprise endpoint instead. It chunks the file server-side and can return a match per recognized segment. Set limit while developing so a long file doesn’t process more audio than you intend.
```
matches = audd.recognize_enterprise(
    "full-episode.mp3",
    limit=10,  # cap matches while developing — enterprise bills per 12s
)
for m in matches:
    print(f"{m.timecode}  {m.artist} — {m.title}")
```

In neither case do you transcode the file first. Pick the endpoint that fits the length of the audio, send the file in its existing format, and let the server do the decoding.

Common mistakes

Sending a whole song to the standard endpoint. A full track as uncompressed WAV will often exceed 10 MB, and even when it fits you’re sending far more than a recognition needs. Trim to a few seconds, or use the enterprise endpoint.
Upsampling or converting to lossless “for accuracy.” Converting a phone recording to a higher sample rate, or a lossy file to FLAC, adds file size without adding information. Send the audio as captured.
Sending a one-second snippet and treating result: null as a hard “not in the database.” A very short clip may simply not carry enough signal. Try a longer clip before concluding the song is unknown.
Treating result: null as an error. On the standard endpoint, no match is a successful response with result: null — distinct from an error status. Handle the two separately.
Reaching for the standard endpoint for video. Video formats are only accepted on the enterprise endpoint, which extracts the audio for you.
Aggressive pre-processing. Heavy noise reduction or low-bitrate re-encoding can strip detail the fingerprint relies on. If you have a cleaner source, prefer it over a heavily processed copy.

Related