TV / Movies / Video - North Texas Radio

2001: A Space Odyssey (1968) – Clip – “I’m sorry Dave, I’m afraid I can’t do that”
Director and producer: Stanley Kubrick – 2:55

Posted on YouTube by
KlingonSpider

ReplayGain analyzes how loud a track sounds and tells the player how much to raise or lower it during playback. The audio file itself can remain unchanged (nondestructive), so the adjustment is reversible and does not require re-encoding. ReplayGain is a common standard, but it is not universal.

LUFS (Loudness Units relative to Full Scale) measures the average perceived loudness of audio over time. The numbers are negative because digital audio has a fixed maximum level of 0. A song at −15 LUFS is not being reduced by 15 dB; it simply measures −15 on that loudness scale. Its individual peaks may still rise close to the digital maximum, for example −1 or −2 dBTP.

Two songs can both peak near 0 dB but one might measure −9 LUFS and the other −18 LUFS. LUFS describes how loud the whole song feels, while peak measurements describe only its loudest moments.

NTR is streaming at -14 LUFS

Approximate range	Typical use	Main advantage	Main disadvantage
−27 to −23 LUFS/LKFS	Film and television	Maximum headroom and dynamics	Quieter average playback
−20 to −16 LUFS	Internet radio, podcasts, quieter music playback	Good dynamics with practical loudness	Can seem quiet in noisy environments
−16 to −14 LUFS	Mainstream music streaming	Good balance of loudness and headroom	Some dynamic recordings may need peak control
Around −11 LUFS	Loud listening modes	Better audibility in noisy environments	More limiting and reduced dynamic range

Outlet / Standard	Loudness	Compared with your −14 LUFS
Netflix	−27 LKFS dialogue	13 dB quieter
U.S. Digital TV – ATSC A/85	−24 LKFS	10 dB quieter
European TV – EBU R128	−23 LUFS	9 dB quieter
AES Internet radio / streaming	−20 to −16 LUFS	6 to 2 dB quieter
Spotify – Quiet	−19 LUFS	5 dB quieter
Apple Music / Sound Check	≈−16 LUFS	≈2 dB quieter
Apple Podcasts	−16 LKFS	2 dB quieter
North Texas Radio	−14 LUFS	Reference
Spotify – Normal	−14 LUFS	Same target
YouTube	≈−14 LUFS	≈Same target
TIDAL	≈−14 LUFS	≈Same target
Amazon Music	≈−14 LUFS	≈Same target
Amazon Alexa audio	−14 LUFS	Same target
Spotify – Loud	−11 LUFS	3 dB louder
U.S. FM radio	No LUFS target	Uses modulation and broadcast processing
U.S. AM radio	No LUFS target	Uses modulation and broadcast processing
Live365	No published LUFS target	Cannot directly rank

ChatGPT-5.6 Sol.

North Texas Radio’s stream headroom is set to −0.2 dB. Over the past two weeks at this setting, the highest measured stream peak has been −0.1 dBTP. Problem peaks have been corrected in the streaming library, and ReplayGain adjusts track playback levels.

True Peak	Headroom to 0	Practical meaning
−3 dBTP	3 dB	Very conservative. Plenty of room for encoding and processing
−2 dBTP	2 dB	Common broadcast safety margin before lossy encoding
−1.5 dBTP	1.5 dB	Comfortable streaming margin
−1 dBTP	1 dB	Common streaming recommendation. Good balance of loudness and safety
−0.8 dBTP	0.8 dB	Slightly less safety margin
−0.6 dBTP	0.6 dB	Quite close to full scale but still below it
−0.3 dBTP	0.3 dB	Very little room for codec or processing overshoot
0 dBTP	0 dB	No headroom
Above 0 dBTP	None	Potential clipping during playback or conversion

Outlet / standard	Loudness target	Typical maximum True Peak / headroom
Netflix	−27 LKFS dialogue	−2 dBTP; Netflix suggests limiter around −2.3 (Netflix Partner Help Center)
U.S. TV – ATSC A/85	−24 LKFS	below −2 dBTP to allow for downstream encoding (ATSC : NextGen TV)
European TV – EBU R128	−23 LUFS	−1 dBTP for linear audio; −2 dBTP may be used before lossy codecs (EBU Tech)
AES Internet streaming	current recommendation ≈−18 LUFS	−1 dBTP at codec input (AES)
Spotify Normal	−14 LUFS	generally preserves 1 dB headroom; recommends masters below −1 dBTP (Spotify)
Spotify Loud	−11 LUFS	limiter engages at −1 dB sample peak (Spotify)
Apple Podcasts	−16 LKFS	≤−1 dB true peak before encoding (Apple Podcasts)
FM / AM radio	no LUFS equivalent	not directly comparable; controlled by modulation/processor limits
Live365	no published LUFS target	no useful published true-peak ceiling I can find

ChatGPT-5.6 Sol.

These are the specific steps AI took to analyze and make corrections

