Before you assemble a YouTube playlist stream, measure each complete audio file and normalise it towards the same chosen loudness target with a true-peak ceiling. FFmpeg’s loudnorm filter supports a double-pass workflow: analyse each file first, then use its measurements when processing that file.
That target is a production choice, not a universal YouTube requirement. A shared measurement can make a playlist more consistent, but it cannot make different performances, arrangements or transitions sound equally loud in every listening situation.
Spot uneven levels in the playlist
Listen to the files in the order in which they will play. An abrupt jump from a quiet devotional recording to a loud one, for example, may be more noticeable than either file sounds on its own. The same can happen between a spoken introduction and a music track, or between a soft piano study piece and a denser recording.
Do not diagnose this by looking only at waveform height or sample peaks. A short drum hit can reach a high peak while the rest of the track is quiet; a sustained organ or tanpura may feel strong without having the same peak shape. Peak matching alone therefore does not tell you how the full files compare in perceived loudness.
Start with a practical listening pass. Note where you reach for the volume control, where speech becomes hard to hear, and whether a track’s opening is unusually quiet compared with what follows. Keep those observations alongside measurements rather than treating either as the whole answer.
Integrated loudness summarises the programme over time, while loudness range describes variation within it. True peak estimates peaks between digital samples, which can matter after encoding. These measures answer related but different questions. A shared integrated-loudness target can guide overall matching, and a true-peak ceiling can constrain peaks, but neither removes intentional dynamics or repairs a poorly edited transition.
If your channel is built around a particular kind of programme, keep that listening context in view. A long bhajan set, a piano study station and a sequence of local news segments do not need identical dynamics just because they are going into one playlist. The practical goal is to avoid unintended level changes while retaining meaningful differences in the material.
For a devotional programme, first decide which recordings belong together and how listeners will encounter them. The guidance in looping a Hindi devotional playlist on YouTube Live can help with playlist structure; the audio work here is about making the files less jarring when that sequence repeats.
Prepare files and identify their audio streams
Make a working copy of the source files before processing. Keep originals untouched so you can return to them if a conversion clips, a stream selection is wrong, or a later listening check reveals that your processing has changed the character of a recording. Use clear filenames for originals and outputs, and keep the playlist order in a separate note or manifest.
Check each file’s streams before you run a batch. A video file may contain more than one audio stream, such as a language track, commentary mix or alternate programme feed. If you analyse one stream and render another, the measurements will not describe the audio you actually put on air. Use ffprobe or another media inspector to identify the intended stream, channel count, sample rate and duration.
Mixed inputs require attention. Some files may be stereo, others mono; some may have multiple channels or contain silence at the beginning. Confirm that the intended programme is present and that the channel layout makes sense. Do not blindly force every source into the same channel layout before understanding what it contains.
Decide whether the files form one listening programme or several distinct ones. A common target is most useful when the tracks are intended to sit together. If a playlist alternates music, announcements and field recordings, you may prefer separate target choices for those groups, or simply retain a deliberate contrast. Processing should support the programme, not erase its editorial intent.
Make an inventory with one row per file: filename, intended audio stream, duration, source format, channel layout, and any known issue. Add columns for analysis values and rendered output checks. This makes it easier to catch a missed file or a duplicate before a long-running channel uses the final playlist.
Audio by itself cannot be uploaded to YouTube as a video. You need to package it with a visual, such as a still image or other video material, using an editing or encoding workflow. YouTube’s recommended upload encoding settings cover matters such as supported audio codecs, sample rate and channel configuration. Check the current page for the delivery you intend to make rather than assuming that normalisation settings also determine upload compatibility.
Run the first loudnorm analysis pass
The analysis pass measures the entire file without creating your final normalised version. FFmpeg documents loudnorm for loudness analysis and normalisation, including double-pass operation for files. Read the FFmpeg filters documentation for the option names and behaviour supported by the version installed on your system.
Choose the target integrated loudness and maximum true peak for your programme before processing. Use the same values for files that are meant to belong together, but do not treat a tool default, a published example or a value chosen for another channel as a rule for yours. YouTube’s upload guidance specifies encoding settings; it does not establish a universal integrated-loudness target for a creator’s playlist.
A basic analysis command has this form, with the input stream selected as needed:
ffmpeg -i "input.wav" -af "loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json" -f null -
The numeric settings in this example are illustrative choices for demonstrating command syntax, not a recommended target for every playlist or a YouTube specification. Select values appropriate to your material, test them on representative files, and consult the FFmpeg documentation for parameter ranges and the exact behaviour of your installed version. In a batch, keep the chosen settings consistent across files intended for the same programme.
The output includes measurements such as input integrated loudness, input loudness range, input true peak and measured threshold. Capture the complete report for each file. The values from one file must not be copied into another file’s processing command: each file has its own measurements. Keep the original filename and the stream selection with the report so you can match the data to the right source.
Analyse the complete programme, not a convenient short excerpt. An excerpt may miss a loud chorus, a quiet introduction or a section with very different dynamics. For a very long file, any alternate sampling or segmentation method should be deliberate and documented; it is not equivalent to measuring the whole file unless you have verified that it represents the programme.
The report is also a diagnostic. A very different integrated value from the other tracks may point to a genuine source-level difference, but it can also reflect silence, an unusual arrangement or a stream-selection mistake. Listen to questionable inputs before deciding that the number alone calls for more processing.
Use the measurements in the second pass
For each file, run loudnorm again with the same integrated-loudness and true-peak targets, and supply the measured values from that file’s analysis report. In FFmpeg these measured inputs include integrated loudness, loudness range, true peak and threshold. The filter documentation describes the relevant options; copy values carefully, preserving the decimal signs and using the measurements from the matching source.
A command template for a stereo output might look like this:
ffmpeg -i "input.wav" -map 0:a:0 -af "loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=INPUT_I:measured_LRA=INPUT_LRA:measured_TP=INPUT_TP:measured_thresh=INPUT_THRESH:linear=true:print_format=json" -ar 48000 -c:a aac -b:a 192k "output.m4a"
This is a template, not a ready-to-run prescription: replace the INPUT_... placeholders with that file’s reported measurements, set the intended audio stream, and choose an output format and bitrate for your packaging workflow. The example target values and encoding options are not a universal recommendation. Check current YouTube upload guidance and your editing workflow before settling on delivery settings.
The linear request does not mean the filter can always apply only a constant gain and satisfy every requested condition. FFmpeg notes that linear normalisation requires measured inputs and may fall back to dynamic mode if the requested change cannot meet the loudness, loudness-range and true-peak constraints together. Read the second-pass report, including its indicated normalisation mode, instead of assuming that setting linear=true guarantees gain-only processing.
This distinction matters for material whose dynamics are part of the performance. Dynamic processing can alter the relationship between quieter and louder passages. If a result sounds compressed or otherwise unlike the source, revisit the chosen target and constraints, or use a less aggressive workflow. Do not chase a numerical match at the cost of a programme that no longer sounds right.
For a command-line batch, treat each report as an input record rather than relying on a single long command with hand-edited values. Keep a processing log with source name, stream selection, targets, measured values, output filename and the filter report. A small script can substitute values from a structured manifest, but first test it on a few files and inspect the commands it generates. A filename mismatch can quietly apply one recording’s measurements to another.
Re-measure the rendered outputs
Do not assume that a successful FFmpeg exit means the output has the intended loudness. Run an analysis pass on every rendered file and record its integrated loudness, loudness range and true peak. Compare the output measurements with your chosen targets and inspect any file that differs unexpectedly. Re-measurement checks the artefact you will actually use, not just the source and processing request.
Listen to a few outputs as well. Check the opening, a representative middle section and the ending, especially when a source contains a fade or silence. Listen for distortion, pumping, an unexpected change in dynamics, or a channel that has disappeared. Measurements can help locate a problem; they cannot tell you whether a vocal has become difficult to understand or whether a quiet devotional passage should remain quiet.
Confirm the output’s codec, sample rate and channel layout against the rest of your programme. The example command above creates an audio file, which still needs to be combined with video for YouTube upload. YouTube re-encodes uploaded videos, so use its current published settings as delivery guidance and keep a clean pre-upload master in case you need to revise the package.
Check stereo phase and mono compatibility before release. YouTube’s guidance on troubleshooting audio or video issues with uploads notes that poor mono compatibility can affect audio when stereo is converted to mono, and recommends checking that audio is in phase. This is especially worth checking if your audience may listen on a single speaker or a phone with mono playback. A stereo mix that cancels important content in mono may sound thin or lose elements even when loudness values look sensible.
Keep an untouched copy of the final files and the processing log. If you later change a target, FFmpeg version or playlist order, you can identify which outputs need to be rebuilt and compare what changed. When a channel runs continuously, predictable source preparation matters: a single bad file can return every time the playlist loops.
Listen to transitions in playlist order
Play the rendered files in their actual order, with the same fades, gaps or crossfades you plan to use on air. A track ending in a long fade into a quiet introduction may still feel like a dip even if the integrated measurements are close. Conversely, two tracks can measure similarly but sound different because one is sparse and one is dense, or because speech and music occupy different parts of the spectrum.
Check transitions at normal listening level, not only while watching meters. Give extra attention to changes in programme type: a news voice into a music bed, a chant into instrumental music, or a quiet ambience recording into a full arrangement. Note whether a transition is intentional, needs an edit, or calls for a modest adjustment to one file. Avoid raising an entire track just to compensate for a single quiet opening if that makes its louder section uncomfortable.
If a transition needs a change, edit the relevant region or use a carefully chosen fade rather than repeatedly altering every track’s target. Then render and measure the revised file again. Keep a note of the reason for the adjustment; this helps you distinguish an editorial choice from an accidental mismatch when the playlist is updated later.
Viewer-side playback features are not a substitute for preparing the source. YouTube describes Stable volume as a playback control available in some viewing contexts; it is not a source-file normalisation workflow, and availability or behaviour can change. Prepare the playlist yourself and check the current official information rather than depending on a viewer setting to correct your mix.
This finishing work sits alongside the streaming setup, not inside it. If you are building a channel from pre-recorded music, the practical outline in creating a 24/7 YouTube piano study music radio channel provides a useful programming context. If your route to a continuous broadcast involves a local machine, OBS versus FFmpeg for streaming an internet radio station to YouTube discusses the separate choice of broadcast software; neither replaces checking the prepared audio files.
Once the files have been checked and the visual package is ready, the remaining question is how you want to keep the channel broadcasting. If the pain is leaving a computer on overnight and noticing a dropped broadcast only in the morning, StreamNeo can take the prepared video and run the YouTube stream while your own computer is off, with monitoring and automatic restarts if it drops. It is YouTube-only, so it is not a fit if you need the same workflow to publish to another platform.
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
Does YouTube require a particular LUFS target for every playlist?
No universal playlist-wide integrated-loudness target is set out in the cited YouTube upload settings. Choose a target for your programme and workflow, then check YouTube’s current official guidance for encoding and upload requirements.
Why use two passes instead of matching peaks?
Peak matching controls sample-level peaks but does not measure how loud the complete files are perceived over time. In a double-pass workflow, the first pass measures each full file and the second uses those measurements to guide normalisation, while a true-peak ceiling constrains peaks.
Will matching integrated loudness make every transition sound equally loud?
No. Arrangement, dynamics, silence, fades and the contrast between speech and music all affect how a transition feels. Re-measure the rendered files, then listen to them in playlist order and make editorial adjustments where needed.
Can I upload the processed audio file directly to YouTube?
No, YouTube requires a video rather than an audio-only upload for this workflow. Combine the audio with a visual in an editing or encoding tool, and check YouTube’s current recommended upload settings for the finished video.