How to fix inter-sample peak distortion in the browser
- Step 1Understand what you're actually fixing — You're leaving headroom so inter-sample reconstruction doesn't clip — not surgically clamping each reconstructed peak. A -1.0 dBTP ceiling is the standard amount of headroom; -1.5 or -2.0 dBTP gives more if your material has dense high-frequency content (which produces larger ISPs).
- Step 2Confirm Pro access — The limiter requires Pro. Free accounts can't run it. Pro processes files up to 200 MB / 120 minutes; Pro + Media and Developer go to 100 GB with no duration cap.
- Step 3Drop the master onto the tool — FFmpeg WebAssembly processes it locally. Accepted input is any audio FFmpeg can decode. The buffer stays in your browser tab — nothing uploads.
- Step 4Pick a ceiling sized to your ISP risk — -1.0 dBTP · standard suits most material. For bright, transient-heavy or already-loud masters that generate larger inter-sample peaks, -1.5 dBTP · safer or -2.0 dBTP · Amazon widens the margin. -0.3 dBTP leaves almost no ISP headroom and is only for material that won't be re-encoded.
- Step 5Choose output format — WAV or FLAC keeps a lossless ISP-safe master. MP3/M4A (192 kbps) is for delivery — but remember the inter-sample overshoot is reproduced by the *playback* decoder, so the headroom in the master is what protects it regardless of output format.
- Step 6Read the ebur128 true-peak figure — The result panel shows the achieved true-peak in dBFS as measured by
ebur128=peak=true— this is the inter-sample-inclusive number. Confirm it sits at or near your ceiling. If it's higher than you want, re-run at a lower ceiling (-1.5 or -2.0 dBTP).
Sample peak vs true peak — what each stage sees
Why a file that reads 0 dBFS on its samples can still clip. The limiter enforces the sample-peak side; the verification meter reports the true-peak side.
| Concept | What it measures | Where it appears in this tool |
|---|---|---|
| Sample peak (dBFS) | Amplitude of the discrete digital samples | What alimiter's linear limit clamps |
| Inter-sample peak / true peak (dBTP) | The reconstructed waveform between samples | What ebur128=peak=true reports after limiting |
| The gap between them | Up to ~1 dB on dense/bright material | Why the ceiling is -1, not 0 — the margin absorbs it |
| Codec/DAC overshoot | ISPs realised on lossy decode or D/A | What the headroom prevents from clipping |
Ceiling vs inter-sample headroom
How much ISP margin each UI ceiling leaves. Brighter, denser, louder material needs a lower ceiling.
| UI option | ISP headroom | Use when |
|---|---|---|
| -0.3 dBTP · loud | ≈ 0.3 dB | Material that won't be lossy-encoded or D/A-critical |
| -1.0 dBTP · standard | ≈ 1 dB | Most masters; the streaming convention |
| -1.5 dBTP · safer | ≈ 1.5 dB | Bright/transient-heavy mixes, low-bitrate encode targets |
| -2.0 dBTP · Amazon | ≈ 2 dB | Dense, very loud masters; Amazon Music spec |
Cookbook
Inter-sample scenarios, including how to read the ebur128 true-peak verification against the sample-peak limit alimiter enforced.
0 dBFS file, true-peak measured above 0 dBTP
Every sample sits at or under 0 dBFS but ebur128 reports the true-peak above 0 — classic inter-sample overshoot. Limiting to -1.0 dBTP brings the reconstructed peak back under control.
Before (measure only): sample peak: 0.0 dBFS ebur128 true-peak: +0.6 dBFS ← inter-sample overshoot After (ceiling -1.0 dBTP, output WAV): ebur128 true-peak: -0.8 dBFS Overshoot pulled under 0; safe for lossy encode.
Bright master needs a wider margin
Dense high-frequency content produces larger inter-sample peaks. A -1.0 dBTP ceiling leaves the verification reading close to 0; dropping to -1.5 dBTP gives a comfortable gap.
At -1.0 dBTP: ebur128 true-peak reads -0.4 dBFS (tight) At -1.5 dBTP: ebur128 true-peak reads -1.2 dBFS (comfortable) For bright/transient material, choose -1.5 dBTP · safer.
Verify true-peak without changing the file
You can use the tool as a true-peak check: run at -0.3 dBTP (effectively a near-zero ceiling). If the file was already below it, nothing changes and the reported figure is your true-peak reading.
Input: master.wav Ceiling: -0.3 dBTP · loud If no peak exceeds -0.3 dBTP: output ≈ unchanged, ebur128 true-peak reported. Use the figure to decide if a real limiting pass is needed.
Why the limit reads differently from the ceiling
alimiter clamps sample peaks to the linear equivalent of your ceiling; ebur128 then reports the true-peak, which includes inter-sample content and can sit slightly higher. This is expected, not an error.
Ceiling chosen: -1.0 dBTP alimiter linear limit: 0.891251 (sample-peak clamp) ebur128 true-peak of output: -0.9 dBFS The ~0.1 dB gap is the inter-sample content alimiter didn't clamp — exactly what the -1 dB margin covers.
ISP-safe lossless master for archival
Keep a master that's guaranteed ISP-safe across future re-encodes by limiting to -1.5 dBTP and storing as FLAC.
Input: master.wav Ceiling: -1.5 dBTP · safer Format: FLAC (lossless) Output: master-isp-safe.flac ebur128 true-peak: ~-1.5 dBFS Survives future MP3/AAC/Opus encodes without ISP clipping.
Edge cases and what actually happens
alimiter is not a fully oversampled true-peak limiter
By designThe engine is FFmpeg's alimiter, a look-ahead sample-peak brickwall limiter — not an oversampled inter-sample limiter. It controls ISPs by leaving headroom (the -1/-1.5/-2 dBTP ceilings), not by clamping each reconstructed peak. The ebur128 verification IS true-peak-aware, so you can see and target the real ISP figure by choosing a lower ceiling. This is the honest mechanism.
ebur128 true-peak still reads near 0 after a -1.0 dBTP limit
Tighten ceilingOn very bright or dense material, ~1 dB of headroom may not fully cover the inter-sample content, so the reported true-peak can creep close to 0. The fix is to re-run at -1.5 or -2.0 dBTP for a wider margin. There's no oversampling control to enable — the ceiling choice is the lever.
Free account
Requires ProThe limiter is Pro-only. Free accounts can't run it and see a 'requires a Pro subscription' message. Pro processes 200 MB / 120 min per file; higher tiers reach 100 GB with no duration cap.
Expecting to remove distortion already audible in the file
Cannot repairIf a file already sounds clipped before any encode, that distortion is in the samples and limiting can't remove it. ISP control is about preventing overshoot on future decode/D/A, not repairing existing clipping. Re-export a clean source from your DAW.
Input already below the chosen ceiling
PreservedIf no sample exceeds the ceiling, alimiter doesn't engage and the audio is unchanged apart from the re-encode — but the ebur128 pass still reports the true-peak, which is useful as a measurement. The limiter never raises level; it's a ceiling, not a maximizer.
File over the Pro 200 MB / 120-minute cap
Limit exceededPro checks size and duration independently. Convert to FLAC with wav-to-flac to reduce size, split with audio-splitter, or upgrade to Pro + Media (100 GB, unlimited duration).
Custom ceiling like -0.7 dBTP wanted
Not in UIThe UI offers only -1.0, -1.5, -2.0, and -0.3 dBTP. The MCP/API schema accepts any value from -6 to 0 dB for automated callers, so a pipeline could request a custom ISP margin, but the web tool uses the four presets. For ISP work the presets span the useful range.
Output bitrate not selectable for delivery
By designLossy output is fixed at 192 kbps. The ISP-relevant work is the headroom in the master, not the bitrate. If you need a specific delivery bitrate, output WAV/FLAC here, then use bitrate-changer.
ebur128 can't parse a true-peak from the output
Verification errorA corrupt or truncated source can leave the verification unable to parse a peak, reported as a true-peak parse failure. The limiting completed; the metering failed on bad data. Re-export a clean file and retry.
Resampling expected to change ISP behaviour
Wrong toolSample-rate conversion can alter inter-sample behaviour, but this tool doesn't resample — it preserves the input sample rate. If you need to change sample rate (and re-evaluate ISPs at the new rate), use sample-rate-converter, then limit at the target rate.
Frequently asked questions
What exactly is an inter-sample peak?
It's a peak in the reconstructed analogue waveform that sits between two digital samples. A D/A converter or lossy decoder draws a smooth curve through your samples, and that curve can rise above the highest sample value — above 0 dBFS — even though no individual sample does. Lossy codecs realise those peaks as clipping, which is why you leave headroom.
Is this a real inter-sample (true-peak) limiter?
Honestly, no — the engine is FFmpeg's alimiter, a look-ahead sample-peak limiter, not a fully oversampled inter-sample limiter. It controls inter-sample peaks by leaving headroom (the -1/-1.5/-2 dBTP ceilings). The verification step, though, uses ebur128=peak=true, which IS true-peak-aware, so you can measure and target the real ISP figure.
Then how do I actually get my true-peak under 0?
Choose a ceiling with enough headroom and check the ebur128 true-peak readout. -1.0 dBTP covers most material; if the reported true-peak still sits near 0 (bright/dense mixes), re-run at -1.5 or -2.0 dBTP. The reported figure is the inter-sample-inclusive number, so you can iterate until it's where you want it.
Why does the reported true-peak differ from my ceiling?
alimiter clamps the sample peaks to the linear equivalent of your ceiling, but ebur128 reports the true-peak, which includes the inter-sample content alimiter doesn't directly clamp. A small gap (a tenth of a dB or so after -1.0 dBTP) is normal and is exactly the overshoot the headroom is there to absorb.
What ceiling should I use for inter-sample safety?
-1.0 dBTP is the standard and works for most material. Bright, transient-heavy, or very loud masters generate larger inter-sample peaks, so -1.5 or -2.0 dBTP gives a wider guaranteed margin. -0.3 dBTP leaves almost no ISP headroom and only suits material that won't be re-encoded.
Can I just measure true-peak without limiting?
Effectively yes — run at -0.3 dBTP (a near-zero ceiling). If the file is already below it, nothing meaningful changes and the reported ebur128 true-peak is your measurement. Use that figure to decide whether a real limiting pass at a lower ceiling is needed.
Does output format affect inter-sample peaks?
The inter-sample overshoot is created by the playback decoder/DAC, so the protection is the headroom baked into the master, not the output format. WAV/FLAC keeps a lossless ISP-safe master; MP3/M4A is fine for delivery. Either way the -1 dB (or wider) margin is what protects against ISP clipping downstream.
Is the tool free?
No — it requires Pro. Free accounts can't run it. Pro handles files up to 200 MB / 120 minutes; Pro + Media and Developer go to 100 GB with no duration cap.
Does my audio upload anywhere?
No. FFmpeg runs as WebAssembly in your browser and the audio stays in the tab. Only an anonymous usage counter is recorded for dashboard stats — never the audio content.
Will limiting for ISPs change my loudness?
Only at the peaks that exceed the ceiling. Inter-sample limiting on a well-made master touches very little of the signal, so perceived loudness barely moves. If you need a specific loudness target, normalize first with loudness-normalizer, then check ISPs here.
Does sample rate matter for inter-sample peaks?
Yes — higher sample rates have smaller gaps between samples, so inter-sample peaks tend to be smaller. This tool preserves your input sample rate; it doesn't resample. If you change sample rate with sample-rate-converter, re-check the true-peak at the new rate because ISP behaviour shifts.
How does this differ from the plain peak ceiling tool?
It's the same engine — the difference is framing and how you read the result. For inter-sample work, the key insight is that the ebur128 verification reports the true-peak (ISP-inclusive) figure, and you choose the ceiling to leave enough headroom for it. The -1/-1.5/-2 dBTP options exist precisely to size that ISP margin.
Privacy first
Every JAD Audio tool runs entirely in your browser via FFmpeg (WebAssembly) and RNNoise. Your audio files never leave your device — verified by zero outbound network requests during processing.