MIDI converter: what is actually inside a MIDI file

The short answer: there is no audio in it. A Standard MIDI file is a list of instructions, and the file this converter writes contains exactly four kinds of instruction: a tempo, a time signature, note-on messages (0x90) and note-off messages (0x80). It is written as format 1 with two tracks and a time resolution of 480 ticks per quarter note. Track 1 holds only the tempo and the time signature — 19 bytes of data, identical on every export except for the tempo number. Track 2 holds the notes: one note-on and one note-off per note, each preceded by a delta time counted in ticks. A three-note export is 80 bytes in total, of which 41 bytes are fixed overhead that has nothing to do with your music. Every byte value quoted on this page was produced by running this site's own MIDI writer, not read off a specification. This is the same audio to MIDI converter online that runs in your browser, so the file it writes is one you can open and check yourself.

The whole file, byte by byte

Here is a complete, real file: three notes (C4, E4, G4), each half a second long, exported at 120 BPM. It is 80 bytes. This is the actual output of the writer in this site's code.

4D 54 68 64 00 00 00 06 00 01 00 02 01 E0
4D 54 72 6B 00 00 00 13 00 FF 51 03 07 A1 20 00 FF 58 04 04 02 18 08 00 FF 2F 00
4D 54 72 6B 00 00 00 1F 00 90 3C 5A 83 60 90 40 50 00 80 3C 5A 83 60 90 43 46
00 80 40 50 83 60 80 43 46 00 FF 2F 00

The first four bytes are the ASCII text MThd; the two track chunks begin with MTrk. Everything after that is numbers. Offsets below are counted from the start of the file.

Format 1 rather than format 0 matters for one practical reason: your DAW will import the file as a tempo track plus a separate note track, so you can delete or replace the tempo map without touching a single note. The 480 division is a resolution choice, not a tempo choice — it says one quarter note is subdivided into 480 steps, and it is why a 1/16 grid lands on a round number of ticks regardless of tempo, as shown further down.

Track 1: tempo and time signature, then stop

Track 1 is 19 bytes of data, wrapped in an 8-byte chunk header, for 27 bytes total. It holds three events and no notes: it deliberately writes no key-signature event — the file records pitches, not an analyzed key. Does audio to MIDI tell you the key? covers what the note list does and does not give you.

The tempo is the one number in the header area that changes with your settings. It is stored as microseconds per beat, computed as round(60 000 000 / bpm), so the relationship is inverse and the byte values are not obvious:

Two consequences follow from this track being written once at tick 0. There is no tempo change anywhere in the file, so if the original recording speeds up, drags, or was played to a click that itself drifted, the MIDI does not follow it — the notes keep marching at one fixed tempo and slide out of place. And the time signature is always written as 4/4: a waltz exports as 4/4 too, because the writer has no meter detection and does not guess.

Track 2: one pair of messages per note

Every note becomes two events, and each event is three bytes: a status byte, a pitch, and a velocity. 0x90 is note-on, 0x80 is note-off, and both use channel 0, so the whole file sits on one MIDI channel. Before each event sits a delta time — how many ticks to wait since the previous event.

Notice the ordering at each boundary. At tick 480 the E4 note-on is written before the C4 note-off, even though they fall on the same tick. That ordering is deliberate in the writer: within one tick, note-ons always sort ahead of note-offs. This is what stops adjacent notes from leaving a one-tick hole between them, and it means a legato line — where one note ends exactly where the next begins — exports as a clean handoff rather than a gap.

The other rule worth knowing is at the opposite extreme. If a note's end rounds to the same tick as its start, the writer pushes the end one tick later rather than emitting a zero-length note. So the shortest note the file can represent is 1 tick: 1.0417 ms at 120 BPM, 2.0833 ms at 60 BPM, 0.5208 ms at 240 BPM. A note that short is inaudible in practice; it exists so that no reader ever sees a malformed event.

