Why your AAF conform found the wrong take

Production sound recorders write rich metadata inside BWF chunks. When those chunks disagree with each other, or with reality, automated workflows break in ways you don't notice until the mix.

The dialogue editor opens the AAF, imports the production sound, and the conform tool matches everything automatically. Boom on track 1, lav 1 on track 2, lav 2 on track 3. Timecode-locked. Ready to cut.

Except track 1 isn’t the boom. It’s lav 2. The iXML metadata in the poly file had the channel names swapped, probably from a template the mixer set up for a different show and forgot to update. The conform tool trusted the metadata, because that’s what conform tools do.

This mistake gets discovered in the mix. The most expensive place to discover it.

What’s inside a BWF

A Broadcast Wave Format file is a WAV with extra chunks. Beyond the standard fmt (sample rate, bit depth, channels) and data (the actual audio), a production BWF typically carries:

bext carries the timecode. time_reference is a sample count from midnight, giving you frame-accurate sync. Also carries originator info, origination date/time, and optionally loudness measurements.

iXML holds the production metadata. Scene, take, tape, project, track names, circled flags, wild-track flags, channel layout. This is what post uses to reconnect a recording to the script.

bext fieldsOriginator: Sound Devices 888Date: 2026-03-15Time reference: 172800000 samplesTimecode: 01:00:00:00 @ 48kHzUMID: 060a2b34...

The eleven ways it goes wrong

In our experience, BWF metadata problems fall into a surprisingly small number of categories:

  1. iXML channel count disagrees with fmt channel count
  2. Track names don’t match the actual audio content (the wrong-take problem)
  3. bext timecode reference is present but the date field uses a non-standard format
  4. Sample rate is slightly off (47999 instead of 48000, thanks to older firmware)
  5. Track names are generic (“Track 1”, “Track 2”) because the template wasn’t configured
  6. Scene/take fields are blank or carry over from a previous recording
  7. Circled-take flag is set on every file because the mixer doesn’t use it
  8. Poly file has ISO tracks interleaved with mix tracks in an unexpected order
  9. bext and iXML carry contradictory origination timestamps
  10. UMID is all zeros (not unique, defeats the purpose)
  11. Channel layout descriptor doesn’t match the actual speaker configuration

None of these crash anything. They all cause downstream tools to make subtly wrong decisions.

The conform trust chain

Automated workflows trust metadata in a specific order. If the iXML says “Scene 42, Take 3” and the filename says “S42_T03”, they agree. If they disagree, the tool has to pick one. Different tools pick differently.

The most robust approach is to inspect the metadata, flag contradictions, and let the operator decide. The worst approach, which is distressingly common, is to silently prefer one source and hope for the best.

Why this matters

If you’re a production sound mixer, most of this is your responsibility at the point of recording. Getting the template right, verifying track names, checking the bext fields. This is the equivalent of a DIT verifying checksums. It’s the upstream work that makes everything downstream reliable.

If you’re a post sound editor, understanding the chunk structure means knowing where to look when something doesn’t match. Is the problem in the iXML? The bext? The fmt? Knowing which chunk to inspect, and being able to fix a field without opening a DAW and re-exporting, saves the kind of time you notice.

BWF Failure Modes
IssueChunkSymptomSeverity
Sample rate mismatch (fmt vs bext)fmt / bextPitch shift or speed change on importcritical
Missing iXML chunkiXMLNo scene/take/track names in conformwarning
Channel mask mismatchfmtWrong speaker routing on playbackcritical
Wrong bit depth declarationfmtClipping or noise floor shiftcritical
Timecode reference mismatchbext / iXMLSync offset, wrong take in AAFcritical
Missing bext chunk entirelybextNo originator, UMID, or TC referencewarning
Ambisonics flag incorrectiXMLSpatial decode fails or collapses to monowarning
Poly vs mono confusionfmt / iXMLDAW imports one channel or duplicates allcritical
Truncated data chunkdataPlayback cuts short or trailing silencecritical
Missing RF64 header for >4 GBds64File unreadable or truncated at 4 GBcritical