[Chris Kenny]

[Jeremy Garchow] “No. And perhaps this is crazy, but I am saying everyone should ignore that fact.

Red has their system, why not use it? Everywhere?

Why use XMP when I can’t use it anywhere else?”

Again, this seems like “we can’t standardize everything so let’s just not even try to standardize anything”. Which seems counterproductive.

[Jeremy Garchow] “Perhaps it’s better for camera manufacturers to assign what a reel is and input that in to FCPX.”

You seem to be worried there might be some situation where FCP X might import the standard QT reel metadata and this might turn out to be wrong. But of course if a clip created by a camera has data in this field, it’s because the camera manufacturer put it there. So I don’t quite see how that’s a concern.

[Jeremy Garchow] “I am looking further down the road as files keep piling on, formats change, containers update, Quicktime dies. Etc. I feel it’s better to look at other methods now while things are being rewritten, rather than try and bolt on what might not be the best method when taking all elements in to consideration.”

We’re free of an FCP that can only natively understand stuff in QuickTime containers (AKA MOV files), and we’re better off for it, but QuickTime, as a container format, is not going away. Really, there’s zero indication of this. Even with FCP X completely shedding any dependance on legacy QuickTime code (which it has), the QuickTime file format is still supported, and not just for legacy compatibility, but in active use. When FCP X generates proxies or render files, guess what container format those use? There’s no reason why Apple will (or should) get rid of this file format. Which makes it kind of baffling that they’ve apparently decided to stop supporting generic reel metadata embedded in it.

[Jeremy Garchow] “It is an important piece of data, and I don’t know why Apple doesn’t read the reel out of Quicktime. There must be a good reason as there’s no question it could be added with minimal fuss. Is that the best way?”

Yeah, if Apple were totally neglecting this issue, that would be one thing, but they’re not, they just seem to have chosen a very odd approach. It does seem like there has to be a reason for this, but I really can’t think of what it could be.

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.

[Chris Kenny]

[Jeremy Garchow] “Is it a standardized way? I would say it’s not. RMD sidecars are standard?”

It’s standardized for each container format (at least for many of them). Your argument seems to be that because it’s not standardized between container formats, Apple should simply ignore that fact.

[Jeremy Garchow] “And that’s not to say that Panasonic or Sony or anyone can change their minds at any moment and start adding or taking away fields and capability. FCPX will be able to handle it much more quickly if camera companies (or third parties) write their own support and keep updating the importer instead of Apple having to keep updating the entire application.”

You’re responding to an argument I’m not really making. I’m not saying vendors shouldn’t be able to release camera-specific import plugins. In fact, I said before this whole debate started that I favored that approach to e.g. Apple trying to support R3D, etc. in-house — for precisely the reasons you’re giving.

What I’m saying is that for container formats that do offer standardized metadata, Apple shouldn’t deliberately ignore that when it’s present merely because it might not always be present or because other container formats might not support it.

And, indeed, this seems to be what Apple is doing… with everything except reel names from QT files, for some reason. If you think of the the other metadata in a QT file — timecode, frame rate, frame size, codec, etc. FCP X is reading this all from standard QT metadata fields, not requiring Arri to add a special ‘Alexa frame rate field’ to Alexa-generated MOV clips and then write a plug-in that maps that to the correct field in FCP X.

It’s odd that Apple chose not to do that with this one piece of metadata, particularly given how important this particular bit of meta data is to many workflows.

[Jeremy Garchow] “I don’t see it as a huge hassle. All of these cameras have different conventions and standards, don’t you think it’s best that the camera manufactures tell the software what to do instead of having the software guess?”

I think it’s best if camera manufactures tell the software if it’s necessary to do so, but again, with Alexa footage we’re talking about MOV files containing a ProRes track, a timecode track, and maybe some uncompressed audio tracks, with reels and timecode embedded according to the QuickTime file format specification. I don’t see what anyone gains by Apple requiring a third-party plug-in (if such a thing is possible in this case) to make that work correctly. It would be like Adobe refusing to read certain types of standardized EXIF data out of JPEG photo files unless the camera vendor supplied a plug-in.

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.

[Chris Kenny]

[Jeremy Garchow] “Red has given their FCPX support away for free. Without downloading and installing their software, you can’t get the information in to FCPX. i am sure their importer maps the data to reel. If Arri released FCPX support, I bet they would map Arri Reel ID to FCPX “Reel”.”

The question is why they should have to, when we’re talking about files that use a container format that already supports this metadata in a standardize way.