What a tick is worth

Timing is integer ticks, and the conversion from seconds is round(seconds × 480 × bpm / 60). Because 480 is multiplied by the tempo, the value of one tick depends entirely on the BPM you set — and setting a faster tempo does not speed your music up, it only gives the file a finer ruler.

The rounding error column is the honest limit of the file's timing: no note can be placed more precisely than half a tick. At 120 BPM that is half a millisecond, which is far below anything you can hear, and well below the 11.610 ms analysis frame the pitches themselves are measured on.

Delta times are variable length

A delta time is stored as a variable-length quantity: seven usable bits per byte, with the top bit set on every byte except the last. So the cost of waiting depends on how long the wait is.

This is why the size of a file is not simply a fixed number of bytes per note. In the example above, each note costs 9 bytes — 6 bytes of message data plus 3 bytes of delta. The general rule is 8 to 14 bytes per note: 6 bytes that every note must carry, plus 2 to 8 bytes of timing.

Quantised and unquantised timing land on different grids

The "Quantise" checkbox decides whether note times are snapped before they ever reach the writer. When it is on, each end of each note is moved to the nearest step of (60 / bpm) × (4 / grid) seconds. Converted into ticks, the bpm cancels out entirely and every grid setting resolves to a fixed number of ticks:

With quantise off, nothing is snapped and note times keep the resolution the analysis produced: multiples of one 11.610 ms frame. In ticks that is an awkward number — 11.146 ticks at 120 BPM, 8.359 at 90 BPM, 13.003 at 140 BPM — so an unquantised export is full of note starts that sit slightly off the round tick values a notation program expects. If you are exporting to print or to edit on a grid, turn quantise on; if you are measuring how accurate the conversion was, leave it off, because snapping hides timing error rather than removing it.

What the file deliberately does not contain

What is missing is as useful to know as what is present, because it explains most of the "why does it open like that" surprises:

• No instrument. There is no program-change message anywhere in the file, so whatever plays it falls back to the General MIDI default of program 0. A conversion of a guitar or a vocal still opens as a piano sound. The notes are right; the patch was never specified.
• No channel split. All notes use status 0x90 / 0x80, which is channel 1. Two simultaneous parts are not separated onto two channels — they are interleaved on one.
• No expression. No pitch bend, no aftertouch, no modulation, no CC7 or CC11 volume. A slide, a bend or a crescendo inside a held note is simply absent from the file.
• No names or text. No track-name event, no copyright or lyric meta events. Files open as "Track 1" and "Track 2".
• No tempo changes. One tempo, written once, at tick 0.
• No audio, and no reference to your audio. Nothing links the file back to the recording it came from.

The note-off messages are also worth a note: they carry the same velocity byte as the note-on. That is legal — the standard defines the third byte of a note-off as a velocity — but sequencers generally treat it as 64 or ignore it, so nothing in your playback depends on it.

That last point is worth following further: because the file carries no record of how its notes were produced, the same 2-track, 1-channel envelope comes out whether the notes were detected from a recording, drawn by hand, or exported from a score. We built the same four-note melody all three ways and compared the bytes in How to make a MIDI file: three routes, one file structure — including the 53-byte empty file and the one-tick difference between a recorded onset and a drawn one.

Because the file leaves out so much on purpose, most people open it once and then tidy it up before using it — How to clean up a converted MIDI before you use it walks the three passes (delete ghost notes, fix velocity, decide on quantize) plus the low-end and metadata fixes.

How big these files get

The fixed overhead is 41 bytes before a single note is written: the 14-byte header plus the 27-byte tempo track. An export with zero notes is 53 bytes. After that, size scales linearly with the note count. Measured on real output at 120 BPM with notes a quarter-second apart:

