MP3 to MIDI: Why a Pickup Shifts Every Bar Line
A converted file contains no bar lines. It stores a time signature and a stream of delta-times, and every bar after the first is counted from tick zero, so a song that opens with a one-beat pickup arrives with its bar lines a beat early. Nothing in the format can record that the first bar is short.
Short answer
- No bar-line event. The specification's meta-event table has fifteen entries and none of them marks a bar; it says the bar number may be derived.
- Bar length is arithmetic. Division times four, divided by two to the power of the denominator byte, times the numerator. At 96 ticks per quarter, 4/4 is 384.
- A one-beat pickup is 96 ticks. The first downbeat lands on tick 96, which the file counts as beat 2 of bar 1.
- The score has a slot. MusicXML numbers a pickup measure 0 and flags it implicit, so the number is never printed.
A meter is not a bar line
Time Signature is FF 58 04 nn dd cc bb. The specification describes nn and dd as the numerator and denominator of the time signature as it would be notated, and the denominator as a negative power of two, so 2 is a quarter note and 3 an eighth. That fixes the width of a bar. It does not mark one. Tick zero is bar 1 beat 1 by convention, and every later bar is counted forward from it. The specification concedes the point in its timing section: a tempo map may carry time signature information so that the bar number may be derived. Derived, not stored.
Bar length is a division sum
With 96 ticks per quarter note, the division the specification uses in its own example, a 4/4 bar is 384 ticks, a 3/4 bar is 288 and a 6/8 bar is also 288, because dd 3 makes the eighth note 48 ticks and six of them fill the bar. Set Tempo gives a quarter note as 500,000 microseconds at 120 BPM, so a 4/4 bar lasts two seconds and a 3/4 bar one and a half.
What a one-beat pickup costs
Take a 4/4 song at 96 ticks per quarter opening with one pickup beat. The pickup occupies ticks 0 to 95 and the first full bar begins at 96. The file cannot say so: it counts bar 2 from 384 and bar 3 from 768. Every bar line from bar 2 onward therefore falls 96 ticks, half a second at 120 BPM, before the downbeat it is meant to mark. A reader trusting the count places the first downbeat on beat 2 of bar 1 and draws every later bar a beat early. The notes are untouched; only the grid is wrong.
The repair is silence
Pad the front with the three missing beats, 288 ticks at 96 per quarter, and the pickup becomes beat 4 of a complete bar. Bar 2 then begins at 384, where the first downbeat actually is. Nothing is re-uploaded: velocities, tempo events and note numbers stay; only the tick positions move.
How a score states the same thing
MusicXML makes the bar a container rather than a count. The measure element carries a required number, and the reference handles the pickup case directly: the number is typically 0 and the implicit attribute is typically yes, where implicit means the measure number should never appear. So a short first bar has a slot in a score and none in a .mid.
The check
Look at the first downbeat, not the first note. In 4/4 at 96 ticks per quarter, a downbeat on tick 96 is a one-beat pickup, 192 is two beats and 288 is three. A first downbeat that is not a multiple of 384 means the file starts short. Pad by 384 minus that tick position, and every bar line moves to where the music puts it.