Quick answer: in my view, AI vs human podcast editing is not an either-or choice. I have not run a head-to-head test or measured costs, so this post makes no numbers claims about either. What it offers is a way to divide the work, using the documented behavior of one editing tool as an example and Apple’s published loudness specification as the finish line.
Contents
Splitting the Work by Task Type
In my view, repetitive cleanup is the part to hand to software: removing filler words, trimming dead air, reducing background noise and balancing levels. Story structure, pacing and deciding which awkward moment to keep are judgment calls, and I would keep a person on those.
How Automated Filler Removal Works in Practice
Descript’s help pages are a useful example of what the software side does, and of where it hands decisions back to you. According to Descript’s filler-word page:
- It flags common filler words such as “um” and “uh” in the script, and the page says this works only for English transcripts.
- You open AI Tools and choose Remove filler words, and a sidebar lists each detected word with a timestamp, lets you preview the audio, and lets you pick a handling option for each one.
- The options per instance are Delete, Delete and replace with a gap (which keeps timing), Ignore, and Remove from transcript only.
- When enabled, the tool skips filler words that cannot be removed without clipping nearby words or leaving an awkward cut.
Notice what that design implies for your workflow: the software finds the candidates, and the page describes you choosing what happens to each. That fits the split above, with the machine doing the finding and the person doing the deciding.
Filler Words: Leave Some In
My suggestion: do not set automated filler-word removal to remove every instance. In my view, a few natural fillers keep the rhythm of conversation, and removing all of them can sound over-processed. Use the per-instance preview described above to listen before applying a setting. I am not citing a percentage for this.
Other One-Click Passes and Their Safety Nets
Descript’s Sound Good page lists several other automated passes that map to the cleanup tasks above:
- Studio Sound enhances voice quality and removes background noise, room echo and inconsistent audio across speakers.
- Remove Retakes detects re-recorded phrases and marks earlier versions for removal. Removals appear as ignored text, which you can restore or delete.
- Shorten Word Gaps shortens long pauses. You can preview gaps individually or shorten them all at once.
- Edit for Clarity trims wordiness, retakes, filler and off-topic segments, with an intensity slider that controls how aggressive the edits are.
- Add Chapters generates chapter markers and titles you can copy as a timestamped list for show notes.
Two features are worth building habits around. The restorable “ignored text” means a bad cut is reversible, and the intensity slider means you can start gentle and raise it only if the result sounds right.
The Finish Line: Make the Final File Meet the Spec
Cleanup is not finished until the exported file meets the specification of where it is going. Apple Podcasts’ audio requirements give these targets:
- Loudness of about -16 LKFS with a tolerance of ±1 dB, and true peak no higher than -1 dBFS, measured to ITU-R BS.1770-5, with loudness processing applied before encoding.
- For RSS feed audio, MP3 or AAC, with AAC strongly recommended by Apple, preferably in an MP4 container. Mono AAC is 64–128 kbps at 44.1 or 48 kHz; stereo is 128–256 kbps at those sample rates.
Measuring loudness is a mechanical check, so it is a good job for software. Whether the episode is paced well is not.
Let a chatbot check the numbers. The comparison is plain arithmetic, so a chatbot can do it if you stop it from judging the sound. Copy the readings from your loudness meter and use this prompt:
Below are the measurements for my exported podcast episode, copied from my loudness meter, and the target I am checking against.
Target (Apple Podcasts): loudness of about -16 LKFS with a tolerance of +/-1 dB, and true peak no higher than -1 dBFS.
My measurements:
[paste the numbers]
Please:
1. For loudness, write the measured value, the allowed range, and PASS or FAIL.
2. For true peak, write the measured value, the limit, and PASS or FAIL.
3. For each FAIL, show the subtraction that gives how many dB it is off.
Rules:
- Use only the numbers I pasted.
- Do not suggest settings or software.
- Do not say whether the episode sounds good.The prompt above is my own wording, not an official or published template.
An invented example. Say the meter shows a loudness of -18.4 LKFS and a true peak of -0.3 dBFS (invented numbers). The allowed loudness range is -17 to -15 LKFS, so -18.4 fails, and the subtraction -17 minus -18.4 shows it is 1.4 dB below the lower limit. The true peak limit is -1 dBFS, so -0.3 fails, and -0.3 minus -1 shows it is 0.7 dB above the limit. You now have two specific numbers to fix before uploading, instead of a general sense that something is off.
A Practical Way to Divide the Work
- Run the cleanup pass with software first.
- Keep a person for the structural pass: pacing, which tangent to keep, and how a moment lands.
- Preview filler-word removals instead of applying them blindly.
- Run audio enhancement before editing. That is my suggestion, not a tested result.
- Check the exported file against the loudness target before you upload.
- Listen to the full episode before publishing, every time.
Where the Real Cost Can Hide
This section is my opinion. A subscription price and an editor’s rate are not the only costs. An episode that goes out with a missed cut, a pause trimmed that mattered, or a tangent left in has a cost too, and it does not show up on an invoice. That is why I would listen to every episode in full before publishing, whichever tool or person did the editing.
Chapters: Software Drafts, a Person Names Them
Chapters are a good example of the split in action, because software can draft them and a person gives them meaning. Apple Podcasts for Creators explains that Apple Podcasts now creates chapters automatically (from iOS 26.2, for full and bonus episodes in English), skips trailers and episodes under 10 minutes long, requires a transcript, and shows an “Automatically Created” label in the chapter list. Creators who want their own wording can provide chapters in one of three ways:
- File metadata: chapters specified in the header of an MP4 file, or in the ID3 tags of an MP3 or AAC file, usually added by an audio editor.
- Episode description: chapter titles and timestamps added to the description. Apple says to start the first chapter at 00:00:00 (hours:minutes:seconds) and to include at least three chapters.
- RSS feed: chapters submitted through your hosting provider with the
<podcast:chapters>tag. Apple says to check whether your hosting provider supports chapters.
For a workflow that uses both sides of the split, let an editing tool draft the chapter list (Descript’s Add Chapters, described above, produces a copyable timestamped list), then have a person rename each chapter so the titles describe what the listener will actually hear.
An invented example of an episode-description chapter list, in the format Apple describes with the first entry at 00:00:00:
00:00:00 Welcome and today’s question
00:04:10 How the guest got started
00:18:45 The mistake that changed the plan
00:31:20 Three tips for beginners
00:42:05 Where to find the guestThe titles and times are made up. The point is that software can produce a starting list, and a person’s renaming makes it match your show. This is my suggestion.
Transcripts: The Automatic Draft and Your Fix
Transcripts follow the same pattern. Engadget’s report on Apple Podcasts transcripts says Apple automatically transcribes episodes starting when they are uploaded, creators can supply their own transcript in VTT or SRT format instead, and creators can edit a transcript to improve its accuracy. It also lists the limits worth knowing before you rely on the automatic version:
- Transcripts may take a short while to appear. Apple’s transcript page says to make sure it has been at least 24 hours since a new episode was published when you are troubleshooting.
- Transcripts will not update if dynamically inserted audio changes the recording.
- Song lyrics are not shown.
- Recordings with overlapping speech or music may transcribe less accurately.
Those limits point to a clear division of labor. The software produces the first draft for free, and a person fixes the places where machines struggle: names, crosstalk and music beds. If your episodes have a lot of overlapping speech, plan that correction pass into your schedule so it is a habit, not a surprise. The routine is my suggestion; the limits above come from the report.
My View on AI vs Human Podcast Editing
This closing part is my opinion. Use software where it can do the job, and keep a person where judgment matters. This post makes no cost or accuracy claims, so the split above rests on what the sources document.