BWF support in QuickTime and Final Cut Pro

One of the new features in Final Cut Pro 5.1.2 will be enhanced support for the Broadcast Wave Format. More informations about BWF can be found at the EBU Website.

BWF2XML is a helpful tool that was used yet for many productions with previous (and current) versions of Final Cut Pro and is recommended in Apple's white paper "Offline workflows for film and television using compressed HD" (page 11).

Beside all the other improvements with this new version of Final Cut Pro, one of the big improvements is that this new version makes extensive use of all the new QuickTime structures, allowing QuickTime metadata access and tc64 timecode (which is audio timecode). This last QuickTime feature has been tested by me with a real lot of different files from different recorders and DAWs, and all files with tc64 information showed up correctly in Quicktime Player.
Additionally the QuickTime metadata access will allow third parties to create QuickTime components with metadata - like the DPX/Cineon component from Bob Monaghan at GlueTools, His component and metadata support seems to work perfect with the 5.1.2 update, change of entries in the file info are written back thru the component to the DPX sequences. His component is the first of it’s kind.
This feature will also allow other companies to create a QuickTime components for MXF, IMX etc., and you’ll be able to drag a MXF (or something like that) to the timeline with all the metadata included. So stay tuned for future announcements from third parties.

tc64 audio timecode is something new in QuickTime:
QuickTime is interpreting the BWAV header entry for the samples after midnight - most of you (at least those who are interested) can check that: just open a BWF file in QuickTime Player Pro (7.1.3), press cmd-J and enable the TC track. You’ll see the samples after midnight (don’t save when closing the file). When you try this, try just another thing, select the timecode track and select the tab "Resources". It will show you the name and source of the timecode. In case of a tc64 timecode track, there is no name available and the source is in memory. Activate the audio movie again and click right arrow (left arrow) to step forward/backwards one frame - the time will go either to the end of the file or the start. Seeing this behaviour might make some of the things written below a little bit more understandable.

Final Cut Pro 5.1.2 makes use of this this QuickTime tc64 feature, and creates a SMPTE timecode based on the tc64 samples since midnight and the actual file sampling rate. This will result in seconds since midnight. The seconds can be converted to timecode by extracting hours, minutes, seconds and partial seconds, based on the setup's timecode base (and the timing) at launch time of FCP.
The file's timecode base is complicated to figure out, since mostly it’s not written to the header of the BWF file. And even if it is, QuickTime won’t interpret it, since it is nearly impossible to automatically interpret all the ways the header could be set up.
There maybe other information in the header as well like reel, scene, take, note etc. However, this currently won’t be interpreted by QuickTime. As opposed to a QuickTime timecode track, reel information can't be kept in a tc64 track. So if QuickTime doesn’t interpret it, Final Cut Pro can’t either, and for the timecode base (as said above), it will use the timecode settings of the setup you used when launching FCP, which might differ from the original sound recording.
When recording audio, there are also timecode settings like 29.97 NDF, 29.97 DF, 30 NDF, 30 DF, which are either not available as an option in Final Cut Pro right now or differ in handling.
So the file's samples since midnight may be based on either real world seconds or NTSC seconds, which is not available as an option in FCP - depending on your launch setup FCP assumes that times are based upon NTSC slow second timing (or not in case of 24, 25, 30); this can lead to some confusion in case you are working with 29.97 DF audio, since FCP will interpret that audio time as 29.97 Full-Frame, which causes the TC to display a lower time value and that doesn't match those seen by other applications.
With BWAV files, there may be 'playback instructions' in coding history or other parts of the metadata. All of this is quite a complicated thing, and it will be left to the user to think about the setup in advance.
For some help see the tables at the end of the text.

