One track per instrument: what a second MIDI track actually adds in bytes

Every row above is the same 169 B source with one variable changed: k, the number of notes reassigned to the new track (highest pitch first, then earliest start tick on a tie). No audio was re-converted, no note was added or removed, and no timing value was altered. The last four rows were each 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 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. So the header's ntrks=2 counts one conductor track and one note track — not two instruments. The independent parser returns 1 note track, 14 notes, PPQ 480 and 0 tempo events. The format field and the delta-time encoding were measured separately on this same file.

2. A track is a container, not an instrument

In a Standard MIDI File, a track is an ordered stream of timestamped events. Nothing in the chunk header identifies an instrument: the association comes from a Program Change message and, optionally, a track-name meta event, both interpreted by whatever opens the file. A file can declare three tracks and give all of them the same program, or declare one track carrying many programs. That is why "one track per instrument" is a description of how a human (or a transcriber) chose to lay out events, not a property the format enforces. Editorial pages about per-instrument transcription usually discuss workflows and DAW import; this page says nothing about those, and instead measures only what the bytes do when a second track is actually built. This section is general format context and is excluded from the exclusive-material denominators above.

3. One variable, four real two-track files

Four copies were built with k = 1, 2, 7 and 14. In each, the k highest notes (ties broken by earliest start tick) are moved out of the original note track A and into a newly encoded note track B carrying Program Change 40. Both tracks keep a track-name meta event, a program event and an End-of-Track marker, so their payload lengths are 4 + 3 + Σ event bytes + 4. Each copy was re-opened from scratch with @tonejs/midi 2.0.28:

The size is not monotonic: k=7 is the largest file (194 B) and k=14 the smallest of the four (188 B). Two opposing effects explain it. Each added track duplicates 11 B of fixed events (track name 4 + Program Change 3 + EOT 4) and adds an 8 B chunk header, while splitting a delta-time chain can change the number of VLQ bytes: at k=7 the two event streams total 126 B versus 120 B in the source, so 169 + 8 + 11 + 6 = 194 B. At k=14 track A is empty (11 B payload) and track B holds the original 120 B of event bytes unchanged, so 169 + (8 + 11) = 188 B. Every figure in that arithmetic comes from the chunk table below or from the variant rows above.

Offsets are cumulative from each file's own length fields; the fourth chunk is the new instrument track. At k=1 it begins at offset 161, at k=7 at 112 and at k=14 at 49, because track A shrinks as notes leave. The last event tick of each track changes with the split (at k=1, track A ends at 7,627 and track B at 4,884), but the file-wide final tick stays 7,627 in all four copies.

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 parser, and the totals from the allocation formula fileBytes = 14 + (8+8) + (8+lenA) + (8+lenB):

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 merging the two tracks back, restoring program 0 and setting ntrks back to 2 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 only prove that nothing else moved; the re-parse is what proves the result is still a usable MIDI file.

5. Fourteen notes, cell by cell at k=7

At k=7 the two tracks split 7 / 7. The table lists every source note in parser order, its note-number byte on disk, and which track it lands in. Selection was highest pitch first with start tick as the tie-breaker, so the two C5 notes at MIDI 72 both move to B while B4 at 71 stays in A:

The six columns are the parser's own reading of the source plus the deterministic selection rule; no column is a transcription of a rendered table. Start ticks are identical in the source and in both tracks after the split: reassigning a note changes which delta-time chain it belongs to, not when it sounds. The two 48 bytes at rows 1 and 14 are the same MIDI 72 at different times, which is why the tie-breaker is stated rather than left implicit.

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

Six further edits change exactly one byte each in the 194 B k=7 copy — the declared track count, the new track's chunk length, its program, its first Note On channel, its End-of-Track meta type, or its chunk magic. Every copy stays 194 B. The readings are what the independent parser actually returned:

Five of the six still parse, and two of those five silently lose information: declaring ntrks=2 makes the parser see only 7 notes, and moving one Note On to channel 1 makes it see 13. Changing the chunk length by one, the program byte, or the EOT meta type still returns 14 notes — a file that still opens can have a wrong declared length, a different instrument, or a broken 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, per-track delta re-encoding, and a byte-for-byte restore that can be re-opened, and not merely for "it opened". The Note On / Note Off bytes and the Program Change byte 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, choose the k highest notes, and write two MTrk chunks whose length fields equal 4 + 3 + Σ events + 4 each, with each event's delta taken relative to the previous event in that same track. Set the header's declared track count to 3 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 assigns instruments to tracks.

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