A thousand-note conversion — roughly a few minutes of dense material — is under 9 KB. That is the whole pitch of the format: a MIDI file is a list of numbers, which is why it is trivial to email, trivial to edit, and completely silent on its own. For the full size picture — how the ~40-byte shell and the ~8–10 bytes-per-note cost add up, and how long a song can get before the file notices — see How big can an audio-to-MIDI file get.

How to look inside your own file

You do not need any special software to confirm any of the above on the file you just downloaded. Open a terminal in the folder holding the .mid file and print the first bytes as hex:

python -c "print(open('yourfile.mid','rb').read()[:14].hex(' ').upper())"

What to check in that output:

1. Bytes 0–3 are 4D 54 68 64. If they are not, the file is not a Standard MIDI file.
2. Bytes 8–9 are 00 01 and 10–11 are 00 02 — format 1, two tracks.
3. Bytes 12–13 give the resolution. 01 E0 is 480 ticks per quarter note.
4. Next comes 4D 54 72 6B and a 4-byte length. 00 00 00 13 means the tempo track holds 19 bytes of data, and inside it you can read FF 51 03 followed by your tempo in microseconds — divide 60 000 000 by that number to recover the BPM you set.
5. The second MTrk is the note track. Count the 90 bytes in it and you have the note count; every one of them should be matched later by an 80.

On Windows, Format-Hex yourfile.mid in PowerShell does the same thing without installing anything.

Convert a file and open the result in a hex viewer alongside these numbers — the Audio to MIDI Converter writes the whole MIDI file inside your browser, so you can export, inspect and re-export with the tempo changed in under a minute.

Related guides

• MP3 to MIDIWhy MP3 loses notes that WAV keeps
• WAV to MIDIHow to prepare the file before you convert
• Voice to MIDIWhat a single-line converter can follow
• Audio to MIDI converterHow accurate a conversion really is
• Audio to MIDI softwareHow many notes it can hold at once
• Clean up a converted MIDIThe 5 passes that turn a raw export into a usable part
• MIDI to sheet musicWhat this tool covers, and where the score comes from
• Sheet music to MIDIWhy this tool listens to audio, not reads scores
• Audio to sheet musicWhere a chord's notes actually land, measured

Questions people actually ask

Does this tool give me the notes, or just a MIDI file?

Both — and "MIDI to notes" is just plain language for the same output. The converter's result is a list of pitches and the times they start and stop, and it is written out in two forms you can use directly: a .mid file your notation or DAW software can open, and a downloadable .csv where every row is one note's name, start, end, and velocity. If what you typed into the search box was "MIDI to notes," the CSV is the most direct view of those notes — open it in any spreadsheet and the pitch-and-time list is already there.

The "MIDI to notes" phrasing shows up because people expect a converter to hand them the actual notes rather than a binary file. This one does both: the binary is the portable format for software, and the CSV is the human-readable answer. Either way, the underlying data is the same dozen-or-so numbers per note that the converter actually measured, and nothing about the input container changes that list once the audio has been decoded to raw samples. For a measured comparison of the two outputs -- seven CSV columns against 480-tick MIDI events, and where their timing disagrees -- see Audio to Notes: what you get before it becomes MIDI.

Does the MIDI file include the tempo and the musical key of my song?

It writes the tempo and a 4/4 time signature, but it leaves out the musical key. Every file this converter produces carries exactly one tempo event and one time-signature event — always 4/4 — stored in the first track next to the notes, with the timing grid set to 480 ticks per quarter note (at 120 BPM that is 1.042 milliseconds per tick, so the rhythm lines up to the sixteenth note without any editing on your side). What never gets written is a key signature: a byte-level scan of the exported file finds zero key-signature events, and zero clef, slur, or rest markers as well. That is deliberate. The converter measures pitch and timing, not harmony, so it has no way to declare a key, and a notation app such as MuseScore or Dorico works that out from the notes you hand it. If you want a specific key signature on the score, you add it in that app — nothing is missing from the MIDI itself, the information was simply never part of what this tool measures.