Skip to content

Radio/audio broadcast format support and loudness requirements #2072

@bokelley

Description

@bokelley

Parent: #1919
Related: #2037 (broadcast TV spot formats), #2036 (Ad-ID)

Problem

The protocol has broadcast TV spot formats but no radio/audio broadcast formats. Radio broadcast shares structural similarities with TV broadcast (no impression pixels, physical delivery, Ad-ID, measurement windows) but differs in creative formats and loudness standards.

Additionally, the audio asset requirements schema (audio-asset-requirements.json) has no loudness fields at all. The audio reference formats (audio_standard_15s, audio_standard_30s, audio_standard_60s) don't declare loudness requirements. This means a creative agent has no schema-level guidance on loudness for any audio format.

Loudness Standards (from Sam Sousa / AES TD1008)

Per AES Technical Document TD1008 v3.13, recommended loudness targets vary by distribution:

Context Target LUFS Tolerance Standard
OTA Broadcast TV -24 ±2 dB ATSC A/85
Audio ads / interstitials -18 ±2 dB AES TD1008
Streaming/SSAI audio -16 to -18 Platform-specific Varies
Podcast -16 ±1.5 dB Spotify/Apple guidance

Key insight from Sam: -24 LUFS is correct for OTA broadcast TV but too quiet for audio-only and digital distribution. Creative reuse across channels (a spot made for TV also running on streaming audio) means the source should be at -18 LUFS. Playout systems normalize anyway, but starting louder prevents quality loss from normalization up.

Greg confirmed: CTV and broadcast TV both manage audio levels at playout. But SSAI for live streaming handles it in the delivery stack, not always at playout — making source loudness more important.

Proposal

1. Add loudness fields to audio-asset-requirements.json

"loudness_lufs": {
  "type": "number",
  "description": "Target integrated loudness in LUFS (e.g., -18 for audio ads per AES TD1008, -24 for broadcast TV per ATSC A/85)"
},
"loudness_tolerance_db": {
  "type": "number",
  "minimum": 0,
  "description": "Acceptable deviation from loudness_lufs target in dB"
},
"true_peak_dbfs": {
  "type": "number",
  "description": "Maximum true peak level in dBFS (e.g., -1 for audio, -2 for broadcast TV)"
}

2. Add loudness to audio reference formats

Update audio_standard_15s, audio_standard_30s, audio_standard_60s with loudness_lufs: -18 per AES TD1008.

3. Radio broadcast formats

Add reference formats for radio broadcast spots, following the same pattern as TV broadcast:

  • :15, :30, :60 radio spots
  • Audio file only (MP3/AAC/WAV), no VAST/DAAST, no impression trackers
  • Ad-ID support (same industry_identifiers field)
  • Loudness at -18 LUFS per AES TD1008
  • 48kHz stereo, minimum 192kbps

4. Radio broadcast measurement

Radio measurement has its own characteristics (different from TV):

  • Nielsen Audio (PPM panels in top markets, diary in smaller markets)
  • Measurement windows may differ from TV's C3/C7 model
  • Needs input from radio sellers on how measurement data arrives

5. Documentation

  • Add docs/creative/channels/radio.mdx (or extend existing audio docs)
  • Add loudness guidance table to docs/creative/channels/audio.mdx and docs/creative/channels/video.mdx referencing AES TD1008

Open questions

  • Should radio broadcast be a separate channel doc or a section within the existing audio.mdx?
  • Do radio stations use Ad-ID or a different creative identifier system?
  • What does radio measurement data look like? (Nielsen Audio PPM vs diary)
  • Should we define separate loudness profiles by distribution context (OTA broadcast, streaming SSAI, podcast DAI)?

References

  • AES TD1008 v3.13 — Audio loudness for interstitials/advertisements
  • ATSC A/85 — US broadcast TV loudness standard
  • EBU R128 — European broadcast loudness standard

Metadata

Metadata

Assignees

No one assigned

    Labels

    claude-triagedIssue has been triaged by the Claude Code triage routine. Remove to re-triage.rfcProtocol change — auto-adds to roadmap board

    Type

    No type

    Projects

    Status

    No status

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions