---
title: "Questions to ask before choosing a music recognition API"
description: "A buyer's checklist for evaluating any music recognition API: coverage, accuracy testing, inputs, long files and streams, private catalogs, metadata, policy control, pricing, limits, data handling, and integration, with what a good answer looks like and how to check it yourself."
slug: "/resources/articles/questions-to-ask-a-music-recognition-vendor"
section: "articles"
keywords: [audd, music recognition api, vendor evaluation, buyer checklist, audio fingerprinting, rfp questions, music recognition vendor]
---

# Questions to ask before choosing a music recognition API

Most music recognition APIs look alike from the outside: send audio, get back
a song. The differences show up later, on your audio, in your bill, and when
something goes wrong at 3 a.m. This checklist is grouped the way an evaluation
usually runs. Each question says why it matters and what a good answer looks
like, and most can be checked yourself in a day without waiting on a sales
call.

Where it helps to have a concrete reference point, AudD's own answer follows
in a short note. Ask every vendor the same questions, including AudD.

## Coverage

**Which music is in the reference database, and how big is it?**
A song that isn't in the database can't be matched, no matter how good the
algorithm is. A good answer gives a size, says what kind of music it covers
(commercial releases, production music, independent uploads), and admits where
coverage is thin. Verify it by building a list of tracks that matter to you,
including regional and niche releases, and checking how many come back.

*AudD:* about 160 million songs of commercially released music.

**How quickly do new releases become matchable?**
If you recognize charting music, a lag between release and matchability shows
up as misses on exactly the tracks users care about. Few vendors publish a
number. Test it: pick releases from the last few weeks and see whether they
match.

**What happens when there's no match?**
You want an explicit "no match" result, not the closest wrong song. Run clips
that you know aren't in any catalog (your own recordings, silence, speech) and
check what comes back.

*AudD:* no match is `result: null`, not a low-confidence guess.

## Accuracy and testing

**Can I test on my own audio before signing?**
This question matters most. Published accuracy figures are measured on the
vendor's audio. A good answer is a token you can get yourself, today, with
enough requests to run a real sample. The
[one-week pilot plan](/resources/articles/evaluate-music-recognition-on-your-audio)
covers how to build the sample and what to measure.

