Creative COW SIGN IN :: SPONSORS :: ADVERTISING :: ABOUT US :: CONTACT US :: FAQ
Creative COW's LinkedIn GroupCreative COW's Facebook PageCreative COW on TwitterCreative COW's Google+ PageCreative COW on YouTube
APPLE FINAL CUT PRO:HomeFCP ForumFCP XFCPX TechniquesFCP TutorialsFC ServerBasics ForumPodcastFAQ

Kinda hijacking the REELS thread from below...

COW Forums : Apple FCPX or Not: The Debate

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Share on Facebook
Bill DavisKinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 7:52:05 am

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.


Return to posts index
Reply   Like  

Sandeep SajeevRe: Kinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 8:22:36 am

When dealing with DSLR footage this is what I use:
CAMID_Mag_Date

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


Return to posts index
Reply   Like  

Franz BieberkopfRe: Kinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 2:08:05 pm

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


Return to posts index
Reply   Like  


Michael PhillipsRe: Kinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 2:20:44 pm

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


Return to posts index
Reply   Like  

John HeagyRe: Kinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 4:19:38 pm

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


Return to posts index
Reply   Like  

Chris KennyRe: Kinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 6:49:43 pm

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


Return to posts index
Reply   Like  
+1


John HeagyRe: Kinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 7:03:46 pm

