Audio → MIDI

Audio to MIDI Converter

MP3 to MIDI Converter: How loud a note has to be before it hits velocity 127

A note reaches velocity 127 only when its running RMS level is −2.22 dBFS or hotter. That is quieter than it sounds, but harder to reach than it looks: −2.22 dBFS means the note's crest factor has to be 2.22 dB or less, and the loudest a clean sine wave can ever get at full scale is velocity 125. Everything below is measured on this site's own analyser (dsp.js), not quoted from anywhere else.

Velocity here comes from exactly one number: the average RMS of the frames a note occupies. There is no normalisation against the rest of the file, no per-track scaling, and no guesswork. That has a practical consequence you can measure in a minute — turn a file down by 6 dB and every note in the resulting MIDI comes out 11 velocity steps quieter. We did exactly that, and it came out at −11 steps on all eight test notes.

The formula, straight from the source

Every note is written by the same function, in both detection modes. The mean RMS is taken over the note's own frames, converted to decibels, and mapped onto the MIDI range:

rms = mean of frame RMS over the note's frames   // frame = 2048 samples = 92.88 ms at 22050 Hz
db  = 20 * log10(rms)
vel = round(20 + (db + 60) * (100 / 54))
vel = clamp(vel, 1, 127)

Three things follow from it, and all three are visible in the measurements below:

Measured: level in, velocity out

One 400 ms A4 (440 Hz) sine at 22050 Hz, default settings (monophonic, sensitivity 60). Level is the true RMS of the tone; velocity is what the converter wrote.
Level (dBFS)VelocityLevel (dBFS)Velocity
−3.01125−29.0377
−4.95121−36.9962
−7.45117−43.0151
−9.03114−49.0340
−10.97110−56.9925
−13.47106−63.0114
−16.9999−69.033
−23.0188
Two panels: a level-to-velocity curve rising from -69 dBFS to -3 dBFS, and peak-normalised waveforms showing that only a squared-off wave reaches velocity 127.
Left: the level-to-velocity curve, measured. Right: peak-normalised waveforms — the crest factor, not the peak level, decides who reaches 127.

Read the top row carefully, because it is the answer to the question in the title. −3.01 dBFS is the RMS of a sine wave whose peaks touch digital full scale. It gives velocity 125. A pure sine cannot be made any louder without clipping, so no clean sine wave, at any level, ever reaches 127 in this implementation.

What actually reaches 127: crest factor

Peak level and RMS level are only the same thing for a square wave. Everything else sits lower, and the gap between the two is the crest factor. Once a file is peak-normalised to 0 dBFS, the formula collapses into a rule of thumb that we then checked against real waveforms:

velocity ≈ round(131.1 − 1.85 × crest factor in dB)      // for material peaking at 0 dBFS
Peak-normalised 400 ms tones at A4, 0 dBFS peak. Crest factor measured from the samples; velocity measured from the converter.
WaveformCrest (dB)RMS (dBFS)Velocity
Square wave0.07−0.07127 (clipped)
Hard-clipped sine1.18−1.18127
Sine3.08−3.08125
Triangle4.84−4.84122
Two-tone (fifth)5.66−5.66121

We then bisected the level of the clipped sine to find the exact ceiling. At −2.25 dBFS the velocity is still 127; at −2.39 dBFS it drops to 126. That brackets the −2.22 dBFS the formula predicts.

So the honest answer to "how loud does it have to be" is: loud enough that its average level sits within 2.22 dB of its own peaks. That is limiter territory. If every note in your MIDI file comes out at 127, the source is squashed, not expressive.

The envelope moves velocity as much as the level does

RMS is an average over the whole note, so a note that decays quickly reads quieter than a note that holds, even when both hit the same peak. Same peak level (0 dBFS), same 400 ms length, only the decay time changed:

Peak-normalised 400 ms notes with exponential decay. Peak level identical in every row; only the shape differs.
Decay time constantCrest (dB)Velocity
50 ms14.70107
100 ms11.86109
200 ms9.03112
400 ms6.63118
800 ms5.02121
No decay (flat)3.08125

