Guide to MXF Metadata for Broadcast Automation Systems

MXF is a container, not a codec. It can wrap video, audio, and captions alongside timecode, identifiers, and structural and descriptive metadata. Some profiles also carry broadcaster-specific XML. That flexibility is what lets one wrapper serve camera, edit, and playout, plus archive and delivery. It is also what leaves room for two files to look identical in an NLE and behave differently at broadcaster ingest.

MXF is a wrapper that carries essence and metadata together.

Broadcast automation systems aren't just checking whether the picture decodes. They are trying to attach the file to a schedule, a traffic record, and an asset ID. They also need to know the version, where playback begins, and how the audio tracks should route. Caption presence gets checked, and some specs add segmentation or compliance metadata on top. When the MXF metadata doesn't line up with the broadcaster’s rules, the file may be rejected or quarantined. It may also be misidentified, or ingested with assumptions nobody intended.

Start with the delivery family, not the wrapper

“MXF OP1a” isn't a complete delivery spec. It tells you the file is a single interleaved package holding video and audio essence. It says nothing about the exact codec, the audio layout, or the timecode mode. It is equally silent on descriptive metadata, caption carriage, and required identifiers. For broadcast delivery, the requirement is often a constrained MXF profile: AS-03, AS-11, AS-11 UK DPP HD, AS-11 X1, or AS-11 X9. Broadcasters also publish their own variants based on one of those. These profiles exist because generic MXF leaves too much room for interpretation. Your team should make one of these first decisions:

For finished program delivery to a broadcaster or publisher, expect an AS-11-style requirement or a house spec derived from it.
For program delivery where traffic metadata is delivered separately, AS-03 concepts are common, with file metadata used to identify and verify the content against external systems.
For production interchange across ingest, edit, server, playout, archive, and fulfillment, AS-10 may be relevant, especially in XDCAM-style production workflows.
For NLE-native media exchange, OP-Atom or vendor-specific MXF may be correct for edit workflows, but that isn't the same as a broadcast delivery master.

The practical takeaway: don't let the NLE’s generic “MXF” menu drive the workflow. Get the broadcaster’s profile, shim, or delivery document first, then build the export and verification process around that target.

The metadata automation systems actually care about

Automation systems care about metadata that answers a few operational questions. What is this file? Does it match the scheduled asset? Where does playback begin? Which tracks should be routed? Are captions or subtitles present? Is this the right version?

Automation systems read attached properties, not just playable picture.

The fields vary by broadcaster, but the recurring groups are stable.

Metadata area	Typical fields	Why automation cares	Common failure pattern
Structural and identifiers	Material Package name and UMID, File Package UMID, track IDs, essence descriptors, operational pattern	Lets ingest, MAM, QC, archive, and playout systems identify the MXF as a coherent asset	File plays, but is rejected as unsupported, duplicate, mismatched, or not linked to the expected record
Timing	Material Package timecode, start timecode, drop-frame mode, edit rate, duration, segment timing	Tells automation where playback starts and how captions, parts, replacements, and schedules line up	Timecode mismatch, one-frame duration errors, caption drift, wrong segment timing
Descriptive metadata	Program title, series, episode, production number, version, synopsis, originator, rights, broadcaster IDs	Connects the media file to traffic, portal, compliance, and scheduling records	File name looks correct, but embedded metadata is missing, inconsistent, or not accepted by the broadcaster shim
Audio and captions	Track count, channel layout, track labels, language tags, M&E, audio description, caption presence, caption carriage	Determines routing, language selection, accessibility handling, and compliance checks	Valid audio or captions are present, but automation cannot identify roles, languages, or required presence signaling

Common structural and identification metadata includes:

Material Package name
Material Package UMID
File Package name
File Package UMID
Track IDs
Track names
Essence descriptors
Duration
Operational Pattern, commonly OP1a for delivery
Codec and essence container labels

That set is what lets downstream systems read the MXF as one coherent media object. The UMID carries extra weight. MXF uses globally unique identifiers to link essence and metadata inside the file. The same identifiers connect the file with external metadata held in databases or traffic systems. Common timing metadata includes:

Material Package timecode track
Start timecode
Drop-frame or non-drop-frame mode where applicable
Edit rate
Duration in frames
Segment or part timing, if the delivery spec supports program segmentation