*AudD:* a public `test` token works on the standard endpoint for 10 requests a
day; get your own token at [dashboard.audd.io](https://dashboard.audd.io)
for a real sample.

**How was the published accuracy figure measured?**
Ask what audio it was measured on, how long the clips were, and how false
matches were counted. A match rate means little without the false-match rate
next to it. If the vendor can't say, measure both yourself.

**Is there a confidence score, and what does it mean?**
A score lets you treat a match differently depending on what a mistake costs:
block on high confidence, send the middle band to a human. A good answer
explains that the score is a relative signal, not a probability, and that you
should set thresholds on your own data. See
[interpreting the recognition score](/resources/concepts/score-thresholds).

*AudD:* each match carries a `score` on a Startup plan or higher.

**What doesn't it recognize?**
A vendor that can tell you its limits is easier to trust. Ask directly about
cover versions, live performances, humming, remixes and edits, heavily
pitch-shifted or sped-up audio, and music under loud speech. Then include
those cases in your test set.

*AudD:* recognition matches recordings. It does not detect covers, humming,
or interpolations, and does not identify AI-generated or voice-cloned audio.

## Inputs and formats

**Which audio and video formats are accepted, and are there size limits?**
Converting files before upload costs engineering time and compute. A good
answer lists formats and per-endpoint size caps. Verify by sending your actual
files, not a clean MP3.

*AudD:* the standard endpoint takes files up to 10 MB and analyzes the first
12 seconds; the enterprise endpoint also takes video files. Details in
[audio formats and quality](/resources/concepts/audio-format-and-quality).

**Can I send a URL instead of uploading bytes?**
If your media already sits in object storage or on a CDN, a URL saves an
upload hop.

**How does it handle phone recordings, noisy rooms, and music under speech?**
These are the inputs that break demos. No vendor can give you a meaningful
number for your audio, so test it: record the same songs in the conditions
your users will be in.

## Long files and streams

**How do you recognize a two-hour file with many songs in it?**
A short-clip endpoint returns one song. For DJ sets, podcasts, broadcasts, and
video, you need every match with its position in the file. Ask how long files
are split, what comes back for each match, and how it's billed.

*AudD:* the enterprise endpoint splits files into 12-second chunks and returns
every match with offsets; see
[standard, enterprise, or streams](/resources/concepts/standard-vs-enterprise-vs-streams).

**Can I control how much of a long file is processed?**
If you only need to know whether a file contains music, scanning every second
is waste. A good answer offers a cap and sampling controls you set per call.

*AudD:* `limit` caps the number of chunks; `skip` and `every` sample the file.
See [enterprise cost control](/resources/concepts/enterprise-cost-control).

**Can you monitor live streams, and how do results reach me?**
Ask which stream types are supported (HLS, Icecast, platform channels), whether
results are pushed to a webhook or pulled, and how stream failures are
reported.

*AudD:* streams cover HLS, Icecast, m3u/m3u8, Twitch, and YouTube; results go
to a callback URL or are read by longpoll. See
[callback vs longpoll](/resources/concepts/callback-vs-longpoll).

## Private catalogs

**Can I match against my own unreleased or private music?**
Labels, production-music libraries, and platforms with exclusive content often
need to recognize tracks that no public database has. Ask whether a private
catalog is available, how tracks are added, how a match from it is reported,
and whether it's priced differently.

*AudD:* a custom catalog is available with special access (email
[api@audd.io](mailto:api@audd.io)). Matches carry your own `audio_id`. See
[custom catalog vs the public database](/resources/concepts/custom-vs-public-db).

**Are uploads to the private catalog billed, and are they safe to retry?**
If uploads are metered, a client that blindly retries can pay twice. Ask how
to tell whether an upload went through.

## Metadata and identifiers

**What comes back with a match?**
Artist and title are table stakes. Reporting, licensing workflows, and catalog
deduplication need identifiers. Ask for a sample response and check it against
what your downstream systems expect.

*AudD:* artist, title, album, release date, label, and a song link; ISRC and
UPC on a Startup plan or higher; Apple Music, Spotify, Deezer, and MusicBrainz
data on request on the standard endpoint. Field list:
[result fields](/resources/reference/result-fields).

**Are identifiers gated by plan?**
If ISRC or a confidence score sits behind a higher tier, your pilot on a lower
tier won't show what production looks like. Ask, and test on the plan you'll
actually use.

**Does the API tell me who owns the rights?**
Usually not, and a vendor that implies it does is overselling. A label field is
not the rights owner. If you need ownership, plan for a separate source.
[ISRC codes explained](/resources/articles/isrc-codes-explained-for-music-apps)
covers what identifiers can and can't tell you.

## Policy control: who decides what happens on a match

**Does the API act on matches, or do I?**
Some systems block, mute, or claim content on their own rules. Others return a
match and leave the decision to you. Neither is wrong, but you should know
which one you're buying, because it decides who answers user appeals and who
can change the rule next week.

*AudD:* returns which recording matched plus metadata. Blocking, muting,
logging, or doing nothing is your code's decision. AudD does not license
music, file royalty reports, or take content down.

**Can I apply different rules to different content?**
A copyright filter and a "now playing" display want opposite thresholds from
the same score. If thresholds are set by the vendor, you lose that control.

**Can I re-run a decision without re-processing the audio?**
Store the raw match, not just your verdict. When your policy changes, you can
re-decide from stored results instead of paying to scan again.

## Pricing model and cost predictability

**What is the billing unit for each kind of input?**
Short clips, long files, and live streams usually bill differently. Get the
unit for each and convert every quote to the same terms: cost per thousand
typical inputs and cost per hour of audio.

*AudD:* standard is one request per call; enterprise is one request per 12
seconds of audio processed; streams are priced per stream. Current prices are
on [audd.io](https://audd.io); the reasoning behind each unit is in
[music recognition API pricing](/resources/articles/music-recognition-api-pricing).

**What does my peak month cost, not my average one?**
A product launch or a backlog import can multiply volume. Ask what happens when
you exceed a plan: overage billing, a hard stop, or a sales call.

**Can I cap what a single call spends?**
On duration-billed endpoints, one forgotten parameter on a multi-hour file can
cost more than a week of normal traffic. A per-call cap is the answer you
want.

**Is there a minimum commitment?**
Ask whether you can start on pay-as-you-go and move to volume pricing later,
and whether unused volume carries over.

## Limits and scale

**Are there rate limits?**
A rate limit decides how fast you can work through a backlog and whether a
traffic spike turns into errors. Ask for the number, whether it is per token
or per account, and how to raise it.

*AudD:* the standard endpoint has no rate limits; requests can run in
parallel. For a large volume, tell AudD in advance at
[api@audd.io](mailto:api@audd.io). The enterprise endpoint has a default limit
on concurrent requests per account, which AudD raises on request.

**What happens when a request fails or is cancelled?**
Ask which errors are safe to retry and whether a cancelled request is still
billed. Then make your client match.

*AudD:* cancelling mid-flight might still consume requests. Guidance in
[retry strategy](/resources/concepts/retry-strategy) and the
[error reference](/resources/reference/errors).

**Is there a status page or incident history?**
Ask how outages are announced and how quickly support responds during one.

## Data handling, GDPR, and retention

**What does a request contain, and is it personal data?**
If requests carry only audio and settings, the privacy analysis is simpler
than if they carry user identifiers. Ask what fields the API accepts and
whether the vendor identifies speakers or builds voice profiles.

*AudD:* a request carries the audio, your token, and recognition settings,
with no field for user identifiers. The analysis is in
[GDPR and music recognition](/resources/articles/gdpr-music-recognition).

**How long is the audio kept, and is it used for training?**
Get the answer in writing if your customers or your counsel will ask. A good
answer states retention for audio and for results separately.

*AudD:* enterprise customers can get an agreement confirming that audio is
removed immediately after processing and is not used to train models.

**Where is the audio processed, and is a DPA available?**
Some compliance frameworks require a named list of processing locations or a
signed DPA regardless of the legal analysis. Ask early, because contract work
takes longer than integration.

## Integration: SDKs, docs, test access, support

**Is there an official SDK in my language?**
An official SDK handles uploads, retries, and response parsing for you. Check
that it's maintained (recent releases, open issues answered) and that it
exposes the whole API, not only the basic call.

*AudD:* 11 official SDKs (Python, Node/TypeScript, Go, Rust, PHP, Swift,
Kotlin, .NET, Java, C, C++) and a command-line tool. See
[docs.audd.io/sdks](https://docs.audd.io/sdks) and
[docs.audd.io/cli](https://docs.audd.io/cli).

**Can I get a working call in ten minutes?**
Self-serve signup and a copy-paste example tell you how the rest of the
relationship will go. If the first step is a call with sales, ask why.

*AudD:* get your own token at [dashboard.audd.io](https://dashboard.audd.io);
the [getting-started walkthrough](/resources/articles/audd-api-getting-started-walkthrough)
runs a first recognition in a few lines.

**Are the docs complete, including errors and edge cases?**
Look for the full error code list, the response shape for no-match and
partial results, and the billing behavior of every parameter. Missing error
docs mean you'll learn them in production.

**Who answers when something breaks?**
Ask whether support is engineers or a ticket queue, which channels exist, and
whether you can talk to a person before you're a large customer. Send a
technical question during your evaluation and time the reply.

## Turning answers into a decision

Put each vendor's answers in one table and mark which ones you verified
yourself. Weight the verified ones. Then run the same labelled audio through
your shortlist; the [pilot plan](/resources/articles/evaluate-music-recognition-on-your-audio)
gives a script and a write-up template. For a side-by-side view of the market,
see [best music recognition APIs](/resources/articles/best-music-recognition-apis).

## FAQ

**What is the most important question to ask a music recognition vendor?**
Whether you can test the API on your own audio before you sign anything. Published accuracy figures are measured on someone else's audio. A self-serve token and a few hundred of your own labelled clips tell you more than any datasheet.

**Should I trust a vendor's accuracy percentage?**
Treat it as a claim about the vendor's test set, not your traffic. Ask what audio it was measured on and how false matches were counted, then measure match rate and false matches on a labelled sample of your own audio.

**Does a music recognition API tell me who owns the rights to a song?**
Usually not. A recognition API tells you which recording matched and returns metadata such as artist, title, label, and identifiers like ISRC and UPC. The label field is not the rights owner, and recognition is not a license. Ownership and licensing questions need a rights database or the rights holders themselves.

**How do I compare prices between vendors that bill differently?**
Convert every quote to cost per hour of your audio and cost per thousand of your typical inputs, using your real mix of short clips, long files, and streams. Then check what happens at your peak month and whether overages are billed or blocked.

---

**Related**

- [Run a one-week pilot on your own audio](/resources/articles/evaluate-music-recognition-on-your-audio)
- [Music recognition API pricing](/resources/articles/music-recognition-api-pricing)
- [Best music recognition APIs](/resources/articles/best-music-recognition-apis)
- [GDPR and music recognition](/resources/articles/gdpr-music-recognition)
- [Standard, enterprise, or streams: how to choose](/resources/concepts/standard-vs-enterprise-vs-streams)
- [Interpreting the recognition score](/resources/concepts/score-thresholds)

## Sitemap

See the [resources sitemap](https://audd.io/resources/sitemap.md) for every guide and the [glossary](https://audd.io/resources/reference/glossary.md) for AudD terms.