musicxml export generates wrong measure length

• May 28, 2019 - 16:16
Reported version
S4 - Minor

Steps to reproduce:

Load the 'test rest.mscz' into musescore 3.0 (two measures of Mozart's piano sonata nr. 11)

export the score as .musicxml

open the .musicxml-file in MuseScore results in an error 'File ... corrupted'
with detail 'Measure 1, staff 1, voice 2 too long. Expected 6/8; Found 7/8'

Reason is a generated rest for voice 2 with a length of a pointed half (3/4 = 6/8) instead of 5/8.

MuseScore 3 does a <backup> of 24 durations - the whole measure - and
has to generate a rest that is not shown in the original .mscz score.
MuseScore 2 did a better job by <backup> only 4 durations from the last note of voice 1
and omittes the generation of an unneeded rest.

Attachment Size
Test rest.mscz 8.88 KB


Status fixed active

Hmh, used version
Added the exported musicxml
Tried the export import thing again
The same error as described
Are there any settings or program property file I can add?
Please compare the musicxml file with the version you created

Attachment Size
Test rest.musicxml 25.75 KB
Fix version 3.1.0  

Sorry, misunderstanding, I though the score you attach were corrupt, not the ex- and then imported musicxml

Indeed a corruption:
Measure 1, staff 1, voice 2 too long. Expected: 6/8; Found: 7/8

In reply to by Jojo-Schmitz

This is NOT a MusicXML export problem. The debugger shows a dotted half rest with duration 5/8 at beat 1 in voice 2. The note value and duration obviously do not match. The MusicXML importer assumes the note value is correct and the duration incorrect. This results in the rest being 1/8 larger than expected and the A4 in voice 2 moved.

Let me clarify my previous remark: the score actually does contain an element of type Rest at beat 1 in voice 2. It might not be considered a "real" rest, as it is represented in the MuseScore file as a "location" element instead of a rest and it is never shown in the score as presented by the GUI. This rest is created by Measure::fillGap().

@ manfrhahn's remark has cause and result switched: the backup of 24 is required to be able to write the rest.

This results in two problems:
- gaps in voices are converted to visible rests by exporting to MusicXML (I seem to remember this being reported previously)
- if the required rest length cannot be represented by a single rest, the MusicXML file's timing is corrupt

Will look for a workaround in the MusicXML export.

In reply to by Leon Vinken

So let me try to clarify my remark also: In my opinion the rest must not be written. Coming to the end of the measure with voice 1 a <backup> of 4 would give the position to write the A# of voice 2 without any rest. MuseScore 2.0 worked this way. Since there should be no rest the <backup> of 24 is NOT required. This is a statement from the musicxml point of view, I don't know nothing about the internal book keeping inside of MuseScore.
To show what I mean I corrected the musicxml manually. This file is imported without error and doesn't show a rest.

Attachment Size
Test rest corrected.musicxml 25.59 KB

In reply to by manfrhahn

Regression No Yes

Looks like we all agree on this, no need for further discussion. What has happened is that in the past, gaps in voice 2 and up were empty (literally, even no rests were present). Some time ago (don't know when) this changed and now gaps are filled with rests marked as "gap". The MusicXML exporter did not get updated for this and simply exports all rests it encounters.

I expect a simple fix will be possible, something like adding "if (!rest->isGap())" somewhere. Once again, I will look into this shortly.

Fix version