Sound Recordists/Editors, Metadata and iXML

[redge]

I am wondering whether there is some point in discussing what sound recordists and editors think should be included in iXML metadata. The subject came up in some detail during today's first rate seminar held in New York by Gotham Sound and Posthouse, which was also broadcast over the Web to participants from five countries. By sound recorderists, I include in addition to location sound recordists people who record ambient sound, nature recording, radio recording and other types of recording, including recording where archiving and searching is an issue.

I raise this question because the manufacturers of recording hardware and software are moving in the direction of adopting iXML as a standard. This raises the question of whether users should be talking about this, and whether there should be a users' group that can express its views to those who are setting the standards.

In making this post, I want to say specifically that the subject is not whether iXML metadata is a good idea or a bad idea. There have been a number of discussions about that question on ramps and elsewhere. There is a view that anyone who thinks that iXML is a good idea is, at best, a bit thick. That is not the issue that I want to raise, although of course if others want to rehash that question, that is their right, subject to the moderation of our host.

Rather, my questions are these.  Given the fact that iXML is being implemented, should there be a users' group that has an impact on how it is implemented and, independently of that question, what kinds of information should be included as metadata having regard to the needs of sound recordists and editors both within and outside the location sound community?

Best,

Rory

[Philip Perkins]

For me: SR, bit width, date, BWF file TC start, scene, take, maybe project name.  I'm not going to have time for much of anything else.  During shooting I want to be dealing w/ scene/take and nothing else.

Philip Perkins

[Darren]

For interest's sake,

Attached is a screen shot of the iXML reader app displaying all of the available data for an iXML 1.4 test file.  Please note that this is slightly out of date as the newest version of iXML is iXML 1.5.

iXML reader app and test file supplied by iXML.org

Also, here is a link to the Pro Tools iXML implementation chart.  You will be able to see exactly what iXML data pro tools supports.

http://www.digidesign.com/index.cfm?navid=54&itemid=23398

Metacorder's iXML 1.2 implementation chart (from Sept 2005):

http://www.metacorder.info/ixml_implementation.html

More info on iXML is available at www.iXML.info

iXML_1.4_data_screenshot.pdf

[Guest tourtelot]

Again, why do we want to fill out all this stuff instead of worrying about what the actors are saying in the next setup.  I don't understand all the noise about this.  In fact, I think that it all comes back to the whole push toward technicians running machines intead of mixers mixing production sound.  I think that all the schools that turn out wads of technically skilled folks with no idea of the whys and wherefores of mixing sound on a movie have pushed post production and hence, producers into expecting multi-track captures of wireless mics because so few people get trained in how to be a great boomman or a great sound mixer.  I am sorry; it probably sounds like I am just a grey oldtimer, but any monkey in headphones can record eight wireless mics onto eight tracks of digital disk for some real mixer to put together later.  Producers are getting used to having mixers who can't mix and, more importantly, boom operators that have no idea that you actually need to follow the head turns with the mic for the boom track to be usable for anything other than a guide track to post-dub radio mics to.  Shee.  Let's take up even more space with how important it is to use a fucking keyboard and how unimportant it is getting to use our ears.  Rant off!

[redge]

Thanks Darren,

In pursuing the links that you provided, I discovered that you may have missed a bit of the URL for the ProTools Implemenation Chart. The following took me directly there instead of to the home page: http://www.digidesign.com/index.cfm?navid=54&langid=1&itemid=23398

[Darren]

Here's a link to a short iXML article featuring Gotham's Peter Schneider.

http://www.imakenews.com/gothamsound/e_article000659356.cfm?x=b8k5LGn,b3kH0Kv1,w

[Noah Timan]

There is a lot of metadata that is either automatically entered based upon machine settings (bit rate, sample rate, time code frame rate, TC values, etc) or based upon things that are or could be entered once at the beginning of the day (sound roll in universal format, etc). 

The only thing that I feel is important for us to constantly enter and adjust is track information. 

