Turning a track down can prevent overload later in the playback chain. It cannot, by itself, reconstruct a waveform that has already been flattened. Before changing a prompt, buying a repair plugin, or exporting again, find out which of those situations you have.
A September 20 question in r/SunoAI describes rough loud passages after export. The follow-up is the useful part: would reducing volume reconstruct instruments that already sound crushed? The thread demonstrates that someone has this problem; it does not establish what caused it or how often it happens.
This tutorial is for creators comfortable with a terminal, and developers building audio inspection features. It uses local files and a deliberately simple experiment. It does not inspect a provider's internal generation pipeline.
Start with the exact file that sounds wrong
Keep the original download untouched. Make a note of its filename, the player or DAW, and one short problem interval—for example, “the snare sounds brittle from 00:42 to 00:47.” That timestamp is an example, not a measurement of a real song.
Create a clean DAW session. Import the file with no processing, disable automatic normalization or enhancement, and listen at a comfortable level. Check whether the problem occurs in the source file or only after adding effects or mixing tracks. If you only compare two differently processed playback paths, you cannot isolate the export.
Distortion is a description of what you hear; clipping is one possible mechanism. A raspy vocal, a saturated guitar, separation artifacts, or a synthetic cymbal can all sound rough without the current file hitting its numeric ceiling.
Measure the file without rewriting it
With FFmpeg installed, run this command in the directory containing a copy named input.wav:
ffmpeg -hide_banner -nostats -i input.wav -map 0:a:0 -af astats=reset=0 -f null -
The null output writes no replacement audio file. Read the final channel and overall statistics in the terminal. FFmpeg's astats documentation defines Peak level dB as a sample peak in dBFS. Its Peak count counts occasions when the minimum or maximum is reached; it is not a clipped-sample counter.
A near-zero peak is a reason to inspect the waveform, not a diagnosis. A negative peak also does not prove the absence of earlier clipping. That distinction is easy to demonstrate.
Build two files with the same peak and different shapes
This Python 3 example uses only the standard library. Run it in a new, empty directory. It creates clean.wav and clipped.wav; those names would overwrite existing files in that directory.
import math
import struct
import wave
rate = 48000
for name, clip in [("clean", False), ("clipped", True)]:
samples = []
for i in range(rate):
x = math.sin(2 * math.pi * 1000 * i / rate)
if clip:
x = max(-1, min(1, 1.4 * x))
# Both files are reduced after the optional clipping.
samples.append(round(0.5 * x * 32767))
with wave.open(name + ".wav", "wb") as out:
out.setparams((1, 2, rate, 0, "NONE", "not compressed"))
out.writeframes(struct.pack("<" + "h" * len(samples), *samples))
These are synthetic test tones, not recordings or AI-generated music. You do not need to play them: importing and zooming into a few cycles is enough to see the difference. If you do listen, start with a low playback level.
Run the inspection command twice, substituting each filename. In the local verification of this exact example, both files reported a peak of approximately −6.0203 dBFS. The clean signal's RMS was approximately −9.0309 dBFS; the deliberately clipped version's RMS was approximately −7.7017 dBFS. Rounding and tool versions can affect the final decimals.
The clipped waveform still has flat sections. Multiplying it by 0.5 made those sections smaller, but did not recover the missing curved tops. The two files therefore have the same peak while retaining different waveforms. This is why an “under 0 dBFS” badge should never be presented as a clean-audio certificate.
The example does not show that a particular generated song was clipped. Real music is more complicated than a sine wave, and a limiter or a deliberately distorted instrument can create shapes that resemble this demonstration.
Use a short comparison to decide what to do next
Listen to the noted interval in the clean session, then compare it with the same interval in your working session. Bypass processing one stage at a time. Record what changed rather than relying on which version initially feels louder or more exciting.
If the clean source is acceptable but the processed version breaks up, investigate that processing chain. Lower the signal before the stage that overloads and compare again. Turning down a later master fader cannot undo distortion already introduced by an earlier stage.
If the problem is audible in the unprocessed source at a modest playback level, try another known-good playback path. This helps separate the file from a device-specific issue. If it persists, preserve that source and evaluate a different generation, a small replacement section, or a repair experiment on a copy. Keep the original as the reference.
Do not treat “32-bit” in a filename or export menu as proof of recoverability. A container label tells you little about previous processing. Even a format that can represent values beyond a usual playback range cannot recreate information that was discarded before it received the signal.
What a useful inspection report should say
For an audio application, show measurements and limits separately. A practical report might contain:
- The exact source filename and inspected interval.
- Per-channel sample peaks, with the unit explicitly labeled.
- A waveform view that the reader can zoom into.
- Whether the audible problem appears with processing bypassed.
- The next comparison to run, rather than a one-click “fixed” verdict.
Sample peaks are not a true-peak measurement. If delivery requirements specify true peak or integrated loudness, use an appropriate meter and check those requirements separately. Neither measurement establishes whether a generated instrument sounds natural.
The result you want from this procedure is a decision: adjust a later gain stage, revisit a processing step, or seek better source material. A quieter file is useful when overload occurs later. A repaired or replacement source is a different task, and its success must be judged by listening as well as measurement.
Disclosure: This article is from the EasyMusic.AI team and was researched and drafted with AI assistance. The synthetic example was run locally; no claim is made that it diagnoses Suno or any other provider's backend. The diagnostic method works independently of the music-generation service used.
Top comments (0)