Basically, Apple seems to be making representation of this data camera-specific when it only needs to be container-specific. Given that there are many more cameras than container formats, this seems counterproductive. It also seems to provide no standard mechanism for embedding reel names in media files that aren’t generated by particular models of camera, like, as in my earlier example, VFX clips.

Also, as far as I’m aware we don’t really know at this point if Arri could fix this. The Alexa files we’re talking about here are, after all, MOV files containing ProRes data. Obviously there’s some mechanism through which FCP X can identify a plugin to use to read data from MXF or R3D containers, but can you create plug-ins (not just additional QT codecs) that get invoked for MOV files? One could imagine the answer to that question going either way.

[Jeremy Garchow] “On the contrary, I said it would be more work and take more coding. I know this. But that hard work won’t go in vain and it will be easier to keep metadata parity between all kinds of systems instead of all of them wrapping it up in to differing conventions/standards.”

I don’t understand this. Again, there’s already a standardized field in this case. Why should Alexa put reels in an ‘Alexa reel’ metadata field, and a hypothetical Foo Camera (which can also record to an MOV container) put metadata in a ‘Foo reel’ field? Isn’t that (which seems to be what you’re advocating) using “differing conventions/standards”, and isn’t that going to be a huge hassle for every single app that needs to read these files? Why isn’t it better to just use the standard field provided by the container format?

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.

[Chris Kenny]

[Oliver Peters] “Actually no. This metadata is also embedded into the QT movie as part of a hidden metadata track. In my examples, FCP X is reading directly from the files. No XML involved.”

OK, so I wasn’t misunderstanding this.

This seems completely nuts. Why favor the creation of a camera-specific field for this metadata when there’s a standardized field supported by the container format that’s intended to (and in the case Alexa-generated MOV clips does) already contain this data?

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.

[Chris Kenny]

[Jeremy Garchow] “Apple is reading the XML that Arri provides. What’s wrong with that? Does DNXHD have a “reel” field? Is it in the same place as a QT movie? How about Arri Raw files? Reel field? Why not just read the XML that applies to all of the footage in the same way form the same camera regardless of recording format?”

Hand on, I’m unclear on this, and I don’t have an untouched downloaded Alexa mag to check with. Are you saying if you import an MOV file generated by an Alexa absent a separate XML file that no reel metadata comes through, even though it’s present in the file? That would also seem like a rather poor decision. Why ignore useful metadata that’s present?

[Jeremy Garchow] “You can export XMLs with custom metadata fields now in FCPXML. Camera manufacturers go out of their way to make things different for everyone. Why is it Apple’s responsibility to combine all of that mess from now and in to the future?”

Because it’s not very difficult and it makes it easier to handle multiformat projects. You know everything you’re saying about reel names here is equally true for timecode. Would you be in favor of Apple supporting ‘R3D timecode’ and ‘Alexa timecode’ and so forth all in different fields, rather than simply mapping all of these onto a single timecode field?

Again, with basically the first two high-end camera formats to get native support, we already seem to have an issue where for Red clips you do get data in the native ‘reel’ field, and for Alexa clips you don’t, because it’s in another field. And even if you do export that other field in XML, it’s still named differently, making things more complicated for other apps that might want to work with the footage.

It’s true that with 100% file based workflow and tools that are completely built around it, reel names won’t really be necessary because you’ll simple use file names. But workflows aren’t quite there yet. And unlike, say, fully supporting tape formats, reading the standard ‘reel’ field from QuickTime movies and mapping reel data from non-QT camera formats into that field would be completely trivial. You’re saying Apple shouldn’t have to this work like it’s some kind of burden, but using camera-specific metadata fields instead of standardized fields (for formats like MOV that support the latter) is more work.

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.

[Chris Kenny]

[Shane Ross] “But, I do know that that isn’t the market for the new FCX. We aren’t the market…”

Honestly, who is the market? This was set up early on as a bizarre ‘consumers’ vs. ‘pros’ dichotomy, but that’s obvious nonsense; consumers don’t buy $300 NLE software and FCP X has (and even in its first release had) tons of features that would be utterly useless to actual ‘consumers’.

People are interpreting every instance of “Apple does this differently for reasons I don’t understand” and “Apple hasn’t implemented this one particular thing yet” as evidence of “Apple isn’t interested in users like me”. As I noted many months ago, I could lay out an extensive argument for how FCP 7 doesn’t cater to higher end workflows and FCP X does. It’s just a matter of focusing on a different set of capabilities. Some people coming from FCP 7 simply take its limitations for granted, while at the same time being hyperaware of the things FCP X doesn’t have, which creates an extremely skewed picture compared with looking at the overall feature sets of the apps.

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.

