MIDI player: what playing a MIDI file back actually shows

The short answer: a MIDI player does not play a recording. It executes a list of note events — a pitch number, a start time, an end time and a velocity — and synthesizes sound from those. The instrument, the timbre, the words and the original waveform are not in the file at all. This site’s own writer makes that measurable: a four-note C4 D4 E4 G4 export is 89 bytes holding 4 note-on / 4 note-off events, one tempo, one 4/4 time signature, two end-of-track markers, and zero program-change, zero pitch-bend and zero text or lyric events, all on one channel. What you hear is the player’s choice of sound, not the recording’s. To find out what playback actually preserves, we rebuilt the exact Play-preview voice from this site’s app.js into a buffer and fed it back into the same detector. Four notes came back as the same four pitches, but velocity fell from 113 to 82.3, and a 0.20 s note that the detector had found was gone after one playback pass. So: use a player to check pitches, timing and whether a note exists at all — never to judge how the original sounded. The conversion and the preview both run entirely in your browser, with no upload and no account.

1. What the file actually hands the player

The most useful way to think about a MIDI player is as an interpreter of a very short instruction list. We built three exports from known note lists and parsed each byte back into an event census with a running-status-aware reader, so nothing below is inferred from a description of the format:

Every file is format 1 with two tracks and 480 ticks per quarter note. Even the zero-note export is a valid 53-byte Standard MIDI File: a player opening it will simply play silence. Notice what is absent from all three rows. There is no 0xC0 program-change, so no instrument is specified; no 0xE0 pitch-bend, so no glide or vibrato; and no 0x01 text, 0x05 lyric, 0x03 track-name or 0x59 key-signature event, so no words and no named key. A previous byte-level check on a two-note export found exactly 71 bytes and only those three meta types.

That absence is the whole answer to “why does it sound different in every player?”. The player is not failing to read the instrument; there is no instrument byte to read. The same 89 bytes played through a piano patch, a guitar patch or a plain oscillator give three different sounds from identical data. What is actually inside a MIDI file walks through the rest of the byte layout, and how big an audio-to-MIDI file can get explains why the size depends on note count rather than audio length.

2. There are two playback clocks, and they do not agree

This is the part most people miss, and it is specific to this converter. The on-page Play preview schedules one oscillator per detected note at the note’s raw analysis time. The .mid you download instead writes times as integer ticks. Both describe the same four notes, but they run on different grids:

• Analysis grid: a 2048-sample FFT window stepped 256 samples at 22 050 Hz, so one frame is 11.609977 ms. The four detected onsets were 0, 0.5108, 1.0333 and 1.5557 s — the second is 43.997 frames, essentially frame 44.
• MIDI grid: round(start × 480 × bpm / 60) ticks, with one tick worth 1.0417 ms at 120 BPM. The same 0.5108 s onset becomes tick 490, which plays back at 0.510417 s.

We computed the deviation for all four onsets at six tempos. It is small, but it is real, and it changes with the BPM you typed even though the audible note positions do not:

The tempo itself changes only the 0xFF 51 event and the tick numbers; the ticks and the tempo scale together, so the note still lands at the same moment. That is the same result as the dedicated measurement in how accurate the tempo a converter writes is. If you want a tempo and key read from the audio rather than typed in, the BPM finder is the separate page that does that. The audio to notes page compares the seven-column note list with the tick-rounded file side by side.

3. A player can address 128 pitches; this file can only use 75

A Standard MIDI File note number runs from 0 to 127, which spans 8.176 Hz to 12 543.854 Hz. The pitch detector behind this converter searches only 55–1800 Hz in monophonic mode and keeps polyphonic spectral peaks up to 4000 Hz. Converting those three boundaries into note numbers gives a hard ceiling on what any player will ever be asked to play from a file made here:

So the widest possible file from this converter occupies note numbers 33–107, or 75 of the 128 a player understands — 58.6% of its range. In monophonic mode it is 33–93, just 61 note numbers. A player is not hiding your sub-bass or your top octave: those notes were never written. The low end is arithmetic rather than a setting, as the bass line extraction and drum transcription limits pages show.

4. The round trip: what one pass of playback actually preserves

