MIDI Note On and Note Off: three bytes, one note

All five rows are the same 169 B file with one byte rewritten. No audio was re-converted, no note added, no track split: only the first note's velocity moved. The last column is what an independent parser read after re-opening each copy from scratch.

1. Where the three bytes sit in a 169-byte MIDI 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 locates the first Note On from the bytes themselves. The offsets below were derived by enumerating events, not typed in:

0x90 >> 4 = 9 means Note On, 0x90 & 0x0F = 0 means channel 0; the release status 0x80 has a high nibble of 8. Data bytes are 7-bit, so note number and velocity are in 0..127, and this file's note-off velocity is 0x00. Delta-time bytes and the PPQ field were measured separately on this same file; this page is about the three bytes 90 48 26.

2. What Note On and Note Off are, and what they are not

The high nibble of the status byte carries the message type and the low nibble carries the channel. The two data bytes are the note number and velocity; a MIDI file stores the numbers, not a loudness curve or an audio sample. A Note On with velocity zero is conventionally a release, which is why one byte can remove a note without deleting any bytes. Pairing a note-on with its note-off gives the duration: the parser subtracts the start tick from the release tick. None of this is audio separated into parts. The MIDI to MP3 tool renders a .mid to audio; this page only inspects bytes. The Program Change byte is a separate label before these notes.

3. Four single-byte edits to the velocity byte

Four copies each change only the velocity byte at offset 48. Every copy is 169 B, differs in exactly one byte, and was re-opened from scratch with @tonejs/midi 2.0.28. The velocity column is the decimal byte written; the normalised column is that byte / 127 to four decimals, exactly what the parser reported:

Each edit leaves 168 B unchanged, keeps 14 notes and PPQ 480, and stays parseable. The first note remains C5 at pitch 72 and tick 0; the other 13 keep identical pitch, velocity, start tick and duration tick. 7F gives 127 / 127 = 1.0000, the top of the range. Writing 26 back restores the exact source SHA-256, the structural check that each copy is a one-byte edit rather than a re-encoded file. A successful parse alone would not establish this: the note list was compared row by row.

4. Every number recomputed from the bytes

No figure below is copied from a rendered page. Chunk lengths come from the file's own length fields, nibbles from the status bytes, velocity from hexadecimal divided by 127, and 168 B 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; the file has no tempo event and none of the four edits changes that. Enumerating the note track reaches offset 169, the end of the file, at tick 7,627 = 7.944792 s. The format and track-count fields were measured separately; the 33 delta-time fields in the whole file include the two conductor-track events absent from this page's 31-event list.

5. A structural control: editing the other two bytes, and one meta-length byte

Changing velocity changes one value; changing the status or note-number byte changes what the message means, and changing a meta length byte changes how many following bytes it consumes. Eight more one-byte edits at offsets 41, 46, 47 and 48 are still 169 B with 168 B unchanged. The readings show why "it opens" and "it says the same thing" differ:

00 in velocity turns the first Note On into a release: the file still parses but reads 13 notes because that note never starts. 90 → 80, 91 or B0 also stays parseable with a lower note count; 91 moves the channel and the parser reports two tracks. FF makes the following bytes a meta event and swallows eight notes' worth of structure. At offset 41, changing the meta length 00 to 80 makes it the first byte of a two-byte VLQ, so the event stream is misread and the parse fails. A file that still parses is not necessarily a file with the same content, and a file that fails to parse may still be 169 B with one byte changed. The four velocity edits were therefore checked for note count, track count, PPQ, a row-by-row note comparison and a byte-for-byte restore, not merely for "it opened".

6. All 31 note-track messages and all 14 notes

Walking delta-times and status bytes until the byte cursor reached offset 169, the end of the note track, yields 2 meta events, 1 Program Change, 14 Note On and 14 Note Off messages. Each row gives the offset, delta ticks, status byte and the message with its data bytes. No event uses running status.

These 14 notes were read by the independent parser. The four velocity copies reproduce the same pitches, start ticks and duration ticks; only the first note's velocity differs. Time is seconds at 1/960 s per tick:

Nothing here encodes an instrument or a separate part: velocity belongs to one note event, so changing it cannot add, retune or re-time a note. For wrong notes after a conversion rather than a wrong velocity, see the clean-up MIDI page.

7. How to repeat this yourself, and what this page does not claim

Open the 169 B source file in a hex editor at offsets 46–48: 90 48 26. Write one byte at offset 48, save and re-open with a MIDI library that reports velocities. Chunk lengths need no editing: all twelve variants are in-place single-byte writes, and writing 26 back restores the original exactly. To convert audio instead, the MP3 to MIDI converter runs in your browser and produces a single-track .mid.

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