Crash opening MusicXML from Finale

• Jul 24, 2011 - 19:30
S2 - Critical

Musescore 1.0 and 1.1 beta crash loading XML Finale file.
Look at attached file

Attachment Size 15.28 KB


There is something weird in the voice numbering in the grand staff. Voices 1,2,3 on staff 1 and voices 4,5,6,7 on staff 2. MuseScore can't cope with it right now.


Sound strange because Finale have only 4 voices and in my score i use a maximum of 3 voices. Maybe an error in finale XML export. Maybe an error message in this case is better than crash

Thank you,



Title Musescore 1.0 crash loading XML finale file Crash opening MusicXML from Finale

Also affects the nightly build.

Using MuseScore 2.0 Nightly Build (4593) - Mac 10.6.8.

Actually, for the second part in the attached file Finales MusicXML export has generated seven voices (numbered 1 up to 7). Voice 3 is on staff 1 only, voices 4, 5 and 7 are on staff 2 only and voices 1, 2 and 6 are on both staves.

The reason import fails is that MuseScore currently assigns a MusicXML voice to the staff on which the voices first note is placed, which happens to be staff 2 for voices 1, 2, 4, 5, 6, and 7. As MuseScore only allows four voices per staff, this fails.

The crash is due to the fact that this situation is detected and reported (see messages "ImportMusicXml: too many voices ..." sent to the console), but not handled correctly. This, of course, shouldn't happen. It is trivial to limit import to the first four voices in a staff, but that means part of the data is not imported, so it is a suboptimal solution. I'm currently trying to design a solution that will import all data correctly, but that is a bit more difficult (and if the MusicXML file contains more than four voices per staff, impossible).

@lvinken, if you are doing some efforts on the voice handling. Here is another test file from Sibelius7... that didn't respect the voice numbering (sometimes voice is missing, and when here the voice is not incremented in a part basis but on a staff basis...). Can we handle it ?

Attachment Size
negro_pno.xml 326.1 KB

No, we can't handle this. Reason is that the voices in staff 1 and 2 both use voice 1. As far as I know, this is not allowed in MusicXML. I am not aware of any easy way to handle this automatically.

Reworked the MusicXML voice mapper in the 0.9.6 branch in revision 4703. Instead of allocating voices "on the fly" it now reads the whole file and then decides how to map the voices. This allows for better decisions and better error handling (still todo). As of yet no end user visible effects but it will allow me to fix this issue and several others in the near future.

Crash fixed in 0.9.6 revision 4704 (trunk still todo). Note: the attached file still does not open completely correctly (part P2 data is not imported for measures 16 and up, probably a separate issue still to be investigated), but at least it does not crash due to the voice mapper anymore.