This is the measurement that separates “playing a file” from “hearing a recording”. The site’s Play button builds one triangle oscillator per detected note with a 12 ms linear attack, a gain ceiling of (velocity / 127) × 0.28, an exponential release down to a fixed 0.0001, and an 80 ms lead-in. We re-implemented that voice exactly, rendered the four known note lists into samples, and ran those samples back through the same dsp.js detector. The site itself never records its preview; this buffer exists only for the measurement.

Three things are worth reading out of that table. First, pitch survives: the clean melody came back as the same four note numbers. Second, level does not: velocity 113 became a mean of 82.3, because the preview plays at a fixed quiet ceiling and then decays, so the second conversion hears a quieter signal. Third, the player faithfully reproduces the detector’s mistakes. The triad’s first pass already contained a spurious G5 (note 79) and a duplicate set of the three chord tones; those events are in the file, so they are what gets played. A player has no way to know which notes were real.

The zero rows matter too. A 55 Hz tone that produced six low note objects on the first pass produced none on the second, and the eight fast notes vanished entirely. The cause is the preview’s own envelope, not the MIDI format. With a ceiling of 0.2491 and a release to 0.0001 (about −80 dBFS), the level at the midpoint of a note is already far below its own peak:

By halfway through a 0.14 s note the voice is 30.78 dB down. That is why a preview is a note-and-timing check, not an audition. MIDI to WAV measures the same voice’s harmonic content and fixed −11.06 dBFS ceiling, and explains why it is wired to the speakers rather than to a file.

5. The shortest note that survives a playback pass

To pin the short-note boundary down rather than describe it, we swept one C4 tone from 0.05 s to 1.00 s and, for each length, compared two renderings of the same detected note: the site’s real decaying preview voice, and a control voice that simply holds its level flat with the same 12 ms attack. Both were converted a second time.

The 0.05–0.14 s rows are the detector’s own floor: those notes never appeared in the first place, so no player can bring them back. The interesting row is 0.20 s. One note was detected, a flat-sustain player returned one note, but this site’s preview returned zero — the exponential release erased a note the detector had already found. The shortest length that survived the real preview in this sweep is 0.30 s. At 1.00 s the first conversion split one sustained tone into three objects and the preview round trip kept two, while the flat control kept all three.

This is a measured property of this preview’s envelope, not of MIDI players in general. A piano patch in a sequencer sustains differently and would give a different second pass. The general rule stands regardless: whatever the player adds at playback is new information, and a conversion of that playback is a conversion of the player, not of your recording. If short or missing notes are your actual problem, start with the four-step order for fixing dropped notes and the mono versus poly decision instead of judging the preview.

6. Three decisions, and when to walk away

Most searches for a MIDI player are really one of three different jobs. Each line below carries one number from the measurements above, so you can tell which job you have.

One honest boundary: you cannot drop a .mid into this converter to hear it. The input path hands the file to the browser’s audio decoder, which needs samples; a MIDI file has none, so it fails to decode. If you already hold a .mid and want to listen, that is the dedicated-player case above. If you hold a recording and want notes, you are in the right place — MP3 to MIDI and how to make a MIDI file cover the other direction.

7. What playback can never show you

The list below is short because the reason is always the same: the event is not in the file. Each item is a byte-level fact about this writer, not a limitation of any particular player.

• Instrument or timbre — 0 program-change events; a player must pick a voice. Inside a MIDI file.
• Glides, bends and vibrato — 0 pitch-bend events; a slide is written as stepped notes. Guitar to MIDI, Pitch bend detection.
• Lyrics, syllables or any text — no 0x01, 0x05, 0x03 or 0x06 meta events; a two-note export starting at zero measures just 71 bytes with only tempo, time signature and end-of-track. Vocal to MIDI and lyrics.
• A named key or scale — 0 key-signature events; the file holds pitch classes, not an analyzed key. Does audio to MIDI tell you the key.
• The original waveform — 89 bytes for four notes, 53 bytes for none; there are no samples to play. Song to MIDI, Who owns the converted MIDI.
• Anything the detector already lost — the 55 Hz floor, the 4000 Hz polyphonic ceiling, the six-peak-per-frame cap and the 11.610 ms grid are decided before any player sees the file. Chord identifier, Drum transcription limits.