MIDI vs MusicXML

Neither format is "better." MIDI was designed in 1983 to send performance data to synthesisers in real time over a serial cable — every byte had to be small and fast. MusicXML was designed in the 2000s to exchange scores between notation programs like MuseScore, Sibelius and Finale — readability and completeness mattered more than size. The 23.5× size ratio is the direct result of those different goals.

1. The same 14 notes in both formats

Both files describe the same passage: eight one-second notes from C4 up to C5, played on acoustic grand piano. The MIDI file (169 B) is the actual downloaded output of running the test WAV through this site's browser converter on 24 October 2026. The MusicXML file (3,964 B) was written by hand from an independent parse of that same MIDI — not generated by any converter, not a textbook example. An independent parse with @tonejs/midi 2.0.28 on 7 November 2026 found 14 notes in the MIDI: the eight intended pitches, plus six short octave-ghost notes that are transcription artefacts (see clean up MIDI).

Here is how the first two notes — C4 and its ghost C5 — appear in each format:

Read the MIDI column carefully: 90 3C 5B is three bytes that encode note on, channel 0, pitch 60, velocity 91. That is the entire note-on event. MusicXML needs opening tags, closing tags, text content and whitespace to say the same thing. The trade-off: MusicXML also declares a clef, a key signature, a time signature and a measure structure that MIDI simply does not carry.

2. All 14 notes, side by side

Each row below is one note, parsed independently from the 169-byte MIDI on 7 November 2026. The MIDI column shows the raw values the synthesiser receives; the MusicXML column shows the XML elements that a notation program reads. Both describe the same 14 notes in the same order.

The odd-numbered rows are the eight intended notes (C4 through C5); the even-numbered rows are the six octave ghosts. Both formats carry all 14 — neither format knows which notes are "real" and which are artefacts. The MIDI stores each note's velocity as a single byte (32–98 here, out of 127); MusicXML carries the same number in a <velocity> element, though many notation programs ignore it entirely.

The seconds column uses the formula ticks × 60 / (120 × 480) = ticks / 960. The MIDI file has no tempo event, so 120 BPM is a player default, not a stored value. MusicXML's <divisions> element sets the same 480 ticks-per-quarter resolution, but the tempo comes from the time signature and the notation context, not from an explicit BPM field.

3. Three one-variable changes, in both formats

Here is something you can check. We took the same 14-note passage and changed one musical variable at a time. For each change, the table shows exactly what byte or element differs in MIDI and what differs in MusicXML. Both formats were parsed independently with @tonejs/midi 2.0.28 on 7 November 2026.

One detail about the pitch row: changing a MIDI note's pitch means editing two bytes — the note-on message and the matching note-off both carry the pitch. In MusicXML, raising C to C♯ means adding a new <alter>1</alter> element inside the <pitch> tag. We measured that element at 16 bytes: the file grows from 3,964 to 3,980 bytes. The MIDI file stays exactly 169 bytes. MusicXML is text, so a change in musical meaning can change the file's length where MIDI would not.

The frequency column uses the formula f = 440 × 2^((n − 69) / 12), where n is the MIDI note number. The ratio between C5 (523.2511 Hz) and C♯5 (554.3653 Hz) is 1.059463, which equals 2^(1/12) — the semitone ratio. You can verify this with any calculator.

4. What changes and what does not

5. Check the arithmetic

Download the 169-byte MIDI file and hash it. Open it in a hex editor and find the bytes at the offsets above. The formulas are reversible, so a mismatch means the edit was made at the wrong offset.

The 960 in the tick-duration row is 120 × 480 / 60. This MIDI file has no tempo event, so the parser falls back to 120 BPM; with 480 ticks per quarter note, one tick is 60 / (120 × 480) = 1/960 second. "120" is a default in the software, not a value stored in this file. If that is the problem you are having, see MIDI wrong tempo after conversion.

6. When to use which

• Use MIDI when you want to play notes, edit them in a DAW, drive a synthesiser, or send performance data. MIDI is compact, universally supported by music software and hardware, and carries velocity and timing at high resolution. This site outputs .mid files for exactly this purpose.
• Use MusicXML when you want to exchange a score between notation programs, print sheet music, or carry clef/key/time-signature context that MIDI does not store. MuseScore, Sibelius, Finale and Dorico all import and export MusicXML.
• They are not interchangeable. A MIDI file can be opened in a notation program, but it arrives without a clef or key signature, and the note durations may not align to a clean beat grid. A MusicXML file can be opened in a DAW, but it arrives as notation data that must be rendered to audio — it does not carry a waveform.
• This site does not output MusicXML. It outputs single-track .mid files. If you need sheet music, import the MIDI into MuseScore or a similar program and let it apply the notation. See what is a MIDI file for the byte-level structure of the format this site produces.

What this page does not cover

• MIDI 2.0 protocol, UMP format, or MIDI-CI. Everything here describes a Standard MIDI File (SMF) on disk.
• MusicXML 4.0 features, compression (.mxl), or the opus format. The file above is MusicXML 3.1 Partwise, uncompressed.
• Automatic transcription accuracy or converter comparisons. The three edits demonstrate the formats, not any tool's performance.
• Multi-track MIDI or per-instrument MusicXML parts. The source file is single-track; the comparison covers one track of 14 notes.