Supe Sound Editor Steve Borne's comments at the Gotham seminar about how iXML metadata is used were interesting.  Rather than an auto-conform scenario, as previously discussed here, Steve indicated that in his experience, the auto-conform software process (even with established plug-ins like Titan) was still riddled with bugs and flaws and it still doesn't work reliably.  Much as in our discussions here, there was a lot of mention of "it should do this" and not a lot of mention of "it DOES do this, and as such it's an important part of our workflow".  He further indicated that conforms of ANY type -- whether they be auto or traditional -- are rare, and that the normal scenario is that there's an OMF and that's what they get.  When they can, they dig for external tracks manually, but the OMF (or its current Apple-sponsored successor) can help by allowing a reference to what other tracks may exist for a certain shot via iXML metadata.  He indicated clicking on a track and receiving a list of all other simultaneously recorded tracks available for that shot.

So it seems to me that the most useful information that we could impart via metadata is a thorough and detailed list of track names.  In other words, rather than just [track1] [track2] etc, put in "Mono Mix" in place of track 1, "Boom" in place of track 2, "Jeff lav" in place of track 3, etc.  If the software on our recorders allowed for a simple cut and paste procedure this could be easy since we are probably just using the same mic or track names over and over again throughout the course of a production and this would eliminate the tedium of typing the names in every setup.

But this would allow post to see clearly what is available to them -- even if they've lost the sound reports or can't cross reference them or whatever.  This is also one of those things that I wouldn't want to trust anyone else to do.

I am quite content, however, to pass the buck on entering scene and take info to the assistant editor, at least until the use of metadata in telecine becomes a working reality.  It's a pain to keep up with on set -- slates change all the time, even in the midst of a setup, false starts are a pain to deal with even when there is easy facility for them, and most importantly, most of that metadata just winds up on the cutting room floor.  Think of shows where the director likes to do 10+ takes of everything but only one ends up in the movie.  Much easier imho for the asst. editor to enter the info for the one relevant take going in than for us to enter info for every single take "just in case".  We've got enough to do as it is.  So do they, but it's less work for them than for us if they don't have to do all the unwanted takes, and it's more error prone on set with all of the misslating, mid-setup corrections and discussions by scripty and 2nd AC ("was that take 4 or 5?"  "No, this should be R23-D-C 3 PU, not 24A take 4!" etc etc).

.02 nvt

I am wondering whether there is some point in discussing what sound recordists and editors think should be included in iXML metadata. The subject came up in some detail during today's first rate seminar held in New York by Gotham Sound and Posthouse, which was also broadcast over the Web to participants from five countries. By sound recorderists, I include in addition to location sound recordists people who record ambient sound, nature recording, radio recording and other types of recording, including recording where archiving and searching is an issue.

I raise this question because the manufacturers of recording hardware and software are moving in the direction of adopting iXML as a standard. This raises the question of whether users should be talking about this, and whether there should be a users' group that can express its views to those who are setting the standards.

In making this post, I want to say specifically that the subject is not whether iXML metadata is a good idea or a bad idea. There have been a number of discussions about that question on ramps and elsewhere. There is a view that anyone who thinks that iXML is a good idea is, at best, a bit thick. That is not the issue that I want to raise, although of course if others want to rehash that question, that is their right, subject to the moderation of our host.

Rather, my questions are these.  Given the fact that iXML is being implemented, should there be a users' group that has an impact on how it is implemented and, independently of that question, what kinds of information should be included as metadata having regard to the needs of sound recordists and editors both within and outside the location sound community?

Best,

Rory

[Darren]

"The only thing that I feel is important for us to constantly enter and adjust is track information."

Personally, I feel that scene, take, and notes are also important.  As far as notes go, while I know that there are people here that detest keyboards, I have really enjoyed trading in my pen and paper for a keyboard and being able to make *detailed* notes for each and every take when necessary.

"If the software on our recorders allowed for a simple cut and paste procedure this could be easy since we are probably just using the same mic or track names over and over again throughout the course of a production and this would eliminate the tedium of typing the names in every setup."

Needless to say, entering track name info is quite simple with a computer based system such as Metacorder or Boom Recorder.  But Kudos to Sound Devices as they now have a "drop down" type of menu system where you can store a list of pre-named track names and assign them to tracks as necessary, even without a keyboard.

Cheers,

Darren

[soundtrane]

http://www.digidesign.com/index.cfm?navid=54&langid=1&itemid=23398

Just get into the digidesign website and do a search for "ixml" and you'll get to the page straight away.

-vin

[soundtrane]

