Short answer: MIDI is not audio. A .mid file stores instructions — start this pitch now, at this force; stop it after this many ticks — and leaves the sound itself to whatever opens the file. The same eight-second C-major passage takes 705,644 bytes as a WAV and 169 bytes as a MIDI file, a ratio of 4,175.4×. One stores 352,800 amplitude samples; the other stores 14 notes. Everything below was read from those two published files on 5 November 2026, and you can download both and check every byte yourself.
| Property | The WAV (audio) | The MIDI (.mid) |
|---|---|---|
| File size | 705,644 B | 169 B |
| Header | 44 B (RIFF + fmt) | 14 B (MThd + 6) |
| Payload | 705,600 B of samples | 131 B of events |
| Timing grid | 44,100 samples / s | 480 ticks / quarter |
| Smallest unit | 1 sample = 2 B | 1 tick = 1/960 s |
| Duration | 8.000000 s | 7.944792 s |
| Notes | not stored | 14 |
| Tempo events | not applicable | 0 |
The WAV is a recording of a waveform: 44,100 amplitude values per second, each 16 bits, so 705,600 / 2 = 352,800 samples and 705,600 / 88,200 = 8 seconds. There is no "note" anywhere in it; a C4 exists only as a pattern of samples that your ear interprets. The MIDI file contains no sound at all. It says, in bytes, which note began, how hard, and when it ended. Change one of those bytes and you change one note — something you cannot do to a waveform without resynthesising it. That difference is the whole subject of this page.
Both files are published on this site and can be downloaded: the test WAV and the MIDI file. The WAV was made on 24 October 2026: eight one-second notes from C4 up to C5, mono PCM at 44,100 Hz, 16-bit. The .mid is the actual downloaded output of running that WAV through this site's browser converter on a Windows computer that day — not a hand-built example, not a textbook diagram.
An independent parse of that real output found 14 notes, not eight: all eight intended pitches, plus six short notes an octave above the first six onsets. That is a transcription artefact, and we are not going to hide it by showing you a cleaner file. It is a single-track result. If you want to understand those six extra notes and how to remove them, see clean up MIDI after conversion.
| Field | WAV | MIDI |
|---|---|---|
| Size (B) | 705,644 | 169 |
| SHA-256 (first 12) | 5854fdafce6f | 90795f6ff271 |
| Declared size | 705,636 (RIFF) | 6 (MThd payload) |
| Channels / format | 1 / PCM | 1 / SMF format 1 |
| Sample rate / division | 44,100 Hz | 480 PPQ |
| Byte rate / note count | 88,200 B/s | 14 notes |
| Data / event bytes | 705,600 | 131 |
| Duration (s) | 8.000000 | 7.944792 |
| Tracks declared / parsed | n/a | 2 / 1 note-bearing |
| Tempo / time / key signatures | n/a | 0 / 0 / 0 |
The WAV duration is computed from its own header (705,600 / 88,200 = 8 s). The MIDI duration of 7.944792 s is where its last note ends, which is why the two numbers differ slightly even though they describe the same passage. The MIDI file has no tempo event, no time signature and no key signature; the 480 in its header is ticks per quarter note, a resolution, not a speed.
Here is the structure of the file, read directly from its bytes on 5 November 2026. Offsets are decimal and count from zero. A Standard MIDI File starts with MThd, then one or more MTrk chunks; each event is a delta-time (how long since the previous event) followed by a status byte and its data bytes.
| Offset | Bytes (hex) | Field | Value | What it means |
|---|---|---|---|---|
| 0 | 4d 54 68 64 | Header chunk ID | MThd | ASCII "MThd" — SMF header starts here |
| 4 | 00 00 00 06 | Header length | 6 | header payload is exactly 6 bytes |
| 8 | 00 01 | Format | 1 | format 1: one or more tracks played at the same time |
| 10 | 00 02 | Track count | 2 | two MTrk chunks follow |
| 12 | 01 e0 | Division (PPQ) | 480 | 0x01E0 = 480 ticks per quarter note |
| 14 | 4d 54 72 6b | Track 1 chunk ID | MTrk | first track chunk |
| 18 | 00 00 00 08 | Track 1 length | 8 | holds only a name and an end marker |
| 22 | 00 ff 03 00 | Track 1 name | delta 0, FF 03 00 | empty track-name meta event |
| 26 | 00 ff 2f 00 | Track 1 end | delta 0, FF 2F 00 | End of Track |
| 30 | 4d 54 72 6b | Track 2 chunk ID | MTrk | the track that holds the notes |
| 34 | 00 00 00 83 | Track 2 length | 131 | 0x83 = 131 bytes of events |
| 38 | 00 ff 03 00 | Track 2 name | delta 0, FF 03 00 | empty track-name meta event |
| 42 | 00 c0 00 | Program change | delta 0, C0 00 | instrument 0 = acoustic grand piano |
| 45 | 00 90 48 26 | Note on, C5 | delta 0, 90 48 26 | pitch 0x48 = 72 (C5), velocity 0x26 = 38 |
| 49 | 00 90 3c 5b | Note on, C4 | delta 0, 90 3C 5B | pitch 0x3C = 60 (C4), velocity 0x5B = 91 |
| 53 | 64 80 48 00 | Note off, C5 | delta 100, 80 48 00 | C5 stops 100 ticks after it began |
| 57 | 86 44 80 3c 00 | Note off, C4 | delta 836, 80 3C 00 | two-byte delta 0x86 0x44 = 836 |
| 165 | 00 ff 2f 00 | End of track | delta 0, FF 2F 00 | last four bytes of the file |
Read row 15 carefully: 90 3C 5B means note on, channel 0, pitch 60, velocity 91. Two numbers, one note. Row 16 says that 100 ticks later the C5 note stopped. Every one of the 14 notes in this file is encoded as a pair of such messages. There is no sample rate, no bit depth, no waveform and no recorded sound anywhere in these 169 bytes — 14 notes cost about 12.07 bytes each including the header.
A definition is easy to copy. Here is something you can check instead. We took the 169-byte file and changed one musical variable at a time, then parsed both versions independently with @tonejs/midi 2.0.28 on 5 November 2026. Each version is still exactly 169 bytes with 14 notes; only the intended field differs, and every other note parses identically. The byte offsets are from the table above.
| Variable | Offset | Byte(s) | Formula | Before | After | Size / notes |
|---|---|---|---|---|---|---|
| Velocity of the C4 note-on | 52 | 5B → 40 | v = byte / 127 | 0.716535 | 0.503937 | 169 B / 14 |
| Pitch of the C4 note | 51 and 60 | 3C → 3D (both) | f = 440 × 2^((n−69)/12) | 60 (C4), 261.6256 Hz | 61 (C♯4), 277.1826 Hz | 169 B / 14 |
| Length of the C5 note | 53 | 64 → 32 | s = ticks × 60 / (BPM × PPQ) | 0.104167 s | 0.052083 s | 169 B / 14 |
One honesty note about the second row: changing a pitch is one variable, but MIDI writes each note as a note-on message and a matching note-off, and the pitch byte appears in both. Two bytes at offsets 51 and 60 had to change together, or the parser could no longer pair them. The velocity and note-length rows each change exactly one byte. We are not calling the pitch row a one-byte edit.
Nothing else moved. In the velocity row, the other 13 notes, every tick position and the whole-file duration are unchanged; in the pitch row, the note's start time and length are unchanged. In the note-length row, the 14 notes remain, but the C5 note is half as long and the 12 notes that begin after that delta each move 50 ticks earlier; the two notes already sounding at tick 0 do not move. Delta-times are relative to the previous event, not absolute timestamps, so shortening one of them shifts everything downstream. The whole file goes from 7,627 to 7,577 ticks (7.944792 s to 7.892708 s).
Why three different kinds of number. Velocity changes how hard a note is struck, pitch changes which note it is, and delta-time changes when it ends. Those are the three axes of a MIDI note event. A WAV has none of them: to change the pitch of a recorded note you have to rebuild the waveform.
Download the 169-byte file, open it in any hex editor, and change the single byte at the offset below. Save, then open both files in any MIDI parser or DAW. No special software and no account are needed. The formulas are reversible, so a mismatch means the edit was made at the wrong offset.
| Change | Formula back-check | Whole file (ticks / s) | SHA-256 before → after (first 8) |
|---|---|---|---|
| Velocity 91 → 64 | 91/127 = 0.716535; 64/127 = 0.503937 | 7,627 / 7.944792 (unchanged) | 90795f6f → 0cdb63ac |
| Pitch 60 → 61 | f(60) = 261.6256; f(61) = 277.1826; ratio 1.059463 = 2^(1/12) | 7,627 / 7.944792 (unchanged) | 90795f6f → 165fbd7d |
| Delta 100 → 50 | 100/960 = 0.104167; 50/960 = 0.052083 | 7,577 / 7.892708 (−50 ticks) | 90795f6f → a50837e1 |
The 960 in the third row is 120 × 480 / 60. This file contains 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. A different host with a different default would place the same 100 ticks somewhere else in time. If that sounds like the problem you are having, see MIDI wrong tempo after conversion.
Two limits belong with that. These are three edits to one 169-byte file, not a benchmark of any converter; and a real MIDI file from a dense mix will have far more than 14 notes. What the edits show is what kind of thing a MIDI file is, not how accurate any conversion is.
.mid. Playback needs a synthesiser, soundfont or instrument; the C0 00 at offset 42 only requests "acoustic grand piano" (program 0), it does not carry one.Because the file only says "play pitch 60, velocity 91, for 100 ticks", two programs are free to render it with different piano samples, different velocity curves and different default tempos. The notes are identical; the sound is not. This is the direct consequence of the byte table above, and it is why a .mid is useful for editing and notation but is not a substitute for an audio export. If you need to hear a MIDI file as audio, the MIDI to MP3 tool renders one in the browser.
Converting audio into this kind of instruction list is a transcription problem, not a format conversion: something has to decide where the notes are. This site runs that step locally in your browser, for a single file up to 100 MB or 10 minutes, without uploading the audio. Start with the MP3 to MIDI converter, the WAV converter, or the piano, guitar, voice and song pages. The accuracy test page describes how we measure what those conversions get wrong. After conversion you may want to clean up the notes and set the tempo before quantising.