Created a .ps1 script for the Windows loudness scan.
Ran the .ps1 in Windows PowerShell, which scanned the music files and created .csv reports.
Analyzed the .csv files for:
- Current loudness of each track
- Tracks significantly below the target
- Gain required to approach −14 LUFS
- Peak / true-peak problems
- Tracks marked Reduced to prevent clipping
- Files that could not be scanned
- Errors and unusual results
Set the correction criteria:
- Target approximately −14 LUFS
- Only correct tracks at least 1 dB below target
- Maximum projected true peak approximately −1.5 dBTP
- Do not force a track to −14 if doing so would create excessive peaks
Created a candidate list from the CSV analysis.
Ran a preflight check in PowerShell before changing any audio:
- Verified file paths
- Checked for missing files
- Verified proposed gain changes
- Checked projected true peaks
- Confirmed there were 0 missing files
Created a manifest listing the files to be processed and the planned corrections.
Because some tracks in the working library had already been modified, untouched backup copies were used as the source for those corrections. This avoided re-encoding already processed MP3s and adding another generation of lossy compression.
Ran the correction .ps1 in PowerShell. The script:
- Read the candidate/manifest information
- Located each original file
- Applied the calculated gain
- Reduced the gain when necessary to protect the peak ceiling
- Created the corrected files
- Logged the changes made to each file
- Reported files that failed
Reviewed the results and errors.
- Checked files that could not be processed
- Checked tracks whose gain had to be reduced to prevent clipping
- Identified unusually quiet tracks that still needed individual attention
Put the corrected files into the working music library, retaining the existing folder structure and filenames.
Tested the corrected library through StationPlaylist and the stream.

ChatGPT-5.6 Sol.

For most personal music libraries, permanently changing the audio files is unnecessary. First check whether your player supports loudness normalization, such as ReplayGain, and whether it is enabled and working. That is usually enough to make playback volume more consistent.

Important Warning Before Modifying Audio Files!
These are destructive changes. The correction process can permanently alter audio files. If a script is pointed at the wrong folder, given the wrong settings, or allowed to overwrite the originals, the damage may be difficult or impossible to reverse.

Check whether permanent file changes are necessary
Before modifying any music files, check whether the playback software supports ReplayGain or another loudness-normalization system. Determine whether that feature is enabled and working correctly. Then determine whether permanent modification of the audio files is necessary or whether playback normalization alone can achieve the desired result.

Before modifying any audio files, have/make two complete backups of the original music library. Store one backup on a different drive or at a separate location and leave it untouched. The second backup may be used as a read-only source if corrected copies are needed later. Do not modify either backup in place. Corrected files should always be written to a separate working or output location. Test the process on a small group of files first. Verify the output before running it on thousands of tracks. Keep the CSVs, manifests, and logs so every change can be traced. If MP3 files must be re-encoded, use untouched originals whenever possible rather than processing files that have already been altered or re-encoded.

The safest approach is: Original library → two verified backups → test batch → verified corrected copy → working library
Do not begin large-scale correction until the backup has been checked and can actually be restored.

Prompts for Analyzing and Correcting a Music Library
Copy the prompts below into ChatGPT one at a time. Complete each step before moving to the next. When a step creates a CSV or other report, upload that file with the next prompt.
Adjust settings such as the loudness target to fit your system..

Create the scanning script
Prompt – I have a Windows music library containing MP3 files. I want to analyze every audio file recursively without modifying anything. Create a PowerShell .ps1 script that scans the files and produces a CSV containing the full file path, integrated LUFS, peak or true-peak information, scan status and any errors. Before writing the script, tell me what software or command-line tools need to be installed. Include exact instructions for running the script in Windows PowerShell.
Analyze the CSV
Prompt – Analyze this loudness-scan CSV. My target is −14 LUFS. Identify tracks that are at least 1 dB quieter than the target. For each track calculate how much gain would be required to approach −14 LUFS. Also check whether that increase would cause its true peak to exceed −1.5 dBTP. Do not modify any files. Create a table showing current LUFS, current peak, requested gain, maximum safe gain, projected LUFS, projected peak and whether the gain needs to be reduced to prevent clipping.
Find problems before changing anything
Prompt – Examine these scan results for anything that should be reviewed manually before processing. Look for failed scans, missing measurements, unusually low or high loudness, suspicious peak values, files that cannot safely reach the target and anything else that appears abnormal. Separate these from the files that can be processed automatically.
Create a preflight
Prompt – Using the approved correction list, create a PowerShell preflight script. It must not change any audio. Verify that every source file exists, destination paths are valid, there are no duplicate or conflicting filenames, proposed gain for each file is correct and projected peak levels remain within the selected ceiling. Create a CSV manifest showing exactly what would happen. Stop and report errors rather than guessing or silently skipping files. Do not proceed to the correction stage until the preflight results have been reviewed and approved.
Create the correction script
Prompt – Now create the PowerShell script that performs the approved corrections. Apply corrections only to the tracks in the approved list. Raise each selected track toward −14 LUFS, but reduce the gain when necessary so the true peak does not exceed −1.5 dBTP. Read from the designated source files and write corrected files to a separate output location. Never modify the source or backup files in place. Preserve filenames, folder structure, metadata, tags and artwork where possible. Do not silently change the audio format, channel configuration, sample rate or encoding settings without explaining why. Log every successfully processed file, the applied gain, files whose gain was reduced because of peak headroom, and every failure. Do not process files that are not on the approved correction list. Before running the script, explain clearly whether the process requires MP3 re-encoding and what changes will be made to the audio files.

*Important: If the files being corrected have already been modified, normalized, or re-encoded, do not process those altered MP3s again if untouched originals are available. Use the untouched backup files as the source and place the newly corrected versions into the working or streaming library. This avoids an unnecessary additional lossy MP3 encode.
Verify the corrected files
Prompt – Create a second scan of the corrected files and compare it with the original CSV. Show the original LUFS, original peak, applied gain, new LUFS, new peak and difference from the original. Flag any files that did not change as expected, exceeded the intended peak ceiling, failed processing or remain significantly below the −14 LUFS target. Confirm that the number of output files matches the number successfully processed