Assemble a Multicamera Recording of Your TV-Format Trial

By pitch.dogFoundation11 min read20 September 2026

Television

You recorded the same small format trial from more than one position, and now you want a single viewing copy that moves between those positions — so that someone watching later can follow what happened instead of opening two unlinked files, one per camera, and trying to stack them in their head.

That copy is an assembly of angles. It is not a second version of the trial. Every frame in it came from one event, recorded once, and the assembly's only job is to change which camera you're looking through without changing the event you're looking at. That sounds modest until you start sliding clips around a timeline and notice how easily you can make a trial appear to happen in an order it never happened in.

Three things have to be settled before the assembly is worth trusting. That the recordings cover the same performance. That they share a reference you can actually point at. And what the sound does when the picture changes. Everything visible — the switching, the pacing, the tidy opening — follows from those three, and so does every way this goes wrong, because the damage happens before the first cut.

The case this procedure is built for

A tabletop format trial, filmed from two positions. Camera A runs from before the start to after the end. Camera B starts rolling only after the first instruction has been given: somebody reached over and pressed record once the trial was already underway.

The late start is the interesting part, and not because it's unusual. It's the ordinary condition of small shoots, and it puts the whole problem in one place — two recordings of one event, made by two machines nobody synchronized in advance, one of which is missing the beginning. The specific recordings of this trial aren't in hand here, and nothing below reports results from a finished edit. The case fixes the shape of the problem: continuous plus partial, two angles, one event. The checks are what travel to your own footage.

Before anything: do these clips record the same trial?

Start by writing down what each file is. Which camera, which take, which date, which event. Where the file begins and ends relative to the trial, and what it doesn't contain. Camera B's file, in this case, begins after the instruction; that's the first fact worth recording, because it constrains everything downstream.

Filenames drift and get reused, and the memory of what B_0042 meant survives about as long as the shoot day. Keep the note somewhere that travels with the clips.

The trap is filenames that look like a set, or timecode displays that appear to agree. Timecode is only a synchronization reference if the cameras generated it on a shared basis. Two cameras can show numbers that look comparable and have produced them from unrelated starts, in which case those numbers are decoration. Before you group clips into one multicamera source, find actual event evidence that they belong together: the same spoken line, the same hand reaching for the same object, the same moment of a person leaning in.

Adobe's documentation for creating a multi-camera source sequence lists timecode, audio, and clip markers as the ways to align angles, and names Camera 1 and Switch Audio among the audio settings. That list tells you what the software can do. It does not tell you that your recordings satisfy any of it — that's your job, and it happens before you press anything.

Audio is often the most useful route on a small shoot, because sound leaves a sharp mark. A single clap, a hand on the table, a slate — one brief, unmistakable event that both microphones caught.

If the shoot is still ahead of you, plan that event: a visible clap once camera B is running. It can't come earlier, because B has to be recording to catch it, which means your synchronization point sits inside the trial rather than at its head.

If the recordings are already made — the case here — you take the shared event you find rather than the one you would have planned. The case fixes the shape of the problem, not the contents of the files, so the first thing to establish is whether this trial's footage already contains a brief sound or visible action both cameras caught. If it does, that is your reference. If nothing so clean exists, any single instant present in both files will serve: one sharp sound, a spoken syllable, or a visible action both cameras framed — a hand arriving on the table, a head turning. Either way the requirement is the same: one instant both recordings witnessed, findable independently in each, and inside the stretch where both cameras were rolling.

A clap earns its place by being available twice over: your ears find the peak in both waveforms, and your eyes find the frame where the hands meet. Two independent checks of one instant. For that to work, the event has to be inside both frames as well as both recordings. If B is tight on the tabletop, a clap somewhere above it may be out of shot; a flat-handed slap on the table surface solves it.

Then do the thing that separates a synchronized assembly from a hopeful one. When the alignment command finishes, zoom in. Look at the frame where the sound peaks in A and the frame where it peaks in B, side by side. A command reporting success is not evidence that two machines agree about time.

Why matching clip starts is not synchronization

Take a copy of the assembly and place camera B's first frame at the head of the timeline, flush with camera A's. It looks tidy. It's correct only if both cameras began recording at the same moment on the same basis — and here, by construction, they didn't.

B's first frame lands after the first instruction has already been spoken. Put that frame at the top of the timeline and every frame B recorded is displayed earlier than the moment it recorded it, by exactly the length of whatever B missed. During the instruction, the picture from B shows action from later in the trial. The close view of the table, the hands already at work — all of it sits under audio that is still the instruction. Whenever you cut to B intending to show what the trial looked like from that side right then, you show something that hadn't happened yet.

The correct placement comes from the shared reference, not from the file boundaries. The frame in B where the clap peaks belongs on the timeline at the frame in A where the same clap peaks. One placement, computed from an event both cameras witnessed, and everything else in B follows from it.

A late camera means a real gap, not a stretch

Camera B has nothing before it rolled. No amount of timeline work creates the missing coverage, and no stretch, freeze, or slow-down should be used to imply otherwise. On the assembly, the opening stretch of the trial is single-camera. That isn't a defect in your edit. It's an accurate description of what was recorded, and it's most legible when you don't disguise it. The first cut to B then marks something true: the moment a second view genuinely began.

