If you want to normalize podcast audio before streaming it on YouTube 24/7, process the recorded episodes first, then configure the live encoder separately. Loudness normalization controls how the programme is perceived; bitrate, sample rate and keyframes control how the stream is delivered.
A reliable workflow is to measure a representative group of episodes, normalize them with true-peak management, listen to quiet and loud passages, assemble the processed files into a continuous sequence, and then test the actual YouTube feed before leaving it running.
What normalization does, and what it does not do
Normalization changes the level of an audio programme so that episodes sit closer together in perceived loudness. It can use measurements such as integrated loudness, loudness range and maximum true peak rather than relying only on the highest sample value.
That distinction matters for podcasts. A short cough, loud laugh or music sting may create a high sample peak without making the whole episode sound loud. Another episode may have a lower peak but a much higher average speech level. Comparing peaks alone can therefore produce a playlist that still jumps in volume between episodes.
Normalization does not repair a poor recording. It will not remove room noise, fix a distorted microphone, make distant speech clear, balance two speakers automatically or restore detail that was clipped during recording. If an episode is already damaged, treat that as a production problem rather than expecting a loudness filter to solve it.
It also does not guarantee that every listener will hear identical volume. Phones, televisions, headphones, browser settings and YouTube playback behaviour all affect the final result. The practical aim is narrower: make your own library more coherent while preserving enough of the programme's natural dynamics.
Keep source loudness processing separate from live encoder settings. A 128 kbps audio stream is not automatically louder or quieter than a 96 kbps stream. Bitrate describes how much data is allocated to the encoded audio; it is not a loudness target.
This separation also makes troubleshooting easier. If one episode sounds much louder than another, inspect the files and their processing. If the stream has crackling, interruptions or a failed connection, inspect the encoder, network and YouTube ingest path instead.
Inspect and measure your episodes
Start with the files, not the live stream. Make a list of the episodes you intend to broadcast and note their format, channel count, sample rate and approximate duration. You do not need to change every file immediately, but you do need to know whether the library contains speech-only episodes, music-led introductions, long pauses or unusually loud adverts.
Measure a representative set rather than only the first episode. Include the quietest episode you already know about, the loudest one, a typical episode and any episode with a different presenter or recording location. If your channel includes music between programmes, measure those transitions as well.
A full-episode measurement gives you a better view of programme loudness than a short extract. Short samples can miss a quiet interview section or a loud opening. If your tool cannot process the entire library at once, begin with representative portions and then check the final output files after processing.
Useful measurements include:
| Measurement | What it tells you | What it does not tell you |
|---|---|---|
| Integrated loudness | The overall perceived level across a programme | Whether every moment has the same level |
| Loudness range | How much the programme varies over time | Whether the variation is artistically appropriate |
| Maximum true peak | Whether the signal may create an over during conversion or playback | Whether the episode sounds loud overall |
| Sample peak | The highest stored sample value | How loud speech feels compared with another episode |
FFmpeg's loudnorm documentation describes EBU R 128 loudness normalization and exposes controls for integrated loudness, loudness range and maximum true peak. You can use it to inspect and process files, but read the output rather than assuming that a command has produced a good result.
Create a simple record for each episode. The file name, measured loudness, measured true peak, chosen output name and listening status are enough for a first pass. If you later change your editorial target, you can identify which files need to be reprocessed instead of starting with an uncertain collection.
Do not normalise each sentence or each short pause independently. That can flatten the relationship between a presenter's quiet explanation and an emphatic line. Episode-level consistency is usually more useful for a continuous channel than forcing every moment to the same level.
Choose a loudness approach and manage true peaks
For a prerecorded podcast, you have time to measure the source and then process an output file. This is different from a live microphone or an incoming live programme, where the signal must be treated as it arrives.
FFmpeg documents both single-pass and double-pass use of loudnorm. A single pass can be useful for a livestream or a simple file workflow. A file-based two-pass process can first measure the programme and then use those measurements when creating the final file. The second approach gives you more information to review, but it adds a measurement step and another opportunity to manage files correctly.
| Approach | Suitable when | Main trade-off |
|---|---|---|
| Single-pass processing | You need to process a live signal or want a straightforward file pass | Less opportunity to use measured file-specific values before rendering |
| File-based two-pass processing | Episodes are available before broadcast | More preparation, but better visibility into the result |
| Real-time processing | The source arrives live and cannot be rendered in advance | Processing must react immediately, so auditioning the final programme is limited |
| Pre-normalized files | You have a stable catalogue of recorded episodes | You must reprocess files when your editorial approach changes |
There is no official YouTube podcast LUFS target established by the encoder settings page. You should choose an editorial target for your own catalogue, then listen to the result in a test stream. The target depends on the source material, the balance between speech and music, the amount of natural dynamics you want to retain and whether the same files will be used elsewhere.
The European Broadcasting Union's EBU R 128 publication recommends average programme loudness of −23 LUFS in its broadcast context and refers to Loudness Range and Maximum True Peak Level descriptors. That is a broadcast recommendation, not evidence that YouTube requires −23 LUFS for a podcast livestream.
If you use −23 LUFS as a starting editorial reference, label it in your notes as your chosen reference rather than a YouTube rule. You may decide that another level suits your library after listening. Do not choose a number simply because it appears in a forum post claiming to know YouTube's universal podcast setting.
True-peak management is a separate decision. A programme can meet an integrated loudness target and still create peaks that are troublesome during sample-rate conversion or lossy encoding. Set a true-peak ceiling appropriate to your workflow, inspect the measured output, and listen for changes introduced by limiting or dynamic processing.
An illustrative FFmpeg starting point is:
ffmpeg -i episode.wav -af "loudnorm=I=-23:LRA=7:TP=-2" -ar 44100 -c:a aac -b:a 128k episode-normalized.m4a
This is an example configuration, not a tested universal preset. The −23 LUFS value reflects the EBU broadcast reference described above, not a YouTube requirement. The loudness range and true-peak values are example parameters, not values prescribed by YouTube. Measure the output and audition it before using the command for a catalogue.
Keep your original masters and export separate stream copies. Check that your FFmpeg build includes the filter and that the output opens correctly. FFmpeg notes that linear normalization can revert to dynamic mode when the measured conditions cannot satisfy the requested limits. That is one reason to inspect the output rather than assuming the requested settings were applied in exactly the way you expected.
Listen across quiet, loud and transition sections
Numbers narrow the problem, but they do not replace listening. Choose a quiet speech passage, a normal conversation, the loudest sustained section and the transition into or out of music. Listen to the processed file at a normal playback level, then compare it with the original without changing your listening level between files.
In a quiet section, check whether speech remains understandable without raising the level so far that room noise becomes distracting. In a loud section, listen for pumping, harshness, flattened emphasis or audible distortion. A limiter or dynamic mode can change the character of a recording even when its measurements appear orderly.
Transitions deserve their own check. Play the final moments of one episode followed by the opening of the next. Also test a spoken episode followed by music and music followed by speech. A library can have acceptable individual files yet feel inconsistent when heard in sequence.
Long silences need attention too. A podcast may intentionally pause, but an accidental silent tail can make listeners think the stream has stopped. Do not remove every pause automatically. Mark unusually long or unexpected silence for editorial review, then decide whether the source should be trimmed or replaced.
If two speakers remain very different within one episode, loudness normalization alone may not be enough. You may need separate dialogue editing, compression or a new mix. Those processes affect tone and dynamics, so make a change on a copy, render it, and listen again. The goal is not to make every voice identical; it is to avoid forcing the listener to adjust the volume repeatedly.
Build a continuous playback sequence
Once the files have passed measurement and listening, create the sequence that the live system will play. Use the normalized outputs, not a mixture of original and processed files. A single unprocessed episode can reintroduce the level jump you were trying to remove.
Choose a predictable naming scheme and keep the stream copies in a separate folder. For example, retain the original recording as the archive, place the processed version in a broadcast folder, and keep a small text record of the processing settings. This makes it easier to replace one episode without accidentally selecting the wrong export.
Decide how the sequence should behave at the end. A playlist can return to the beginning, continue into a new batch or hand off to another set of files. Check that the playback system does not insert an unexpected gap, repeat one file indefinitely or stop when it reaches the last item.
If you are building a file-driven system, the guide on streaming a playlist of videos 24/7 with FFmpeg explains the wider playlist problem. Its purpose is different from loudness processing, but the distinction is useful: first prepare dependable media, then make the playback process continuous.
A cloud workflow can remove the need to leave your own computer running overnight. With StreamNeo, you upload the prepared video, paste the YouTube stream key and let the channel continue while the service monitors and restarts the broadcast if it drops. That does not replace checking your audio files or YouTube preview, and it does not decide the editorial loudness target for you.
Keep a recovery copy of the playlist and the processed media. If the stream stops, you should be able to identify whether the issue is a missing file, a failed playback loop, an audio export problem or the live connection. A written sequence is more useful at two in the morning than a collection of files with ambiguous names.
Set YouTube-supported audio encoding separately
After the files are prepared, configure the live encoder for delivery to YouTube. YouTube's live encoder settings guidance lists AAC or MP3 audio, 44.1 kHz stereo and 128 kbps stereo among its advanced stereo recommendations. It also recommends constant bitrate encoding and a two-second keyframe interval, with the interval not exceeding four seconds, for the live stream settings described there.
These are transmission settings. They do not tell you how loud the podcast programme should be. Changing the audio bitrate will not normalise an episode, and changing the sample rate will not fix a loudness difference between presenters. Apply loudness processing to the source files, then use the delivery settings consistently.
For the ingest connection, YouTube recommends RTMPS for encrypted transmission in the same guidance. Use the protocol supported by your encoder and account setup, and copy the stream key carefully. A correct audio export cannot compensate for a wrong key or a stream configured for a different destination.
The final encoded audio should be checked after the encoder has processed it. A source file can sound clean while the live configuration introduces a channel mismatch, unexpected resampling or silence. Keep the encoder configuration simple enough that you can identify each change.
If the video side of the stream is also causing trouble, do not raise bitrate blindly. The explanation of why a YouTube live stream can look blurry at high bitrate is relevant because delivery quality depends on more than choosing a larger number. Audio loudness and video sharpness should be diagnosed as separate problems.
Test the preview and monitor the stream
Run a test before committing the catalogue to an overnight broadcast. Send representative content that includes speech, music, a quiet passage, a loud passage and at least one episode transition. YouTube specifically advises testing with audio and movement similar to the intended live content.
Open the Live Control Room preview and listen to the actual feed, not only the local file. Use the same type of playback device your audience is likely to use where practical, but also check headphones if you need to hear distortion or clicks. Keep the listening volume fixed while comparing sections.
A practical test checklist is:
- The first episode begins with audio rather than an unexpected silent lead-in.
- Speech is understandable at a normal playback level.
- The loudest section does not audibly clip or become harsh.
- The transition into music and the next episode does not produce a sudden jump.
- The playlist continues after the first file and returns correctly at the end.
- The preview shows the expected audio channel arrangement.
- The stream does not show unexpected silence, repeated files or a stalled video.
- The upload connection has room beyond the configured stream bitrate.
YouTube's live streaming tips advise testing before a stream, keeping upload bitrate within available outbound bandwidth and allowing headroom. The same guidance recommends continuously monitoring audio and video quality. Treat that as an operating task rather than something completed when the first preview looks acceptable.
During the first overnight run, check the beginning, an episode transition and a later section. Look for dropped connection notices, unexpected silence, clipping, a frozen picture or a loop that fails after the first cycle. If you cannot listen continuously, arrange periodic checks and keep a short procedure for stopping, correcting and restarting the stream.
A separate restart plan is useful because a good loudness workflow does not prevent every operational failure. The guide on restarting a YouTube live stream automatically after it ends covers that part of the problem. It should complement, not replace, testing the media and monitoring the actual broadcast.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How do I normalise podcast audio before streaming it on YouTube 24/7?
Measure representative episodes, choose one editorial loudness reference, process the files with integrated loudness and true-peak controls, and listen to quiet, loud and transition sections. Then use only the checked outputs in the continuous playlist and test the encoded feed in YouTube's preview.
What LUFS should podcast audio be for a YouTube livestream?
YouTube's encoder guidance does not establish one podcast-specific integrated-loudness requirement. The EBU's −23 LUFS recommendation is a broadcast reference, not a stated YouTube rule, so choose a target for your catalogue and evaluate it by measurement and listening.
Can FFmpeg normalise audio for a continuous stream?
Yes. FFmpeg's loudnorm filter supports loudness, loudness-range and true-peak controls, with single-pass use for live signals and file workflows and a two-pass approach for files. It cannot repair a poor recording, and the rendered result still needs to be measured and auditioned.
Does a higher audio bitrate make a podcast louder?
No. Bitrate allocates data to the encoded audio and does not set programme loudness. Loudness is handled during source processing, while bitrate, codec, sample rate and transport settings belong to the live delivery stage.