For AS-03, expect a timecode track in the Material Package that defines a synthetic program run time. The applicable shim controls the starting time and the mode. Real delivery specs ask for 10:00:00:00, 01:00:00:00, or something else entirely. Don't assume your house default is acceptable. Common descriptive metadata includes:

Program title
Series title
Episode title or number
Production number
Version or edit identifier
Synopsis or description, where required
Originator or production company
Rights or usage fields, where required
Audio description presence
Sign language presence
Subtitles or captions present
Clock, part, or segmentation information
Broadcaster-specific IDs

In AS-11-style workflows, descriptive metadata can be embedded in MXF Header Metadata using defined descriptive metadata schemes. Those schemes cover core program metadata and broadcaster-specific extensions. Some AS-11 variants also allow or require embedded XML documents carried in header metadata. So the metadata may not live only in the file name or a separate spreadsheet. The broadcaster may expect the MXF itself to carry machine-readable delivery information. Common audio and caption metadata includes:

Audio track count
Channel layout
Track labels
Language tags
Stereo, dual mono, 5.1, M&E, audio description, or other role labels
Captions or subtitles presence
Caption format and carriage method
Ancillary data descriptors where applicable

This is where files fail despite having valid video. A file with eight audio channels isn't automatically an eight-channel broadcast deliverable. The automation or QC system may need to know which channel is left, right, center, LFE, surround, M&E, audio description, or silence. Some UHD AS-11 profiles moved toward multi-channel sound tracks with explicit labels, which is exactly the kind of detail automation depends on.

UMID matters for ingest and relinking

The UMID, or Unique Material Identifier, gets ignored until an ingest system rejects the file or an NLE relinks it strangely. In MXF, identifiers can link essence and metadata within a file, link file material to external metadata, and connect metadata stored in the MXF with records in other systems. Automated broadcast environments rarely handle a media file in isolation. The file gets matched against traffic systems, media asset management records, and QC reports. It also has to line up with replacement deliveries, archive entries, and playout schedules. A well-formed file typically has UMIDs at package level. Depending on the application, systems may care about:

Material Package UMID
File Package UMID
Source Package identifiers
Track IDs that are unique within a package
Spanning IDs when a production format splits material across files

For straightforward finished-program delivery, don't invent or edit UMIDs by hand unless the tool or delivery spec explicitly requires it. Let the conforming exporter or wrapping tool generate valid identifiers. Duplicate or missing identifiers break automated matching, and so do mismatched or non-conforming ones. Some editing systems are also picky about “fully formed” OP1a MXF metadata. In practice they may look for material package names and UMIDs, plus file package names and UMIDs. They may also want track names, reel or source names, and timecode. That is an editing interoperability issue rather than a broadcaster delivery rule. The warning still holds: different systems read different parts of the same MXF.

Timecode needs to match the delivery logic

Timecode is one of the easiest metadata fields to set casually. Once a file has cleared review and QC, then traffic matching and playout testing, changing it is expensive. Automation systems use timecode for one or more jobs:

Confirming the program starts at the expected point
Matching part timings or segment markers
Validating caption timing
Supporting replacement of acts, parts, or versions
Supporting archive and downstream edit references

The correct start time depends on the broadcaster’s delivery model. Some specs want program start at a fixed timecode. Some expect the file to include pre-roll material and use metadata to identify the first frame of program. Some use segmentation metadata for parts. Some want a clean, self-contained playout-ready program without extra leader. The timecode track in the MXF has to match the edit timeline, the file duration, and any external paperwork or traffic metadata. A mismatch of one frame can trigger a QC warning. A mismatch of several seconds can cause the wrong segment to play, captions to drift, or automation to reject the asset.

Timecode, timeline, and related timing data need to line up.

When exporting, avoid these common traps:

Exporting from a sequence that starts at 00:00:00:00 when the broadcaster expects 10:00:00:00.
Mixing drop-frame and non-drop-frame assumptions on 29.97 fps material.
Rewrapping a file and losing the original timecode track.
Exporting captions from a different timeline version than the MXF master.
Trimming leader or tail without updating duration and part metadata.

Aim for one result. The MXF timecode expresses the same program timing that every downstream system expects, from automation and QC through traffic and captions.

Descriptive metadata can be embedded, external, or both

