-
FCP X Reels
-
[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.
-
[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.
-
[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.
-
[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.
-
[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 -
[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.
-
[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.
-
[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] “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?
-
[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.
Reply to this Discussion! Login or Sign Up