WAV vs MP3 for Audio to MIDI: What Reaches the .mid File

The one variable: the container, not the music

The source is a file already published on this site: /examples/C-major-eight-notes-44k1.wav, made on 24 October 2026. It is eight one-second notes from C4 to C5, mono PCM, 44,100 Hz, 16-bit, 8 seconds. Its size is not a mystery: 44 + 44,100 x 8 x 1 x 16/8 = 705,644 bytes, which is exactly the byte count on disk.

We copied those 352,800 PCM samples and encoded them with lamejs 1.2.1 as MPEG-1 Layer III CBR at 128 and 320 kbps. No resampling, no gain change, no added silence, no trim. So the only thing that changes between the three inputs is the container and its compression; the source PCM sha256 5854fdafce6f8520… is the parent of all three.

The MP3 byte counts land within 0.57% of bitrate x 1,000 x seconds / 8; the remainder is frame alignment and encoder delay, which is also where the tick shift below comes from.

What the converter produced

Each file was selected in a real Chrome page, converted by the site's own tool (app-7c537f3f6b.js), downloaded as a .mid, then parsed independently with @tonejs/midi 2.0.28. The page engine's own parser was not used to produce any number here.

All three have one track, 9 notes, PPQ 480, and zero FF 51 03 Set Tempo events. 120 BPM is the player default, not a detected tempo. The .mid byte count is identical (129 B) while the sha256 differs for every input: same-sized, different bytes.

Note by note: the 33-tick shift is not a constant

The extra short note changes position, so pairing notes by array index would shift everything after it by one row and invent six fake pitch changes. We separate the eight sustained melody notes (matched by pitch sequence, identical across all three) from the one short low-velocity note, then compare ticks cell by cell.

The melody pitch sequence is identical in all three files. But the WAV-to-MP3 onset shift is not a uniform offset: it ranges from 0 to 34 ticks across the eight notes, and one note (number 8) does not move at all. Saying "MP3 adds 33 ticks" would be wrong; the table is the claim.

The extra short note moved

Each output also contains one brief, low-velocity note beyond the eight-note scale. In the WAV output it is 74 (D5) at tick 959, 67 ticks long. In both MP3 outputs it is 79 (G5) at tick 3859 — a different pitch appearing three notes later. This is the same kind of artefact described on the clean up MIDI page.

The two MP3s differ only in that note's length: 78 ticks at 128 kbps versus 67 ticks at 320 kbps. Velocity is 0.3150 in both, versus 0.2913 for WAV.

Did the bitrate matter?

Not for the note sequence. The 128 kbps and 320 kbps files have the same 9 notes in the same order at the same pitch set, and both are 129 bytes. They are still different files: sha256 bd926d878814c739… versus dc0fe201d13ad720…. Every differing cell is listed below.

On this one clip, the container switch (PCM to lossy MP3) moved the onsets and changed the extra note; raising the MP3 bitrate from 128 to 320 changed only six small cells. That is an observation about these three files, not a general rule about bitrate.

Recompute every number yourself

Both source files are downloadable from this site, so the whole experiment can be repeated. The formulae and the two independent readings are side by side; tick-to-second conversion uses seconds = ticks x 60 / (BPM x PPQ) with 120 BPM as the player default and PPQ 480 read from the files.

Checksums for all six files (three inputs, three outputs):

A .mid that is only 129 bytes can be opened in any MIDI editor; these were parsed with @tonejs/midi 2.0.28, which is independent of the browser engine that wrote them.

How much of this page is exclusive material

Exclusive means independently reproducible measurements from files this site actually produced, not method notes, limitations, disclaimers or general facts. We report both denominators side by side, as required: sections 7/10=70.0% and characters 6,310/7,931=79.6%.

Algorithm: split the body at every <h2>, count sections; strip tags, normalise entities, collapse whitespace, count characters. Sections carrying data-exclusive="1" are the numerator. The head, the first-screen answer and the footer are outside the denominator. A section is exclusive only if it contains measurements that can be recomputed from the published files.

What this does not tell you

One eight-second synthetic C-major scale, mono at 44,100 Hz, on one Windows Chrome on 6 November 2026. It says nothing about a full song, a voice, a guitar, or a mix. It is not an accuracy measurement, not a comparison with any other converter, and not a promise about how long a conversion takes. The tool writes a single track with no tempo event; it does not separate instruments, does not keep a drum part, does not detect BPM, and accepts local files rather than links.

If you need the tempo set to something other than the 120 BPM default, see MIDI wrong tempo after conversion. For the byte-level structure of a .mid, see what is MIDI.

Convert your own WAV or MP3

The converter runs in your browser and does not upload your audio. It accepts MP3, WAV, M4A, FLAC and OGG, one file at a time, up to 100 MB or 10 minutes, whichever comes first. The result is one editable single-track .mid file.

• Audio to MIDI — the general tool on the site root
• WAV to MIDI — if your source is a WAV
• MP3 to MIDI — if your source is an MP3
• Clean up MIDI — fixing short extra notes and split notes afterwards
• MIDI to MP3 — going back the other way

Related reading

MP3 to MIDI accuracy: four converters, measured describes the paired-clip comparison and its limits. What is MIDI shows the same 169-byte file byte by byte. About explains what the tool does and does not do.