Many delivery problems come from assuming descriptive metadata is “paperwork,” while the broadcaster expects some of it inside the MXF. MXF supports descriptive metadata as plug-ins carried in header metadata. AS-11 builds on that model for finished program contribution and delivery. AS-11 UK DPP HD, AS-11 X1 for UHD, and AS-11 X9 for North American AVC delivery each define a constrained package for a specific business purpose. Each also sets codec constraints and representation rules for descriptive and technical metadata. Depending on the spec, your team may need to deliver descriptive metadata as:

MXF descriptive metadata sets
AS-11 Core descriptive metadata
Broadcaster-specific descriptive metadata
Embedded XML documents in header metadata
External sidecar metadata submitted through a portal or traffic system

You need to know which metadata is authoritative. In some workflows the traffic system is the source of truth, and the MXF carries enough IDs to match the file to that record. In others, the MXF itself must contain a complete metadata set. In many broadcaster portals, both must match. Don't treat the file name as a substitute for embedded metadata. File names are useful for human handling and routing, but automation may parse them only as a first-pass identifier. Suppose the package metadata or embedded descriptive metadata disagrees with the file name. The ingest system may trust the embedded values, reject the file, or require manual intervention.

Embedding metadata during export

The best time to get MXF metadata right is during the master export or wrapping stage. Fixing metadata after export is possible in some workflows, but it carries risk. Not every tool can rewrite MXF header metadata safely. A careless rewrite disturbs identifiers and indexes, or changes durations and essence references. A reliable export setup usually starts with these decisions:

Delivery spec or shim
MXF operational pattern
Video codec and profile
Audio track count and channel layout
Caption or subtitle carriage
Start timecode and timecode mode
Package name and file naming convention
Required descriptive metadata fields
Whether your team enters metadata in the NLE, imports it from XML, adds it by a wrapping tool, or injects it by a delivery system

In an NLE or finishing tool, your export preset should match the broadcaster’s profile as closely as possible. If there's a dedicated AS-11 or DPP preset, use that instead of a generic OP1a preset. If the tool supports metadata panels or template fields, populate them from the same source used for the delivery portal or traffic record. In a transcode or rewrap workflow, watch what survives. Moving media from MOV to MXF, OP-Atom to OP1a, or camera MXF to delivery MXF preserves some technical metadata. It can still drop descriptive fields and reel names, or lose source package references and timecode details. Camera-originated MXF can be rich in acquisition metadata covering image and sound, plus lens and color information. That is not the same thing as the finished-program metadata a broadcaster expects. If your team must add metadata after export, use MXF-aware tools and validate immediately after the rewrite. Generic media tools can be excellent for transcode inspection. They may not write every package-level identifier, or every broadcaster-specific descriptive metadata structure a strict delivery target needs.

Verification belongs inside the workflow

Verify the file at every point where the MXF is created or wrapped, transcoded, or where metadata is modified. Waiting until the final upload is how teams discover that a perfectly viewable master has the wrong start time or unlabeled audio. It may also be missing AS-11 metadata, or carrying a package identifier the receiving system doesn't like. Use different tools for different questions:

General media inspection tools are good for codec, duration, frame rate, audio channels, and basic timecode visibility.
Command-line probing tools are useful for repeatable reports in automated pipelines.
MXF-aware analyzers are better for package structure, operational pattern, header metadata, descriptors, indexes, and UMIDs.
Use AS-11, DPP, or broadcaster-specific validators when the delivery target is a formal constrained profile.
Your team still needs full QC systems for picture, audio, captions, loudness, gamut, and delivery compliance.

Match the inspection tool to the risk. A quick MediaInfo-style readout may confirm the codec and channel count. It won't prove that embedded XML descriptive metadata conforms to a broadcaster’s AS-11 variant. A dedicated AS-11 validator catches metadata and structural issues that a playback test never will. For teams building repeatable delivery pipelines, save inspection reports with the file version. When a broadcaster rejects a delivery, those reports show whether the issue entered during export or rewrap, during upload, or inside the broadcaster’s own portal processing and ingest.

Failure modes that look like mystery rejections

Broadcast MXF failures look vague from the outside. The portal returns “invalid metadata,” “unsupported MXF,” “timecode mismatch,” or “audio configuration error.” Underneath, the cause is specific. Common metadata-related failure modes include:

The file is OP1a MXF, but not the required AS-11 or broadcaster shim.
The Material Package timecode starts at the wrong value.
Duration in header metadata doesn't match the essence duration.
Audio tracks are present but not labeled correctly.
Descriptive metadata is missing required fields.