A second run at a fixed level, 300 ms notes, made the same point harsher: a 20 ms decay gave velocity 89 where the same note held flat gave 114. That is a 25-step spread from envelope alone, with no change in peak level at all.

MP3 bitrate does nothing to velocity. Level does everything.

This is the part that matters if you are feeding MP3s into a converter. We built an eight-note C-major clip with a deliberate dynamic curve (amplitudes 0.90, 0.45, 0.70, 0.30, 0.80, 0.55, 0.35, 0.95), encoded it with LAME at four bitrates, decoded it back, and ran all five versions through the analyser:

Eight notes, one clip, five versions. Every column is one note's velocity.
Version12345678
Source WAV123112119106122115108124
MP3 320 kbps122111119105121115107123
MP3 192 kbps122111119105121115107123
MP3 128 kbps122111119105121115107123
MP3 64 kbps122111119105121115107123
Same WAV, −6 dB1121011089511010497113

Two findings, and they point in opposite directions:

Two caveats we will not paper over: this test used eight synthesised sine notes, not a real master, and the encode/decode chain was LAME through ffmpeg 7.1. A browser's own MP3 decoder may land a fraction of a decibel elsewhere. The size of the effect is what matters — level moves velocity by 1.85 steps per dB, and the bitrate moved it by less than one.

MP3 bitrate does not bring back lost notes either

The test above shows bitrate leaves velocity untouched. It also leaves the note pitch untouched in a different sense: an MP3 has already lost low-frequency detail during encoding, so those notes may never reach the converter at all. That is a separate problem from velocity, and worth reading on its own — see whether MP3 to MIDI loses notes vs WAV (measured) for the FFT-resolution explanation and a way to test your file.

What does not change velocity

Three controls people reach for, measured:

One 400 ms A4 at −9.03 dBFS, one control changed at a time.
ControlSettingVelocity
Sensitivity0 / 20 / 40 / 60 / 80114
Sensitivity100113
Detection modemonophonic114
Detection modepolyphonic112

The sensitivity slider decides which frames become notes; it does not touch the velocity arithmetic, so moving it will not rescue a flat or a blown-out velocity map. Monophonic and polyphonic modes share the same velocity line of code — the one-step difference above comes from the two modes claiming slightly different frames at the note edges, not from a different rule. Quantisation also leaves velocity alone: the note is measured first, and only its start and end times are moved afterwards.

One more signal worth knowing: on the demo file shipped with this site, all eight notes came out at velocity 113–114. That is not a bug, that is what a constant-amplitude synthesised clip looks like. If your own conversion comes out equally flat, the source had no level variation across the notes.

How loud does a note need to be, in one minute

A velocity meter climbs as the waveform below it gets louder and more compressed. It stops just below the dashed line at the top — that is what 127 looks like.

The video is a one-minute visual summary of the measured curve above: the louder and more compressed the source gets, the closer the meter approaches 127, and it stops short of 127 for any clean waveform at full scale.

How to check your own file in four steps

  1. Convert the file and export the note list as CSV. The columns are index, midi_note, note_name, start_sec, end_sec, duration_sec, velocity, with times to four decimal places.
  2. Look at the spread of the velocity column. If the minimum and the maximum are the same number, you either have a constant-level source or a file sitting on the ceiling.
  3. Change the file's level by a known amount in any editor — 6 dB is easy to hit — convert again, and diff the two CSVs. Every velocity should move by about 11. If it does not, the conversion is not tracking level at all.
  4. If most notes sit at 127, turn the file down before converting. If most sit below about 70, the file is simply quiet relative to full scale; raising the level is the whole fix, because nothing here is normalised for you.

What "best MP3 to MIDI converter" can actually mean

Short answer: "best" is not a ranking you can read off a list here — for this engine it is a property of your file. Run one clip through and check the six boundaries below; every number comes from the constants in our DSP or from a clip we ran through it. Inside those boundaries this converter does the job; outside them, no slider setting makes it the best.

