playing with X demo. effect keyframes???

> Alexa naming is actually pretty logical

Logical, yes. Filmmaker-friendly? No. Scene/shot/take numbers are the way to go. Mag number doesn't mean anything except for the technical aspects, media management. A lot better than Panasonic P2 data, but still impossible to use once your'e actually in the creative mindset (ie. trying to figure out how many takes of 01-02A were shot). My life was further complicated by the fact that they did an insane number of series takes, something like 22 in one clip, and the AC completely blew the notetaking process by sometimes assigning a separate number to each moment in the series...and sometimes not, and by not slating every camera take.

I digress, of course...that is neither the fault of NLEs nor the camera designers, but I wonder, is it impossible to control a tapeless camera's file-naming scheme?


www.derekmok.com

> ... but I wonder, is it impossible to control a tapeless camera's file-naming scheme?

Yes - at least for the user. It's too deep inside the cams construction.

The options are to store user data inside a file or with an additional file. Both options may be good or not. They require that the NLE (or a 3rd party app) allows to read these data. In case of a 3rd party app it has to translate those data matching the NLE.

We use a custom app which takes scene/take from the audio recorder and additional info from P2 for example to create clips with metadata which make sense. Same with Alexa or h.264 files. This workflow requires TOD TC (or LTC).

-Andreas

Some workflow tools for FCP [www.spherico.com]
TitleExchange -- juggle titles within FCS, FCPX and many other apps.
[www.spherico.com]

>Logical, yes. Filmmaker-friendly? No. Scene/shot/take numbers are the way to go.

Not exactly. That's only for narrative. It's quite impossible that the camera guy logs the shot with scene, shot and take numbers in the camera, as camera inputs are usually quite clunky. I'm fine if the file name contains reel number, date and clip number. Canon DSLRs, AVCHD cameras and Panasonic P2 file names are absolute gibberish. You can't use it to track down the card, which is useful when need to re-link or re-ingest a particular clip from an archive. This becomes is a potential workflow hazard. Otherwise, logging scene and shot number in the comments column in the NLE is fine by me.



www.strypesinpost.com

> Not exactly. That's only for narrative.

Nope, for commercials as well, and music videos. Any scenario where multiple takes of the same shot are done. The only situations where the numbers don't matter is documentary (and all event shoots), where takes don't repeat the

> It's quite impossible that the camera guy logs the shot with scene, shot and take numbers in the camera, as camera inputs are usually quite clunky.

Yes, they are. But in this day and age, is it impossible for somebody to develop a professiona camera that can interface with an iPhone, a laptop...anything with a keyboard to accept a file-naming convention? Or just a simple USB slot to accept a computer keyboard. It's just text, after all. Or, just put an underscore _ between mag/card number and clip number. A simple visual solution that helps find things much faster.

