Single-Track vs Multitrack MIDI

"Single-track" and "multitrack" are often used as if they were a property you can hear. In a Standard MIDI File they are a property of the byte layout. This page takes one real file, reads its chunk table, and changes exactly one variable at a time to show what actually moves.

1. What the 14-byte header actually declares

The source is the 169 B MIDI file published on this site on 24 October 2026 — the actual downloaded output of running the test WAV through the browser converter. Its first 14 bytes are 4D 54 68 64 00 00 00 06 00 01 00 02 01 E0. Read as a Standard MIDI File header:

Note the mismatch that matters: the header says format 1 and ntrks = 2, yet this is a single-track conversion. Format 1 is a capability, not a claim that two instruments were recorded. Walking the chunk length fields gives the whole file:

An independent parse with @tonejs/midi 2.0.28 on 8 November 2026 returned 1 track, 14 notes, channel 0, instrument acoustic grand piano, 0 tempo events and 0 time-signature events. The empty first MTrk is folded into the header information by the parser, so the two declared chunks collapse to one usable track. That is why "how many tracks are in this MIDI file" has two honest answers: 2 chunks on disk, 1 track in the parser.

2. Three one-variable changes, measured

Each row changes one variable in the same 169 B file. The injected files were written to disk and parsed again with the same independent library; "Tracks parsed" and "Notes" are those second parses, not predictions.

The first row is the only one that changes the file size. A minimal legal MTrk is 4 bytes of ID, 4 bytes of length and 4 bytes of payload (00 FF 2F 00, End of Track) — 12 B in total. 169 + 12 = 181 B. The header field and the appended chunk are the two required parts of the single change "add one track". The parser then reports 2 tracks, but the new one has 0 notes, so the audible content is identical.

The other two rows are in-place replacements: 2 status bytes and 1 data byte respectively, +0 B. The file already contains 00 C0 00 at offset 42 — a 3 B Program Change event (1 delta + 1 status + 1 data). Changing its data byte from 00 to 28 (GM program 40, 0-indexed) relabels the instrument without adding or removing a single byte. A three-byte note-on message takes 0.96 ms on a 31,250 bit/s MIDI cable; the program byte costs the same three-byte slot, so neither edit changes timing.

3. Channel 9 does not create a drum track

This is the edit most likely to be misread. In General MIDI, channel 9 is reserved for percussion, and many players map it to a kit by default. Moving one C4 to that channel changes the label a parser attaches, not the musical content.

After the channel edit, the parser returns two tracks: 13 notes at channel 0 under acoustic grand piano, and 1 note at channel 9 under standard kit. That "standard kit" is a General MIDI lookup table entry, not a detected percussion performance. The single note is still pitch 60, still 936 ticks long, still velocity 91 — the same C4 from the original file. A file that genuinely preserved a drum part would contain percussion notes at their own pitches and times; this one contains one relabelled piano note. No drum track was recovered, and no instrument separation took place.

The same caution applies to the program edit. Changing C0 00 to C0 28 makes the parser say violin, but the 14 notes are byte-for-byte the same events. A program number is a playback hint, not evidence of what was recorded.

4. Check the arithmetic

Every size on this page comes from a formula applied to the file's own length fields. Download the 169 B source and hash it; the sha256 begins 90795f6ff271.

The 120 in the tick-duration row is worth repeating: this file contains no Set Tempo event, so 120 BPM is a default the player supplies, not a value stored in the file. With PPQ 480, one tick is 60 / (120 × 480) = 1/960 second. If your converted file plays at the wrong speed, see MIDI wrong tempo after conversion.

5. All 14 notes, and where they live

These are the 14 notes parsed from the 169 B source on 8 November 2026, sorted by start tick then pitch. The eight odd-numbered rows are the intended C4–C5 scale; the six even-numbered rows are short octave-ghost artefacts of the transcription. All 14 sit on channel 0 in the original file. Seconds use the formula above.

In the channel-9 injected copy, only row 1 moves; rows 2–14 stay on channel 0. That single row is the entire "second track" the parser reports. If you want to remove the six ghost rows from a real conversion, see clean up MIDI.

6. What this means if you convert audio here

• You get one .mid file with one note track. Every note is written on channel 0 with a piano program; there are no separate instrument parts.
• If a DAW shows a "drum" or "kit" sound after you import, check the channel and program bytes first. A channel-9 label is a playback assignment, not a recovered drum performance.
• Adding tracks, changing programs or reassigning channels is editing work you do after download, in a DAW or notation program. This site does not do it for you.
• See what is a MIDI file for the byte-level structure, and MIDI vs MusicXML for how the same 14 notes look as XML text.

What this page does not cover

• Stems, source separation or per-instrument transcription. The three injected files are byte edits of one single-track MIDI, not multitrack audio analysis.
• MIDI 2.0, UMP or MIDI-CI. Everything here is a Standard MIDI File on disk.
• Transcription accuracy or converter comparisons. The edits demonstrate file structure; they measure no tool's performance.
• Automatic tempo or BPM detection. The source has zero tempo events and the 120 BPM used in the formulas is a documented player default.