The Motion Test Stutters in Preview. Check Playback Before Changing the Edit
The Motion Test Stutters in Preview. Check Playback Before Changing the Edit
Take a hypothetical that behaves like hundreds of ordinary ones. A two-second motion study: 48 frames at 24 frames per second. A latch swings down and contacts a strike plate at frame 30, and a click is placed at frame 30 so the sound and the contact are meant to be the same moment. Played in the authoring preview, the fall stutters — a few positions, then arrival — and the click sounds a beat after the contact it was placed to mark. The tempting response is to drag the click two frames earlier and render again.
Slow down first. A preview is a review tool with its own settings, and it is allowed to skip frames, show them soft, or hand them over unevenly. The lurching fall and the late click can both come from the same skipped frames, which makes the preview a poor witness to rhythm — and a poor witness to almost anything else — until you know how it was configured for the playback you just watched. Before you retime anything, pin down a short interval with a known event, read the settings the preview is actually using, keep caching and playback and frame inspection in separate compartments, and compare what you saw against a render played somewhere else. Change the edit only for a defect the checked playback actually reveals.
Choose a short passage with a known event
"The whole study feels slow" is not a finding you can act on. Pick one or two seconds that contain an unmistakable visual event — a contact, an arrival, a snap, a reveal — and, if the piece has sound, one cue tied to it. Then write down where those events sit in the timeline before you play anything. In the latch study that means: composition length 48 frames, rate 24 fps, contact at frame 30, click onset at frame 30. Record the project or composition revision too. A judgment made against a version you are remembering rather than reading is not a comparison.
Freeze the source for the duration of the diagnosis. If you do make an edit, note it and treat the next playback as a new test rather than a continuation of the old one, because you have changed one of the two things you are trying to tell apart.
There is one more thing to settle here, and it has nothing to do with performance. A preview can appear to pause simply because the study is supposed to pause. The latch example includes a deliberate six-frame hold at frames 12–17, where the latch rests at the top of its travel; those frames are the same picture on purpose. Step through 12–17 and you see repeated images — authored stillness. Now step through frames 22–26, where the latch is falling, and you will find that every frame differs from the last. If playback appeared to freeze somewhere in that stretch, the frames themselves prove it was never meant to hold. That distinction is available to you without judging a single second of real-time motion, which is why it belongs at the start.
Read the preview settings actually in use
Adobe's documentation for previewing in After Effects describes a set of separate controls — frame rate, skip, resolution, caching before playback, manual preview — and notes that these can be configured independently and that shortcut behaviour is configurable (Preview without rendering in After Effects, checked 18 September 2026). The practical consequence is blunt: the key you press does not guarantee the settings you get. On another workstation, or in a project you set up months ago, the same shortcut may run a lower preview frame rate, a higher skip count, or a different resolution than the one you have in mind. Read the active preview control before you interpret a single frame of what plays.
A few things are worth knowing about what each setting does to your evidence.
The preview frame rate is the rate the preview aims to play at, which may be lower than the composition's own rate. You are still looking at the same timeline; you are seeing fewer distinct pictures of it.
Skip controls how many frames the preview passes over. This one matters enormously for a frame-specific question. If the preview passes over frame 30 — the contact frame — then the picture you associate with the click is a different picture. At 24 fps, one frame is about 42 milliseconds; two frames is about 83. The size of that gap is not really the point. The point is that the setting changed which image you were judging the sound against, and then you drew a conclusion about the edit from it.
Resolution makes the preview softer. That is a reasonable trade for rough iteration, and a bad way to check a fine contact edge or a one-frame reveal. Keep it in its own column: preview resolution is not output resolution, and changing one does not change the other.
Caching before playback prepares frames ahead of the play. A partial cache means some frames arrive from the prepared store and others get computed on the way to the screen, so the delivery rate shifts during a single playback for reasons that have nothing to do with the study.
The most useful sentence here is also the least comfortable one: a preview setting that makes playback smoother has not improved your animation. A faster preview is an easier review. Those are different quantities, and mixing them up is how a designer ends up "fixing" a sequence that was never broken.
Separate caching, playback, and frame inspection
These are three activities, and they get conflated constantly.
Caching is letting the declared interval get prepared. If the cache is still filling when you press play, you are watching a mixed delivery and cannot read rhythm into it. Let the interval you named finish preparing first.
Playing back means watching the interval without touching the edit. No nudging the click, no trimming the range, no relinking audio. Each of those restarts the test.
Frame inspection means stepping or scrubbing to a specific frame. Scrubbing answers "what is at frame 30?" It cannot answer "does the click land on contact?" because you are choosing when the pictures appear. The documentation draws exactly this line: scrubbing cached frames is a different activity from continuous playback of all composition frames. Scrubbing is how you find a cue and check what a frame contains. It is not a rhythm test, and no amount of careful scrubbing turns it into one.
Once the cache has settled, play the same interval under two preview conditions and compare them. One should be the no-skip check, as close to the intended experience as the preview can get. The other is the reduced-work preview you use for rough iteration — fewer frames, lower resolution, whatever gets you through a first pass. The gap between those two runs measures what the preview is costing you. It does not measure the study.
Write down what changed between runs: skip count, resolution, preview frame rate, cache state, range. And write down what you saw in plain language — "latch holds at 12–17, contact at 30, click reads about two frames late." That sentence is the thing you are going to test, so keep it somewhere you can disagree with it later.
Cross-check a render before making the creative correction
The second route is a render of the same interval at declared output settings, played in a separate player. The render is a second opinion, not an oracle. It earns its authority from four things matching what you intended to compare: the revision of the composition, the interval itself (same start and end frames), the timing the excerpt should be seen at, and the presence of the audio. A rendered excerpt with no sound cannot answer a question about a click. A render made from a different cut of the composition is not a comparison at all.
The player can fail too, and this is where the method needs some nerve. If the rendered file hitches in the player, you have two failing routes rather than a comparison. Try the file somewhere else, or deliver it a different way, before promoting either surface to the status of truth. If the played file hitches in the same place the preview did, that is a real signal and worth pursuing. If the file refuses to play smoothly anywhere, you do not yet have a reference — and "the render is the truth" is exactly the assumption that will send you back to the timeline for no reason.
Two routes that agree are stronger than either one alone. Two routes that disagree send you to the settings, not to the edit.
It is also worth being clear about what this whole exercise can and cannot do. A checked render tells you whether the timing you placed is the timing you get. It says nothing about whether the timing is any good. That judgment comes after, and it comes more honestly when you are no longer arguing with a playback engine.
What the latch study would need to show
Here is the study the method implies, kept to a size you could set up in an afternoon. It is a plan, not a report: no preview run, render, or player comparison has been executed for it, so nothing below is a measured result — only what to set up and what each outcome would let you conclude.
Fixed facts. A 48-frame composition at 24 fps. The latch contacts the strike plate at frame 30, with a click at frame 30. A deliberate six-frame hold at frames 12–17. A second control copy of the same animation, in its own file with its own revision label, in which the click is placed at frame 33 — three frames late, about 125 milliseconds. The control exists to answer a prior question: can your review path reveal a real mistiming at all? If it cannot, no result from the main copy means anything.
The runs. First, the primary copy with a completed cache, skip off, preview frame rate at the composition rate, resolution full. Second, the primary copy with frame skipping and reduced resolution, cached however that run allows. Third, a render of the primary over the same frames at the rate the piece should be seen at, played in a separate player. Fourth, the control copy rendered the same way, played in the same player.
What the outcomes would tell you. If the clean preview and the render agree that the click sits on the contact, and the control copy clearly shows its click arriving late, then the review path works and the primary study is correct. The stutter was delivery, and the edit needs nothing.
If the clean preview says the click is on the contact but the render says it is late, you have a comparison problem before you have a timing problem. Check the render's range, rate, and audio, and the player, before touching the comp.
If both routes show the click late, then the placement is genuinely suspect, and that is the one situation in which retiming is the right next move — and even then, you are editing the study because playback showed a defect, not because a preview hiccuped.
If the reduced preview shows the click early or late while the clean preview and the render agree, the preview condition produced the impression. Loosened settings are for surviving iteration; they are not evidence about a frame-specific alignment.
One conclusion this study does not support: that the machine is slow. Even a clean result tells you which route misbehaved, not why. Nor does a completed cache promise smooth playback in every situation — caching is a control, not a guarantee. And a stuttering preview is not a shopping list.
Where the problem lives
At the end of the procedure you have three possibilities, and they are worth naming exactly rather than blending into "it looks off." The apparent timing problem belongs to the preview, in which case the delivery conditions changed what you saw and the study stands. It belongs to the output route — the render settings, the file, or the player — in which case the disagreement is between two viewing surfaces and still not a fact about your animation. Or it belongs to the sequence itself, in which case a checked playback showed the click landing away from the contact, and the click is what moves.
Getting to the third answer honestly requires passing through the first two, and that is the whole cost of the method: a few extra runs, a note about what settings were live, and the discipline not to touch the timeline while you find out. The reward is that when you finally do move a frame, you know it was your edit that needed moving.
Frequently asked questions
What should be pinned down before moving a click that seems late in the preview?
The article advises choosing a short interval with a known event, writing down where those events sit in the timeline before playback, recording the project or composition revision, reading the preview settings actually in use, keeping caching and playback and frame inspection separate, and comparing what you saw against a render played somewhere else. Change the edit only for a defect that checked playback actually reveals.
Why can a stuttering preview be a poor witness to rhythm?
A preview is a review tool with its own settings and is allowed to skip frames, show them soft, or hand them over unevenly. The lurching fall and late click can both come from the same skipped frames. If the preview passes over the contact frame, the picture associated with the click is a different picture, so the preview changes which image you were judging the sound against.
How can authored stillness be distinguished from dropped frames?
Step through the frames. In the latch example, frames 12-17 are a deliberate six-frame hold where the latch rests at the top of its travel, so repeated images are authored stillness. Frames 22-26 show the latch falling, and every frame differs from the last. If playback appeared to freeze in that stretch, the frames themselves prove it was never meant to hold.
What does a render cross-check establish, and what does it not establish?
The render is a second opinion, not an oracle. It earns authority only if the composition revision, interval, timing the excerpt should be seen at, and audio match what you intended to compare. A checked render tells you whether the timing you placed is the timing you get; it says nothing about whether the timing is any good. If the rendered file also hitches in the player, you have two failing routes rather than a comparison.
What is the control copy meant to test in the proposed latch study?
The control copy places the click at frame 33, three frames late, about 125 milliseconds. It exists to answer a prior question: can your review path reveal a real mistiming at all? If it cannot, no result from the main copy means anything. The article presents this as a plan, not a report, and says no preview run, render, or player comparison has been executed for it.