[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


Return to posts index
Reply   Like  

Bill DavisRe: Kinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 7:22:23 pm

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.


Return to posts index
Reply   Like  

Chris KennyRe: Kinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 8:30:06 pm

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


Return to posts index
Reply   Like  
+1


John HeagyRe: Kinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 11:56:28 pm

[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


Return to posts index
Reply   Like  

Bill DavisRe: Kinda hijacking the REELS thread from below...
by on Oct 30, 2012 at 1:06:41 am

[Chris Kenny] "and Apple seems to be backing off of supporting them without having presented a comprehensive alternative."

Well, I actually see X's robust range and/or file renaming functions to be precisely that "comprehensive alternative" but I suspect I define that term differently than you do Tom. Not saying mine is better or worse than yours - just necessarily different since we have different needs.

I think that's different than asking the software to accommodate any one arbitrary manufacturer standard (like a RED or Alexa format ReelID) that the majority of the software's users might not have any need to ever use.

I know that someone working for a network affiliate expects every operator to be labeling things to a "house standard" and to have a similar ID structure.

But in my use of X it's extremely common for me to use a dozen or more more timeline content sources. It's not just digital tape roll-offs and DSLR and GoPro generated files, it's those plus stock video clips, , buyout annimations, H4n audio files, stock sourced still photos and Zeus knows what else.

What I'm saying is that in a well budgeted "shop" world, I totally know you want to track numbers which are consistently attached to every tape that enters your particular workflow.

Out here in the "other" world of production, it's nowhere so consistent and organized.

The big question is whether the shops need to bend in order to accommodate the needs of the wider world - or the wider world has to bend to accommodate the needs of the shops.

The lesson of FCP-Legacy - to my mind at least - is that you let the program do the best it can for the largest pool of users at first - then let it evolve to accommodate the needs of smaller constituencies as it can.

This is tough for the professional industry, I think, because in the history of video - the pros got the tools first and only afterwards did those tools "trickle down" to the masses.

FCP has always been an example of development in the other direction. It started with what was actually a very small subset of tools for DV Video editors (more "the masses" than the pros after all!) - and only evolved as a great tool for professional use over time.

And here we are again. I think that X version 1 will be a lot like Legacy version 1 in that regard.

But we'll see.

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.


Return to posts index
Reply   Like  

Walter SoykaRe: Kinda hijacking the REELS thread from below...
by on Oct 29, 2012 at 11:20:00 pm

[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


Return to posts index
Reply   Like  


Michael PhillipsRe: Kinda hijacking the REELS thread from below...
by on Oct 30, 2012 at 12:44:07 pm

A few companies have tried this - a concept of "virtual KeyKode" Where KeyKode was a unique identifier for every frame in a production. In all my years of dealing with Kodak based production did I come across two frames in the same production with the same number. Fuji film was more apt for that to happen.

The issue is settling on a format that encapsulates the identification as well as ensuring it is unique. RED cameras had this issue early on where two cameras could create the same file name till they started using the last 4 characters as a random hash. Things get complicated with formats that don't use metadata in the header (TIFF) where both historical and versioning nomenclature is contained within the name of the file. Then there are formats that can contain metadata in the header and is not used by all processes. Not to mention the fragility of just the filename on its own.

A good example is BMCC that only uses the folder containing the DNG files to be unique, but every file within those folders are identical to any other file - and there is nothing in the header to identify them after the fact. On the files I have been getting, I use a file renamer to at least take the folder metadata and apply it to the files themselves. Also, all user metadata is contained within the XML portion of the WAV file - be sure to record audio!


I digress - some of these companies got pretty far in their proposal, but the maintenance and logistics of assigning and such was too much for one company. These are one of these things that should be part of a SMPTE type effort, and probably is - haven't checked. But as with all standards, it takes years to get everyone to agree and get on board. And speaking of timecode, SMPTE should also start allowing for timecode beyond 23 hours - for production it makes sense, but for archival and post processes it would be nice to have an additional 76 hours of unique identifier in timecode as well as define a 50 and 60fps timecode - and maybe a 24fps DF, not that we need confusion, but cutting 23.976 for broadcast it would be helpful to not have to add an additional 30fps DF ruler to the UI.

Michael


Return to posts index
Reply   Like  
+1

Chris KennyRe: Kinda hijacking the REELS thread from below...
by on Oct 31, 2012 at 4:57:04 am

[Michael Phillips] "A few companies have tried this - a concept of "virtual KeyKode" Where KeyKode was a unique identifier for every frame in a production. In all my years of dealing with Kodak based production did I come across two frames in the same production with the same number. Fuji film was more apt for that to happen.

The issue is settling on a format that encapsulates the identification as well as ensuring it is unique."


Obviously getting everyone on board with the same solution is quite non-trivial, but the technical problem is pretty simple. Just generate a full-on UUID for the first frame of every captured clip, and increment it by one for each subsequent frame of that clip. That gives you unique frame IDs — just just on a given production, but globally (from Wikipedia: The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs), but they're still sequential, meaning that an app trying to figure out which of a bunch of media files contained a given frame would only have to read the first and last frames' UUIDs out of each file it was examining.

Of course UUIDs are not easily human-readable, being 128 bits long and usually represented in hexadecimal, so you'd probably still want to keep more human-friendly identifiers like reels and timecode around. But when push comes to shove, software should have a reliable way to uniquely identify frames.

--
Digital Workflow/Colorist, Nice Dissolve.

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


Return to posts index
Reply   Like  

Michael PhillipsRe: Kinda hijacking the REELS thread from below...
by on Oct 31, 2012 at 1:05:19 pm

Exactly - the format takes on the concept of what TinyURL does for long URL names. It is then up to the system (NLE or other) to interpret as needed on a per frame basis. We are seeing more and more frame based metadata where many vectors change on a per frame basis coming from the lens and motion control world with similar challenges and solutions.


Michael


Return to posts index
Reply   Like  


Walter SoykaRe: Kinda hijacking the REELS thread from below...
by on Oct 31, 2012 at 7:18:31 pm

[Michael Phillips] "I digress - some of these companies got pretty far in their proposal, but the maintenance and logistics of assigning and such was too much for one company. These are one of these things that should be part of a SMPTE type effort, and probably is - haven't checked."

SMTPE is in fact doing quite a bit of work around metadata, especially in MXF. I don't know how long this will take to actually filter into production, though.


[Michael Phillips] "It is then up to the system (NLE or other) to interpret as needed on a per frame basis. We are seeing more and more frame based metadata where many vectors change on a per frame basis coming from the lens and motion control world with similar challenges and solutions. "

And as with medicine, the first rule should be "do no harm." Don't use it if you don't need it, but don't muck it up for other systems later in the tool chain.

As I think more about how I might use reel/tc metadata for synthetic images in my own workflows, I'm realizing that it could be very useful for effects and compositing systems to allow source metadata from camera images to flow through.

In other words, uniquely identify the synthetic frames, but also preserve the source footage's UUIDs so that the provenance of the image is knowable to any software that cares. This could get pretty complicated, but it could also be very powerful.

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


Return to posts index
Reply   Like  

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Share on Facebook


FORUMSTUTORIALSFEATURESVIDEOSPODCASTSEVENTSSERVICESNEWSLETTERNEWSBLOGS

Creative COW LinkedIn Group Creative COW Facebook Page Creative COW on Twitter
© 2014 CreativeCOW.net All rights are reserved. - Privacy Policy

[Top]