Anybody who says randomly generated text or "39A-1" (where the letter represents the shot -- I think the American Cinematographer's Handbook actually insists on this) is enough for editorial, claiming they are as good as Scene/Shot/Take numbers, I would refer them to a film like Jackie Chan's Dragon Lord, where 2900 takes were done of a single shot. The alphabet system would have fallen apart even before one per cent of the takes were completed, and with 2900 takes in the system, you start losing more time plowing through mountains of randomly named clips than if the AC could have spent two minutes on set plugging in a keyboard to the camera and inputting a name for that shot.


www.derekmok.com

>with 2900 takes in the system, you start losing more time plowing through mountains of randomly named clips
>than if the AC could have spent two minutes on set plugging in a keyboard to the camera and inputting a name for
>that shot.

My impression is that production guys like to shoot as quickly as possible, preferring not to touch anything related to file naming until they load/unload the cards. In fact, usually productions are happier to hire assistant editors to sort out the footage in post. Of course, we don't always get assistants. In fact, nowadays I don't even get scripts. However, I prefer not having a script than to have a badly written one.


>Nope, for commercials as well, and music videos.

I don't usually refer to log sheets unless it's a corporate video, and I need to know which are the client's good takes, but point taken. However, why not input the data somewhere else, like in a batch list? One thing that I kinda hated with tapeless formats is that I can't batch capture from tapeless formats off a tab delimited text file.


>But in this day and age, is it impossible for somebody to develop a professiona camera that can interface with an
>iPhone, a laptop...anything with a keyboard to accept a file-naming convention?

Aside from time delay (3-7 seconds to input the data per take), there is also the issue of bulk if cameras came with keyboards. A wireless connection may take a while to establish connection, so that's even more seconds wasted. That's not to mention the chaos on location. I've heard of camera operators who refuse to even carry a lock it box.

I think Andreas' solution is pretty neat. ToD and metadata can serve as a bridge. I haven't seen an app for that, but it would be cool if all the AD needs to do is to look at his watch, and fill in the time, scene and shot description, and the app will eventually automatically link up that data and marry them in the NLE. So, you feed that little text file of a log sheet that the AD was filling up, run it through an app, and it will sync up batches of rushes to log notes, via XML, reel name and nearest time input. Resolving conflicts could be nuts, also, it may be troublesome to get it to work with all the different NLEs.



www.strypesinpost.com

> My impression is that production guys like to shoot as quickly as possible, preferring not to touch anything related to file naming until they load/unload the cards.
> In fact, usually productions are happier to hire assistant editors to sort out the footage in post.

And I would have said the same thing with RED, AVCHD and even DSLR footage. I used to be the guy telling the producers, "Let the DITs have some breathing room and do the backups only; let editorial handle the ingest". Because those formats used to require an ingest process where naming could be done according to computer-literate editing conventions, so we don't get stuck with crappy camera naming conventions. But now, with formats like the Alexa (which are plug-and-play, files are editing-appropriate right out of the camera), we're in uncharted territory. Hence my original challenge: Even if we can edit native...should we? It appears to me that this approach is still young enough that we haven't encountered and prepared for all the pitfalls that can arise, say from a four-year documentary process.

> Aside from time delay (3-7 seconds to input the data per take)

I'd say it's worth it. Second ACs take that long to wipe the slate and write in something new. Also, audio recorders have been able to take a prefix on file names for years -- eg. Scene/Shot number don't change until manually adjusted; Take numbers automatically update when recording is stopped. We're really not talking about anything too different than what's already in the camera.

> you feed that little text file of a log sheet that the AD was filling up, run it through an app, and it will sync up batches of rushes to log notes, via XML, reel name and
> nearest time input. Resolving conflicts could be nuts

Great idea in theory. Basically automated script supervision. In practice, it needs to have some sort of safeguard to prevent human errors, and wholesale errors that may screw up the entire list in one go. And the database needs to be saved and backed up in real files like XMLs, and it would also need to be updatable because on-set organization is sometimes insufficient, and also because editorial's needs are 10 times larger. And of course, with something like this, producers will increasingly want to take control of even the assistant-editor stage, which can be a real slippery slope. Imagine now, the producer only ingests one take of a certain shot, chosen right at the shooting stage, and doesn't even let the editorial department look at all the takes.


www.derekmok.com

In these days of Pluralize doing things that would have once been considered magic, syncing up a timecode/TOD text/XML log of scene/take/slate/whatever with a bin full of similarly timecoded tapeless files doesn't SEEM like it should be too hard. But then I've never written any code.

ak
Sleeplings, AWAKE!

>And of course, with something like this, producers will increasingly want to
>take control of even the assistant-editor stage, which can be a real slippery
>slope.

Nah. They would have done it a long time ago. I don't see how log sheets or an xml parser will make too much of a difference. It's not there to import takes, but to marry log notes with footage.



www.strypesinpost.com

I also hate it when you've got multiple DSLRs at a shoot and they come back with cards that are full of identically numbered files just by coincidence. Sure, you can use Automator to quickly add a _b to the end of all the b cam files, but why should you have to? Can't we even have some kind of programmable header name that goes on at the start of a shoot, like Karratha_A, Karratha_B etc?

It would certainly help when you get those notices that clip MVI_4755 is missing and you've got ten terryabytes of drives full of MVI clips. Before you say it Derek, yes I could find it because of my file and folder structure naming conventions lol, but some others I'm sure might not be so organised.

> Before you say it Derek, yes I could find it because of my file and folder structure naming conventions lol, but some others I'm sure might not be so organised.

And that's not good enough even if you're organized. FCP does not go by volume structure, it goes by file name. While it is possible to figure out the original disk location of a file, it takes forever plowing through ant-sized text. Unfortunately, today's tapeless approaches means that our ability to organize folder structures is severely limited, because we have to keep the original card structures, but that's why the ingest stage is so desireable -- you can make it so that of the 50,000 files you're using to edit, the video clips are all in one folder, or just two or three.

The best way to organize footage is still the old tape-capture way: One folder to target as the scratch disk, and a maximum of one folder per external drive per project, for time-coded batch-listed clips. With this system, even if 4,000 files go missing, you choose one disk location for the reconnect and you're done. And if Media Manager goes haywire, gathering clips by hand (eg. for streamlining after the edit is done) is also fast and easy, instead of navigating through 100 discreet folders for clips that have the same names but different content.

I did a commercial in August that was like this. Arri Alexa, ProRes 4444, and the on-set DMT was also the colorist, an advantage. However, because he kept a set of the clips and brought it to the lab, I didn't have the freedom to rename anything, and then after they did the colouring session on the Da Vinci, they tried to name the clips the same as the original offline clips because they thought I could reconnect directly from the offline Sequence, but the reconnect didn't recognize the new colour-corrected clips, so we ended up having to do manual conforms with three sets of clips that have identical names but different content. Clips had to be reconnected one at a time to make sure they go to the correct folder, and it was at that point that I was glad I was editing two 30-second spots (with 40-second versions) rather than a half-hour show.

> Can't we even have some kind of programmable header name that goes on at the start of a shoot, like Karratha_A, Karratha_B etc?

That's what I mean.
Actually, in my opinion, the ideal general catch-all prefix would be: Day 01 Card 01 [Clip Number], with the Day # and Card # being customizeable, or [Today's Date] Camera 01 [Clip Number]. One of the biggest mistakes I've seen from inexperienced camera operators is that they get the Day # or overall Card # wrong, at which point you have volumes that are called the same but have different contents, the deadliest mistake of all. "Karratha" is still not good enough because...which "Karratha"? Is it B-roll or is there an important interview there? Or is it historical footage? But the above system would work for any shoot, because card numbers get reset at the beginning of every shoot day, so it's easy to follow.


www.derekmok.com

And date and card number alone wouldn't work for a lot of production houses I work for because they have several crews out at different jobs on the same day and they might be thousands of kilometres apart, so setting card numbers would get confusing. I think if it could just be something you could set up before shooting, and each company could choose exactly what that would be, it would be a huge improvement.

Especially when, months later, you need that shot of a specific item that you know you took for a certain company, 'was it on the 13th? Maybe the shoot we did there later, the 28th? I'm not sure, try looking in the folder of stuff that we used for the short promo. Pretty sure it wasn't in the in-flight version..' and so on.

Hundreds of thousands of shots, all with the potential to be called MVI_5672 or even 00_0002_2012-08-29_081306 is not funny or fun.

So here again what we do (it's a custom solution and requires TOD TC, some discipline on set and some investment - and it works for FCP and somehow with PPro CS6 - and it's dual sound always)

Using DSLR there are Lockits which provide a TOD LTC to one track of the audio
Using P2 cams with TC In, they are just synced with the HDR
Using P2 cams without TC In it's the same as with DSLRs
Alexa always can be synched with the HDR

The audio guy always is responsible for scene/take/note and comments. It's easy cause the HDRs do have a better to use counting system. Not for file names but inside the metadata (P2 also has, but the camera operators don't want to use it). They also have an iPad app which allows to insert metadata on the fly.

