---
title: "Audio formats and quality for music recognition"
description: "Which audio and video formats AudD accepts, the 10 MB standard-endpoint cap, and practical guidance on clip length, sample rate, channels, and compression for reliable matches."
slug: "/resources/concepts/audio-format-and-quality"
section: "concepts"
keywords: [audd, audio format, audio quality, sample rate, music recognition]
---

# 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.

1. **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.
2. **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.
3. **Favor a clean moment.** Capture while the music is playing clearly, not
   over a gap or under a sudden burst of crowd noise.
4. **Send it.** A few seconds of typical microphone audio is well under the
   10 MB cap, so the standard endpoint is the right endpoint.

```python
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.

  ```python
  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.

  ```python
  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**

- [Standard, enterprise, or streams: how to choose](/resources/concepts/standard-vs-enterprise-vs-streams)
- [Build a Shazam-style "what's playing" feature](/resources/recipes/shazam-clone)
- [SDK docs](https://docs.audd.io/sdks)
- [API reference](https://docs.audd.io)