Watch for the three things that look like coverage and aren't. A frozen frame where a camera stalled is an absence, not a view. A clip from a second attempt at the same setup is a different event, and its reactions belong to that event; dropping one in to cover a hole borrows evidence the trial didn't produce. And an empty stretch on the timeline where a shot "should" go is information. A camera that stopped and restarted gives you two clips with potentially different offsets, and they need identifying as two.

Check the alignment somewhere other than where you set it

Your clap tells you the two files agree at one instant. That's one instant, and it may be near the beginning of a long take. Find a second shared event later — another clap, or a distinctive move both cameras can see — and measure the interval between the two events in each file. Measure it as elapsed time, dividing each file's frame count by that camera's frame rate. Raw frame counts are comparable only if both cameras record at the same rate; if they don't, the counts diverge for a reason that has nothing to do with clock drift, and conforming the clips to a common rate is the fix.

With both intervals expressed in time, compare them. If a single offset holds all the way through, the two recordings agree. If the alignment is snug at the clap and has slackened by the second event, you have a rate difference between the machines, and no single number will fix it; the offset would have to be adjusted across the timeline. That needs diagnosing before you cut, because otherwise the assembly quietly asserts a simultaneity that isn't there — two views of different instants sitting side by side, looking authoritative.

The end of the trial is worth a look for the same reason. And remember what you can't check: the stretch before B started rolling has nothing to verify against. It stays single-camera, and its alignment is a matter of A's record alone.

Sound is a separate decision from picture

Now decide what happens to the sound, and decide it deliberately, because the picture cuts will otherwise decide it for you.

Adobe's source-sequence settings offer Camera 1, which fixes one camera's audio as the sound source, and Switch Audio, which makes the audio follow the picture cut. For a trial, the continuous record is usually the honest choice. The instruction being given, the pauses, the room — that's the record of the event, and letting a cut to camera B swap in B's microphone mid-sentence replaces it with a different machine's copy at a slightly different distance and level.

The setting lives on the source sequence, but the place you'll actually hear the result is the target sequence, where the cuts live. The companion page describing that target sequence — which I'm relying on from an earlier reading rather than a fresh one — treats it as the edit that switches among synchronized angles and lets you adjust the switch points afterward. So inspect the target timeline's audio, not just the setting you chose one level up. Check a cut that lands in the middle of speech; that's where a silent swap announces itself.

Switch when the switch shows something

Every change of angle is a claim that a different view is more useful at that moment. Cut to the close view when the hands are the point. Stay on the wide when the whole table is the point. Cutting between the two views of the same move is how the assembly earns its keep, and its value is legibility, not variety.

Keep the trial in order. Shortened passages are fine and should be marked, so a viewer knows material is missing. Reordering for smoothness isn't fine, and neither is a cutaway that implies an event no camera recorded. If the timeline needs a transition you don't have footage for, that's a gap in the record and not a problem the edit should solve.

Review the assembly against the originals

Watch the assembly once for the beginning: does the first frame show what A recorded first? Watch each cut point: does the picture change at a moment that makes sense, and does the sound stay continuous? Find the gap and confirm the assembly admits B's late start rather than covering it. Watch the end.

Then export a short assembly and compare it with the sources — the key events, the offsets you computed, the audio at each switch. Exporting matters because it's the only way to see the piece the way a viewer will: at speed, on a screen, without a timeline in front of you.

What the assembly is not

A clean, well-switched assembly shows what the trial looked like from several positions at once. It cannot show that the format works, that people behaved as they would without cameras, or that the trial was a fair test of anything. Those are separate questions with their own checks, and editing fluency is not evidence for any of them.

What you can finish with is a viewing copy whose timing and sound choices you can explain: where the synchronization came from, which stretch only one camera recorded, and what the audio does when the picture changes. Leave the gaps as gaps. An unrecorded angle is not an invitation to manufacture the evidence you wish you had.

Frequently asked questions

What must be established before assembling multiple camera angles?

That the clips record the same performance, that they share a usable synchronization reference, and what the sound will do when the picture changes. Filenames or timecode displays that appear to agree are not enough unless the timecode came from a shared basis.

Why is matching clip starts not synchronization?

If one camera started late, placing its first frame at the head of the timeline shifts every frame it recorded earlier than it happened by the length of the missed material. Use an event both cameras witnessed, such as a clap or a sharp sound, and verify the peaks frame by frame.

How should a late-starting camera be handled?

The missing opening is a real gap. Leave that stretch single-camera and let the first cut to the late camera mark where its view began. Do not use freeze frames, stretches, or an earlier take to imply coverage that was not recorded.

How can alignment be checked beyond the synchronization point?

Find a second shared event later, measure the interval between events in each file as elapsed time, and compare. If the offset drifts, the cameras have a rate difference and no single offset will fix it; conform to a common rate before cutting.

What can a multicamera assembly not show?

It can show what the trial looked like from several positions, but not that the format works, that people behaved as they would without cameras, or that the trial was a fair test. Those are separate questions with separate checks.