Record a Remote Table Read With Separate Speaker Files

The setting that produces separate audio files is easy to switch on. What it actually produces is harder to guess. A separate file per participant is not a separate file per character, and it is not a clean studio microphone. It is the audio the meeting received from each person, written out as its own file — often exactly what an editor needs, and occasionally much less than a team assumes when they promise "we'll send you everyone's tracks."

So the short answer runs in one direction only: choose the recording mode first, say plainly what that mode delivers, make a short deliberate setup recording and inspect its finished files, then run the read and inspect again before the sources leave anyone's hands. Most of the work is in the inspecting. The article is about what "inspect" means.

One boundary up front. This describes the documented computer-recording route in Zoom — the support article Starting a computer recording (Zoom support) — as read in September 2026. That documentation is not a test. No account, meeting, consent process or recording has been run for this article, and instructions and availability change with installed desktop versions. Check the steps against the version your team actually has.

Choose the capture route before promising deliverables

Three different arrangements get called "recording the read," and they produce different things.

Computer recording. The provider's instructions describe an option to record a separate audio file for each participant, and describe a conversion step that runs after the meeting ends. Files land on the computer doing the recording.

Cloud recording. The provider documents this as its own route. Do not assume the file behavior carries across from the computer-recording instructions; check the cloud route's own documentation if that is what your account uses.

Every performer records themselves. Each person captures their own local audio on their own device, in whatever application they have. This is a general practice rather than a provider feature, and it can give you the most separation of any route — and the most setup, the most files to chase, and the most ways for one person's contribution to be missing on the day.

Whichever you choose, choose it before you tell the editor what to expect. Swapping routes mid-project is where teams get burned: someone promises isolated voice tracks, someone else turns on a meeting recording, and the gap gets discovered by the person cutting the pitch sample.

A realistic deliverable list for a read is short:

• The shared reference recording — the mixed audio everyone heard, which is your timing map and your record of what the room actually experienced.
• Identifiable participant audio, in whatever form the chosen route produces it.
• A written note of gaps: who dropped, what is missing, and where in the reference.

Notice what is not on that list. "One file per character" is not a deliverable. A participant file is named for the person, and a person may be reading two roles.

Map performers and characters before starting the setup call

Two documents prevent most of the confusion later, and both are cheap to make before anyone records anything.

The first is a performer-to-role map. Every performer needs one distinct, agreed identity in the meeting — the name they appear under — because that identity is what ends up attached to the file. If someone joins as "Avery (phone)" in week one and "A.M." in week three, you have made matching harder for no reason.

The map should include the action reader. Action lines are a role in the read, not an absence of one, and the person reading them is a participant with a file like anyone else.

Three performers, four speaking roles:

That table is the sentence that stops the misunderstanding. Three participants. Four roles. If someone asks for "all four character stems," the map is your answer about what exists.

The second document is the person responsible for retaining the sources. On a computer recording, the files are made on one machine, which puts retention in one place. Name who owns that folder, where the copy goes, and when.

Now the setup recording. It should be short, separate, and built to fail visibly if something is wrong. Invent a scene — an original one, not pages from the script — containing three things: solo turns, an interruption, and one performer changing roles. Here is a fictional exchange for the team above:

JULES (action): Rain on the window. Neither of them moves. AVERY (Ivy): You said the ferry left at six. SAM (Bo): It did. AVERY (Ivy): Then where were you? SAM (Bo): Ask the Sergeant. AVERY (Sergeant): That is enough. JULES (action): Bo keeps talking anyway, half a beat too late. SAM (Bo, overlapping): Ask her where she was.

That scene is invented, and the file behaviors below are what you write down, not what anyone has observed yet. It carries its own tests. The interruption puts two voices on top of each other, which is precisely the case where a mixed recording is hard to untangle and separate tracks should help. Avery crosses from one character to another without leaving the meeting, which is the case where one file carries two roles. Jules speaks least, which is the case where a track is easiest to overlook when you scan a folder.

Finally: confirm the intended recording and its later use through whatever arrangement your team already has. Consent and permission are separate questions from file format, and a recording setting settles none of them.

End the short setup session and inspect what it produced

Turn on the documented option for recording a separate audio file per participant, run the invented scene, and then end the trial deliberately.

Deliberately matters. The provider describes conversion as happening after the meeting ends, so there is nothing to inspect while the call is still open. The temptation is to fold the check into the first ten minutes of the real read and look at the files afterward — but by then the read has already been recorded the way it was recorded, and the check has no power to change anything.

When conversion finishes, open the folder and answer these questions in writing:

• Which files exist, under which names?
• Which performer does each name belong to?
• Does every performer who spoke have a file?
• What are the track lengths, and do the tracks start at the same moment in time?

Take those measurements rather than assuming them. Do not assume the names use the meeting identities you agreed, that the tracks are equal length, or that they share a start point. Record what happened. If a name does not match the role map, fix the map or the display name before the real read, not after.

