The Three Layers of AAF Metadata
AAF metadata sits in three distinct layers. Understanding which layer a field belongs to predicts whether it survives a given step in the chain.
Sequence-level metadata describes the project as a whole: name, frame rate, sample rate, start timecode. It is the most reliable layer. Sequence-level fields almost always survive the export from any major NLE and load into Pro Tools cleanly.
Track-level metadata describes each audio track in the timeline: name, track number, activation state, lock state. Track-level metadata is mostly reliable but has a known failure mode in Avid Media Composer (inactive and locked tracks do not export at all).
Clip-level metadata describes each individual audio clip: mob ID, display name, source name, source timecode, channel count, sample rate, bit depth. The clip layer is where most metadata loss happens, because the NLE has to reconcile what it received from production sound with what its own internal database stores, and different NLEs make different decisions about which fields to preserve.
Per-Clip Metadata Fields
The AAF specification defines the following per-clip fields. Whether each field is populated depends on the source recording, the NLE's edit-time handling, and the export configuration.
The two fields most commonly missing from a clip in audio post are the recording start time (a wall-clock anchor that lets a dialogue editor cross-reference production sound logs) and the multi-channel channel labels (which mic captured which channel of a field-recorder track).
Per-Track Metadata Fields
Track-level metadata carries the structural decisions the picture editor made about audio organization in the timeline.
The Avid track-state issue is the single most consequential silent-loss case in AAF metadata: inactive and locked tracks export with no warning and no log entry. Audio post discovers the gap when a scene's production sound is missing from the conformed session.
Sequence-Level Metadata
Sequence-level fields are the most reliable layer of AAF metadata. They describe the project, not the content.
Frame rate and sample rate at the sequence level are non-negotiable for a usable handoff. A frame rate mismatch produces a session that drifts against picture; a sample rate mismatch produces a session that plays at the wrong pitch and length.
The iXML and Production-Sound Metadata Problem
iXML is a metadata standard embedded inside Broadcast Wave Format (BWF) audio files at the recording stage by professional production sound mixers. It carries scene number, take number, slate information, microphone identification, recordist notes, and multi-channel mapping. iXML is rich production metadata, and every modern professional audio recorder writes it.
iXML is not part of the AAF specification. AAF preserves source timecode at the clip level, but it does not transport the full iXML payload from the original recording through the NLE to Pro Tools. By the time an audio file reaches a Pro Tools session via AAF, the iXML data is typically gone. The dialogue editor working from the AAF cannot read scene number, take number, or recordist notes from the clip itself. That information lives only in the original BWF source files, which are usually held by the production sound team and may or may not be accessible to audio post.
Some workflows preserve iXML by keeping the original BWF files alongside the AAF and re-linking them in Pro Tools after import. That path requires production sound to deliver the original files, audio post to manage the file replacement, and Pro Tools to read the iXML once linked. It works when the workflow is set up for it. It does not happen by default.
What Each NLE Exports
The four NLEs in regular professional use each handle AAF metadata differently.
Across all four NLEs, what the AAF actually carries depends on what the editor did inside their NLE during the cut. An NLE that preserves a field is not the same as a sequence that uses it. A Media Composer session where the editor never assigned scene or take metadata produces an AAF without scene or take, regardless of what Avid is capable of exporting.
The AAF complete guide covers what AAF is at the format level and where it fits in the picture-to-Pro-Tools handoff.
What Pro Tools Loads on Import
Pro Tools imports AAF via File > Import > Session Data. The import dialog exposes track and clip selection, media handling (link or copy), and a small set of options for time-base treatment.
The fields Pro Tools loads from a valid AAF:
- Clip names (display name)
- Source timecode (per clip)
- Track names
- Track numbers
- Sequence start timecode and frame rate
- Sample rate
- Sequence in/out points for each clip
- Fade information (subject to fade-type compatibility)
The fields Pro Tools does not load, even when present in the AAF:
- iXML data from the original BWF files
- NLE-applied audio plugins or processing
- NLE-applied automation curves on tracks
- NLE color labels (Pro Tools applies its own color logic)
- Multi-channel field-recorder mappings beyond what the NLE preserved
The gap between what Pro Tools could theoretically load and what it actually loads is small relative to the gap between the AAF and the original production sound. Most AAF metadata loss happens upstream of Pro Tools, not at the Pro Tools import.
How to Catch Metadata Gaps Early
Three checks at AAF receipt surface the metadata gaps that matter for audio post.
Spot-check three clips. Pick a clip from the start, middle, and end of the timeline. Confirm the clip name, source timecode, and channel configuration match what production sound delivered. A mismatch on any of the three points to a metadata problem that affects the rest of the session.
Audit track count against the cut. If the picture editor's cut shows 12 audio tracks and the AAF imports 10, the missing two are inactive or locked in the source NLE. Re-export with those tracks enabled before starting any creative work.
Confirm multi-channel field recordings. For projects with multi-channel sources (5.1 production mixes, multi-mic captures), open one multichannel clip and verify all channels are present with correct labels. A missing channel or a stripped label indicates the multichannel mapping was lost in the NLE edit phase, and the original BWF files are needed to recover it.
fPost surfaces these gaps as part of the standard import. AI-R content analysis classifies clips as dialogue, SFX, or music; clips that do not match any of those categories cleanly are flagged for review. Track-count discrepancies between the AAF and the facility template are reported. The safety copy of the unmodified AAF is preserved alongside the organized session, so the original metadata remains accessible for cross-reference even after the prep step has run.
Frequently Asked Questions
What metadata does an AAF file actually contain?
AAF carries metadata at three layers. Sequence-level: name, frame rate, sample rate, start timecode. Track-level: name, number, activation state, lock state. Clip-level: mob ID, display name, source name, source timecode, channel count, sample rate, bit depth, sequence in/out points. Production-sound metadata embedded in the original BWF files (iXML, scene, take, recordist notes) is not part of the AAF specification.
Does AAF preserve scene and take numbers?
Not directly. Scene and take numbers live in the iXML data inside BWF source files, which is not part of the AAF specification. Avid Media Composer preserves scene and take inside its own database during edit and can carry them through to the AAF as clip-level annotations when the editor populated those fields. Premiere Pro, DaVinci Resolve, and Final Cut Pro X handle scene and take less reliably. To work with scene and take in audio post, the original BWF files typically need to be linked alongside the AAF.
What is iXML and why does it matter?
iXML is a metadata standard embedded inside BWF audio files at the recording stage by professional sound mixers. It carries scene number, take number, slate information, microphone identification, and recordist notes. iXML is rich metadata that audio post relies on for cross-referencing against production logs. AAF does not transport iXML through to Pro Tools. To preserve iXML in audio post, the original BWF source files have to be linked alongside the AAF.
Why are some tracks missing from my Pro Tools import even though the AAF was complete?
The most common cause is inactive or locked tracks in the source NLE, particularly in Avid Media Composer. Both states exclude tracks from the AAF export with no warning. Re-export with the tracks enabled before starting audio post.
Can fPost read iXML from the source files?
fPost operates on the AAF and the audio it carries. iXML lives in the original BWF files alongside the AAF. fPost does not currently inspect or surface iXML from those source files; the dialogue editor or assistant handles iXML cross-reference manually when production sound delivers the BWF set alongside the AAF.
If your facility runs into metadata gaps on every AAF arrival, fPost handles the prep step (content classification, template mapping, safety copy) so the audio post team's time goes into the gaps that need human judgment rather than the structural restart. Demo at forte-ai.com/demo.
