Voiceover Timecoded Feedback: How to Write Notes That Get Fixed

By /

Voiceover timecoded feedback means every note points to an exact moment in a specific version of the recording, names the issue, and says what you want instead. A note like “At 0:34, the line ‘call us today’ feels rushed, slow it slightly” gets fixed in one pass. A note like “make it more natural” starts another round of guessing. This guide shows you which time format to use, how to word notes for performance and for technical problems, and how to keep several reviewers from contradicting each other.

Audome
audome.com
Keep Voiceover Feedback Timecoded
Audome lets audio collaborators add time-stamped remarks to lossless audio and manage project feedback in one hub.

Visit

TL;DR

  • Put four things in every note: version, timestamp, the words affected, and the change you want.
  • Agree on one timing convention (elapsed time or frame-based timecode) before anyone reviews.
  • Split pronunciation, pace, tone, pauses, and script changes into separate notes, and mark each as required or preferred.
  • Consolidate all reviewers into one list on one version, then check every note against the new file before approving.
  • Use a review tool that puts comments on the waveform, so the timestamp is attached automatically.

Table of Contents

What a good timecoded note contains

A useful note answers four questions: which file, where, what, and what should happen. Creator Edit Lab gives an example of an actionable note that names the review version, the timing convention, the range, and the issue: version 07, elapsed 00:42 to 00:44, and the problem in that stretch. That pattern carries over to audio unchanged.

For voice work, add the words. Trevor O’Hare suggests either giving the exact timestamp or quoting the line itself, for example noting that at 0:34 the line “call us today” feels rushed. Quoting the line helps when the talent re-records and the timing shifts by a second or two. The words stay the same even when the clock does not.

Masahiro Kobayashi’s narration template runs in a similar order: audio position, target words, desired change, reason, and desired result. The reason matters more than people think. “Slow down here because the price is easy to miss” lets the engineer or talent solve the problem in a way you may not have thought of.

Here is a template you can paste into any notes document:

Field Example
Version Narration v03
Timestamp 00:34 to 00:36 (elapsed)
Words “call us today”
Change Slightly slower, warmer
Reason Sounds rushed after the previous sentence
Priority Required

Pick one timing convention first

Most confusion in timecoded feedback has nothing to do with the voice. Two people read two different clocks and end up pointing at different moments.

There are two common conventions. Elapsed time counts from the start of the file, such as 00:42. Frame-based SMPTE-style timecode is written HH:MM:SS:FF, where the last field is the frame. Vitelnk notes that the frame rate has to be defined, because the same displayed number can mean different moments at different rates. It also recommends a shared timing convention so reviewers and editors land on the same spot.

Creator Edit Lab suggests recording the export version, duration, frame rate, and whether feedback uses elapsed time, program timecode, or a player clock before review begins. For a voiceover that will be laid to picture, that header is worth a few seconds of typing.

A practical rule:

  1. Audio-only deliverable (e-learning narration, audiobook, podcast ad): use elapsed time from the start of the file you are reviewing.
  2. Voiceover going to picture: use the program timecode of the video, and state the frame rate once in the header.
  3. Mixed review: write both when it is cheap, for example “elapsed 00:42 / program 01:00:42:00”.

Whatever you choose, say it at the top of the notes and never switch halfway.

Tie every note to a version

A timestamp without a version is a trap. Once the talent or engineer sends a new take, 00:42 may be a different sentence. Kobayashi recommends putting the audio, video, and script versions plus the revision number at the top of the revision table, keeping earlier versions, and naming one decision version when several people review.

In practice:

  • Put the version in the filename (for example ClientName_Narration_v03), and never overwrite an earlier one.
  • Write the same version label on every note.
  • If the script changed between versions, say which script revision the note refers to.

Script changes after recording are their own category, because they can mean new lines, new fees, or a pickup session. We cover that in how to handle voiceover script changes after recording. For tracking files across rounds, see our guide to audio version history.

Writing notes about the performance

Performance notes are where reviewers struggle most, because they react emotionally and write vaguely. Three habits fix that.

Describe the listener’s impression, not the technique

O’Hare recommends describing how the line should land rather than prescribing a technical fix. His example, “warmer, like you’re talking to one person”, gives a performer a clear goal while leaving microphone technique and processing to the audio professional. If you are the engineer reviewing for a client, translate their impression into a technical action yourself.

Voice talent recording a conversational narration

Use tone, pace, and intention instead of “energy”

Toby Ricketts organizes performance notes around tone, pacing, and intention, with examples such as “softer, more conversational,” “slow the list for clarity,” and “reassurance, not urgency.” Words like “energy” or “vibe” can mean five different things to five people.

