Standardize Uploaded Audio for Reliable Playback

At a glance

How the workflow fits together

A supported upload becomes a consistent, playable file in four managed steps. Processing must complete before playback, so your application waits for the track to become ready and then requests the variant by name.

Supported source audio (WAV, FLAC, MP3, ...)
        |
        v
Upload to AudioDN
        |
        v
AudioDN processes the track      (track_status_id: processing)
        |
        v
Configured variant generated     (track_status_id: ready)
        |
        v
Play the same named variant on web, mobile, or server

1. Configure the output first

The transcode variant is the feature this example is really about. A variant is a reusable recipe that tells AudioDN how to turn any supported upload into a specific output. Configure it once and AudioDN generates that same named variant for new uploads automatically — your code never has to detect or special-case the source codec, and it always requests the result by the same name.

Why AAC at 128 kbps

AAC is a practical default for general web and app playback: it is broadly supported across modern browsers, mobile operating systems, and media players, and 128 kbps strikes a useful balance of quality, file size, and streaming performance for typical listening. AudioDN delivers this variant with the content type audio/aac. If your product needs different trade-offs, configure a different codec or bitrate, or add more variants — see Variant Types.

2. Upload the source

It does not matter how the file arrives — a lossless studio master, a compressed voice memo, or whatever a listener’s phone produced. The upload is a short, explicit sequence: create a session (optionally with a nested track to create the first track up front), create any additional tracks, PUT the bytes to the track’s upload URL, then wait until the track is ready.

POST /v1/upload_session                       -> upload_session_id
  (optional nested track object)               -> also track_id + track_upload.upload_url
POST /v1/upload/{upload_session_id}/track     -> track_upload.upload_url  (per additional file)
PUT  {track_upload.upload_url}                  (send the source bytes)
GET  /v1/track/{track_id}                       (poll until track_status_id = ready)
Request the configured variant                 (e.g. variants="aac")

Then poll GET /v1/track/:track_id until track_status_id is ready, or listen for a track webhook, before starting playback.

# COLLECTION_ID: uuid of the collection to upload into
curl -X POST "https://api.audiodelivery.net/v1/upload_session" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "collection_id": "COLLECTION_ID",
  "expires_in": 7200
}'

// COLLECTION_ID: uuid of the collection to upload into

const payload = {
  "collection_id": "COLLECTION_ID",
  "expires_in": 7200
};

const response = await fetch('https://api.audiodelivery.net/v1/upload_session', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify(payload)
});

const data = await response.json();

# COLLECTION_ID: uuid of the collection to upload into

import requests

headers = {
    "Authorization": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
}

payload = {
    "collection_id": "COLLECTION_ID",
    "expires_in": 7200
}

response = requests.post(
    "https://api.audiodelivery.net/v1/upload_session",
    headers=headers,
    json=payload,
)
data = response.json()

# SESSION_ID: upload_session_id returned by the previous call
curl -X POST "https://api.audiodelivery.net/v1/upload/SESSION_ID/track" \
  -H "Content-Type: application/json" \
  -d '{
  "file_name": "track.wav"
}'

// SESSION_ID: upload_session_id returned by the previous call

const payload = {
  "file_name": "track.wav"
};

const response = await fetch('https://api.audiodelivery.net/v1/upload/SESSION_ID/track', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify(payload)
});

const data = await response.json();

# SESSION_ID: upload_session_id returned by the previous call

import requests

headers = {
    "Content-Type": "application/json",
}

payload = {
    "file_name": "track.wav"
}

response = requests.post(
    "https://api.audiodelivery.net/v1/upload/SESSION_ID/track",
    headers=headers,
    json=payload,
)
data = response.json()

# After create-track returns track_upload.upload_url, PUT the source bytes.
# Any supported source format works, regardless of its original quality or codec.
curl -X PUT "$UPLOAD_URL" \
  --data-binary @track.wav \
  -H "Content-Type: audio/wav"

npm install @audiodn/components

<script type="module" src="https://unpkg.com/@audiodn/components@latest/dist/uploader.js"></script>

<script type="module">
import '@audiodn/components/uploader';
</script>

<audiodn-uploader
api-key="YOUR_UPLOAD_API_KEY"
collection-id="COLLECTION_ID"
></audiodn-uploader>

3. Play the variant

Once the track is ready, every surface your product ships to requests the exact same variant by name and gets the exact same predictable file — no format detection, no per-platform special-casing. The fastest path on the web is the <audiodn-player> component with a Client-Side Player key:

npm install @audiodn/components

<script type="module" src="https://unpkg.com/@audiodn/components@latest/dist/player.js"></script>

<script type="module">
  import '@audiodn/components/player';
</script>

<audiodn-player
  api-key="YOUR_PLAYER_API_KEY"
  scope="track"
  id="TRACK_ID"
  variants="aac"
  size="regular"
></audiodn-player>

Live demo

The homepage hero track, played here from its single standardized aac variant.

Request the same variant anywhere

The player is optional. Custom web, mobile, Flutter, native, and server applications can create a play session and stream the returned signed URL for the same named variant, or sign delivery URLs directly for backend playback.

• Website / custom player — embed <audiodn-player>, or request the file for your own UI. See the Web Integration guide.

• Mobile app — create a play session requesting the aac variant from Swift, Kotlin, or Flutter, then stream the signed URL with any platform audio player. See Mobile Integration.

• Server / API — sign delivery URLs for backend-to-backend playback or downloads. See Signed Delivery and the Variants API.

More player options (themes, sizes, playlists, cover art): Player component docs.

When to use this workflow

Reach for this whenever your product accepts audio you do not control and needs it to play back consistently. That covers uploads from users, artists, phones, browsers, recording devices, editing software, external systems, and multiple production tools at once.

It fits music platforms, podcasts, voice recordings, social audio, educational products, marketplaces, AI-generated audio apps, and other user-generated audio products. In each case AudioDN can replace the custom infrastructure you would otherwise operate: upload storage, processing queues, FFmpeg workers, output storage, delivery signing, and playback delivery.

What this example does not cover

This example focuses on producing one consistent playback format from inconsistent uploads. The following are related but separate capabilities, not part of this workflow:

• Preview clips — short, seek-restricted excerpts. See Preview clip player.
• Waveforms — waveform image or video variants. See Variant Types.
• Additional variants — extra bitrates or codecs alongside aac for multi-quality delivery.
• Lossless downloads — offering FLAC or WAV downloads from the same upload.
• Loudness normalization — AudioDN does not perform LUFS targeting or gain adjustment; this workflow standardizes format, not loudness.

FAQ

Checklist

• An aac transcode variant recipe exists at 128 kbps (configured once in the dashboard, or added to a single track via POST /v1/track/:track_id/variant).
• A supported source file uploaded — via the API or the <audiodn-uploader> component — and reached track_status_id ready.
• Player is scoped to the track, requesting the aac variant with a Client-Side Player key.
• The same aac variant is requested consistently across web, mobile, and server integrations.