-
Kinda hijacking the REELS thread from below…
SInce I spent quite some time late last year trying to get up to speed on taxonomy issues – I’d be interested in hearing from everyone about just what people think a good REEL ID field should look like?
How many digits should it have. Numeric only? Alphanumeric? Do you allow non-standard keyboard characters and/or wildcards?
What do your reel ID’s look like now? Are you carrying over legacy systems from your tapes? Do you have content on physical tapes, cartridges? cards? in virtual “reels” on hard drives?
How many digits do you suggest a “standard reel number” use in order to keep the typical shop from running into issues of reel number duplication?
Many here seem to be really interested in seeing a REEL ID field – and it seems to me that what they want is to be able to do the same thing they’re doing currently – so what exactly is that?
I’d be very interested in hearing about how different pros approach this same, very traditional task.
My suspicion is that there’s going to be a HUGE variety of approaches out there.
In my personal case, during the many years I produced hundreds of programs for my corporate clients I worked first in BetaSP and then in DVCAM. I generated about 400 physical tapes before I switched to cards. So I used a Reel ID system that used 4 alpha characters (2 for the client – 2 for the division) then a 2 digit year code – and a 3 digit tape number code. So the “Reel number” I needed was something like PSTR-05-206 – which told me the tape was from a PetSmart Project for the Training Dept shot in 2005 – started in February – and that that particular tape was the sixth one I used for that project.
It made physical filing and location easy. But it was designed for physical objects, not electronic files.
When I switched to using FCP-X and working exclusively with CARD based media, I had to re-think my old system, and started using simpler numerics in the year/month/day format plus one letter like 120807A- for my Card IDs and dumped all the rest.
So I’m honestly interested in knowing ….
Its only important to handle RED IDs if you shoot RED. Same with Alexa or Phantom Files or whatever.
IS there a universal Reel ID format that anyone could ever agree on?
And if not, isn’t it going to be an issue if you’re going to import different types of REEL IDs into a unified REEL ID field and then ever want to SORT them into meaningful lists?
Truly curious about this.
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
-
15 Replies
-
When dealing with DSLR footage this is what I use:
CAMID_Mag_DateSo for example A001_29102012 is Cam A, Mag/Card 1 and it was shot on October 29, 2012.
On the odd occasion (it’s only happened twice in the last 2 years) where we have multiple projects shooting simultaneously, I’ll add a Client Key to the end of the above string.
For dual system sound, I change the CAMID to S, so i know straight away that it’s come off a field recorder. The rest of the string stays the same.
I translate this info into FCPX angle metadata as well, so if I’m using Multicam and I sync up various angles, the priority follows accordingly. A at the top and S at the bottom.
-
[Bill Davis] “My suspicion is that there’s going to be a HUGE variety of approaches out there. …isn’t it going to be an issue if you’re going to import different types of REEL IDs into a unified REEL ID field and then ever want to SORT them into meaningful lists?”
Bill,
In my workflows, the purpose of these fields is to communicate sources effectively to the lab so that they can conform back to original materials.
As such, the requested format of this information differs from lab to lab (and sometimes project to project).
I have not been particularly pro-active in seeking or promoting any sort of standard, as I’ve been quite happy with this workflow – it’s always been simple enough and it works.
Franz.
-
I just did a session dealing with camera metadata and the importance of consistency and persistence of that metadata throughout post. Not only for picture, but sound, and then double system workflows where a single clip represents two different sources, etc.
There are formats that have long filenames, but also include a REEL ID in the header of the file which is usually a truncation of the filename to 8 characters; such as ARRI Alexa and Red to some extent. This is due to EDL’s being the sequence translation in many cases (unfortunately) and it’s legacy limitation of only having 8 characters as source. Media Composer offers 16 and 32 versions of the EDL while also removing other CMX limitations such as number of events and number of sources (999 and 254 respectively).
So some cameras use a shorter REEL ID, some don’t. Some cameras allow you to create very long Camera ID such as the BMCC. I have seen some as long as 51 characters. VFX can create long filenames, and such. So in the end, systems need to be prepared to support any length of filename string supported by the OS as well as any and all metadata in the header to allow full flexibility in post workflows chosen.
Michael
-
Our Reel system applies to all media, camera original, masters, and elements. It is a simple 6digit number that simply increments.
It obviously started as tape IDs where each camera tape and every master have it’s own Reel ID. In the case of digital camera media we currently assign Reel ID on a card/container basis but ultimately it will span multiple cards to represent a camera/day. Because we require unique reel IDs we can’t use the camera generated Reel in Alexa or Red as they are not unique and quickly repeat.
I use Reel as more of a GUID or content ID then anything to do with a container/tape. I need a way to ID content so when a select gets sliced out of a larger file, or a partial file restore comes in from LTO, the Reel ID persists so I can link to it without worrying about the original filename/path, or any other linking criteria matching. I can’t rely on UUIDs as they are reset whenever a new file is made regardless of content.
Reel ID is also a way of communicating accurately. Remembering the exact name of a master or group of camera files is less accurate, or as easy to remember, as a 6 digit number.
As far as a standard I think it should continue to be whatever the user needs it to be. So a simple text string is fine for me.
John
-
[Bill Davis] “How many digits should it have. Numeric only? Alphanumeric? Do you allow non-standard keyboard characters and/or wildcards?”
It should allow anything, up to at least 255 characters.
[Bill Davis] “Many here seem to be really interested in seeing a REEL ID field – and it seems to me that what they want is to be able to do the same thing they’re doing currently – so what exactly is that?”
Right now we’re working mostly with Red/Alexa projects, and moving them from NLE software to Resolve. Resolve is heavily reliant on reels, and can read them out of QuickTime files. With projects from FCP 7, we manually assign reels to any elements like VFX where they’re not already present. Often these are descriptive and/or based on file names, so if you import an EDL/XML and the file doesn’t re-link, you can tell from the reel name what file it is.
Now, one could make an argument that in file-based workflows this shouldn’t be necessary — file name + timecode is sufficient to uniquely identify any frame in the project. However, this makes me very nervous. Most of the projects we work on are edited from offline footage, and though it’s a really bad idea, clients sometimes rename those offline video clips on disk. This means if they don’t have embedded reel names that the NLE can read and export, there is absolutely no way to automatically relink them to online media. It’s not hard to imagine this occurring with FCP X projects as it’s more widely used.
So the issue here for me isn’t that there’s no good workflow if FCP X doesn’t read reels out of QuickTime files, it’s that there are more bad workflows, and it won’t be obvious to our clients that they’re bad until it’s too late. This could all be resolved by FCP X simply reading reel metadata into the ‘reel’ field whenever it’s present in a source media file that FCP X can natively import.
Of course in a really ideal world, timecode would be expanded to include day/month/year, plus a randomly generated universally unique frame ID just in case a reset clock would otherwise create duplicated timecode. Plus every file-based camera should also write a universally unique camera ID. It’s silly that in 2012 we still don’t have a reliably way to uniquely identify frames on a global basis.
—
Digital Workflow/Colorist, Nice Dissolve.You should follow me on Twitter here. Or read our blog.
-
[Chris Kenny] “Now, one could make an argument that in file-based workflows this shouldn’t be necessary — file name + timecode is sufficient to uniquely identify any frame in the project. However, this makes me very nervous.”
I’m not a fan of filename/path linking either. Why would I rely on the two easiest to change attributes of a file. We routinley change both the name and path of files and rely on Reel and TC to link.
John
-
Chris,
Thanks for taking the time to write that. It helps me understand the issue better.
Here’s my continuing problem.
Imagine that two post houses have decided on a REEL ID format. Each chose to use a simple date code consisting of two digits for the year, month and day.
I’d do it as 120507 representing year, month and day (with leading zeros) because I’ve learned that putting the year field first lets me order my work by year in common sort situations such as a file listing in an NLE.
But the other guy, after decades of thinking Month/Day/Year decides to ID that same date as 050712.
Then we tell the software to make the imported Reel ID’s a big thing.
And whoops. The jobs from the first system from May of 07 (05 in the Month Field) get interlaced in the database results with ALL the 2005 jobs from the other guy (05 in the YEAR field). It’s a total mess.
The one thing databases require in order to be efficient is consistency.
We each think something like Reel IDs should be easy – because we only think in terms of the Reel ID’s that we’re individually accustomed to working with. But in the file based world – there are hundreds if not thousands of possible Reel ID formats that a piece of general purpose editing software has to accommodate.
Suddenly this thing we think should be trivial – isn’t so trivial at all.
And that’s why I imagine that when they were building X, the designers simply decided that trying to make REEL IDs an important part of the initial X construct wasn’t a smart move. They knew that at best, it would be encouraging their customers to screw up their databases every time they tried to read a card or reel that imported data in a different format into an ID field that wasn’t expecting it.
I might be totally wrong about this. But I think Reel ID that seems to trivial to handle at first – in the context of a database system – isn’t really so trivial at all. Unless you work with only ONE kind of file generation where ALL your reel names are very consistent.
FWIW.
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
-
[Bill Davis] “I might be totally wrong about this. But I think Reel ID that seems to trivial to handle at first – in the context of a database system – isn’t really so trivial at all. Unless you work with only ONE kind of file generation where ALL your reel names are very consistent.”
I think this is throwing the baby out with the bathwater. Yes, reel IDs can sometimes conflict if they’re generated by different processes, or if they’re generated by file-based cameras that have their reel counters reset, or whatever. But usually they don’t conflict, and they often end up being a very import piece of metadata in a world where file names can be changed to easily, and where offline/online workflows are still quite common.
As I said at the end of my last post, every single frame should really get a globally unique identifier — anything short of that is a compromise, including the use of reel IDs. But in practice, reel IDs work pretty well most of the time.
In the video world, footage is fundamentally independent of files. The same footage can exist in multiple files in different formats or of different durations, as a consequence of transcoding, trimming, etc. Given that timecode wraps around every 24 hours, there has to be some additional identifier that can be used to figure out what footage in this set of offline files over here corresponds to what footage in the other set of online files over there. Reel names are the standard approach to this, and Apple seems to be backing off of supporting them without having presented a comprehensive alternative.
—
Digital Workflow/Colorist, Nice Dissolve.You should follow me on Twitter here. Or read our blog.
-
[Chris Kenny] “Of course in a really ideal world, timecode would be expanded to include day/month/year, plus a randomly generated universally unique frame ID just in case a reset clock would otherwise create duplicated timecode. Plus every file-based camera should also write a universally unique camera ID. It’s silly that in 2012 we still don’t have a reliably way to uniquely identify frames on a global basis.”
I love this idea, and it’d be great to see it extended to synthetic footage as well.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
[Chris Kenny] “usually they don’t conflict, and they often end up being a very import piece of metadata in a world where file names can be changed to easily, and where offline/online workflows are still quite common.
“Here’s how we use Reel ID in a offline/online workflow. Let’s take a 3hr football game that’s assigned Reel and of course TC. Initially, due to quick turnaround shows, the entire game is made available to online (HD) and offline (proxy) systems. Once these shows are delivered the online media gets paired down to only the highlight plays, but the offline systems keep the entire game. With a workflow like this, filename/path doesn’t work, a more agile system is required. One that identifies the content in the files, not just the files themselves.
Reel also benefits LTO archive and restore. Take the same 3hr game. Imagine having to restore the entire 3hr file just to link up a few shots. In our case the “chopped up” game is now in many shorter segments (highlights and outs) so just the segments that contain the shots need be restored.
If one happens to have an LTO system that supports partial file restore, something I’m not in favor of, then the system “slices out” just the content required and assigns it a new filename. Again reel and TC would be how these files are linked.
In both cases the reel metadata should be embedded in the media and need to survive this “chopping/slicing” process, thankfully QT Reel/Tape does.
Now with typical digital acquisition with many camera start/stops one doesn’t have long media files. The exception being lengthy interviews and live events. Ether way data granularity is an issue with archive and restore and Reel/TC can help.
John
Reply to this Discussion! Login or Sign Up