The Audio Pitch Changer shifts one local audio file by -12 through +12 semitones using the playback-rate formula 2^(n/12), and a complete procedure document captures every value before, during, and after each run. Documenting the steps you use to run an audio pitch changer turns a one-off experiment into a reproducible record: the input file you loaded, the semitone value you chose, the playback rate the browser applied, and the duration change you observed when the WAV download finished. The tool runs entirely in the current browser tab, so the document you write is also the only persistent record of what the run actually did — there is no server log, no cloud history, and no auto-saved project file. A clear document removes guesswork the next time you need the same shift, makes it easy to hand the procedure to someone else, and lets you compare two runs to confirm a result was identical. For each Audio Pitch Changer session, record the inputs, the formula you relied on, the limits you checked, and the file you downloaded.
What a Procedure Document for an Audio Pitch Changer Should Contain
A useful procedure document is more than a list of clicks. For an audio pitch changer that runs locally and produces a fresh PCM16 WAV download on every run, the document should answer four questions for any future reader: what was uploaded, what was changed, what came back, and what could have failed. The first column captures file identity — name, format, declared size, and any tag or artwork details that the new file will not preserve. The second column captures the math — the semitone value entered, the playback rate the browser derived, and the duration change the tool reported. The third column captures the output — channel count, sample rate, file size, and any audible artifacts you noticed on first listen. The fourth column captures the limits you checked, so a future run can be planned against the same budget.
Writing the document in a fixed order, even if some fields are blank, keeps every entry comparable. When you revisit the procedure in a month, the headings alone will tell you which value to confirm before pressing the download button. When you hand the document to a teammate, the same headings remove ambiguity about which knob was set to which value. This is especially helpful for the Audio Pitch Changer because the tool deliberately changes both pitch and duration, and the only way to recover what actually happened is to write it down while the result is still on screen.
The Inputs, Limits, and Formulas Worth Recording
Three pieces of information belong in every Audio Pitch Changer entry. The first is the input file's source format and size, because the tool accepts common browser-decodable MP3, WAV, M4A, AAC, Ogg, WebM, and FLAC inputs up to 50 MiB, but actual codec support still depends on the current browser, so a recognized extension does not guarantee every codec profile will decode. The second is the integer semitone shift, drawn from -12 through +12, with 0 meaning no change and ±12 meaning a full octave up or down. The third is the playback rate that the tool will apply, which follows twelve-tone equal temperament: the rate for n semitones is 2^(n/12), a relationship confirmed in McGill University's MIDI/frequency reference material.
The limits below the file size matter too, because lowering pitch inflates the required output frame count. The Audio Pitch Changer caps decoded audio at five minutes, eight channels, a sample rate between 8,000 and 192,000 Hz, and 30 million channel samples on both the input and the pitch-shifted output. A document that records the planned semitone value alongside the input length is the easiest way to predict whether a planned run will fit inside the output budget. MDN's playbackRate reference explains that values below one slow the audio, values above one speed it up, and a non-unit rate causes resampling — the same mechanism the Audio Pitch Changer relies on.
| Semitone shift (n) | Playback rate 2^(n/12) | Expected duration change |
|---|---|---|
| -12 | 0.5000 | About twice the original length |
| -7 | 0.6674 | About 1.5× the original length |
| -5 | 0.7492 | About 1.33× the original length |
| 0 | 1.0000 | No change |
| +5 | 1.3348 | About 0.75× the original length |
| +7 | 1.4983 | About 0.67× the original length |
| +12 | 2.0000 | About half the original length |
The exact figures in the table are the tool's published equal-tempered values; any single run can deviate slightly because the browser resamples at the decoded sample rate and may round output frame counts up to the next whole frame.
How to Document the Steps to Use the Audio Pitch Changer
Follow this order when you write the procedure so nothing is missed. Each step corresponds to one line in the document.
- Open the Audio Pitch Changer in a fresh browser tab and clear any earlier input so the document starts from a known state.
- Pick one browser-decodable audio file no larger than 50 MiB and record its name, declared size, and source format in the document before loading it.
- Load the file into the tool and, once decoded, note the input length, channel count, and sample rate the browser reports.
- Choose a whole-number semitone shift between -12 and +12, remembering that the duration will change in the same direction; write the chosen value into the document before rendering.
- Compute the playback rate as 2^(n/12) for your n and write the rate next to the semitone value; this is the figure the tool will apply.
- Trigger the local render, wait for the full result, and record the stated duration change the tool reports when the render completes.
- Download the resulting PCM16 WAV and record its filename, size, channel count, and sample rate in the document next to the input row.
- Save the document in the same folder as the WAV so the two files stay linked for every future reference.
This sequence mirrors what the tool actually does — the page never uploads anything, never trims the output silently, and never substitutes a partial render — so the document stays an honest record of the run.
A Worked Example of the Semitone-to-Rate Conversion
A single worked example is enough to show how the document is filled in. Suppose the input is a 60-second mono WAV at 44,100 Hz and the planned shift is +5 semitones. The formula is rate = 2^(n/12), so substitute n = 5:
rate = 2^(5/12) = 2^0.41667 ≈ 1.3348
The browser will set its source playbackRate to about 1.3348, which means the rendered output is shorter by the same factor. Expected output duration = 60 / 1.3348 ≈ 44.95 seconds. The document row should read: input 60.00 s at 44,100 Hz mono, semitone shift +5, playback rate 1.3348, expected output duration 44.95 s, output file audio-pitch-plus5.wav.
That row is enough for anyone reading the document later to reproduce the run, to predict the duration of a similar shift on a different input, or to verify a download against the planned values. If you repeat the same +5 shift on a 120-second input, the expected output duration is 120 / 1.3348 ≈ 89.90 seconds; the formula scales linearly with input length, so the relationship in the table above holds for any starting duration.
Verifying the Documented Result Against the WAV
A documented procedure is only useful if the documented values match the file that was actually produced. After each Audio Pitch Changer run, open the downloaded WAV in a trusted local player and confirm the channel count, sample rate, and duration listed in the document. If the tool reported a duration change, that change should match the difference between the input length you wrote down and the output length the player shows. A mismatch usually means the wrong semitone value was logged, or the document was copied from a previous run with different settings. For a deeper verification walkthrough, see verify an audio pitch changer result step by step.
Because the tool uses playback-rate resampling rather than a time-stretching algorithm, the original tempo, speech cadence, and beat positions are not preserved; the document should state this explicitly so a future reader does not assume the result is tempo-neutral. If the production requires pitch change at fixed duration, the document should also note that a dedicated phase-vocoder or other time-stretching workflow is the appropriate alternative; the Audio Pitch Changer is not designed for that case. Recording both what the tool did and what it deliberately does not do keeps the procedure honest.
Keeping the Procedure Document Useful Over Time
Procedures drift if they are not revisited. After every shift, append the new entry below the previous one with the same headings so the document grows into a log rather than a one-off note. When a run fails — for example, when the planned shift pushes the output over the 30 million channel-sample budget because the input is long and the shift is negative — copy the error text into the document verbatim. The exact wording matters, because the Audio Pitch Changer reports that the requested shift is over budget and that nothing was truncated; future readers benefit from knowing that message is the one to look for when a similar input is rejected.
The document should also record any context that the WAV itself cannot carry. The download is a freshly encoded uncompressed PCM16 RIFF/WAVE file, and it does not preserve the original codec, compression quality, bitrate, tags, artwork, chapters, cue points, loop metadata, or container metadata. If those details matter to the project, the document is the only place they will be remembered. Treat the WAV as the audio artifact and the procedure document as the project record: kept together, they let a future reader reproduce the result, audit the choices, and decide whether the same workflow is appropriate for the next shift.
For a deeper look, see Audio Speed Changer Mistakes That Break Your Output.