Weak versus strong:

Weak note Strong note
Make it more natural v03, 00:12 to 00:18: sounds read, not spoken. More conversational, as if explaining to a colleague
Too fast v03, 00:34: “call us today” feels rushed. Take a breath before it
Needs more energy v03, 00:50 to 00:58: intention should be reassurance, not urgency
Wrong word v03, 01:05: “data” should be pronounced “day-ta” per the brief

Separate the types of issue

Kobayashi advises separating pronunciation, speed, tone, pause, and copy issues into distinct notes. A single comment that says “too fast, and change the word, and sounds flat” is three requests that may need three different fixes. Splitting them also lets the talent tick them off one by one.

Writing notes about audio quality

Technical notes need the same structure, with a different vocabulary. Bunny Studio’s quality-control standards list what to listen for: room echo, microphone distance, distortion or clipping, editing clicks and pops, unnecessary silence, over-processing, compression or limiting, breaths, mouth clicks, plosives, hiss, electrical hum, background noise, and sibilance. The same page also covers brief and script compliance, labeling of multiple takes, performance, synchronization, and whether music leaves the voice intelligible.

A few examples of technical notes written well:

  • “v02, 00:21: a mouth click on ‘perfect’. Remove or use the alternate take at 01:14.”
  • “v02, 00:45 to 00:52: music bed covers the last three words of the sentence. Lower the music or duck it under the voice.”
  • “v02, 01:30: faint hum begins and continues to the end. Check the noise reduction.”

One caution from TooLab: a waveform can reveal peaks, gaps, and possible clipping, but it cannot by itself tell you how loud, pleasant, or clear the voice sounds. Audition the exact moment with headphones before asking for a new take. TooLab also suggests a first pass where you listen once without stopping or editing, at a comfortable level, and check intelligibility and consistency before comparing against the brief’s pace, mood, emphasis, and pronunciation requirements.

Loudness depends on where the audio will play. SOVAS lists -24 LKFS for U.S. television and advises identifying the target platform before recording. So “too quiet” is a weaker note than “the delivery spec is -24 LKFS and this section reads lower than the rest”.

A review order that keeps notes manageable

Amanda de Andrade suggests reviewing from the big picture down: overall rhythm first, then melody variation, predominant emotion, recurring pause or breath patterns, clarity of openings and phrases, and finally accurate delivery of names, numbers, and key information. She cautions that this order keeps the performer from getting lost among simultaneous artistic and technical requests.

To apply it to a timecoded list:

  1. Listen start to finish once with no notes.
  2. Write the global notes first (overall pace, tone, mood).
  3. Then add the specific timecoded notes in the order they occur.
  4. Last, check names, numbers, URLs, and phone numbers line by line against the script.

Ricketts recommends giving one or two notes per take when possible, prioritizing the most important direction and saying what already works so the performer keeps it. That is easy in a live session. For after-the-fact review, the equivalent is a priority tag on each note.

Kobayashi suggests priorities such as required, preferred, and for a future version. Required means the file cannot be approved without it. Preferred means try it if it is cheap. Future means park it. Those three words cut a typical list of 30 comments down to the handful that matter.

When several people are reviewing

Contradictory notes are the most expensive kind. One reviewer wants a slower read, another wants it tighter to hit a 30-second slot, and the talent receives both.

Kobayashi recommends consolidating production-side comments so contradictory directions do not reach the narrator separately, and naming one decision version. Here is a workable process:

  1. Everyone reviews the same file and the same version.
  2. Each reviewer comments on the shared file, not by email or text.
  3. One person (the producer or lead engineer) reads all comments, resolves conflicts, and marks priorities.
  4. Only that consolidated list goes to the talent or editor.
  5. Set a feedback deadline, and treat notes that arrive after revision work starts as belonging to the next round.

If conflicts come up in a comment thread, our guides on comment threading for audio feedback and turning client comments into one edit pass walk through the details. For tone with clients, client feedback etiquette is a good companion.

Confirming that every note was addressed

A revision is not done when a new file arrives. It is done when each note has been checked against it. Kobayashi’s guidance is to update the filename with the new version and keep the previous one, check the surrounding context of each fix, and record the filename you checked, along with who checked what and when, and document approval.

A simple loop:

  • Open the new version and the old one side by side.
  • Go to each timestamp. Remember the timecodes may have shifted if the edit changed length, so use the quoted words to find the spot.
  • Mark each note as done, not done, or changed (when you did it a different way, with a reason).
  • Listen to a few seconds before and after each fix. Fixes often create new clicks or pacing problems at the edit point.
  • Ask for an explicit final approval in writing. Silence is not approval.

