MusicXML error message

• May 15, 2021 - 03:38

MuseScore considers the MusicXML element <duration> to state the musical time that should be allocated to a note. I consider this to be inappropriate, but that is a topic for another thread. For this thread, I will proceed based on the way MuseScore works now (version 3.6.2).

When a MusicXML file is presented for import, the MuseScore syntax validator adds up the musical time values of the <duration> elements for all the notes in a measure, and matches that total against the asserted musical time length of the measure as given by the encoded time signature. If they do not match, we get an error message, like this:
MXML_error_message-01.jpg
It seems to me that the language here is backward. With a 4/4 time signature, we should expect 4/4 worth of notes in the measure.
In this example, all the <duration> elements add up to 3/4. So I would think that the message should be: Expected: 4/4; found: 3/4

Best regards,

Doug


Comments

HI Doug,

This does appear to be an erroneous error message ... given that the MusicXML you submitted expresses the meter as 4/4:

 < time>
 < beats>4
 < beat-type>4
 < /time>

scorster

Apologies for the space added after each opening <
I made other attempts to get the XML to display as literal text, but those failed.
For future purposes, can anyone explain how to do so?

It's important to note this message doesn't come directly from the MusicXML import facility, it's a general message that applies to any score. It means that at the point the error check was run, the measure claimed to have a duration of 3/4 (in this case, apparently the MusicXML imported must have set the actual duration that way, which you can verify using Measure Properties) but there are 4/4 worth of notes present in the measure. So the message is accurate - the contents of the measure are 4/4 but 3/4 was expected because 3/4 is what the imported said it should be.

The question is, why did the imported say the measure should be 3/4 if it isn't, but it sounds like you have a handle on that.

In reply to by Marc Sabatella

Hi, Marc,

In fact, in the instant case, the length of the measure was declared (by the encoded key signature in the MusicXML code) as 4/4, but the "content" of the measure as judged by MuseScore (from its interpretation of the values of the elements of all the notes in the score) was only 3/4.

For the specific test case involved, Measure Properties for Measure 1 shows this:

Duration_test-2003-02.jpg

Thus my view that, in this situation, the language of the error message is inverted.

Thanks.

Doug

In reply to by Doug Kerr

Again, the message is simply reporting what the importer did/ We can't lie about that or else the same message would be wrong for all the other cases. The issue is that the importer changes the duration of the measure when you didn't want it to, but the message is correctly reporting that fact. Whether or not the importer should have changed the duration I can't speak to, as I don't understand those intricacies. I am just saying, the message is absolutely correct about what it reports the importer has done. So if there's an issue, it's not with the message, but with the importer.

In reply to by Marc Sabatella

Hi, Marc,

You say:

"The issue is that the importer changes the duration of the measure when you didn't want it to"

Not so. In the example, I started out in the source score with a 4/4 "long" measure, the time signature in the MusicXML code is 4/4, and the measure length reported by MuseScore for the reconstructed score is 4/4. Nothing changed that along the way that I can see.

What MuseScore (perhaps by virtue of the working of the importer) judges to be the content of the measure (owing to differing views between Overture and MuseScore as to the significance of the MusicXML <duration> element) is 3/4.

Clearly we disagree as to whether the wording of the error message, as it pertains to this example, is apt. Fair enough.

As an aside, I consider that the "disagreement" between Overture and MuseScore I alluded to above is (mostly) Overture's faux pas.

Doug

In reply to by Doug Kerr

To give a very succinct overview of the "disagreement" of which I spoke above.

Overture takes the view that the MusicXML element <duration> defines the play duration of the note.

MuseScore (and by this I mean the importer plus the program proper, as I do not known the division of labor here) takes the view that the element <duration> defines what I will call the "musical time allotment" of the notes. This is the amount of "musical time" consumed by the note. In MuseScore's case, this is not necessarily the amount of musical time implied by the note symbol (what is called in music theory its time value).

Thus, if we have in a 4/4 measure four quarter notes, but for each its <duration> has a value that corresponds to 3/4 the length of a quarter note, then in the reconstructed score, MuseScore will start the quarter notes at intervals of the duration of a dotted eighth (3/4 the duration of a quarter note). The result of this is rather bizarre, especially since MuseScore then sounds each note for a duration corresponding to its full time value (quarter note in this case). On the other hand, I consider that encoding to be inappropriate.

