Tutorials Enterprise

Reading and Meeting a Delivery Specification

Professional · ~20 min

Overview

A delivery specification is a contract about the file, and rejections are expensive in both money and relationship. Specs are long, written defensively, and contain requirements in places people do not look, particularly around audio layout, timing, and metadata rather than the picture, which is the part everyone checks. This guide covers how to read one systematically, the sections that most often cause rejections, and how to verify a deliverable against the spec before it leaves.

What You Need

The actual current specification document, not a version from a previous job
A named contact at the recipient for questions, established early
QC tooling capable of checking the parameters the spec names
A checklist derived from the spec, not the spec itself, for the delivery pass
Time to fix a failure before the deadline, budgeted deliberately
A record of what you delivered and how it was verified

Steps

Get the current spec and confirm its version

Specifications are revised, and working from the version you used last year is a common and avoidable cause of rejection. Ask for the current document, note its version and date, and confirm it applies to this specific delivery, broadcasters frequently have different specs for different strands.

Read the audio section first, because that is where rejections come from

Everyone checks resolution and frame rate. Audio is where deliveries actually fail: required channel count and layout, which track carries which content, whether stems or mix-minus are required, loudness targets and true peak limits, and whether audio description or a clean effects track is expected. Read it twice.

Extract the timing and structure requirements

Specs usually define exactly what appears before and after programme content: bars and tone, a slate with specific fields, a countdown, the precise timecode at which programme starts, black at the head and tail, and part boundaries for programmes with breaks. These are simple to get right and cause rejections when skipped.

Turn the spec into a checklist

Do not verify against the document itself, extract every testable requirement into a flat checklist with a pass or fail against each. A spec is written to be comprehensive. A checklist is written to be worked through. This conversion is what stops requirements buried in prose being missed.

Verify the actual file, not the timeline

Check the delivered file with QC tooling: resolution, frame rate, scan type, codec, bitrate, audio channel mapping, loudness, true peak, timecode start, and duration. Timeline settings and export dialogues frequently do not produce what you assume, and the file is what will be assessed.

Ask rather than guess on anything ambiguous

Specs contain ambiguities and legacy clauses. A short email to your contact costs nothing and is far cheaper than a rejection and a redelivery. Record the answer, because the person who told you may not be the person who assesses it.

Pro Tips

Audio layout causes more rejections than picture. Read that section first and most carefully.
Confirm the spec version applies to this delivery. Strands within one broadcaster differ.
Convert the spec to a flat checklist. Prose hides requirements. Lists do not.
Budget time for a rejection before the deadline rather than delivering at the last possible moment.
Keep the QC report you generated. It is your evidence if a dispute arises about what was sent.

Knowledge Base

What You'll Learn

A delivery spec is a technical contract, and treating it as one changes how you work with it. Below: what specs actually cover, and why audio and metadata cause most failures.

What a Delivery Specification Actually Covers

Specs are longer than people expect because they cover several separable areas, and skipping any one produces a rejection.

Picture: resolution, frame rate, scan type, aspect ratio, colour space, codec and bitrate, and sometimes constraints on graphics such as safe areas and minimum text size.

Audio: channel count and layout, what each track must carry, loudness target and tolerance, true peak limit, dialogue normalisation, and any additional tracks such as audio description or clean effects.

Structure and timing: what precedes programme content, the exact start timecode, black at head and tail, part boundaries, and total duration tolerances.

Metadata and paperwork: file naming, embedded metadata fields, and accompanying documents such as an as-run list, subtitle files, and rights information.

Compliance: photosensitivity requirements, subtitle standards, and any editorial restrictions.

Reading only the picture section, which is the instinct, covers perhaps a quarter of what will actually be assessed.

Why Audio and Metadata Cause Most Rejections

Picture problems are visible. If the resolution or frame rate is wrong, someone notices during the edit. Audio and metadata problems are invisible until assessed, which is why they dominate rejection statistics.

Channel layout is the classic. A spec requiring specific content on specific tracks (stereo mix on one and two, mix-minus on three and four, or discrete stems) is easy to get wrong in an export dialogue, and the file plays perfectly while being non-compliant.

Loudness is measured, not judged. A programme that sounds fine can sit outside the required target or breach the true peak limit, and there is no arguing with a measurement.

Timecode start and head structure are trivially checkable and frequently wrong, because they are set once in a project and forgotten.

Metadata and file naming feel administrative and are automated checks at the receiving end, so an incorrectly named file can be rejected before anyone looks at the content.

The pattern is consistent: the things that fail are the things you cannot see or hear during normal work, which is exactly why the verification pass has to be measurement-based rather than a viewing.

Where This Fits

This guide covers one specific part of broadcast ingest. The wider picture, baseband, file-based, and IP ingest, metadata capture, QC gates, and never losing the source, is in Broadcast Media Ingest: How Enterprise Pipelines Actually Work, which frames the discipline as a whole and links out to the detailed guides underneath it, including this one. If you are starting from scratch rather than solving a specific problem, read that first and come back here.

FAQ

Q: What causes most delivery rejections?
A: Audio and metadata rather than picture. Channel layout that does not match the required mapping, loudness or true peak outside tolerance, wrong start timecode or head structure, and incorrect file naming or missing metadata. These are invisible during normal work, which is why they survive to delivery.

Q: Can I reuse a delivery spec from a previous job?
A: No. Confirm the current version applies to this specific delivery. Specs are revised, and broadcasters frequently maintain different specifications for different strands. Working from a stale document is a common and entirely avoidable cause of rejection.

Q: How should I verify a deliverable?
A: With QC tooling against the actual file, not against your timeline settings or export dialogue. Check resolution, frame rate, scan type, codec, audio channel mapping, loudness, true peak, start timecode, and duration. Work from a flat checklist extracted from the spec rather than from the prose document.

Q: What should I do about ambiguous requirements?
A: Ask your named contact and record the answer in writing. A short email costs nothing compared with a rejection and redelivery, and the person who clarifies it may not be the person who assesses the file, so having the answer documented matters if there is later disagreement.