FORUMS: list search recent posts

FCP X Reels

COW Forums : Apple Final Cut Pro X Debates

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Oliver Peters
FCP X Reels
on Oct 26, 2012 at 5:32:47 pm

We've had this discussion before regarding tape reel names. Here's an update with 10.0.6. Apple has gone the route of using the embedded metadata track within QuickTime to place all sorts of metadata. This is something they are working out with camera manufacturers and it is starting to fall into place with 10.0.6. The new RED support already shows reel names.

One of my pet peeves has been with Alexa files and the fact that Reel ID numbers, which showed up in FCP 7, didn't in FCP X. That has now changed. Under Inspector/Info/Extended View you can open the Edit Metadata function. There's a whole bunch of additional options in there that you can turn on and have visible in the inspector. Specific to the Alexa, there's a lot of ARRI metadata, including the ARRI Reel ID. The catch is that these have to come from a camera using newer ARRI firmware.

The user entry "Reel" field is precisely that, intended for user entry - just like scene and take. If a piece of software embeds reel ID names/numbers as part of the TC track (like QtChange and FCP 7 have done) it won't be read in FCP X.

- Oliver

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


Return to posts index

Rick Lang
Re: FCP X Reels
on Oct 26, 2012 at 5:40:47 pm

I'm hoping FCPX 10.0.6 supports reel, etc. from the metadata input from a menu on the Blackmagic Design Cinema Camera.

Rick Lang

iMac 27” 2.8GHz i7 16GB


Return to posts index

Larry Asbell
Re: FCP X Reels
on Oct 26, 2012 at 6:24:42 pm

Did you mean "will be read in FCPX?"



Return to posts index


Oliver Peters
Re: FCP X Reels
on Oct 26, 2012 at 9:31:55 pm

[Larry Asbell] "Did you mean "will be read in FCPX?""

Reel IDs embedded into the TC track of a QT movie WILL NOT be read in FCP X.

- Oliver

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


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 27, 2012 at 4:11:43 pm

[Oliver Peters] "Reel IDs embedded into the TC track of a QT movie WILL NOT be read in FCP X."

It's kind of confusing that Apple would ignore this standard field and then rely on vendor-specific solutions. It seems like we've already got a situation where imported R3D clips come in with reel data in the 'Reel' field, but Alexa clips come in with reel data in a different Alexa-specific field. Why wouldn't you want reel metadata in the same field for all media types?

Well, as long as people don't rename the media files on disk it's never that hard to derive reel names for stuff shot on modern file-based cameras. Still, that would be more of a comfort if we hadn't had clients bring us projects where media files had been renamed.

--
Digital Workflow/Colorist, Nice Dissolve.

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


Return to posts index

Oliver Peters
Re: FCP X Reels
on Oct 27, 2012 at 4:42:45 pm

[Chris Kenny] "It's kind of confusing that Apple would ignore this standard field and then rely on vendor-specific solutions."

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".

- Oliver

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


Return to posts index


Chris Kenny
Re: FCP X Reels
on Oct 27, 2012 at 5:25:55 pm