Each of these changes an automation decision. Automation systems are designed to reduce manual interpretation. If a human can tell what you meant but the metadata says something else, the system will usually follow the metadata or reject the file.

Different broadcasters, different rules

The hardest part of MXF metadata is managing variation. AS-11 itself is a family of constrained delivery specifications. UK DPP HD, UHD-oriented X1, and North American X9 exist because different markets and business requirements need different constraints. Individual broadcasters then add their own naming rules and metadata fields. They may also specify audio layouts and caption expectations, or their own portal validation and traffic matching behavior. The practical way to manage this is to treat each broadcaster requirement as a separate deliverable profile, not as a small tweak to “the MXF preset.”

Different broadcasters often require separate deliverable profiles.

For each broadcaster, document:

Accepted MXF family and shim
Required codec, raster, frame rate, and bit depth
Audio layout, labels, languages, and silence rules
Caption or subtitle format and presence signaling
Start timecode and drop-frame requirements
Required embedded descriptive metadata
Required external metadata or portal fields
File naming convention
Whether bars, tone, slate, clock, leader, or tail are expected
Approved validation tool or report format

Once that exists, build presets and naming templates around it. Avoid sharing one export preset across broadcasters unless their specs are genuinely identical. Avoid “extra” metadata experiments on strict deliveries too. More metadata isn't better when the receiving validator expects a constrained set of fields. For productions delivering to multiple outlets, make broadcaster-specific masters when the specs diverge. A single generic master may be useful internally. Don't assume it will satisfy every automation system downstream.

An MXF metadata workflow

A sane workflow is simple: define the target, export to the target, inspect against the target, then preserve the evidence. In prep, collect the broadcaster delivery spec and confirm the exact profile, not just “MXF.” In finishing, set the timeline start and audio layout to match that profile, along with captions and sequence metadata. During export, use the most specific conforming preset available. Then populate package and descriptive metadata from an approved source. After export, inspect the file with a general media tool and a profile-specific validator when one exists. If the file needs a transcode or rewrap after finishing, repeat the metadata inspection after that step. Don't assume a pass on the mezzanine export means the delivered wrapper is still compliant. The goal is a file the automation system has nothing to say about. Correct identifiers and correct timecode. Correct descriptive metadata and correct audio labels. A profile the broadcaster actually asked for. Get those right and the file clears ingest and QC, then scheduling, playout and archive, with nobody rescuing it by hand.

FAQ

Usually not by itself. MXF OP1a describes the file structure, but it doesn't define the full delivery requirement. Broadcasters often expect a constrained profile or shim: AS-11, AS-11 UK DPP HD, AS-11 X1, AS-11 X9, AS-03, or a house specification. Codec, audio layout, timecode, captions, descriptive metadata, and identifiers all have to match the broadcaster’s delivery document.

The structural group covers Material Package name, Material Package UMID, File Package name, File Package UMID, track IDs, track names, essence descriptors, duration, operational pattern, and codec labels. The timing group covers timecode track, start timecode, and edit rate. The descriptive and audio groups cover audio layout, language tags, caption presence, program title, version ID, production number, and broadcaster-specific asset IDs. The exact field list depends on the broadcaster and delivery profile.

Sometimes, but it should be done carefully with MXF-aware tools. Rewriting metadata after export can disturb header metadata and identifiers, or change indexes, durations, and essence references if the tool isn't appropriate for the delivery profile. It's safer to populate required metadata during export or wrapping, then validate the file immediately after any metadata change.

General inspection tools can confirm codec, frame rate, duration, channel count, and basic timecode. Command-line probes are useful for repeatable pipeline reports. MXF-specific analyzers are better for package structure, UMIDs, operational pattern, essence descriptors, and header metadata. For formal delivery profiles, use an AS-11, DPP, or broadcaster-specific validator when available.

Broadcasters use different MXF profiles and metadata fields. They also differ on audio layouts, caption rules, timecode expectations, file naming conventions, and portal validation systems. A file that's valid for one delivery target may fail another because the metadata doesn't match that broadcaster’s shim or house specification. Treat each broadcaster’s requirement as a separate deliverable profile.

Keep those files in one governed project space instead of scattering them across local drives, transfer links, and email threads. Aspect gives editors, assistants, and post supervisors one shared cloud filespace, so the MXF, validation report, captions, metadata spreadsheet, and broadcaster spec stay together for everyone working on the delivery.