The short answer: an audio-to-MIDI file is so small you will never think about it. This converter writes a Standard MIDI File (format 1) that records note events — pitch, start time, end time, velocity — not sound, so a typical 3-minute song comes out around 12 KB. The size is set by how many notes the detector finds, not by the audio's length, bitrate, or container. A dense 10-minute track stays under about 50 KB. The MIDI is measured in kilobytes; the audio it came from is measured in megabytes. We measured the exact numbers below using the same writer this site ships, and the rule holds: more notes, bigger file — longer audio, higher bitrate, or a "better" format changes nothing.
Why a MIDI file is small in the first place
A .mid is not a recording. It is a list of instructions: "note 60 (C4) on at tick 0, off at tick 240, at velocity 100." The converter's own writer produces a format-1 file with two tracks — one tempo track (tempo + time signature) and one note track — running at a 480-ticks-per-quarter-note division. None of that carries a single sample of audio. A three-note chord and a three-hour drone both describe their notes with a handful of numbers per note, so the file never balloons the way an audio container would.
This is the single fact that makes every size question easy: the output grows with the number of note events, and only with that. Audio duration, bitrate, sample rate, MP3 vs WAV, stereo vs mono — none of them touch the byte count, because none of them are stored.
What we actually measured
Rather than quote a textbook constant, we ran this site's real writer (midi.js) on note lists of different densities and read back the byte length of the file it produced. The three columns below are real outputs — sparse (one note every half second), chord (four-note stacks every quarter second), and busy (three-note changes every 120 ms), which is the kind of density a dense polyphonic song produces.
| Notes | Spacing | Approx. audio | File size | Bytes / note |
|---|---|---|---|---|
| 50 | sparse (0.5 s) | ~25 s | 503 B | 10.06 |
| 200 | sparse (0.5 s) | ~100 s | 1 853 B | 9.27 |
| 500 | sparse (0.5 s) | ~250 s | 4 553 B | 9.11 |
| 200 | chord (0.25 s) | ~12 s | 1 703 B | 8.52 |
| 800 | chord (0.25 s) | ~50 s | 6 653 B | 8.32 |
| 2 000 | chord (0.25 s) | ~125 s | 16 553 B | 8.28 |
| 300 | busy (0.12 s) | ~12 s | 2 453 B | 8.18 |
| 1 000 | busy (0.12 s) | ~40 s | 8 053 B | 8.05 |
| 3 000 | busy (0.12 s) | ~120 s | 24 053 B | 8.02 |
Two things to read off that table. First, the bytes-per-note figure collapses to a narrow band: about 8 bytes per note when notes are close together, about 10 when they are far apart. Second, the file is still only tens of kilobytes even at three thousand notes — that is a busy, several-minute track, and it is smaller than a single thumbnail.
Where the bytes come from
The file splits cleanly into a fixed shell and a per-note cost, so you can predict the size of any result without running it:
- Fixed shell: roughly 40 bytes. This is the format-1 wrapper — the
MThdheader, plus a small tempo track that holds the tempo and time-signature meta events and the track-end marker. It is the same for every file, whether the song is two seconds or two hours. - Per note: 8–10 bytes. Each note becomes two events, a note-on and a note-off, and each event is a 3-byte message (status + pitch + velocity) preceded by a variable-length time gap. When the gap to the next event is short it fits in one byte, so the note costs about 8 bytes; when the gap is long the gap needs two bytes, so it costs about 10. That is the entire reason the per-note number drifts between 8 and 10 in the table above.
So the size of any conversion is roughly 40 + (notes × 8 to 10) bytes. A 1 000-note export is about 8 KB; a 5 000-note export about 40 KB. Nothing else enters the formula.
What actually decides the note count
The only lever on file size is how many notes the detector emits, and that is bounded by the analysis grid this converter uses: it reads the audio in frames that are 11.610 ms apart (about 86.13 frames per second), and at each frame it keeps up to 6 spectral peaks. That gives an absolute theoretical ceiling of around 516 note-ons per second — a wall of six simultaneous tones changing every frame, which is not music. Real recordings land far below that: a busy pop or game-track arrangement tends to sit around 8–10 notes per second, and a sparse solo line is a fraction of that.
Plugging the realistic rates into the per-note cost gives the song-length numbers a user actually cares about. These are also real writer outputs, not estimates:
| Audio length | Note density | Notes | File size |
|---|---|---|---|
| 60 s | 8 / s | 480 | 4 013 B (3.92 KB) |
| 3 min | 8 / s | 1 440 | 11 933 B (11.65 KB) |
| 5 min | 10 / s | 3 000 | 24 803 B (24.22 KB) |
| 10 min | 10 / s | 6 000 | 49 553 B (48.39 KB) |
Read the last row as the practical worst case for normal music: ten minutes of dense material, under 50 KB. For the contrast that makes the point — the audio that produced it is typically 3–6 MB as an MP3 and tens of MB as a WAV, so the MIDI is roughly one hundred to one thousand times smaller.
Is there any hard limit?
Not one you will reach. The format and the writer both leave the ceiling effectively unbounded for real use:
- No note-count cutoff. The writer does not truncate the track at any number of notes. If the detector finds more, the file just gets longer at the ~8–10 bytes-per-note rate above.
- The container ceiling is astronomical. A Standard MIDI track's length field is a 32-bit integer, so a single track could in theory describe a file of about 4 GB. You would run out of sensible musical material long before that.
- One file per conversion. Each conversion you run here is its own
.mid— there is no accumulated project file that grows across runs — so the size question is always "this one song," never "my whole library." - The real constraint is memory, not disk. Because the conversion runs entirely in your browser, the whole audio file is decoded into memory before analysis. On a phone that is the thing that caps how long a clip you can feed in (a very long file may fail to decode on a low-RAM device), not the size of the MIDI it produces. See Can you do audio to MIDI on iPhone or Android for the measured decode cost.
Why the size is good news
- Email it, don't upload it. A 12 KB file goes anywhere a text message goes. You can send a conversion to a collaborator without a cloud link.
- Edits are instant. Opening, quantizing, or deleting notes in a DAW touches a few thousand bytes, so even a long session loads and saves in a blink.
- Storage is a non-issue. A thousand conversions take less room than one MP3. You can keep every draft without thinking about it.
- The raw export still needs cleanup. Small does not mean finished — How to clean up a converted MIDI before you use it walks the passes (ghost-note deletion, velocity, quantization, low-end correction) that turn the tiny raw file into a usable part.
The companion question — how many notes the converter can hold at once in a single frame — is answered separately in Audio to MIDI software: how many notes it can hold at once, and the difference between mono and poly detection (which changes note count, and therefore size) is in Mono vs poly: what each detection mode misses.
Questions
Does a longer song make a bigger MIDI file?
Only indirectly. A longer song usually contains more notes, and more notes mean more bytes — but a long, quiet song with few notes stays small, and a short, dense one can be larger per second. Length sets the opportunity for notes; the note count sets the bytes.
Will converting from WAV instead of MP3 give me a smaller file?
No. The container is not stored in the MIDI at all, so the source format never enters the byte count. WAV and MP3 of the same take produce the same notes and therefore the same file size (within the note-detection noise described on the MP3 vs WAV page).
Does a higher bitrate or sample rate shrink the MIDI?
No, for the same reason: none of those properties are written into the file. They can change which notes are detected, and thus the note count, but they never change the bytes-per-note cost.
Can the file get too big to open?
In practice, no. Even the dense 10-minute case above is under 50 KB, and every DAW and sequencer opens files like that instantly. The only way to produce something awkward is to feed in audio so long it cannot be decoded in your device's memory — and that fails at the decode step, before any oversized MIDI exists.
Why is my downloaded file sometimes a .mid and sometimes I only see notes?
This converter gives you two views of the same data: the binary .mid for software, and a CSV of the note list for reading. They are the same dozen-or-so numbers per note, just in different formats — see What is actually inside a MIDI file for the byte-level breakdown of the binary.
Convert a file now — runs in your browser, nothing is uploaded, and the result is a few kilobytes you own.
Related guides
- MIDI converterWhat is actually inside a MIDI file, byte by byte
- Audio to MIDI softwareHow many notes it can hold at once
- Mono vs polyWhat each detection mode misses
- Batch converting several filesWhy there is no folder-drop button
- Clean up a converted MIDIThe passes that turn a raw export into a usable part
- iPhone or AndroidCan you convert on a phone, and what it costs