BWF- og iXML-metadata forklaret: hvad der bor i en broadcast-WAV

BWF er bare WAV, plus disciplin

En WAV-fil er en beholder af chunks: en fmt -chunk der beskriver lyden, en data-chunk der rummer samples'ene, og et vilkårligt antal valgfri chunks, som software frit kan ignorere. Broadcast Wave Format (BWF), defineret af EBU i Tech 3285, tilføjer præcis én obligatorisk chunk til almindelig WAV: bext, broadcast-udvidelsen. Det er hele tricket: en BWF spiller alle steder, en WAV spiller, for i alt, der ikke forstår bext, er den en WAV.

Feltoptagere skriver en anden, uofficiel-men-universel chunk ved siden af: iXML, et XML-dokument indlejret i filen, specificeret af et branchekonsortium snarere end et standardiseringsorgan. I praksis deler de to arbejdet: bext svarer på “hvornår startede denne fil”, iXML svarer på “hvad er den”: scene, take, rulle, spornavne og den frame rate-kontekst, som bext som bekendt mangler.

Bext-chunken, felt for felt

bext-chunken er en binær struktur med fast layout. Felterne, der betyder noget på en optagelse:

• Description (256 tegn): fri tekst. Optagere skriver typisk noget i stil med sSPEED=025.000-ND sTAKE=012 sSCENE=14A sTAPE=SR003, en fladtrykt kopi af slate-informationen, nyttig når iXML mangler.
• Originator (32) og OriginatorReference (32): optagermodellen og en maskingenereret unik reference for filen.
• OriginationDate (yyyy-mm-dd) og OriginationTime (hh:mm:ss): vægur-stempel for oprettelsen, kun med sekund-præcision. Sync ikke efter dem; det er ikke deres job.
• TimeReference (64-bit heltal): feltet alt hænger på: antallet af samples siden midnat i det øjeblik, den første sample blev optaget. Mere om det nedenfor.
• Version, UMID: version 1 tilføjede en 64-byte unik SMPTE-materialeidentifikator; de fleste workflows rører den aldrig.
• Loudness-felterne (version 2): integreret loudness, loudness range, max true peak og venner, tilføjet til EBU R128-leveringsmastere. Feltoptagere lader dem stå tomme; de betyder noget, når BWF'en er en broadcast-leverance, ikke en rush.
• CodingHistory: fritekst-log over signalkæden (A=PCM,F=48000,W=24…), som hvert behandlingstrin føjer til i en velopdragen pipeline.

TimeReference: ét heltal, sample-præcist

Time referencen er bevidst simpel: samples siden midnat. Dividér med sample raten, og du har starttidspunktet på dagen; omregn det til et frame-antal, og du har start-timecoden. Et gennemregnet eksempel ved 48 kHz og 25 fps:

• En optager ruller ved timecode 10:35:20:12. Sekunder siden midnat: 10×3600 + 35×60 + 20 = 38.120 s.
• I samples: 38.120 × 48.000 = 1.829.760.000. De 12 frames lægger 12 × (48.000 ÷ 25) = 12 × 1.920 = 23.040 til.
• TimeReference = 1.829.783.040. At læse den tilbage er samme regnestykke i omvendt rækkefølge.

To egenskaber falder ud af det design. For det første er den sample-præcis: optageren kender sin start på 1/48.000 sekund, mens et kameras timecode kun er frame-præcis. Derfor hører restfejlen i en dual system-sync hjemme på kamerasiden. For det andet er den kontekstafhængig: heltallet er meningsløst, indtil du kender den sample rate, det tæller i, og, for visning som timecode, den frame rate der skal divideres med. Og her kommer krogen:

Bext-chunken gemmer hverken en frame rate eller et drop-frame-flag. Sample raten bor i det mindste ved siden af i fmt , men frame raten er simpelthen fraværende i standarden. Et værktøj, der viser dig 10:35:20:12 fra en nøgen BWF, har antaget en frame rate. Og ved 23.976 eller 29,97 drop-frame er antagelser den måde, lydruller ender minutter forkert ved wrap. At lukke det hul er halvdelen af grunden til, at iXML findes.

iXML: slaten, maskinlæsbar

iXML er et almindeligt XML-dokument gemt i sin egen chunk. Fordi det er XML, er det udvideligt og læsbart for mennesker. Du kan åbne en lydrulle i en hex-viewer og bogstaveligt talt læse scenenummeret. Sektionerne, et post-workflow læner sig op ad:

