How to Convert MP3 to MIDI
Without Losing the Clip's Place

Convert a clear MP3 excerpt, inspect its notes, and place the exported MIDI at the excerpt's original start time—not automatically at the song's beginning or at its first note. Keep the crop start alongside the file. In our local four-note test, an excerpt cut at 1.600 seconds produced its first MIDI event at 0.232 seconds. Placing that clip at 1.600 seconds restores the event to about 1.832 seconds on the original timeline. It does not repair the detector's early attack.

Use the existing browser converter to select your MP3, run Balanced, review the preview and download the draft. This tutorial covers the next handoff: keeping a short conversion in the right place when you return to the complete recording. For general source selection, use the main MP3-to-MIDI guide.

A conversion workflow with an explicit time reference

1. Keep the untouched MP3. Choose a short, isolated melody whose attacks you can identify. Write down the excerpt start in seconds relative to that original. Include enough audio before the first wanted attack; this site is a transcriber, not an audio cutter.
2. Export a working excerpt. Reopen it and check that the intended beginning and ending remain. Keep a small note such as excerpt.mp3: source start 1.600 s. The filename alone need not carry that information into the MIDI.
3. Convert the excerpt. Choose it in the converter, start with Balanced, inspect the notes and save the unedited MIDI. A successful download establishes that a file was written, not that every pitch and attack is correct.
4. Check the destination's time handling. Put the excerpt audio and its MIDI beside the original recording in your editor. Preserve the MIDI's internal lead-in and place the clip's time-zero at the recorded crop start. If your application removes initial rests or changes tempo on import, check that behavior first. We did not test an application's import switches here.
5. Compare several attacks before editing. A constant displacement points to placement; an error that changes through the phrase needs another check. Review pitch and note endings separately. Keep a raw copy before quantizing or moving notes.

For the earlier decision about cutting without losing an attack, see the MP3 crop-boundary experiment. Here the source attacks all survive the crop. The question is which clock the exported events refer to.

Three different zero points

The simple placement rule is original time = crop start + excerpt event time, provided both are interpreted on the same seconds scale. The first detected event is not the beginning of the excerpt. Removing its initial 0.232-second rest would introduce another shift. If you instead match the first attack by ear, record that correction separately; it need not repair later attacks.

The MIDI Association describes Standard MIDI Files as time-stamped event exchange and notes that tempo and descriptive metadata are supported. That does not mean this exporter writes your source-song position. Our independent parser found only a tempo meta event and an end-of-track meta event in these two exports; neither records the 1.600-second crop origin.

One source, two conversions, four matched pitches

On October 31, 2026, on this Windows machine, we generated a 5.6-second mono, 48 kHz, signed-16-bit source. Four half-second sine tones use MIDI pitches 60, 64, 67 and 72 at 2.0, 2.8, 3.6 and 4.4 seconds, amplitude 0.25 with 10 ms edges. We encoded the source as 192 kb/s MP3, decoded it, cut at 1.6 seconds and encoded the four-second excerpt as another 192 kb/s MP3. The excerpt therefore includes a second lossy encoding; this is not a sample-identical comparison.

Both MP3s were decoded with FFmpeg and analyzed by the unchanged production downsample, detectNotes and buildMidi functions in Balanced mode. Each produced four notes and a 72-byte MIDI file. These are actual local code-level conversions, not browser-decoder or DAW-import tests.

The table reads event ticks from the saved files, rather than copying the detector's floating-point objects. Each file uses 480 ticks per quarter note and a 500,000-microsecond tempo event, giving 960 ticks per second in this fixture. Tick rounding explains small differences between the JSON detector starts and this table.

Adding the crop start restores the coordinate system, not perfect transcription. Even after placement, the excerpt's first event is about 168 ms earlier than the source's intended 2.000-second attack. The two conversion paths differ by 25 ms on the first two notes and about 20.8 ms on the last two. Their analysis windows start at different positions, and the excerpt was re-encoded. This run does not isolate the separate contribution of either cause.

A file-size match is especially unhelpful here: both outputs are 72 bytes, but their bytes and timing differ. Whole MIDI SHA-256: d85fb19d32422d42278ef125e15230822314baf715b856f8fce29d825f362225. Excerpt MIDI SHA-256: 0aaba07b859a6b7f7b7d3f410bd3f8fa52801fbb78ca199318d7863fd90d1961.

When adding an offset is not enough

If all events move by the same amount, check the crop record and clip placement before changing sensitivity. If the first event aligns but later ones drift, check the receiving project's tempo interpretation and the actual performance. Do not stretch the whole part just because one attack is early. If a pitch is missing, that is a different decision from where to place a correctly exported event; the quiet-note comparison addresses one such case.

This site's measured writer uses a fixed tempo representation to serialize seconds. The tempo event in these files is not a measured BPM of the recording. A receiving editor may use its own project tempo; consult its import behavior and compare the resulting seconds before accepting alignment. This experiment did not open any DAW or demonstrate an application's automatic placement.

Download the evidence and repeat it

• Inputs: original WAV, whole MP3, excerpt MP3.
• Unedited outputs: whole MIDI, excerpt MIDI.
• Measured events and hashes: detector results, independent MIDI parser results, placement comparison CSV.
• Reproduction: Node experiment, independent Python parser, and this site's unchanged production source.

Save the scripts together in a fresh directory, provide FFmpeg through FFMPEG_BIN or your executable path, and point SITE_SCRIPT to the saved production source. Run the Node script, then the Python parser. The private verification regenerated the five audio/MIDI files in a separate directory and compared their SHA-256 hashes and complete numerical results; the check result is recorded in the research audit.

The extraction uses atrim=start=1.6,asetpts=PTS-STARTPTS. The official FFmpeg filter documentation distinguishes selecting a subpart from resetting its timestamps. The explicit reset defines our excerpt's zero; we retain the original offset separately instead of expecting the output MIDI to infer it.

Limits: one synthetic monophonic phrase, one MP3 encoder configuration and one detector setting. No real instrument, full song, browser audio decoding, listening, DAW import, automatic BPM detection or competitor conversion was measured. We do not claim a general accuracy rate, universal offset behavior or perfectly restored timing. The value of this test is an inspectable handoff: keep the source, keep the crop start, and check the events after placement.