[ This article was first published in the March, 2010, issue of
Larry’s Final Cut Pro Newsletter. Click here to subscribe. ]
As I was writing this issue of the newsletter, I got an email from John Bertram in Toronto that included two different missives on why metadata support is crucial to the next generation of Final Cut Pro.
One is a tongue-in-cheek monolog, which can be seen here. But the second was more serious, and more thought-provoking. So, I asked John to edit his second, wider-ranging essay into something shorter that focuses on metadata, because I wanted to share his commentary with you here.
Here’s what John wrote:
As recently as mid-2008, if you’d asked me to write down my personal “wish list” for Final Cut Pro (you know, that pesky list we all have bouncing around in our brains), I doubt the following paragraph would have even occurred to me. But today, in early 2010, I know this one wish would certainly rank at or near the very top:
Final Cut Pro urgently needs a vastly improved Metadata capability. Ideally this would be something very much akin to Aperture’s ability to import, create, customize, display, and intuitively manipulate a wide range of metadata — both camera-created and user-defined.
And here’s how my Conversion on the Road to Metadata came to pass…
By the time of Final Cut Studio 3’s release in the early Fall of 2009, it happened that I’d actually spent more of the preceding year working with Aperture than I had with FInal Cut — and had become so accustomed to Aperture’s powerful Metadata & Keyword-based sorting, searching, and organizational capabilities, that I began taking much of it for granted.
So much for granted, in fact, that I probably unconsciously just assumed that any new version of Final Cut was bound to have incorporated the same functionality. How could it not? Especially since both of these Apple applications typically involve importing visual media from a host of different cameras, and both frequently require accessing, arranging, and referencing hundreds — if not thousands — of distinct “creative units” at any given time. (In Aperture, those units are of course individual image files, represented by Versions; and in Final Cut, individual media files, represented as Clips.)
Most of my previous work in Final Cut had been on shorter, script-oriented projects, where all my meticulously-logged Scene, Shot and Take numbers (I’ve always had to be my own assistant editor) made Bin organization and Clip sorting relatively straightforward.
But it also happens that my first major project using version 7 of FCP (really “6.5” — but that’s for another rant — I mean, “article”) is a long-form, no-budget indie doc, with absolutely no pre-determined scene order, and certainly no script or slates to use as a numbering or naming guide. It’s just a few thousand clips worth of interviews and B-roll shot over several months (in both single and two-camera shoots; acquired on AVCHD but also HDV) — all of which is creatively open to being intercut in a thousand different ways.
No problem (I thought)! I’ll just organize this project the way I do my images in Aperture: I’ll use all that good metadata the cameras record (like the Date & Time info for each shot, which will make displaying any group of Clips in simple chronological order a breeze), and I’ll create new sets of custom Keywords (for location, interview subject, weather & light conditions, eyeline direction, which cameraperson, which interviewer, needs release form — and dozens more), which I can then apply to my Clips either as I’m logging them, or at any point along the way as I’m editing.
Oh, and in the Browser — just like with Aperture’s Smart Albums — I’ll simply create some Smart Bins, which will automatically include any Clips whose metadata and Keyword tags match the criteria I’ve set. Plus I’ll be able to do precise searches, simply by checking off the Keyword combination I want — with whatever “AND”, “OR”, “BUT NOT” qualifiers I choose (plus any further metadata filters such as date range, clip length, rating level, camera model, etc.) — and in a second or two see just the 7 or 8 clips out of my project’s 2-3 thousand whose attributes exactly match the search terms I’ve set. And all with just a few mouse clicks in what I’m sure will be the search window’s new, easy-to-navigate HUD — no typing required.
Yeah — it’ll be great…
Now, even before bringing my FCS 3 Upgrade box home from the Apple Store, I knew that many a “wouldn’t it be nice” Final Cut feature gets pulled over at the Carbon/Cocoa roadblock of Old Code vs. New Code, and that our dear old FCP is apparently still burdened by enormous and impenetrable sedimentary layers of the former, BUT…
I’d also been hearing about this glorious age of the “Tapeless Workflow” we’ve apparently entered — a brave new world where METADATA is king, and where we’re all supposed to be taking full advantage of it to organize our projects so much faster and with such greater ease. So you can imagine my disappointment that Final Cut Pro — even at version 7 — doesn’t appear to have gotten that particular memo.
In fact, compared to a now well-established program like Aperture, Final Cut’s abilities to ingest and retain, to augment and automate, to customize and configure, to easily access, selectively display and effectively utilize most kinds of Metadata — whether directly from the camera; added, edited, or inserted during the Logging process; or created, defined and applied within its own Browser — range from frustratingly limited to embarrassingly nonexistent.
But wouldn’t the kind of flexible, intuitive and infinitely customizable sort-ability & search-ability described above be a temptingly powerful option for just about any editor on any large project? Of course like any feature, no matter how elegant or appropriate, it would not get used by every editor, or on every project. Still, if all of Aperture’s metadata-based organizational power can be applied to individual image files (and has been for years now), why can’t it also be applied to individual movie files (aka clips) in Final Cut Pro?
Recent insights and musings from technology insider Philip Hodgetts have helped me better understand some of the technical, business, and design factors at play here. But even though some of this NewCode-requiring functionality may still be as much as two long years away for Final Cut, that won’t stop me beating the drum for the kind of metadata functionality I honestly think (however naively) any professional NLE should be able to do right now — even in the confines of a more rigid, “OS-9 Lives!” interface like Final Cut’s. Things like…
1) See, Retain, and MAKE ACCESSIBLE TO THE USER (in easy-to-customize Views) all camera metadata from ALL ingestible formats, whether SD or HD, tape-based or to-the-file born. For example, this would include the camera record Date & Time information from even Non-TimeCoded formats like HDV and AVCHD. No longer would we have the bizarre split-code personality disorder of Final Cut’s Log & Transfer window being able to see and display the Date created information for each about-to-be-ingested-and-transcoded AVCHD clip, only to have that same — and potentially quite valuable — information be invisible and completely inaccessible to the Final Cut Browser — the Browser of the very same application!
2) Let the USER assign and configure any number of custom-named Logging fields (with lots of preset templates to get started) — with more options for auto-repeating text fields, customized combinations of selected camera metadata merging with user-generated information, and a direct transfer of all that data into corresponding, easily searchable Columns in the Browser.
3) Let the USER create unlimited numbers of custom and always searchable Keywords. Keywords in families. Sets of keywords for different kinds of projects. Keywords visible in a floating Heads-Up Display, in a separate pane, or as buttons in their own visible-whenever-and-wherever-you-choose Control Bar. Keywords you can easily assign to a single clip (whether in the Browser or the Timeline; before ingesting or months into the editing); or to a non-contiguous group of selected clips; or to an entire Bin’s worth of clips — whatever’s highlighted, and all in a single mouse click.
Apple’s Aperture app (–and how much fun is that to say!–) does all this, and more, with relative ease. And it doesn’t ask you to purchase, learn, and then constantly have to work with a whole ‘nother, multi-user, high-end business program called “ApertureServer” to do so.
So if progress in software development is to be measured in terms of giving the USER more choice, more flexibility, and easier access to more information (so those choices can be made more intelligently) — which is exactly how I think it should always be measured — then surely bringing this kind of already-overdue Metadata muscle to Final Cut ASAP would be a huge step forward. It’s all about giving power to the User, not just to the Program.
Oh dear — I think I’m getting a little “verklempt”.
Best to end with the paraphrased words of Coffee Talk’s Linda Richman (aka Mike Myers’ classic SNL character): “Talk amongst yourselves. I’ll give you a topic: When it comes to Metadata, Final Cut Pro is neither final, nor cutting… (nor particularly pro). Discuss.”
JOHN BERTRAM is a Toronto-based writer/director/editor who is currently busy resenting having to learn anything at all about Codecs and Conversions, Renders and Resolutions, Formats and Frame Sizes, Gradients and Gamma Curves. He began Non-Linear Editing with Final Cut 4, and since then has been struggling to understand anything he can about, well… (see list). The preceding article, together with his new blog you can read here, will illustrate the futility of that struggle.
John also sent his original article to Philip Hodgetts who added the following comments:
[First, Philip wrote, I need to state that I have no insider information, nor am I passing on rumors. This is just my understanding from looking at the software with the eyes of a developer and connecting the dots.]
I guess you do know that FCP does retain all the metadata from non-tape workflows ingested via Log and Transfer. But the [Browser] bin code, as it currently is, is not flexible. Each column has to be added by Apple (and they have added a lot over the years). Needless to say I expect that is “non-trivial” to change.
But every indication is that Apple have been working on a foundation for metadata management in QT Media (as of FCP 5.1.2) and that is exposed in the XML export. See our miniME app- in demo mode you can export to an Excel spreadsheet. http://assistedediting.com/miniME
These things are, I think, on the road map for FCP but will require large sections of the code to not only be ported to Cocoa but also completely rewritten. When you rewrite one component it often has unforeseen (or non-obvious to those outside the dev team) consequences and implications on other code. Fortunately a lot of FCP was written in modular form from the start, Browser included. Check inside the FCP package > MacOS > Plugins > Browser.bundle. .bundles usually indicate complied C code i.e. Carbon. In fact there were earlier versions of these in all versions of FCP. The .bundle version dates from around FCP 4.5 (or perhaps FCP 4.0) when they recompiled the Carbon code from CFM (Code Fragment Manager) to MachO (and thereby losing OS 9 compatibility).
All these bundles need to be rewritten. Most can probably just be ported as-is without significant change to functionality. (Really what improvements to the Transition Editor do we need?) In the earlier versions of FCP I experimented with removing specific plug-ins and found FCP still ran but the functionality disappeared.
Anything in the Frameworks folder is Cocoa.
Also, the new code is found in Resources > English.lproj. A .nib file indicates Cocoa, so I’m informed: at least created in Xcode’s interface builder.
Overall, I’d say John is pretty much spot on as to what I’d like to see in the future version of FCP as far as metadata management, but it can’t be shoveled into this code. It has to be new. I also *hope* that Apple takes this opportunity to rework Media Management but I have no data points to suggest whether or not they will, particularly now that media management is very much improved from the early days.
Remember too, that the FCP dev team believed up until July 2007 that there would be 64 bit Carbon (only because Apple said so at the WWDC in 2006 only to reverse it a year later). it was only then that the need to rewrite became essential. Ultimately I think this is a great thing although it will take time because I’m of the (optimistic) belief that Apple will be rewriting things like the browser to give exposure to the metadata they’re already retaining and tracking. If they could have gone to 64 bit Carbon they may not have felt the need.
Which is why I think we’ll not see a new version until 2012 as I said in my recent blog post.
The reality of code development is that it does not scale. 10 engineers won’t be twice as fast as five. In fact evidence suggests that it would take longer with 10 than 5 (whatever the [actual] numbers are). There’s an article floating about the “myth of the man month” related to software dev scaling. Software development takes the time it takes.
Even so, I’d say it’s probably a very expensive rewrite, which FCP can definitely afford as the Pro Apps Suite (i.e. FCP really) is highly profitable based on my back-of-the-envelope calculations.
Good stuff, though, John. Keep the agitation going.
OTOH, Premiere Pro has awesome metadata tracking and handling and yet the users seem to not care about it one iota! If you’re at NAB catch my presentation on Wednesday at 1 PM in the PostPit at NAB on “The Mundane and Magic Future of Metadata”.
The issue of how you find media files when there are tens of thousands to search from becomes increasingly important as we move into all tapeless workflows. Adobe has staked out a strong position in this area for all their media applications.
It is my hope that Apple is working to bring the metadata power of Final Cut Server down into all of its applications, then make it easy enough for mere mortals to use.
[ Go to Top. ]
William Aleman writes:
Artists and producers are starting to ask for the display of their information (artist’s name, project details as extended description, “i” short for information, credits among others fields) in iTunes and Apple’s devices. The problem is that the information locally entered in iTunes’ tab is not embedded in the files, it’s user’s iTunes library display only. Moving the files to a different server or location will cause the lose of all metadata – information about the information- as described by some specialists in this field.
I haven’t found yet a way to add metadata from FCP 6.0 or Apple Compressor for iTunes and Apple’s devices while exporting the files, except chapter markers. In addition, all locally created music videos automatically get placed by iTunes under Movies category. That was until I found the solution through some dedicated software, which does just that: to embed this type of metadata in the files wherever they go.
I found three applications dedicated to embed metadata in video and audio file with the purpose of being displayed in applications that support the display of this type of data, including chapter markers, as iTunes, QuickTime, among others do.
This applications are MetaX, Lostify, (shareware) and SimpleMovieX (buy). After several tries of all three, the best that worked for me is MetaX.
A good feature of MetaX is that you can update the metadata in the files already in iTunes (music video, movie or audio) without re-importing them. In addition, we can change and embed a poster frame. To update the metadata, we just have to hold down ‘Control’ key in any iTunes’ tab, at the bottom of the list of the open window where we will find a text line that says “Edit Tag in MetaX” That will load the file from iTunes into the MetaX and will update it without leaving iTunes. I haven’t tried that feature in the other two applications. By the way, any QuickTime movie can be metadata embedded with this application, not just the H.264 Codec.
Shareware
- MetaX
- Lostify
Trial & Buy
Larry replies: Thanks, William, for sharing this information.
