How to Batch Normalize Podcast Episodes to One Loudness

You are re-releasing a back catalogue, onboarding a season from another producer, or fixing the archive after a listener complains that episode 12 whispers and episode 13 shouts. Normalizing files one at a time is how weekends die. This guide shows a batch workflow that brings every episode to one target with one report to check.

Paid plans on LoudNorm accept batches of files in one upload for exactly this job.

Why Batch Loudness Drifts Happen

Catalogues drift because they were made at different times: a new microphone in season two, a different editor in season three, a "louder" phase after a sponsor note. Each episode was fine alone. Played back to back, the seams show. Batch normalization re-measures everything against one target today, so the catalogue sounds like one show.

The drift is rarely dramatic in any single step, which is exactly why it happens. Season one is mixed by ear on laptop speakers. A new microphone arrives and everything gets a little hotter. A producer joins for season three with broadcast habits and delivers at broadcast-ish levels. A sponsor asks for "more energy" and the whole show creeps up for a year. No single episode sounds wrong; the archive sounds wrong — and archives are how new listeners meet you. A binge listener plays six episodes in a row and experiences every equipment change you ever made as a volume problem. Batch normalization is how you introduce your whole catalogue to a new listener at one consistent, professional level.

Before You Start: What a Batch Is and Is Not

Batch normalization means: many files, one target, each file measured and corrected on its own. It does not mean one blanket gain applied to all files — that would preserve every difference between them, which is the problem you came to fix. A quiet episode gets its +6 dB; a hot episode gets its -3 dB; they meet at the target from opposite directions.

It also does not mean re-mixing. Batch loudness fixes level, not balance, content or quality. An episode whose guest is buried stays an episode whose guest is buried, now at a certified loudness. The workflow below therefore starts with a triage pass: most episodes go straight through, and the handful with real problems are pulled out for repair first, then rejoin the batch.

The Batch Workflow

1. Gather the final mixes. Batch loudness is the last step; do not normalize files you still plan to edit. Re-check problem episodes with the quiet recording guide first.
2. Pick one target for the whole batch. -16 LUFS stereo / -19 mono for podcasts (the rule is in the mono guide); -14 for streaming-first shows. Mixing targets inside a batch defeats the purpose.
3. Upload the batch. On the home page tool, add all files, choose the preset once, and start. Each file is measured and normalized on its own — batch means one trip, not one blunt gain for all.
4. Read the single report. Every file lists before/after LUFS, true peak and LRA (terms in the LUFS explainer). Files outside ±1 LUFS are flagged; usually they are the very hot or very quiet ones from the table below.
5. Spot-listen the flags, publish the rest. Trust the numbers for the clean files; spend your ears only where the report points.

A Worked Example: A 40-Episode Archive

A comedy podcast with 40 episodes decides to fix its archive before a relaunch. The first measurement pass — before any correction — produces this picture:

Thirty-seven episodes go through the batch at the Podcast preset in one run. The report confirms every one inside -16 ±1 with peaks under -1 dBTP. The three outliers are pulled: the -29 interview goes through the quiet-recording repair order and then rejoins; the live show is accepted slightly under target after softening its wildest peaks; the panel episode gets its voices levelled, which brings its LRA from 18 to 9, and then normalizes cleanly.

Total time: one measurement pass, one batch run, three small repairs, one verification pass over the final report. The alternative — forty individual normalization sessions — is the same work with forty times the clicking and forty chances to pick the wrong preset once.

Preparing Files So the Batch Runs Clean

Half an hour of preparation saves the batch from its most boring failures:

1. Work from the best copies you have. Masters or first-generation exports, not the MP3s downloaded back from your host. Every encode generation costs peaks and detail; loudness work deserves the cleanest source available.
2. Name files so the report reads like a list. Episode numbers in the names make the combined report scannable and the flags actionable. "Ep014" beats "final_mix_june (2)".
3. One format per batch where you can. A batch of all-WAV or all-MP3 behaves predictably; mixed formats are supported, but uniformity removes a class of surprises.
4. Exclude anything still being edited. Put the batch folder together as a deliberate act: these files, final, no exceptions. Files added "because they were nearby" are how works-in-progress get certified and shipped.
5. Check total duration against your plan. Forty 45-minute episodes are 30 hours of audio. Run the arithmetic against your monthly minutes before the run, and split by season if needed.

None of this is glamorous. All of it is the difference between a batch that finishes while you make coffee and a batch that becomes next weekend's project.

Reading the Batch Report Like a Producer

