FCP X Reels

[Jeremy Garchow]

[Chris Kenny] “You keep arguing as if my position is that FCP X should refuse to read camera-specific metadata or otherwise support camera-specific formats. That’s not my position at all. Rather, my position is that in addition to supporting camera-specific formats, it should also be able to read standard metadata out of standard container formats — or at least out of QuickTime files, given that this is Apple’s own file format.”

I guess I am seeing this differently. First, this isn’t a personal attack against you, I am just talking about what is ultimately the best way.

What is apparent to me, is that the Quicktime API is going away, or at least it isn’t being used in FCPX. It hasn’t completely disappeared from the OS yet, and there are still many capable things to do with Quicktime. Just look at applications like QT Edit which have been thriving with every new MacOS iteration.

Since FCPX doesn’t work with a Quicktime foundation like FCP Legend, perhaps being able to WRITE in to a Quicktime file isn’t ready yet? As John Heagy says, all the components seem to be there, but perhaps all the dots aren’t connected yet? And what about MXF? If you have P2 MXF files, there’s no reel tab, so how is FCPX going to write to that format? Also, does it need to write to the P2 XML? What about formats that don’t support metadata very well? Does it need to write to those files?

So for now, it’s all handled in metadata in the form of an FCPXML which allows you to completely customize which metadata fields get exported. Some of that metadata will simply be passed through from the camera files if you have a proper importer, some of it will be user generated. Camera manufacturers, or third parties, have the opportunity to best support their systems. They also have the responsibility to keep their importers updated with any changes that might happen. While some people see this as Apple skirting responsibility, I see it as ultimately becoming the most useful and best way to handle the situation.

This brings it back to “standards”. There are no standards, but there’s a ton of useful data out there. If Resolve knows how to reconnect to an Arri Reel ID, or a Red Reel, or a P2 GlobalClipID, what does reel become but a user generated field as it always has been in the days of tape?

I don’t think that FCPX should refuse to read what’s there, but I do think we need to look at the whole picture.

[Chris Kenny] “One of the systems currently in place — and already used by camera systems Alexa — that that reel metadata can be embedded in a standard location in QuickTime files.”

But let’s say you have Arri files that are raw as well as ProRes. What is the metadata that connected those? Shouldn’t Arri write an importer that has the camera specific metadata and fields that will connect those files forever no matter where they are placed?

[Chris Kenny] “User-assgnable reels are useful, but they’re more useful if they can be shared across apps — which they mostly can’t be with FCP X, because unlike FCP 7, when you change reel data in FCP X, it doesn’t change it in the file, meaning that another app reading that file (like, say, Resolve) has no way of associating the reel name in the FCPXML file with that media file.”

I hear you, but there are now ways to get that data in and out of FCPXML, just like that data was available in XMEML of FCP7 and earlier, and there’s a lot more of it. So the data CAN be shared across an app and there’s already a ton of information in every single camera generated file for Resolve to make sense of it.

Jeremy

[Jeremy Garchow]

[Oliver Peters] “Of course, knowing how RED works, it will probably be different again the next version. 😉 “

[Oliver Peters] ” Unfortunately Apple seems to want its cake and eat it, too – lock down the app and make everything work well inside the walled garden, but then leave it up to outside developers when users need more flexibility.”

These two statements conflict.

So Red gets to do what it wants and Apple doesn’t?

Or is Apple taking only certain responsibility in giving manufacturers much more capability in FCPXML with which the manufacturers can do what they want with it?

[Jeremy Garchow]

[John Heagy] “The value of tcsource for us is that it’s embedded in the file, it’s actually the name of the timecode track, and can survive encodes, at least with Telestream software. The fact that tcsource is user definable in QT is where the value is for us. Having it user definable in FCPX, while not updating the file, is pointless to us. User definable data is only useful for that project/event. We need it to persist across projects/events as part of the media. “

But isn’t there persistent metadata in all of these files?