[Chris Kenny]

[Jeremy Garchow] “That’s easy, bud.

Quicktime is not the future.

Arri won’t rely it on it forever, as they already have at least two other recording formats.”

This still doesn’t make a case for what Apple is doing. You can’t meaningfully ‘standardize’ a metadata field across two different container formats, because metadata is stored in different ways in different container formats. In other words, an NLE that wants to read reel metadata out of an MXF file needs to do that using different code than it uses to read a reel out of an MOV file, or an R3D file, or whatever. This is equally true regardless of whether the ‘reel’ data in question is stored in a camera-specific field or is stored in a generic ‘reel’ field provided by the container format.

[Jeremy Garchow] ”
If camera manufacturers have their own metadata or formats, it’s best if NLEs can read that data rather than try and force translate in to some other convention.”

I agree that had Arri used a custom metadata field for reel information in MOV files generated by the Alexa, Apple should have written code to import that (but probably they should have written code to map it to the primary ‘reel’ field, not a field with another name that won’t be present for clips from any other camera). But that’s not what happened here. In this case, the Alexa was writing this data to a standard field. Why would Apple not just read that?

Think about a project that uses a mix of Alexa and R3D footage, as well as some VFX shots that have been rendered to ProRes and dropped into the timeline. In FCP 7, all of these things have reel metadata in the same field (or can have it added, in the case of the VFX shots which might not come it with it — and the added data is embedded in the QT file, so it’s readable by other apps). In the case of FCP X, the R3D clips will have reel metadata in one field, the Alexa clips will have it in another, and while you can attach reel metadata to your ProRes VFX clips in FCP X, it won’t embed that data in those media files, so it’ll be useless for conforming with those clips in other apps.

There must be some logic behind Apple’s approach, since it seems like they’re actively going out of their way to do things thing way, but I can’t for the life of me understand what it is.

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.

[Chris Kenny]

[Jeremy Garchow] “If Resolve, FCPX, Pr, Avid, whatever, all use “ARRI Reel Name” for Alexa footage, then the metadata will travel to any system.

I know it’s more complicated to code at first, but it will at least offer some parity.”

Third party software already could (and did) read the standard QuickTime metadata field, though, so this isn’t really an explanation for why Apple decided to go this way.

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.

[Chris Kenny]

[Shane Ross] “- Tape capture from non-firewire? Use the capture card software for that. Same for output to tape…third party”

Personally I think they’d have been nuts to devote resources to tape at this point. I know it’s still pretty widely used, but it’s on the way out. There will almost certainly never be another new professional video tape format. The future of SR, for instance, is solid state.

[Shane Ross] “- Import/export of standard XML? Third party”

FCP X’s XML format is no less of a ‘standard’ than FCP 7’s, it’s just newer and consequently not as widely supported. (Although really support is pretty widespread now.)

[Shane Ross] “- A NEW feature they tout in the 10.0.6 update…the ability to work with MXF files native! YES…via third party.”

I actually prefer the model of building in flexibility (which FCP X clearly has — it can natively work with media in non-MOV containers, which ‘classic’ FCP never could) and then leaving this sort of thing up to plug-ins. That way you’re not waiting on the NLE vendor when things change. Maybe this doesn’t matter that much with MXF, but it’s quite important with support for native camera formats that are sometimes updated (i.e. Red).

[Shane Ross] “- And now reading of reel numbers embedded in the metadata? Third party.”

This isn’t really ‘third party’ — FCP X doesn’t require a plug-in to read the Alexa-specific field in question. I’m not even sure there’s anything meaningfully ‘professional’ or ‘unprofessional’ about this decision. It’s just a bit odd that they’d require Arri to add this field when the relevant metadata was already present in a standard field, and that they’d adopt an approach that seems to leave no mechanism for attaching reels to arbitrary MOV files. There must be some logic behind this (it’s not like doing things this way is easier for them or anything) and I’m curious what it is.

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.

[Chris Kenny]

[Oliver Peters] “The operative word is “standard”. Nothing about QuickTime is an actual standard. As odd as it may sound, moving this over to specific metadata fields is actually an effort to become standardized, if still not an actual “standard”.”

QuickTime isn’t a formally certified industry standard, if that’s what you mean, but the file format is openly documented.

—
Digital Workflow/Colorist, Nice Dissolve.

You should follow me on Twitter here. Or read our blog.