-
FCP X Reels
-
[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?
-
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
-
[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
-
[Jeremy Garchow] “No. And perhaps this is crazy, but I am saying everyone should ignore that fact.
Red has their system, why not use it? Everywhere?
Why use XMP when I can’t use it anywhere else?”
Again, this seems like “we can’t standardize everything so let’s just not even try to standardize anything”. Which seems counterproductive.
[Jeremy Garchow] “Perhaps it’s better for camera manufacturers to assign what a reel is and input that in to FCPX.”
You seem to be worried there might be some situation where FCP X might import the standard QT reel metadata and this might turn out to be wrong. But of course if a clip created by a camera has data in this field, it’s because the camera manufacturer put it there. So I don’t quite see how that’s a concern.
[Jeremy Garchow] “I am looking further down the road as files keep piling on, formats change, containers update, Quicktime dies. Etc. I feel it’s better to look at other methods now while things are being rewritten, rather than try and bolt on what might not be the best method when taking all elements in to consideration.”
We’re free of an FCP that can only natively understand stuff in QuickTime containers (AKA MOV files), and we’re better off for it, but QuickTime, as a container format, is not going away. Really, there’s zero indication of this. Even with FCP X completely shedding any dependance on legacy QuickTime code (which it has), the QuickTime file format is still supported, and not just for legacy compatibility, but in active use. When FCP X generates proxies or render files, guess what container format those use? There’s no reason why Apple will (or should) get rid of this file format. Which makes it kind of baffling that they’ve apparently decided to stop supporting generic reel metadata embedded in it.
[Jeremy Garchow] “It is an important piece of data, and I don’t know why Apple doesn’t read the reel out of Quicktime. There must be a good reason as there’s no question it could be added with minimal fuss. Is that the best way?”
Yeah, if Apple were totally neglecting this issue, that would be one thing, but they’re not, they just seem to have chosen a very odd approach. It does seem like there has to be a reason for this, but I really can’t think of what it could be.
—
Digital Workflow/Colorist, Nice Dissolve.You should follow me on Twitter here. Or read our blog.
-
[Chris Kenny] “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:
-
[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.
-
[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
-
[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 -
[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
-
[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
Reply to this Discussion! Login or Sign Up