In early September, I was approached by an old colleague of mine who had just returned from directing a feature film that was shot in Italy over the course of the summer. Just coming off a two year feature documentary, I was in the market for my next narrative project and this came at the right time.
After some negotiating with my company, we worked out a deal where I waived payment on the project in exchange of providing two full billable weeks of editing time through my employer, and all extra work was to be done off hours.
Although the director asked to cut a few scenes himself, I knew I'd only be able to execute such a hefty project under these constraints with the help of an additional editor. So I called on a buddy of mine who had availability in his schedule to help take on part of the responsibility of the workload and essentially push through work in half the time.
Once the team was together, I manually synced and organized all of the raw material myself to ensure it was organized properly. There were a few extra pickup days scheduled during the first few weeks of post production, so I worked on all of the AE tasks, prepping the project as they finished principal photography. As new footage came in, I would add it to the project and kept it managed across all the team's drives.
I'm still acting as the post production supervisor of the film so I'm helping see it through to the end, but the majority of my work is done and I felt like now was a good time to reflect on the project as a whole, while it was still fresh on my mind. There were a few major personal triumphs in this project. The first was the big reason I committed so early to it and proved to be a successful experiment.
I don't speak Italian. At. All. I took an Italian cinema course in college, and studied a handful of semesters of Spanish which, as a romance language, gave me a basic aural guide to understand some root words. So this provided grounds for an interesting experiment that put Walter Murch's first commandment of editing: cut for emotion. Could I cut a scene solely based on performance, inflection, cadence and how the takes made me feel? The short answer is YES.
To avoid a trainwreck of committing to a project I could potentially fail at, I chose to tackle this language barrier head on and the first scene I cut put this to idea the test. I chose a pivotal scene that sets the plot in motion that was sure to have enough meat in it to play with and put my theory to the test.
|Francesco tells his wife of a startling encounter he had earlier in the day.|
While some of the film was shot improvised and loose, for the most part they followed a basic
outline and script for each scene that through repetition, I could learn the beat breaks of the actors in each take and then could really play with punctuating and accenting the emotional notes given in each performance. Even though it was the first scene I cut, it ended up being one of my most favorite of the film. I think this scene in particular made me tune into the electricity of the performances, and by stripping away things like factual information provided by the story, or even the added complexities that comprehending dialogue can add to the long list of decisions an editor takes into consideration in each cut, it sets contrivances aside that we typically try to prop up, and it simply puts emotion in the driver's seat. Watching the director's reaction to the scene once I was completed with the initial rough really invigorated me to push this project and "plus it" in every way I could.
This wouldn't be so difficult if we were all operating under one roof, but we were each in remote locations. The solve for that was creating a centralized project, and as rough edits and additional footage would come in from the director and other editor, I would update my project with that that new material. I would then report where that material was filed, and on big milestones of the edit, would share that project with both the director and other editor. This "master project" would then become their new source to work from.
The second big hurdle to solve was the actual collaboration process in moving each edit forward. We used a mixture of online screenings of rough cuts through the wonderful review tool, Frame.io, as well as face-to-face sessions where we'd work through scenes together. By the time we were ready to build the first full assembly edit, my second editor's contract had been fulfilled and it was on to refining the edit with just the director and me.
At which point, we blocked out several full day edit sessions, working through the key scenes first, and then circling back to the beginning and working sequentially.
I've been involved in large scale projects in the past that either didn't have a post supervisor managing the flow of assets, a collaboration plan, or any sort of guidelines in managing the material. They quickly turned to disarray, files would go missing, confusion would come up as to which sequence on which project was the newest version to work from. Just hours and hours of time wasted and all kinds of headaches. So I made sure to run the collaborative process sternly to make sure that didn't happen. And for the most part, we succeeded. Things occasionally fell through the cracks. A temp track wouldn't get shared, or temp sound effects would get organized a little differently between each person's machine, but the problems were minimal enough that we could spot them right away and squash them out. So for that, I'm proud we were able to set that plan, execute it, and see the benefits of that system play out in real time.
Because I had to manually sync all of the footage myself, and the crew ran cadence spoken solely Italian, I took it upon myself early on to learn the cadence and set terminology in order to inform my editing decisions. I kept a little notes sheet next to me in order to help with that process:
Color coding is nothing new to my process, but I’m just continually amazed at how well it works. My process typically goes as follows. Once the material is synced, I’ll duplicate my sequence and label it as the “Paredown”, at which point, I’ll parse away all of the pre-roll and false takes, and the remaining material goes through a color coding process. This gives me two things: A firmer knowledge of every take by watching through everything, it also gives me an impression that I can reference later on and save time without having to go back through every clip. My color code typically follows a stoplight’s colors. Red (or Rose as Premiere calls it) is typically useless material. It’s a pass for me to skip looking at, but still exists on my timeline if I need to get creative in solving a problem. Yellow (or Mango in Premiere’s world) is passable material. It may have great moments, but there’s something that’s holding it back from being fully usable. Maybe it’s a technical flub, or the talent misses their mark, or they stumble on a portion of their monologue. But there is still good material in it to work with. Green (or forest in Premiere), is good clean material. Lastly, I break the stoplight code a bit and use blue (Premiere’s cerulean color) for B-roll, inserts, MOS material, or sometimes I use it as MUST USE material.
|A typical scene assembly after using the color coded paredown of footage. (I realize the music track is unlinked, deal with it.)|
I don’t know many editors who use this regularly, but any AE, or collaborative editor I’ve worked with, I’ve taught them this trick and they’ve come back to me sometimes years later to tell me that they’ve adopted it into their own process.
Some editors solely use markers with little notes baked into the clips. If that works for you, do it. I usually do that as a second layer of defense on large form projects, when I have the time and liberty to make those extra notes. I find that most useful in long interviews to help earmark subject changes in extra long takes. For me though, it’s bitten me in the ass (especially when I used to cut primarily on Final Cut), that meta data doesn’t always stick to the metadata of the clip, but instead is saved locally on your machine. So when you’d share the project with someone, all of that work would be lost. Thankfully, Premiere’s better about that, and if you’ve got the ability and an AE, their application Prelude does wonders in expediting that process before even firing up Premiere.
Dynamic Health Chart As A Tool:
Setting a schedule and enabling all team members to stick to it (as best we can) was crucial to pulling this project off and not letting it go long tail. I looked into ways we could kind of keep tabs on the progress of the project as a whole without having to hit the breaks and talk it out every time a new scene was accomplished. There are online system organizers and project trackers like Trello that could be used, but we just needed to get the ball rolling and I didn’t want to have to have everyone sign up for yet another account just to use the service. So I developed this handy tool that gave every team member the status of the project and where everyone was working.
I called it the Dynamic Health Chart, and it was created as a Google Sheets that everyone could see and update live. There’s something just satisfying about having a checklist and crossing things off one by one. It makes you feel accomplished and instills vigor to keep going. I liked this chart for that very reason. It served as a very visual, complex checklist that we could see our progress on any given day at any given time.
Each scene is plotted out in story order. Under each scene there are five cells that show if the material has been imported, synced and verified by the post super (myself), what editor was assigned to the project, if the rough edit has been completed, what current version the scene is on, and if it has been placed in the master timeline or not. Nixed scenes were still left in the chart but blacked out as “dead content”. I then set up a color code to mark the status of each cell. (Sticking with the simple stoplight code that I use for parsing material in my timeline), red is waiting to be worked on, yellow is being worked on, green is completed, and then breaking away from that, dark green is a lock, and magenta is held up (either waiting for new content from reshoots, shared project assets, or is simply waiting for review).
See nearly 4 months of progress in a few seconds:
The Editing Time Quotient
I may be a little more meticulous at keeping track of my hours than most editors, but when the majority of time needed for a given project is coming from my free time, I want to use it efficiently and try to keep myself on track. Our office uses an hour-tracking tool called Harvest, which we manage per project. In the past it has helped us keep track of scope creep and profitability. Each project is broken out by basic phase:
- Hard drive management/project organization/AE work
- Color Grading
- Sound Mixing
For this instance, I used solely the editing data from previous narrative projects as a baseline estimate for amount of time per scene. The next thing I did was calculated total runtime of footage per scene. To start, there were 52 scenes in the film (four were off the bat nixed, and a few were eventually rolled into a bigger sequence with intercutting). Some scenes only had 5-6 minutes of raw footage, others had close to a couple hours. I took all of that information and built a total hour estimate for what I thought we’d need to collectively edit the project and get it to picture lock. We then figured out how many hours each of us could put into the project per week. I then broke out the Dynamic Project Health Chart and assigned each editor their scenes based on the proportion of time they could contribute in total against the total projected hour estimate.
I believe initially I had projected out the project taking somewhere around 320-330 hours to picture lock and we ended up finishing in 346. For going past the schedule a few weeks, an additional 16 hours isn’t too far off. That’s about a 5-8% offset.
And all the while, we were logging our hours spent working through each scene. So what did I do with this data? I built a spreadsheet (of course), that logged the scene, the editor, the estimated runtime of raw footage, the actualized time it took each editor to complete the first rough of the scene, the runtime of the edit of that scene and the true gold nugget: the efficiency quotient that’s calculated per minute of raw footage. This gave me an accurate estimate down to the minute of how long it was taking to sift through and edit every minute of raw footage. I could then average these per editor and now that I’ve begun this log, I can more accurately project out future narrative projects.
While I still have about half of the logged hours to crunch into this spreadsheet, at last count I was hitting about 650 minutes per hour of footage, or 10.97 minutes spent per minute of raw footage to get it into a rough cut.
At first I was a little embarrassed to reveal how long it actually takes me to get through footage, but I came to realize that number is truth. It’s the actualization of what it takes for me to thoroughly vet and familiarize myself with the material and gain enough confidence in making selects and assembling them together. It’s just the facts. And for future work, it means I can justify our hourly estimates when building out budgets for post production.
For someone who doesn’t consider myself the most organized post production super/editor, this is one thing I am passionate about and proud of to have developed. I’ve gotten to roll in this quotient into the estimate process of approximately a half dozen projects over the last couple projects and it’s been surprisingly accurate. Occasionally there’s an outlier of a project that just kind of cuts itself because the material is just so dialed in, but in working on averages here, there are also other projects that take a bit longer than the quotient.
Keep in mind with all of this though, there’s a variable to this quotient that can’t be calculated: the feedback and fine tuning process. That’s why the quotient just is calculated up to the rough cut, because that’s when the project is in my control. Once it turns into a collaborative process working with the director/producers and we begin refining the project, it’s a wild horse that can’t be tamed. The best you can do in that phase is to have a set expectation on the number of rounds of revisions, or in the case of most narrative work, just have a clearly communicated set of boundaries with the director. “I need to be done by 6pm tonight.” “If we want to have picture lock by the end of the week, we should probably try to get in one more full day session together before I build and organize the master timeline.” Statements like that can just help navigate the sometimes very gray and ethereal looseness that occurs during this phase and it helps make everyone accountable for making set deadlines.
I’m sure I will continue to refine the quotient and the process, but for now it’s a unique and valuable tool that gives me a pretty great visibility into actual time needed to pull a project off.
A Project Worth Doing:
As with every project I take on, there's always a rich number of takeaways that I can grown from and implement into the next one. This one is no exception. I've spoken with many editors who would turn down projects like this. It's too low budget. Too small. It won't help their reel. It doesn't further their career. They're waiting for that whale of a project that they know will land them an Oscar nom. That's fine if your work is at that caliber, but I bet it's not. You need to be conditioned, and build your craft as a discipline. The old adage is that you need 10,000 hours to master a craft. I think realistically it's something closer to ten times that number, but my philosophy through my entire career has been aimed at committing to being a life-long learner. And this project was just right for me where I am in my career. It provided just the right amount of challenges, the stakes weren't too high (i.e. budget scale, the schedule, the team's working relationship, the general demands of the project). It was just the right sized bite for me to take and enjoy through the process, and to walk away being just a slightly different, more honed human than I was going into it. Because what I've learned is that even the best projects are going to have their problems that you will need to be able to have solutions prepared for, far before you're even asked for them. And the only way to confidently suggest and enact those solutions are to have given them a "trial run" on a previous project; to understand and speak to how that given solution could solve the problem in front of you.
Post a Comment