Should I vibe code
Normalize loudness, reduce noise, and batch-process user-owned audio locally
Loudness normalisation is a well-specified standard and ffmpeg already implements it.
?
Their verdict, the Recurring credits price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Batch audio processing is a script. The standards here are public and the tooling is mature, which makes this one of the safest builds on the list.
What actually breaks
not "if". the specific failures.
- Noise reduction pushed too far, which produces the underwater artefacting that is worse than the noise it removed
- Normalising to peak rather than integrated loudness, so two episodes measured identically still sound different
- Multitrack levelling, where ducking one speaker against another needs the tracks aligned first
- Processing the file in place, so an over-aggressive setting is discovered after the original is gone
- Clipping introduced by the loudness stage itself, if there is no true-peak limiting after it
The stakes here are low and the failure is aesthetic. You set noise reduction generously because the room was noisy, and the result is clean in the pauses and slightly metallic on the voice — the model removed the noise and some of the speech with it. It is subtle enough that you approve it and obvious enough that a listener notices without being able to say why. The original recording was better, and you processed over it.
Is that you?
the verdict is a default, not a law
- You process to a new file and keep the original untouched
- Loudness targets integrated LUFS with true-peak limiting after
- You listen to the result before publishing
- Processing overwrites the source recording
- You normalise by peak amplitude rather than integrated loudness
- Noise reduction is applied at a fixed aggressive setting regardless of the input
- There is no true-peak limiter after the loudness stage
If you build it anyway
the checklist, then the prompt that enforces it
- Never process in place. Write to a new file, always, so an over-processed result is a re-run rather than a loss.
- Normalise to integrated loudness against a stated target, not to peak. Peak normalisation makes two episodes match numerically and not audibly.
- Put a true-peak limiter after the loudness stage, because raising the level can push intersample peaks past full scale.
- Be conservative with noise reduction and make it adjustable. Artefacts on the voice are more noticeable than the noise they replaced.
- Measure and report the loudness before and after, so the processing is inspectable rather than magic.
- Use ffmpeg's existing filters rather than implementing DSP — the standards are specified and already implemented correctly.
Before you build an audio post-processing pipeline, apply these and push back if I ask you to break them. 1. Never modify the source file. Always write to a new output, and tell me this is what makes every other setting safe to experiment with. 2. Normalise to integrated loudness — LUFS — against an explicit target, not to peak amplitude. Tell me what target you are using and why, and explain that peak normalisation produces episodes that measure the same and sound different. 3. Apply a true-peak limiter after the loudness stage, because raising level can push intersample peaks above full scale and cause clipping on playback. 4. Keep noise reduction conservative by default and expose the amount. Explain that aggressive reduction produces artefacts on the voice which listeners notice more than the original noise. 5. Report measured loudness, true peak and loudness range before and after processing, so the result is inspectable. 6. Use ffmpeg's existing loudness and filter implementations rather than writing DSP. These standards are specified and correctly implemented already. 7. For multitrack, align tracks before any levelling or ducking, and say what happens if they cannot be aligned. 8. Process in a queue with resource limits so a malformed file fails one job rather than the batch. 9. Out of scope unless I ask: transcription, chapter detection, music beds, voice enhancement models.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Auphonic is excellent and its free tier covers a lot of podcasting. Build your own because the standards are published and ffmpeg implements them, as the hot take says — the value in doing it yourself is a batch pipeline that runs locally on files that never leave your machine.
Keep originals archived separately from processed output. Since every processed file is regenerable from the original plus a settings file, the archive plus a small config is the complete state of the project.
Long-running open-source multitrack audio editor and useful implementation prior art.
Questions
What's wrong with normalising to peak?
It matches the loudest instant rather than the perceived loudness. A recording with one door slam and an otherwise quiet voice will be turned down to accommodate the slam, so it measures the same as a consistently louder episode and sounds much quieter. Integrated loudness measures the whole programme the way a listener experiences it.
Why is a limiter needed after normalising?
Because loudness normalisation raises the level, and the true peak of a signal after digital-to-analogue conversion can be higher than the highest sample value suggests. Without true-peak limiting, a file that looks safe in the editor can clip on playback — audibly, on some devices and not others.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice