Stuck MIDI Notes: Does the Note-Off Match?

If a MIDI note seems stuck, check whether its release event has the same channel and key number as its note-on. A note-off somewhere in the file is not enough: it may refer to another note. Also look for note-on messages with velocity zero, which can serve as note-offs rather than new silent notes.

This is one narrow file-level check, not a diagnosis of every hanging sound. Sustain, overlapping repeated notes, routing, device behavior and instrument release tails need separate checks. Our four downloadable examples isolate channel-and-key matching so you can see exactly what the event list proves.

Four files with the same note-on

We constructed four original Standard MIDI Files on October 26, 2026. Each starts key 60 on channel 1 at tick 0 with velocity 80. At tick 480 it contains a release-shaped message; its channel, key or message form varies. The files use format 0, one track, 480 ticks per quarter note and a 500,000-microsecond tempo event.

In the wrong-channel case, the key number is right but the release addresses channel 2. In the wrong-key case, the channel is right but the release addresses key 61. Both leave the original channel-1/key-60 pair unmatched in the parser. The ordinary note-off and zero-velocity note-on both remove that pair.

Two examples intentionally contain an unmatched note-on. They are diagnostic fixtures, not finished musical clips. Prefer inspecting their event lists; if you audition them, stop/reset the receiving player afterward. Some players may automatically terminate notes at end-of-track or stop, so hearing a sound stop does not prove the file contained a matching release.

Read three fields together

The MIDI Association's message summary identifies the channel in the status byte and the key number in Note On and Note Off data. Compare message type, channel and key, rather than looking only at a piano-roll rectangle or searching for any “off” label.

90 3C 50   note-on: channel 1, key 60, velocity 80
80 3C 00   note-off: channel 1, key 60
81 3C 00   note-off: channel 2, key 60
80 3D 00   note-off: channel 1, key 61

These are hexadecimal message bytes without the MIDI file's delta-time or track wrappers. Hex 3C is decimal 60; hex 3D is decimal 61. The low status nibble 0 denotes human channel 1, while 1 denotes channel 2. A similarly named editor track is not evidence of either channel; the separate track-versus-channel comparison demonstrates that distinction.

Why a zero-velocity note-on belongs in the release check

A filter that counts only messages beginning with 8 may overlook valid releases. Oracle's MIDI channel documentation explicitly treats a zero-velocity note-on as note-off behavior. JUCE's MIDI message interface likewise includes note-on velocity zero in its default note-off classification.

In the fourth fixture, 90 3C 00 therefore releases the same channel/key pair as 80 3C 00 in the first fixture. Do not “fix” that zero to a small positive velocity merely to make a list look consistent: doing so changes the event's meaning in this model and can create another note-on instead of releasing the old one.

A matching release is only the first branch

The experiment does not render audio, exercise a DAW, measure USB or cable loss, or diagnose any controller. It tracks one active key with no pedal messages and no repeated overlapping note-ons. It reports unmatched events, not an audible duration or a claim that every instrument will hang.

If the release matches but the sound continues, inspect sustain and the instrument's release behavior. Musio's own troubleshooting guide includes checking CC64 and its MIDI reset control. Those are product-specific instructions, not something we measured here. Our separate sustain-pedal files isolate the case where key release arrives while the pedal remains held.

If the file looks correct but playback differs, compare the events at the receiver with the file. A DAW's output channel setting, a transpose/filter operation, or a route switch can change what reaches the destination. A file-only parser cannot identify where a live message was dropped. Keep source and received traces separate rather than blaming a cable from this table alone.

A short troubleshooting record

1. Preserve the original. Inspect a copy and a short passage containing one troublesome note.
2. Record the note-on identity. Write down port if known, channel, key number and event time.
3. Find its matching release. Include ordinary note-off and zero-velocity note-on. Compare channel and key, not just a count of on/off events.
4. Check the other branch. If that pair matches, inspect pedal data, overlapping repeats, receiver routing and instrument behavior. Avoid adding random note-offs across every channel as a substitute for finding the mismatch.
5. Retest the same passage. Use the player's documented stop/reset control to clear an existing held state, then compare the original and repaired copy.

For a MIDI draft made from audio, first compare detected pitches and timing with the recording using the transcription checklist. Repairing a release mismatch will not restore a note that was never detected.

Reproduce the four-file audit

Download experiment.py into an empty folder and run python experiment.py with Python 3. It creates all four MIDI files, the event/state trace and the result CSV. Assertions check unmatched counts of 0, 1, 1 and 0, and confirm that both mismatched releases leave channel 1/key 60 active.

The parser supports only the explicit note statuses and meta events generated here. It is not a general MIDI importer and does not implement running status, pedal state, repeated-note voice allocation or sound synthesis. An independently reproduced byte-identical result establishes this controlled comparison, not a universal repair for every stuck-note report.