So for example you got a P2 card.
We use the MXF4mac component to have access to the files immediately.
Probably it's named "No Name"
There is CONTENTS -> CLIP, VOICE, VIDEO, PROXY, ICON, AUDIO and LASTCLIP.TXT.

On our side we are only interested in CLIP (which contains the "side car" XML), VIDEO and to a certain extend in AUDIO
So VIDEO will contain all the ugly named MXF files
00063D.MXF
0005CY.MXF
0004GE.MXF
0003H2.MXF
0002LA.MXF
0001F1.MXF
...
CLIP will contain the same file names but with XML extension.

AUDIO contains the same file names extended by channel counter.
00063D00.MXF for example.

Now you got an audio card
It also has a name, lets say "12Y05M31"
Inside there are a lot of BWAVs (in our case multiple mono files) with ugly names as well.

Now they use my sync app.

Drag the video card(s) to the video section, the audio card(s) to the audio section.
The app does a preflight for all available metadata and timecodes. Also different cameras will be retrieved and an angle will be assigned to them as well as an possible TC offset.
The second step creates referenced movies with merged AV renamed movies based upon TC information along with an XML.
The XML contains several bins:
Multiclips
Merged and Synched Clips only
Unlinked files - with sub-bins for video, audio for each used card.

So the "0001F1.MXF" for example shows up as clip "310517-15-1" with is "scene - take - angle" other metadata are distributed either to their matching columns or merged into the different comment fields.
The beauty of FCP with XML is that you can write QT metadata to the XML which are automatically inserted by FCP when the file loads. Means once you got the merged clip you can open it in any project and it will show you scene/take/note cause the audio iXML hidden in the file will be recovered by FCP in any case. The other data as well, but they don't make their way into the interface.

