Audio to MIDI: Did the Octave Change, or Just Its Name?
Compare the MIDI note number before transposing. A note called C4 here can be displayed as C3 in another editor while remaining note 60. That is a naming difference, not an octave shift. In our local four-note test, changing the display convention left all 72 MIDI bytes untouched. Actually moving the phrase down an octave changed eight key-number bytes and produced 48–52–55–60 instead of 60–64–67–72.
If the note number is unchanged but playback really sounds lower, check the instrument, tuning, track transpose and pitch bend separately. Matching numbers rule out a change in those saved note events; they do not certify identical sound from every receiving instrument.
One saved number, three possible labels
AudioToMidiNow labels note 60 as C4. Its note-name function divides the MIDI number by twelve and subtracts one from the octave. A different display convention can subtract two, or subtract zero. The key number in the file does not change when a viewer calculates a different label.
The distinction matters after converting audio to MIDI: do not move a correctly detected phrase merely because the receiving piano roll uses another octave name. Apple's Logic Pro display documentation describes C3 and C4 naming settings for middle C, note 60. The MIDI Association's message summary defines note-on and note-off messages in terms of a key number and velocity. Neither a letter nor a printed octave digit replaces that number in the channel note message.
The following labels were calculated locally from our detected keys. They are a display-convention comparison, not screenshots or measurements from Logic Pro, GarageBand or another installed DAW.
| Saved key | This site's label | Middle C = C3 | Middle C = C4 | Middle C = C5 |
|---|---|---|---|---|
| 60 | C4 | C3 | C4 | C5 |
| 64 | E4 | E3 | E4 | E5 |
| 67 | G4 | G3 | G4 | G5 |
| 72 | C5 | C4 | C5 | C6 |
A C3 label therefore does not, by itself, tell you whether the file contains 48 or 60. Ask which convention the editor is showing, or open a numeric event view. In this table every row describes one fixed key, not three different performances.
A real transpose changes the file
Measured on this Windows machine on November 1, 2026. We generated a four-second, mono, 44,100 Hz, signed 16-bit WAV containing separate sine tones for keys 60, 64, 67 and 72. The amplitude was 0.2 before PCM rounding, each tone lasted 0.55 seconds, and the attack and release ramps were 10 ms. Intended starts were 0.25, 1.15, 2.05 and 2.95 seconds. The WAV is 352,844 bytes.
We read the saved PCM samples back, ran this site's unchanged downsampling and Balanced note-detection functions, then used its unchanged MIDI writer. The detected keys matched those four intended numbers. We also made two deliberate controls from the same detected events: subtract twelve from every key, or add twelve. These are constructed transpositions, not additional audio transcriptions.
| Download | Saved note-on keys | File bytes | Changed bytes vs original |
|---|---|---|---|
| Unchanged export | 60, 64, 67, 72 | 72 | 0 |
| Deliberately down twelve | 48, 52, 55, 60 | 72 | 8 |
| Deliberately up twelve | 72, 76, 79, 84 | 72 | 8 |
Our separate Python parser reopened the actual files. Each control differs at byte offsets 31, 36, 41, 46, 51, 56, 61 and 66, counting the first byte as zero. Those are the four note-on and four note-off key bytes. Starts, ends, velocities, tempo, track length and every other byte remain identical. All three files have the same size, so size alone would miss the transposition.
The right pitches do not make the timing right
This fixture is intentionally not presented as a perfect transcription. The independent parser found these event times in the unchanged file:
| Key | Intended start | Saved start | Saved gate length | Start / end tick |
|---|---|---|---|---|
| 60 | 0.250 s | 0.092708 s | 0.742708 s | 89 / 802 |
| 64 | 1.150 s | 0.975000 s | 0.743750 s | 936 / 1650 |
| 67 | 2.050 s | 1.904167 s | 0.696875 s | 1828 / 2497 |
| 72 | 2.950 s | 2.786458 s | 0.742708 s | 2675 / 3388 |
All four starts were early in this run, and the saved gates exceeded the intended 0.55 seconds. A different octave label cannot explain or repair those errors. The files use 480 ticks per quarter note and a 500,000 microsecond tempo event. Times above come from those serialized bytes, including rounding, rather than copying the detector's floating-point values. For note-length checks, use the separate duration comparison.
Check the handoff before changing pitches
- Keep the original audio and exported MIDI. Duplicate the editable region before trying repairs.
- Compare a numeric key at both ends. If the source export says 60 and the imported event still says 60, a C4-to-C3 label difference is not evidence of a saved octave change. Check several notes rather than the visible range label alone.
- If every saved key changed by twelve, investigate an actual transpose. Our down-octave control provides an exact byte-level example. A live track transpose may instead act during playback without rewriting the source file.
- If numbers match but the sound differs, separate the playback path. Check instrument mapping, octave switches, tuning and pitch bend. Our pitch-bend example demonstrates a separate state problem; changing note names does not reset that state.
- Return to the recording for transcription accuracy. A detector can make a real pitch mistake even when an editor labels its result consistently. Do not transpose a whole phrase to repair one wrong event.
With an A4 = 440 Hz, equal-tempered reference, key 60 corresponds to about 261.626 Hz, key 48 to 130.813 Hz and key 72 to 523.251 Hz. These are calculated reference frequencies, not measured audio output from a DAW. An instrument can transpose, detune or map a key to a sample, so a key number alone is not a guarantee of the sound you will hear.
Files, hashes and what we did not test
The unchanged MIDI SHA-256 is 3082871b9a1597e2344ec110d63dcd6a187c8655d3d5591fe43f032d2b93fd73. Down twelve is 03a699c4d1062090c4dffbca93def0e4435c5c3532dda283a596a8808a332203; up twelve is 460ac35bff79c0be45181a5755b4dec4a47337136621118b37def77b6cf1efdc. Re-running in a fresh directory reproduced the WAV and all three MIDI files byte for byte.
Download the known audio input, generation and detection script, independent Python parser, detector observations and label calculations, parsed byte comparison, and event table CSV. Run the generation script from the AudioToMidiNow project root with its unchanged dist/script.js, or set SITE_SCRIPT to that script's path; then run python inspect.py beside the generated files. The JSON records the exact site-script fingerprint so a later detector revision can be distinguished from this run.
This was a synthetic PCM and code-level test, not a real instrumental performance, competitor conversion, DAW import, listening test or browser audio-decoding benchmark. The label columns are our arithmetic demonstrations. The parser supports these explicit-status single-track fixtures, not every MIDI file or tuning system. It proves the saved data differences in this example; it does not diagnose every apparently low-sounding import.