FCPXML vs. Premiere XML: hvad de to udvekslingsformater faktisk bærer

To filer, én opgave og ét dødt program

En udvekslings-XML svarer på det spørgsmål, en ALE ikke kan: ikke bare hvad klippene er, men hvordan de hænger sammen. Hvilket optager-spor hører til hvilket kameraklip, hvilke vinkler udgør en multicam-gruppe, i hvilken rækkefølge timelinen spiller. XML'en indeholder aldrig medier. Den indeholder referencer: navne, stier, reels, timecodes, som den modtagende NLE slår op mod de faktiske filer. Derfor betyder identitets-trioen af filnavn, start-timecode og reel mere end nogen anden egenskab i filen.

De to dialekter kommer fra samme stamtræ. Final Cut Pro 7 definerede xmeml, og da Apple byggede Final Cut forfra i 2011, skiftede de formatet ud med FCPXML i én bevægelse. Branchen havde i mellemtiden standardiseret på den gamle dialekt: Premiere Pro tog FCP7 XML til sig som sit de facto-udvekslingsformat, og derfor kalder alle det ”Premiere XML” i dag, og formatet frøs fast. Det ene format har siden udviklet sig gennem et dusin versioner; det andet har ligget stabilt i femten år, netop fordi moderprogrammet holdt op med at ændre det.

Sådan tænker de to filer

Åbn begge filer i en teksteditor, for ligesom med en ALE er læsbarheden halvdelen af værdien, og forskellen i verdensbillede springer i øjnene med det samme.

FCPXML er en database med referencer. Filen åbner med en <resources>-blok, der deklarerer hvert format, hvert asset og hver effekt én gang: en format-ressource der fastlåser billedstørrelse og frame-varighed, en asset-ressource pr. mediefil med dens URL, timecode og lydkanal-layout. Kroppen, altså events, projekter og timelines, henviser derefter til ressourcerne via ID. Intet gentages; et klip der bruges fyrre gange, findes én gang som asset og fyrre gange som reference.

xmeml er et dokument, der gentager sig selv. Der er ingen ressourcetabel: hvert <clipitem> bærer sin egen kopi af klippets navn, sti, rate og reel, nestet inde i tracks, inde i sekvenser, inde i bins. Den samme kildefil refereret fem steder beskrives i fuld længde fem gange. Det gør formatet ordrigt og af og til selvmodsigende, for to kopier af samme klip kan være uenige, men også tilgivende: en parser kan læse ét clipitem isoleret uden at jage referencer.

Tid: rationelle tal vs. frame-tal

Den dybeste forskel er, hvordan de to formater tæller.

FCPXML skriver tid som et rationelt antal sekunder. En frame ved 23.976 fps varer præcis 1001/24000s; et klip der starter én time inde ved 25 fps, starter ved 90000/25s. Hver værdi er en eksakt brøk, så fraktionelle rater repræsenteres uden afrunding. Der gemmer sig ingen drift i regnestykket, og lyd kan placeres med sample-præcision med nævnere som 1/48000s.

xmeml tæller hele frames mod en timebase. Et klips <start>, <end>, <in> og <out> er hele frame-numre, og en <rate>-blok fortæller, hvad en frame betyder: <timebase>24</timebase> plus et <ntsc>-flag. ntsc TRUE betyder ”divider med 1,001”, så 23.976 skrives som timebase 24 med ntsc TRUE, og 29.97 som timebase 30 med ntsc TRUE. Flaget er let at skrive, let at læse og let at håndtere forkert: et værktøj der ignorerer det, tolker en 23.976-timeline som ægte 24, og det er den samme fejl på 0,1 %, én frame hvert 42. sekund, som bliver dissekeret i guiden om frame rate-mismatch. Og fordi positioner er hele frames, må sub-frame-forskydninger i lyden, som sample-præcis dual-system-sync producerer hele tiden, enten rejse i en leverandør-udvidelse (Premieres eksporter lægger tick-baserede pproTicksIn/pproTicksOut-elementer ved siden af frame-numrene) eller rundes til nærmeste frame: én af grundene til at en sample-præcis sync kan lande en anelse skævt efter en tur gennem den gamle dialekt.

Sync og multicam: selvstændige objekter vs. nestede sekvenser

For dual-system-arbejde skilles formaterne præcis der, hvor det gør ondt.

FCPXML modellerer et synket par som et synchronized clip: ét objekt der rummer kameraklippet og lydrullens audio ved en fast forskydning, med roller (dialog, effekter) hæftet på. En multicam-gruppe er tilsvarende en selvstændig multicam-ressource med navngivne vinkler; det modtagende program får grupperingen, vinkelnavnene og sync-relationen som data, klar til at klippe i. Final Cut og Resolve læser begge disse objekter direkte.

