MP3 to MIDI: Why a Converted Part Has No Clef
A converted file carries pitch and nothing about how to draw it. The MIDI file format has no clef field, and the words clef, staff and treble appear in it zero times. MusicXML needs three elements to state a clef. A part that arrives buried in ledger lines is therefore a page setting, not a bad transcription: the note numbers are right.
Short answer
- No field. A note number is the entire pitch statement: 16 channels, 128 numbers, and no clef, staff or ledger attribute anywhere in the format.
- Three elements. MusicXML spells a clef as sign, line and clef-octave-change. Only the sign is required.
- Three anchors. Line numbers count from the bottom, and the standard values are 2 for G, 4 for F and 3 for C, with no two clefs sharing a line.
- One thing is lost. A transposing clef has no home in a .mid, which stores sounding pitch and nothing else.
The file has no clef field
Appendix 1 of the file-format specification gives Note On as 1001nnnn 0kkkkkkk 0vvvvvvv. The key byte is the whole pitch statement, and the channel is four bits: 16 times 128 addresses, each one an absolute pitch. A clef does the opposite job. It turns a position on a staff into a pitch, and the file never contains a staff position. Read end to end, the specification contains the string clef zero times, staff zero times, treble zero times and ledger zero times. The closest it comes is the word notation, used twice, both times about how hexadecimal digits are written.
What a notation format needs instead
The W3C reference states the shape: clefs are represented by a combination of sign, line and clef-octave-change elements. The sign is required, the other two optional. The percussion example writes a sign of percussion and nothing else, because a percussion staff has no pitch anchor to place. That is the whole vocabulary a notation format needs and a performance format does not: a symbol, a position, an octave instruction.
Three anchors on one staff
Line numbers count from the bottom of the staff, with 1 as the bottom line, and the reference names the standard values: 2 for the G sign, 4 for the F sign and 3 for the C sign. Three clefs, three anchor lines, no overlap. The element can also take a value outside the staff, which the reference gives for a C clef in the middle of a grand staff: the number is a drawing coordinate, not a property of the note.
The one clef a .mid cannot hold
clef-octave-change is defined in one sentence: it is used for transposing clefs, and a treble clef for tenors takes a value of -1. The bass-clef example writes sign F, line 4 and -1. That instruction is about written pitch, and a .mid stores sounding pitch only, so nothing records that the page is read an octave lower. A guitar or tenor part transcribed from audio arrives at concert pitch, and the 8 under the clef is added by hand.
Why the reader guesses, and the setting that fixes it
MusicXML says clefs appear at the start of each system unless print-object is set to no, which makes the clef page furniture. With no clef in the file the reader has only the note numbers, so its choice is a guess about range; the number attribute reads 1 when absent, and staves reads 1 when absent too. The fix is a page setting, not a re-run. Set staves to 2, the reference's own example being a typical piano part, give the lower staff the F sign on line 4, and nothing is re-uploaded.