One man’s tcsource is another mans ClipID.

Once you start working with Red native files, or other RAW files, or image sequences, or anything that’s not a nicely package Qt movie, does that mean that FCPX has to translate and write in to every single file format possible? Isn’t is easier to have everything stored in an FCPXML that can be read by everyone the same way? ALong with the user generated data in the FCPXML, there’s persistent camera data that can be attached to this FCPXML and therefore attached to any file regardless of file format?

All of those formats have different methods of describing a reel.

[Oliver Peters]

[Jeremy Garchow] “So Red gets to do what it wants and Apple doesn’t?”

I’m not completely thrilled with either company’s approach. Workflows are built around consistency.

– Oliver

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

[Jeremy Garchow]

[Oliver Peters] “I’m not completely thrilled with either company’s approach. Workflows are built around consistency.”

The only consistency in this modern video age is the inconsistency.

[John Heagy]

[Jeremy Garchow] “But isn’t there persistent metadata in all of these files?

One man’s tcsource is another mans ClipID.
“

In the case of QT it’s UUID and for P2 it’s ClipID neither survive the encode process.

[Jeremy Garchow] “Once you start working with Red native files, or other RAW files, or image sequences, or anything that’s not a nicely package Qt movie, does that mean that FCPX has to translate and write in to every single file format possible?”

I package up everything in QT first. Too many NLEs try to be the center of the universe when it comes to media. We prepare, or as we say make the files “full citizens” of our process. This means being assigned unique Reel and TC.

Every frame of media whether film, tape, or digital media from 1958 ’till today can be found with two numbers… beat that!

I’m not asking for anything new here. This is bread and butter QT metadata that is currently supported in AVFoundation.

If Apple has other plans for “Reel” then just read and populate it as tcsource. There’s no excuse for excluding it.

John

[Jeremy Garchow]

[John Heagy] “I package up everything in QT first. Too many NLEs try to be the center of the universe when it comes to media. We prepare, or as we say make the files “full citizens” of our process. This means being assigned unique Reel and TC.

Every frame of media whether film, tape, or digital media from 1958 ’till today can be found with two numbers… beat that!

I’m not asking for anything new here. This is bread and butter QT metadata that is currently supported in AVFoundation.

If Apple has other plans for “Reel” then just read and populate it as tcsource. There’s no excuse for excluding it.
“

Perhaps.

[Jeremy Garchow]

Here’s a case in point.

Look at the absolute blitzkrieg of formats recently announced by Sony.

Sorry guys, handing this process off to camera manufacturers/3rd party developers to support it, is smart and logical.

https://blog.creativevideo.co.uk/2012/10/sonys-newf-cameras-revealed-f5-f55/

With an importer, metadata will get passed through in FCPXML.

I know, it won’t write to the files, but that’s a daunting task. Best to keep the metadata separate (like Panasonic already does) to allow all applications to read and access the data fairly easily.

Fcpx allows ultra quick manipulation of user generated data, you can export user customized blobs of metadata, there’s plenty of metadata from original cameras to make groups of clips or track clips through the post process.

With RAW workflows, the image manipulation information is metadata.

It will require a bit of workflow enhancement, but what else is new.

I’m not afraid. We will make it through.

Jeremy

[Richard Herd]

[Shane Ross] “Smash Blur isn’t basic editing”

Please make a tutorial on Smash Blur!

Thanks!

[John Heagy]

[Jeremy Garchow] “Sorry guys, handing this process off to camera manufacturers/3rd party developers to support it, is smart and logical.

With an importer, metadata will get passed through in FCPXML.

I know, it won’t write to the files, but that’s a daunting task. Best to keep the metadata separate (like Panasonic already does) to allow all applications to read and access the data fairly easily. “

I have no problem with addition metadata be read and populated via other methods beside Reel. However if one chooses to embed data in QT tcsource aka:Reel then READ IT!