incorrect beams info interpretation in reading xml file

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 https://musescore.org/en/node/328606, 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.

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.

Source code for trivial MuseScore 3.x fix available in https://github.com/lvinken/MuseScore/tree/328629-musicxml-zig-zag-beams…. 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

That code doesn't fit on top of my PR #9000 and I'm not sure how to adapt it.

If you want I can provide a patch relative to your PR (or something like that). Should be easy enough for me.

Yes, please

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.

It isn't in the issue tracker, not in the public one

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 :-(.

Yes, the idea to fix a bug in the backend without fixing it in master at the same time was not too brilliant...
I ported all these backend changes to 3.x in my PR #9000 with a few exceptions, listed in that PR.

See https://github.com/musescore/MuseScore/pull/9581 for some of them being ported to master

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