The cut is not where you think it is
A vanish that lands on the exact frame the object leaves reads as a glitch. Moving the seam back by about 800 ms made every test cut believable.
The first version of PoseCut joined two takes at the obvious place: the last frame of take one, then the first frame of take two. Frame-accurate, mathematically clean, and it looked wrong every single time.
Not wrong wrong. Nobody watching could tell you what had happened. They just said it looked fake, and then apologised for not being more helpful.
What people are actually watching
When you set up a vanish, you are not filming an object. You are filming a little piece of theatre with three beats: the setup, where the viewer registers what is in the frame; the hold, where nothing happens; and the reveal. The trick only works if the viewer has finished the first beat before the third one arrives.
Cutting on the exact frame the object was last present collapses the setup into the reveal. The eye has not finished reading the shelf before the thing on the shelf is gone. The brain files that under edit rather than under magic, because a change that fast is not something the physical world does — it is something a video player does when it drops frames.
The number
I sat with a stack of test footage and moved the seam backwards a frame at a time, which at 60fps is about 17 ms per nudge. The window where it started working was wide and soft, and it centred somewhere around 800 ms of held, uneventful frames before the cut.
Under about 500 ms it reads as a stutter. Over about 1.2 s the shot goes slack and the viewer’s attention drifts off the thing that is about to disappear, which ruins the reveal in the opposite direction. Between those it reads as magic, and 800 ms sits comfortably in the middle.
It is worth saying plainly that this is not a discovered constant. It is a number that worked on my footage, at my pace, in shots of a fairly ordinary length. But it was consistent enough across clips that I stopped treating it as a per-clip decision.
Half a second of nothing is what makes the next half second look impossible.
Why the app needs to know this
You could leave this to the person editing. Give them a timeline, let them drag the seam, and let them discover the 800 ms on their own over a few weekends. That is what every general-purpose editor does, and it is a defensible choice for an app that does not know what your cut is for.
PoseCut does know. Every project in it is the same shape: takes of the same framing, joined at seams, where the interesting event is the discontinuity. So the trim handles do not start at the raw ends of the take. They start where the cut is likely to want to be, and dragging them is a correction rather than a search.
The rest of the work was making that default invisible. If you never notice that the app moved your seam, it moved it to the right place. If you do notice, the handles are right there.
The one case it gets wrong
Fast action across the join — someone running into frame, a ball entering — does not want the hold at all. The motion itself covers the seam, and 800 ms of stillness in front of it just makes the shot feel like it stalled before something happened.
That is what the Shake transition is for, and picking it drops the hold back to near zero. Two defaults for two kinds of cut, and one tap to say which one you are making.