WAV Volume Adjuster
Multiplies every sample in an uncompressed PCM or IEEE-float WAV by one amplitude factor, with an optional peak scan that reduces a positive boost to available headroom. The original container is copied and only bytes in its audio data chunk are rewritten locally.
A little-endian PCM or IEEE-float RIFF/RF64 WAVE file up to 100 MB. Compressed WAV codecs need a decoder and are refused.
Results are provided as-is, with no warranty of accuracy. The method and its sources are published below so you can check the working.
How it works
What this works out
A WAV volume change is a multiplication, not a fixed number added to every sample. Adding a constant would shift the waveform away from zero and create a DC offset. Multiplying positive and negative samples by the same factor keeps silence at zero, keeps channel balance intact, and preserves the recording’s relative dynamics until a value reaches the format’s hard boundary.
The tool reports both sides of that operation: the gain that was actually applied and the sample peaks before and after it. When protection reduces a boost, the result says so numerically rather than making the requested number look successful while using a different one.
The method
NIST expresses a field or amplitude level ratio with 20 times the base-10 logarithm. Solving that relation for a multiplier gives:
gain dB = 20 × log10(output amplitude / input amplitude)
multiplier = 10^(gain dB / 20)
A negative setting produces a multiplier below one. A positive setting
produces one above one. -6.0205999 dB is exactly 10^(-6.0205999 / 20) = 0.5;
+6.0205999 dB is 2.
Before touching samples, the implementation reads the RIFF structure. Chunks
have a four-character identifier, a 32-bit payload size and a pad byte when the
payload length is odd. RF64 uses the same layout but stores the audio length in
its ds64 chunk. The fmt chunk supplies the sample representation and
data supplies the interleaved channel samples.
The accepted representations are deliberately finite and explicit:
| WAV sample kind | Stored range | Full-scale interpretation |
|---|---|---|
| 8-bit PCM | unsigned 0 to 255 | subtract 128, then divide by 128 |
| 16-bit PCM | signed -32,768 to 32,767 | divide by 32,768 |
| 24-bit PCM | signed -8,388,608 to 8,388,607 | divide by 8,388,608 |
| 32-bit PCM | signed -2,147,483,648 to 2,147,483,647 | divide by 2,147,483,648 |
| 32/64-bit float | IEEE floating point | nominally -1 to +1 |
Integer positive full scale is one code smaller than the negative magnitude. The headroom calculation therefore measures the most positive and most negative sample separately:
positive headroom = largest positive code / measured positive code
negative headroom = absolute lowest negative code / absolute measured negative code
safe multiplier = min(positive headroom, negative headroom)
applied multiplier = min(requested multiplier, safe multiplier)
Silence has no finite peak constraint. An already over-range float file is the opposite case: no positive factor can bring it back under full scale. Protection uses 0 dB rather than changing the requested direction, and the writer clamps and counts any over-range values that remain.
Before you read on
A WAV's largest sample is 50% of full scale. What is the largest constant boost with peak protection?
About +6.0206 dB. The available multiplier is 1 / 0.5 = 2, and an amplitude ratio of two is 20 × log10(2). This is a sample-peak result, not a claim about perceived loudness or true peak between samples.
A worked example
The formula test builds a one-second, mono, 16-bit PCM WAV at five samples per second. Its known sample codes are:
0, 16000, -16000, 8000, -8000
The selected gain is -6.0205999 dB, so the multiplier is exactly 0.5:
| Figure | Working | Result |
|---|---|---|
| Peak before | 16,000 ÷ 32,768 × 100 | 48.828125% |
| Multiplier | 10^(-6.0205999 ÷ 20) | 0.5 |
| Output samples | each source code × 0.5 | 0, 8000, -8000, 4000, -4000 |
| Peak after | 8,000 ÷ 32,768 × 100 | 24.414063% |
| Limited samples | every result fits 16-bit PCM | 0 |
| Duration | 5 frames ÷ 5 Hz | 1 second |
The test asserts every output sample and each displayed result. It also restores the original data bytes into the downloaded artifact and compares the complete file with the source, proving that all bytes outside the sample payload stayed unchanged.
What clipping prevention can and cannot promise
This is sample-peak protection. It keeps the stored output samples inside their integer range or the nominal float range. A reconstructed analogue waveform can peak between samples, so a sample-safe file is not automatically true-peak compliant for broadcast delivery. Measuring that requires an oversampled true-peak algorithm and a specified standard.
The tool also uses one gain for the complete file. A limiter or compressor changes gain over time, and loudness normalisation measures programme energy and frequency weighting. Those are different operations with different quality and policy choices; they are not hidden behind this control.
What remains byte-for-byte intact
The downloaded file is a copy of the complete RIFF or RF64 container. Its
channel layout, sample rate, bit depth, fmt extension, cue positions,
comments and unknown private chunks stay at the same byte offsets. Only sample
bytes within the sole top-level data payload are replaced.
That fidelity has one deliberate caveat. Metadata can contain facts about the waveform rather than facts about its timeline: a stored peak, integrated loudness, checksum or analysis result becomes stale after any sample changes. The tool cannot safely recognise every private chunk, so it preserves those bytes and calls out the limitation instead of deleting metadata without permission or pretending to have recalculated it.
How it is done
- Check that the file is a little-endian RIFF or RF64 WAVE container, then walk its padded chunk list to find exactly one fmt block and one data block. Read RF64's 64-bit data length from ds64 when required.
- Read the channel count, sample rate, block alignment, bit depth and format tag. Unwrap WAVE_FORMAT_EXTENSIBLE only when its valid precision fills the sample container; refuse compressed codecs, big-endian RIFX and inconsistent frame widths.
- Decode each 8-, 16-, 24- or 32-bit PCM sample, or each 32- or 64-bit IEEE-float sample, and measure the largest positive and negative amplitude. Reject non-finite float values rather than propagating NaN or infinity.
- Convert the requested decibel change to an amplitude multiplier with multiplier = 10 raised to gain dB divided by 20. When clipping prevention is on for a boost, reduce that multiplier to the smaller signed headroom limit.
- Copy the complete source file in bounded pieces. In the copy's data chunk, multiply each channel sample by the same factor, round integer PCM symmetrically to the nearest code, and clamp any over-range result at digital full scale.
- Report the actual gain, measured peaks, number of samples that required limiting and unchanged duration. Offer the copied container as a separate WAV download; the source file remains untouched.
What it assumes
- Supported audio is little-endian integer PCM at 8, 16, 24 or 32 bits, or IEEE float at 32 or 64 bits. Compressed WAV codecs and big-endian RIFX require a decoder or byte-order conversion and are refused.
- WAVE_FORMAT_EXTENSIBLE is supported when its valid-bit count is zero or equals the container width. Reduced-precision samples such as 24 valid bits left-aligned in 32-bit containers are refused rather than interpreted by guesswork.
- The same constant factor is applied to every sample in every channel, preserving channel balance and relative dynamics. This is peak gain adjustment, not LUFS loudness normalisation, compression, limiting over time, resampling or dithering.
- Peak prevention caps only a requested positive gain. If an IEEE-float source is already outside the nominal -1 to +1 range, the applied boost becomes 0 dB and those existing over-range samples are still clamped and counted; the tool does not silently turn a boost into attenuation.
- Integer PCM is rounded to its nearest representable sample code after multiplication. At half-way cases, equal positive and negative magnitudes round away from zero so the operation does not introduce sign-dependent rounding.
- RIFF chunks and their positions remain byte-for-byte unchanged outside the data payload. That keeps cues and channel metadata in place, but any embedded peak, loudness, checksum or analysis metadata can describe the old samples and is not recalculated.
- Input is capped at 100 MB. The browser holds the source and copied output at once, while the scan, copy and rewrite loops yield in bounded pieces so progress and Cancel remain responsive.
Common questions
Does changing WAV volume upload or compress the recording?
No. The browser reads and rewrites uncompressed sample values locally, then offers a separate WAV download. It does not use a lossy codec, resample the audio or send the file to a server.
What does minus 6 dB do to a WAV waveform?
A change of -6.0206 dB multiplies every sample amplitude by exactly one half. Perceived loudness does not necessarily sound exactly half as loud; this tool changes sample amplitude, not psychoacoustic loudness in LUFS.
How does the tool prevent clipping when I make a WAV louder?
It first measures the largest positive and negative sample, calculates the constant multiplier each side can accept before full scale, and caps the requested boost at the smaller limit. It does not use a time-varying limiter or change the waveform's relative dynamics.
Why does the applied gain differ from the gain I requested?
The source peak left less digital headroom than the requested boost needed and clipping prevention was enabled. The result shows the actual constant gain, while disabling protection applies the request and counts samples that had to be clamped.
Does WAV gain adjustment change stereo balance or duration?
No. The same multiplier is used for every channel, and the sample count, sample rate and channel layout do not change. The duration and positions of existing cue markers therefore stay fixed.
Is all WAV metadata still accurate after the volume change?
Every non-audio byte is preserved, which keeps structural and positional metadata in place. However, stored peak, loudness, checksum or analysis figures can describe the old waveform; recalculate those in a metadata- aware audio editor when they are part of a delivery specification.