incorrect beams info interpretation in reading xml file

• Jan 21, 2022 - 09:39
Reported version
S3 - Major

When importing an XML file, MuseScore shows many notes, that are supposed to be connected with the beam, without it.
To check that the it wasn't an XML file issue, I had the same XML file imported in Harmony Assistant and it shows the notes correctly with the beam.
The XML file was generated via SmartScore 64 PRO, which also shows the notes correctly.
See the attached XML file.

Attachment Size
b.xml 2.39 MB


EDIT: I just realized the specific info I gave about line numbers etc is about a different file, the one attached to the forum post, but I assume it's probably the same issue - a backup tag in the middle of a beam apparently confusing things.

Will be interesting to see what Leon or someone who understands the MusicXML spec better than I do says. I looked at the score in MuseScore and see what I assume you are talking about - measure 2 of part 5 has notes in voice 2 that look like they should be beamed but aren't. In the MusicXML that measure starts at line 52853. I see beam tags, a start for the first dotted eighth of voice 1, an end for the sixteenth that follows, as well as a backwards-hook on the latter. Makes sense to me, but there is also a "backup" tag between the two notes to get the second voice in. i think that's what is confusing things. I tried manually rearranging things so the two beamed notes in voice 1 came first in the MusicXML file, then the backup, then the two voice 2 notes, and now the beams show for those notes.

So my tentative conclusion is, the backup tag doesn't work well in the middle of a beamed group. Whether it should or not I cannot say.

In reply to by Marc Sabatella

Marc's analysis is correct, MuseScore's MusicXML importer assumes all notes in a voice are consecutive in a MusicXML file. This is not required by the specification but was recommended in the MakeMusic MusicXML forum. Unfortunately, some exporters do not conform to this recommendation which breaks beam import.

In technical terms: the importer maintains a beam state for a single voice instead of for all possible parallel voices. See variable Beam* beam in function MusicXMLParserPass2::measure(). Fixing this is relatively easy.

Note that similar issues are present in grace note and tuplet handling.

Frequency Once Few
Status active duplicate

Source code for trivial MuseScore 3.x fix available in…. Consider this proof of concept, the fix still requires some cleanup and still has to be ported to the master branch, for inclusion into MuseScore 4.0.

Result of importing file b.xml into Finale NotePad and MuseScore 3.x (with fix) attached.

Note: this is a duplicate of #323168: Issues with beaming when importing Encore generated MusicXML

Attachment Size
b_FN.png 444.67 KB
b_MS.png 101.54 KB

No need to adapt my fix. After I built your PR #9000 to my surprise I found the issue does not reproduce. Turns out it already contains a very similar fix:

commit ab07adef66673433e3cd9f1a78da3d6e84213295
Author: iveshenry18
Date: Fri May 14 20:11:03 2021 -0700

ENG-17: Fix beams in multi-voice MusicXML import

The presence of a second voice would prematurely break
beams upon MusicXML import in some cases, as only one beam was
stored at a time as the "current beam", and this would get thrown away
if a note in another voice/track was handled before the end of a
beam. This commit adds a QMap to store one beam *per voice* at a time,
avoiding the conflict while retaining the existing logic.

Port of #8108, part 3

Note that this fix is not yet present in master (will take care of that) and I don't know why I did not find it in the issue tracker.

Did some digging on Github, it seems MusicXML import was improved for the backend, but (some ?) updates did not make it into 3.x or master. Now I don't know if it makes sense at all to work on MusicXML :-(.

Thanks for the reference to PR #9581, I did not notice that one.

My main worry here is potential wasted time, investigating issues that have already been solved in the backend. I would very much like to see the status of backend fixes. A simple reminder in an issue in the issue tracker would do.

Yes, I did complain about those "ENG-xxx" internal issue tracker back then, as being counter-productive, esp. in an Open Source development. After that the internal team switched to using GitHub issues, at least for the problems with master