Some more details about the two kinds of timecode tracks:
The QuickTime timecode tracks we are used to work with behave, let’s say, just like another “movie” track, so you can step thru frames.
tc64 reads the timestamp of an BWF audio file - this happens only once, so it behaves like a long frame, which can’t be stepped thru by samples, frames, seconds etc. It’s just one frame when activated (in QT Player Pro) - even though it shows the samples during standard playback.
The QuickTime timecode track forces a file into a specified playback behavior, which is user- or application-defined, and can be changed within Final Cut Pro (within certain limits). It can also be used as AUX TC in synched clips.
tc64, when used in QuickTime/Final Cut Pro, just gives a reference which relies on the sample rate to get the time. To change the playback behavior, you need to change the sample rate “virtually”. This means that the file’s samples are not changed but the “this file is sampled at” entry will be changed as well as the "samples after midnight" one. This only can be done with third party applications outside of FCP.

Advantages and disadvantages of the tc64 timecode handling with FCP 5.1.2.
The advantage definitively is that you can work with the original source files in some cases without the need to modify them.
The disadvantage though maybe the way FCP interprets the tc64.
As said above the interpretation is based on the launch settings of FCP So for example starting with a 25 fps setup any files imported, will be interpreted as 25 fps based, even if the sound is recorded at a different setting, it would be same with a film project at 23.976 where the sound is done on 30/29.97. You can start (with a new launch of FCP) with the (more or less) correct set up for the audio, then open the real project and copy the files. This will keep up your audio TC for a while, if you did it the other way round you stuck for a while, since FCP "remembers" the first interpretation. I the latter case an option is to make the files offline and reconnect, but this will cause a recalculation within all projects you used the sound file and this may need quite a few clicks when you open them again.
Except with the "29.97 DF" set up the above doesn't matter in many cases, but you should be aware of it. And finally it only matters if you need audio timecode.
But there is still the synch issue and that's a bigger one. To get an overview see the tables at the end of the text.
Also as said above, with QuickTime timecode there is timecode, timecode timebase, reel info and playback instructions which are constant thru projects and setups, with tc64 there can’t be timecode timebase, reel info and playback instructions with the current handling.
Something which can lead to even more confusion is the fact, that FCP doesn't handle DF timecode for audio, so whatever setup you have, the tc64 timecode will be handled as NDF. Additionally the FCP way of describing time uses 30 DF or 30 NDF, which differs from the audio 30 DF or 30 NDF which is finally something different.

File formating and appearance:
BWF can show up in either polyphonic or multi-mono format. Both of these formats do have advantages and disadvantages.
Polyphonic files are easy to handle. As all tracks are included in one file, they maybe faster on transfer from the audio harddisk recorder than mono files. Polyphonic files are also easy to import with the new Final Cut Pro feature. They have the disadvantage that removing unused tracks is difficult when it comes to exchange with other audio workstations or when using XML and reconnect, since they are interleaved.
Mono files may take longer when transfered from the audio harddisk recorder since the de-interleave may have to be done prior to transfer. They also have the disadvantage that they can only be imported as discrete files, and need to be connected “channel by channel” with Final Cut Pro direct import features, which makes the process much more tedious. The big advantage of using mono files though is, that you can remove (or even add) channels and will have no problems when doing an interchange with DAWs, via XML (as long as they are not linked in FCP 5.x) or with content management systems - or within FCP environments via XML (as long as they are not linked in FCP 5.x). With a set of mono files the channel files can be handled by Media Manager up to a certain extent when left untouched, or fully when converted to a .mov format.

What about bringing BWF2XML and the new QuickTime/Final Cut Pro features together?
This should work cool (as long a the project organization is kept straight like 24 fps film/video and 24 fps audio), since Final Cut Pro 5.1.2 will accept the tc64 for first time ever, and BWF2XML can supply you or Final Cut Pro with the additional metadata without converting to QuickTime timecode (though as you read above there are still a real lot of advantages doing that).
But it needs some additional steps done with BWF2XML, like maybe changing playback settings to apply pull-up or pull-down. If that’s done, BWF support in Final Cut Pro can be exceptional compared to other NLEs since the amount of tracks supported, the metadata exchange, and conversion will be lightning fast - even if there is no direct import plug-in for this “combined” import. With the new XML version 3, things may become easier and BWF2XML may work as a pseudo importer plug-in using the Apple Event support of FCP.

