export const meta = {
title: "Guide to MXF Metadata for Broadcast Automation Systems",
description: "Learn how to prepare MXF metadata for broadcast automation, including UMIDs, timecode, descriptive fields, audio labels, validation, and broadcaster-specific shims.",
tldr: "Don't treat MXF as a simple export preset. Start with the broadcaster’s exact delivery profile or shim, then make sure the file carries the expected UMIDs, timecode, descriptive metadata, audio labels, caption signaling, and identifiers. Validate after export or rewrap with tools that understand both MXF structure and the broadcaster-specific profile, because a file can play correctly and still fail automation ingest.",
slug: "guide-to-mxf-metadata-for-broadcast-automation-systems",
publishedAt: "2026-08-05",
readingTime: 10,
thumbnail: "https://cdn.aspectlabs.dev/blog/guide-to-mxf-metadata-for-broadcast-automation-systems/cover-cf23f8621d75.png",
authors: ["gurish"],
primaryTopic: "codec-workflows",
topics: ["codec-workflows"],
tags: ["mxf"],
faq: [
{
"question": "Is MXF OP1a enough for broadcast delivery?",
"answer": "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 such as AS-11, AS-11 UK DPP HD, AS-11 X1, AS-11 X9, AS-03, or a house specification. The required codec, audio layout, timecode, captions, descriptive metadata, and identifiers must all match the broadcaster’s delivery document."
},
{
"question": "Which MXF metadata fields do broadcast automation systems commonly expect?",
"answer": "Commonly expected fields include Material Package name, Material Package UMID, File Package name, File Package UMID, track IDs, track names, essence descriptors, duration, operational pattern, codec labels, timecode track, start timecode, edit rate, 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."
},
{
"question": "Can I fix MXF metadata after export?",
"answer": "Sometimes, but it should be done carefully with MXF-aware tools. Rewriting metadata after export can affect header metadata, identifiers, indexes, durations, or 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."
},
{
"question": "What tools are useful for checking MXF metadata?",
"answer": "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."
},
{
"question": "Why can one broadcaster accept an MXF file while another rejects it?",
"answer": "Broadcasters often use different MXF profiles, metadata fields, 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."
},
{
"question": "How can a remote post team keep MXF exports, sidecar metadata, QC reports, and delivery specs in sync?",
"answer": "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."
}
],
}
For broadcast automation, start with “which delivery specification and shim is this broadcaster expecting?” before choosing which MXF export preset looks close.
[MXF is a container](https://www.drastic.tv/images/documentation/st377-1-2019.pdf), not a codec. It can wrap video, audio, captions, timecode, identifiers, structural metadata, descriptive metadata, and sometimes broadcaster-specific XML. That flexibility is why MXF works across camera, edit, playout, archive, and delivery systems, and it's also why a file can play perfectly in an NLE and still fail ingest at a broadcaster.
Broadcast automation systems aren't just checking whether the picture decodes. They're trying to connect the media file to a schedule, a traffic record, an asset ID, a version, a start time, audio routing, caption presence, and sometimes segmentation or compliance metadata. If the MXF metadata doesn't line up with the broadcaster’s rules, the file may be rejected, quarantined, misidentified, or ingested with the wrong assumptions.
## Start with the delivery family, not the wrapper
“MXF OP1a” isn't a complete delivery spec. It tells you something important about the structure, usually that the file is a single interleaved package containing video and audio essence, but it doesn't tell you the exact codec, audio layout, timecode mode, descriptive metadata, caption carriage, or required identifiers.
For broadcast delivery, the requirement is often a constrained MXF profile such as AS-03, AS-11, AS-11 UK DPP HD, AS-11 X1, AS-11 X9, or a broadcaster-specific variant 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](https://static.amwa.tv/as-03-mxf-program-delivery-spec.pdf), 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](https://static.amwa.tv/as-10-mxf-for-production-spec.pdf), 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](https://www.amwa.tv/_files/ugd/f66d69_d6fd785a870d4728856743a7aa79f603.pdf) first, then build the export and verification process around that target.
## The metadata automation systems actually care about
Automation systems care about metadata that helps them answer 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?
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
This is the metadata that helps downstream systems understand the MXF as a coherent media object, and the UMID is especially important because MXF uses [globally unique identifiers](https://tech.ebu.ch/docs/r/r121.pdf) to link essence and metadata inside the file, and to connect the file with external metadata 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 the file to contain a timecode track in the Material Package defining a synthetic program run time, with starting time and mode controlled by the applicable shim. In real-world delivery specs, the requested start time might be 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, including core program metadata and broadcaster-specific extensions. Some AS-11 variants also allow or require [embedded XML documents](https://amwa-tv.github.io/AS-11_X9/AMWA_AS_11_X9.html) carried in header metadata. That means 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](https://www.youtube.com/watch?v=25rc34dFDzg)
- 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 often 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, is one of the fields people tend to ignore 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. That matters in automated broadcast environments because those environments rarely handle the media file in isolation. It's matched against traffic systems, media asset management records, QC reports, 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, you usually shouldn't manually invent or edit UMIDs unless the tool or delivery spec explicitly requires it. Let the conforming exporter or wrapping tool generate valid identifiers. Duplicate, missing, mismatched, or non-conforming identifiers can break automated matching.
Some editing systems are also picky about “fully formed” OP1a MXF metadata. In practice, they may look for material package names and UMIDs, file package names and UMIDs, track names, reel or source names, and timecode. That's more of an editing interoperability issue than a broadcaster delivery rule, but it's a useful warning: 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 and one of the hardest to fix late if a file has already moved through review, QC, traffic matching, and playout testing.
For broadcast automation, systems usually 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 important detail is that the timecode track in the MXF must 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.
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.
The right result is that the MXF timecode expresses the same program timing that the broadcaster’s automation, QC, traffic, and caption systems expect.
## 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 all define constrained packages for specific business purposes, and they define 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 systems may parse them only as a first-pass identifier. If 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's risky because not every tool can safely rewrite MXF header metadata without changing identifiers, indexes, durations, or 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.
Aspect lets teams add custom metadata fields to assets, so delivery IDs, version notes, and status can stay with the media. Assistants and post supervisors spend less time reconciling spreadsheets against files with unclear provenance.
In a transcode or rewrap workflow, be careful about what survives. Moving media from MOV to MXF, OP-Atom to OP1a, or camera MXF to delivery MXF may preserve some technical metadata while dropping descriptive fields, reel names, source package references, or timecode details. Camera-originated MXF can be rich in acquisition metadata, including image, sound, lens, and color information, but that doesn't mean it contains 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, but they may not write every package-level identifier or broadcaster-specific descriptive metadata structure needed for a strict delivery target.
## Verification belongs inside the workflow
Your team should verify the file at every point where the MXF is created, wrapped, transcoded, or metadata is modified. Waiting until the last upload is how teams discover that a perfectly viewable master has the wrong start time, missing AS-11 metadata, unlabeled audio, or 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, but it won't necessarily prove that embedded XML descriptive metadata conforms to a broadcaster’s AS-11 variant. A dedicated AS-11 validator may catch 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 help you determine whether the issue was introduced during export, rewrap, upload, portal processing, or broadcaster ingest.
Aspect stacks every version on one asset, so the newest master and the notes on it stay together. Reviewers and post supervisors can confirm which MXF is current before QC, upload, or replacement delivery.
## Failure modes that look like mystery rejections
Broadcast MXF failures often appear vague from the outside, and the file may get a portal message like “invalid metadata,” “unsupported MXF,” “timecode mismatch,” or “audio configuration error.” Underneath, the cause is usually 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.
These issues affect automation decisions. Automation systems are designed to reduce manual interpretation. If a human can tell what you meant but the metadata says something else, the automation 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 may then add their own naming rules, metadata fields, audio layouts, caption expectations, portal validation, or 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.”
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. Also avoid “extra” metadata experiments on strict deliveries. More metadata isn't always better if 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, but don't assume it will satisfy every automation system downstream.
## A practical 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](http://downloads.bbc.co.uk/scotland/commissioning/TechnicalDeliveryStandardsBBCFile.pdf) and confirm the exact profile, not just “MXF.” In finishing, set the timeline start, audio layout, captions, and sequence metadata to match that profile. 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 both a general media tool and a profile-specific validator when available.
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 to make the MXF boring for the automation system. Correct identifiers, correct timecode, correct descriptive metadata, correct audio labels, and a profile the broadcaster actually asked for. When those line up, the file has a much better chance of moving through ingest, QC, scheduling, playout, and archive without someone having to rescue it manually.