MIDI Program Change: the one byte that names an instrument

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

1. Where the instrument byte lives in a 169-byte MIDI file

The source is the 169 B MIDI file published on this site on 24 October 2026, alongside the test WAV it came from. Its first 14 bytes are 4D 54 68 64 00 00 00 06 00 01 00 02 01 E0: the MThd chunk declares format 1, two tracks and a division of 01 E0 = 480 ticks per quarter note. The three chunks were read straight from the file's own length fields, with no assumed offsets:

The first MTrk is an 8 B conductor track with a track-name meta event and end-of-track. The second holds 131 B of events, beginning with another track-name event. Walking forward from the note-track body start (offset 38) through the variable-length delta-times locates the Program Change event from the bytes themselves rather than from a remembered subscript:

The C0 status byte splits into two halves: 0xC0 >> 4 = 0xC means Program Change, and 0xC0 & 0x0F = 0 means channel 0. The next byte is the program number. The delta-time bytes before each event and the PPQ division field are separate measurements on this same published file; this page is about the three bytes 00 C0 00.

2. What a program change is, and what it is not

General MIDI assigns numbers 0–127 to instrument names: 0 is acoustic grand piano, 40 is violin, 127 is gunshot. A Program Change event stores one such number on one channel. It is metadata, not sound. The file never contains a piano sample or a violin waveform; whatever plays the file decides what that number sounds like, and two players can sound entirely different while reading identical bytes. Editing this byte therefore changes a label and nothing else about the notes. It is also not a way to split one track into instruments: a single-track file with one Program Change byte is still one track. The MIDI to MP3 tool on this site renders a .mid to audio; the byte inspection on this page does not.

3. Four single-byte edits to the program number

Four copies were made, each changing only the program-number byte at offset 44. Every copy is 169 B, differs from the source in exactly one byte, and was re-opened from scratch with @tonejs/midi 2.0.28. The GM number column is the decimal value of the byte written; the instrument name is what the parser reported, not a name supplied by this page. The notes column is the parser's note count across all tracks:

Each edit leaves 168 B unchanged, keeps 14 notes and PPQ 480, and leaves the file parseable. The instrument number read by the parser equals the decimal value of the byte written in all four cases: 0A = 10, 28 = 40, 46 = 70, 7F = 127. A single data byte therefore selects the label while the musical content is bit-for-bit the rest of the file. Writing the original 00 back over the changed byte restores the exact source SHA-256, which is the structural check that each copy is a one-byte edit and not a re-encoded file.

4. Every number recomputed from the bytes

No figure below is copied from a rendered page. The left column is the formula, the middle is the computed result, and the right says where the same value appears independently. Chunk lengths come from the file's own length fields; nibbles come from the status byte; GM values come from hexadecimal; 168 B is subtraction:

The division bytes 01 E0 give 480 ticks per quarter note, so one tick is 60 / (120 × 480) = 1/960 s at the SMF default of 120 BPM. The file itself contains no tempo event, which is why the default applies; none of the four program edits changes that. The format and track-count fields were measured separately on this same file, and the 33 delta-time fields were enumerated from its events. Those values are unchanged by every edit on this page.

5. A structural control: editing the status byte instead

Changing the data byte changes a label. Changing the adjacent status byte at offset 43 changes what the following bytes mean. Three more one-byte edits were made there, still 169 B and still 168 B unchanged. The parser's readings show why "the file opens" and "the file says the same thing" are different claims:

C0→C1 moves the event to channel 1; the file still parses and still holds 14 notes, but the parser now reports two tracks because the channel changed. C0→B0 turns the event into a Control Change, and the parser reads 12 notes instead of 14 while still opening the file. C0→FF turns it into a meta event and the parse fails outright. A file that still parses is not necessarily a file with the same content. This is also why this page never treats a successful parse as proof of a good conversion; the four program edits were checked for note count, track count, PPQ and a byte-for-byte restore, not merely for "it opened".

6. The 14 notes do not move

The strongest check is the note list itself. The independent parser read these 14 notes from the source file; the same list, with the same pitches, velocities, start ticks and duration ticks, was read from each of the four program-number copies. Pitch is the MIDI note number, duration ticks come from the note-on and note-off delta-times, and time is seconds at 1/960 s per tick:

Nothing in this list names an instrument. The Program Change byte sits before the first note-on and applies to the whole track, which is exactly why changing it cannot add, remove, retune or re-time a note. If you are chasing wrong notes after a conversion rather than a wrong instrument label, the clean-up MIDI page covers the note artefacts that a real audio-to-MIDI run leaves behind.

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

Download the 169 B source file, open it in any hex editor, and look at offsets 42–44: 00 C0 00. Write one byte at offset 44, save, and re-open with a MIDI library that reports instrument names. The chunk length fields do not need editing because all seven variants are in-place single-byte writes; writing 00 back restores the original file exactly. If you would rather convert audio than edit bytes, the MP3 to MIDI converter and the other format pages run in your browser and produce a single-track .mid you can inspect the same way.

What is not here: no measurement of conversion accuracy, 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. The numbers come from one 169 B file published on 24 October 2026 and seven one-byte edits of it, measured on 10 November 2026 (UTC). A different audio input produces a different file, and the current engine produces a different byte count from the same WAV. General format facts, method notes, limits and disclaimers are deliberately excluded from the exclusive-material denominators above.