Transposing a MIDI file: what actually changes in the bytes

All five rows are the same 169 B file: the only variable is k, the semitone offset applied to every note-number byte. No audio was re-converted, no note added, no track split. The last column is what @tonejs/midi 2.0.28 read after re-opening each copy from scratch.

1. Where pitch actually sits in a 169 B file

The source is the 169 B MIDI file published here on 24 October 2026, alongside the test WAV. Its first 14 bytes are 4D 54 68 64 00 00 00 06 00 01 00 02 01 E0: MThd declares format 1, two tracks and division 01 E0 = 480 ticks per quarter. Chunks below come from the file's own length fields, with no assumed offsets:

The first MTrk is an 8 B conductor track; the second holds 131 B of events. Walking from its body start at offset 38 through the variable-length delta-times enumerates 31 events: 14 Note On, 14 Note Off, one Program Change and two meta events. These byte positions were derived by enumeration, not typed in:

Each Note On / Note Off message carries two data bytes: note number then velocity. That gives 28 note-number bytes and 141 B of the file that a transposition leaves completely alone. The header contains no key or transpose field at all, and the independent parser reports 0 key-signature events. The Note On / Note Off bytes and the PPQ field were measured separately on this same file.

2. Key signatures, tempo events and the header are not pitch

A common mental model is that changing a song's key means editing one header value. In this file that value does not exist. The header declares format, track count and division; the conductor track holds only a track-name meta event and an End-of-Track marker. The independent parser reports 0 tempo events, 0 time-signature events and 0 key-signature events. Adding semitones to the notes therefore cannot be done by editing a single field: every note-number byte of every note message has to change, and the pairing Note Off for each Note On has to change with it. This page reports only what the bytes declare and what the parser returned; it makes no claim about how any particular editor displays a key. The format field and the delta-time encoding were measured separately.

3. One variable, four transpositions

Four copies apply k = +1, +5, +7 and +12 semitones to the same 28 note-number bytes. Every copy is 169 B, differs in exactly those bytes, and was re-opened from scratch with @tonejs/midi 2.0.28. The formula is byte' = byte + k, because an SMF note-number data byte is the 7-bit MIDI note number:

Each copy keeps 14 notes, PPQ 480, 0 tempo events and the same 14 start ticks, duration ticks and velocities as the source. Writing every original byte back restores the exact source SHA-256 — the structural check that these are in-place edits and not re-encoded files. A successful parse alone would not establish this: all 14 notes were compared row by row against midi' = midi + k and against the unchanged timing columns. Note numbers stay inside 0–127 for all four shifts (highest source pitch 81, highest shifted pitch 93); a shift that pushed a byte past 0x7F would leave the 7-bit data-byte range, which is why the range is stated here rather than assumed.

4. Every figure recomputed from the bytes

No figure below is copied from a rendered page. Chunk lengths come from the file's own length fields, note numbers from the data bytes, and the unchanged byte count from subtraction:

01 E0 gives 480 ticks per quarter, so one tick is 60 / (120 × 480) = 1/960 s at the SMF default of 120 BPM; this file has no tempo event, and none of the four edits changes that. Enumerating the note track reaches offset 169 at 7,627 ticks = 7.944792 s. Pitch names follow NOTE_NAMES[midi % 12] + (floor(midi / 12) - 1): 60 is C4, 72 is C5, 84 is C6. The Program Change byte and the byte-level anatomy of this file were measured separately.

5. Fourteen notes, cell by cell

The independent parser returned 14 notes from the source, with pitches between 60 and 81. The table shows each note's base pitch, its note-number byte on disk, and the reading after the smallest (+1) and largest (+12) shifts. Both shifted columns were checked against the formula before being written here:

Both shifted byte columns equal base byte + k in hex, and both shifted name columns equal the note name recomputed from that byte. Start ticks are identical in all three readings: transposition moves pitch, not time. All 56 cells in the four shifted columns came from the parser and were independently recomputed from the two rules above.

6. Structural controls: parseable is not the same as intact

Six more edits change exactly one note-number byte each — either the first Note On's pitch byte or the first Note Off's pitch byte — without changing its partner. All six are still 169 B with 168 B unchanged. The readings below are what the parser actually returned:

All six still parse, and all six return 13 notes instead of 14: breaking one half of a Note On / Note Off pair silently drops that note. Even writing 0x80 — a byte with the high bit set, which is not a legal data byte — does not make this parser throw; it still parses and reads 13 notes. A file that still parses is not necessarily a file with the same content. That is why the four transpositions were checked for note count, PPQ, a row-by-row pitch comparison, unchanged timing and velocity, and a byte-for-byte restore, and not merely for "it opened". In this round of controls there is no parse-failure row; we report that as measured rather than adding one from a different kind of edit.

7. Repeating this, and what this page does not claim

Open the 169 B source file in a hex editor, add k to each of the 28 note-number bytes listed in section 1, save and re-open with a MIDI library that reports note pitch, ticks and velocity. Chunk lengths need no editing: all four variants are in-place writes, and restoring the original bytes gives back the source SHA-256. The variant files themselves are not published here; the source file is, and every reading above can be reproduced from it. To convert audio instead, the MP3 to MIDI converter runs in your browser and produces a single-track .mid; the MIDI to MP3 tool renders in the other direction. Neither tool transposes.

Not here: no conversion-accuracy measurement, no speed figure, no tempo, BPM or key detection claim, no multitrack or per-instrument output, no drum track, no URL or YouTube input, no DAW test, and no claim that this site is more accurate than anyone else. Numbers come from one 169 B file published on 24 October 2026, four single-variable injections and six single-byte controls, measured on 12 November 2026 (UTC). General format facts, method notes, limits and disclaimers are excluded from the exclusive-material denominators above.