The combined report is the product of a batch run; learn to read it in layers:

• The spread column first. Before values tell you your history: a catalogue spanning 12 LU has a story, and the pattern of it (by season, by producer) tells you where your current workflow still leaks.
• The flags second. Only flagged files need ears. A batch that flags 3 of 40 is healthy; a batch that flags 30 of 40 means the sources have a systemic problem worth fixing at the source for future episodes.
• LRA as the smoke detector. Batch runs surface the unbalanced episodes you forgot about. High-LRA flags are tomorrow's listener complaints, visible today.
• Keep the report. Filed with the catalogue, it is the answer to every future "didn't this episode used to be louder?" — and the baseline your next batch compares against.

Keeping New Episodes Consistent

A batch fix solves the past. For the future, add one line to the publish checklist — measure, normalize to the house target, file the report — and use the single-episode workflow in the -16 LUFS guide. Consistency is a habit with a number attached.

The deepest version of the habit: normalize at the end of production for every episode, so the archive is born consistent and batch passes become a yearly audit instead of a rescue. Producers who do this describe the batch tool differently — not as the fix, but as the proof. Run the catalogue once a year; a clean report across the board is the certificate that your per-episode routine is actually working.

What Batch Costs on LoudNorm

Batch is a paid-plan feature, because a season's worth of audio is real processing time. The free plan covers 60 minutes a month — enough to keep a current show consistent episode by episode, with the same measurement and report. Starter ($9) covers 10 hours a month; Pro ($19) covers 30 hours a month, which swallows most back catalogues in a single month. No plan, free included, adds a watermark or a jingle to your files: the difference between plans is minutes and batch, never the quality of the result.

Common Mistakes

Normalizing files you are about to re-edit. Loudness is measured on the final file. A batch run over works-in-progress certifies numbers that the next edit destroys.

Letting the batch include mixed channel counts blindly. A batch with stereo and mono episodes needs the target rule applied per file — stereo to -16, mono to -19. A batch tool that detects channels handles it; a single blunt preset does not. Check the report's target column for the mono episodes specifically.

Re-running the whole batch to fix three files. Pull the flags, repair them, run a small batch of just those. Re-running everything re-processes good files, wastes your minutes, and risks a wrong-preset accident on files that were already right.

Trusting filenames over measurements. "Final_v2_REALLYFINAL" is not evidence. The report measures the bytes you uploaded; if an old mix slipped into the folder, its numbers will betray it — another reason to read the before column.

Publishing the batch without spot-listening anything. Numbers catch loudness; only ears catch the wrong episode entirely, a corrupted file, or a render missing a channel. Listen to the flags and to a random sample of the clean files — five minutes of listening insures the whole run.

Frequently Asked Questions

Will batch normalization change how my episodes sound? Only their level. Each file gets one clean gain change plus, where needed, limiting on its highest peaks — the same processing as a single-file normalization, because it is single-file normalization, repeated. Character, balance and dynamics within an episode are untouched.

What if my catalogue mixes podcasts and video versions? Normalize the audio masters for the podcast feed at the podcast target; handle video soundtracks at the streaming target (-14) as their own batch. Two batches, two reports, no cross-contamination.

How big can a batch be? Practically, as many files as your plan's monthly hours cover. For a very large archive, run it season by season and file each report; if a season's flags suggest a systemic problem, you will see it before processing the rest.

An old episode cannot reach the target — the report flags it every time. That file has a peak or noise problem, not a batch problem. The hot ones need their peaks softened; the quiet ones need the repair order. After repair, they normalize like everything else; if one truly cannot, accept a documented near-miss rather than distorting it onto the number.

Should I re-batch after changing my target? If your show moves from the -16 podcast convention to a -14 streaming-first strategy, yes: one batch run re-bases the catalogue so old and new episodes agree. Changing targets without re-basing the archive rebuilds the very drift you fixed, one new episode at a time, until a listener writes in again.

Does my host re-normalize episodes anyway? Some platforms adjust playback loudness, but they adjust from your file: a consistent catalogue gives every platform the same starting point, and platforms that do not normalize — plenty of podcast apps among them — play your file exactly as published. Your consistency is the only copy of consistency that exists everywhere your show is heard.

References

• https://www.apple.com/apple-podcasts/ — Apple Podcasts, whose -16 LUFS convention is the usual batch target.
• https://www.itu.int/rec/R-REC-BS.1770 — ITU-R BS.1770, the measurement every file in the batch is judged by.
• https://tech.ebu.ch/publications/r128 — EBU R128, the broadcast loudness framework.