MusicXML export adds hidden rests, causing voices to go out of alignment (Musescore 3 & 4)
Hi, I was wondering if anyone has been experiencing the same issue: the score is rendered perfectly on musescore.com, however, opening the downloaded .mxl file with musescore 4 results in out of alignment voices. When the .mxl is opened locally, I can see there is a hidden rest at the end voice 1 of measure 191, but on musescore.com, it appears that the hidden rest has no effect at all and is not observed. This is happening for many other measures in the same score as well.
This is how the measure is rendered on musescore.com:
This is how the measure looks like with musescore 4 locally:
This is causing the score to show up differently when opened locally than on musescore.com
Please see attached screenshot for details. The score in question is Réminiscences de Norma here: https://musescore.com/user/26830520/scores/14831791
Appreciate anyone's input on this issue! The misalignment issue is really causing lots of headache
Comments
Why mxl rather than mscz?
That's comparing apples with peaches
In reply to Why mxl rather than mscz? by Jojo-Schmitz
Hi Jojo - I never thought too much about .mscz files as I have to work with .xml files directly (so I just download the .mxl file and unzip it), I tried downloading the .mscz from musescore.com, opened it with musescore 4 then exported it to .xml, and the hidden rests are gone. So it looks like the .mxl generation on musescore.com is either breaking / not matching the .mscz exactly? Appreciate it if you have any extra insight on this, I was assuming every downloadable format will end up looking the same
In reply to Hi Jojo - I never thought… by haotian9850
Export to any non-native format is doomed to loose information, esp. about layout.
That after all is why MuseScore has that native format (mscz/mscx) in the first place.
In reply to Export to any non-native… by Jojo-Schmitz
Thanks - this makes sense, but should I expect new musical elements like hidden rest to be added to the end of a voice when exporting .mscz to .xml? I noticed that is still happening for other parts of the score, resulting in a different temporal structure (which is a PITN as the exported xml is now incorrect for a pianist) in the .mscz than the .xml. Should this be considered a bug in the export feature for musescore?
From the .mscz file:
![Screenshot 2025-06-08 at 12.56.10 AM.png]( "Screenshot 2025-06-08 at 12.56.10 AM.png")
From the exported .xml:
![Screenshot 2025-06-08 at 12.57.14 AM.png]( "Screenshot 2025-06-08 at 12.57.14 AM.png")
You can see that the note onset times has shifted inwards for voice 1 in the right hand after exporting
I have attached the downloaded .mscz as well if you are interested, thanks!
In reply to Thanks - this makes sense,… by haotian9850
I'm away from.my computer so can't analyze anything right now (and not before Tuesday/Wednesday)
In reply to I'm away from.my computer so… by Jojo-Schmitz
Hi Jojo - no worries! I was just encountering this issue so your reply is already a huge help. If you can take a look on the exporting, or provide some pointers in the musescore code (I am a developer myself) when you can it'd be great!
In reply to Hi Jojo - no worries! I was… by haotian9850
For the record, rests that appear grayed out after export to MusicXML format are simply those that you have hidden yourself in the .mscz file (and completely on the screen via menu View / Show / Show invisible)
MusicXML export ignores this option. So, if you don't want these rests appear, go back to View / Show / Untick "Show invisible".
In reply to For the record, rests that… by cadiz1
I can confirm that in the .musz format, there is no invisible rest at the end of voice 1 even when show invisible is enabled:
![Screenshot 2025-06-08 at 1.10.23 PM.png]( "Screenshot 2025-06-08 at 1.10.23 PM.png")
However, the exported xml does have an extra invisible rest added to the end of voice 1, exactly as other commenters suggested:
![Screenshot 2025-06-08 at 1.12.00 PM.png]( "Screenshot 2025-06-08 at 1.12.00 PM.png")
This is causing a misalignment and the temporal structure also became different between the original mscz and xml
In reply to I can confirm that in the … by haotian9850
Well, there are two things:
![Capture d’écran 2025-06-09 à 00.16.53.png]( "Capture d’écran 2025-06-09 à 00.16.53.png")
1. What I was explaining about the rests that you had completely hidden (and appear grayed out after export in MusicXML format)
And 2. And this is much more annoying, your score is fundamentally corrupted. For some reason, MuseScore 4 doesn't complain about this. That's a bit surprising.
On the other hand, on opening it with 3.6.2, this version indicates a problem with the validity of the file in XLM format (fatal error...) - image below.
If I have time tomorrow, I'll see if this can be resolved.
And then, if I export your .mscz file in MusicXML format (and reopen it with 4.5.2: now MS4 complains about this), a warning clearly indicates a number of corrupted measures (as you can see, Voice too long...). And a corrupted score inevitably means a problem with the duration of measures and therefore “unexpected” rests.
In reply to Well, there are two things… by cadiz1
Hi, thanks for checking this, I did see the warning when loading the exported xml with musescore 4, however measure 190 to 191 are not in the list. Here is the full warning message:
Voice too long: Full score, measure 53, staff 1, voice 2. Found: 17/16. Expected: 4/4.
Voice too long: Full score, measure 54, staff 1, voice 2. Found: 17/16. Expected: 4/4.
Voice too long: Full score, measure 67, staff 1, voice 2. Found: 17/16. Expected: 4/4.
Voice too long: Full score, measure 71, staff 1, voice 2. Found: 17/16. Expected: 4/4.
Incomplete measure: Full score, measure 210, staff 1. Found: 285/192. Expected: 5/4.
Incomplete measure: Full score, measure 210, staff 2. Found: 432/288. Expected: 5/4.
Incomplete measure: Full score, measure 212, staff 2. Found: 84/72. Expected: 139/128.
Incomplete measure: Full score, measure 213, staff 2. Found: 84/72. Expected: 139/128.
Incomplete measure: Full score, measure 223, staff 1. Found: 7020/6240. Expected: 4/4.
Incomplete measure: Full score, measure 224, staff 1. Found: 4200/3360. Expected: 4/4.
Incomplete measure: Full score, measure 232, staff 1. Found: 2860/1760. Expected: 11/8.
Incomplete measure: Full score, measure 339, staff 2. Found: 9/8. Expected: 4/4.
Incomplete measure: Full score, measure 341, staff 2. Found: 9/8. Expected: 4/4.
Incomplete measure: Full score, measure 342, staff 2. Found: 9/8. Expected: 4/4.
I also checked the total musical durations of each voice from measure 190 to 191 in the exported xml, and they are mostly the same (there is a weird offset of 2 for some voices, not sure where that came from):
"190": {
"1": 2398,
"5": 2398,
"9": 2398
},
"191": {
"1": 2400,
"5": 2400,
"6": 2398,
"9": 2398
},
"192": {
"1": 2400,
"5": 2400,
"6": 2398,
"9": 2398
},
Hope these info will help!
In reply to Thanks - this makes sense,… by haotian9850
There is a problem and it also exists in Musescore 3(.7)!
![ScreenShot 428 MuseScore 3 Evolution_ Liszt1.png]( "ScreenShot 428 MuseScore 3 Evolution_ Liszt1.png")
![ScreenShot 429 MuseScore 3 Evolution_ Liszt2.png]( "ScreenShot 429 MuseScore 3 Evolution_ Liszt2.png")
See my attached files. Liszt1.mscz are measures 190-192 of the original. I have made all invisible elements visible.
I exported Liszt1.mscz as xml and imported and saved it in Musescore as List2.mscz. Compare for yourself (measure 191) ...
Liszt1:
Liszt2:
For example, there are some triplets that have been changed to nonuplets. And a beat has been added so that it becomes 5/4 measure!
I made this with Musescore 3.7.
In reply to There is a problem and it… by HildeK
This issue is affecting musescore 4 as well :(
In reply to This issue is affecting… by haotian9850
Should be issued @ github.com then and hopefully it can be backported afterwards to get 3.7 up-to-date. Or vice-versa (forward-ported) if Jojo/someone is slick enough to beat the 4.x team ;) There was a particular dude that was privy to the import/export xml code, so maybe he should be 'pinged'
In reply to Should be issued @ github… by worldwideweary
This guy (software developper) is @Leon Vinken: https://musescore.org/en/user/1036
Leon Vinken is a regular contributor to this forum. I'd say it would be a good idea to get first his opinion here. However, I think @haotian9850 should edit the title of his thread to mention the MusicXML format, so that it can immediately gain visibility on the forum for this developper when he comes back here.
In reply to This guy (software… by cadiz1
Thanks for the info! I have created an issue here: https://github.com/musescore/MuseScore/issues/28305 and have renamed this post to more accurately reflect the nature of the problem
In reply to This guy (software… by cadiz1
And also @rettinghaus.
Hi guys,
the "particular dude" speaking, I am still here :-).
Had a quick look. Most likely explanation (unable to fully debug at this time) is as follows:
- The MuseScore file contains nested triplets, which get exported correctly to MusicXML
- MuseScore's MusicXML importer does not support nested triplets (nor does it report those explicitly), resulting in nonuplets and timing errors on import
This is a known issue, e.g. see https://github.com/musescore/MuseScore/issues/22671. Unfortunately this is non-trivial to solve.
Regards, Leon.