What a DAW reads from one real MIDI file: a Logic Pro example

All five rows are the same 169 B file with one byte rewritten at offset 53. No audio was re-converted, no note added, no track split: only one delta-time value moved. The last column is what @tonejs/midi 2.0.28 read after re-opening each copy from scratch.

1. The bytes a DAW has to read

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 each event from the bytes themselves. These offsets were derived by enumerating events, not typed in:

The last byte of the note-track length field at offset 37 is 83 = 131. The first Note Off's delta at offset 53 is 0x64 = 100 ticks; the End-of-Track meta type at offset 167 is 0x2F with length 0. The delta-time and VLQ encoding and the PPQ field were measured separately on this same file; this page is about what those bytes do to the note readings.

2. Declared tracks and parsed tracks are different readings

The header says ntrks = 2, but the independent parser reports one track with 14 notes: the 8 B conductor track carries only a track-name meta event and an End-of-Track marker, so it contributes no notes. A DAW reading this file has to decide what to do with an empty conductor track; this page reports only what the header declares and what the parser returned. It does not claim that any particular DAW shows one region, two regions, or a specific instrument name. The single-track versus multitrack page covers what this site outputs; the format field was measured separately. None of these readings is a claim that a file was tested in Logic Pro.

3. One delta byte, four different timelines

Four copies each change only the delta byte at offset 53. Every copy is 169 B, differs in exactly one byte, and was re-opened from scratch with @tonejs/midi 2.0.28. A single-byte VLQ holds its value directly, so the byte written is the delta in ticks. The two duration columns are tick counts read back by the parser for the first two notes:

Each edit leaves 168 B unchanged, keeps 14 notes and PPQ 480, and stays parseable. The pitch and velocity sequence is identical in all four copies. Because the edited delta sits before the remaining events, the absolute tick of every later event moves by shift = new delta − 100: the second note's release moves with it, while notes 3 to 14 keep their durations and move their start ticks. Writing 0x64 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 14 notes were compared row by row.

4. Every figure recomputed from the bytes

No figure below is copied from a rendered page. Chunk lengths come from the file's own length fields, ticks from the single-byte delta, seconds from ticks / 960, 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; this file has no tempo event (tempos = 0), no time-signature event and no key-signature event, and none of the four edits changes that. Enumerating the note track reaches offset 169 at 7,627 ticks = 7.944792 s. The Program Change byte and the Note On / Note Off bytes were measured separately on this same file.

5. Fourteen notes, cell by cell

The independent parser returned 14 notes from the source. The last two columns are the readings after the 64 → 01 and 64 → 7F edits; both were checked against the formula before being written here. Duration ticks for notes 3–14 do not change, so only that column is shown for the short-duration copy:

The first note's duration equals the injected delta byte; the second note's duration is 936 plus the shift; from the third note on, start ticks are the source ticks plus the shift and durations are unchanged. All 56 cells in the last four columns were produced by the parser and independently recomputed from those three rules.

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

Six more one-byte edits change a chunk length field, the End-of-Track meta type, or the chunk magic instead of a delta. All six are still 169 B with 168 B unchanged. The readings show why "it opens" and "it says the same thing" differ:

Shortening or lengthening the declared track length by one byte leaves all 14 notes readable in this library, because it still finds the events inside the file. Setting that length byte to 00 declares an empty note track: the file still parses but reads 0 notes. Changing FF 2F 00 to another meta type keeps all 14 notes. Changing the chunk magic MTrk to XTrk makes the parse fail outright with Bad MIDI file. Expected 'MTrk'. 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 delta edits were therefore checked for note count, PPQ, a row-by-row note comparison, a byte-for-byte restore and the recomputed timeline, not merely for "it opened".

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

Open the 169 B source file in a hex editor, go to offset 53 and write one byte, save and re-open with a MIDI library that reports note durations in ticks. Chunk lengths need no editing: all ten variants are in-place single-byte writes, and writing 0x64 back restores the original exactly. The variant files themselves 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.

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, no DAW compatibility 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 and ten one-byte edits, measured on 11 November 2026 (UTC). General format facts, method notes, limits and disclaimers are excluded from the exclusive-material denominators above.