Sheet music · Printed page to MIDI
Sheet music to MIDI is three different problems.
Which one you have depends on what is in your hand, and the three routes fail in different places. A PDF or a photo needs optical music recognition, which reads the page before it can read the notes. A printed score you can already play needs no recognition at all — you perform it into a MIDI track. A recording of the piece needs pitch detection, which is the only one of the three that has to guess. Picking the wrong route is the usual reason a conversion comes back unusable.
People search this both ways — sheet music to MIDI, music sheet to MIDI — and the word order does not change the job: notes off the page, into a file. What does change the job is which of the three routes you are on. This site does not read printed music: there is no scanner here, and no recognition model. What it does is the last mile, and it is the part most people skip. Whatever route produced your MIDI, the file has to still know its own meter — and most exports do not. Measured below: the same eight-bar waltz engraves as six bars without a time-signature event and eight bars with one, and the difference is fifteen bytes you can insert yourself.
| What you have | Route | Where it breaks |
|---|---|---|
| A PDF, a scan, or a photo of the page | Optical music recognition (OMR) | Staff detection, then symbol recognition. Clean, straight, high-resolution scans work; skewed phone photos, handwritten scores, and dense chords do not. |
| A score you can play | Perform it into a DAW or a MIDI keyboard | Nothing is recognised, so nothing is misread — but you get your tempo, not the printed one, and every note is quantised to whatever grid you set afterwards. |
| Only a recording of the piece | Audio to MIDI | Pitch detection. It hears one line at a time, so chords collapse and low notes vanish. This is the route the converter on this site takes. |
The part nobody checks
The MIDI you get back usually forgot it was in 3/4
A time signature in a MIDI file is a meta event with the type byte 0xFF 0x58. It is optional. A writer that only cares about note numbers can skip it and still produce a file every DAW opens and plays — the DAW just assumes 4/4, because that is the default in the format and in every sequencer built on it.
That assumption is invisible until something draws bar lines. Here is the same music twice: eight bars of a 3/4 waltz, each bar a root, its octave, and a chord tone, written by the same code. The first file carries no meter event. The second is the first file with a 0xFF 0x58 and a 0xFF 0x51 inserted at the start of its single track — nothing else changed.
| No meter event | Meter event inserted | |
|---|---|---|
| File size | 242 bytes | 257 bytes (+15) |
| Time-signature event | none → 4/4 assumed | 3/4, read from the file |
| Bars engraved | 6 | 8 |
| Bar 1 contains | C3 C4 E4 D3 — the next bar's downbeat pulled in | C3 C4 E4 — exactly one waltz bar |
| Bar lines fall on | beats 1, 5, 9, 13… | beats 1, 4, 7, 10… |
The arithmetic is dull and decisive: 24 quarter notes of 3/4 is 96 sixteenth notes, and 96 divided by 16 (a 4/4 bar) is exactly 6. The music is unchanged, the notes are unchanged, and every accent now sits one beat away from where it was written. This is what people mean when they say the import "looks wrong but sounds right" — play it and you hear the waltz, read it and the bar lines argue with you.
Nothing about this is specific to OMR. The same thing happens to a MIDI exported from notation software that had the meter set as a display property, to a file assembled by a script, and to anything written by a generator that only emits note-on and note-off pairs. If you want to know which kind of file you have, the answer is one hex search away.
Ten seconds, no software
Search the file for FF 58 before you trust it
Open the .mid in any hex viewer — even a text editor that shows hex will do, the files are a few kilobytes — and search for the byte pair FF 58. If it is not there, the file does not state a meter, and any bar line you see afterwards was invented downstream. Search FF 51 the same way for the tempo.
A second check costs nothing and catches the failure the hex search cannot: engrave the file and look at where the bar lines land. If the printed score has a bar line after three quarter notes and the engraving puts it after four, the meter is the problem, not the recognition. The MIDI to sheet music converter runs that check in the browser and reports both events by name — Tempo event: None and Time-signature event: None — so you see the assumption instead of inheriting it.
Putting it back
Fifteen bytes, inserted at the top of the track
You do not need a MIDI editor to add a meter. Both events are seven and eight bytes, and they belong at tick zero, at the very start of the track chunk, right after the MTrk header and its four-byte length.
| Bytes | Means |
|---|---|
00 FF 58 04 03 02 18 08 | delta 0, time signature, 4 data bytes: numerator 3, denominator 2² = 4, 24 MIDI clocks per click, 8 thirty-second notes per quarter |
00 FF 51 03 07 A1 20 | delta 0, tempo, 3 data bytes: 500,000 microseconds per quarter note = 120 BPM |
Three details decide whether the edit works. First, the four bytes after MTrk are the track length and they must be increased by the number of bytes you inserted — 15 here. Change the events and forget the length and the file is corrupt, not merely wrong. Second, the leading 00 on each event is the delta time and it is required; a meta event without it shifts every following note. Third, in a format 1 file the meta events belong in the first track, the tempo map, not in the track holding the notes.
What this fixes is bar placement, and only bar placement. It does not move a note, does not change a duration, and does not repair a misread pitch. If the recognition put a note on the wrong beat, that stays wrong — the meter only decides where the bar lines are drawn through it. Fix the notes first, then set the meter, otherwise you will be re-checking bar lines after every correction.
Test conditions. Both files were generated by localmidi-ops/run-score-to-midi.js: format 0, one track, 480 ticks per quarter note, 24 quarter notes at 120 BPM, written with the same byte-level writer used elsewhere on this site. File A carries only note-on, note-off and end-of-track. File B is file A with the fifteen bytes above prepended to the track payload and the length field raised from 0x000000DC to 0x000000EB. Both were then parsed by the same reader the sheet music converter uses, and the bar counts are that reader's output, not a hand count. Log: localmidi-private/logs/score-to-midi-meter-2026-11-11.txt.
What none of the routes fix
A MIDI file holds notes, not a performance
Whichever route you take, what arrives at the end is note numbers, start ticks, and durations. Slurs, dynamics, articulations, repeats, and the difference between a staccato and an accent are not in the file unless the tool that made it wrote them, and most do not. If the printed page says dolce, the MIDI says nothing.
Two consequences worth planning for. A repeat sign is a page instruction, not a musical one, so a scanner has to either unroll it or drop it — if your file is twice as long as the page looks, check that first. And a score with two staves becomes one or two tracks depending on the exporter, which decides whether you get a piano part you can edit or two unrelated lines you have to re-join.
None of that is a reason to avoid the conversion. It is a reason to check the file before you build anything on top of it: the meter is the cheapest check, the bar lines are the visible symptom, and fifteen bytes is the whole repair.
FAQ
Questions about converting a printed score.
Can this site convert a PDF or a photo of sheet music to MIDI?
No. Reading printed music needs optical music recognition, which is a server-side recognition model and not something this site does. What this site covers is the audio route (a recording to MIDI) and the check afterwards — engraving the returned file to see whether its bar lines match the page.
Why does my MIDI file look like it is in 4/4 when the score is in 3/4?
Because the file has no time-signature event, so every program downstream falls back to 4/4, the format's default. Search the file for the bytes FF 58. If they are absent, nothing was lost in transit — the meter was never written.
Does adding the meter event move my notes?
No. It changes where bar lines are drawn and nothing else. Note pitches, start times, and durations are untouched. If the notes are also in the wrong place, that is a separate problem and the meter will not hide it.
Is 120 BPM the right tempo to insert?
Only if the piece is at 120. The tempo event stores microseconds per quarter note, so the value is 60,000,000 ÷ BPM: 500,000 for 120, 600,000 for 100, 400,000 for 150. Converting that to three hex bytes by hand is easy to get wrong, so set the tempo in a DAW or a notation program instead and reserve hand-editing for the meter.
My file is format 1 with several tracks. Where does the meter go?
In the first track — the tempo map that notation software writes on its own. Meta events in a later track are legal but many programs ignore them, so a meter placed in the piano track may never be read.
What if the recognition misread a note as well?
Then you have two problems, and they are fixed in that order: notes first, meter second. Correct the pitches and rhythms in a DAW or notation editor, export, then check the bar lines. Setting the meter first means re-checking every bar after every correction.
Keep going