The discussion of this whole matter in the MusicXML Documentation does not allow this difference in outlook to be clearly resolved.

After an extensive study of this topic (in which many conundrums were encountered), I conclude that the "intended" significance of the element <duration> is simply an alternative way to define the note symbol (and thus its time value), the other way being by way of the <type> element (which is in fact optional).

Thus, if for a note both <type> and <duration> are present, <duration> should just be ignored. If only <duration> is present, its value should be used to select the symbol for the note (and thus its time value), rounding as seems "appropriate" to be used in doing so.

I realize that this seems quite silly, but that's the way it comes out to me.

Doug

In reply to by Doug Kerr

I note that if, as I recommend, a program generating a MusicXML file included the optional <type> element in each <note> element (as well as the mandatory <duration> element), always making the value of <duration> consistent with the note symbol specified by <type>, the error message discussed above upon import of the MusicXML file into MuseScore will not occur.

Workers in Overture (remember Overture?) planning to transport scores via MusicXML into MuseScore can avert the error message and the ensuing bizarre score construction in MuseScore by setting the play duration of all notes to "100% of face" before generating the MusicXML file. This will cause the <duration> elements to all have values implying the same duration as implied by the note symbol specified by <type>.

Doug

In reply to by Doug Kerr

The score you posted clear has 3/4 as the "actual duration" of the measure. You were saying (and I took your word for on this) that the MusicXML file actually specified 4/4 as the duration. That is the thing the importer apparently changed. Again, I don't really understand the details. I'm just saying, looking at the actual score as actually imported, it's a measure with an "actual duration" of 3/4 but it has four beats in it. That's the absolute truth of the situation, and hence the absolute truth of the error message presented.

In reply to by Marc Sabatella

Marc wrote >> the MusicXML file actually specified 4/4 as the duration. The score you posted clearly has 3/4 as the "actual duration" of the measure.

Yes. That's the crux. The importer missed the meter declared in the MusicXML beats element. The score should open with all measures having:

• Nominal duration = 4
• Actual duration = 4
• and of course, with the beat-type = 4 (which is correctly imported)

Are you saying we can have a more coherent conversation once that's fixed? I don't see how the importer can proceed intelligently report measure errors if it's got a mistaken notation of the "size" of the measures.

scorster

In reply to by scorster

It didn't miss the beats declaration at all (and shows the correct time signature).
What it did was total all durations and those only add up to 3/4ths of the measure, so it is missing 1/4th in duration.

Keep in mind that Doug posts and investigation is all about how he proposes the duration and type element should be interpreted and how it differs from how that happens currently.
Currently the import process expects the sum of all "durations" in a measure to equal the measure duration and it shows such a corruption message when this isn't the case (as in the provided example).

In reply to by scorster

To be clear: the importer is not what reported the error. It built the measure, set its properties, put the notes into it, and then asked the main MuseScore code to check the resulting score. It is that main MsueScore code - the same code run on any score upon open, not just scores that happen to result from MusicXML import - that is reporting the error.

So again, MuseScore is correctly reporting the news here regarding the score that the importer created and presented to the main code. That score absolutely does have the actual duration set to 3/4, and it absolutely does have four beats worth of notes in it. That is an error, and MuseScore accurately reports that.

So yes, if it's in fact the case that the importer should not have created the score this way based on the MusicXML, that's certainly the conversation to have next - why did the importer create an incorrect measure. Here, though, I would have to defer to someone who understands MusicXML and the importer logic better. I have no insight whatsoever into what should have been created here by the importer. I just know that what actually did get created has exactly the problem that MuseScore is reporting: a 3/4 measure with four beats.

At least, all this is true if you believe the raw durations that are presented (four apparent quarter notes). As per the comment in the score, the durations are scaled somehow in a way that in theory could have been represented accurately (as a quartuplet, for instance, or as a "local" time signature). Again, I don't understand enough of MusicXML or the importer to say how this should have been encoded. I can just say it wasn't encoded in a way that avoided the error.

In reply to by Marc Sabatella

