Odd handling of beams in certain MusicXML files

• Jul 18, 2021 - 22:53

This problem arises when a MusicXML file is exported by Encore from a file having two or more voices active in a measure in which there are beams.

When the file is imported into MuseScore, at first the beams are not present. But applying Format>Reset Beam puts them in place.

A similar oddity does not take place with a MusicXML score from essentially the same score generated by Overture or MuseScore itself.

Testing suggest that the difference in behavior comes about because of a difference as to the sequence in which the notes of the two voices in a measure are encoded. In Encore, the encoding ziz-zags between the notes in the two voices, short <backup> elements being used frequently. In Overture and MuseScore, all the notes in the measure in one voice are encoded, following which there is a big <backup> element, and then all the notes in the measure in the other voice are encoded. I'm sure both schemes are "legitimate".

The attached MusicXML file, generated in Encore, should exhibit this oddity when imported into MuseScore.

This odd behavior is certainly not debilitating, as it is so easily corrected. But it is disconcerting.

Best regards,


Attachment Size
Beams and voices 1004M.xml 9.63 KB


I recently imported an Encore generated MusicXML file. And indeed, it was a two-voice score.

UPDATE: I've deleted a section of my original post where I mentioned that, on MusicXML import, notes were swapped between V1 and V2. But that appears to have been entirely in error. Sorry for any confusion!!

I immediately noticed that the resulting Musescore document contained a sea of flagged eighths rather than properly beamed groups as found in the original. Thankfully that is easily rectified by running Format>Reset Beams.

So yes, I've got easy workaround. But I think it would be far better if Musescore handled the import with greater panache. Doug Kerr and Leon Vinken have fixed the problems related to Encore's use of the MusicXML element—which results in an unmanageable mess on import. Once MuseScore commits Leon and Doug's fix, Encore MusicXML score import will be less problematic However, It should be know that, pre-export workarounds exist within Encore—but one has to be in the know and take steps to set modify score playback:

Measures>Align Playback: This quantizes the start time of selected note match the literal onset according to the note's face value.
Notes>Change Duration>Set play duration to 100% and uncheck Set Note Duration (i.e. face value)

In a similar way, why not roll out the welcome mat for the newcomers by fixing this beaming issue?

Imagine the hapless Encore refugee using Musescore for the first time, expecting this on import:

     Encore import expectation.png

... but finding this:

     Encore import result.png

The seminal and once-thriving Encore has a large community of scorists looking somewhere to go. I think Musescore is the place.

But Musescore has to convince Encore refugees that Musescore is a viable alternative by providing a good experience in their first few minutes. Likely a new use explores two avenues in their first minutes:

• 1) poking around the interface to see how one creates a score from scratch
• 2) importing MusicXML files generated from scores created in other notation applications.

Regarding 2) MuseScore needs to provide a clean bridge to Musescore via MusicXML so Encorians can easily leverage their existing scores into a new and better incarnations in MuseScore. Fixing beam import would be another step in that direction. And Encore users will confidently conclude, wow, that was easy. And they can immediately begin exploring Musescore from the perspective of a working score they're already familiar with.


The simple explanation is that the "big backup" encoding is the recommended practice and different encodings have not been encountered often enough for me to support them in MuseScore.

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