Delivery specifications template

What this is about

Every recipient has requirements, and they rarely match: a broadcaster wants a different loudness target and a different audio layout than a client's media library, and a platform wants a file the mastering suite has to build separately. Collecting all of that in one document at the start decides things that are cheap in prep and expensive after the mix — the delivery frame rate, whether subtitles are burned in or supplied as a sidecar file, whether stems are owed. The specification is also what makes rejection reviewable: with it, a returned file has a named clause; without it, it has an opinion.

A template is the starting point, not the goal: once it has been filled in by hand twice, it is worth asking whether the document should come out of the plan instead.

What runs differently here

In planning terms, that means:

• Picture: codec and wrapper, resolution, frame rate, scan type, colour space and transfer function, plus whether a separate textless version is owed
• Sound: channel layout, which tracks carry what, the loudness target with its measurement standard such as EBU R128, and whether stems are included
• Timeline conventions: start timecode, slate or countdown, black handles at head and tail, and where the programme actually starts
• Text and access: subtitles burned in or as a sidecar file with a named format, closed captions, and any language versions with their own files
• Naming and route: the exact filename pattern, the delivery platform or drive, the contact who confirms receipt and the date the file is due

Step by step

This order gets you there fastest:

1. Ask every recipient for their spec sheet in writing at briefing stage, before the shooting format is chosen, not after the mix is booked.
2. Put the requirements side by side in one table and mark where they differ, because the differences are the extra masters you have to budget.
3. Fix the delivery frame rate first and check it against the shooting frame rate, since a conversion late in post touches picture and sound together.
4. Write the loudness target with its standard and note who measures it, so the mix and the recipient are not measuring two different things.
5. Decide subtitles and language versions early: burned-in subtitles multiply the number of masters, sidecar files multiply the number of checks.
6. Agree the filename pattern with an example line, then use that exact example when the real file is produced.
7. Run your own QC against the sheet before delivery and keep the report, so a rejection can be answered with a measurement rather than an assurance.
8. Deliver, ask for explicit receipt confirmation, and archive the delivered master together with the spec it was built to.

Common pitfalls

What most often goes wrong in practice:

• Discovering the required frame rate after picture lock, when the fix touches the mix, the subtitles and every cutdown at once
• A loudness value agreed without naming the standard it is measured in, which reads as compliant on one meter and as too loud on another
• Filenames invented at export time, so the recipient's ingest rejects a file whose content is perfectly correct
• No textless version requested, then discovered as missing when a second language version becomes necessary

With TillyGen

TillyGen captures the required formats and versions with the briefing, so the delivery list exists while the shooting format is still a decision rather than a constraint.

Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.