What a turnover is
A turnover is the moment editorial hands VFX an updated cut and says "this is current now." With it should come the answer to one question: what changed since the last one? That list drives everything the vendor does next - which shots to start, which to stop, which to re-time, which to re-render at a new length. Turnovers are not rare events. A show in active edit produces a new one every time the cut is locked for review, sometimes weekly, and each one silently invalidates part of the shot list you were working to.
The five things that change between two cuts
Compare cut A to cut B and every difference falls into one of five buckets. A good cut diff reports each separately, because each one means a different action:
- Added - a shot in the new cut that was not in the old one. New work to scope and start. Easy to spot, easy to miss when there are forty other lines.
- Removed - a shot dropped from the cut. Every frame anyone is still comping on it is now wasted. This is the change that costs money the moment it is missed.
- Re-timed - the same shot, but a different in/out or duration. The cut is longer or shorter, which changes the handle-inclusive render length. A shot that passed conform yesterday can be short today without a single new render.
- Re-versioned - the cut now references a different clip version of the same shot. Someone updated it, or the offline picked up a newer render. Either way the "which version is final" answer moved.
- Reordered - the same shots, a different edit order. Rarely breaks a render, but it changes context, adjacency and sometimes continuity work, and it is completely invisible in a timecode-sorted list.
Why diffing two cuts by eye fails
The instinct is to open two EDLs side by side and scan. It does not work, for a structural reason: a human comparing two lists is good at presence and bad at magnitude. You will catch that a shot appeared or vanished. You will not reliably catch that SH040 is now 6 frames longer, or that its version went from v002 to v004, because those changes look like the same line. The failures that actually cost turnaround - re-times and re-versions - are precisely the ones the eye slides past.
It gets worse when the cut is reordered, because now the lines do not even align. Two lists that describe almost the same edit can look completely different on the page, and a person given ten minutes under deadline will either declare "looks the same" or "looks totally different" - both useless. And EDLs, remember, do not carry the frame rate explicitly, so even the timecode maths you are doing in your head can be against the wrong clock.
How a cut diff view catches it
A cut-diff view does the boring, mechanical thing a person cannot: it matches shots between the two cuts by name - not by line position - and then compares each matched pair field by field. Same shot, different in/out? Re-timed, and here is by how much. Different version token? Re-versioned. Present in B but not A? Added. The reorder problem disappears because matching is by identity, not order.
The output is a categorised turnover report you can act on directly: start these, stop these, re-render these to a new length, re-confirm these versions. It turns "read two cuts and hope" into a checklist. Pair it with a conform check against the renders folder and you close the loop - the diff tells you what the cut demands now, the conform tells you whether disk satisfies it.
Where Cutlist fits
Cutlist Tracker has this built in. Drop in the previous cut and the current one - as EDL, OTIO or FCPXML, in any combination - and its cut-diff / turnover view reports added, removed, re-timed, re-versioned and reordered shots as separate lists, matched by your shot-naming convention rather than by edit order. The last cut is remembered when you reopen the project, so the next turnover diffs against the right baseline automatically.