Peter Schneider of Gotham Sound and Communications, an audio sales and rental house in New York, gave this address at IBC 2006 in Amsterdam.

As many of you know, a couple of years ago, they stopped making location DAT recorders and so there was a quick move towards file based recorders for on set production. One of the things that came about as a result of this quick move is that no longer is it suitable just to record a file and write a label and hand it into the production personnel down the line. And as the metadata – the data about the data - became more and more embedded into the file, it became increasingly obvious that, number one, the existing ways of recording that metadata were inadequate and, number two, mistakes and errors made on set during the production became increasingly amplified as those files made their way through the post production chain, even if the mistake was as simple as not being able to find a track, where an actor was wired, for example, that could have saved an ADR session.

Mark Gilbert from Gallery, who couldn’t make it here today, is one of the leading proponents of iXML as a result of some of the ambiguities in the current BWF chunk way of storing metadata. As a company that’s in business not just to sell the stuff, but to support it, we wholeheartedly endorse iXML or whatever it will eventually become as a way to keep these errors from being amplified and ultimately affecting each of us down the whole chain of post production. 

One of the key things that I think iXML addresses is particularly valuable to the NTSC world where you sometimes have the requirement of recording at a sample rate that’s deliberately different from the sample rate that you intend to play back at, and this goes to NTSC pull-down issues. For example, many times on set sound mixers are asked to record at 48.048k, ultimately to be played back at 48k. Right now the Broadcast Wav spec has no way of indicating this difference; they only say that 48k is a valid sample format and this has lead to all kinds of misinterpretations among the many different manufacturers as to how to handle this situation. iXML now can very neatly address this situations by separating what the file was recorded at, what its intended playback rate is, what the camera frame rate was intended to be and, in fact, was on set. This can only help, certainly from a selfish point of view, the number of support calls we get, both from our customers directly and from the other facilities down the post production chain.

I’m happy to report that almost all of the manufacturers that we deal with and again, it’s primarily portable recorders, are beginning to adopt iXML standards. Fostex, Sound Devices, Zaxcom, Aaton, and HHB are all either fully on board or intend to be fully on board. Finally, the other thing that’s great about iXML for us is that is allows certain unique metadata that’s unique to the set to be stored, things like the clapper sync point, things like scene and take numbers, things like whether the camera was even rolling or whether it’s just a wild track. Things that there was just no standardization for until iXML came along.

Prototype of the "MetaSlate"

I brought a show and tell for the kind of integration that it allows. Basically, we took a regular dumb slate, attached standard security alarm magnetic sensors to the back, hooked it up to a 35mm flash transmitter and now, when the sticks close, the pulse is transmitted to this receiver which, I can assure you, is no easy feat to get thru airport security.

Mark Gilbert at Gallery changed his MetaCorder software to now read the pulse and store that as part of the iXML chunk where exactly the sticks closed. This has huge implications for telecine operators because many times they are stuck with reading numbers on the slate that are just incorrect and this just cuts across all that sort of ambiguity of what the time code numbers on the slate mean or don’t mean and go right to the heart of the matter. That’s something that’s very unique to iXML.

Mark’s also taken the further step of then embedding that into the iXML right into Final Cut. We record the sticks and now on the time line of Final Cut, when I open up the file, are markers for when the sticks closed.

That kind of integration has tremendous capability and I think as we look forward to the future of what can happen on set, I see a set area network developing where the script supervisor, the camera department, and the sound department all share and exchange metadata and can make corrections on the fly even to the extent where slates can have electronic LED's. In fact, we’ve been talking to Chris Price at Ambient and Charlie at Denecke about paper LED’s, this kind of paper new electronic ink display so that literally a script supervisor with a PDA can be entering in the scene and take number all while the assistant camera person is recording the footage. I understand that Cook make an announcement at this show where they’re now recording lens metadata and can do so linked to timecode and all of this information can be gathered on set and forwarded down the line.

The most important thing we can do now is to agree on a standard and make that standard public, so that any manufacturer can jump on board. Filmmaking is a collaborative enterprise and I think iXML can only make that collaboration stronger, if we go about implementing it in an organized, thought-out way.

Thank you.