How to make a MIDI file: three routes, one file structure

The short answer: there are three ways to make a MIDI file — convert a recording, draw the notes by hand, or export from a score — and on this converter all three end up as the same kind of file. We ran the site’s own writer on the same four-note melody made each way. Every route produced the same 2-track Standard MIDI File — 89 bytes for the recording and hand-drawn versions, 87 bytes for the score version — with one tempo event, one 4/4 time-signature event, one channel, and four note-on/note-off pairs. There is no byte anywhere that records which route you took — no key signature, no track name, no lyric, no instrument name, no program change. Even a file with zero notes is still a valid 53-byte MIDI. So the route does not choose a format; it chooses the note list, and each route can supply a different part of that list. If what you have is audio, the direct path is the one on this page: load the file, pick mono or poly, type your BPM, and download the .mid — in your browser, with nothing uploaded. The rest of this page measures, byte by byte, what each of the three routes actually gains and loses, and the three cases where you should walk away and open something else instead.

What a MIDI file actually is before you choose a route

A MIDI file is not sound. It is a list of instructions: note 60 starts at tick 0, note 60 stops at tick 401, note 62 starts at tick 479, and so on, plus a few events that say how fast a tick is. That is the whole object. Which is why “how do I make one” is really two separate questions that get tangled together:

1. Where do the notes come from? A recording, your own hand, or a written score. This is the part that differs between routes.
2. What shape is the file written in? On this converter, that part is fixed. The writer takes a single array of { pitch, start, end, vel } objects and emits one fixed skeleton, regardless of how the array was filled.

Keep those two apart and the whole topic gets simpler. The three routes are three ways of answering question 1. Question 2 has one answer here, and it is measurable down to the byte. The note list itself is the real intermediate product — what you get before it becomes MIDI walks through the seven-column CSV that this same array also produces.

The one thing all three routes share: the file has no memory of its origin

We built the same four-note melody (C4, D4, E4, G4) three ways and parsed the resulting bytes back with a running-status-aware MIDI reader. Here is the complete event census. There are no other event types in any of the three files.

Read the bottom four rows. A score can say “C major, soprano, with these lyrics, on a piano”; this file cannot. The writer emits a fixed vocabulary of three meta types and two channel-message types, and nothing else. So the route is not metadata. If you need the file to remember a key, a part name, lyrics or an instrument, no route feeding this writer will give it to you — that has to be added afterwards in an editor. What is actually inside a MIDI file takes the same skeleton apart byte by byte; here the point is the comparison: three different origins, one identical envelope.

How identical? We diffed the recording-route file against the hand-drawn file. Both are 89 bytes, and exactly 7 bytes differ, at offsets 54, 58, 63, 67, 72, 76 and 81 — all inside the note events of track 2, all delta-time and pitch bytes. Nothing in the header, nothing in track 1, nothing in the event count. The file can tell you what notes arrived and when; it cannot tell you how they got there.

The 53-byte floor: what an empty file still contains

The clearest way to see the fixed skeleton is to make a MIDI file with no notes at all. This is the entire file, in hex:

4d546864 00000006 0001 0002 01e0        MThd, format 1, 2 tracks, 480 TPQ
4d54726b 00000013                        MTrk, 19 bytes
  00 ff51 03 07a120                       tempo = 500 000 us per beat (120 BPM)
  00 ff58 04 04021808                     time signature = 4/4
  00 ff2f 00                              end of track
4d54726b 00000004                        MTrk, 4 bytes
  00 ff2f 00                              end of track (empty note track)

That is 53 bytes of valid MIDI with zero notes. Track 1 always carries the tempo and time signature you get from the controls; track 2 is always the note track, even when it is empty. Growth is then close to linear in the note count, not the audio length:

Roughly 9 bytes per note, because each note costs a note-on and a note-off, each with a variable-length delta time. The practical consequence for all three routes is the same: a MIDI file is tiny, and its size tracks how many notes you made, not how long the recording was or how dense the score looked. How big an audio-to-MIDI file can get extends this with real song-length extrapolations.

Route 1: make a MIDI file from a recording (this converter)

This is the route that needs no notes from you at all — a recording goes in, a note list comes out. The analyser resamples to 22 050 Hz, reads a 2048-point FFT stepped 256 samples at a time (one frame every 11.609977 ms, 86.13 frames per second), searches 55–1800 Hz for a fundamental and keeps up to 6 spectral peaks per frame in polyphonic mode (peaks up to 4000 Hz). Velocity is derived from loudness, not chosen. We ran a clean four-note melody through it:

All four notes came back, but note the third and fourth columns: every onset sits exactly on a whole frame number, so the second note lands at tick 479 instead of the round 480 a drawn note would use. At 120 BPM one tick is 1.0417 ms, so the recording route is early by exactly one tick. This is not a bug in the file — it is the analysis grid showing through. A frame is 11.610 ms wide, which is 11.146 ticks at this tempo, so the detector simply cannot place an onset more finely than one frame. Where the note boundaries land goes deeper into that grid.

What this route can and cannot put into the file, measured on the same engine:

