Does a higher MP3 bitrate give better MIDI conversion?

Not for this converter. Encoding the same audio at 128 kbps and 320 kbps produced byte-identical note lists - the same notes, the same start times, the same durations. The reason is that the analysis runs at 16 kHz, which only looks below 8 kHz, while the difference between the two bitrates sits above 17 kHz.

What actually changes the MIDI result?

Whether more than one note sounds at once, and where the sensitivity slider is set. A three-note chord came back as a single note two octaves low at every bitrate. Moving the sensitivity slider on that same file changed the output from 0 notes to 18 notes.

Is 320 kbps a waste for audio to MIDI?

For this converter, yes - it produced exactly the same result as 128 kbps while being 2.5 times larger. That does not mean 320 kbps is pointless in general; it preserves content above 17 kHz that this particular detector never looks at.

128 kbps vs 320 kbps MP3 to MIDI

I encoded the same audio twice and ran both through this site's own detector. Here is what came out.

Short answer: for this converter, the bitrate made no difference at all. The same audio at 128 kbps and 320 kbps produced the same notes, the same start times and the same durations - identical, line for line. The file was 2.5× bigger for 320 kbps. What did change the output was whether more than one note played at once, and where the sensitivity slider sat.

This is a test I ran rather than something I looked up, so the rest of this page is the setup, the numbers and the parts I could not test. You can repeat all of it.

Why I expected a difference

The usual advice is that 320 kbps preserves more of the audio than 128 kbps, so a detector has more to work with. That is true as a statement about the files. A 128 kbps MP3 throws away content above roughly 17 kHz that a 320 kbps MP3 keeps, and my own measurements below confirm exactly that.

So the assumption going in was: better source, better notes. The test says otherwise, and the reason is specific to how this converter works.

How the test was run

To make this fair, both files had to go through the same detector. The converter is a single page with the analysis in plain JavaScript, so the parameters are readable in the page source:

Parameter	Value
Analysis rate	16,000 Hz
Frame length	1024 samples
Frame hop	256 samples
Pitch search range	60 - 2000 Hz
YIN threshold	0.15
Minimum note length	60 ms

I re-implemented that exact detector and ran the files through it locally, so the comparison is apples-to-apples. Encoding was done with libmp3lame at 44.1 kHz, constant bitrate, from one lossless source file. Both MP3s came from the same source, so any difference between them is the encoder's doing and nothing else.

Test 1 - a single-line scale

Source: a 4-second C major scale (C4 up to C5), 44.1 kHz mono, one note at a time.

Input	File size	Notes detected	Frames rejected
WAV, lossless	352,844 B	C4 D4 E4 F4 G4 A4 B4 C5	0 / 247
MP3, 320 kbps	163,047 B	identical, line for line	0 / 247
MP3, 128 kbps	65,244 B	identical, line for line	0 / 247

Three runs, three identical results. Not "close" - the note names, start times and durations matched character for character.

Test 2 - stereo, harmonics and a transient

A pure scale is an easy case, because a sine tone has almost no energy for a lossy encoder to throw away. So I built a harder source: the same scale, but stereo, with each note carrying harmonics up to 20 kHz, a click at every onset, and a noise floor. That gives the encoder real high-frequency content to work with.

Input	File size	Notes detected	Frames rejected
WAV, lossless	705,644 B	C4 D4 E4 F4 G4 A4 B4 C5	3 / 247
MP3, 320 kbps	163,047 B	identical, line for line	3 / 247
MP3, 128 kbps	65,244 B	identical, line for line	3 / 247
MP3, 64 kbps	32,643 B	B4 starts at 3.01 s instead of 2.99 s	5 / 247
MP3, 32 kbps	16,448 B	B4 starts at 3.01 s; C5 lasts 0.46 s instead of 0.43 s	4 / 247

Even at 32 kbps - a quarter of the 128 kbps file - every note name was still correct. The only damage was a 20 ms shift in where one note starts. For single-line material, the bitrate is simply not the variable that decides whether this works.

Why the bitrate does not reach the detector

The numbers above are not a fluke of my test material. They follow from two facts, and I measured both.

