Midi import chooses accidentals badly (for this file)

• Mar 27, 2015 - 18:52

(New thread as requested).

Here is my midi (from Personal Composer) of a very major, E major, as a matter of fact, chorus from Bach's Matthäuspassion. The key signature is given in Midi as E major; yet, Eb's are used instead of D# by the import, and Bb instead of A#.

Anyone lifting the score: it's pretty bad without any work; I have a worked-on version which is great, but that's not the issue here.

Attachment Size
omb2.mid 81.8 KB

Comments

Also, I don't know if Midi knows the difference between Eb major and C minor, but ... no, the default of Gb over F# is wrong in either. The leading tone of the relative minor and its dominant are more likely than the flattened thirds of the tonic or subdominant (in major), and in minor there's no contest. Example if asked.

Hmm, I can reproduce the problem with this file, but not with other MIDI files in the key of E. Are you finding the same? Not sure what about this file is causing the problem whereas my simple example in E worked fine. Without knowing much about the internal structure of a standard MIDI file, I'm going to guess the problem with this file is related to whatever is going on to cause the English horn to have a different key signature than the rest of the stave s- and not the key signature you would expect just because of its transposition. I suspect that whatever program exported this file originally did so in an incorrect way, but it's also possible that it was simply an "unexpected" way that MuseScore needs to know how to deal with. Do MIDI files have a concept of a "global" key signature separate from a "track" key signature? If so, maybe these aren't being exported in the way that MuseScore expects?

As for Gb in the key of Eb major, as I said, the algorithm is simple: it always chooses the more closely related spelling on the circle of fifths. So in the case of scale degree #2 versus b3 in a major key, that is a win for b3, because it is only three steps away on the circle of fifths whereas #2 is four. And b3 *is* actually an extremely common note, appearing in a "borrowed chord" context from the parallel minor. That said, yes, of course, #2 as the leading tone in the key of iii is very common too. That and #5 versus b6 are probably the biggest "toss-ups" in a contest between spellings - in both cases, it's a question of usage in secondary dominants versus usage in borrowed chords. Might be interesting to see an actual study - something could probably be programmed up quickly using music21 to study a set of scores and produce statistics. I suspect we'd find a slight win for #2 & #6 in classical music (a stronger win for the analogous notes in minor keys as you suggest), but also a perhaps more convincing win for b3 and b6 in rock / jazz / blues etc.

In reply to by Marc Sabatella

It's impossible to export it "incorrectly." Midi has no concept of transposition. As you note, when the score is in a minor key, you get chaos: the very leading tone is wrong in every key.

If half the scores in a given key signature are major, and the #5 b6 and #2 vs b3 are arguable, the other half are in the minor (leaving aside, of course, church-mode and church-mode-yearning music) and the decision is "slam dunk". I would think that this would settle the case.

Clearly, MuseScore is seeing the -correct- signature on the staves with the incorrect Eb's and Bb's.

As I said initially, you should be able to say what you want.

In reply to by [DELETED] 1831606

I'm not sure what you mean about it being impossible export "incorrectly". I can think of a lot of things that would constitute incorrect export from what I *do* know about how an SMF is structured. But I can also think of a lot of things that would be tehcnically correct just unexpected. For instance, the difference between a global key versus a track-specific key, the difference between an overall track key versus a key *change* that happens to occur right at the beginning of the track. Which is why I'd like more information, or would prefer to defer analysis to someone who understands SMF formats better than I do and has the appropriate tools to examine the contents of this one.

The point being, somehow, the MIDI exported by MuseScore seems to import fine whereas the MIDI exported by the software you have been using does not. So *something* is different, where "incorrect" or merely "unexpected". Until we understand *what* that difference is, it is hard to say what is going on. But for comparison, try importing this score, and you'll see it actually imported perfectly. So it's not like MuseScore does not know it is supposed to use D# in the key of E in general. Somehow, something is different about that one aprticular score of yours that causes it to be confused about the key - and probbably that same thing is causing the English horn to get the wrong key signature in your file even though it gets it right in mine.

