Podcast and Spoken-Word Audio

Podcast export settings in REAPER: format, bitrate, mono or stereo

By StudioRescue Editorial

Published September 17, 2026

Exporting an episode is the last five minutes of a job that took hours, which is exactly why it gets guessed at. REAPER's Render dialog has a lot of controls, most advice online is written for music, and the numbers people repeat are often copied from somewhere without a source. The result is a lot of 320 kbps stereo podcast files that are four times bigger than they need to be and sound no better.

This guide is specifically about the delivery settings for a spoken-word episode. If you have never opened the Render dialog before, start with how to export audio from REAPER, which covers the mechanics of the window itself. Everything below assumes you can already get a file out and you want to know what to put in the boxes.

Why a podcast export is a different job

A music master and a podcast episode are optimised for opposite things. A master is meant to be worked on again or to sound its best on good speakers, so it is large and lossless. An episode is meant to be downloaded over a phone connection, often on a commute, and listened to on earbuds or a kitchen speaker. Your file is going to be streamed thousands of times if things go well, and most of the people listening cannot tell 96 kbps mono speech from 320 kbps stereo speech.

So the goal changes. You are not chasing maximum quality. You are finding the smallest file that still sounds clean, because that is what your listeners and your hosting bandwidth actually experience.

Mono or stereo: the decision that matters most

This is the single biggest lever, and most home podcasters get it wrong by default.

A show that is people talking is, in practice, a mono recording. One microphone per person, each voice sitting in the centre, no left or right information that carries any meaning. Rendering that to a stereo file writes the same audio twice. At a fixed bit rate, a stereo MP3 splits that budget across two channels, so a 128 kbps stereo file is giving each channel roughly what a 64 kbps mono file would get on its own.

Simplecast, which hosts a large number of shows, states this plainly in its own encoding guidance: mono is recommended for spoken-word podcasts, including shows with music at the intro and outro, and stereo is for storytelling shows where sound design and effects genuinely move across the stereo field.

In REAPER's Render dialog, this is the Channels setting. Set it to Mono for a talking show. Your project can stay stereo; the render collapses it on the way out.

If your episode sounds like it is only coming out of one side rather than centred, that is a different problem and it happened at the recording stage. See how to fix a podcast recorded in mono or on one channel before you export anything.

Bitrate: what the platforms actually publish

This is where invented numbers are everywhere, so here is what the two biggest destinations put in writing.

Two things follow from that table. First, 96 kbps mono sits comfortably inside every published range and is a sensible default for a talking show. Second, there is no published requirement anywhere that asks for 320 kbps, and Simplecast notes that uploading at 128 kbps or less means it does not re-encode your file at all, so what listeners hear is what you rendered.

Treat these as starting ranges rather than laws. The honest test is the one Simplecast suggests: render the same episode at 64, 96 and 128 kbps, listen to all three on the device your audience actually uses, and take the smallest one you cannot fault.

Sample rate, and CBR versus VBR

Sample rate. Apple lists 44.1 kHz and 48 kHz as the recommended rates for podcast audio, so either is fine. Match whatever your project is already at rather than resampling on the way out. If you have no reason to prefer one, 44.1 kHz is the long-standing podcast convention and is what Simplecast's guidance uses.

CBR. Host guidance generally asks for constant bit rate MP3 rather than variable. Simplecast specifies CBR outright. Variable bit rate saves a little space, but it introduces a compatibility risk with older players and feed parsers reading episode duration, and the space you save on a speech file is not worth the chance of an episode showing the wrong length in someone's app. In REAPER's MP3 options, choose a constant bit rate mode and set the number.

Loudness, and the mono number that is not Apple's

Apple's own audio requirements ask for an overall loudness of around -16 dB LKFS, with a tolerance of about ±1 dB, and a true peak that does not exceed -1 dB FS, both measured per ITU-R BS.1770. That is the origin of the number everyone quotes. The full method for measuring and hitting it inside REAPER is in how to get your podcast to -16 LUFS in REAPER, including the render-time normalisation that does it for you.

Here is the part worth knowing before you render mono. You will see -19 LUFS for mono quoted constantly, and Simplecast publishes exactly that figure. That number does not appear in Apple's document. Apple publishes one figure and does not split it by channel count.

The reason the two figures coexist is a measurement quirk rather than a disagreement. BS.1770 loudness is summed across the channels present, so the same audio measured as a one-channel file reads roughly 3 LU lower than the identical audio duplicated across two channels. That is why Simplecast describes -19 LUFS mono as the same perceived loudness as -16 LUFS stereo. The two targets are aiming at the same result, applied to files with different channel counts.

Metadata: the step most people skip

ID3 tags are what podcast apps read to show your episode title, show name and artwork. REAPER can write them at render time, so there is no reason to use a separate tagging tool.

In the Render dialog, tick Embed: Metadata, click the Metadata button, and choose the ID3 scheme for an MP3. Simplecast recommends filling in artist, album, track name, year, a genre of "Podcast" and artwork so episodes display correctly across players including Apple Podcasts.

One caution in the other direction: Spotify for Creators asks you to keep embedded artwork, ID3v2 tags and other metadata as small as possible. A 3 MB cover image welded into every episode is pure overhead on every single download. Fill the fields in, keep the artwork modest, and do not embed anything you do not need.

Save it once as a render preset

This is the part that turns a fiddly twenty-setting dialog into a two-click job, and it is the main reason this article exists.

If you are already building repeatable pieces of your workflow, this pairs naturally with saved FX chains and track templates. The recording side and the delivery side both stop being decisions.

What these settings will not do

Export settings are the last step, and they are the weakest step. Being clear about that saves a lot of wasted rendering.

• A higher bitrate will not fix a bad recording. Room echo, hiss, plosives, uneven levels and a boomy voice all survive encoding intact. They just arrive in higher fidelity.
• Hitting a loudness target will not make an episode sound consistent. Integrated loudness is one number for the whole file. If your guest is quiet and you are loud, the file can hit the target exactly and still be uncomfortable. That is a balance problem, handled in matching host and guest loudness, before you render.
• Mono will not repair a one-sided recording. Collapsing to mono can hide the symptom while leaving one voice 3 dB down relative to where it should be.
• None of this is the audiobook spec. Audiobook delivery is a separate and stricter set of numbers. If that is your job, see how to meet ACX audiobook specs in REAPER.

If the exported file is wrong

1. It plays in one ear. The problem is in the session, not the render. Check the take channel mode before exporting again.
2. Your host re-encoded it and it sounds worse. You uploaded above the host's threshold. Render lower, at or under whatever the host publishes, so the file passes through untouched.
3. The app shows the wrong episode length. Re-render as constant bit rate.
4. Artwork or the title is missing in a player. Metadata was not embedded, or the wrong scheme was used. Re-render with the ID3 fields filled.
5. It is much quieter or louder than other shows. Measure integrated loudness rather than trusting the peak meter, and confirm whether your target assumes mono or stereo.