For a broader view of the stages from first mix to sign-off, see our audio proofing workflow. The full method is also in our timestamped feedback process guide.

Our take: put the note on the waveform

We built Audome because timecodes typed into emails and spreadsheets break in all the ways this article describes. Someone reads the wrong clock, someone comments on version 2 after version 3 exists, and the audio gets compressed into a preview that nobody should be judging a voice on.

Our view is that the timestamp should be created by the act of commenting, not typed by hand. In Audome, a reviewer clicks the waveform and writes the note, so the position is attached for them. Files stay at their original quality, up to 96kHz/24-bit, so the voice your client hears is the voice you delivered. Version tracking is automatic, so a note always belongs to the file it was made on.

Clients do not need to log in to comment, which matters when the reviewer is a busy marketing manager who will not create another account. You can add a password and your own branding to the portal, set revision limits, and bill for paid revisions through Stripe when a project grows past scope.

The best feedback format is the one your client will actually use. We think that is a link, a waveform, and a comment box.

Kreg

Run your voiceover reviews in Audome

If you produce voiceovers, podcasts, or post-production audio for clients, Audome gives you a single place to share files, collect time-stamped comments on the waveform, and track versions. The Studio plan is $12.50 per month or $150 per year, and the Pro plan is $48 per month or $576 per year. Details are on the pricing page.

Audome

You can see how the whole workflow fits together on the Audome home page.

A complete example from start to finish

Here is what a short round of voiceover timecoded feedback looks like when everything above is applied. The project is a 45-second explainer narration, version 03, reviewed in elapsed time.

Header: Narration v03, elapsed time, decision version. Script revision 2. Reviewer list consolidated by the producer.

Global note (required): Overall pace is good. The tone should stay conversational throughout, closer to explaining to one person than presenting to a room.

Timecoded notes:

  1. 00:08 to 00:10, “built for small teams”: the emphasis lands on “built”. Move it to “small”. Required. Reason: the brief positions this for small teams.
  2. 00:19, “fifteen percent”: number reads too fast to catch. Add a short pause before it. Required.
  3. 00:27: mouth click before “and”. Remove if possible. Preferred.
  4. 00:33 to 00:38: music covers the end of the sentence. Lower the bed by a few dB under the voice. Required.
  5. 00:41, last line: delivery is a little flat for a closing line. Try a slight smile, more reassurance than urgency. Preferred.
  6. 00:44: client wants to change “today” to “this week”. Script change, route through the producer for approval. Future version.

Notice what the list does. Six notes, each with a position, a reason, and a priority. Two are labeled preferred, one is parked as a script change, and nothing asks the talent to guess. When v04 arrives, the checker works down this list, marks each one, and records the filename reviewed.

Common mistakes to avoid

  • Notes with no version. Always label them, even when you think there is only one file.
  • Mixed clocks. Pick elapsed time or timecode and stick with it.
  • Prescribing the fix to the performer. Describe the result you want, and leave technique to the person with the microphone.
  • Stacking notes. Ten notes on the same sentence is a rewrite, not a revision. Prioritize.
  • Reviewing on weak playback. Judge noise, sibilance, and clicks on headphones or monitors, not laptop speakers or compressed previews.
  • Treating a script change as a performance note. If the words change, it is a copy edit and may need a pickup.

FAQ

What is timecoded feedback on a voiceover?

It is a review note tied to an exact point in the recording, such as “00:34, the line ‘call us today’ sounds rushed”. The timestamp lets the talent or engineer jump straight to the problem. Adding the version, the words, and the change you want keeps the note clear even after new takes arrive.

Should I use elapsed time or SMPTE timecode?

Use elapsed time for audio-only files and program timecode when the voiceover is going to picture. If you use frame-based timecode, state the frame rate, because the same number can mean different moments at different rates. Write the choice at the top of the notes so everyone reads the same clock.

How many notes should I give on one take?

As few as will do the job. Ricketts suggests one or two notes per take in live direction. For written review of a finished file, group notes by type and tag them required, preferred, or for a future version so the important ones stand out.

How do I handle feedback from several reviewers?

Have everyone comment on the same version, then let one person consolidate the comments and settle conflicts before anything goes to the talent. Name one decision version, and set a deadline so late notes roll into the next round instead of interrupting the current one.

How do I know a revision fixed everything?

Compare the new version to the old one at every timestamp, listen a few seconds either side of each fix, and record the filename you checked. Then get explicit written approval. Do not treat silence as sign-off.

Sources

Scroll to Top