[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.


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 5:29:10 pm

[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"."

While it might cause confusion at first, I think that moving the NLE to camera metadata is a good thing.

THis means that any NLE, if they use each manufacturers suggestions, should have portable metadata with the footage.

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.


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 27, 2012 at 6:33:35 pm

[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.


Return to posts index


Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 7:39:43 pm

[Chris Kenny] "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."

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.

With a unified metadata system, every single one of their file, be it DNxHD, Arri Raw, ProRes.mov will have the same metadata. Since all of those different formats have different fields, it is best to have their own fields, at least, it's best for Arri.

Now, apply that across every current and as yet to be developed container, codec, format, etc.

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.

At some point, a user could map metadata to other fields, but then what if that container doesn't support that field?

Jeremy


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 27, 2012 at 7:56:16 pm

[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.


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 8:28:00 pm

[Chris Kenny] "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."

Yes, and that is exactly what Apple is doing. Reading metadata from other camera manufactures and putting their fields in to the software.

There are still user defined fields that allow you to select a group of clips and assign what you want.

I am sure with the new v1.2 xml, media asset systems will allow metadata mapping.

There are no standards, Apple is embracing it.

[Chris Kenny] "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?"

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?

[Chris Kenny] "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."


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?

Why not give the capability to read whatever the camera manufacturer suggests and export it back out?


Return to posts index


Oliver Peters
Re: FCP X Reels
on Oct 27, 2012 at 8:42:10 pm

[Jeremy Garchow] "Apple is reading the XML that Arri provides. What's wrong with that?"

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.

- Oliver

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


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 27, 2012 at 9:22:32 pm

[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.


Return to posts index

Oliver Peters
Re: FCP X Reels
on Oct 27, 2012 at 9:36:15 pm

[Chris Kenny] "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?"

Here's my guess - and ONLY a guess. But, it would explain why we are seeing different results with Alexa and RED files. Apple has a camera SDK and quite possibly is leaving it up to various manufacturers to control how and where the data lives. RED requires an Importer plug-in. MXF media will require another Importer plug-in. So maybe a manufacturer has the option of whether to uses a unique field or create data in user columns. For example, it seems to me that there's no reason ARRI couldn't also create an Importer module that places some of these metadata fields also into the user fields.

Forget what FCP 7 was, what it does and so on. X is a new beast. Just like Adobe has been trying to encourage use of the Dublin Core metadata configuration, likewise Apple is doing their own thing with metadata in X. Maybe it gets used. Or maybe users will simply say that it's too much trouble.

All I know is that all of these possible places that reel/source ID show up (like it's different in Avid whether it's a file source or a tape source) make my life more difficult as an editor when I need to go outside of a single application.

- Oliver

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


Return to posts index


Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 10:05:01 pm

[Oliver Peters] "Here's my guess - and ONLY a guess. But, it would explain why we are seeing different results with Alexa and RED files. Apple has a camera SDK and quite possibly is leaving it up to various manufacturers to control how and where the data lives."

Yes, because it's a moving target.

The next format that comes out might not have a reel field, or perhaps the tc is stored in another file.

This is what I was saying when I said Quicktime is not the future.

Just like you have to buy different VTRs for different formats, tapeless formats have differing standards. FCPX allows all the proprieties to live comfortably as long as manufacturers or third party workflow enhancers want to support it.


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 9:33:16 pm

[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."

Apologies, I got ahead of myself.

When Arri (or Glue Tools or whoever) writes the blob that will allow the metadata mapping, it will use the XML, jsut like Red's importer does now, and kind of like the native P2 importer does for FCPX today (a third party MXF utility does it better, though).

My basic point is that FCPX is allowing real native camera metadata to be imported and exported out of the NLE with user generated fields, and also camera generated fields. It doesn't have to shoehorn them into a weird set of columns, a weird metadata "standard", or once and future container that may or may not ahve the appropriate metadata fields. I am sure some people see this as "stupid" or unnecessary on Apple's part, I see it as an opportunity.

This is not a bad thing, at least to me. It also allows access to third party workflow enhancers. This is also good.

The nice thing about the camera generated fields is that any system should be able to read them if they allow camera specific metadata. The rest of the user generated fields will need to be mapped to whatever the receiving application is comfortable with.

Since metadata is data that describes data, FCPX is looking like it's going to be very good at it.


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 27, 2012 at 9:18:39 pm

[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.


Return to posts index


Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 9:58:29 pm

[Chris Kenny] "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?"

It's not. Have a look at Oliver's original post.

[Chris Kenny] "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?"

For Red, Edge code start TC in the file is available in FCPX.

DSLR tc can be generated from THM files, yet FCPX doesn't generate it.

P2 material doesn't have reel, but it does have timecode.

Timecode is rather "fixed" on most cameras, while reel is not.

[Chris Kenny] "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."

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".

As far as the field naming, this is exactly what I am saying. If Red has a consistent naming system, and every NLE or video application uses that system, then there is parity. For instance,

If Red has a field named "SweetField", and every video application can read Red's fields, then every video application's "SweetField" will be the same.

Any user generated fields would have to be mapped, similar to how "Reel" is mapped to "Tape Name" in Pr. If you search the metadata window in Premiere, you won't find a "reel" field, but you will find "Tape Name". What does "Tape Name" have to do with an Alexa File?

In the case of P2, P2 has very specific metadata that is specified by their camera (you can also add user generated content). FCPX would allow exporting of that metadata that could be read by the camera (or any other system that understands P2 metadata in the P2 specific fields), as well as any user generated content. There is no confusion

How is this stupid and why can't you see where Apple is going with this?

[Chris Kenny] "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."

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 hope that makes sense.


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 27, 2012 at 10:15:12 pm

[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.


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 11:38:50 pm

[Chris Kenny] "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."

Is it a standardized way? I would say it's not. RMD sidecars are standard?

So the question of why should Red support their own cameras? Because they have the right to change or add capability at any moment. They should be responsible for that change.

Red has had great support for their own cameras starting with RedCineX. They also wrote their own Final Cut Studio support. All of thier camera support programs work really really well and that is because they support it.

[Chris Kenny] "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."

Container specific is also a moving target. When one makes an MXF file, there are many choices is to how that file could be made and what it needs to comply to. Panasonic has different recommendations than Sony.

MXF is a very "propritized" open standard.

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.

[Chris Kenny] "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."

I don't know. At this moment, no.

Final Cut 7 had this capability. You could either drag in an Alexa file(or import XML and reconnect), or with a Glue Tools Importer bring in much more metadata than FCP did on it's own, and it offered more tools such as Color Transformation and ISO control.

[Chris Kenny] "I don't understand this."

I'm sorry. I have a hard time explaining myself sometimes.

[Chris Kenny] "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?"

The Foo camera sounds fantastic. Can't wait to see the footage.

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?


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 28, 2012 at 12:32:58 am

[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.


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 28, 2012 at 1:22:09 am

[Chris Kenny] "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."

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?

[Chris Kenny] "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."

But don't you see that this is the problem?

I understand completely what you are saying, "there's a reel number, use it".

FCPX, as Oliver points out, FCPX treats reel as a user generated field.

Perhaps it's better for camera manufacturers to assign what a reel is and input that in to FCPX. What happens if a format doesn't have a reel?

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.

[Chris Kenny] "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."

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?


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 28, 2012 at 3:31:41 am

[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.


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 28, 2012 at 3:25:42 pm

[Chris Kenny] "Again, this seems like "we can't standardize everything so let's just not even try to standardize anything". Which seems counterproductive."

I disagree. It's obvious that there's not one NLE/Camera/Company/etc that can and will standardize metadata in the video world. So why should we keep trying to squeeze everything in to limited parameters? Why not just accept them all?

That's what FCPX seems to be doing. They're allowing camera manufactures/3rd parties to manipulate the software to assign and inject meaningful metadata that are present in the camera files, create whatever fields they want to reflect that data, and then you are able to export those fields out through FCPXML to pass to ther systems. If every system did this, there'd be metadata parity and there'd be no reason to make decisions like "what's a reel number" as the "Arri ID" or as John Heagy says, tcsource, would be the same across everything. So, I ask you, why standardize when all the information is already there? Why not make better use of the systems that are currently in place instead of trying to reinvent the wheel when passing data to all other systems?

[Chris Kenny] "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."

In another thread, we had a discussion about reel means in a tapeless world. Some said, it doesn't matter at all move on, others said, just keep the current convention. I feel the answer is somewhere in the middle.

John Heagy talked about the reel system that he uses. It is extensive and extends to many types of media including tape. FCPX allows user assignable reels, which are crucial to his organization system and archive. There are some things, especially when talking about tapeless assets, that shouldn't be changed.

If you'll allow me to correlate tape with tapeless:

A reel number on tape represents an actual tape/reel (location on a shelf), and the timecode represents where on that tape the media is. With tapeless, reel should represent one file (location on a hard drive) and the timecode represents where in the file the relevant media we need is situated. So maybe reel should be shifted to a user based input. When I used more tape, reel numbers were typed in by me all the time. No with tapeless, there's already data there to use, so why not use it and allow me to assign Reel as I see fit to conform to my organizational system?

Also, quite often out footage gets spread out across different projects so it needs to be "parted out" from the source material, so then the 'encompassing folder as a reel' starts to lose meaning.

[Chris Kenny] "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?"

That's easy, the answer to that question is purple.

In all seriousness, I'm not saying QT the container is going to die, but the API certainly is. It might not be right now, but it is going away.

And render files are not Quicktime files, they are these kinds of files, whatever that may be:



xrender_files.png


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 28, 2012 at 4:15:46 pm

[Jeremy Garchow] "I disagree. It's obvious that there's not one NLE/Camera/Company/etc that can and will standardize metadata in the video world. So why should we keep trying to squeeze everything in to limited parameters? Why not just accept them all? "

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.

[Jeremy Garchow] "Why not make better use of the systems that are currently in place instead of trying to reinvent the wheel when passing data to all other systems?"

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.

[Jeremy Garchow] "FCPX allows user assignable reels, which are crucial to his organization system and archive. "

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.

--
Digital Workflow/Colorist, Nice Dissolve.

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


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 29, 2012 at 3:39:19 pm

[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


Return to posts index

John Heagy
Re: FCP X Reels
on Oct 28, 2012 at 8:11:31 pm

[Jeremy Garchow] "John Heagy talked about the reel system that he uses. It is extensive and extends to many types of media including tape. FCPX allows user assignable reels, which are crucial to his organization system and archive. There are some things, especially when talking about tapeless assets, that shouldn't be changed."

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.

If Apple is reading all the custom QT keys from cameras, what is it reserving Reel for if not tcsource? If Apple has other plans for Reel so be it. Just give me the data from tcsource in a tcsource metadata field. I don't think that's asking too much. What excuse could they possibly have for excluding it?


John


Return to posts index

Oliver Peters
Re: FCP X Reels
on Oct 28, 2012 at 8:28:42 pm

[John Heagy] "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."

I completely agree and like to work that way, too. Unfortunately I think that ship has sailed. It's not the direction Apple has decided to go.

- Oliver

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


Return to posts index

John Heagy
Re: FCP X Reels
on Oct 28, 2012 at 10:34:52 pm

[Oliver Peters] "Unfortunately I think that ship has sailed. It's not the direction Apple has decided to go."

Can you explain what you believe Apple has in mind for "Reel". It's being populated by Red's importer but every other file is not allowed to populate it?

The Quicktime API replacement AVFoundation does support tcsource entry. Why would Apple carry it forward and not read it?

Worst case, as silly as it sounds, one could build a QT importer that does read tcsource and populate Reel.

Apple does seem willing to change course, like source monitor, so hopefully conversations like these can help persuade them.

Again, if Reel is so important it can't be touched just map tcsource to tcsource. What's one more metadata reel in the sea of fields FCPX already supports. There are 3 Altitude fields for Pete's sake!

John


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 29, 2012 at 3:47:00 pm

[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.


Return to posts index

John Heagy
Re: FCP X Reels
on Oct 29, 2012 at 4:38:00 pm

[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


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 29, 2012 at 5:05:24 pm

[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.


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 30, 2012 at 3:10:27 pm

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.

http://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


Return to posts index

John Heagy
Re: FCP X Reels
on Oct 30, 2012 at 6:04:58 pm

[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!


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 30, 2012 at 6:16:39 pm

[John Heagy] "However if one chooses to embed data in QT tcsource aka:Reel then READ IT!"

Oliver points out that it does happen, just not as expected.


Return to posts index

John Heagy
Re: FCP X Reels
on Oct 30, 2012 at 6:53:05 pm

[John Heagy] ""However if one chooses to embed data in QT tcsource aka:Reel then READ IT!""

[Jeremy Garchow] "Oliver points out that it does happen, just not as expected."

If your referring to the Arri Reel Name, that is a custom QT Key via a com.arri.camera.ReelName entry and not tcsource aka:Reel.

Apple has decided to exclude tcsource!

This is all exposed in CatDV which is excellent at reading every QT metadata entry amoung many others.

APPLE!!

IF IT"S THERE... READ IT!!!

John


Return to posts index

John Heagy
Re: FCP X Reels
on Oct 28, 2012 at 2:12:12 am

[Chris Kenny] "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. I"



Agreed! There's never an excuse for not reading metadata, particularly one this easy for Apple to read.

If Apple has a problem mapping it to Reel, then don't. Call it what is: tcsource and populate a tcsource metadata field in FCPX.

John


Return to posts index

Shane Ross
Re: FCP X Reels
on Oct 27, 2012 at 5:28:29 pm

[Chris Kenny] "It's kind of confusing that Apple would ignore this standard field and then rely on vendor-specific solutions."

Normally I would agree. But when they came out with FCX they flat out ignored most of the major needs of the higher end professionals, and relied on third parties to provide those solutions.

- Tape capture from non-firewire? Use the capture card software for that. Same for output to tape...third party

- Export AAF or OMF for audio mixing? Third party

- Import/export of standard XML? Third party

- A NEW feature they tout in the 10.0.6 update...the ability to work with MXF files native! YES...via third party.

- And now reading of reel numbers embedded in the metadata? Third party.

Frankly I'm shocked that FCX even cares about timecode anymore.

Reminds me of a few years ago when Apple went to the Supermeet in Las Vegas to do a presentation. What was the presentation? "Look at all our great third party partners...."

Shane
Little Frog Post
Read my blog, Little Frog in High Def


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 27, 2012 at 5:41:10 pm

[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.


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 5:42:06 pm

[Shane Ross] "Normally I would agree. But when they came out with FCX they flat out ignored most of the major needs of the higher end professionals, and relied on third parties to provide those solutions. "

Boo hoo.

Third party support isn't a bad thing unless you want it to be.

You rely on plugins to enhance/supplement your NLE and edits, then third party workflow tools enhance your NLE and workflow.

Some people use them, some people don't.

You buy what you need.

It makes perfect sense to me, although I used third party MXF and Alexa tools in FCP Legend, so I'm Ok with it.

I also think that this makes camera manufacturers pay attention and see how their footage and data will be used through the post process, in turn, making their products better.

Third parties make everything better in my opinion, as they work with the internal structures on a level that us users do not. Third parties usually have a more direct line to the major developers than general users do, therefore third parties can actually request features that make bigger differences in users day to day workflow.

Plus, if something is "broken" and you need to get actual support for a workflow enhancer, you can call and email people for a fix instead of waiting desperately for any major NLE patch. There's an advantage to working with smaller companies for this type of support.

It's a win win in my book. With 10.0.6, FCPXML has received some huge updates, and I expect will be seeing some major workflow enhancement fairly soon.


Jeremy


Return to posts index

Shane Ross
Re: FCP X Reels
on Oct 27, 2012 at 5:51:45 pm

[Jeremy Garchow] "Boo hoo."

Whatever. I've moved on. Just more of the "this used to do this stuff, now we no longer think you need it" things.

Like tape. Still using it...will be for a few more years. why not keep supporting it as long as the infrastructure does?

But...whatever. I don't use FCX, no plans to. Dunno why I keep hanging out here.

Shane
Little Frog Post
Read my blog, Little Frog in High Def


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 6:00:06 pm

[Shane Ross] "Whatever. I've moved on. Just more of the "this used to do this stuff, now we no longer think you need it" things. "

I could talk about this for a long time.

Ultimately, I think the FCPX model has potential to be better, even if it is more confusing up front.

For instance, let's look at AMA.

If AMA is "broken" or you want more capability, who do you have to wait for and for how long to get those fixes?

If an MXF workflow enhancer for FCPX is "broken" who do you have to wait for and for how long?

With tape capture, you will now rely on third party vendors. Every capture card manufacturer has their own capture software. Now with FCPXML v1.2, it seems there are more hooks than ever to be able to send data back and forth in and out of FCPX.

So, if I own an AJA card, and if they ever release their Control Room software, won't I be able to add this capability right back in to my workflow?

Let's say I am a user that doesn't use tape, I am now expected to let Apple develop a robust tape capture system when I'd rather they fix and enhance other parts of the NLE?

Parting out certain workflows to third parties is NOT a bad thing in my book, but again, I am used to it and have been doing this type of workflow for years in FCP Legend. It doesn't bother me one bit.

Jeremy


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 6:04:50 pm

[Shane Ross] "Like tape. Still using it...will be for a few more years. why not keep supporting it as long as the infrastructure does? "

One more thing, let's put it in to plug in terms.

Let's say I do a ton of green screen, and the tools of my particular NLE are no good.

Do I get mad at my NLE company because their internal keyer sucks, or do I turn to a third party to help enhance that capability with my current NLE?

Same thing for interchange workflows.

Not everyone needs a keyer, not everyone needs native MXF support, not everyone needs EDL/OMF/AAF.

If you do, you go purchase that capability.


Return to posts index

Shane Ross
Re: FCP X Reels
on Oct 27, 2012 at 7:02:02 pm

[Jeremy Garchow] "Let's say I do a ton of green screen, and the tools of my particular NLE are no good."

Green Screen isn't part of the main realm of the NLE. Editing is. And apps that ignore the basics of editing...reel numbers...capturing from a still industry standard format (even though it is fading, there is no argument there)...exporting files to other aspects of post production (audio, color grading machine). Those were all features of FCP. Gone in FCX.

But, I do know that that isn't the market for the new FCX. We aren't the market...so why do I keep hoping they will support our needs? Apple is aiming at a broader, more profitable market. I can't blame them. So I see where they are going. It isn't where I am.

Shane
Little Frog Post
Read my blog, Little Frog in High Def


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 7:51:37 pm

[Shane Ross] "Green Screen isn't part of the main realm of the NLE. Editing is. And apps that ignore the basics of editing...reel numbers...capturing from a still industry standard format (even though it is fading, there is no argument there)...exporting files to other aspects of post production (audio, color grading machine). Those were all features of FCP. Gone in FCX."

But what if Green Screen is part of your realm?

OK, let's say it's not green screen, lets say is a smash blur transition, or some other transition that your NLE doesn't have.

Do you complain to Avid to add it, or do you go buy a transition filter that will get the job done?

For some, EDLs aren't part of an editing realm.

[Shane Ross] "But, I do know that that isn't the market for the new FCX. We aren't the market...so why do I keep hoping they will support our needs? Apple is aiming at a broader, more profitable market. I can't blame them. So I see where they are going. It isn't where I am."

I see it differently. I know that FCPX isn't for everyone, or that you might not like the way the software works, that's all good, but with later releases, especially this latest release, there's a lot more infrastructure that is targeted directly at high end professionals.

Jeremy


Return to posts index

Shane Ross
Re: FCP X Reels
on Oct 27, 2012 at 8:03:54 pm

[Jeremy Garchow] "
OK, let's say it's not green screen, lets say is a smash blur transition, or some other transition that your NLE doesn't have.

Do you complain to Avid to add it, or do you go buy a transition filter that will get the job done?"


Smash Blur isn't basic editing. Cutting, dissolving, that's basic editing. All NLE's have that. Tape capture, tapeless capture. Basic importing of footage so that you CAN edit...that's a basic editing function. To leave one out, that is still in use...albiet by us 2%ers...is odd. But, as I said, they don't market to us anymore...don't look to our needs. They look to the needs of the masses, because that is where the money is. But, I guess the masses need an NLE too. One that they can afford.

[Jeremy Garchow] "
For some, EDLs aren't part of an editing realm."


I know...but it still is a part, silly as it is. But again, not part of the realm that Apple targets to any more. And again, something it USED TO DO...that is still in use, but it no longer cares to support.

[Jeremy Garchow] "I see it differently. I know that FCPX isn't for everyone, or that you might not like the way the software works, that's all good, but with later releases, especially this latest release, there's a lot more infrastructure that is targeted directly at high end professionals."

All I'm saying is that FCP used to do this, and now it doesn't. Because only a small few used those features, and it wasn't a good use or resources to make those features for those few...so ditch it. Aim for those vast number of editing professionals that have other needs.

As I said..."whatever." I should stop loitering about here because the app isn't aimed at my area of production anymore. People keep saying "Keep your eye on FCX...soon it will!" Sorry, I don't see that. Even with the latest update...it still isn't a tool that does what i need, offer me ways to deliver what I need to deliver.

Shane
Little Frog Post
Read my blog, Little Frog in High Def


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 9:20:25 pm

[Shane Ross] "All I'm saying is that FCP used to do this, and now it doesn't. Because only a small few used those features, and it wasn't a good use or resources to make those features for those few...so ditch it. Aim for those vast number of editing professionals that have other needs."

I guess I feel completely different about this situation.


Return to posts index

Richard Herd
Re: FCP X Reels
on Oct 30, 2012 at 4:00:19 pm

[Shane Ross] "Smash Blur isn't basic editing"

Please make a tutorial on Smash Blur!

Thanks!


Return to posts index

Chris Kenny
Re: FCP X Reels
on Oct 27, 2012 at 8:05:02 pm

[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.


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 3:37:49 am

[Oliver Peters] "One of my pet peeves has been with Alexa files and the fact that Reel ID numbers, which showed up in FCP 7, didn't in FCP X. That has now changed. Under Inspector/Info/Extended View you can open the Edit Metadata function. There's a whole bunch of additional options in there that you can turn on and have visible in the inspector. Specific to the Alexa, there's a lot of ARRI metadata, including the ARRI Reel ID. The catch is that these have to come from a camera using newer ARRI firmware."

Weird.

How new does the firmware have to be and do you have a version number?

I have Alexa files shot in March that aren't showing any info.

Now we need a metadata mapper. At least FCPXML will now export the data.


Return to posts index

Oliver Peters
Re: FCP X Reels
on Oct 27, 2012 at 1:28:09 pm

[Jeremy Garchow] "How new does the firmware have to be and do you have a version number?
I have Alexa files shot in March that aren't showing any info."


The camera owner has to have updated the camera's firmware. I believe not all of these are free updates, so owners don't necessarily upgrade their camera as frequently as other types of software. I'm not sure when this kicked in, but the current version is SUP 6.x. There are incremental patch numbers, but 6.0 forward should be fine. Maybe even a version earlier.

In the attached screen grab, note all the camera-based metadata fields that are available. This example is from a clip shot in April.



In the Inspector view, notice the ARRI Reel Name versus the blank Reel name. (BTW - these fields can be dragged up or down to change position.) In the fields that you can add to the Inspector, the ARRI fields are listed as "Camera" type, meaning that they are coming from the file. The Reel field is listed as a "Studio" type. This means it's a user entry field. Quite possibly "Studio" fields could tie into a 3rd party app down the road - presumably some that can write FCPX XML - or via a utility, which doesn't exist yet. Or maybe FileMaker Pro in the future.

- Oliver

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


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 5:23:11 pm

[Oliver Peters] "The camera owner has to have updated the camera's firmware. I believe not all of these are free updates, so owners don't necessarily upgrade their camera as frequently as other types of software. I'm not sure when this kicked in, but the current version is SUP 6.x. There are incremental patch numbers, but 6.0 forward should be fine. Maybe even a version earlier."

Seems weird.

The rental house we use is always up to date. The XML says the Sup is 6.0 when this footage was shot.

It was an Alexa Plus, I don't know if that has any bearing on the situation.

On a completely separate tangent,

When you open the import window, do you have the choice of sorting by list view or filmstrip view? Or is it just list view?

The reason I ask is that I have seen a few screengrabs were filmstrip is available, but they might have been non release builds.

If you have this option perhaps I should redownload 10.0.6.

Jeremy


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 5:31:57 pm

I should add, all Red metadata is completely fine.

Jeremy


Return to posts index

Oliver Peters
Re: FCP X Reels
on Oct 27, 2012 at 7:01:16 pm

[Jeremy Garchow] "The rental house we use is always up to date. The XML says the Sup is 6.0 when this footage was shot. It was an Alexa Plus, I don't know if that has any bearing on the situation."

Note sure why. My example was also a Plus. Could be that the your files weren't a direct copy. Maybe handled through some on-set software or Resolve to add a LUT.

[Jeremy Garchow] "When you open the import window, do you have the choice of sorting by list view or filmstrip view? Or is it just list view?"

I see a list, a filmstrip and a viewer. The Import module functions differ depending on if it's a file on a hard drive, a camera card or a mounted volume (disc image from card) or a camera archive. If it thinks it's from a camera device/volume, you can import range selections - like FCP7 L&T - except multiple ranged. If it's from a hard drive, you have to import the whole clip.

- Oliver

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


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 7:47:00 pm

[Oliver Peters] "Could be that the your files weren't a direct copy. Maybe handled through some on-set software or Resolve to add a LUT."

It was me that did the transfers, and it was Shotput Pro. Everything seems to be in place.

[Oliver Peters] "I see a list, a filmstrip and a viewer. The Import module functions differ depending on if it's a file on a hard drive, a camera card or a mounted volume (disc image from card) or a camera archive. If it thinks it's from a camera device/volume, you can import range selections - like FCP7 L&T - except multiple ranged. If it's from a hard drive, you have to import the whole clip."

Got ya. I never import straight form a card/image so maybe that's why it's different. If you look here at the first few grabs in this article, my import window doesn't look like that. That is coming off of a direct attach camera, though:

http://www.kenstone.net/fcp_homepage/fcp_x_first_look_06_martin.html

Thanks for verifying that.


Return to posts index

Oliver Peters
Re: FCP X Reels
on Oct 27, 2012 at 8:04:39 pm

[Jeremy Garchow] "my import window doesn't look like that. That is coming off of a direct attach camera"

It should look like this if coming from a hard drive.



- Oliver

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


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 27, 2012 at 8:28:57 pm

Thanks, Oliver. That's how it looks here. I have not seen the Ken Stone window, that's why I asked.


Return to posts index

John Heagy
Re: FCP X Reels
on Oct 28, 2012 at 2:02:32 am

How did a Reel conversation get this long without me chiming in? That's what I get for taking a few days off.

Interesting that FCPX sees what is apparently an Arri custom QT metadata key. CatDV is excellent at exposing these. I will have a look on Monday.

As far as the theory that Apple is treating each camera file's Reel data separately, that's all fine. All metadata should be read and the correct field populated. So what's Apple's excuse for ignoring QT tcsource aka: Reel, Tape Name, Tape ID and Source in QT files?

Why doesn't Apple read tcsource and include a tcsource metadata field to populate?
That would work fine for me "A rose by any other name..."

Anybody care to argue for not reading a file's metadata?

Bottom line: If there's metadata, and it can be read... READ IT!

John


Return to posts index

Oliver Peters
Re: FCP X Reels
on Oct 28, 2012 at 10:57:57 pm

[John Heagy] "Can you explain what you believe Apple has in mind for "Reel". It's being populated by Red's importer but every other file is not allowed to populate it?"

I can't honestly say what they intend. I guess they plan to make more use of the metadata track in QT. I think the only reason the RED reels are there is because RED puts it there. I suppose each manufacturer has that option. Of course, knowing how RED works, it will probably be different again the next version. ;-)

Although I agree with your overall sentiment, Apple is not alone in this. Likewise, Adobe and Avid do their own things with metadata and there's no guarantee in any of these, that a "reel" name or ID is going to appear where you think it is. Avid in particular makes a hard distinction in the difference between tape and file sources and that extends into the coding, which the user cannot easily override.

[John Heagy] "if Reel is so important it can't be touched just map tcsource to tcsource. What's one more metadata reel in the sea of fields FCPX already supports."

One of the things you have to remember is that workflows you and I have discussed in our posts are inherently destructive. We are doing things that alter the media file. Apple used to do this with FCP "legacy" but I think they found out over the years that there are enough stupid users, so that this can be a VERY BAD thing. FCP X tends to go overboard in the other direction, by locking down the media file and doing all the changes within the internal database. Avid has basically done the same thing for years, which is why they get praise for rock solid media management. 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.

- Oliver

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


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 29, 2012 at 3:42:33 pm

[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?


Return to posts index

Oliver Peters
Re: FCP X Reels
on Oct 29, 2012 at 4:18:43 pm

[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


Return to posts index

Jeremy Garchow
Re: FCP X Reels
on Oct 29, 2012 at 4:22:10 pm

[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.


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]