FCPX metadata–how significant is it? And why?

[Bill Davis]

Oliver,

But isn’t’ the very concept of a “REEL ID” a contextual thing? I mean it’s certainly important meta-data – to my knowledge there isn’t actually a STANDARD for what a REEL is in the modern scheme of thing.

For one person it’s a physical tape. For another it’s a CF card. For yet another, it’s a DISC IMAGE on a hard drive. And just to look at that last case, that DISC IMAGE can be cloned so that instead of residing on a particular drive, it might also simultaneously exist on a “home” server, and/or on a thumb drive on the road.

The point is that the very IDEA of a REEL ID, is going to be increasingly variable. One user may want it to be a 5 digit number. Another producer may want it to be 7 place alpha-numeric designation.

Presuming that’s true, EVERY NLE manufacturer is going to need to do the same thing that Apple has done (and is clearly not the FIRST to do) here. Which is to provide a function where WHATEVER data is generated has a “capture pathway” into the DB.

My opinion is that if it’s META-DATA by nature, all you can expect APPLE to do in the design phase is to provide ACCOMMODATION for any and all types of data that their range of users want to provide. Asking APPLE to be the entity that sifts and sort and pick winners and losers from among the REEL ID tagging schemes of a dozen manufacturers is a waste of time at this point, IMO. Also, parsing database information presented in a text stream (something ALL databases are built to do) is so simple that worrying about whether someone will write the correct “translator” to make a particular systems ID scheme work in FCP-X has got to be dismissively trivial. I can’t fathom that since it appears that there are hundreds of thousands of X owners already – all camera manufacturers won’t get around to making their camera ID data accessible to it.

So I guess I personally don’t want Apple spending their time trying to determine and accommodate this manufacturer or that manufacturers particular REEL ID scheme. I want them concentrating on the GUTS of the program. Which is where they appear to be at this stage.

Trust me. In a capable database like the one underpinning FCP-X – if you have meta-data generated from ANYWHERE – there WILL be an easy way to leverage it.

