If you saw a cryptic headlong for this post – the first line above – I apologize.  I have my Twitter account set to post to the blog when I post “new”, that is not a reply to someone. Even then I catch the tweet when it posts, tidy the headline and expand the post with a little commentary.

The context was we were discussing mastering codecs and which one gave the most flexibility, highest quality and best cross platform performance.  All three of the discussed codecs – Cineform, DNxHD and ProRes – are similar in quality. One will have strengths over the other in one instance, but ProRes has the disadvantage of very limited encoders on the Windows side of the production spectrum, while the other two have readily distributable codecs for encoding and decoding on both platforms.

If there was a readily available Windows encoder for ProRes, then that would sit with Cineform and DNxHD for cross platform mastering codecs.

In this episode Terence and Philip discuss the different approaches to updating their NLEs to 64bit modern architectures, with a particular emphasis on Media Composer 6, Avid’s just-released 64 bit update to the venerable Media Composer.

I figured you could answer this question, one which has been knawing on me since I first saw the beta of MC6.0.  How is it possible that Apple, and Adobe had to rewrite their apps virtually from scratch in order to switch to 64 bit, but Avid didn’t?  Is MC6.0 really 64 bit?

It’s a really good question. When an application needs to move from 32 bit to 64 bit, there are many approaches, but one thing is certain: all the code has to be 64 bit, including any dependencies or plug-ins. By dependencies I mean where the application relies on OS frameworks or libraries, such as QuickTime or AVI or other OS level service.  All these must be 64 bit or the application can’t compile to 64 bit. So all three companies had some rewriting to do, but because of their histories it’s actually different for each app.

Even though Premiere Pro is the most modern app of the three (Premiere Pro, Media Composer and Final Cut Pro) having been completely rewritten ahead of the 2003 release, it still largely depended on AVI (Windows) and QuickTime (OS X) for media handling. Neither have been adequately rewritten for 64 bit: AVI because all development stopped in 1996 (the zombie format that will not die) and QuickTime because Apple decided to transition to AVFoundation for media handling in applications, after attempting a partial rewrite of QuickTime as QTKit in 64 bit.

So, Adobe decided to write their own media engine so they could go to 64 bit without the external dependencies. (Premiere Pro still imports and plays QuickTime media by use of a complex workaround.) Most of Adobe’s code is C or similar with only an OS level wrapper around the cross platform code. So it’s “true” Cocoa on OS X because the interface is a heavily subclassed Cocoa frameworks (subclassed to make it look like an Adobe app, in the same way many Cocoa frameworks are subclassed in FCP X for its unique look).

