How a Review Version Is Built Before Anyone Gives Feedback

What a review version actually is

A review version is not a rough guess at the finished sound. It is a complete, playable pass through the whole piece, with edits made against the approved script, cleanup applied at a sensible level and levels broadly balanced. What it leaves undone is the final polish: last loudness trims, final naming and the delivery export. Keeping that line clear matters, because a reviewer who hears a half-finished file tends to comment on things we have not yet touched.

When I prepare one for a learner exercise or a paid job, I begin by asking what the reviewer needs to judge. Usually it is pacing, wording against the script, and whether the voice sounds natural after cleanup. Those are the questions the file should answer. Anything else, such as fine mix decisions, can wait for the next round without anyone feeling short-changed.

Building the file for the person who has to listen

Most reviewers listen on whatever is nearest: laptop speakers, a phone, one earbud. So I check the review version on more than one playback route before it leaves my desk. If a breath edit only sounds clean on studio headphones, I would rather hear that myself than have a producer report it from the back of a train.

I also make the file easy to talk about. A reference tone at the start is unnecessary, but a visible timecode burnt into a low-resolution picture, or a simple numbered list of segments if there is no picture, lets someone write 'at 02:14, the second sentence' instead of 'somewhere in the middle'. It sounds minor, yet it removes most of the back-and-forth that eats an afternoon.

• Export a lower-quality file that plays anywhere
• Add timecode or segment numbers for reference
• Check playback on laptop speakers and headphones

Collecting feedback in a form you can act on

Feedback arrives in every shape: a numbered email, a marked-up script, a voice note, occasionally a phone call. I ask for one consolidated list per round, from one named person where possible. When three people send three lists, the contradictions are not mine to resolve, and the producer is usually relieved to be asked to settle them before editing begins.

Each comment gets sorted on arrival. Some are plain edits, such as removing a repeated phrase. Some are judgement calls, such as making a voice warmer. And some are outside the agreed scope, such as re-recording a line. I note which is which in a short reply, so nobody is surprised later. In the course, learners practise exactly this sorting on a sample set of comments.

Keeping revisions inside the agreed scope

Scope is agreed before the first edit, in writing, and it is usually simple: a number of review rounds, and what counts as a change within a round. A trimmed pause, a swapped take, a level nudge on one segment are all revisions. A new script, a replaced voice or a restructured running order is a different job, and it is better named as such than absorbed quietly and resented.

I find that stating this early rarely causes friction. Producers tend to appreciate knowing the boundary, because it also protects their own budget. When a request does fall outside, I describe what it would involve and let them decide, rather than refusing or quietly doing it. Patience here saves more time than any shortcut in the editing itself.

• Agree the number of review rounds first
• Name what counts as a revision and what does not
• Describe out-of-scope requests before acting on them

Closing a round without losing track

At the end of each round I keep a short change log: what was asked, what was done, and anything deliberately left. It is plain text, a few lines per comment. When the final round arrives and someone asks why a pause was kept, the answer is already written down, with the version it applies to.

Version names matter just as much. I number review files in sequence and never overwrite an earlier one, so a producer who prefers the second pass to the third can return to it in seconds. Learners are asked to keep this habit from their first exercise, because it is a quiet discipline that prevents the most common mistake in review work: sending the wrong file.

What learners practise in this module

In the review module, learners take an edited voiceover and prepare a review version from it, then work through a set of realistic comments from a producer brief: some clear, some conflicting, one outside scope. They write the short reply, apply the changes and log them.

The aim is not speed but a calm, repeatable habit. By the end, they should be able to hand over a review file with confidence, receive feedback without dread and explain what a revision does and does not cover. Those are skills that stay useful whatever software they edit in.