Then compare voices against the shared reference. Play a few seconds of each participant file alongside the same moment in the mix and confirm the person is who the filename says. Once you can hear that the file labeled with a given name really is that performer, you have earned the right to trust the folder.

If a voice is absent, or the route produces something you cannot use, change the route now. The setup call exists to absorb that failure cheaply.

Preserve the main read before making an editorial excerpt

After the main meeting ends, let conversion finish, then check its files — not the setup files, which are already old news. The main recording is the one the pitch sample depends on.

Start with the folder itself. Preserve it complete, and make working copies before anyone opens anything for editing. Keep any backup your team agreed on until a checked source set exists.

Then run the same inspection you ran on the setup, and add the events of the day. This is where the fictional scenario earns its place: suppose Avery's connection drops partway through the read and Avery rejoins a minute or two later. What you should do is inspect — not predict. Look for whether a second file appears for Avery, or a file under a changed name, or no new file at all. Look at the shared reference for whether the exchange around the drop is complete. The provider documentation does not tell you what your account and your version will produce under that condition, and neither does this article.

When you find the answer, write it down: the time in the shared reference where the break occurs, which files cover which side of it, and retain both segments if both exist. Then note what is missing, if anything. Separate files do not restore speech the meeting never captured. A participant track is the audio that arrived from that person's connection; if the audio never arrived, no setting brings it back, and the honest entry in the gap note is "not captured."

The point of all this annotation is a specific reader: the editor cutting the pitch sample. They should be able to locate each voice, understand who is who in the role map, and recognize a gap from the note instead of reconstructing the meeting from memory. That is the standard to check the folder against — not "the files exist," but "someone else can use these files without asking you what happened."

Empty gaps in the folder are worth naming here rather than in the pitch. If a voice is thin, if a track is oddly short, if a reconnection left a hole, write it plainly in the note. An editor can build around a documented gap. They cannot build around a surprise. And the note is not an invitation to repair the performance invisibly — patching missing dialogue, re-reading lines in a different room, or presenting a rebuilt exchange as one continuous read all create a source that no longer matches what the team approved.

What you end up holding

The end state is a folder and a note. The folder holds the shared reference recording, the participant files the route actually produced, and the performer-to-role map that ties them together. The note says which recording route was used, who was captured, where the known gaps fall in the reference, and what the files are not: not isolated local microphone capture, not a per-character set, not a promise that every second of the read survived.

That note travels with the sources to whoever edits the sample. If the read gets used publicly, the same limits belong in whatever context accompanies it, in ordinary language, because they describe the material rather than the team's effort.

The reason to spend ten minutes on a setup call and another ten on inspection is that everything downstream inherits these files. A pitch sample built from a folder whose gaps were documented can be trusted, adjusted, or replaced. A pitch sample built from a folder whose gaps were guessed at tends to get found out at the worst moment — in the room, with the reader listening.

Frequently asked questions

What does a separate audio file per participant actually capture?

It is the audio the meeting received from each person, written out as its own file. It is not a separate file per character and not a clean studio microphone; it can be exactly what an editor needs, or much less than a team assumes when they promise everyone's tracks.

What are the three capture routes, and why choose one before promising deliverables?

Computer recording can record a separate audio file for each participant and runs a conversion step after the meeting, with files landing on the recording computer. Cloud recording is its own route, and its file behavior should be checked in its own documentation. A third route is every performer recording themselves locally, which can give the most separation but also the most setup, files to chase, and ways for a contribution to go missing. Choose before telling the editor what to expect, because swapping routes mid-project is where teams get burned.

What belongs on a realistic deliverable list for a remote table read, and what does not?

The list can include the shared reference recording, identifiable participant audio in whatever form the chosen route produces, and a written note of gaps naming who dropped, what is missing, and where in the reference. One file per character is not a deliverable; a participant file is named for the person, and a person may read two roles.

Why run a short setup recording and inspect its files before the main read?

A separate setup call can absorb failure cheaply. Build an invented scene with solo turns, an interruption, and one performer changing roles; include the action reader as a role. End the trial deliberately, because conversion happens after the meeting ends, then inspect which files exist, which names belong to which performers, whether every speaking performer has a file, track lengths, shared start points, and whether voices match the shared reference. If a voice is absent or the route is unusable, change the route then.

How should a connection drop or missing audio be handled after the main read?

Inspect rather than predict. Look for whether a second file appears, a file under a changed name, or no new file, and check the shared reference for whether the exchange around the drop is complete. Write down the time of the break, which files cover which side, retain both segments if both exist, and note what is missing. Separate files do not restore speech the meeting never captured; the honest entry is not captured. Do not invisibly patch missing dialogue or present a rebuilt exchange as one continuous read.

Further reading

• Assemble a Multicamera Recording of Your TV-Format Trial — When a performer drops and rejoins, this shows how to align separate recordings on a shared event and how to leave a real gap unfilled.