Audio → MIDI

Audio to MIDI Converter

MP4 to MIDI: Why the AAC Audio, Not the Video, Decides Your Notes

An MP4 is a container. The converter reads only its audio track and ignores the video. In almost every MP4 that audio is AAC — a lossy codec. On this converter's own dsp.js, an AAC file at 64–256 kbps changes the MIDI by at most one velocity step compared with a WAV original, while an MP3 of the same clip shaves about 0.75 step off most notes. So the format in the filename barely matters; the codec inside it is what decides whether anything moves.

What is actually inside the file

An MP4 wraps one video stream and one (or more) audio streams together. Our converter asks the browser to decode the file and hands the resulting samples to the pitch detector. It never looks at the video frames, never uses the resolution, and never uses the duration of the picture track. If you have ever been told “the video wrapper makes no difference,” that part is true — for the video. What is not neutral is the audio codec, because that is the one thing the detector actually hears.

Phones, cameras, screen recorders and social platforms almost all store that audio as AAC. It is a perceptual codec: it throws away the parts of the signal a model of human hearing is least likely to miss. A WAV or FLAC export, by contrast, keeps every sample. MP3 is the older cousin that does the same kind of throwing-away with a different recipe. The question this page answers is whether that throwing-away changes the notes you get back.

How the measurement was done

The test clip is a known-answer phrase: eight notes of a C-major scale with a deliberately uneven loudness curve, rendered at 22,050 Hz. We encoded that single clip to AAC at 64 / 128 / 192 / 256 kbps and to MP3 at the same four bitrates, decoded each file back to raw PCM, and ran the site's real dsp.js over every version in both mono and polyphonic mode. The numbers below are what the converter itself produced — not a formula, not an estimate.

Decoded audio versus the source PCM (louder is closer to the original)
VersionPeak dBFSRMS dBFSMono notesPoly notes
Source WAV (16-bit)−0.45−8.1788
AAC 64 kbps−0.08−8.1788
AAC 128 kbps−0.43−8.1788
AAC 192 kbps−0.43−8.1788
AAC 256 kbps−0.43−8.1788
MP3 64 kbps−0.89−8.6288
MP3 128 kbps−0.89−8.6288
MP3 192 kbps−0.89−8.6288
MP3 256 kbps−0.89−8.6288

The AAC column is the headline: at every bitrate the decoded file matches the source RMS to within 0.02 dB and the converter returns the same eight notes. The MP3 column quietly loses 0.45 dB of RMS energy — enough to nudge velocities down, but not enough to drop or add a note on this phrase.

Per-note velocity, mono mode (true loudness curve 0.90 / 0.45 / 0.70 / 0.30 / 0.80 / 0.55 / 0.35 / 0.95)
Versionn1n2n3n4n5n6n7n8
Source WAV123112119106122115108124
AAC 64–256 kbps123112119106122116108124
MP3 64–256 kbps122111119105121115107123

AAC lands within one step of the WAV on a single note. MP3 sits one step lower on six of the eight notes, a consistent −0.75-step drift that tracks the 0.45 dB it shaved off the file. In polyphonic mode the same pattern holds: AAC matches the WAV note-for-note, MP3 comes back one step quieter across the board.

Why AAC is the gentler container

The reason shows up in the decoded audio itself. AAC at these bitrates rebuilt the waveform so faithfully that its RMS energy was indistinguishable from the source; MP3's decoder returned a file that was measurably quieter. Velocity on this converter is a function of how loud each note reads after the codec, so a codec that preserves level preserves velocity. AAC did; MP3 didn't, on this content.

This is not a promise that AAC is always perfect. It is a measured result on a clean, separated phrase — exactly the kind of material the converter handles best. The point is that the container's codec is a real variable, and on the common bitrates it is a small one.

Where it still breaks, and how to check

Two honest caveats. First, this was a clean clip. A heavily compressed phone video, a low-bitrate stream, or a busy mix pushes any lossy codec past the point where it can hide the damage, and then you will see the same kinds of stray and missing notes this site documents for dense mixes elsewhere. Second, a 48 kHz soundtrack gets folded to the converter's 22,050 Hz working rate before detection; if your MP4 is 48 kHz and you want the sample-rate side of that story, it is covered separately on the video to MIDI page.

You do not have to trust the table. Drop your file in, export the CSV, then open the same audio exported as a WAV from your editor and convert that too. Compare the velocity column row by row. If the two lists match note-for-note and the velocities differ by a step or two, the codec is doing what the measurement above shows. If whole notes appear or vanish, the problem is the recording, not the container.

The practical takeaway: you do not need to re-encode an MP4 to WAV before converting. AAC is already the faithful one here. If anything, exporting through an MP3 step is the move that costs you a little velocity — so leave the MP4 as it is and let the converter read its audio track directly.

Questions people actually ask

Does the converter read the video track, or just the audio?

Just the audio. The browser decodes the MP4 and hands the converter the samples from the audio stream; the video frames are never opened. Resolution, frame rate and video length have no effect on the MIDI. The only part of the file that matters is the codec the audio was stored in.

Should I re-encode my MP4 to WAV before converting?

No. The audio in an MP4 is AAC, and on this converter's own code AAC at 64–256 kbps moved the MIDI by at most one velocity step versus a WAV original. Re-encoding to WAV adds a decode-and-re-encode round trip for no gain, and if you route that round trip through MP3 instead you actually lose about 0.75 velocity step on most notes. Convert the MP4 as it is.

My MP4 came from a phone at a low bitrate — will that hurt?

At the common bitrates it will not: the measurement above held from 64 kbps up. A very heavily compressed or low-bitrate capture can smear transients enough to add stray notes or drop quiet ones, the same way any lossy codec does on busy material. To find out which you have, export the audio as a WAV from your editor, convert both, and compare the CSV's velocity column note-for-note. Matching lists mean the codec is fine; appearing or vanishing notes mean the recording is the limit, not the container.

Related guides

Back to the converter to try your own file.