So why do I write all these mostly “negative” things (about FCP)?
Pretty simple, since working with these relatively new formats and devices isn’t that simple for most video and postpro people.
Apple made another step into the tapeless future, as well as some of you who made this step using “new” devices and formats. With new devices there is always the problem to establish something like a “common sense” for set up and workflow, which doesn’t exist right now.
So if a BWF import into Final Cut Pro would give you an erroneous result, don’t blame Apple and don’t start threads about blaming Apple, they made the above step, and they too will probably run into similar problems as any of the other companies - like me - who are dealing with BWF, machine setup, file setup and naming as well as user setups.
Other companies just restrict, maybe by the amount of channels, maybe by the titles/names of metadata entries, maybe by kicking out metadata entries - and still these other companies look to be a little bit ahead.

An Apple explanation about the handling of BWF and FCP 5.1.2 can be found here.

Though I normally don't overlook any of the BWF audio things happening with FCP, I did overlook the above one.
It's a little bit incorrect about the calculation of TC when importing:
"When you import a Broadcast Wave file, Final Cut Pro calculates timecode based on two parameters:
The time base (frame rate) of the currently selected sequence preset
The audio sample rate of the imported Broadcast Wave file"

It should read:
"When you import a Broadcast Wave file, Final Cut Pro calculates timecode based on two parameters:
The time base (frame rate) of the selected preset at FCP launch
The audio sample rate of the imported Broadcast Wave file"

Though things can happen with a BWF which are related to "the currently selected sequence preset"

But it is quite a good explanation why (29.97) DF audio setup won't work.
And it shows another new feature I've overlooked: first time ever you're able to change audio TC to DF with "Modify -> Timecode"; it's not a big help if you have to change the TC of some hundred files, but finally it's in there after all the years.

Something they also forgot to mention is that the TC (modification) is only cached to the FCP project, so if files go offline and are re-connected all modifications are lost and/or re-interpreted using the current launch settings.

Known bugs or oddities in FCP with BWF (audio and XML) - means what you should avoid do with FCP and BWF (and other audio and XML):

  • Using FCP 5.1.2 / other 5.x: Importing a multi mono set of BWFs and use the "Merge Clips" function all tracks will be renamed to the name of the first track.(This is not a BWF specific feature)
    Exporting such a clip as XML and re-import will fail, if there are more than two tracks and there is NO CHANCE to re-connect. Versions below 5 don't show this behaviour.
    Timecode behaviour will be the same as described.

  • Using FCP 5.1.2 / other 5.x: Linking a multi mono set of BWFs in the timeline will keep the track names as long as you don't drag them to the browser or into a bin. Exporting the linked clips from the browser/bin as XML will have the same effect as above.
    Exporting the sequence will work.
    Timecode behaviour will be the same as described.

  • Using FCP 5.1.2 and BWFs, the files should never go offline, since re-connect may re-calculate data and TC related entries.

If you find other strange things happen please report this to the FCP Feedback Team

You can send me a mail about that as well

Comparing FCP's direct BWF importer, BWF2XML and Sebsky.
The below results are the results of several tests I did and they did proof to be true and repeatable on my machine, but I don't give any warranty that these results are globally valid.
I haven't found the time to test long recordings, which would show whether the below "(ok)" entries would really mean a "run out of synch" or whether it's only a normal rounding error.

Supported Data or Actions FCP 5.1.2 BWF2XML Sebksy
Audio TC
QT TC no
User selectable Timebase/TC (no)* (•)**
Reel Support no
29.97 DF support no
User Selectable NTSC/Real World Timing for QT TC no no
Full Metadata Support and Mapping no (•)***
Automatic Mono File Merging via XML no no
Automatic Mono File Group Merging to Stereo no no
Virtual Premix no no

