Compress a Podcast Episode Without Wrecking the Voice

Measured on a 64.185-second two-voice speech fixture, 44.1 kHz 16-bit stereo, 11,322,238 bytes. Per-hour figures are computed from the bitrate each encoder actually delivered, not from the rate we asked for. Machine: Apple M2 Pro, macOS 27.0 (build 26A428), 26 September 2026.

Apple states its accepted range plainly in the Apple Podcasts audio requirements: for RSS feeds, MP3 or AAC at “64–128 kbps” mono or “128–256 kbps” stereo, at 44.1 or 48 kHz. That is the constraint most shows are actually working inside, and 64 kbps mono AAC sits at the efficient end of it.

The Opus rows are not our opinion either. Xiph, who wrote the codec, publish a recommended settings table listing “Audiobooks / Podcasts” at 24 kbps for one channel and 32 kbps for two. Our measurements land on exactly those numbers because that is what we asked for and libopus delivered it.

Only if you also change the bitrate, which is what everyone who repeats the claim is unknowingly doing. Here is the same speech fixture encoded three ways, stereo against its own mono downmix:

Three of those rows say mono changes nothing and three say it halves the file. Both are true, and the difference is whether you named a bitrate.

A bitrate is a byte budget. If you fix it at 64 kbps, you get 64 kbps of bytes whether that budget is describing one channel or two. The AAC row where mono came out larger is the same effect from the other side: the encoder had one channel to spend a stereo-sized budget on and slightly overshot, delivering 35,011 bps against a 32,000 request.

Where -ac 1 genuinely halves the output is when nothing is pinned. ffmpeg with no flags picks 128 kbps for stereo and 64 kbps for mono, which is exactly the 50.0% we measured. That is a default doing the work, not the channel count.

None of which makes mono a bad idea. It is the right call for a single-microphone recording, because a dual-mono stereo file stores the same signal twice for no benefit, and because it lets you spend 32 kbps where you would otherwise spend 64. Just write the instruction correctly:

# right: mono AND a lower bitrate
ffmpeg -i episode.wav -ac 1 -c:a aac -b:a 48k episode.m4a

# wrong: mono at the stereo bitrate buys nothing
ffmpeg -i episode.wav -ac 1 -c:a aac -b:a 128k episode.m4a

One caveat worth knowing if you publish to Apple. For the WAV and FLAC files submitted through Podcasts Connect, Apple requires that “If a stereo audio source exists, it must be used.” The mono advice applies to the compressed file in your RSS feed, not to a master you deliver to Apple.

Not to save space, because it does not. This is the second thing podcast guides get wrong. We encoded the same mono speech at a fixed 48 kbps from five different sample rates:

The MP3 column spans 216 bytes across a nearly threefold change in sample rate, which is 0.06%. At a fixed bitrate the byte budget is fixed, full stop. What changes is how the encoder spends it: fewer frequency bands to describe means more bits per band, so a lower sample rate can sound better at a very low bitrate, at the cost of a hard ceiling on treble.

Sample rate does drive file size when the audio is uncompressed or lossless, where the arithmetic is exact:

Keep your master at 44.1 or 48 kHz because that is what Apple accepts and what your editor is already working in, and let the encoder decide what to throw away. The one exception: if your host caps you at something brutal like 32 kbps mono, dropping to 24 kHz first is a defensible move. The full arithmetic behind all of this is in audio bitrate explained.

Opus sidesteps the question. It resamples everything to 48 kHz internally, so every Opus file we produced reported 48,000 Hz regardless of what went in.

Two authorities, two numbers, and they are measuring different things. It is worth getting this straight because most pages quote one and attribute it to the other.

Apple Podcasts states that “The overall loudness remains around -16 dB LKFS, with a +/- 1 dB tolerance” and that the “true-peak value doesn’t exceed -1 dB FS”, measured per ITU-R BS.1770-5. LKFS and LUFS are the same unit. That is a target for the finished episode, and it is the one to aim at.

AES TD1008 (document AESTD1008.1.21-9, Recommendations for Loudness of Internet Audio Streaming and On-Demand Distribution, 24 September 2021) sets -18 LUFS with a +1 LU tolerance for its “Assorted” category, whose footnote explicitly covers “podcasts containing speech, music and/or effects elements”. Its measurement method is Dialog Integrated Loudness rather than plain integrated loudness, and its audience is streaming distributors rather than individual producers.

A note on a figure you will see everywhere: the frequently quoted “-16 LUFS stereo, -19 LUFS mono” pairing does not appear in TD1008. We checked the document. The -19 is community convention, not a published standard, and we are not going to cite it as one.

Measuring is one command. Our raw fixture came back at -23.7 LUFS integrated, 6.9 LU loudness range, true peak -7.9 dBFS, which is a normal unmastered level:

ffmpeg -i episode.wav -filter_complex ebur128=peak=true -f null -

Correcting it properly takes two passes. The first measures, the second applies the measurements, which lets loudnorm work linearly instead of riding the gain. loudnorm gates slightly differently from ebur128 and reported -23.82 LUFS, 7.10 LU and -7.87 dBTP on the same file, which is why the numbers in pass two are not identical to the ones above:

