musicxml export generates wrong measure length
Reported version
3.0
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
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 |
Fix version
3.2.0
Comments
I'm not sure what the original looked like, but open it in 3.1, which was just released. I looks good to me there.
Most probably the fraction change inside 3.1
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
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
Went back to factory settings, but the error message is still the same.
my test rest,mscz has only 2 measures. Are you shure you are looking at the right file?
time for me to get away from my keyboard... post above corrected
This needs to be tagged as related to musicxml.
In reply to (No subject) 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.
It is an export problem, the score doesn't have that rest, the export assumes/adds that for some reason, and wrongly
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 Let me clarify my previous… 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.
In reply to So let me try to clarify my… by manfrhahn
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.
Just checked, the fix is indeed trivial.
https://github.com/musescore/MuseScore/pull/5083 fixes the corruption. Instead of a single backup, a backup/forward pair is still generated. This causes no harm and is more difficult to fix.
Fixed in branch master, commit ae857f5573
fix #289819 - musicxml export generates wrong measure length
Fixed in branch master, commit 9cac3b0035
_Merge pull request #5083 from lvinken/289819-musicxml-wrong-measure-length
fix #289819 - musicxml export generates wrong measure length_
Automatically closed -- issue fixed for 2 weeks with no activity.