A 62 minute episode came in last month with four cameras and two audio tracks. Raw, that is roughly 280 minutes of 4K footage sitting on one timeline. I opened it on a machine that handles single-camera work without blinking, hit play, and got about four frames per second and a fan that sounded like a hair dryer. That is the moment most editors decide proxies are worth the twenty minutes.
I have a strong opinion about this and I will say it up front. Proxies are not a performance tweak on multi-cam work. They are the format you edit in. The camera originals are archive material. You touch them twice, once at ingest and once at export, and never in between.
Most people arrive at that conclusion slowly, after a few episodes of dropped frames and one terrible night where the render failed at 94 percent. I would rather you skip that part.
Why two cameras lie to you
Two cameras is the trap. A modern machine will play back two 4K streams badly but survivably. You scrub, it stutters, you shrug, you keep going. So you never build the habit.
Then a host upgrades. They add a wide, they add a third guest chair, and suddenly you are asking your machine to decode four long-GOP streams at once while you make cut decisions in real time. The decode cost does not go up in a straight line. It goes up and takes your ability to judge timing with it.
That last part is the real cost, and nobody puts it on the invoice. When playback stutters, you stop cutting on feel. You start cutting on the waveform and the timecode, which produces technically correct edits that feel dead. Conversation editing is a rhythm job. If you cannot hear and see the rhythm at full speed, you are guessing. Pacing is where multi-cam either earns its budget or wastes it, and you cannot feel pacing at four frames per second.
If you cannot play the timeline at full speed, you are not editing. You are assembling.
What I actually build, and at what size
My default proxy for multi-cam editing work is 1280 by 720, ProRes Proxy, same frame rate as the source, timecode preserved, matching filenames.
A few notes on each of those, because the details are where this breaks.
- 720p, not 540p. You need to be able to see whether the guest blinked or looked away. At 540 you start missing eyeline problems that show up huge at export.
- ProRes Proxy over H.264. H.264 proxies are smaller on disk and worse in every other way. They are still long-GOP, so scrubbing is still expensive. The whole point is an all-intra codec your machine can decode without thinking.
- Same frame rate, always. Do not conform a 60p B camera to 30p at proxy time. You will relink to a file with a different frame count and spend an hour wondering why the sync drifts at minute 40.
- Filenames identical. Different folder, same name. Every relink problem I have ever debugged came down to somebody renaming a file to be helpful.
Build time on a 60 minute four camera episode runs somewhere between 25 and 45 minutes depending on the machine. That is not free. But it is once, and it happens while I am reading show notes or listening to the isolated audio, which I do anyway.
Sync before proxies, or proxies before sync
I sync first. Always.
The reason is boring and practical. If I sync on camera originals with real embedded timecode, or on real audio waveforms, I have one source of truth. Then I generate proxies from the synced clips and the sync comes along for the ride.
Do it the other way and you have now synced compressed derivatives, which means any encoder-side frame offset becomes a permanent alignment error baked into your multi-cam group. It is a small error. It is also the kind of small error that shows up as lips that are ever so slightly wrong for an entire hour, and once a viewer notices it they cannot unnotice it.
If sync is where your episodes usually go sideways, what to do when audio desyncs covers the recovery moves in more depth, including the drift case where the offset is not constant.
The one setting that causes most proxy disasters
Toggle state. That is it. That is the whole category.
You finish an edit in proxy mode, you export, and the client gets a soft 720p file with a fat bitrate. Or the reverse, you leave the toggle off during the edit and wonder why the machine is crawling when you already built proxies.
So the rule I run on every episode: the proxy toggle gets checked at three moments, not one. At the start of the edit, before any export, and again after any project reopen. Reopening a project is the sneaky one, because some setups do not remember the toggle state and you will not notice until you are watching the export.
Related, and I say this to every editor I onboard: never do color or graphics work with proxies engaged unless you are certain your proxy pipeline preserves color. Proxies are for cutting decisions. Look decisions happen on full res. Intros, lower thirds, any branded element, all of that gets judged on the real footage.
Storage math, because people underestimate it
Four camera 4K at reasonable bitrates on a 60 minute record gives you roughly 250 to 400 GB of camera originals, depending on the cameras and whether anyone remembered to stop recording during the break.
Add ProRes Proxy at 720p and you are adding maybe 30 to 50 GB. That is the good news. The bad news is what happens across a season. Twelve episodes and you are looking at multiple terabytes that you cannot casually delete, because the client will absolutely ask for a re-cut of episode 3 in month five.
My structure, per episode:
01_CAMERAfor untouched originals, read only after ingest02_AUDIOfor isolated tracks, separate from the camera scratch audio03_PROXYmirroring the camera folder structure exactly04_PROJECTfor the project file and autosaves05_EXPORTfor deliverables
Proxies live in 03_PROXY and they are the only folder I feel free to delete when archiving. You can always rebuild proxies. You cannot rebuild a camera original that got cleaned up by somebody trying to free space.
The handoff side of this matters just as much, especially when a host is uploading from a hotel with bad wifi. I put the whole delivery checklist in file handoff that does not break, and the short version is that naming discipline saves more time than upload speed does.
When I skip proxies, and what it buys the client
I am not religious about this. There are cases where building proxies is a waste of forty minutes.
Single camera, 1080p, one hour, all-intra or lightly compressed. Cut it native. There is nothing to gain. Most single camera shows fall in this bucket, and adding a proxy step just adds a place for something to go wrong.
Short turnarounds under 20 minutes with two cameras, also usually native. The build time eats the benefit.
And clips work. When I am pulling verticals out of a finished episode, I am working from the graded master, not the multi-cam project. That is a different pipeline with different rules, closer to short form work than to a full episode assembly.
Everything else, three cameras or more, or anything 4K, or anything longer than 45 minutes, gets proxies. No exceptions and no debate with myself at 11pm.
Here is where I connect this to money, because a workflow post that never mentions the client is a hobby post.
A proxy workflow does not make the edit better on its own. What it does is make the edit reviewable at speed, which means I catch the reaction shot I missed, the two second dead air after a good line, the moment where the guest lit up and camera B was on the host. Those catches are the difference between a competent multi-cam edit and one people actually watch to the end.
Our editors watch the entire episode. Nothing gets auto-cut by silence detection, which means a human is making every one of those calls in real time, and real time only works if the timeline plays in real time. That is the whole argument.
It also protects the delivery promise. First cut goes out in 48 hours, revisions come back the next working day. You cannot hold that schedule if half your afternoon is spent waiting for a scrub to catch up. Studio at $299 per episode covers 2 to 4 cameras in 4K with unlimited revisions, and the unlimited part is only sustainable because the underlying workflow is fast. Starter at $199 covers single camera 1080p with one revision, which is a different job entirely.
For teams running multiple shows at once, the discipline matters even more, because the failure mode is not one bad episode, it is a queue backing up. That is a fairly common conversation in our podcast editing for marketing agencies work, where three or four client shows are moving through the same week.
The retention connection nobody makes
One more thing, and it is the part I find genuinely interesting.
When I look at a retention graph on a multi-cam episode, the drops almost never land on bad content. They land on stretches where the camera sat too long on one person while the energy was somewhere else. Viewers do not consciously think "that shot is stale". They just leave.
Catching those requires watching the cut at full speed, repeatedly, with fresh eyes. Which brings us back to proxies again. I go deeper on how to actually read those graphs in reading a podcast retention graph, and the pattern holds across almost every show I have looked at.
If you are also packaging these episodes for YouTube, the thumbnail is doing more work than any cut decision you make. Our sister studio ClickTheory handles that side, 8 thumbnails for $250, and I mention it only because multi-cam shows tend to be the ones going hard on YouTube.
What I would tell a new editor
Build the proxies. Sync first. Match the filenames. Check the toggle three times. Never grade in proxy mode. Keep camera originals read only.
That is six rules and they will prevent about 90 percent of the multi-cam problems I have watched people fight through. The rest of my setup, the tools and the order I do things in, sits in the podcast editing stack I actually use.
None of this is clever. It is just the difference between an edit that flows and an edit that fights you for eight hours. If your show has grown past two cameras and post has started to feel heavy, that is usually not a talent problem. It is a workflow problem, and workflow problems are the cheap kind to fix.
If you want a second pair of hands on it, I am at samy@pixelsamy.com. Dubai based, working with hosts everywhere.