MP3 to MIDI starts late?
Move it. Don't stretch it.

Same phrase. A different starting point.

We generated a four-tone phrase at MIDI pitches 60, 64, 67 and 72. The baseline tones start at 0.2, 0.75, 1.3 and 1.85 seconds; each lasts 0.35 seconds. The second input contains the same phrase with exactly 44,100 zero-valued samples inserted before it: 44,100 / 22,050 = 2 seconds. This is deliberate source silence, not a measurement of MP3 encoder delay.

Both mono inputs were encoded as 128 kbps MP3 and decoded with native FFmpeg at 22,050 Hz. Basic Pitch 1.0.1 ran on the Node CPU backend, followed by this site's unchanged extraction thresholds and note writer. The baseline is 2.5 seconds long and the lead-in version is 4.5 seconds long. Nominal tone starts and lengths are rounded to the nearest whole sample in the generator. No user recording was involved.

Baseline → 0.196875 s

First exported event. Four source tones produced five events.

Lead-in → 2.195833 s

The source contains two extra seconds of silence.

Shifted → 0 s

Subtract 2,108 ticks from every event's start. Keep durations unchanged.

The measured first-event difference is 2.1958333333333333 − 0.196875 = 1.9989583333333334 seconds. It is close to the defined two-second edit, not exactly equal. That difference is a result for these generated files, not a universal correction to apply to your recording. The detector does not promise exact source onsets.

Both runs returned five events from four tones: pitch 60 was split into two adjacent events. Their later boundaries and velocities also differ between runs. Adding silence did not produce a bit-identical transcription merely moved by two seconds. A start correction does not repair a split note or certify the pitch transcription.

What the zero-start edit actually changed

We parsed the lead-in MIDI and subtracted its earliest note position, 2,108 ticks, from every note's start. We did not transcribe the audio again, change a tempo event, quantize the notes, or shorten a note. The shifted file below is a separate experimental artifact; the homepage converter does not silently make this edit for you.

The interval from the first event to pitch 72 is 3,702 − 2,108 = 1,594 ticks before the edit and 1,594 − 0 = 1,594 ticks afterwards. The script checks every relative start, every duration, every pitch and every velocity after serialization. All those checks passed. Both files have zero tempo events and a resolution of 480 ticks per quarter note.

Zero is not always the right musical target. Moving the earliest note to zero removes the intentional opening gap as well as the added lead-in. If the phrase contains a pickup or should begin after the bar line, preserve that placement. To compare our two unedited controls, keep their known two-second source difference separate from the zero-start rewrite.

Fix the right kind of mismatch

1. Keep the original audio beside the MIDI. Find an early note that both files clearly contain, then compare a later one. Do not use a spurious split fragment as the alignment anchor.
2. If both positions need approximately the same correction, select the whole MIDI phrase and move it together. Preserve gaps and note lengths; leave tempo unchanged for this step.
3. If the first note lines up but later notes progressively drift, check the tempo or time mapping instead. See the separate ticks-versus-seconds experiment before changing BPM.
4. If only individual boundaries are wrong, edit those boundaries. The duplicated pitch 60 in our controls needs a separate split-note review, not another global shift.

This is an editing workflow, not a claim that we imported the controls into Ableton, FL Studio or another DAW. A note position is also different from latency while playing an instrument live. Use the actual source and imported events to decide which problem you have.

Open the files. Check the claim.

• Baseline MP3 / source WAVGenerated phrase without the added lead-in.
• Lead-in MP3 / source WAVThe same defined tones, preceded by two seconds of zeros.
• Baseline MIDIOffline exported control, 138 bytes. Not a browser download.
• Lead-in MIDIOffline exported control, 138 bytes. First event at tick 2,108.
• Uniformly shifted MIDIExperimental rewrite, 137 bytes. First event at tick zero.
• Raw measurements / reproduction scriptParameters, file hashes, parsed events and all six shift checks.

Run the reproduction script in this project's installed dependency environment, passing the project directory as its first argument. It expects the installed model and this build's src/app.js for the source hash; downloading the script alone is not a complete project setup. It needs Basic Pitch, TensorFlow.js, the MIDI libraries and native FFmpeg. The script generates its own audio and uses the local model; it does not send recordings to an external service. Its result describes this CPU path, not an untested device or browser decoder.

Seconds shown here are parsed-file values. The installed MIDI library uses its default timing interpretation when a file has no tempo map; that is not a detected source BPM. The invariant edit is expressed in ticks to avoid claiming a new tempo estimate. The library's note representation documents how note ticks relate to seconds; our installed version and actual bytes are recorded in the raw report.

Late-start questions, answered