MIDI running status: what omitting a status byte actually changes

Every row is the same 169 B source with one variable changed: k, the number of leading omittable status bytes removed, in event order. No audio was re-converted, no note was added or removed, and no timing value was altered. Each of the four copies was re-opened from scratch with an independent parser.

1. What the 169 B source file declares

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. The chunk table below is read 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, ending at tick 7,627. Its status-byte sequence is FF C0 90 90 80 80 … 80 80 FF — the notes arrive in same-status pairs, which is exactly what makes running status applicable. The two versions of this file's engine are listed separately:

2. What running status means

In a Standard MIDI File, each channel event normally carries a status byte followed by one or two data bytes. When consecutive channel events share a status, the later one may omit that byte; a reader carries the previous status forward until a new explicit status or a meta event appears. It is a space-saving rule defined by the file format, not a feature of any converter and not a statement about the music. This section is general format context and is excluded from the exclusive-material denominators above. The Note On / Note Off bytes and the delta-time encoding were measured separately on this same file.

3. One variable, four real files

Four copies were built with k = 1, 2, 7 and 14. In each, the first k omittable status bytes are deleted and nothing else is edited except the note track's length field, which must fall by k for the chunk table to stay consistent. Each copy was re-opened from scratch with @tonejs/midi 2.0.28, and independently walked by a second parser that implements running status directly:

The size is strictly linear: each omitted byte removes exactly one byte from the file and one from the length field. The header is untouched — format 1, ntrks=2, division 480, 0 tempo events. All four copies are parsed as 14 notes at PPQ 480, and the second parser reads the same 14 notes with identical (midi, ticks, durationTicks, velocity) tuples at the same 7,627-tick end point. The four derived files are not published; every reading can be reproduced from the published source.

4. Every figure recomputed from the bytes

No figure below is copied from a rendered page. Chunk lengths come from the files' own length fields, note counts from the independent parsers, and totals from the byte formula fileBytes = 14 + (8+8) + (8+length) for the three chunks:

Division 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 0 tempo events and none of the four edits adds one. The final event sits at 7,627 ticks = 7.944792 s in every copy. The single-variable check is stronger than a successful parse: all 14 notes were compared row by row on (midi, ticks, durationTicks, velocity) against the source, and re-inserting the deleted bytes rebuilt a file whose SHA-256 equals the source byte for byte — and that rebuilt file was itself re-opened and read as 14 notes at PPQ 480:

Byte equality alone would prove only that nothing else moved; the re-parse is what proves the result is still a usable MIDI file.

5. Fourteen omittable bytes, cell by cell

Which status bytes can be omitted is determined by the file, not chosen by hand: a channel event whose status equals the immediately preceding channel event's status, with no meta event between them, is a candidate. The source has exactly 14 such positions. The table lists each one with its original offset, the status byte, its delta-time bytes and its absolute tick; the last column shows whether it is among the first seven omitted at k=7:

Every second event of the 28 note messages qualifies, alternating 90 (Note On) and 80 (Note Off); the Program Change at C0 and the two FF meta events do not. Offsets are absolute positions in the original 169 B file, so after deleting earlier bytes a later byte sits k positions earlier in its copy. The delta bytes and ticks are the parser's own reading of the source, not a transcription of a rendered table.

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

Six further edits change exactly one byte each in the 162 B k=7 copy — a delta-time byte, a note-number byte, a velocity byte, the low byte of the length field, the MThd magic, or the End-of-Track meta type. Every copy stays 162 B. The readings are what the independent parser actually returned:

Five of the six still parse, and one of those five silently loses information: changing a note-number byte by one semitone leaves its Note Off paired with a different pitch, so only 13 notes are read. Changing a delta byte, a velocity byte, the length field's low byte, or the End-of-Track meta type still returns 14 notes — a file that still opens can carry a shifted tick, a different loudness, a mismatched declared length or a changed terminator. Only the M → X magic-byte edit throws. A file that still parses is not necessarily a file with the same content. That is why the four reconstructions were checked for chunk-formula totals, per-note equality, and a byte-for-byte restore that can be re-opened, and not merely for "it opened". The Program Change byte and the format field were measured separately.

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

Open the 169 B source file in a hex editor, enumerate its 31 events from body start 38, mark each channel event whose status repeats the previous channel event's status, delete the first k of those status bytes, reduce the note track's length field by k, and re-open with a MIDI library that reports note pitch, ticks, velocity and per-track counts. The four derived files and six control files 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 writes files that rely on running status.

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 omit-status reconstructions and six single-byte controls, measured on 14 November 2026 (UTC). General format facts, method notes, limits and disclaimers are excluded from the exclusive-material denominators above.