Mangling of enharmonics by 2.0.0

• Mar 26, 2015 - 16:42

Open the enclosed score. Worked perfectly in beta 2. Looks good, ... but ..

Save a copy and open the saved copy: All the non-default accidentals are enharmonically corrupted. This is a pretty big issue, as it undoes copious laborious work (on many scores). Whatever it is, this is urgent.

(and I can't go back to beta 2, because it now (since I installed 2.0.0) crashes on startup.)
(Mac Yosemite).

Attachment Size
kyrie2.mscz 56.01 KB


This score is already "corrupted" in that while these are concert pitch instruments, they have different enharmonic spellings for concert pitch versus transposed. This probably happened in beta 2. A fix was made to correct this corruption when saving in the final release - the same spelling is always used for both. But unfortunately, it means that depending on which of the two incompatible spellings you actually meant, there is a chance MsueScore will settle on the "wrong" spelling.

There are several different ways this corruption could have happened in Beta 2, but only one I know of that it can happen in the final release: use of the "J" command on a concert pitch instrument while not in concert pitch mode. See #51886: Enharmonic change made using "J" on concert pitch instrument not saved. This is a very unfortunate situation indeed, but luckily, also simple to workaround for future scores: if you use the "J" command for whatever reason with concert pitch instruments, do so in concert pitch mode. Unfortunately, for scores like the above that were already corrupted by this or by other bugs in earlier builds (there were actually a number of these that were fixed for the ifnal release), I'm not sure there is any way to automatically correct for this.

I propose that we fix the one remaining source of this corruption in 2.0 by making "J" always affect both the concert pitch and transpose spellings no matter which mode you are in, even though its *usual* purpose is specifically to allow these to differ for transposing instruments.

In reply to by Marc Sabatella

Well, that's pretty unfortunate indeed; it worked in the past by accident and no longer works since it's been fixed. Nor do I understand why transposition is relevant here -- there is not a transposing instrument in any of my many scores. Nor have I ever used "concert pitch" mode -- are you saying that I have to use this mode in order to ensure accurate explicit specification of enharmonic spellings?

You are telling me that the "J" key doesn't work -- I read that elsewhere here. All I want to do is specify the correct spelling of a note, or change it to be correct, and be sure that is saved correctly, will read back correctly, and copy correctly.

What are the proper gestures and modes to specify and correct persistent spellings, and to correct invalid beta version spellings? Can I fix the scores I have by hand, or do they have to be re-entered?

(later) I see- there are two versions, if I say "concert pitch" I get the bad version, and "not concert pitch" gets the "good version". Is there no way to recover the "good version"?

When I say "copy the score to a new file", why doesn't it write out both versions?

Is it possible to find all this information in the MusXML? I'm willing to write tons of python scripting to recover my scores.

Do you have any idea why beta 2 now crashes? I would like to go back to Beta 2 if I could.


In reply to by [DELETED] 1831606

Transposition is relevant because as I said, the main purpose of the "J" command is to allow you to have *different* spellings of a note betwene concert pitch and transposed modes. So for transposing instruments, it is normal and proper that MuseScore allow you to do this. For concert pitch isntruments, hwoever, there is no reason in the world for MuseScore to allow you to do this. Your score is, as I said, already corrupt. Load it into 2.0, press the concert pitch button, and you'll see all those same spelling changes happen. And Beta 2 would have done the same.

So again, the score is *already* corrupt - it was corrupted by Beta 2. Shortly before the release of 2.0, code was added to 'fix" these corruptions on the next save operation by forcing concert pitch instruments to have the same pitch in both modes, which is how it should have been in the first place. There are two different values stored in the score because of this bug in Beta 2, so MuseScore 2.0 is picking one of them and throwing away the other to un-corrupt your score. Unfortunately, in your particular case, it just happens to choose to keep the "wrong" value (the one you didn't want it).