As for #2/b3 versus #5/b6, you certaibnly raise good points, and I think you should file an feature request to the issue tracker to ask the algorithmn be changed, or at least an option be provided. Anyhow, the point is, the key *is* honored, just not in the particular way you would profer. And as a separate issue, this one file in particular (or maybe all files from that software) seems to cause some other as-yet-unexplained problem presumably due to a bug in either the software you are using or in MuseScore; too early to say which).

Attachment Size
tpc.mid 229 bytes

In reply to by [DELETED] 1831606

Here are a couple of other relevant descriptions:

http://www.somascape.org/midi/tech/mfile.html#mtrk

and

http://www.somascape.org/midi/tech/mfile.html#meta

My understanding of this - also based in part on my memory of when I dealt with such matters more around 25 years ago - is that for type 1 files there is supposed to be a single track with key info as well as tempo and other global info. Not sure; I actually dealt more with type 0 files. But in those early days of MIDI, there were programs that would place this info in individual tracks. I guess that was maybe the idea of type 2 files, although apparently that format died out?

In point of fact, you -have- a program that interprets midi files, namely, the MS importer. It is to your advantage (other users may well encounter this problem) to breakpoint it where it e-flats my d-sharp and find its motivation. I know enough about midi files (years ago I wrote an interpreter) to know that therein are nothing but unspelled pitches with durations, and occasional "meta" marks for tempo, tagging, etc. Other than the file-wide key-signature (and mode), it sequesters no hints for note spelling. Evidently, MS sees all the notes and knows what they are, as well as the key signature. Whatever my file's problem (and as I said, I have "fixed" the new MS score of that particular file), I think it would benefit your product to know what, valid or invalid, drove it to deny my E major its leading-tone. Perhaps the anomaly involves the number of staves/channels or some other putatively irrelevant artifact; say, an uninitialized variable and/or unchecked array store. Sheer programmer's curiosity?

In reply to by [DELETED] 1831606

Well, it's not as simple as that - I don't know that part of the code at all. It's already reaosnably obvious to me what is going wrong - somehow, the code that tries to decide the correct spelling for each pitch based on the key is not seeing the correct key. But that won't in itself tell me *why* the key is not known, and it would require an awful lot more of analysis and stepping to figure that out.

Would it be possible for you to construct a simpler example? Like, a single staff, single measure, single note?

Realistically, as I said, this is a job better suited to someone who understands the MIDI import code better. If I were you, I'd simply file a bug report to the issue tracker and include this file, or better yet a simpler one that exhibits the same problem, so someone better suited to fixing this can look at it. But I'll still try if you can find a simpler example.

In reply to by [DELETED] 1831606

Just click the "Issue tracker" link in the menu to the right of this page, then click "Create a new issue" at the top of the page. After that it's just a matter of filling out the form. Select "MuseScore" as the project, "Code" as the component, and "bug report" as the category. Leave the other fields at their defaults (hmm, why aren't MuseScore / Code / bug report the defaults as well?).

I'm curious to see if it turns out to be all MIDI files created by Personal Composer that have this whatever-it-is going on, or if it really is something more specific than that.

(edited)
I have some more news here; open the same file (omb2.mid). Click "concert pitch". The English Horns show up in F, not E (as they should). This is clearly wrong, and gives a clue. The "properties" on the staff says "perfect fifth down", but that's not what the key signature says, one flat instead of four sharps. This may have a lot to do with it -- the bad accidentals in the concert pitch part are consistent with F major.

In concert pitch mode, all key signatures should be the same, no?

As a matter of fact, the key signature of the English Horn in NON-concert pitch mode should be B, (as it is in tpc2), not the E that appears! It is as though the importer confused the concert-pitch and non-concert pitch.

In reply to by [DELETED] 1831606

It's worse (or maybe better?) than that. Press Concert Pitch again and the key signature for the English horn staff does not return to E (which was wrng in the first place) - it turns to C, which is the correct transposition for F concert. This is what I meant in my response a while back when I said "Without knowing much about the internal structure of a standard MIDI file, I'm going to guess the problem with this file is related to whatever is going on to cause the English horn to have a different key signature than the rest of the stave s- and not the key signature you would expect just because of its transposition". Somehow there seems to be a conflict between the overall key signature for this file and the staff-specific key signatures, and that's what made me suspect the file itself was doing something very unusual. Because my simple example with flute & English horn does fine.

Do you still have an unanswered question? Please log in first to post your question.