*) Needs to select the correct setup (if available), then quit FCP and re-launch.
**) audio QT TC: 24, 25, 29.97 DF.
***) No metadata mapping.

Working Setups Using FCP's direct BWF importer.

For detailed descriptions see tables below.

Audio/FCP@Launch FCP 23.98 FCP real 24 FCP 25 FCP (24@25) FCP 30 DF or 30p FCP 30 NDF no NTSC
23.976 NDF (ok)* no no no no no
24 NDF no ok no (ok)** no no
25 NDF no no ok (ok)** no no
29.97 NDF no no no no ok no
29.97 DF no no no no no no
30 NDF no no no no no ok
30 DF no no no no no no

*) should work, but the duration/synch may differ slightly.
**) does work, but the audio timecode runs on 25 fps.

Results using FCP's direct BWF importer.

The tables below show the timecode value comparison between original BWF iXML values generated by the recorder and those values displayed in FCP.

"-" shows that the FCP value is either too early or too short, "+" means that is either too late or too long.
The "ok" indicates that the values match, a "(ok)" indicates, that they do nearly match.

The light/darker green backgrounds show that both start timecode and duration match either exactly or more or less.

The blue backgrounds show that start timecode match with +/- 1 frame and duration match (or match somehow), but running timecode wouldn't reflect the original file's running timecode.
The additional light/darker brown backgrounds indicate, that this setup will keep the stuff in synch and can be used for short audio clips if you don't need audio timecode. The synch should work there, but as said above it's not tested with long files and there it probably won't match.

Audio Recording Setup:
48000 kHz Hardware / 48000 kHz Digitizer / 48000 kHz File Sample Rate / 48000 kHz TC Sample Rate

FCP @ Launch Settings = 30 DF (Using DV-NTSC Easy Setup)
Audio Recording Settings Matches Start TC Duration TC
23.976 no + +
24 no - +
25 no - +
29.97 NDF (ok) (ok) ok
29.97 DF no - ok
30 NDF no - ok
30 DF no - +
FCP @ Launch Settings = 30 NDF (using FCP 30 p settings)
Audio Recording Settings Matches Start TC Duration TC
23.976 no + +
24 no - +
25 no - +
29.97 NDF ok ok ok
29.97 DF no - ok
30 NDF no - ok
30 DF no - +
FCP @ Launch Settings = 30 NDF (using a real 30 FPS setting)
Audio Recording Settings Matches Start TC Duration TC
23.976 no + +
24 no - +
25 no - +
29.97 NDF no + ok
29.97 DF no - ok
30 NDF ok ok ok
30 DF no - +
FCP @ Launch Settings = 23.976 (which is used by standard p24 presets - so PAL users should build their own)
Audio Recording Settings Matches Start TC Duration TC
23.976 (ok) ok +(ok)
24 no - ok
25 no - ok
29.97 NDF no - -
29.97 DF no - -
30 NDF no - -
30 DF no - -
FCP @ Launch Settings = 25
Audio Recording Settings Matches Start TC Duration TC
23.976 no + +
24 (ok) +/-ok - (ok)
25 (ok) ok + (ok)
29.97 NDF no + -
29.97 DF no + -
30 NDF no - -
30 DF no - -
FCP @ Launch Settings = 24@25
Audio Recording Settings Matches Start TC Duration TC
23.976 no + + (ok)
24 (ok) +/-(ok) ok
25 ok ok ok
29.97 NDF no + -
29.97 DF no + - (ok)
30 NDF no - -
30 DF no - -
FCP @ Launch Settings = 24 (real 24)
Audio Recording Settings Matches Start TC Duration TC
23.976 no - + (ok)
24 ok ok ok
25 (ok) (ok) ok
29.97 NDF no + -
29.97 DF no + - (ok)
30 NDF no - -
30 DF no - -

If you need an application that reads and displays (nearly all) BWF metadata to test your BWAV files for FCP compatility drop me an email.

© 2006 Andreas Kiel, Spherico Filmtools