Avid also decided to rewrite all their code from scratch, but instead of one big hit, they have been progressively rewriting their code for the last  three or four releases, if not longer.  You can write the code and have it compile into a 32 bit application (MC before 6) and then when you have all the app ready in 64 bit, you recompile it into 64 bit. Avid did not need to radically change the application, although there are two very major changes from the original code base. Avid Media Architecture was Avid’s approach to the multiplicity of non-tape sources, and it was all new code ready to recompile to 64 bit when the main application did. Avid also appear to have changed their approach to hardware interfaces with Media Composer 6, integrating a hardware abstraction layer so that third parties can integrate with Media Composer without needing to make any changes to Media Composer code. (Previously the Media Composer code needed to be rewritten to talk to each piece of changed hardware.

Apple had to rewrite because their media engine – QuickTime – was only partially rewritten to 64 bit and was lacking most of what the Pro Apps team needed for a modern video application. The solution to the media engine was AVFoundation originally created as the media frameworks for iOS and ported back to OS X with 10.6.7 and Lion,  which is why FCP X requires 10.6.7 or later.

Adobe relies on its own proprietary media engine. Avid relies on its proprietary media engine.  Final Cut Pro  X relies on AVFoundation, which only exists on OS X and iOS and is very, very new to code to0. (This was the likely reason that broadcast video out was delayed, because they had to wait for AVFoundation to be finished before BMD, AJA etc could even start work on drivers no longer based on QuickTime.)

All are really 64 bit, but they’ve taken different paths to get there, as they had different needs.

By itself, XML tells you nothing. It is a generic term that tells you as much about the content as having a “Text” document tells you about the content. As I wrote four years ago for KenStone.net XML stands for eXtensible Markup Language.  You may be familiar with another markup language: HTML, or HyperText Markup Language.  In HTML only the WC3 consortium can add new tags because it is not extensible. On the other hand XML is “extensible”, meaning  anyone can extend it to mean whatever they want it to mean.

And that’s true for every type of XML.  In the case of XML for editing applications, the XML represents the underlying data structures from the application. So, we have:

• Final Cut Pro 7 XML known as xmeml
• Final Cut Pro X XML known as fcpxml
• Motion Project XML files are ozxmlscene
• Premiere Pro file is XML in the PremiereData format.

Each one is XML, and there is zero compatibility between them.  The design of data in an XML file is called a “schema” and every variation of XML is a different schema. More on schema at Wikipedia. The best way to think of the generic thing that is XML is that it is like an alphabet: one that can display French, English, German, Spanish and a whole bunch of other languages that use that alphabet.

So the first takeaway is that every format of XML is different and incompatible. So we need to stop thinking of “XML” as having any more meaning than saying “QuickTime” without specifying the codec(s): neither has any useful meaning without the further detail.

So that brings us to the specifics of translating xmeml to fcpxml (FCP 7 to X respectively) or going from fcpxml to xmeml.  Jon Chappell did a great job of explaining the differences in his blog post, but the important point is that the XML must relate to the data structures that it is trying to represent.

So when we come to going from Final Cut Pro X to FCP 7 we are immediately struck with the fact that FCP X has Events (media) and Projects (timelines), each with its own XML file, while FCP 7 puts them all together in one XML file. Because FCP X and FCP 7 are so different it will be impossible to ever do a truly perfect translation, just as all other inter-NLE transfers lack full fidelity. Import FCP 7 XML to Premiere Pro and say goodbye to most of you metadata (all Master Comments are lost, in fact all but scene, shot, take and description are lost). Also say goodbye to all your tiles and expect only imperfect mapping of filters and transitions.

And that is between applications that are fundamentally the same (having both come, originally, from the mind of Randy Ubillos). Final Cut Pro 7 and Final Cut Pro X  are fundamentally different in ways both visible and not.

FCP 7 counts all time measures in frames; FCP X counts time as rational seconds.

FCP 7 rounds frame rates to 3 decimal places; FCP X uses rational time so frame rates will be accurate, not approximate.

FCP 7 has tracks with time down the track as the only deliminator: FCP works with relationships between connected clips and story lines.

FCP 7 Title are a mix of FXscript and proprietary Boris Calligraphy formats (hidden in the metadata); FCP X titles are Motion 5 templates with rigs published to FCP X.

FCP 7 uses bins for media organization (and subclips); FCP X works with metadata (keywords) for media organization.

The way the media file information is stored in the XML is very different.

There is no common dictionary between the two versions of XML. There’s much more difference than say between English and Spanish, in the vocabulary.

The entire structure of the XML is much simpler and, at first blush fcpxml seems to miss a lot of necessary information, which isn’t really needed.

And so on. This is just a quick list of the differences off the top of my head. Translating is difficult!

We had a lot of difficulty translating fcpxml to xmeml – trust me, Project X₂7 was not created in the two days from FCP X 10.0.1′s release to the announcement Wednesday night.  And we’ve got the easy conversion. Going from FCP 7 to FCP X seems to be much more difficult. For example, all FCP X title text is visible in plain text, so we can insert that to an Outline Text Generator in FCP 7. Not so anything in FCP 7 that uses Title 3D, Vector, Crawl or Random. They are hidden in the xmeml XML as a “private data block” only Boris knows. So any of those titles cannot give you more than what Premiere Pro conversion does: there’s a title there but we have no idea what was in it.

Effect filters cannot be translated either way because the effect architectures are just so different. FCP 7 applies filters directly to clips; FCP X’s filters are applied in Motion templates and published to FCP X. There’s no way to reproduce that in a translation.

Another way of thinking about why translation might be difficult is when translating between two languages where the culture is very different. I recall, during the year I spent in Japan as an exchange student, trying to make a pun in Japanese. This fell completely flat because the pictographic basis to their language makes the concept of a pun impossible.*

Similarly, the very difference between the “culture” that is FCP 7 and the “culture” that is FCP X means that there are untranslatable bits.

Going from Final Cut Pro X to Final Cut Pro 7 has been a total pain and we’re still only at about a 65% fidelity, by which I mean we bring in the basic edit, including connected clips, markers, todos, etc. Going the other way should be even more problematic and I wish whoever’s working on it “good luck” because they’ll need it.

* I am told that a pun in Japanese is not impossible. Apparently my language skills never got good enough, or it was just a really bad pun!

Until that point we’d only done black and white printing, and it’s easy to proof what you’re going to get on a B&W laser printer. Not so with color. Color output wasn’t as common then as it is now and we didn’t get the first Kinkos until very late in the 1990′s, so we really only had one choice for our runs of 2-3 covers for each job.

This became a serious problem when – while developing a food product for my parent’s company during the period I managed it (in addition to my own two companies) – we needed a very specific purple on mockup packaging we were presenting to food buyers at the national department store chains in Australia. Cadbury – Australia’s biggest chocolate company – have always used a specific purple in their packaging, and had just spent several million dollars on a campaign that heavily featured this purple. Since the new product was a chocolate variation on a traditional English Christmas Pudding, having the purple match was beyond important. And we got blue-purple, and red-purple: seemingly every color except the one we wanted.

The Chocolate "Blast of Mouthwatering Bliss" had to match Cadbury purple.

The problem was, what we saw on the screen and what they printed were two entirely different images. Just like that, the print industry’s color management problems were now my color management problems. There’s nothing like first hand knowledge of the problem to appreciate the cure!

By early 1998 we were full on into publishing, with the release in February 98 of the Media 100 Editor’s Companion. By this time we had  learnt – although that particular output bureau never did – the joys and benefits of ColorSync. While the interior was done with xerography (i.e. photocopying) the color covers were done in Sydney by a direct-to-plate digital offset and we never ever had color accuracy problems with an output bureau that used ColorSync.

Every printed cover looked the same, and the same as it did on the computer screen when it was desgined.

ColorSync was the solution the print industry needed to deal with color consistency and matching. The challenge is quite significant when you consider that each device treats color slightly differently: they have different “color profiles” in ColorSync Profiles. What ColorSync facilitates is a color accurate workflow, also referred to as a color managed workflow.

The challenge in print is to ensure that a scanned image reproduces with correct colors on an RGB display and prints consistently on a wide range of types of printers (and size of output) in CMYK color. On computers the images are additive (three light sources) while on paper they are subtractive.  If you worked hard you couldn’t create a less consistent workflow.

And yet, for the last 15 years or so, this has not been a problem. Colors in Photoshop, Illustrator, InDesign, Quark, etc. are accurately reproduced in the final output despite the different color models, device variations, display variations, differing types of paper and even ink variations. This has been possible because of ColorSync, largely developed by Adobe and Apple but now supported on every platform and by all manufacturers of scanning or printing hardware.

What is ColorSync?

This I knew when I wrote recently on how ColorSync might be used as part of Final Cut Pro X’s color management, but from the comments it quickly became obvious that I was very uncertain about:

• How does ColorSync work with video files, and specifically
• How does Final Cut Pro X use ColorSync to accurately monitor color.

So I took it upon myself to start researching the topic. I very quickly discovered that, while there is a lot of information regarding ColorSync and printing workflows, there was really nothing about ColorSync and video short of an OS 9 era article on ColorSync and QuickTime, noting that we can add ColorSync profiles to QuickTime movies using Terran Interactive’s Media Cleaner Pro! (That really dates it. Neither company nor product still exist.)

I took the opportunity to ask my contacts at Apple some specific questions about how ColorSync works in Final Cut Pro X and then synthesized that with the best information I could about ColorSync in general to research what I found. What was also interesting is that, while ColorSync has been mentioned in the PR materials and demos, there has been no explanation as to how that facilitates accurate color. This is my attempt to redress that lack.

ColorSync is built on ICC profiles and the two  terms are interchangeable: an ICC profile managed workflow is a ColorSync managed workflow. Each device – scanner, printer, camera, monitor – has at least one ICC profile. In an oversimplified explanation the ICC profile tells ColorSync (or equivalent engine in Adobe’s applications) how this device’s color representation differs from the standard. In this case it’s the XYZ Profile Connection Space: a colorspace with a very wide gamut.

So, for a given scanner the ICC profile is used to create an accurate representation of the scanner’s result into the Public Connection Space (PCS from here on) and the display’s ICC profile tells ColorSync how to accurately display that PCS on that specific monitor for most accurate fidelity to the original image content data.

In simple terms each device tells ColorSync how that device’s files relate to the PCS either to convert to the PCS or convert from the PCS to a display or printer. This way, each display or printed copy is color accurate to the original file, despite variations in printers or displays.

Source to PCS to destination. From Apple's 2003 ColorSync in Mac OS X document.

Workflows that correctly follow this practice are known as Color Managed workflows.  (Check and see if you’re reading this in a color managed browser.) From that page:

This is happening BECAUSE your color-managed browser is reading each file’s embedded profile and Converting or Mapping them to your monitor profile for a theoretical display of True Color.

In practice, while you may have to set up Photoshop or some other tools, for the most part, like the color management in Safari demonstrated from the link above, it just happens. You’ll find scanners and printers install ColorSync (ICC) profiles for all the functions – a scanner/printer will have a scan-to-PCS profile, and a PCS-to-printer profile – and OS X uses them.  Earlier versions of the OS required some setup but recent (10.5 onward at least) have implemented ColorSync so it “just happens”. As long as each device has a profile, and files are tagged with the appropriate source ICC profile, color accuracy along the entire process is assured.

Color consistency in the video world

Meanwhile, it was easy to monitor video: use a calibrated video monitor. Connect output of your edit system to said calibrated monitor. If you were very particular about your video signal you connected Waveform and Vectorscope to the output as well, so you could really see what’s going on in the signal.

The accuracy of the color entirely depended on how good a monitor you put on the end of the chain. Now in a perfect world this would be a broadcast level monitor, calibrated at least once a year, that could be relied on. I confess, I never had one, even though I delivered a decent number of TV Commercials for national TV broadcast, and other content that went to air. The majority of my editing career, however, has been for non-broadcast purposes.

Even today, I support systems that do work for major studios and none of them have a broadcast grade monitor, let alone calibrate it. One system is finishing HD footage to a 10+ year old SD TV set of no particular brand. Another restoring historic footage works primarily with a decent (but domestic) Plasma display that’s distinctly off axis from the editing position.

I’ve set up movie edit stations that have monitored on a Cinema Display via an AJA SDI to DVI adapter (with CLUT); or to an LCD TV. In fact that device is doing in hardware exactly what ColorSync is doing in software. Now these movies were not graded on this system, just for editing so that’s probably fair. Another client working on a TV series  for Cable Networks, has only a broadcast monitor (JVC 24U) in the grading room; the other four bays all work with consumer LCD or Plasma.

JVC-DT-V24L is a low priced broadcast spec monitor.

Color fidelity required that the NLE made no unintentional changes to the signal coming in and ultimately the accuracy of color depended entirely on how accurately the specific display represented the colorspace it was attempting to represent. In SD that would normally be Rec. 601 and for HD normally Rec 709.

It’s up to the NLE software to convert colorspace from the different source profiles it encounters: not only Rec 601 and 709 in video files but sRGB or any of another dozen possible profiles for still images.

This type of monitoring – a conventional video output – allowed monitoring in the destination colorspace, but appears to be not part of Final Cut Pro X’s design, at least according to Matrox. So, how does Final Cut Pro X ensure color consistency? Of course, ColorSync.

ColorSync was implemented in QuickTime. Badly. Final Cut Pro 7 did not support it, instead working with it own color conversion/matching technology.

Final Cut Pro X and ColorSync

As I’ve discussed the important considerations for ColorSync are:

• The colorspace, which can be considered to be the equivalent of an ICC profile, must be known and accurate for the file (taking the place of the source device profiles in print workflows);
• The rendering engine must use ColorSync to convert from source to destination colorspace/profile;  and
• The frames must be converted for the desired output, be it a Cinema Display, SD 601 or HD 709 result.

This is exactly what Final Cut Pro X does.

As files are ingested, Final Cut Pro X will read any ColorSync information if the files are tagged with information about their colorspace. If it’s a QuickTime file that contains an explicit tag for color information, that is respected by Final Cut Pro X, Motion 5 and Compressor 4.

If there’s not an explicit tag, then Final Cut Pro X infers the colorspace from known information. For example DV files automatically imply either an NTSC Rec 601 colorspace or a 1280 x 720 or 1920 x 1080 file will be tagged as being HD Rec 709 colorspace. These are quite reasonable assumptions and yet another use of Inferred metadata in the Final Cut Pro X world. Beyond those examples, Final Cut Pro X will simply make an intelligent guess based on whatever information is available. Fortunately, image size and aspect ratio are very strong clues to how the source color should be interpreted (the purpose of tagging it). 720 x 576 pixel files are almost certainly PAL SD files and so Rec 601 PAL is reasonably inferred.

Generally it’s older files that have no useful information and require inferring colorspace, but since there really are so few colorspace choices for video, compared with print where each device has its own characteristics, the source ColorSync information is likely to be highly accurate.

I’m sure someone will take me to task on the fact that Rec 601 doesn’t fully describe the color profile because there is no primaries defined, but Final Cut Pro X uses other information in the file to determine which of the well know primaries should be associated with the file.

So we have source color profile information associated with the files. Now it’s up to Final Cut Pro X to ensure that the rendering is accurate.

For Final Cut Pro X and Motion Apple created a shared render engine, touted as the “Linear Light Engine” at the NAB Supermeet Preview but that branding seems to have been dropped ahead of release. This shared render engine uses ColorSync to conform an image from one colorspace to another. ColorSync creates the steps that are required for a specific transform and then assembles them into a series of GPU operations into the GPU processing pipeline. Or in simpler terms, it manages the transforms so the source image content is accurately represented into the processing space.

There is no assumption about the input colorspace at render time. ColorSync profiles were derived or inferred on ingest or come from the image file. Most processing uses the Rec 709 primaries with a linear (1.0) gamma, ready for the final stage.

The third point above, is that the render engine has to accurately prepare that processing space for the appropriate output. If outputting to a Cinema Display, then the render engine conforms the processing space so that the visual appearance on the Cinema Display will look like the image should be viewed. (This works well with the recommended gamma and color temperature for the display: 2.2 and 65oo K respectively.) For the most accurate results you’ll want to create a ColorSync profile for the specific monitor rather than using the supplied “generic for this type of monitor” profile that ships. You can use the ColorSync Utility for that, or a tool that reads values off the screen to generate the profile.

If you’re working with an HD Rec 701 file but request an output for DVD, then the 701 frames (and other graphics from their colorspace) are converted and output so they are correct for the Rec 601 colorspace of a DVD.

So Final Cut Pro X determines the colorspace (ICC Profile) of the source on ingest; manages color using ColorSync through the rendering engine and then uses ColorSync to make sure that the representation on the display – whatever type of display – is also an accurate representation.

Meaning, there is no need for an external broadcast monitor in the classic sense. What you see on a monitor that has a ColorSync profile, is an accurate representation on that monitor of the source colors displayed on a Rec 709 monitor. And you don’t have to do a thing to get the goodness!

Not convinced? Well, coincidentally the Academy of Motion Picture Arts and Sciences’s “ACES or Academy Color Encoding Specification” initiative is planning something almost identical to ColorSync, but specific to the needs of motion picture post production, particularly with so much digital manipulation and inclusion of digital elements. (Look for the heading “ACES: Academy Color Encoding Specification”).

Beyond Rec 709

While the ACES initiative is largely about colorspaces used in digital cinema, it should be pointed out that a “broadcast video monitor” would be no help for colorspaces other than Rec 709 (for HD). So if you want to work with, DCI-P3, also SMPTE-431-2, for example in a traditional NLE you’d be stuck previewing in the wrong colorspace.

With a color managed/ColorSync workflow, if you have DCI-P3 media, and the appropriate source ColorSync/ICC Profile (or colorspace definition,) then ColorSync in Final Cut Pro X would present an accurate representation of that source on the computer monitor.

Mixing any of these colorspaces into any one, and then outputting the appropriate colorspace becomes no problem when using ColorSync.

Conclusion

While it’s a significant change from traditional workflows, the approach taken by Apple with Final Cut Pro X is a better fit for what happens in edit bays outside the big studios, where the problem with early Final Cut Pro users wasn’t that they weren’t monitoring on calibrated broadcast monitors but that they were monitoring only on the computer display. How many times did I, and the other Final Cut Pro 1 pioneers have to remind people that the computer display is not an accurate representation of the video!

Well, 2.2 gamma on OS X (since Snow Leopard) and ColorSync have made that advice not only null and void, but downright wrong. With a ColorSync workflow, the view on the computer monitor, particularly in full screen mode, will be more accurate than using a consumer television as a display, with the sole exception of interlaced video output. If you’re delivering for web, for LCD or plasma screen (i.e. all currently available displays) the display is progressive. Produce and edit accordingly.

I don’t think we have broadcast video output from Final Cut Pro X, because we have something better that accommodates todays colorspaces and will expand to accommodate whatever the future holds as well.

A disclaimer. I do not have the equipment available to test this: I don’t have a broadcast monitor nor a system that could output to it via SDI or even analog. (I could do DV via Firewire, but really….) I am confident that the solution that solved my inconsistent print color issues is robust enough, with the right software design, to manage my consistent video image needs.

The purpose of monitoring video on a broadcast monitor is to ensure that we have consistent color accuracy from a known reference. The value of a ColorSync workflow is that we ensure that we have consistent color accuracy wherever its shown. It’s a superior choice that avoids the limitations and expense of the previous “standard workflow.” Instead of having to build in a single colorspace on a monitor, Rec 601 or 709 style, with ColorSync all wide gamut monitors can be calibrated (ideally with a colorimeter and on that specific monitor) and used as reference monitors.

As it turns out, Final Cut Pro 2 was released early the next morning, so the first thing I had to do in that second day of class was tell my students that what we had learned the day before was no longer relevant for version 2 because the software had become smarter, and that made it easier for people to use Final Cut Pro and no doubt contributed to its success.

There is an inevitable trend with technology (at least) that starts with something being difficult: it requires a specialist operator with scarce craft skills. Think about how challenging a Model T Ford would have been compared to a modern motor vehicle. To drive a car – even as late as when I was growing up in the 50′s – you really needed to have some pretty good mechanic skills as well. Cars still had crank slots in my youth in Australia! A driver really should have known something about timing, cleaning spark plugs, tightening (or replacing) fan belts and more. Not to forget the joy of manual chokes and manual gearboxes.

Zip forward a few years and we have the modern motor vehicle, which in most cases not only does not need the amateur mechanic to constantly fiddle, they make them almost impossible. But I don’t hear the massively enlarged group of drivers complaining about how operating a car has become “dumbed down”. I’ve certainly heard drivers who enjoyed tinkering complain, but not the average user/driver.

Configuring my first Media 100 system required skills I did not have: they were embedded in the reseller who knew the magic combination of drivers that worked, because there were conflicts and the setups were “fragile”. Enter Final Cut Pro and DV and, if you worked within those limits, there were many fewer conflicts – it mostly “just worked”. These days we add storage and hardware cards to our computers that “just works” with little chance of failure (most of the time). I distinctly remember that the VARs were not happy selling Final Cut Pro because it required a lot less involvement from the VAR: there wasn’t the value needing to be added by a Value Added Reseller! (Now there are still complex systems that require the input from experts to choose and configure, but for stand alone systems most people don’t need the VAR.)

The software and computers have become smart enough that the (then essential) role of the expert is needed much less.

Cars get smarter and require fewer “craft skills” from drivers; computers have grown up and require fewer interventions from experts, and most people consider these good things. People who aren’t mechanics or VARs I guess (which describes most of us).

So it puzzles me when one of the common criticisms of Final Cut Pro X is that it “dumbs down” the need for specialist knowledge or craft skills. It does this by making the software smarter and less prone to “user error” with mixed frame rates, frame sizes and Sequence settings. I’m sure there are skilled editors who pride themselves on managing all this without realizing it’s all workarounds! We are just more comfortable with the workarounds we know and use, than with new workarounds.

If you follow that thought, Media Composer has always been more “dumbed down” than Final Cut Pro! My cohort in The Terence and Philip Show and Lead Dog at Alpha Dogs once said that Final Cut Pro should only be used by skilled professionals because it is so flexible it lets you get yourself into trouble, whereas Media Composer wouldn’t let you get into trouble by (for the longest time) supporting only their own media format, forcibly managing media in its own way and keeping track of every Timecode reference the media walked past! He has a point.

So, Final Cut Pro X does what every technology does: moves from the realm of the specialist, skilled crafstperson out into the wider group of people who need smarter tools that won’t let them get into trouble. A skilled mechanic bemoans the fact that they can’t tinker with modern cars, and race-car drivers have very different needs than the average driver, there are those who need a fine-tuned vehicle, the general purpose vehicle that requires no knowledge of how the engine works in order to drive for pleasure or in fact to drive for a living. No special skills or knowledge needed. We’re not *there* yet with video editing but we’re heading there.

For those who want to tinker, or need a race car, the smarter “dumbing down” software is a threat or at best as useless as a Smart Car on a race track. But for everyone else – the vast majority of drivers – the dumbed down modern car is a big improvement.

This is simply part of a much larger trend: video production as a form of literacy, the use of templates or presets (the subject of the next Terence and Philip Show), cameras that are more sensitive and need less lighting (or none for No Reservations who no longer light thanks to the sensitivity of their Sony PM2-F3s) and decent quality production is accessible and affordable to many more people. Exactly as every technology in history has done, and every technology in the future will do.

There are many more ways that our tools will become automated. And like the trend in automobiles those who want to get in under the hood and tinker – or feel they need that level of control of their vehicle – will be disappointed, frustrated and annoyed, just as we’ve seen with some people’s responses to the “dumbing down” (by making it smarter) of editing in Final Cut Pro X. Apple may have been relatively late to the metadata party (Avid and Adobe being way ahead for many years in flexible metadata handling) but one way Apple have gone beyond the others is in the use of Inferred Metadata.

As well as the work-in-progess inferred shot type (inferred from the analysis of the size and position of faces, itself Derived Metadata) I have discovered that they use a lot of Inferred metadata in the ColorSync workflow. (A comprehensive article on the use of ColorSync in Final Cut Pro X is coming, but it’s a lot of research even with help from Apple.)

There will, of course, be those who need to see every frame, to “touch” the media and to use the tools that give them the control they need, and there are great choices for them. Thanks to the dumbing down of the skillset needed by making the software smarter more people can reach their creative goals. And I think that’s a good thing.

9-5 September 20 Basic Tech for Producers (and recent Film School Graduates)

In this session, technology expert and DV magazine contributor Philip Hodgetts will cover the technological choices in production and post in a non-geeky way to help producers — and others without a technical background — make good technology choices for their productions. From formats to software choices; selecting cameras to creating Web video; designing graphics that will work and much more.  PRICE: $195 ($245 after Aug 31) Click here to register now.

9-5 September 21 Using Metadata For Production and Asset Management

Metadata is becoming increasingly important throughout the production cycle–from camera to asset management. In this session learn about the types of metadata in use; how each major NLE (Final Cut Pro 7, Final Cut Pro X, Premiere Pro CS 5.5 and Media Composer 5.5) handles metadata and how we can use that metadata to speed postproduction and VFX. Once post is done, assets need to be management through through distribution and repurposing. What tools are available, how are they used and how do they fit into the metadata structures promoted by SMPTE and other standards bodies.  PRICE: $195 ($245 after Aug 31) Click here to register now.

9-5 September 22 Avoiding Postproduction Nightmares

Post expert and DV magazine contributor Philip Hodgetts details the most common (and costly) problems inadvertently created during production that will be “fixed in post.” From color correction to audio, and editing to the final QC pass on deliverables, he’ll not only reveal the tricks of the trade that he’d use to save your production, but also explain how you can avoid these costly issues in the first place. PRICE: $195 ($245 after Aug 31) | Click here to register now.

In the light of full disclosure, I certainly expect to be paid but I always deliver good value. There will be some overlap between the Basic Tech and Avoiding Postproduction Nightmares sessions as they both seek to make the technology understandable, but with a different focus to each day’s class.

Growing up in Australia in the 1960′s thru to 90′s on Saturday afternoon the average Sydneysider – the biggest city in Australia – could choose from five networks: 3 commercial (7, 9 and 10) and two Government – ABC (think PBS but Govt funded) and SBS (for multicultural entertainment). Typically two of the commercial networks and both ABC and SBS would have some sort of sport. (Soccer on SBS was very “multicultural” at the time!)

The ratings winner was the 10 network because they programmed something that wasn’t sport! Although sports were, and are, very popular, the aggregate non-sport market was bigger!

Although Media Composer wasn’t the first non-linear editing software, it was the first to capture the popular imagination of the industry. It’s interface was very comfortable for editors familiar with both Moviola and tape-based offline editing. That was probably exactly the right thing to do at the time.

At the time.

At that time, there were very few professional editors. Those working tended to be involved in the production of Motion Pictures (for big companies), Episodic Television, lessor Television and the beginnings of the Cable market. There would have been a few working in production houses working on big corporate productions. Overall, a fairly small group of people who had well defined needs for tools. Very common needs in fact, because the outputs were really not that different.

Then in the 1990′s the industry became democratized. Blame DV and Firewire-based NLEs if you want, but the number of people editing video skyrocketed over the next 15 years through to today. The type and variety of video projects has also changed, with distribution options starting with VHS, then DVD and now the Internet, added to any traditional channels. Of course in the US, the Cable business boomed from the mid 90′s, although the bulk of production was now outside the TV and Film worlds.

And yet, in 2011, one of the major NLE developers decides to, finally, give us a choice in interface designs, and that’s a problem?  It will probably prove to be the most brilliant move any NLE developer has ever done. And probably only Apple have the resources and chutzpah to pull it off!

Final Cut Pro X is the first revisit to the NLE interface since Sony Vegas. Sony Vegas, designed by audio rather than video oriented engineers, developed according to what its users and developers thought “made sense”, not the way it had been done since time began. Although it has a very large market (sharing the bottom 32% with Media 100, Premiere Pro and Edius) it’s not Apple nor Avid!

Avid would have extreme difficulty taking even part of its user base on that journey. You only have to view the controversy over the Smart Tool changes implemented in MC 5.0 (and substantially improved/fixed in 5.5 btw) to know that a complete rebuild of the interface would be too much.

Apple had two things going for them. They can, as I said, withstand any market push-back for as long as it takes for the new software to be as fully featured as its predecessor, and for the marketplace to understand the value of the new approach. They also have a range of really good technologies on their operating systems that were just waiting for the right design to come along.

Plus, the time was ripe for there to be another choice. Something other than sport all Saturday afternoon!! A real choice of interface, one they hope will be more suited to a wider range of users than the existing Final Cut Pro design.

And if you still want to “watch sport”, then there’s Premiere Pro (very similar to Final Cut Pro and probably the easiest transition, particularly since you likely already own it because you bought Photoshop, Illustrator and After Effects), or Media Composer (very affordable with the cross-grade promotion going on until mid June!).

I like the idea of choice. Avid have made it clear that they are focused on, and are focussing their tools on, those working in Studio film Broadcast and Cable TV and the professional newsrooms of the TV industry. That’s good market positioning and clearly sets out a Unique Selling Proposition.

Adobe are making the best, faster horse that they can, and I’m sure that will endear them to many soon-to-be former Final Cut Pro 7 users.

Of course, as my friend Oliver Peters has pointed out, Final Cut Pro X competes with Final Cut Pro as well as with NLEs from other companies. Apple are likely to be selling both for a while to come.

I think that Apple’s decision to give us interface choice, to reinvent the NLE for the next generation of editors, preditors and others, is exactly the right move for 2011.  Final Cut Pro’s similarity to other NLEs when it was introduced was similarly exactly the right thing for that time. But not for now.

The thing is that  the rest of the project is HDV, XDCAM, DVCPRO HD, AVC-I, AVCCAM, some SD – so today we add DSLR!

This is not an art project so there’s no big advantage of a “shallow depth of field”. Most of the b-roll is coming from achieve SD video of varying quality, but because it was shot over a long period, without anyone keeping track of formats we end up with this sort of mess. A young and reasonably competent “editor” was on the job but totally unaware of the complications of having every known frame rate and format in the project (except DSLR until today).

Every different format complicates the project and adds additional processing time to bring everything to a common format before starting the edit, including mixing 23.98 and 29.97 frame rates.

And while Premiere Pro and Media Composer (and probably Final Cut Pro X) can deal with all these formats natively, I hope no-one would recommend that as a workflow for a large documentary project. Certainly AMA for Media Composer is a great way to choose selects from the native format and then transcode to DNxHD for the edit.

This is simply madness. Every one of us needs to educate producers and directors that mixing frame rates and formats is going to cost them a lot of money in post production. And then make sure the message communicates by charging what it costs.

Metadata is crucial in today’s ever-changing, competitive post production environment. New, exciting tools continue to emerge. Trying to sort through it all? Join us for a special event in LA onJanuary 27 @ 6:30.

Metadata is becoming increasingly powerful and vital in today’s ever-changing, fact-paced post production environment. Once an afterthought, producers, editors and digital content creators alike are now embracing metadata and implementing it into their workflows. New, exciting tools continue to emerge in the marketplace that make gathering and tracking metadata quicker and more efficient. Having the power to streamline your workflow, and maximize your search capability is an immeasurable asset, and will ultimately save you time, money and headache on your next project.

MediaSilo and Oasis Imagery are proud to present, ‘Metadata Workflow: How to Make Metadata Work for You.’ Join us along with guests from CET Universe, AV3 Software and Intelligent Assistance Inc., as we navigate our way through the importance of metadata and the tools that allow you to take the most advantage of it.

Philip Hodgetts of Intelligent Assistance is an expert and consultant in digital production and post-production workflows, encoding, web applications, digital delivery and technology innovation. He is the President of Intelligent Assistance and has also authored several books.

Doug Hynes of AV3 Software, is a creative media industry veteran, having worked for all of the major software manufacturers, including Avid, Apple and Autodesk. As Director of Products at AV3, Doug provides technical support, account and product management.

Tony Cahill is the chief engineer of CET Universe, a leading provider of services and systems for professional audio and video production. He manages a team of technology specialists that provide design, installation, and service support for integrated workflow solutions.

Erik Freid – Media Silo – has more than 15 years of experience in major markets, working with clients including independent and documentary filmmakers, episodic TV, and studio feature production.  As VP of Product Management at MediaSilo, Erik leads the development and feature set of the MediaSilo platform, as well as designs cost effective workflows for even the most challenging of production needs.

But today I saw some things I really want in the next version of Final Cut Pro. Like scalable waveforms that change color according to their level! Scalable waveforms (as Media Composer already has and I think PPro CS5) has been a feature request for Final Cut Pro as far back as I can remember. And now the technology is there in the Apple technology basket. We’ll take that, thanks.

Trailers – semi-automatic completion of a trailer – and Themes, fit comfortably with my concept of Templatorization: the use of templates to speed up production. I first mentioned the concept in a blog post of April 2005 titled “Can a computer replace an editor?“. It’s still a good read and remember, that was long before we started actually building that future with our First Cuts/Finisher products. Templatorization is already in the Final Cut Studio with Master Templates from Motion used and adapted (with custom images and text) inside Final Cut Pro.

The concept here is similar. We’ll see more Templatorization over time, even if they are custom templates for a project, like custom Master Templates.

Plus, as my friend Rob Birnholz tweeted during the presentation when some were complaining that Templatorization would drive hourly rates down even further:

I can now sell CUSTOM Professional video design! (vs. template based ‘insta-video’)

But the one piece of technology I most want to see in the next version of Final Cut Pro is People Finder because it automates the generation of so much metadata, that combined with Source metadata is going to really open up Assisted Editing to take away a lot of the dull work of finding footage and a story. (And Shane you can hate me now, but more efficient production is always going to be the driver, but we can automate the drudgery, not the creativity.)

By analyzing your video for faces, People Finder identifies the parts with people in them and tells you how many are in each scene. It also finds the close-ups, medium shots, or wide angles so it’s easy to grab video clips as you need them.

We get shot type metadata – CU, M, Wide and we get identification of the number of people in the shot. That’s powerful metadata. I suspect we won’t get it in the next version of Final Cut Pro because they’ve got enough to do and can’t do everything at once, but I’d love to see this level of automated metadata generation. Remember too, that as well as the facial recognition technology already shipping in iPhoto and now iMovie, it was announced back in September that they had purchased another facial recognition company to improve the accuracy.

The holy grail, from my perspective, of facial recognition would be if the software (Final Cut Pro please) recognized all faces in the footage, and grouped the same face together (like Faces in iPhoto). You’d still have to identify the person once, but from there on basic Lower Thirds (person and location) could be automatically generated (location eventually coming from GPS in the camera – we’re not there yet).

It’s a pity Apple don’t have or license speech recognition technology. Licensing Nexidia’s speech search would be ok (it’s what powers Get and ScriptSync) but it doesn’t derive metadata like speech analysis does. Once you have speech as metadata is makes things like prEdit possible; and ultimately the automatic derivation of keywords.

And it seems like my five year old ruminations might have been on to something.

I start work in prEdit shortly – nearly started today, so it looks like Friday now – but already we discovered some ideas that have now been implemented in the 1.1. release.

Along the way I’ve learnt a lot about how well (or not) Adobe’s Speech Analysis works. (Short answer: it can be very, very good, or it can be pretty disappointing.) As prEdit is really designed to be used with transcriptions I also tested the Adobe Story > OnLocation > Premiere method, which always worked.

Well, from that workflow it became obvious that speakers (Interviewer, Subject) were correctly identified so wouldn’t it be nice if prEdit automatically subclipped on speaker changes. And now it does.

If multiple speakers have been identified in a text transcript, prEdit will create a new subclip on import at each change of speaker

It also became obvious as I was planning my workflow that we needed a way to add new material to an existing prEdit project, and to be able to access the work from historic projects to add to a new one.

New Copy Clips… button so you can copy clips from one prEdit project to another open project

Now that I’m dealing with longer interviews than when we tested, I needed search in the Transcript view.

Search popup menu added to Transcript View.

That led to one problem: adding metadata to multiple subclips at a time. Previously I’d advocated adding common metadata to the clip before subclipping in prEdit (by simply adding returns to the transcript) but if it comes in already split into speakers, that wasn’t going to work!

Logging Information and Comments can be added for multiple selected subclips if the field doesn’t already have an entry for any of the selected subclips

Because you never, ever want to run the risk of over-writing work ready done.

And some nice enhancements:

Faster creation of thumbnails

Bugfix for Good checkbox in Story View

prEdit 1.1 is now available. Check for updates from within the App itself. And if you work in documentary, you should have checked it out already.

The only thing Ogg is good for, is being open source, which isn’t relevant to professional media producers.

People who actually work in media don’t mind paying for stuff, and don’t mind not owning/sharing the IP. Video production professionals are so accustomed to standardizing on commercial products, many of them become generic nouns in industry jargon: “chyron” for character generators, “grass valley” for switchers, “teleprompters”, “betacam” tape, etc. Non-free is not a problem here. And if your argument for open-source is “you’re free to fix it if it doesn’t do what you want it to,” the person who has 48 shows a day to produce is going to rightly ask “why would I use something that doesn’t work right on day one?”

The open source community doesn’t get media. Moreover, it doesn’t get that it doesn’t get media. The Ogg codecs placate the true believers, and that’s the extent of their value.

Now, AV Foundation is the iOS media system, so we’re not talking about QuickTime per se but I have to wonder.

QuickTime – the real OS-centric media framework, not the little sub applications that function as players – is transitioning from C APIs (Carbon) to Cocoa via QTKit. Trouble is, QTKit got a lot of work around QuickTime 7′s release, but not so much in recent years. And yet Final Cut Pro needs a lot of what’s not written, before it can release a Cocoa version of Final Cut Pro.

Actually, Apple could do what Adobe have done for Premiere Pro CS5. In rewriting their core media handling engine, Adobe retained QuickTime support by spinning it off into a 32 bit thread, but that’s a complex workaround that does nothing for performance, nothing positive anyway.

When you consider slide 9… Even though it was only introduced in iOS 2.2, extended in iOS 3 and “completed” in iOS 4 (consider the reference framework growth in slides 6, 7 and 8), AV Foundation has 56 Classes and 460 Methods (the more you have of these, the more you can do with it). QTKit has 24 Classes (less than half) and 360 Methods. Compare that with the (very mature) QuickTime for Java with 576 Classes and more than 10,000 Methods. Something tells me that QTKit is not in favor at Apple.

Not that I think QuickTime is going away, at least not as a brand for their media players and the overall technology. I say that because, although the code that’s in iPhone OS shows a simplified player, that was all that was originally released and it shared no “QT Classes or Frameworks”. So, the QuickTime brand is likely to be retained.

If I was extrapolating from this presentation, and I am extrapolating wildly from a small amount of data, I’d guess that the direction within Apple was toward the more modern Classes and Methods of AV Foundation, and that, eventually, AV Foundation, Core Audio, Core Animation and Core Media will replace what we currently have under QuickTime on OS X: Core Audio, Core Video (well, just a subclass of Core Image) and a lot of deprecated (do not use) C APIs.

If you consider slide 14, and the similarity of Classes between QTKit and AV Foundation it makes no sense to build two technologies in the company that were essentially doing the same thing.  Slide 29 shows how similar an AVAsset is to a QTMovie. The other Classes all seem to duplicate functionality that’s in QuickTime now, but in efficient, new, modern code. Capture, editing, playback, media formats… they all seem to be in AV Foundation duplicating work done (or not yet done) in QuickTime’s QTKit.

Importantly Core Media Time is in “n’ths of a second” not “ticks” or “events”. Media based on time will be better for video frame rate uses than one based on ticks or events, which caused the “Long Frames” problems of earlier versions of Final Cut Pro.

In support of my hypothesis I offer slide 42: specific references to AVAssetExportSession.h being available in OS X with 10.7 and likewise CMTime.h has a reference to becoming available in 10.7.

So, I’ll go on a limb and suggest that QuickTime as we’ve known it is somewhat dead; long live a new QuickTime. QuickTime will continue being the branding, but everything “below that” will transition to new architectures essentially ported from iOS to OS X.

This would be a very good thing. A completely new, modern, efficient (you see what it does on the iPhone) underpinning for QuickTime down below that QTKit layer.

Who wouldn’t want to use that in an modern NLE, even if it means waiting for OS X 10.7, which hasn’t been announced yet? It would make it much easier for the Final Cut Pro team to create a much more powerful media engine than it has now; one that really understands time and not events and one that mimics the power of Adobe’s Mercury Engine. Let’s face it, media performance on a 1 GHz A4 chip is in some ways better than the performance on 8 core processors. iMovie for iOS, built on these frameworks (if slide 24 is to be believed) can edit Long GOP H.264, which Final Cut Pro can’t! (And in both cases the H.264 playback is accelerated by hardware: dedicated chips in the iPhone, on the graphics card in OS X.)

As always, conjecture on my part, and this time based solely on what I’ve learnt from the quoted slide show. Chris Adamson does not work for Apple but he does claim expertise in iOS and QuickTime. Other posts on his blog indicate some differences between AV Foundation and QuickTime; and Classes still missing from AV Foundation that are in the current version of QuickTime. That shakes my confidence in the hypothesis a little, but given how little work has been done on QTKit in the last two years, and the need to have the foundations for QuickTime modernized, it still seems like the most likely path Apple will take.

Another data point is that the QuickTime X player was promoted thusly:

Using media technology pioneered in OS X iPhone™, Snow Leopard introduces QuickTime X, which optimizes support for modern audio and video formats resulting in extremely efficient media playback. Snow Leopard also includes Safari® with the fastest implementation of JavaScript ever, increasing performance by 53 percent, making Web 2.0 applications feel more responsive.*

Pioneering the technology under iOS, and then porting it to Mac OS X has happened already.

UPDATE: Chris Adamson, who did the presentation I referred to, clarified many of the points I get wrong or wrongish, including the fact that AV Foundation is not under NDA. His Connecting the Dots post is essential reading if you’ve got this far!

Touchable in the sense that the images react to being touched, poked, distorted etc, by using cameras to determine where hands are. They are not claiming (as far as I can see) that the viewer can “feel the image”

A group working under the guidance of the Entertainment Technology Center at USC is trying to create specifications for an interoperable set of master files and associated metadata. This will help interchange and automate downstream distribution based on metadata carried in the file. The first draft of the specification is now done based on (no surprises) the MXF wrapper. (Not good for FCP fans, as Apple has no native support for MXF, without third party help).

Main new items: dynamic metadata for hinting pan-scan downstream and “Output Profile List”:

“The IMF is the source if you will, and the OPL would be an XML script that would tell a transcoder or any other downstream device how to set up for what an output is on the other side,” Lukk explained.

The intention is to bring this draft spec to SMPTE, but first, ETC@ USC is urging the industry to get involved. “We need industry feedback and input on the work that the group has done thus far,” said ETC CEO and executive director David Wertheimer. “Anyone who has interest in this topic should download the draft specification and provide feedback to the group.”

I’ve had the pleasure of meeting Zak Ray when I travelled to Boston. I like people who have an original take on things and Zak’s approach to picture editing – and his tying it to existing technologies (that may ned improvement) – is an interesting one.

And yet, despite such modern wonders as Avid Media Access and the Mercury Playback Engine, modern NLEs remain fundamentally unchanged from their decades-old origins. You find your clip in a browser, trim it to the desired length, and edit it into a timeline, all with a combination of keys and mouse (or, if you prefer, a pen tablet). But is this process really as physically intuitive as it could be? Is it really an integrable body part in the mind’s eye, allowing the editor to work the way he thinks? Though I can only speak for myself, with my limited years of editing experience, I believe the answer is a resounding “no”. In his now famous lecture-turned-essay In the Blink of an Eye, Walter Murch postulates that in a far-flung future, filmmakers might have the ability to “think” their movies into existence: a “black box” that reads one’s brainwaves and generates the resulting photo-realistic film. I think the science community agrees that such a technology is a long way off. But what untilthen? What I intend to outline here is my thoughts on just that; a delineation of my own ideal picture-editing tools, based on technologies that either currently exist, or are on the drawing board, and which could be implemented in the manner I’d like them to be. Of course, the industry didn’t get from the one-task, one-purpose Moviola to the 2,000 page user manual for Final Cut Pro for no reason. What I’m proposing is not a replacement for these applications as a whole, just the basic cutting process; a chance for the editor to work with the simplicity and natural intuitiveness that film editors once knew, and with the efficiency and potential that modern technology offers.

It’s a good article and a good read. Raises the question though – if Apple (or Adobe/Avid) really innovated the interface would people “hate it” because it was “different”?

We just launched prEdit, our pre-editing tool for developing paper cuts (a.k.a. radio cut) from transcripts. prEdit:

• Lets producers or editors cut transcripts into selects in seconds
• Adds and updates log notes with auto-complete logging fields
• Previews the video for any clip, subclip, paper cut or section of paper cut
• Exports to Excel spreadsheets and Final Cut Pro, or Premiere Pro Sequences

“prEdit marks a new generation of postproduction tools,”  say I. “Video editing by text is a whole new way of working that will take weeks out of developing a paper cut.”

prEdit is available now from AssistedEditing.com and carries an MSRP of $395, discounted for an introductory special to $295 until August 31st. The prEdit workflow is described at http://assistedediting.com/prEdit/workflow.html and a video overview is available at http://assistedediting.com/prEdit. The first 80 seconds provide an overview.

The video is now available at YouTube  http://youtu.be/3fV388QsVVA?a

Most readers will likely be aware of the Transcription ability introduced with CS4 and updated in CS5. Either in Soudbooth, or in Adobe Media Encoder (AME) via Premiere Pro for batches, the technology Adobe builds on from Autonomy will transcribe the spoken word into text. Our initial testing wasn’t that promising, but we’ve realized we weren’t sending it any sort of fair test. With good quality audio the results are pretty good: not perfect but close, depending on the source, of course.

We first explored this early in the year when we built and released Transcriptize, to port that transcription metadata from the Adobe world across to Apple’s. That’s what set us down our current path to the unreleased software, but more of that in a later post.

Now we’re back in that world, it’s a pretty amazing “story”. There’s three ways they get it that I see:

1. Good metadata tracking at the file level
2. Flexible metadata handling
3. Metadata-based workflows built into the CS applications (and beyond).

Balancing that is the serious miss of not showing source metadata from non-tape media that doesn’t fit into pre-defined schema. At least that seems to be the case: I can’t find a Metadata Panel that shows the Source Metadata from P2, AVCCAM/AVCHD, or RED to display. Some of the source metadata is displayed in existing fields, but they are only the fields that Adobe has built into Premiere Pro, which miss a lot of information from the source. For example, none of the exposure metadata from RED footage is displayed, nor Latitude and Longitude from P2 and AVCCAM footage.

That’s the downside. To be fair, Final Cut Pro doesn’t display any of the Source Metadata either (although you can access it via the XML file.)  Media Composer can show all the Source if desired.

Good Metadata Tracking at the file level

Apple added QuickTime Metadata to Final Cut Pro 5.1.2 where they retain and track any Source Metadata from files imported via Log and Transfer. This is a flexible schema but definitely under supported. Adobe’s alternative is XMP metadata. (Both XMP and QuickTime metadata can co-exist in most media file formats.)

XMP metadata is file based, meaning it is stored in, and read from, the file. There are seven built-in categories, plus Speech Analysis, which is XMP metadata stored in the file (for most formats) but considered as a different category in the Premiere Pro CS5 interface. I believe that the Source metadata should show in the XMP category because it is file-based even if its not XMP.

On the other plus side XMP metadata is very flexible. You don’t need third party applications to write to the XMP metadata. Inside Premiere Pro CS5 you simply set up the schema you want and the data is written to the file transparently. If the data is in a file when it’s added to a project, it’s read into the project and immediately accessible.

This metadata travels with the file to any and all projects. This provide a great way of sending custom metadata between applications. Speed Analysis metadata is also carried in the file, so it can be read by any Adobe application (and an upcoming one from us, see intro paragraph) direct from the file.

Flexible Metadata Handling

Not only is the XMP file-based metadata incredibly flexible, but you can also apply any metadata scheme to a clip within a Premiere Pro project, right into Clip metadata. For an example of how this is useful, let’s consider what we had to do in Final Cut Pro for First Cuts. Since Final Cut Pro doesn’t have a flexible metadata format, we had to co-opt Master Comments 1-4 and Comment A to carry our metadata. In Premiere Pro CS5 we could simply create new Clip-based fields for Story Keywords, Name, Place, Event or Theme and B-roll search keywords.

(Unfortunately this level of customization in Premiere Pro CS5 does not extend to Final Cut Pro XML import or export.)

An infinitely flexible metadata scheme for clips and for media files (independently) is exactly what I’d want an application to do.

Metadata-based Workflows in the CS5 Applications

To my chagrin I only recently discovered how deeply metadata-based workflows have become embedded in the Adobe workflow. (Thanks to Jacob Rosenberg’s demonstration at the June Editor’s Lounge for turning me on to this.) Adobe have crafted a great workflow for scripted productions that goes like this:

1. Collaboratively write your script in Adobe Story, or import a script from most formats, including Final Draft. (Story is a web application.)
   • Adobe Story parses the script into Scenes and Shots automatically.
2. Export from Adobe Story to a desktop file that is imported into OnLocation during shooting.
   • In OnLocation you have access to all the clips generated out of the Adobe Story file. Clips can be duplicated for multiple takes.
   • Clips are named after Scene/Shot/Take.
3. During shooting you do not need to have a connection to the camera because some genius at Adobe realized that metadata could solve that problem. All that needs to be done during shooting of any given shot/take is for a time stamp to be marked against the Clip:
   • i.e. this clips was being taken “now”.
   • Marking a time stamp is a simple button press with the clip selected.
4. After footage has been shot, the OnLocation project is “pointed” to the media where it automatically matches the shot with the appropriate media file, based on the time stamp metadata in the media file with the time mark in the OnLocation Clip.
   • The media file is renamed to match the clip. Ready for import to Premiere Pro CS5.

Now here’s the genius part in my opinion (other than using the time stamp to link clips). The script from Adobe Story has been embedded in those OnLocation clips, and is now in the clip. Once Speech Analysis is complete for each clip, the script is laid-up against the analyzed media file so each word is time stamped. The advantage of this workflow over using a guide script directly imported is that the original formatting is used when the script comes via Story.

All that needs to be done is to build the sequence based on the script, with the advantage that every clip is now searchable by word. Almost close to, but not quite, Avid’s ScriptSync based on an entirely different technology (Nexidia).

It’s a great use of script and Speech Analysis and a great use of time-stamp metadata to reduce clip naming, linking and script embedding. A hint of the future of metadata-based workflows.

All we need now, Adobe, is access to all the Source Metadata.