Using Alexa
Same as above, but not that complicated folder structure.
And no MXF4mac needed.

Using DSLR or P2 without TC in (using LTC)
This needs another pre-flight and the user has to know that these cards/files use LTC.
This run will search for the LTC and analyze a very fewseconds at the beginning of every clip to insert a normal TC track.

The whole thing takes maybe two minutes for an one card combi or a few more minutes for several (a day's production).

The reference movies can be converted in the background to self-contained while you are working with the ref movies.
The advantage of creating these ready to use files is that FCP doesn't have to take care what belongs where in the internal links. This makes the work faster and way more safe.

There is an old screen capture without audio here (I unfortunately deleted the audio when reviewing it)
[www.spherico.com]

And here is one of the ancient days of FCP
[www.spherico.com]

-Andreas

Some workflow tools for FCP [www.spherico.com]
TitleExchange -- juggle titles within FCS, FCPX and many other apps.
[www.spherico.com]

Jude Cotter Wrote:
-------------------------------------------------------
> And date and card number alone wouldn't work for a
> lot of production houses I work for because they
> have several crews out at different jobs on the
> same day and they might be thousands of kilometres
> apart, so setting card numbers would get
> confusing. I think if it could just be something
> you could set up before shooting, and each company
> could choose exactly what that would be, it would
> be a huge improvement.
>
> Especially when, months later, you need that shot
> of a specific item that you know you took for a
> certain company, 'was it on the 13th? Maybe the
> shoot we did there later, the 28th? I'm not sure,
> try looking in the folder of stuff that we used
> for the short promo. Pretty sure it wasn't in the
> in-flight version..' and so on.
>
> Hundreds of thousands of shots, all with the
> potential to be called MVI_5672 or even
> 00_0002_2012-08-29_081306 is not funny or fun.

Jude,

I can feel your pain.
But there is something one could do - maybe;-)

So every card has a unique serial number. So serial numbers can be assigned to a crew at a certain day and time (as long as they have set the date correctly). This will give you (using a data base) access to billions of clips with ease.

-Andreas

> And date and card number alone wouldn't work for a lot of production houses I work for because they have several crews out at different jobs on the same day

Yeah, but in those cases, wouldn't you separate the jobs by giving each one a master folder?

Even I'm not quite OCD enough to prefix every single clip on every discreet show with the show's title. That really bogs down the visual organization of files -- the same reason why adding track numbers before MP3 file names is a bad idea; it homogenizes the files so that they all look alike.

Another solution to this is to add one simple, short prefix. If there are 12 crews shooting today, then Crew #1 gets the prefix "T01_101312_C01_Clip01" (Team 01, Date, Card 01, Clip 01), Crew #2 is "T02_101312_C01_Clip01", and so on. A short prefix would be enough to ensure unique names, yet not screw with file management.