# pass 1 — read the numbers
ffmpeg -i episode.wav -af loudnorm=I=-16:TP=-1.0:LRA=11:print_format=json -f null -

# pass 2 — feed them back in
ffmpeg -i episode.wav -af \
  loudnorm=I=-16:TP=-1.0:LRA=11:measured_I=-23.82:measured_TP=-7.87:\
measured_LRA=7.10:measured_thresh=-33.94:offset=1.50:linear=true \
  -c:a aac -b:a 64k -ac 1 episode.m4a

That landed our fixture at exactly -16.0 LUFS integrated with a -1.0 dBFS true peak, inside Apple’s stated tolerance, with the loudness range tightened from 6.9 to 6.0 LU.

For contrast we also tried the lazy version, a flat volume=7.87dB to push the peak to full scale. It landed at -15.8 LUFS and -0.0 dBFS. On uniformly dense speech that is close to the target by luck, and the problem is the headroom: after MP3 encoding, the loudness-normalized file decoded at -1.4 dBFS and the peak-normalized one at -0.4 dBFS. We did not observe clipping on this fixture, so we will not claim we did, but the margin is the entire reason the -1 dBTP ceiling exists. Lossy codecs do not reproduce peaks exactly, and a file mastered to 0.0 dBFS has nowhere to put the overshoot.

Loudness correction changes no bytes. All three versions of our WAV were 11,322,238 bytes. Normalize first, encode second, and the two steps never fight.

The honest answer is not about how they sound at 128 kbps, where the argument is subjective and the difference is small. It is that at the bitrates speech actually wants, MP3 cannot participate. Asked for low bitrates on 44.1 kHz stereo speech:

MP3 has a hard 32 kbps floor at 44.1 kHz and clamps silently: our 16, 24 and 32 kbps requests produced three byte-identical 257,193-byte files with no warning. Apple’s AAC encoder refuses to go under roughly 64 kbps for 44.1 kHz stereo and at least says so out loud: [aac_at] Bitrate 32000 not allowed; changing to 64000. Mono halves that floor to 32,006 bps. Opus delivered every rate we asked for, down to 17 kbps.

One libopus trap to know before you budget bytes. ffmpeg defaults libopus to unconstrained VBR, where -b:a is a target rather than a ceiling. Asked for 64 kbps stereo it delivered 82,128 bps, a 28% overshoot and a 658,988-byte file. Adding -vbr constrained brought it to 64,601 bps and 518,359 bytes. If your host has a size limit, be explicit.

The practical constraint on Opus is distribution, not quality. Apple Podcasts lists MP3 and AAC for RSS feeds, so unless you know your audience’s players handle Opus, AAC at 48 to 64 kbps mono is the setting that will not generate support email.

On the repetitive part. Smol took the fixture to mono Opus at 24 kbps and produced 193,989 bytes measuring 24,176 bps at 48 kHz, and to mono AAC at 48 kbps and 22.05 kHz for 412,756 bytes. Audio compression covers aac, m4a, mp3, wav, flac, ogg and opus, with bitrate from 16 to 512 kbps, sample rate from 8 to 192 kHz, and a mono or stereo channel setting.

Two findings you need before building a workflow on it. Asking for the opus output format gave us an AAC .m4a in testing, reproduced twice in isolation; the Opus encoder is reachable through the ogg output, which produced a genuine Opus stream byte-identical to ffmpeg -c:a libopus. And there is no loudness normalization. Smol is an encoder, not a mastering tool. The two-pass loudnorm above is still your job, and it has to happen first.

For a weekly show that is the shape of a pipeline, which is where the MCP server earns its place: Claude Code, Codex and Google Antigravity can drive Smol directly, each one click to enable in the AI access panel as of Smol 1.0.35, so “normalize then encode everything in ~/Episodes to 64 kbps mono AAC” becomes one instruction over a folder rather than a script you maintain. The tool surface and guardrails are on the Smol MCP page. Running the loop across a back catalogue is covered in batch converting audio on a Mac.

For podcast production, most of the time, and it would be dishonest to dress this up.

Your editor already does this. Any DAW, and every podcast host worth paying, exports at a chosen bitrate and channel count. If Logic, Audition, Reaper, Descript or Auphonic is already in your chain, adding an encoder to the end of it buys nothing.

Loudness is the part that matters, and we do not do it. An episode at the wrong loudness is a worse listener experience than an episode at the wrong bitrate, and the fix is free: two ffmpeg commands, or one pass through a normalization service. That is the single highest-value thing on this page and it is not our feature.

One episode: use afconvert or ffmpeg. afconvert -f m4af -d aac -b 64000 -c 1 in.wav out.m4a is installed on your Mac already. No purchase justifies one file.

Where we are useful is a back catalogue, or a show where audio lands beside cover art, transcripts and PDFs that all need squeezing in the same pass, with settings you set once. If that is the job, Smol is $29 once and runs entirely on your Mac with nothing uploaded. If it is one episode a week out of a DAW that already exports correctly, keep your $29 and spend the afternoon on the loudness pass instead. For the general format-and-bitrate decision beyond speech, compressing an audio file on a Mac is the broader page.