What the file decides before you touch a setting
BoundaryValue in this engineWhat to check in your clip
Lowest pitchF_MIN = 55 Hz (A1)A 41.2 Hz tone with harmonics returns 0 notes at sensitivity 60 and 80; a 55 Hz sine returns A1. Sub-bass is not transcribable here.
Low-frequency resolution2048-point window at 22050 Hz = 10.77 Hz per binBelow ~181 Hz (near F#3) a semitone is narrower than one bin, so low notes blur together.
Peaks per frameMAXP = 6 peaks per 11.610 ms frameA dense 8-note chord came back as 17 note objects, not 8. Past the ceiling, notes flicker and fragment rather than vanishing.
Shortest noteminFrames = round(minms / 1000 / frameT)At the 60 ms minimum-note setting that is 5 frames = 58.05 ms, and the first and last ramp frames still have to survive the gate.
Salience gatesalThr = 0.35 − 0.25 × sens (0.20 at sensitivity 60)If clean notes vanish, raise sensitivity before re-recording: a frame whose harmonic salience falls under this line is discarded.
Pitch movementOnly 0x90 / 0x80 note events are writtenA 440→494 Hz glide becomes 3 stepped pitches and 0 pitch-bend events. Slides are not preserved.

The tempo you enter is written into the file unchanged, and the engine never normalises your level — the velocity measurements above are the proof. The whole analysis runs locally in the browser, so the audio is never uploaded; that is a property of the page, not a claim about anybody else's service.

Which of the three routes is yours:

Where the note list lands frame by frame is in where the note boundaries land; if a conversion dropped notes, the four-step order to fix it starts with the format, not the sensitivity slider.

What other transcription approaches may do differently

Approaches built on learned models can emit pitch-bend events and separate sources before transcription. Those are real capabilities, but they answer different inputs than a browser FFT detector with a 55 Hz floor and a 6-peak-per-frame ceiling. The comparison that matters is the one you can run yourself: convert a file, export the CSV, and check the note list against the six rows above.

Questions people actually ask

Does the MP3 bitrate change the MIDI velocities?

No. We encoded the same eight-note clip at 320, 192, 128 and 64 kbps and got identical velocities from all four, within 0.75 steps of the source WAV. Bitrate changes what survives in the audio; it does not change the level the converter reads. What changes velocity is the file's level — 1.85 steps for every decibel.

Why does every note come out at the same velocity?

Because velocity is the mean RMS of that note's frames, and your notes all have the same mean RMS. This is common with synthesised or heavily compressed material: on the demo clip shipped with this site, all eight notes land at 113–114. Real recordings vary, but only by as much as their level actually varies — if a compressor removed the variation before you converted the file, the MIDI will be flat too.

Can I fix the velocities with the sensitivity slider?

No. We swept sensitivity from 0 to 80 on the same note and velocity stayed at 114; at 100 it moved to 113, and only because the note picked up a frame at the edge. Sensitivity controls which frames qualify as a note. Velocity is computed from loudness afterwards, so no threshold setting will change it. Change the file's level, or edit the velocities in your DAW.

Why did converting audio to MIDI change my velocities?

It is not random, even though it looks that way — this is a question people have asked out loud on production forums, usually after noticing that "some notes are now much louder" while the change "doesn't reflect the audio volumes". Two notes that look equally loud on a peak meter can read very differently here, because what is measured is the average level across the whole note, and a note that decays quickly averages lower. A 20 ms decay and a flat sustain at the same peak level differed by 25 velocity steps in our test.

How does audio to MIDI decide each note's velocity?

Velocity comes from how loud each note is in the recording. The converter takes the average level of the frames that make up a note and maps it to a value from 0 to 127, reaching the maximum 127 at around −2.22 dBFS. Louder notes get higher velocity; quieter ones get lower, so a performance with natural dynamics keeps its accents in the MIDI. It is a per-note loudness reading, not a fixed value — which is why a heavily compressed file can come back with every note at nearly the same velocity.

Related guides

Everything on this page is measurable on your own machine: convert a file, export the CSV, and check the velocity column against the numbers above.