Hi, Marc,

This is all true, and well said.

My concern is that the language of the error report seems inverted. But it may just be that I don't understand the background of the terms used.

Indeed the encoding used in the test MusicXML file, and the importer's interpretation of it (which, together, led to this error report), is a quite separate (and rather convoluted) matter. I think my outlook on this is covered in the Technical Note I recently posted here.

Doug

In reply to by Doug Kerr

Again, to summarize the actors in this drama, in the test MusicXML file:

• The time signature is declared as 4/4.
• In each measure we have four notes, whose <type> elements identify them as quarter notes.
• For each note, the <duration> element states a musical time 3/4 that of the time value of a quarter note.

Now what is the "content" of each measure? Is is 4 quarter notes worth of musical time (since we have four notes, for each of which the time value is that of a quarter note)? Is it 3 quarter notes worth (since the sum of the four <duration> elements sums to 3 quarter notes' worth of time)?

And what is the "length" of the measure defined by this MusicXML code? Is it 4 quarter notes' worth, since the time signature is declared as 4/4 (but maybe that is only a "mark")? Is is 4 quarter notes' worth, since the content of the measure is four notes, each of which is a quarter note? Is is 3 quarter notes' worth, since the sum of the four <duration> elements sums to 3 quarter notes' worth of time?

And which of these values do we think of as "expected" and which do we think of as "found"? Do we have three pounds of potatoes in a four pound bag? Or do we have four pounds of potatoes in a three pound bag?

This is enough to make an old geezer's head hurt (I was 85 the Monday before last).

Doug

In reply to by Doug Kerr

Hi, Marc,

OK, I get it.

MuseScore reckons the length of the measure from the total of the <duration> values (3 quarter notes worth in the case of the example). (And if we proceed, it indeed makes the "working length" of the measure that value.)

Then it reckons the "content" in terms of the total of the time values of the notes. That is 4 quarter notes worth in the case of the example.

Thus it reports: expected 3/4, found 4/4 (which now makes sense to me).

I think perhaps the term "incomplete" is not appropriate for a measure that is "overfull", as in the example. Perhaps "not filled properly" would better take case of errors in either direction.

In any case, the encoded time signature is not involved in this matter.

Thanks.

Doug

In reply to by Doug Kerr

Now, back to the other matter.

Overture's encoding of <duration> to reflect the intended play duration of the note is, in my opinion, inappropriate. (And I work on that in another, bizarre world, inhospitable to sentient humans, which ain't easy.)

In fact. my belief, strange as this may seem, is that <duration> should give, numerically, the note symbol (and thus time value) which is also given as an enumerated text value by the element <type>.

Then what if (as in the test file) the values of <type> and <duration> are both present (<type> is optional under the syntax specification) but inconsistent? If both are present I recommend that the receiving program ignore <duration>.

Doug

In reply to by Doug Kerr

Doug Kerr wrote>> If [values of < type > and < duration >] are present I recommend that the receiving program ignore .

Thanks Doug,

I believe that perfectly summarizes a simple solution regarding the import of Overture generated MusicXML.

Oh I see @Leon Vinken is on this:

"MuseScore's MusicXML importer using note duration instead of note type to determine how long a note takes and thus where the next note starts. As far as I can tell MuseScore in principle cannot handle cases where these two don't match" ...

"I plan to provide a pull request that causes MuseScore to calculate the note duration based on the type instead of the duration. This will completely prevent this issue from occurring, as far as I know without any regression."

Sounds like a good call. Thanks Leon!

scorster

IMHO, this results from the combination of two things:
- MuseScore's MusicXML importer using note duration instead of note type to determine how long a note takes and thus where the next note starts. As far as I can tell MuseScore in principle cannot handle cases where these two don't match
- Overtures (ab)use of the MusicXML duration element to specify the play duration of a note (instead of using the attack and release attributes which would be required according to my interpretation of the spec)

I plan to provide a pull request that causes MuseScore to calculate the note duration based on the type instead of the duration. This will completely prevent this issue from occurring, as far as I know without any regression.

Note that I will not comment on the wording of the error message (I leave that to native English speakers) and on the completeness of MuseScore's validation of its internal data after import (which could be improved).

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