Never Say Cut? Part 4

Never Say Cut? Part 4

When we last left the project, it was in crisis. The speed changes on clips didn’t make it through color grading properly because during production there was no urgency to stop the recording. As a result, very long clips were created.

Because the clips were extremely long, it wasn’t practical to render out fully graded original length clips. Instead, shorter clips comprising the actual frames used in the finished cut plus some extra heads and tails were rendered.

There were several shots in the edit that ran at normal speed, then instantaneously cut to a faster speed, then cut back to the normal speed of the same clip. The effect was seamless. The cut from and to the normal speed footage was match framed.

When I compared what I had to the offline I had three problems: 1. The clip was running at a slightly different speed; 2. During the fast section, the frames actually used were different; and 3. The cut back to normal speed wasn’t matched—there were two identical frames.

Given the time crunch I was under, I first tried to deal with the speed changes. In one clip, the original speed was 180 percent, but the XML I received from color showed 179.7 percent.

I had seen this happen before but didn’t think much of it—I wrote it off to translation between two different pieces of software from two different manufacturers. So I went through the timeline and changed all the speeds back to the proper setting.

Unfortunately, changing the speed didn’t fix the problem in every case. Doing a frame-by-frame comparison, I could see different frames from the offline. Then I tweaked the in-point of the sped-up clip. That fixed the first part of the clip, but not the later part. Also, the last frame of the sped-up clip was identical to the first frame of the normal speed clip it was cutting to. This meant there was a repeated frame at the cut point. The seamless effect that was present in the offline was a stuttering mess in my online.

What was the problem? The clip had the same speed now, so it should match. As it turns out, it all came down to how edit software calculates what frames to show when clips are sped up or slowed down.

Think about a simple case of increasing the speed to 200 percent. A 100-frame clip will be displayed as 50 frames. But which 50? Will the sequence show the first frame and then every other, or the second frame and then every other frame? Let’s assume that it shows the first frame, then the third, and so on— all the odd frames. But if the color graded trimmed clip actually starts on an even frame, then 200 percent shows all even frames.

(Note that edit software usually bases the calculation starting at the beginning of the clip, not the in-point. So just trimming a frame in the timeline won’t fix the problem. You have to trim the actual movie file to make it work.)

That’s just a simple speed change—100 percent to 200 percent. But imagine if the speed was 120 percent or 230 percent or 480 percent. Instead of every other clip being dropped, you might play two frames, drop a frame, play one frame, drop one frame, play two frames, drop two frames, etc.

Never Say Cut? Part 4
The bottom row of timecode represents an original clip running at 160 percent speed. The rows above are trimmed clips at various start points. The numbers should all match.

Now imagine there are 20 of these effects, all at different speeds. Finally, imagine that four of the effects are actual speed ramps, as opposed to constant speed changes.


Although I eventually found a fix that involved nesting of clips, my point isn’t about that solution. It’s about what can happen if you never say “Cut.” In this case, because it was impractical to render the color grades all to the full-length clips, trimmed clips were rendered. From these shorter clips, it was almost impossible to deliver what the offline promised.

There are certainly times when saying “Cut” isn’t practical, but I hope you might think about the impact it can have on post.