Peter Schneider of Gotham Sound and Communications, an audio sales and rental house in New York, gave this address at IBC 2006 in Amsterdam.
|Peter Schneider (C) discusses iXML with other
attendees at IBC
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.
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.
Prototype of the "MetaSlate"
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
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,