MIDI to ABC: two commands, and six header lines you have to check.

The input is a 329-byte file: 34 note events, nine bars, and no FF 51 tempo event, no FF 58 time-signature event and no FF 59 key-signature event — which is what most browser converters, including this site's own, produce. This is midi2abc song.mid -o song.abc, pasted without editing:

Eighteen lines. Nine of them are header, including the voice declaration; the other nine are music — eight bars and a closing chord. Two of the header lines are comments — they start with % — and those two comments are the converter admitting which of its values are guesses. Everything after this page's field-by-field walk comes from files this small, because a small file makes every field checkable by eye.

Each field below was tested by changing one thing in the input file and re-running the converter. The tests used five MIDI files: the 329-byte one above; the same waltz with and without a meter event (242 and 257 bytes); a file with two sharps in its key signature; a file of sixteen sixteenth notes; and files at 90 and 60 BPM.

X: The tune number, and it is always 1

X: is the reference number of the tune. One ABC file may hold several tunes, and this is the index that tells them apart. A MIDI file is one performance of one piece, so every run produced X: 1 — across all five test files, with no variation. Leave it alone.

T: The title — and it is your filename, not your title

This is the first field that costs you something. midi2abc writes T: from followed by the input filename. It does not read the title inside the MIDI file.

The test: a 307-byte waltz with a FF 03 track-name event reading Waltz in D, plus a FF 01 text event. The output header still said T: from v-keyd.mid. The title in the file was ignored, and the filename was promoted into the document title.

So T: is the one field you rewrite every single time. It is also the field a reader sees first, and the one that survives into anything that indexes ABC files.

M: The meter, read from the file or invented as 4/4

M: comes from the FF 58 event. When that event is absent, the converter does two things at once: it writes a comment saying the event is missing, and it writes M: 4/4 anyway. The comment does not stop the 4/4 from being used.

The two files hold the same 24 notes. The difference is fifteen bytes of meta event, and it changes where every bar line falls:

In the first version the bar line lands after the first note of the next bar, so each written bar contains four notes and spans one and a third real bars. In the second, every bar holds exactly the three notes the waltz was written in. Nothing was added or removed; the same notes are simply grouped differently. This is the same experiment as the fifteen bytes on the sheet-music-to-MIDI page, seen through ABC instead of through a staff.

L: The unit, fixed at 1/8 whatever the notes do

L: is the default note length. Every duration in the body is a multiple of it, so a sixteenth note under L: 1/8 is written as half a unit: C/2.

midi2abc writes L: 1/8 and leaves it there. A file of sixteen sixteenth notes still came out as L: 1/8, with the body reading C/2D/2E/2F/2 G/2A/2B/2c/2. That is not an error and not a sign that something was lost — it is one eighth split in half.

There is a flag, -gu, that is documented as guessing the unit from the note durations. On the same file it did not change L: at all. It changed two other things instead:

Total playing time is identical, because doubling every note and doubling the tempo cancels out. What changed is the notation: a passage of sixteenths is now written as eighths at twice the speed. It plays the same and reads wrong, which is the worst kind of wrong, because you only find it when someone tries to perform from it.

Q: The tempo, read from the file — and the flags that do not set it

Q: comes from the FF 51 event, and it tracks that event exactly:

That last row is the trap. 120 is the format's default, and 120 is also the most common real tempo, so a file that never had a tempo looks exactly like a file that had 120 written into it. If you care about the tempo, check the source for FF 51 before you trust the line.

Now the flags. midi2abc documents -Q <tempo in quarter-notes per minute>. It does nothing here:

So: -Q is dead, and -m quietly rewrites the tempo while setting the meter. Both were checked with the flag before and after the filename, so it is not an argument-order problem. Edit the Q: line in the text instead — that path is verified in the last section.

K: The key, read from the file or defaulted to C

K: comes from the FF 59 key-signature event. The two cases look completely different in the output:

The second case has a comment that reads like a diagnosis but is only a comment. K:C is what the notes are written in, so a tune whose last note suggests Mixolydian will be spelled with accidentals all over it — the F natural in =F is there because the header says C major and the note is not in C major. The comment did not change a single note.

Unlike -Q, the key flag works: -k 2 on the same file produced K:D % 2 sharps. If you know the key and the file does not carry it, that is one flag you can use.

Here is why the header matters more than it looks. Run abc2midi on the ABC that midi2abc produced from a file with no meter, and the 4/4 guess becomes a real time-signature event in the new MIDI file:

The original file had no meter event at all. After one trip through ABC, it has one, and if you did not edit the header, that event is wrong. The guess has been laundered into data. A program downstream has no way to know it was a guess, because it is now the same fifteen bytes a correct meter would be.

Which is why the fix has to happen in the text, before abc2midi runs. Changing M: 4/4 to M: 3/4, Q:1/4=120 to Q:1/4=90 and the T: line, then re-running, produced exactly the bytes it should: ff 58 04 03 02 12 for 3/4, 666,666 µs for 90 BPM, and the new title in FF 03.

It also produced three warnings, and those are the most useful lines in the whole exercise:

M: changes how bar lines are drawn. It does not re-bar the notes. Change the meter and leave the body alone, and you get a file that claims 3/4 while three of its bars hold four beats — and abc2midi still writes the 3/4 event, because it writes what the header says. The header and the music are two independent statements, and nothing forces them to agree.

1. midi2abc song.mid -o song.abc
2. Open song.abc. Rewrite T: — it is the filename and always will be.
3. If the file contains %***Missing time signature meta command, decide what the meter really is and edit M:. Do not use -m for this; it changes Q: too.
4. If the source had no FF 51 event, edit Q: by hand. Do not use -Q; it does nothing.
5. Read the body and check that the bar lines match the meter you just set. This is the step everyone skips, and it is the one the warnings will catch for you.
6. abc2midi song.abc -o song-fixed.mid, then read the warnings about bars that do not match the time signature.
7. Verify: the new file should contain FF 58 if you set a meter and FF 51 if you set a tempo. If it does not, the header line was not where the converter looks for it.

MIDI to sheet music — the notes on a staff, in the browser →

MusicXML to MIDI — the same trip in the other format, and what it drops →

Sheet music to MIDI — the fifteen bytes that decide where bar lines fall →

Audio to MIDI — a recording to notes, in the browser →