Podcast editing turnaround: how long should it really take?

"How long should podcast editing take?" is two questions wearing one coat. The first is "is my editor slow, or is this normal?". The second is "can I build a release calendar around this?". They have different answers, and both depend on something most turnaround pages skip: what actually happens between the moment you stop recording and the moment an episode goes live. This guide walks that path stage by stage, shows where the time genuinely goes, and is honest that the slow part is sometimes the editor, sometimes the source files, and sometimes the client. If you are still picking a provider, start with how to choose a podcast production company; this post is what to expect once you have.

Is your editor slow, or is this normal?

Most frustration about turnaround comes from measuring the wrong interval. Clients count from the end of the recording to the published episode. Editors count from the moment usable files land in their system to the moment a review cut goes back. Those two intervals can differ by a wide margin without anyone being lazy, because the gap between them is filled with transfers, checks, and waiting for a decision.

Plenty of providers advertise a fixed number of working days. Read that as the length of their part of the chain under good conditions: complete files, a clean recording, a client who answers the same day. It is not the length of the whole path, and it says nothing about what happens when a file is missing. We quote a rhythm rather than a stopwatch: under a week per episode, with the full package included. We work in weekly cycles and bill per four-week cycle. The rest of this post is about what fits inside that rhythm and what breaks it.

A workable test of whether your provider is slow: ask which stage your episode is sitting in right now. A good editor can answer in one line ("waiting on your notes", "syncing the angles", "re-transcribing because the guest track was missing"). If the answer is vague, the delay is unexplained, and that is a different problem from the delay being long.

Where does the time go between recording and publishing?

Six stages, in the order they happen. Each has a natural cost, and each has a way of quietly doubling.

1. Getting the files

This is the stage everyone forgets, and it stalls more episodes than any other. A video podcast is heavy. In our own archive, raw camera files run about 8.5GB per camera. Synced multicam takes on a three-angle shoot come in at 9GB to 14GB per angle. Finished masters sit at 2.1GB, 3.4GB and, for one show, 16GB. Almost every finished export is well over 400MB, and many land between 1GB and 16GB.

Put that together and a single three-camera session is tens of gigabytes before anyone has made a cut. Those gigabytes have to leave the recording machine, cross an upload, land in shared storage, and be pulled down again at the other end. On a domestic connection that is a job for an evening, not a coffee break. If the upload is started on the way out the door and fails at 80%, nobody notices until the editor opens an empty folder the next morning. Transfer time is real time, and all of it happens before the edit exists.

What makes it longer: uploading from a laptop that goes to sleep, sharing a folder that is still syncing, sending one camera and forgetting the other two, or sending the recording platform's web page rather than the files behind it. What an editor actually needs in the package is covered in outsourcing podcast editing.

2. Ingest, sync and transcribe

Once the files are in, the editor lines up every angle and every separate audio track against each other, generates a transcript, and reads the source for faults. This is where problems reveal themselves, and the reason it cannot be skipped is simple: a fault found here is cheap, and a fault found after the story edit costs the story edit.

What makes it longer: cameras that started at different times, an audio track that drifts against the picture, a transcript with blank stretches, or file names that do not match the episode they contain.

3. The story edit

This is the stage that makes an episode good, and the stage that cannot be hurried. A human editor watches the whole conversation, decides what it is actually about, removes the false starts, the tangents that go nowhere and the warm-up chatter, then reorders what remains so the best material lands where a listener will still be there for it. Taking a loose 80 minutes down to a tight 45 is a long stretch of undivided attention, and the difference between a fine edit and a good one is almost always here rather than in the polish.

What makes it longer: a conversation with no clear spine, a host who wants nothing cut but also wants it shorter, and notes from a previous episode that were never resolved and reappear on this one.

4. Polish

Audio repair, levels, noise, room tone, colour matching between cameras, graphics, lower thirds, the intro and the outro. Individually these are small. Together they are a second pass over the whole runtime.

What makes it longer: a room that changed acoustically halfway through, one camera set to a different white balance, or a brand kit that is still being decided while the episode waits for it.

5. Packaging

Short-form clips, a thumbnail, titles, show notes, chapter markers. This is what turns one file into a release. It is also the stage most often started before the master is signed off, which is efficient right up to the moment a revision moves a clip's best line out of the cut.

What makes it longer: clip selection with no brief, a thumbnail that needs a photo nobody has taken, and titles that need a guest's company name spelled correctly when the recording and the notes disagree.