(Heck, if I can CUT and PASTE text within it. (and I can!) then PASTE exists – and if it exists, then I can PASTE anything. Which is just another way of saying “general data import!” at a basic level.

Maybe they’ll keep developing it so it someday has a dedicated “import text file” capability with some ordering or parsing of the data available on import – that would be nice. And would blow open the whole “can it read my XML (or even historical CMX files!) debate nicely. But I don’t think asking them to concentrate on a front end at this point over “key features” is wise.

But that’s just me.

“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor

[Tom Wolsky]

I should note that reel information is available in FCP. It can be added and seen in the General display of the Info tab of the Inspector. It doesn’t display in the browser.

All the best,

Tom

Class on Demand DVDs “Complete Training for FCP7,” “Basic Training for FCS” and “Final Cut Express Made Easy”
Coming in 2011 “Complete Training for FCPX” from Class on Demand
“Final Cut Pro X for iMovie and Final Cut Express Users” from Focal Press

[Oliver Peters]

[Bill Davis] “But isn’t’ the very concept of a “REEL ID” a contextual thing? I mean it’s certainly important meta-data – to my knowledge there isn’t actually a STANDARD for what a REEL is in the modern scheme of thing.”

Sure. But right now, Apple doesn’t recognize its own “standard”, which is an embedded name/number/etc. in the “reel” column within QuickTime. Camera manufacturers, such as ARRI, are using that to identify the card. Other folks, like Avid make a distinction between a reel/tape (something captured from a VTR) versus a source (file-based). Import a QT with embedded reel ID and it shows up as a source ID inside Media Composer.

So while it’s contextual, Apple has provided a mechanism to use this slot in QuickTime files for whatever you need it to be. Sure would have been nice if they’d remembered that in the design of FCP X.

And please don’t bring up Apple and STANDARDS in the same sentence 😉 Apple has never expressed any interest in adhering to any actual sanctioned standards.

– Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com

[Jeremy Garchow]

Yeah, but Christian, this is FCP7s way, and frankly, it does allow searching, but it’s not very useful or powerful as every search takes a long time, and puts everything in to a new window/folder. It’s not very efficient and not dynamic at all.

Here’s how I like metadata in FCPX, and I also have some comments about other things.

It is true, embedded Reels don’t come in to FCPX for some reason. They do come in if you use the “import from camera archive” function (sort of like log and transfer). This seems to be a bug of some sort as there’s a reel column in FCPX. Perhaps it has to do with A/V Foundation vs Quicktime. I have no doubt reels will eventually make it in to FCPX, but it might take some work by camera developers.

P2 metadata does come in, but with caveats. It comes in to the absolutely massive metadata database that is in FCPX, but if you try and search for it in the browser, not all of it is available, it depends on the field. If you look closely at all the fields in FCPX, only the ones that are editable (the fields with the text box) become searchable in the browser. Here’s three screen grabs of every single metadata field that comes in to FCPX. Some of this is P2 specific that has been “preedited” in P2Flow before importing to FCPX. The difference here is that instead of a straight import, FCPX is actually reading the P2 XML file and parsing the metadata. In your case Oliver, if and when Arri develops an Arri importer for FCPX, I am sure the Alexa metadata will travel, or FCPX will need to be updated to simply read the embedded data in QT files (which it already does for tc):

metadata_01.png
metadata_02.png
metadata_03.png

And here’s a grab of the P2 fields that are implemented in P2 Transfers that have been preedited by me in P2Flow (searchable and non searchable) and some of these fields come from the camera metadata itself (like model name/number):

metadata_04_p2.png

Throw all of the politics aside for a moment and try to accept FCPX for what it is, not for what it isn’t, or isn’t yet. This level of information seems to indicate a connection to a rather large professional ecosystem that we just can’t see yet.

Now, why is FCPX’s implementation important?

Well, for me, it’s how I keep track of things. The longer a project goes on, and the more projects I work on in between that initial project, the less I remember about that initial project. If everything is catalogued, I can search by a word instead of scrubbing 25 timelines of selects (or I can also scrub selects in FCPX very easily, with no timelines, if that’s preferable).

Markers in FCPX also become searchable, AND they also transfer to the timeline index, so I can now search just the timeline for words in the marker.

And I’m sure you’re asking, “Well, why don’t i just put things in to bins and do it that way? It works fine!” Well, you can. But let’s say you know there’s a shot or series of shots that are from a certain location. Since FCPX has a dynamic keyword structure, those shots might be spread out across many keyword collections. In FCP, you can do a search for “Irvine, CA” and all those clips will show up which you can then make a smart collection for later use, or simply find the shot you need and add it to your timeline, and it’s all very fast and very dynamic. In FCP7, you’d have to dig through multiple bins looking for a few shots within those bins. It’s kind of messy.

If all of these FCPX metadata fields ever become searchable, you will be able to search for camera type (Arri Alexa or HPX-2000 for example) or embedded GPS coordinates (location), or once all the EXIF data becomes available, it will be searchable by lens, ISO or shutter speed. So if you need to do a certain treatment or series of treatments to certain shots from certain cameras, you will be able to parse that information by searching for “50mm EOS” or whatever. If you have multiple angles, you will be able to sort your footage by camera angle, or add a CC filter to certain angles just by typing “Cam_B” and adding a filter.

Metadata is data that describes data. As we move to an increasingly file based society, this metadata will do more to describe our footage and our deliverables much more so than a filename allows.

From an editing stand point it allows keywords to be searched without having to dig through many collections or bins. Simply select the Event, type the word you are looking for, and there’s your shot(s). Of course, this means you must take the time to enter this information up front. Since I have been working a metadata structure with P2Flow for a number of years now, this workflow is not a new venture for me. i find the more time I take upfront to properly add metadata, the greater that effort serves me as the project drones on, that is, it saves time later on. It’s the very reason Murch uses File Maker Pro as he said in the latest interview video. He wants to know where things are to give him a birds eye view of the project, without looking through mountains of footage/bins/selects/timelines. He can search by scene number, for example. FCPX begins to account for that style of thinking and workflow inherently in the application, and presents it in a very clear and dynamic fashion.

Sure, maybe not everyone needs that level of detail. I for one, welcome it as I like it and think it’s very useful.

Jeremy

[Bill Davis]

[Oliver Peters] “To my knowledge, it’s not there. I don’t believe any of the P2 data comes across. With Alexa this data is carried in an XML, not the QT. Since FCP X doesn’t read old XMLs, you don’t get this info. Presumably Apple is leaning on the implementation of camera manufacturer plug-ins based on their SDK. That doesn’t help with the QT issue though. For example, I never use native H264 5D files and always convert first. When I do, I add TC and Reel IDs. Only the TC is recognized by FCP X.

Oliver
“

That it might not “automatically” look for “P2” data right now, but it DOES “look” for CF card data and SD card data, so it’s clearly capable of “reading cards” with finesse.

So this is merely a development issue, not a capabilities one.

And the FIRST thing on the design teams list was clearly not “cater primarily to the guys with $60,000 cameras” (Are you shocked at that in a $299 downloadable program? I’m not.

I’m comfortable that if they continue to get the fundamentals of the development really right, I think it’s going to grow into a tool that handles EVERYBODY’s FILES – regardless of origin- including all the meta-data variants. (why build it as a “resolution agnostic” tool otherwise?) but it’s not a Version 1 priority. Nor should it be in my estimation.

FWIW.

“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor

[Walter Soyka]

[Bill Davis] “But isn’t’ the very concept of a “REEL ID” a contextual thing? I mean it’s certainly important meta-data – to my knowledge there isn’t actually a STANDARD for what a REEL is in the modern scheme of thing.”

Reel ID is not contextual. It is a property of a clip’s acquisition which should ideally carry through the entire post-production process. The physical acquisition format doesn’t matter; reel ID exists primarily to allow multiple clips from different acquisitions with common timecode to be properly differentiated.

[Bill Davis] “Trust me. In a capable database like the one underpinning FCP-X – if you have meta-data generated from ANYWHERE – there WILL be an easy way to leverage it.”

You don’t, which was what Oliver was pointing out. Even when the Quicktime media file includes a reel number, FCPX ignores it. FCP7 did not.

Also, and I intend you no offense here, but given Oliver’s extensive experience with Final Cut Server, I think we should be trusting him on the topics of capable databases and leveraging metadata.

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events

[Bill Davis]

[Oliver Peters] “And please don’t bring up Apple and STANDARDS in the same sentence 😉 Apple has never expressed any interest in adhering to any actual sanctioned standards.”

Really?

Funny, I kinda remember driving RS-232 and 422 decks 10 years ago out of FCP. Those weren’t “standards?” (I won’t belabor the point with a dozen other easy similar audio and graphics standards examples, (cough) AIFF, TIFF, … oh never mind ;.)

I will admit that Apple has a penchant for doing their own “standards” development in-house.

With all the IP wars going on between the monster companies these days (hello KODAK!) I’m thinking that’s been a pretty darn smart long-range strategy.

YMMV.

“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor

[Bill Davis]

[Walter Soyka] “You don’t, which was what Oliver was pointing out. Even when the Quicktime media file includes a reel number, FCPX ignores it. FCP7 did not.
“

Well as Tom points out, actually not.

I’d forgotten, but yes, REEL data is in there. It’s just not “front and center” in the display – but you can call is up by clip. So problem solved.

“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor

[Bill Davis]

Which is all well and good.

FCP-X takes “Find Whatever” AND gives you a way to persistently group all the Whatevers together – and after you’ve done that, you can narrow that list down to only BLUE Whatevers, and make THAT persistent recallable data.

If you can’t see how that might be more useful that being limited to “find whatever” then fine.

Your choice.

“Before speaking out ask yourself whether your words are true, whether they are respectful and whether they are needed in our civil discussions.”-Justice O’Connor

[Jeremy Garchow]

[Walter Soyka] “Reel ID is not contextual. It is a property of a clip’s acquisition which should ideally carry through the entire post-production process. The physical acquisition format doesn’t matter; reel ID exists primarily to allow two multiple clips from different acquisition devices with common timecode to be properly differentiated.”

But it kind of is.

For instance, in FCP7 and using P2Flow, the reel ID becomes the clip ID, which is a really long number. It points directly to that specific P2 MXF file. Would you rather have a Reel that points a to folder name that might change(or get moved) or to a unique ID that points to one file no matter where that file is located/moved? Here’s an example of some Reels that were handled by both P2Flow (third party) and Log and Transfer (FCP7):

reel.png

With Log and Transfer, the Reel is the name of the Folder. If that directory gets changed, moved or torn apart, the folder name is now meaningless as is the reel name. with the P2Flow Reel, that number describes a file no matter where it is, and it always reconnects really easily in FCP. This level of detail has made FCP7 more robust in it’s media tracking for us (but of course it’s not perfect as FCP7 can’t rearrange P2 MXF file structures).

So in this case, it is contextual to the program that created the reel number.

[Walter Soyka] “Even when the Quicktime media file includes a reel number, FCPX ignores it. FCP7 did not.”

With FCPX’s camera import SDK, I think Apple is leaving it up to the camera manufacturers to determine what the best reel number is for their footage. I am totally fine with that. The very nature of the definition of what a “reel” is in digital terms is redefined. It is not a physical object or location anymore and different cameras store data differently.

Damn, I was trying to get some work done, but this conversation is good!

Jeremy