Playback-rate resampling changes pitch and duration together, with a playback rate of 2^(n/12) for a shift of n semitones, so +12 semitones run the file at 2× speed (roughly half the original duration) while −12 runs it at 0.5× speed (roughly twice the original duration). The most common cause of a "wrong-looking" result from the Audio Pitch Changer is not a broken file but a working file whose duration moved in the direction the math requires. Because the tool shifts pitch by changing the playback rate rather than by analyzing and rebuilding the signal, every semitone upward simultaneously shortens and speeds up the audio, and every semitone downward simultaneously lengthens and slows it down. If the rendered WAV looks shorter or longer than the original, that is the expected behavior at the chosen shift, not a sign that something failed. Many surprises come from setting +12 and expecting a master-quality, same-length octave, or from setting −5 and wondering why the speech now drags. Once the relationship between semitone, rate, and duration is clear, "wrong" usually becomes a matter of choosing a different shift or accepting the trade-off rather than re-running the same settings and hoping for a different file.
Why the Output Looks Off: Playback-Rate Resampling, Not Time-Stretching
The Audio Pitch Changer applies pitch shifts by changing the source playbackRate in the browser's Web Audio graph. According to MDN's documentation for AudioBufferSourceNode.playbackRate, values below 1 slow the audio down, values above 1 speed it up, and any non-unit rate triggers resampling of the decoded audio. Pitch and rate are linked by that resampling step: speeding playback up also raises the perceived pitch, and slowing it down also lowers it.
What the tool is not doing is the harder job that a phase-vocoder or dedicated time-stretcher does: rebuilding the audio so the pitch changes while the duration stays put. The product contract is explicit on this point. It states that the implementation uses playback-rate resampling, not a time-stretching algorithm, and that the tool never claims to preserve tempo, speech cadence, beat positions, or the exact original duration. If the rendered result looks wrong because the timing no longer matches a backing track, a video, or a metronome click, that is the limit of the chosen method rather than a misconfiguration to fix inside the same tool.
A useful framing: this method is excellent when you want pitch and speed to move together (faster and brighter for a chipmunk-style effect, slower and darker for a heavy sound), and it is the wrong tool when you want only one of those to move. Mistaking those two needs is the single most common source of a "wrong" result, and re-running the same settings will not change the outcome because the math is fixed.
The Math Behind Semitone, Rate, and Duration
The pitch ratio follows twelve-tone equal temperament. McGill University's course material on MIDI/frequency conversion states that an octave contains twelve equal semitones, each with a ratio of 2^(1/12), and that one semitone equals 100 cents. The W3C Web Audio specification defines the same relationship in the AudioBufferSourceNode playback algorithm, where a detuning value contributes a factor of 2^(detune/1200). For whole-number semitone shifts, the Audio Pitch Changer uses the simpler form: playback rate = 2^(n/12), where n is the semitone value you enter.
The practical consequences are summarized in the table below. Each row gives the rate the browser will use, the approximate multiplier applied to the original duration, and the pitch step in plain musical terms.
| Semitone shift | Playback rate | Approximate duration factor | Pitch step |
|---|---|---|---|
| −12 | 0.5× | 2.0× longer | One octave down |
| −7 | ≈0.667× | ≈1.50× longer | Perfect fifth down |
| 0 | 1.0× | 1.0× (unchanged) | Original pitch |
| +5 | ≈1.335× | ≈0.75× shorter | Perfect fourth up |
| +12 | 2.0× | 0.5× shorter | One octave up |
One worked example, kept short to make the relationship concrete. Take a 180-second input file and apply +7 semitones: the playback rate is 2^(7/12), which equals roughly 1.498; dividing 180 by 1.498 gives an output duration of about 120 seconds, so the audio finishes in roughly two minutes and sits about a perfect fifth above the original. The exact figures depend on the audio frame counts the browser reports, which is why the tool surfaces a stated duration change rather than a fixed number.
Limits That Break the Render Before You Hear Anything
Some "wrong-looking" results are not the math's fault at all. They are the tool stopping before it produces a file because one of the declared budgets would be exceeded. If nothing downloads, or the page reports a message about budget or dimensions, walk through the limits below before changing your shift.
- Encoded input size. One file may be at most 50 MiB. Larger files are rejected before decoding so the browser does not waste time on a job it cannot finish.
- Decoded input budget. Decoded audio is limited to five minutes of duration, eight channels, a sample rate between 8,000 and 192,000 Hz, and 30 million channel samples in total. Inputs that fail any of these checks never reach the render step.
- Decoded output budget. The pitch-shifted output is separately capped at 30 million channel samples. Because lowering pitch increases the required output frames, an input that passes the decoded limit can still fail the output limit. In that case the message states that the requested shift is over budget and that nothing was truncated.
- Format and decode failures. Empty files, unsupported MIME types, invalid decoded dimensions, and failed decodes are all rejected with an explicit message rather than a silent partial render.
The output-over-budget case is the one that most often surprises users because the input looked fine on paper. A four-minute stereo file at 44.1 kHz already lands close to the 30-million-channel-sample ceiling, and dropping the pitch by a few semitones pushes the required output frames past that line. The fix is either to trim the input (the Audio Cutter can produce a shorter PCM16 WAV for the shift to work on) or to pick a smaller absolute shift. Re-running with a higher positive semitone value usually succeeds because positive shifts reduce the output frame count.
How to Re-Run the Pitch Shift Correctly
If the first render came out wrong for any of the reasons above, the recovery path is a clean re-run with corrected expectations. The same browser, same file, and same local processing apply, so nothing has to be re-uploaded.
- Open the tool and choose the original audio file. Stick with a single browser-decodable file no larger than 50 MiB. MP3, WAV, M4A, AAC, Ogg, WebM, and FLAC are all listed as supported, but actual decoding depends on the current browser, so an unusual codec profile can still be rejected after selection.
- Decide whether the "wrong" result is a duration problem or a pitch problem. If the pitch ended up where you wanted but the duration is off, the render is correct and you need a different tool to keep length fixed. If the pitch is wrong and the duration change is acceptable, adjust the semitone value and re-render.
- Set a whole-number semitone shift between −12 and +12. Use the table above to predict the playback rate and the duration factor before clicking render. Remember that the playback rate is exactly 2^(n/12); the math does not bend for special cases.
- Confirm the input still fits every decoded limit. Five minutes, eight channels, 8 kHz to 192 kHz sample rate, and 30 million channel samples. Long files can be trimmed first with the Audio Cutter to avoid the over-budget output case.
- Create the complete local render. The browser renders through an OfflineAudioContext at the decoded sample rate and asserts the channel count, sample rate, and full frame count before producing a download. There is no silent tail cut, no hidden duration cap, and no fallback that ships an incomplete file.
- Review the stated duration change. The tool shows the predicted duration change so you can sanity-check the math. If the number does not match what 2^(n/12) predicts, stop and re-render rather than downloading a surprise.
- Download the PCM16 WAV and play it in a trusted local player. The page does not expose a blob-backed preview by policy, so the download is the only inspection path. The exported file is uncompressed, interleaved, little-endian PCM16 in a RIFF/WAVE container, and it does not carry the original codec, tags, artwork, chapters, or cue points.
If the second render still looks wrong, the issue is almost certainly one of three things: a shift that moves pitch in the wrong direction (a negative value raises nothing), a duration expectation that playback-rate resampling cannot meet, or an input that has crossed one of the size or sample budgets. Each of those is a setting change, not a tool fault, so a third pass with corrected inputs is usually enough to land the file you wanted.
When the Tool Cannot Fix the Result on Its Own
There is one class of "wrong" that no setting change inside the Audio Pitch Changer can resolve, and recognizing it saves a lot of re-renders. If the production needs pitch change with duration held constant — vocals re-tuned to a different key without slowing the song, dialogue re-pitched to match a video cut, drum loops transposed without changing the beat grid — the playback-rate method is the wrong approach by design. The product contract states this directly: the tool never claims to preserve tempo, speech cadence, beat positions, or exact original duration, and a setting that requires pitch change with fixed length should use a dedicated phase-vocoder or other time-stretching workflow instead.
Strong upward shifts also expose quality limits that no tool setting can remove. Browser resampling quality is implementation-defined, and floating-point samples are clipped to the legal −1 to +1 range before PCM16 conversion, so quantization can differ from the source. The original codec's compression artifacts, which were inaudible at the original pitch, can become noticeable as aliasing after a +12 shift. Those are not bugs in the output; they are the cost of asking a resampler to do extreme work on already-compressed material. For the same reason, the contract describes the export as useful for quick creative experiments, practice tracks, sound effects, and rough editing, not as a transparent mastering process.
For readers who want a deeper checklist of what to watch for, the Audio Pitch Changer: Practical Tips and Common Mistakes guide covers the same budgets and the same misunderstandings in more detail. After that, the right recovery path is usually one of three things: pick a different semitone, trim the input to fit the output budget, or move the job to a workflow that can hold duration constant while pitch moves. The first two stay inside the browser and cost nothing beyond a fresh render; the third is a deliberate tool change, not a fix to the same tool.
Related reading: Volume Changer Without App: Adjust Audio in a Browser.