Timecoded comments (a note at 0:42) are right for dialogue, pacing, and audio feedback; frame-accurate annotations (a note pinned to one exact frame with a drawing) are right for anything visual. Teams that only use timestamps rework visual notes twice; teams that only annotate lose the big-picture pacing conversation. You need both, deliberately applied.
The two feedback styles, defined
- Timecoded comment: a note attached to a timestamp - "music swells too early at 0:38". It identifies a moment (typically a second or two wide) without pinpointing pixels.
- Frame-accurate annotation: a note pinned to one exact frame, usually with a drawing on the image - an arrow at the lower-third, a circle around the logo, a box on the misaligned caption. It identifies a moment and a location.
At 24fps, one second is 24 frames. "0:42" is ambiguous by up to 24 frames; a pinned annotation is ambiguous by zero.
Which note needs which style
| Note type | Right tool | Why |
|---|---|---|
| "This line reads flat" (dialogue) | Timecoded comment | The note is about performance over a moment, not a position on screen. |
| "The middle section drags" | Timecoded comment (range) | Pacing feedback lives on spans, not frames - a start point plus the conversation. |
| "Logo is too small" (graphics) | Frame annotation | Circle the logo. The editor sees exactly what and exactly where. |
| "Caption is misaligned" | Frame annotation | An arrow on the caption beats describing which caption in prose. |
| "Swap this shot" (edit) | Frame annotation | Box the exact shot; the cut point is unambiguous. |
| "Legal flag on the claim" | Timecoded comment + resolve | The claim occupies seconds of VO; the timestamp anchors the thread and the resolution. |
How the wrong style creates rework
Visual notes sent as timestamps cost a clarification round: the editor scrubs 0:40-0:44 looking for "the thing", guesses, exports, and the reviewer says "no, the OTHER text". That loop is one annotation away from disappearing. The inverse is true too: forcing every pacing note onto a single frame produces brittle feedback ("what do you mean, frame 1004?") that misses the actual conversation.
The hybrid review workflow
- Tell reviewers the mapping. "Pacing and dialogue: drop a comment at the moment. Anything visual: pause on the exact frame and draw on it." One sentence in the review-request note does it.
- Let the editor reply on the object. Answers live in the thread attached to the timestamp or annotation - not in a separate chat where context dies.
- Resolve by object, not by person. "All of Sarah's notes" is not a state; "17 open, 12 resolved" is. The open-count is the revision queue.
- Carry threads across versions. When v3 arrives, resolved visual notes on v2 stay visible - the reviewer confirms the fix instead of re-reporting it.
One number to remember
24. That is how many frames live inside a single timestamp second at 24fps. Every "around 0:42" note asks the editor to guess which one.
Frooty supports both styles natively - timecoded comments for pacing and dialogue, draw-on-frame annotations for visual notes - in the same thread surface. See review and approvals, or our guide to collecting client video feedback for the reviewer-side setup.
Frequently asked questions
Are annotations really necessary if we use precise timecodes?
For visual notes, yes - a timecode identifies the moment but not the element. At 0:42 there can be a logo, three text layers, and a lower-third. The drawing collapses that ambiguity to zero.
Do annotations work on mobile?
They should - a finger-drawn circle on a phone screen is how many executives give notes. If a tool's annotation only works with a mouse, its senior-reviewer experience is broken.
What do editors do with annotations when re-cutting?
Frame-pinned notes carry their timestamp into the next version automatically. Even if the cut shifts, the note (with its drawing) stays anchored to its original moment, so nothing needs re-explaining.
Can reviewers mix both styles in one review?
That is the normal case, and the reason to pick a tool that puts both in one comment surface instead of two modes. Mixed-style threads resolve like any other thread.