Request for MusicXML file with incorrectly encoded triplets to be auto-corrected

As the error message says, it seems that isn't a valid MusicXML (3.1) file, there's an error on line 26. It seems your file was exported using MusicXML 4.0 features but nonetheless claims to be version 3.0. Anyhow, MusicXML 4.0 was not released after MuseScore 3.6.2, so no surprise MuseScore doesn't support it yet.

It's hard to say at this point if that has anything to do with why the triplets in this file also seem problematic. Could be this file is taking advantage of some new features there too. But to be clear - in the vast majority of cases, triplets do important correctly, when using supported versions of MusicXML.

For the record, though, the measure I looked at doesn't seem corrupted, there is just an extra beat and a half that is correctly accounted for in the measure properties. You can clear the contents of the measure as needed and remove the extra beats normally (eg, using Measure Properties, or Ctrl+Delete of a specific note or rest).

IIRC MusicXML 4 is in master meanwhile, so would be in MuseScore 4, which means we could mark this issue fixed?

See https://github.com/musescore/MuseScore/pull/10060

Please check whether that fixes this issue

Thanks for reporting this issue.

Analysis:

This is totally unrelated to MusicXML 4.0. The attached file claims to be 2.0 in the DOCTYPE statement and 3.0 in the score-partwise element :-). Do not expect MuseScore 4 to handle this file differently.

MuseScore 3.6.2 reports a schema validation error. This is correct and caused by the incorrect order of the lyric-font and staff-layout elements (they should be swapped).

The real cause of the timing issue is that all triplets are encoded incorrectly: the time-modification is not taken into account for the duration of the notes in the triplets. All eighth notes get a duration of 240 (both when they are in a triplet and when they stand alone). For the eighth notes in triplets the duration should be 160.

MuseScore's MusicXML importer assumes correct durations and is not very intelligent in handling errors. MuseScore compensates for the longer duration by adding hidden / invisible rests. The incorrect duration leads to gaps in the triplets and overfull measures. If anyone has a proposal for improving MuseScore's handling of incorrectly encoded files, I would be most interested. Otherwise, unfortunately, this has to go into the "won't fix" bucket.

Finally, I'd like to know which application produced this file. I kindly suggest you report this issue to its maintainers.

Thanks for the clarification, Leon! I was under the mistaken impression that staff-layout wasn't in MusicXML 3 at all, based on the error message and a quick web search that only turned up hits in the 4.0 spec.

From my understanding of what Leon writes, the file is quite far off from being correct - each and every note in these triplets has a duration of 240 when it should be 160. That's a huge difference, and the thing is, both programs seem to be aware of the error, and nicely make some attempt to fix it rather than simply reject the file. But neither programs what the right answer was - they just know this answer is wrong. So they make a guess at a fix. It seems in this particular case, MsueScore's guess turns out to be wrong and the other programs' guess turns out to be right. Presumably we could change our guess to do what the other program does, but who knows if there are other cases where our guess is correct and theirs is wrong (eg, another MusicXML generator might make the opposite mistake). If so, changing our guess would make this particular erroneous score better but other erroneous score worse. Hard to know without more reported cases which is the more common error.

But, right now, the score is 1-0 in favor of programs making this particular mistake over the opposite mistake. So that's something.

If I'm on the right track, one possible way to implement a solution would be to detect cases where the note durations add up to a more than the measure durations, and in such cases, if tuplets are present, "assume" the error was in the reporting of those durations, and further, "assume" the error was to not take the time-modification into account. Redo the calculation, and if the results add up this time, go with that. And maybe, set a flag and assume a similar mistake will be made on subsequent tuplets in this score.

@fm42, I am aware that several other programs handle this situation differently, I consider it a better solution and I actually already implemented this change (see issue #321751: [MusicXML import] use note type instead of note duration to determine note length and pull request https://github.com/musescore/MuseScore/pull/8429. Unfortunately, this pull request has been mostly ignored for quite some time. Result of import with issue #321751 implemented is attached.

Marc and @fm42, please be aware that ignoring note duration works well in single voice contexts. It may lead to unexpected results in multi voice contexts, as backup and forward are also expressed in duration. Note that many different errors in MusicXML encoding have been observed, it is extremely hard to find out which happen more often and which fixes would provide the best overall result. With the current MuseScore design, I am convinced that it would be better to include the issue #321751 solution than to leave it out.

trat PR has been backported for the 3,x branch and integrated into https://github.com/musescore/MuseScore/pull/9000, so using its artifacts (development builds from GutHib) might help here