musicxml export generates wrong measure length

• May 28, 2019 - 16:16
Reported version
3.0
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore
Tags
musicxml

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.

Remark:
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

Comments

• May 28, 2019 - 19:50
Status fixed ⇒ active

Hmh, used version 3.1.0.7078
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

Reply

• May 28, 2019 - 19:56
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

Reply

• May 29, 2019 - 20:02

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.

Reply

• May 30, 2019 - 11:44

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.

Reply

• May 30, 2019 - 15:41

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

Reply

• May 30, 2019 - 16:12
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.

Reply

Fix version
3.2.0