MP3 to MIDI.
A range is not a source.

The upper layer disappeared.
So did a reference pitch.

Case 0 has no frequency bounds. Case 1 has only an upper MIDI-derived boundary of 60. Case 2 raises that boundary to 61. Case 3 adds a lower boundary of 48 to case 2. Case 4 moves the lower boundary to 49. Case 5 has only an upper boundary of 61.01. Case 6 sets both boundaries to 48. These are arguments to our installed extractor, not instrument names or slider values from another site.

The unbounded fundamental WAV and MP3 produced nine and eight events. The stronger-partial pair produced thirteen and fourteen, with eight higher-layer events each. Cases 1, 2 and 3 produced the same event counts within each input: eight and seven for the fundamental pair, four and five for the stronger-partial pair. All three cases kept only three of the four known reference slots. No higher-layer event remained in those stronger-partial exports, but that alone is not evidence of a complete transcription.

Case 4 left two reference slots in every control: pitches 52 and 55. Its fundamental WAV and MP3 contained four and three events; the stronger-partial pair contained two and three. Case 6 produced no events in any input, and we did not create empty MIDI files and call them successful conversions.

The argument and the array edge
are different numbers.

We converted the selected MIDI-derived boundary to hertz with Hz = 440 * 2 ** ((MIDI - 69) / 12). The constants and formula match the installed Basic Pitch implementation. The inverse used there is MIDI = 12 * (log2(Hz) - log2(440)) + 69. After subtracting its MIDI offset of 21, the result becomes an array-fill boundary.

These are the actual floating-point readings, not rounded replacements. The upper constraint zeros frames and onsets from the effective start index onward. In our boundary-61 run the effective start was bin 39, which corresponds to pitch 60. In case 5 it was bin 40. The parsed exports confirm the consequence: pitch 60 is absent in case 2 and present again in case 5.

This is a diagnosis of this installed extraction path, not a statement that every instrument-range control has the same endpoint semantics. Rounding a label to a whole MIDI pitch does not prove that its internal index has the intended endpoint. The result JSON keeps the requested boundary, full hertz value, inverse-mapped raw bin and effective integer index for every case. A different implementation may map those arguments differently.

Keeping a pitch is not separating it.

Case 5 restored four reference slots in every control. The fundamental exports returned to nine and eight events. The stronger-partial WAV and MP3 contained six and seven events, each with one higher-layer event. That remaining extra event is pitch 60 in the first source slot, whose reference is pitch 48. Pitch 60 is also the legitimate reference pitch of the final slot. A global frequency ceiling does not know which occurrence belongs to which source.

Removing pitch 60 globally removed that upper event but also removed the later reference tone. Retaining the pitch brought both back in this fixed-output comparison. Our labels describe parsed events assigned to known source slots; we are not claiming that an arbitrary musical recording can be classified from those labels. Extra reference-pitch events can also be fragments, so event count and source-slot coverage remain separate measurements.

This test changes frequency bounds, not sensitivity or minimum duration. Compare the sensitivity sweep and minimum-length sweep as separate interventions. They do not demonstrate a universal setting, and the live homepage has not gained a range selector in this update.

What stayed fixed.

All four generated WAV/MP3 inputs and their retained CPU captures are copied byte-for-byte from the preceding experiments. We checked input, compressed capture and decoded JSON SHA-256 values. Each run starts with a fresh deep copy because the frequency constraint mutates the onset and frame arrays. No new model inference or external conversion service is used here.

Both onset and frame thresholds stay at 0.25 and minimum note length stays at five frames. Inferred onsets, residual-energy extraction and energy tolerance retain the installed defaults. The source starts remain 0.20, 0.75, 1.30 and 1.85 seconds, each tone lasts 0.35 seconds, and reference pitches remain 48, 52, 55 and 60. The result JSON records the actual installed package versions.

We assign a parsed event to the nearest source centre using its midpoint: argmin(abs((parsedStart + parsedDuration / 2) - (sourceStart + 0.35 / 2))). A higher-layer event exceeds that slot's reference pitch. Reference-slot coverage counts slots containing at least one exact reference-pitch event. Neither classification is a natural-recording accuracy score.

Twenty-four nonempty MIDI exports were parsed back into pitches, ticks, durations and velocities; four zero-event cases have no fabricated MIDI. The unbounded exports match the prior five-frame, 0.25-threshold exports byte-for-byte. The export path is unchanged, including its zero-start clamp, minimum 0.03-second duration and velocity range of 0.05–1.

The reproduction script contains every extraction call, chosen frequency formula and baseline hash check. In this project run node scripts/measure-frequency-bounds.cjs. The required preceding inputs and captured arrays are publicly downloadable from the linked evidence pages; the run must keep their hashes unchanged.

A real range-control question.

Tuneonmusic's settings section explains that instrument choice sets frequency bounds, and its extra-note guidance discusses octave-doubled bass. That actual explanation prompted this independent extraction experiment. We did not run its converter or infer its instrument presets.

The fixed reference pages Note Foundry and MP3MIDITool discuss confidence or repair. On the three pages read, we did not see this fixed-output frequency-edge comparison with parsed exports. That is a page-limited observation, not a domain-wide novelty or ranking claim.

These short generated controls are not voice, full-band recordings or a labelled evaluation set. There is no browser, physical-phone, DAW, source-separation or accuracy result here. Actual browser exports remain documented separately.

Inspect the actual notes.

Full result JSON includes all boundaries, raw and integer indices, capture hashes, extracted frame events and parsed MIDI events. Four zero-note cases are labelled rather than hidden. Inputs and captures are retained exactly, not regenerated to make the result cleaner.

• Fundamental WAV inputRetained capture. MIDI: case 0 · case 1 · case 2 · case 3 · case 4 · case 5 · case 6 — no notes.
• Fundamental MP3 inputRetained capture. MIDI: case 0 · case 1 · case 2 · case 3 · case 4 · case 5 · case 6 — no notes.
• Stronger-partial WAV inputRetained capture. MIDI: case 0 · case 1 · case 2 · case 3 · case 4 · case 5 · case 6 — no notes.
• Stronger-partial MP3 inputRetained capture. MIDI: case 0 · case 1 · case 2 · case 3 · case 4 · case 5 · case 6 — no notes.