One question I have for you, then, is to ask if you have any idea how the score *got* corrupt in the first place. Did you perhaps enter this via MIDI then use the "J" command to change spellings? If so, then my proposed solution will indeed prevent this from happening in the future. If the corruption was caused by any of the things that we've already fixed - bugs in MusicXMl import, Capella import, etc - then there is nothign to worry about. If Beta 2 caused the corruption due to some other bug we don't know about, though, it would be nice to find out so we can fix it.

And for now at least, to correct spellings in concert pitch instruments, as I said, simply make your "J" changes in concert pitch mode when dealing with concert pitch instruments. Or, don't use "J", but instead use the method that was the only available in 1.3 - press up then down or vice versa.

As for how to fix scores that Beta 2 has already corrupted, as I said, the code in 2.0 is already *trying* to fix it. It just doesn't know which of the two different spellings you actually wanted, and it got unlucky this time. But it's certianly possible to try to fix it yourself. If you open the MSCZ file in a ZIP program, you'll see within it an MSCX file that is plain text in an XML-type format (not actually MusicXML). You'll see the problem notes have both a "tpc1" and "tpc2" too. Currently, MuseScore 2.0 is throwing away one of those when writing the file. I think you need to instead throw the *other* one away. And then convert the other to just "tpc". Something like that. Compare the "before" and "after" versions to see.

Meanwhile, I'm investigating alternatives that hoepfully will make their way into a nightly build soon. My guess is we will have something figured out soon.

BTW, you don't want to go back to Beta 2. Not only will it continue to create corrupt scores like this that are just a problem waiting to happen, but it has hundreds of bugs far worse than this easily-worked-around problem. And your scores won't be fully compatible with anyone else. So don't bother trying to get that working - you'll only regret it later.

In reply to by Marc Sabatella

This is terrific. I have to study this and the mscx. More when I have. Thank you so so much.

