AAF carries a defined set of metadata from a non-linear editor into Pro Tools. The set is smaller than what production sound originally captured, smaller than what the picture editor saw inside their NLE, and smaller again than what the AAF specification technically supports. Every layer of the picture-to-Pro-Tools chain drops something, and most of what gets dropped is invisible until audio post needs it. This guide is the reference: what AAF carries at the clip, track, and sequence level; which NLEs export which fields; what Pro Tools loads on import; and how to identify the metadata gaps before the mix is on the line.
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.
| Field | What it carries | Reliability through export |
|---|---|---|
| Mob ID | Globally unique identifier for the clip | High. Generated by the NLE, always present in valid AAF |
| Display name | The clip name the editor saw in the NLE | High. Usually carries the original file name or an editor-applied label |
| Source name | The original audio file name on disk | Medium. Some NLEs replace with internal labels |
| Source timecode | The recording timecode of the audio at this clip position | High. Preserved at the clip level by all major NLEs |
| Recording start time | The wall-clock time the source was recorded | Low. Often missing; not part of every NLE's clip database |
| Channel count | Mono, stereo, or multi-channel | Medium. Multi-channel often splits at export |
| Channel labels | Identifiers for each channel in a multichannel clip | Low. Frequently lost in NLE edit operations |
| Sample rate | Source audio sample rate | High. Preserved when matching the project rate |
| Bit depth | Source audio bit depth | High. Preserved on export |
| Audio format | PCM, BWF, or compressed | High |
| Sequence in/out points | Where the clip lives in the edited timeline | High. This is the core information AAF was designed to carry |
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.
| Field | What it carries | Reliability through export |
|---|---|---|
| Track name | The label the picture editor applied | Medium. Reliable from Avid Media Composer; less so from DaVinci Resolve and Premiere |
| Track number | A1, A2, etc. | High |
| Track activation state | Active or inactive | Avid-specific failure mode: inactive tracks do not export at all |
| Track lock state | Locked or unlocked | Avid-specific: locked tracks do not export |
| Track format | Mono, stereo, or multichannel | Medium. Affects how clips on the track are interpreted on export |
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.
| Field | What it carries |
|---|---|
| Sequence name | The project or episode identifier |
| Start timecode | The timecode anchor for position 0 in the sequence |
| Frame rate | 23.976, 24, 25, 29.97, 30 |
| Sample rate | Project-level audio rate, typically 48 kHz for broadcast and film |
| Project ID | An identifier the NLE generates for the project |
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.
| NLE | Track naming reliability | Stereo handling | Notable metadata behavior |
|---|---|---|---|
| Avid Media Composer | Highest. Editors typically follow broadcast track conventions | Reliable when sequence is stereo | Inactive and locked tracks excluded with no warning. Best clip name preservation |
| Adobe Premiere Pro | Variable. Naming reflects editor's workflow, often without audio post conventions | Common dual-mono problem (stereo splits to two mono files falsely paired) | Plugin and effects metadata typically dropped. The Premiere AAF export guide covers the export-time settings that control this |
| DaVinci Resolve | Lowest. Tracks default to A1-A8 with no further labeling. Clip names from field-recorder file numbers | Generally reliable | Fairlight effects can bake into the export |
| Final Cut Pro X | Role-based metadata carries through (when the editor assigned roles) | Stereo handling depends on clip-level configuration | No native AAF export; conversion via X2Pro or DaVinci Resolve |
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.
