Moving toward reading FCP source timecode from imported Quicktimes in After Effects

A recent thread on aenhancers discussed reading source timecode from Quicktimes imported from Final Cut Pro captures in After Effects. Seems like a perfectly reasonable request, there could be a bunch of situations where this information would be useful in an After Effects project. Problem is, it doesn’t seem really easy to grab that data. When you view the timecode track in the imported quicktime, the timecode is in reference to the source Quicktime not the source tape from the capture.

Correction

Mark Burton posted on the thread mentioned above that actually the timecode is written to the Quicktime. He offered a link to Sebsky Tools as an example of an app using that info. I simply misread the Quicktime player info. There is still useful info from Final Cut we can access and I think the ideas in this article are interesting so I’m leaving it up with this correction. Thanks Mark.

At least until Apple decides to put that information into the captured Quicktime We’ll need to find a workaround way to read FCP info and that’s what I’m going to cover in this post.

In approaching this problem the first order of business is to figure out what information we do have access to. We know we can use the file attribute of footage item via extendscript to grab the path of the selected footage in After Effects. We know we have access to the original capture information via FCP-XML. We also know we have access to external applications in After Effects via system.callSytem().

At first glance, what are we missing? We don’t really know which FCP-XML file has the source information and we have to figure out how to get that information into a usable form back into After Effects.

Let’s tackle the FCP-XML part first. In my last post I had a bit of teaser info about metadata via spotlight in OSX10.4(Tiger). I’ve had some problems with Spotlight, mostly related to the bizarre behavior of the GUI find command and indexing that happens at inopportune times, but the more I research it I think the benefits will eventually outweigh the negatives as the technology is tweaked and enhanced.

What exactly does Spotlight do? For our purposes, Spotlight works on a couple of different levels. It gives us access to metadata keywords and it indexes our content. In my teaser, I used:

mdfind 'kMDItemKind == "QuickTime Movie"'

The kMDItemKind is an example of a metadata keyword. In this case this is a keyword Apple has set aside as a “common metadata attribute key”. This means that Apple has reserved some metadata keywords that all application developers should use because they are common enough that some consistency is useful. Application developers will also develop their own dictionaries of keywords for their particular application.

In addition, an indexing process grabs the content of your files based on an importer tailored to the individual application. What is unclear is how the balance of keywords and indexing will play out. If you play with the mdls command line it is clear that the keyword store is much smaller than the matching indexed content which appears to be just a really large string. I’ll be reporting back with more research as I learn more.
I’ll go into more detail about metadata in future posts, but if you want to do your own research in the meantime, John Siracusa has a pretty definitive article at arstechnica.

So great, we’ll just grab the Final Cut Pro metadata importer and we’re on our way. uh, umm, well…there isn’t a FCP importer at this point. I’m sure we’ll see one soon enough, but in the meantime there are some workarounds. If we feed a file to mdimport -d1 -f on the command line we find out some interesting stuff. mdimport is the command line spotlight indexer. The -d1 flag tells it to output the type and which mdimporter is being used and the -f flag forces that file to be updated no matter what indexing rules are set.

Which importer is used is based on something called “Uniform Type Identifiers” . UTI’s, despite their unfortunate name, are really an advance in how files are handled. It’s like a file extension, but much more. While we’re waiting for the FCP importer we’re going to use an xml importer for our mdimport. The one I’m working with right now is here. It’s from a Wiley book called Hacking Mac OSX Tiger. (note)The one caveat if you build this yourself is to make sure you do a development style build in Xcode, not a deployment style build. There are some broken dependencies in the deployment style.

We build the mdimporter above, move it to /Library/Spotlight, run our mdimport -d1 -f on a test FCP-XML file and search with mdfind /path/to/our/file | grep xml and…wow. It worked.

We could then run something like:

var selectedItems = app.project.selection;
var selectedFootage = new Array();

for (var i = 0; i < selectedItems.length; i++){
if (selectedItems[i].typeName == "Footage"){
selectedFootage[selectedFootage.length] = selectedItems[i];
}
}
for(var x= 0; x < selectedFootage.length; x++){
var file = String(selectedFootage[x].file);
var osString = "mdfind '" +  file +  "' | grep xml";

var xml = system.callSystem(osString);
var osString = "./qtFileInfo -x " + xml + " -f " + file;
var timecodeRef = system.callSystem(osString);

return timeCodeRef;
}

from After Effects. where qtFileInfo had an Xquery like so:

for  $i in //clipitem/file   where contains($i/pathurl, $file)
return $i

This would match all of the node for the captured clip, including the source tape time code. My initial experiments have been very promising. I'm putting this out there as a sort of "sanity check" to see if I've missed anything. Off the top of my head, I can see us matching on multiple xml files, duplicating file paths, etc. but I think these things could be sorted out. It would be much like guess 3:2 pulldown, you occasionally miss your guess, but your right enough to be useful. We'll also need to develop an indexing workflow. I'm thinking a launchd chron job with smart folders or perhaps an automator set up.
I'm not putting up any files until I've done a bit more research, figured out a useful gui and gotten some feedback on gotchas, but I thought i'd put this out there to document the thought process I'm going through. Hope you find it useful.


6 Comments

  1. […] When we were last talking about reading timecode from FCP sourced Quicktime’s I followed a tangent into Spotlight and other OS X technologies. Well, recently I revisited this problem for another project I’m working on and I think I’ve got a working solution for reading embedded timecode in After Effects on OS X. […]

  2. Gerrit Van Woudenberg said

    This seems really important. The functionality would make our lives SO much easier.

    Please, if you work this out, post some files. I’ll be forever in your debt.

    Keep it up!

  3. Dale said

    Hey Gerrit,

    check out reading quicktime timecode in after effects redux a solution where I offer a working solution to the above.

    best,

    Dale

  4. ben prisk said

    What the heck are you talking about!?
    (kidding) Just saying hey!!

  5. Dale said

    Hey Ben!

    Thanks for stopping by, how’s the time off going?

    Dale

  6. Nick said

    I WANT THIS! I’m not a developer, so I’ll help test you software if you make an end-user gui. I’d also like to see a log output for producers and assistants with source timecode, composite info, maybe keyframes like a readable xml. I’m going to experiment with your post but I’ll donate if you make this real.

RSS feed for comments on this post

Comments are closed.