"The bit near the end where the music changes. Can we look at that?"
The editor now scrubs. Finds two places where music changes. Guesses. Changes the wrong one. You watch version three, say "no, the other one", and a round has been spent on a misunderstanding that a six-character string would have prevented.
Timecode is that string. It's the single cheapest improvement most people can make to how they give feedback, and it takes about a minute to learn.
What a timecode is
HH:MM:SS:FF: hours, minutes, seconds, frames.
00:01:23:14
│ │ │ └── frame 14
│ │ └───── 23 seconds
│ └──────── 1 minute
└─────────── 0 hoursThe frame field counts up to the project's frame rate and then rolls the second over. At 25fps the frames run 00–24; at 24fps, 00–23. So 00:01:23:24 at 25fps is the last frame before 00:01:24:00.
That's the whole format. It exists so two people looking at the same cut can refer to precisely the same instant. SMPTE timecode is a broadcast standard, and it's why every professional review tool anchors comments to one.
You almost never need frames
Here's the practical part most guides bury: for giving notes, `MM:SS` is enough.
"At 1:23 the pause is too long" removes essentially all ambiguity. Frame accuracy matters when you're conforming an edit, syncing sound, or placing a graphic. It does not matter when you're telling someone a section drags.
So don't let the format put you off. The discipline that pays is quoting a time at all. Whether it's 00:01:23:14 or 1:23 is close to irrelevant.
Where to find it
In the player. Most review players show a running time. That's your number.
Two counts, and they differ. Some timelines start at 00:00:00:00, broadcast deliverables traditionally start at 10:00:00:00. If the editor's timecode and yours are an hour apart, that's why. Say which you're reading from. On a web player it's almost always the first.
Ranges, for anything longer than a moment. 1:12–1:40 for a section. A single timecode points at an instant; a lot of notes are about a stretch.
The note format
Three parts, in this order. Covered in giving feedback on a cut, but the timecode is what makes the rest land.
1:12–1:40 · My attention drops through this section.
I think it's because we're still on the factory and we
made that point at 0:30, and we haven't yet shown the
product doing the thing, which is the brief's one thing.Where. Timecode or range. What you observe. The symptom, not the prescription. Why it matters. Tie it to the brief.
Notes in a numbered list, in timecode order, ascending. Not grouped by who wrote them, not grouped by theme: in the order they occur in the film. An editor works through the timeline once, and a list that jumps around forces them to re-navigate for every note.
Small conventions that help a lot
Say which version. "v3, at 1:12". Timecodes shift between cuts. A note against the wrong version is worse than no note, because it looks actionable and isn't.
Flag frame-accurate notes explicitly. If you genuinely mean this exact frame (a flash frame, a logo one frame short), say so. Otherwise the editor will reasonably treat your time as approximate.
Distinguish "at" from "from". "At 0:47" is a moment. "From 0:47" is everything after it. Editors read these differently.
Don't quote timecode from a phone at a glance. Scrub back and check. A note that's eight seconds off sends someone to the wrong shot.
Why this is worth the small effort
Three reasons, in ascending order of importance.
It saves time. Ten minutes of scrubbing per ambiguous note, several notes per round, several rounds per project.
It removes an entire class of dispute. "I did change that" / "not that bit" is a conversation that cannot happen when both parties are pointing at 1:12.
It changes how you're read. Fairly or not, a crew reads timecoded notes as coming from someone who has done this before. People work differently for clients they think are competent. It's a small signal that buys a lot of goodwill.
If you're on the other side
For creators receiving notes: if a client sends you "the middle bit", don't guess. Reply with a timecode and a question: "do you mean 1:12–1:40, the factory section?" It costs one message and saves a version.
And when you deliver, give them the tools to be precise: a player that shows a running time, and a version number on every cut. Most vague feedback is a symptom of the reviewer not having an easy way to be specific.
Where Acumin fits
Delivery Rooms anchor every comment to a frame: you scrub to the moment, type, and the note is attached there rather than described in prose. Versions sit side by side, so a note against v2 stays attached to v2 when v3 arrives.
That removes the mechanical part of this article. It doesn't remove the judgement: a timecoded note that says "not feeling it" is still a timecoded note that says nothing.
How to use this tomorrow
Next set of notes you send, do one thing: put a time in front of every single one, in ascending order.
Nothing else has to change. It'll come back closer to right the first time.
Related: Giving feedback without destroying the edit covers what to put after the timecode, and the three rules that matter more than the format.