MP3 to MIDI: Why a Repeated Note Dies at the Same Tick
A converted .mid file has no duration field and no way to state that two notes begin together. Both facts are written the same way: two events carrying a delta-time of zero, read in file order. That one rule explains the most common complaint about transcribed MIDI, the repeated note that never sounds.
Short answer
- Length is a gap, not a value. A note lasts from its Note On to its Note Off.
- Zero is a time. A delta-time of zero says no time has passed since the previous event.
- Order decides. Events sharing a tick are processed in the order they sit in the file.
- A release written second kills the repeat. Swap the pair; do not lengthen the note.
A note has no length field
The specification defines an MTrk event as a delta-time followed by an event, and the delta-time is "the amount of time before the following event". There is no slot for how long a note lasts. Length is arithmetic: the ticks between a Note On and the Note Off that releases it. The specification's own example file sets division to 96 and tempo to 500,000 microseconds per quarter-note, so one tick is 500,000 divided by 96, about 5,208 microseconds, or 5.2 milliseconds.
Zero means now
Delta-times are always present, and "if two events occur simultaneously, a delta-time of zero is used". Zero is not a missing value or an abbreviation; it states that no time has passed. A four-note chord is four Note On events, three carrying zero, not one object with four keys.
The example file puts five events on one tick
The format 0 example ends in a cluster. C3 and C4 start at tick 0 with a zero between them, G4 at 96, E5 at 192, then a single delta of 192 reaches tick 384, where four Note Offs follow with three zeros between them and End of Track with one more. Five events, one tick. The durations that fall out are 384 ticks for the two lower notes (2.0 seconds), 288 for G4 (1.5 seconds) and 192 for E5 (1.0 second).
Why order decides a repeat
The file is a stream, so events at one tick are handled in the order stored; nothing marks them as concurrent. A Note Off names a key and a channel, not a note instance: sixteen channels times 128 keys gives 2,048 addresses, and no field says which of two overlapping notes is being released. When a pitch repeats on the same tick, the release has to come first. Written the other way, the release ends the note that just began: the repeat is silent, though the piano roll shows two notes.
The release has two spellings
Note Off is status 1000nnnn. The second spelling is a Note On with velocity zero, which the specification's own format 1 example uses: the E5 release that appears as 80 4C 40 in the format 0 file appears as 4C 00 under running status, labelled "note on, vel=0". A checker that scans only for 0x8n reports notes that never end. End of Track, which is not optional, fixes "an exact ending point", so a release written after it lies outside the track's stated length.
What to check in a converted file
Sort the events by tick and look at three things. A Note On and its Note Off with no time between them: a note with no measurable length. A release that follows an attack on the same key and channel at the same tick: swap the two. Any event after End of Track: a reader will not count it. songscription calls converted output "a first draft of the notes, not a finished part" with durations that overlap or run too long; the file shows why the fix is often a reorder rather than a resize.