• PROJECT, SCENE, TAKE, TAPE: slaten. TAPE er lydrullens navn (SR003), lydsidens pendant til en kamerarulle: identiteten der følger materialet gennem ALE-filer og conform hele vejen til finish.
• CIRCLED, NO_GOOD, WILD_TRACK, NOTE: lydmixerens domme. Circled takes er dem, scripteren markerede som keepers; et dailies-værktøj, der løfter dem frem, laver klippeassistentens sortering gratis.
• SPEED: sektionen der fuldender bext. Den angiver FILE_SAMPLE_RATE, AUDIO_BIT_DEPTH og, helt afgørende, TIMECODE_RATE som et eksakt forhold, 25/1, 24/1, 30000/1001, plus TIMECODE_FLAG for drop/non-drop. Skæve rater, som bext ikke kan udtrykke, angives eksakt. Den gentager også tidsstemplet som TIMESTAMP_SAMPLES_SINCE_MIDNIGHT_HI/LO, så en fil med beskådiget bext stadig kan placeres.
• TRACK_LIST: én post pr. spor med kanalindeks og NAME: Boom, Lav 1, Lav 2, Mix L. Det er her, din klippers spor-etiketter kommer fra. Eller ikke gør.
• FILE_SET og FAMILY_UID: optagere kan skrive én polyfonisk WAV (alle spor interleavet i én fil) eller et sæt monofoniske filer, en pr. spor. I mono-sæt bærer hver fil samme FAMILY_UID og sit indeks i sættet, så software kan samle taket igen uden at gætte ud fra filnavne.
• HISTORY og FILE_UID: det oprindelige filnavn og et unikt ID, der overlever omdøbning. Når en rushes-mappe er blevet “hjælpsomt” omdøbt i hånden, er det sådan, lydrapporten stadig matcher filerne.

Hvad dit NLE faktisk læser

Understøttelsen er reel, men ujævn, og at kende hullerne sparer en eftermiddag:

• DaVinci Resolve læser bext-time referencen som start-timecode og trækker scene, take og spornavne fra iXML ind i metadata-panelet. Lydsiden af dens timecode-baserede multicam-sync.
• Premiere Pro læser time referencen til klippets start-TC og viser iXML-spornavne ved import; scene og take er synlige i metadata, men bruges ikke til at navngive noget automatisk.
• Avid Media Composer læser bext-TC ved link, men den fulde slate ankommer traditionelt via en ALE genereret fra netop disse felter. Den iXML-til-bin-bro, som ethvert dailies-værktøj bygger.

Fællesnævneren: time referencen læses stort set alle vegne; de beskrivende metadata overlever kun, hvis din ingest-vej bevidst bærer dem videre.

Sådan dør gode metadata

BWF-metadata er robuste i filen og skrøbelige i pipelinen. De sædvanlige dræbere:

• Re-eksport. Bounce en WAV ud af en DAW, eller konvertér den med et tilfældigt værktøj, og begge chunks er typisk væk. Den nye fil er lyd, der lyder identisk og intet ved. Ethvert behandlingstrin (niveau-rides, støjreduktion) skal eksplicit kopiere chunks med sig.
• Lossy transkodninger. En MP3 eller AAC har ingen bext og ingen iXML, punktum. I det øjeblik nogen “sender lyden over” som MP3, er sync-workflowet tilbage ved waveform-matching.
• Antagelser om sample rate. Produktioner, der optager ved 48.048 kHz til pulldown-workflows, bærer en time reference talt i den rate. Tolk den ved 48.000, og hver afledt timecode er 0,1 % forkert. En “drift”, der i virkeligheden var aritmetik.
• Midnat. Samples siden midnat betyder, at en optagelse, der ruller forbi 00:00, wrapper til små tal. Filerne sorterer forkert, og TC-baseret parring krydser døgn; origination date-feltet er det, der afgør sagen.
• 4 GB-klippen. WAV's 32-bit størrelsesfelt sætter loftet ved 4 GB, cirka 100 minutter otte-spors 48 kHz/24-bit. Lange multitrack-ruller skifter til RF64/BW64, de 64-bit-efterfølgere der holder bext og iXML intakte; ældre software, der sætter sig fast i dem, sætter sig fast i containeren, ikke metadataene.

Her passer Launchr Post ind

Launchr Post læser alt det ovenstående under ingest, på din egen maskine. Bext-time referencen, tolket gennem iXML-SPEED-sektionens eksakte rater, ikke en antagelse, driver timecode-først-sync mod kamerafilerne; scene, take, tape og spornavne flyder ind i klip-navngivningen, transskriptionerne og editor-pakken; circled takes forbliver markeret. Ankommer en fil strippet for sine metadata, falder syncen tilbage på LTC eller waveform-matching, og rapporten pr. klip siger det. Så du ved, hvilke filer der bar deres egen identitet, og hvilke der blev reddet.