Fact one: 128 kbps really does lose the top end. Measuring the average power in 1 kHz bands across the full 44.1 kHz bandwidth:

Input	Highest band still above -50 dB	Power above 17 kHz
WAV, lossless	~20,000 Hz	-53 dB
MP3, 320 kbps	~20,000 Hz	-46 dB
MP3, 128 kbps	~17,000 Hz	-118 dB

So the 128 kbps file has essentially nothing above 17 kHz - it is 70 dB down, effectively silence - while the 320 kbps file still carries that content. If the detector looked at the full band, this would matter.

Fact two: it does not look at the full band. The converter resamples to 16 kHz, whose Nyquist limit is 8 kHz. Everything above 8 kHz is gone before the pitch detector ever sees a sample. I re-measured both MP3s after that same downsample, and across the 1-8 kHz range the two bitrates differ by at most 0.3 dB in any band.

The content 128 kbps destroys lives entirely above 17 kHz. The detector stops listening at 8 kHz. The two ranges do not overlap, which is why the MIDI came out identical.

What actually changes the result

If bitrate is not the lever, it is worth knowing what is. I ran two more tests on the same detector.

Test 3 - two notes at once instead of one

Source: a C major triad (C4 + E4 + G4) for two seconds, then a G major triad (G3 + B3 + D4) for two seconds. Six distinct notes in total, all of them inside the tracked 60-2000 Hz range.

Input	Frames rejected	Notes detected
WAV, lossless	124 / 247 (50%)	C2, 0.00-1.97 s
MP3, 320 kbps	124 / 247 (50%)	C2, 0.00-1.97 s
MP3, 128 kbps	124 / 247 (50%)	C2, 0.00-1.97 s

Six notes went in. One note came out, and it was C2 - two octaves below the lowest note actually played. Half the frames were rejected outright. And again, all three bitrates agree exactly, down to the rejected-frame count.

This is not a bug and not a bitrate problem. The detector tracks one pitch per frame by design, so when three notes sound together it reports a period that matches none of them. The site says so on its own about page, in the sentence "it is a monophonic detector, not a chord or polyphonic one".

Test 4 - the sensitivity slider

Same file throughout: the 128 kbps polyphonic mix from Test 3. The only thing changed was the sensitivity slider, which sets the YIN threshold.

Sensitivity	Frames rejected	Notes detected
0.50	39 / 247 (16%)	18
0.85 (default)	124 / 247 (50%)	1
0.95	239 / 247 (97%)	0

One slider, one file, and the output moves from nothing at all to eighteen fragments. Compare that with the bitrate test, where a 2.5× change in file size moved the output by zero. If you are trying to get a better result out of a dense recording, the slider is where the leverage is - not the export settings of the file you feed in.

What this means in practice

Do not re-export at 320 kbps for this tool. It produced the same MIDI as 128 kbps and a file 2.5 times larger. Spend the effort elsewhere.
Do not bother hunting for a lossless copy if a 128 kbps one is what you have. Both gave identical notes here.
Do check for polyphony first. If more than one note sounds at once in the section you care about, no bitrate will save the result. Extract or record the line on its own.
Do move the sensitivity slider and compare runs. On dense material it changes the output far more than anything you can do to the source file.

What I could not test, and what this does not prove

Being straight about the limits of the above:

These were not real recordings. Test 1 used a synthetic scale; Tests 2 to 4 used signals I generated. They are controlled and repeatable, which is what makes the comparison clean, but they are not a substitute for a real song.
Only one encoder was used. All MP3s came from libmp3lame. A different encoder may make different choices at 128 kbps. The conclusion holds for the encoder tested.
The detector was re-implemented, not the page itself. I reproduced the parameters and logic from the page source and ran them locally. If the page's behaviour differs from that logic in some case I did not cover, this test would not catch it.
This says nothing about other tools. A service running a polyphonic model on a server may well benefit from a higher bitrate. The finding here is specific to a single-line YIN detector.
I did not measure perceptual quality. 320 kbps genuinely sounds better than 128 kbps on good equipment. Nothing here disputes that. It only shows that this detector cannot tell them apart.

Open the converter and run your own file