Confiteor. I used "J" on scores imported from Midi. From 1995-2003, I used "Personal Composer" on Windows. It was pretty good actually (had performance controls that MuseScore doesn't), but had no export to any other format, on purpose (the vendor did not want people leaving). They have gone out of business, whereupon I have largely succeeded rescuing major scores I entered (my own works as well as repertoire, mainly large Bach choral/orchestral movements) via the only path possible, MIDI, which, of course, loses not only spellings but multiple parts in one channel/staff. I have spent dozens of hours "recovering" such scores, and J was a key and very powerful tool.

I see now that every one of my scores has a "Doppelgänger" visible when "concert pitch" is pressed, which re-introduces every error ever corrected with a "J", even if the score was fresh and not from MIDI. For midi-recovered scores, it sends a chill down the spine.

I will start investigating the XML, but there "oughtta" be a way of "recovering" your own "good" score from itself; surely, I am not alone. if I produce useful scripting, I'll gift it to you.

By the way, Midi import TRULY needs a key-signature recommendation, i.e., not mess up (for the most part) in the first place (yes, works often have G# and Ab both, etc, but the bulk.).


In reply to by [DELETED] 1831606

FWIW, I just implemented and am testing a fix for this. I have it so "J" always affects *both* concert pitch and transposed mode, but "Ctrl+J" affects just the current mode. Thus "J" would be the command to cintue using to correct MIDI input; "Ctrl+J" would be what you'd use when you want the two modes to use different spellings as it is often the case when writing for transposing instruments (choose concert pitch spelling based on what is theoretically correct; choose transposed spelling based on readability).

I have also temporarily backed out the "fix" for the corrupt scores that caused the "wrong" spelling to get preferred. However, that just means that already-corrupt scores remain corrupt; it just won't matter so much. Unless you switch to concert pitch mode, you'll remain blissfully unaware of the problem lurking there. I suspect Werner is not going to approve of that, in which case, I'll argue to find a way to better guess which of the two incompatible spellings to keep, because it's clearly the wrong one in this case.

BTW, I would love to tell you a workaround to fix corrupt scores would be to select the score while concert ithc is off, copy, then turn concert pitch on, and paste. However, the same issue prevents this from working, since copy & paste uses the same code as read / write.

Anyhow, one way or another, this should be licked in nightly builds soon.

Oh, and what do you mean about "key-signature recommendation"? It should already be the same that MIDI import tries to spell what it thinks will be the correct according to key, but of course, that's not really possible. Are there spoecific cases where you are disagreeing with its choices? What happens if you select that passage and choose Notes / Respell Pitches?

In reply to by Marc Sabatella

Thank you so much for these tremendous planned improvements. That will help a lot.

It has been my experience that no matter what the key signature in the midi itself, midi imports notate F# C#, G#, Bb, Eb. Works great for G minor movements, except for the occasional Ab, but E major movements need a lot of work. The choice of the spelllings should be based on the key signature. Has this changed recently?

In reply to by [DELETED] 1831606

Well, MIDI import probably ignored keys in 1.3, but it definitely works pretty well from what I can tell in 2.0 - probably started working around the time of Beta 1 or Beta 2. If you have a specific MIDi file where you think the enharmonc choices could be made better, you shoudl start a new thread to discuss it.

But FWIW, I just created a score in E major - the key you said required a lot of work - and entered an E major scale followed by the five notes not in that key. What I got back after MIDI export / import was a correctly spelled a E major scale followed by the five non-diatonic notes, spelled as E#, G, A#, B#, and D. This is consistent with how notes are spelled in other keys: #1 is favored over b2, b3 over #2, #4 over b5, #5 over b6, and b7 over #6. The algoirithm is simple but effective: we prefer the spelling that is more closely related to the key. #1 is only two steps away on the circle of fifths, whereas b2 is four steps away. And so on. So as far as I can tell, spelling *is* based on key signature in exactly the way one might expect without actually getting into some sort of artifical intelligence to analyze the harmonic structure measure by measure.

So again, if you have a specific MIDI file where you are seeing soemthing different, or if you think this isn't the optimum algorithm, please start a a new thread with a sample file and discussion.


If you have an entire passage, nay, an entire score, in which enharmonic spellings are -consistently- wrong, selecting the ENTIRE PASSAGE, all voices, and do "down, up!" arrows (assuming "too flat" errors) (in "concert pitch" mode), every single misspelling gets fixed and nothing else is touched! This reduces the pain and the work of these problems by orders of magnitude.

In reply to by [DELETED] 1831606

I'm having difficulty absorbing what all of this means as a practical matter - but it seems very alarming. I use MuseScore 99% of the time for piano solo music. I never heard of the 'J' shortcut before, and I never paid attention to whether I was in Concert Pitch mode or not because I thought it was irrelevant.

I've had no problems like what's been described. Is that just dumb luck, or should I be doing something differently? Could someone distill what's in this thread into clear and concise guidelines for engraving scores that do - or do not - involve transposing instruments? Or is it already documented somewhere, and I've perhaps overlooked it?

In reply to by [DELETED] 448831

What it means as a practical matter is this: the "J" shortcut is currently broken for concert pitch instruments except when working in concert pitch mode. If you weren't using "J", you have nothing to worry about. If you *do* wish to use "J", and you are creating scores for concert pitch instruments, then until this bug is fixed, do your work in concert pitch mode.

Since I've learned so much about this in the past week, I can now say that both these files (omb2, E major, and kyrie2, F# minor) can be fixed readily in the following way. Go to "concert pitch". Drop the correct key signature on any staff of the score. Mark the whole score with Command-A. "down/up". Everything is now right except some double-sharps which should be naturals, but that's an order of magnitude better than it was.

Every file that has problems like this is either going to be "too flat" or "too sharp", and up/down or down/up will fix it. Files in one or two flats or sharps will not have as widespread problems.

The problem is no longer urgent, but the J command should be taught some manners, as planned (and whatever is in that file trips up your importer).

Once the J command is fixed, there should be a manual page on managing accidental spelling, esp with regards to midi imports.

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