6. Review and revisions

The client's turn, and in our experience the true long pole. An episode that took one focused stretch to edit can sit in review for longer than every previous stage combined, because review competes with the client's actual job. Then the notes arrive, and if they are impressions ("the middle feels slow") rather than timestamps, a round of conversation has to happen before a round of changes.

Said plainly: the block of calendar the client is most frustrated by is frequently theirs. That is not a complaint. It is a planning fact, and the calendar section below is built around it.

What actually makes an episode slow?

The stages above have a natural rhythm. What breaks it is nearly always a fault in the material, and every fault below is one we have met in our own archive. They are described as things seen in the edit rather than as anyone's failing, because most of them happen to careful people.

A fault in the source resets the clock. On one four-episode show, three of the four episodes came back with the guest's separate recording missing from the finished multicam transcript. The result was long, blank timestamp gaps, for example 00;06;44;13 to 00;07;06;23 with no text at all, in places where the guest was clearly talking. The audio existed, sitting in the per-speaker raw files. Recovering it meant going back to those individual tracks and re-running the sync and the transcription, not nudging a slider. Every stage downstream waited.

Unrecoverable audio. In one episode, one interviewee transcribed cleanly enough to yield five complete, usable quotes. A second interviewee in the same episode came back as single words: "Right." "Yeah." "Was also." No amount of editing turns that into a segment. It has to be re-recorded, or re-transcribed from the original synced audio if that is any cleaner, and either way the release date moves.

Mislabelled files. A transcript filed under EP03 that actually documents EP04's conversation. Files named EP15 sitting inside the EP14 folder. Untangling which episode is which costs real hours of reading and cross-checking, and the cost of getting it wrong is publishing the wrong episode under the wrong title.

Incomplete deliveries. One episode arrived with no transcript, no finished cut, and only two raw single-speaker recordings of about 600MB each. That is not an episode waiting to be edited. It is the start of a conversation about what else exists and where it is.

Read the middle column honestly. Half the rows are in the client's hands, a couple belong to the tools, and two are squarely the editor's. A provider who tells you every delay is your fault is not being straight with you. Neither is one who lets you believe every delay is theirs.

How do you plan a release calendar that survives a bad week?

Given all of the above, a weekly show that records at the start of the week and publishes the same week is running with no margin. It works until the first missing track, and then it misses. The fix is not a faster editor. It is a calendar with slack in the right places.

Record ahead. The single most effective change. If the episode going out this week was recorded some time ago, a fault in this week's recording is an inconvenience rather than a missed release.

Keep a buffer of finished episodes. Two or three complete, approved, packaged episodes sitting ready to publish is the difference between a bad week and a bad month. Build the buffer once, at the start, by recording in a burst. After that, each cycle only has to replace what went out.

Batch record. Two or three conversations in one day cost one setup, one upload session and one ingest. They also arrive at the editor together, which lets the stages overlap: one episode in the story edit while another is being synced.

Decide who signs off and how fast. Name one person. Agree a review window that you choose for yourselves and can actually keep. Agree that notes come as timestamps. Most of the review long pole disappears when review stops being a committee.

Decide what happens when an episode cannot be saved. Some episodes should not go out: a guest who transcribes as single words, an interview with no usable second half. Agreeing in advance that such an episode is dropped or re-recorded, rather than argued about for a fortnight, protects the calendar more than any editing speed could.

Match the cadence to the cycle. Joycast works in weekly cycles and bills per four-week cycle, with no minimum term and revisions until you are happy. 10% comes off at three or more episodes in a cycle, which is a quiet nudge towards exactly the batching described above. Current prices are on the pricing calculator. If you are weighing this against doing it yourself, the DIY versus outsourcing comparison puts hours against pounds.

What should you ask a provider about turnaround?

Not "how fast are you?". Every answer to that question sounds the same, and none of them survives a missing file.

Ask instead: "Walk me through what happens to my files between upload and my first review, and tell me what you do when something is wrong with them." A provider who has done this properly will describe the stages above in their own words, will mention checks before the edit rather than after, and will have a plain answer for what a missing track or a mislabelled folder does to the plan. That answer tells you far more than a number. Numbers describe the good weeks. Process describes the other ones.

Then ask yourself the mirror question: how quickly can your side sign off, and who is doing it? The honest answer to that is very often the real turnaround of your show.

If you would like to see what a cycle would cost, spec an episode on the calculator.