For me: SR, bit width, date, BWF file TC start, scene, take, maybe project name.  I'm not going to have time for much of anything else.  During shooting I want to be dealing w/ scene/take and nothing else.

I have a humble opinion about this:

ONE - I agree with Phil and Doug to a great extent. I have personally experienced the 'clerical' feeling when I first started using a NL recorder - I was maintaining a physical sound report along with entering metadata into the recorder - secne, shot, comment (noisy/airplane/ambience etc) and cross reference the Event Number to the physical report. Phew...

Maybe iXML is actually to cross reference between people who do different things on the shoot but all handle data that is crucial to a smooth post job. I mean to say, someone like the Script Supervisor can dictate exact scene/shot numbers, false starts, etc. This info should be relayed wirelessly to the NL recorder and thereby to the post.

I remember a Hollywood gig I was doing last year out here in India - the daily grind at wrap would be the Script Supervisor wanting to go through the entire sound report to corroborate with her data. Many times I would be right and she would be wrong. Many times, she would yell out a new scene number (that's beause they decided to shoot scenes different from what was in the call sheet, and I would basically follow the call sheet to figure what scenes were to be shot the next day). Or I would be handed sides which had scenes quiet different from the call sheet and would have to  're-adjust'. Too much effort in human coordination was required to fill in a few numbers.

For that matter - ANYONE who has to maintain some kind of report that refers to numbers on the set that NEED to be coordinated and matched with each other should be done in such a way that each person only enters what is unique to him - for example - the mixer has track descriptions, take - ok/noisy etc., standard entries - bit rate, etc to fill, the script sup has sc/sh/tk to fill in etc.

-vin

[Noah Timan]

Personally, I feel that scene, take, and notes are also important. 

Scene and take can be more efficiently and accurately entered by the assistant editor...see my post about this.  Notes are good, but it's still a clunky time-consumer to do this on many recordings.  The Deva has a pretty elegant way of coining shortcuts for notes, but even that's not perfect.

As far as notes go, while I know that there are people here that detest keyboards, I have really enjoyed trading in my pen and paper for a keyboard and being able to make *detailed* notes for each and every take when necessary.

Telecine and others still want a paper report in addition to whatever you enter in the metadata.  In this transitional period, it is disheartening to go through all of the effort to enter the metadata thoroughly, knowing it will probably not get used for anything -- especially since, as others have noted here, it chews up time and attention span that could benefit the track much better by having that resource focused on fixing noise problems and working on micing between takes, instead of data entry.

.02 nvt

[redge]

I approach this question as someone who has used the full range of Adobe products. These products include metatdata capabilities that have been around, and have been considered basic, at least in the photographic world, for many years. They also include the ability to customize metadata. In comparison, the current metadata capabilities for sound are primitive.

It is interesting that some sound people care only about metadata at the capture end. This is like a photographer, using a digital camera, saying that he or she cares only about what the camera registers as metadata. Indeed, that is pretty much where we are at with sound. But the fact is, no professional photographer is satisfied with the basic metadata that the camera captures. They enter, and use, much more. To take the most obvious example, one of the basic abilities is to search for photographs according to key words that have been applied to individual photographs. For photographers, this is not fluff, it is essential to organisation. The value of an ability to find files by key word is equally obvious for recordings of ambient sound. For example, I have many sound tracks (ambient, and dialogue given that I am working on a radio documentary) that I have tagged with key words in Adobe Audition. This makes it possible to locate these tracks, and pull them up from a hard drive, immediately, simply by entering a search term.

In other words, photographers use metadata captured by their camera plus metadata that they input later. This information is used not just by the photographer, but by others up the line, who edit and publish the photographer's work, and who add their own metadata. Nobody, as far as I know, thinks that this is problematic or challenging. In fact, the idea, in the world of photography (or web design or book publishing), that metadata capture should stop with the camera (or in the case of sound, the recorder), would be considered bizarre.

The interesting question, considering that iXML is happening, is who is going to make the decisions on iXML, how standardized it will be, how customizable it will be and whether iXML will take into account the interests both of people who record sound (including people who are not making fiction films or television commercials with scene and take) and people who then work with sound. It would be interesting to know whether there is a process for dealing with these issues, or whether some "result" will be presented as a fait accompli.