• It gains the performance. Timing, pitch and loudness come from the audio, so you do not have to know the notes. A clean C–G–Am–F progression of four triads returned 12 of 12 expected notes with onsets 7–12 ms from the bar lines.
• It loses expression. A 440→494 Hz glide came back as 3 stair-stepped notes (A4, A#4, B4) and 0 pitch-bend events. The writer has no bend message at all; what a glide becomes is a fixed part of this file shape.
• It loses voice separation. Two notes played together (C4 + G4) returned 6 note objects, all on the same channel, in the same 2 tracks. There is no per-instrument or per-voice split.
• It has density and range limits. An eight-note chord returned 17 note objects instead of 8, because 6 peaks per frame plus harmonic suppression fragment dense material. A C major scale returned 8 notes and 0 key-signature events — the pitches are there, the key is not.
• Velocity is inferred, not authored. Every note in the clean test came back at 113, derived from the measured loudness. If you want a deliberate accent, you add it later.

The practical workflow is short: open the converter, load your file, choose monophonic for a single line or polyphonic for chords (which mode misses what), set the shortest-note and sensitivity controls, type the BPM you want written, and download the .mid. If a note is missing, the order to fix it is format, then mode, then sensitivity, then shortest note.

Route 2: make a MIDI file from scratch, by drawing the notes

The second route skips the recording entirely. You open a piano roll, place each note where you want it, choose its velocity, and save as .mid. Here you control the note list directly — and that buys you exactness that a recording cannot deliver.

A drawn note lands on tick 480 exactly, versus tick 479 for the same note detected from audio. That one-tick gap is the whole difference between the two routes at the timing layer. But the file still quantises whatever you draw to the nearest tick, so even hand placement cannot beat 1.0417 ms resolution at 120 BPM; a note at 0.5037 s becomes 0.504167 s. And the hand route still inherits the same envelope: 2 tracks, 1 channel, 0 program changes, 0 key signatures, no lyrics. Drawing notes freely does not make the writer gain new event types.

What you gain is authorship, not format. You can set a velocity of exactly 100, place any pitch — including one below the analyser’s 55 Hz floor or above its 1800 Hz search ceiling — and make a note as short as you like without triggering a shortest-note gate. What you pay is that every single note is yours to supply. For a three-minute part that is hundreds of decisions; for the same three minutes of audio, the converter produces the list in one pass. A useful middle path is to convert the recording first, then fix the notes by hand — the five cleanup passes and why a converted file feels robotic both start from that exported list.

Route 3: make a MIDI file from a score, by exporting it

The third route starts from written music. If you already have notation, exporting it produces a note list with the score’s pitches and rhythmic durations — no listening, no detection, no ambiguity about which note was played. That is very different from pointing a converter at a PDF: this tool listens to audio, it does not read scores, so the score route belongs to a notation editor, not to this page.

Here is the interesting part. We fed a score-like note list — C major, two conceptual voices, four notes, a whole note under two half notes — through the same writer and parsed the result. It came back at 87 bytes with 2 MTrk chunks, 1 channel (channel 0), 0 key-signature events, 0 track names, 0 lyrics, 0 instrument names and 0 program changes. The two voices did not become two tracks: track 1 is always the tempo track, and track 2 holds every note from every voice together.

So the score route gives you the most musically informed note list of the three, and the file still throws away most of what makes a score a score. A key signature, separate staves, lyrics, instrument assignments and part names all live outside this writer’s vocabulary. One small detail makes the point: the time-signature event is always the bytes ff 58 04 04 02 18 08, i.e. 4/4, even if your score is in 3/4. Exporting a score into this file shape is a lossy step in a specific, measurable direction. If you want to go the other way and turn notes into notation, where the score comes from and how the notes land before the staff is drawn cover that boundary.

Which route should you take? Three honest lines

Most pages about making a MIDI file try to keep every reader. That is not useful, because two of the three jobs below genuinely cannot be done in a browser converter. Each line here is tied to a number measured on this engine, so you can check the boundary yourself.

That second and third line are the ones worth trusting the first line for. A page that says “you can make any MIDI file here” would be guessing; the event census above shows exactly where this writer stops. For the large middle case — you have audio, you want notes — the route is short and it runs in your browser: convert a file now.

How to make the file, in four steps

1. Choose your starting material. A recording is the only input this converter reads. Prefer a clean, single-line WAV where possible; how to prepare the file and what MP3 does and does not lose cover the input side. If the source is compressed or a different container, what the container changes explains why the codec, not the file extension, decides the notes.
2. Set the detection controls. Monophonic for one voice, polyphonic for chords; sensitivity and shortest-note decide how much quiet or brief material survives. The analyser’s 55 Hz floor and 181 Hz resolution line are properties of the window, not of your file, so raising sensitivity cannot recover a note below the floor.
3. Type the BPM. This is written to the file verbatim rather than detected, and it does not move the notes: the written tempo is exact to your input. If you would rather have the tempo read from the audio, the BPM finder measures it in the browser.
4. Download and check. Take the .mid and the .csv. Diff the note names, look at the piano roll rather than the note count, and fix anything the analysis grid or harmonic suppression distorted. What a chord identifier can name from audio and why the file records pitches, not an analyzed key explain the two most common surprises.

Everything above happens on your own machine: no upload, no account, no queue. Several files go one at a time, each from a clean state, and the result is discarded when you close the tab — so download before you leave. The privacy detail is in the privacy note.

Convert a file now — runs in your browser, nothing is uploaded.

Related guides

• MIDI converterWhat is actually inside a MIDI file, byte by byte
• Audio to notesThe 7-column note list that both downloads are built from
• Sheet music to MIDIWhy this tool listens to audio, not reads scores
• MIDI file sizeWhy the note count decides the size, not the audio length
• Clean up a converted MIDIThe 5 passes that turn a raw export into a usable part
• Pitch bend detectionWhat a glide becomes when the writer has no bend events
• Key & scale detectionWhy the file records pitches, not an analyzed key
• Mono vs polyWhat each detection mode does to the note list
• Audio into MIDIWhere the note boundaries land, and the two grids they follow
• MP3 to MIDIHow to diff two CSVs, and the 181 Hz resolution line