MusicXML exporter of Musescore generates inaccurate data

[mxAlexG]

Hello,
I am using an excellent library that has the capability to import mxl files. However, the problem I noticed is that the files I download from musescore.org contain meaningless voices data- possibly other concerns too.

For the piano, I noticed the bass clef notes being given a random value of 5 by default. In other instances, the files contain multiple notes with sequential numbering (1,2,3,4) with no way to discern whether this is just the exporter module not being consistent or it's actually intended by the author of the file. They sometimes don't contain enough data to constitute a valid note that the importer's parsing logic can make sense of.

I think this is a serious issue because whatever is exported ends up being part of the large scores library hosted on your .org site, which means other apps can barely benefit from this, and consequently, this becomes detrimental to the ubiquity of the format.

[MarcSabatella]

I could be mistaken, but I assume the reason the bass clef of a piano part starts with voice 5 is that each staff can have up to four voices. So the voices are assigned sequentially in a way that means the assignments don't change if you later add more notes. And the four voices on each staff - the voices actually assigned by the editor of the score - are converted directly into voices. So unless you have a specific example where you think the MusicXML does not correctly reflect the content of the score, this isn't garbage, it's perfectly normal and legitimate MusicXML as far as I know, and any importer should be able to understand it. Are you saying you know of a specific program that fails to handle this?

[mxAlexG]

Hello,
By garbage I am using the word in the computing sense. I apologize if it sounds demeaning.
I am basing my point of view on some of the replies found here by I believe people who are contributors:
https://musescore.org/en/node/295100
Personally, I simply grouped the notes by pitch and discarded ones with multiple voices, so it's no longer an issue for me. All I wanted is to pinpoint that.

Thank you for the response.

[MarcSabatella]

I'm not sure what that thread has to do with the subject here, but anyhow, yes, I understood you to be trying to use the computer sense of the word "garbage". And as I explained, it isn't. "Garbage" would imply would imply the voice values are random - that the value of 5 for the first voice of the second staff was the result of an uninitialized variable or a bad pointer reference, rather than a simple and logical algorithm based on a legitimate design choice.

Voices are assigned in the manner I described - 1-4 for staff 1, 5-8 for staff 2, etc. I don't think there is anything in the MusicXML spec that disallows this, and certainly every MusicXML importer I know of handles this without a problem. So again, I'm trying to understand what you perceive the actual issue to be. Everything works as expected and in accordance with the spec as far as I can tell.

That's not to say an alternate algorithm that always assigned voice numbers sequentially wouldn't also be possible to implement someday. But since the MusicXML spec doesn't require this as far as I know, any standard-compliant importer needs to handle voices that are not assigned sequentially.