Enterprise response and match fields

Source: AudD•

Enterprise response and match fields

The chunked response shape of the AudD enterprise endpoint (enterprise.audd.io): per-chunk offset, per-song score, ISRC/UPC, accurate offsets, and the request parameters that control chunking.

Reference

The chunked response shape of the AudD enterprise endpoint (enterprise.audd.io): per-chunk offset, per-song score, ISRC/UPC, accurate offsets, and the request parameters that control chunking.

view .md auddenterpriseoffsetstart_offset

The enterprise endpoint (POST https://enterprise.audd.io/) processes longer audio — full-length songs, short-form videos, podcasts, broadcasts, DJ sets — by splitting the file into 12-second chunks server-side and returning every recognized track. Its response is shaped differently from the standard endpoint: result is an array of chunks, each carrying its position in the file and the songs found in it. This page documents that shape, the per-song fields, and the request parameters that control chunking. For the single-object standard response, see the recognition result fields reference.

Response shape

result is an array. Each element is one chunk:

The top level also carries execution_time (a string such as "159.226763ms"), and status is "success" as usual.

Song fields

Each entry in a chunk’s songs array:

offset vs. start_offset / end_offset

These two locate a match at different scales, and confusing them produces timestamps that are off by minutes.

  • offset (on the chunk) is the position in the file you submitted of the start of the 12-second fragment that contains the match, formatted MM:SS or HH:MM:SS. It places the chunk in the overall file.
  • start_offset / end_offset (on the song, only with accurate_offsets=true) are positions in milliseconds within that 12-second fragment — not file seconds. They range from 0 to about 12000.

To get the file-absolute position of a match, parse the chunk offset to seconds and add the song’s start_offset divided by 1000:

For a chunk with offset "04:48" and a song with start_offset 3520, the match begins at 288 + 3.52 = 291.52 seconds into the file.

Request parameters

Sent as multipart/form-data. Supply audio with url (a file or page URL the server fetches) or file (a multipart upload). api_token is required on every request.

Always set limit during development. The enterprise endpoint bills per 12 seconds of audio processed; an unbounded call can ingest hours of audio before it returns. Set limit to a small number while testing.

Always set limit during development. The enterprise endpoint bills per 12 seconds of audio processed; an unbounded call can ingest hours of audio before it returns. Set limit to a small number while testing.

Notes

  • result is an array, not an object. Iterate chunks, then iterate each chunk’s songs.
  • A chunk can return multiple songs. Lower-score entries in the same chunk are usually overlapping or blended audio rather than separate placements.
  • The typed SDKs flatten the chunk array into a single list of matches, but each match carries the file-absolute position for you as start_seconds and end_seconds (seconds into your file). They apply the offset + start_offset/1000 formula above internally, and request accurate_offsets=true by default, so those seconds are precise — you don’t need the raw response or the chunk offset to place a match. The raw start_offset/end_offset remain available as the fragment-relative milliseconds. Use the formula directly only when calling the HTTP API yourself.
  • score, isrc, and upc require a Startup plan or higher. On lower plans these fields are absent from the response.
  • start_offset/end_offset are present only when the request sets accurate_offsets=true.
  • Enterprise cost control
  • Build a DJ set tracklist
  • Assemble DMCA takedown evidence
  • Recognition result fields
  • Glossary
  • API reference

Reading this as an AI agent? The raw Markdown is at reference/enterprise-match-fields.md, and the full index is /resources/llms.txt.

What this article says