> Especially when, months later, you need that shot of a specific item that you know you took for a certain company, 'was it on the 13th?

That's a bit of a lose-lose situation, isn't it? Clients and producers already complain sometimes that my file names are too long, because on every exported movie file I insist on at least part of the project name, version number, date and, on small screener files, an "h264" suffix, plus frame size and bit rate. They don't understand that 12 months from now they could have 120 different projects in the system and need to look for one single movie file. ISCII codes work great for a unique prefix, but it's a lot faster to search for "verizon" than to look up what code was used for a particular spot.

I can't imagine doing that kind of file name on editing files. Looking at a whole screen filled with the same prefix creates the same problem as having no prefix at all -- you get eye rot and tire out quickly, affecting other parts of work.

I think in the above situation, I'd rely on a project file. Or a database with metadata embedded, notes that are searchable. If the client is referencing a specific shot, then those long movie-file export names would allow me to find the version number quickly. It's just not practical to try to embed shoot-context information into file names.

> Using Alexa
> Same as above, but not that complicated folder structure.
> And no MXF4mac needed.

That was one advantage -- no ingest means clips could be separated out and reorganized, perhaps? I was apprehensive about reorganizing the clips on that Alexa commercial because of my "don't mess with tapeless" mentality, but in retrospect, it probably would have simplified things if I could have had one folder for all the clips from the offline, one folder for all the clips from the first CC session, etc. Anybody see any pitfalls, especially in the long run? I just hate having every mag be its own folder -- such a waste of drive real estate (in terms of organization neatness, not storage space).

I haven't kept up with P2 as a format, but given how wasteful it is (for storage space, cost of the cards), I would've thought it would have died out by now. DSLRs are not a viable replacement for pro video cameras, but P2 in particular has just been expensive and inefficient in many ways. $600 for 32GB -- good Lord.


www.derekmok.com

I have one client who shoots HDV to card and his clips come in with a clip number, date and then a seemingly random number, but they at least organise easily by timecode so I can see the grouping. It's mostly the 'this is a completely arbitrary number which might be exactly the same as another clip in your current project' ones that really annoy me.

Bring back the days when you got to write 'Jack G IV 121029' and 'Warehouse Exteriors'.

Oh wait, that meant hours of sitting there doing the capture, figuring out what it was and doing the naming as it went along. It's six of one, half a dozen of the other on annoying really.

> Oh wait, that meant hours of sitting there doing the capture, figuring out what it was and doing the naming as it went along. It's six of one, half a dozen of
> the other on annoying really.

Capturing is far preferable. I always have to calm down clients and producers who want to rush the first part of post-production. They always come around to my way of thinking when the deadline comes and I'm able to nail late-stage problems in 10 minutes. Bad prep (and tapeless laziness is bad prep) causes delays that keep coming back; time spent to prep everything properly is killing the problems before they get a chance to be born.


www.derekmok.com

I do agree that bad prep gives you headaches almost without fail, but the tapeless workflow in PP means you copy a card to the drive, link to the card and start work. It really saves hours and hours of work and so far it's been rock steady EXCEPT when things get moved or opened from a new workstation. Then it's back to 'not fun at all'.

We do have some projects that are up to 23 episodes and the ones that haven't been kept clean - ie all 23 episodes are linked inside the current episode - are getting a bit heavy to work with, but we're also running off storage that's so full its about to blow. So I'm going to reserve judgement on how PP handles large projects until after that's sorted.

> EXCEPT when things get moved or opened from a new workstation.

Now that's a problem, isn't it? Especially since editors are expected to move all over the place now. The great thing about the old FCP's file management is, once you understand it, it's very versatile and user-customizeable.


www.derekmok.com

It's absolutely a problem. It's similar to FCP 7s setup though. It's just that if someone moves the files into a folder you don't know the name of, and you have to find MVI_5710, you're not happy.

Jude,

Are you using Prelude?
I can't make any real sense of it.

-Andreas

Some workflow tools for FCP [www.spherico.com]
TitleExchange -- juggle titles within FCS, FCPX and many other apps.
[www.spherico.com]