xmeml har intet synchronized clip-element. Konventionen, grundlagt tilbage i FCP7 og stadig det Premiere forventer, er en sekvens pr. synket klip: billede på videosporet, optagerlyd lagt imod ved den rigtige forskydning, det hele navngivet som taget. Multicam bliver til nestede sekvenser inde i sekvenser. Det virker, og alle conform-værktøjer forstår det, men semantikken ligger underforstået i strukturen i stedet for at være deklareret: et modtagende værktøj ser ”en sekvens med lyd ved en forskydning”, ikke ”et synket klip”, og den organisering FCPXML siger ligeud, skal rekonstrueres eller genforklares i en navngivningskonvention.

Hvem læser hvad

Kompatibilitetsmatricen er mindre, end den ser ud:

To praktiske konsekvenser. For det første findes der ingen direkte XML-vej mellem de to største NLE'er: Final Cut læser ikke xmeml, og Premiere læser ikke FCPXML. Resolve er oversætteren i midten og læser og skriver begge. For det andet er ”hvilken XML skal jeg sende?” i virkeligheden spørgsmålet ”hvad står der nedstrøms?”. Og er svaret ukendt, indeholder den sikre editor-pakke begge dele, hvilket er præcis sådan en velbygget overlevering er skruet sammen.

Versions-dialekter

FCPXML versioneres aggressivt: 1.9, 1.10, 1.11 og fremad, med versionen stemplet i rodelementet. Apple dokumenterer hver revision, og nyere versioner tilføjer ægte semantik. Men Final Cut afviser versioner, der er nyere end det selv forstår, og tredjepartsværktøjer understøtter hver deres vindue af dialekter. Siden version 1.10 kan XML'en også rejse som et .fcpxmld-bundle, en pakke omkring det samme dokument. Den praktiske regel: spørg hvilken programversion der står nedstrøms, og eksportér den nyeste dialekt den accepterer, præcis som med FCPXML's fætter-problem, Resolves multicam-import, hvor dialekten afgør hvad der overlever.

xmeml er frosset. Rodelementet bærer et versionsnummer, men formatet holdt op med at udvikle sig med FCP7, og læserne er tilsvarende overbærende. Stabiliteten er formatets dyd: en xmeml skrevet i dag er strukturelt den fil, et conform-værktøj fra 2010 forventer. Prisen er, at alt hvad der er opfundet siden 2011, roller, captions, rigere rate-håndtering, sample-præcis placering, enten rejser i proprietære udvidelser som kun én leverandør læser, eller slet ikke rejser med.

Sådan dør gode XML'er

Udvekslings-XML fejler i mønstre, og næsten alle handler om identitet eller aritmetik:

• Den forkerte dialekt. En FCPXML én version for ny afvises blankt; en xmeml fuld af én leverandørs private udvidelser importeres med huller. Eksportér til læseren, ikke til skriveren.
• Det ignorerede ntsc-flag. En 23.976-xmeml læst som ægte 24 forskyder hver begivenhed med 0,1 %: sync der er perfekt i klippets hoved og en frame skæv i halen, den klassiske fejl i pulldown-klassen.
• Knækkede mediestier. xmeml gemmer absolutte file://-URL'er fra eksportmaskinen; importmaskinen har andre volume-navne, og hvert klip ankommer offline. Harmløst hvis relink-identiteten er intakt, fatalt hvis den ikke er, for…
• …relink nøgler på identitets-trioen. Filnavn, start-timecode, reel. Proxyer eller transcodes der har tabt reel'en eller fået stemplet ny timecode, relinker til ingenting, eller værre: til det forkerte klip. Kontrakten er den samme, som proxy-workflows lever og dør på.
• Blandede rater i én fil. En 25 fps-sekvens der refererer 50 fps-klip er lovlig og bliver rutinemæssigt håndteret forkert; hvert værktøj runder konverteringen en anelse forskelligt. Hold sekvensrater eksplicitte og kedelige.
• Håndredigering med en hjælpsom editor. Som med en ALE gennem Excel kan en XML gennem en ”smart” editor, der genkoder entities eller normaliserer whitespace inde i værdierne, korrumpere navne og stier usynligt. Redigér kopier, og diff før brug.

Hvilken skal du sende

Beslutningen koger ned til stolen nedstrøms. Final Cut nedstrøms: FCPXML i den nyeste dialekt, klipperens version accepterer. Premiere nedstrøms: xmeml med sync udtrykt som sekvenser pr. klip. Resolve nedstrøms: begge virker; FCPXML bærer den rigeste sync-semantik. Avid nedstrøms: ingen af dem. Send en ALE til metadata og AAF til sekvenser. Ukendt eller blandet: send begge XML'er ved siden af de samme medier, og lad hver stol gå ind ad sin egen dør. De to filer beskriver den samme sync fra samme kilde, så de kan ikke være uenige, medmindre værktøjet der skrev dem, var det.

Her passer Launchr Post ind

Launchr Post eksporterer begge dialekter i én arbejdsgang, på din egen Mac. Efter ingest og sync indeholder editor-pakken en FCPXML med synchronized clips og multicam-grupper til Final Cut og Resolve, en Premiere XML med de synkede sekvenser pr. klip, som Premiere forventer, og en merge-klar ALE til Avid. Alle refererer de samme medier med samme filnavn, timecode og reel, så uanset hvilken dør klippet går ind ad, falder relinket på plads.