Crash opening MusicXML from Finale

• Jul 24, 2011 - 19:30
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

Hello,
Musescore 1.0 and 1.1 beta crash loading XML Finale file.
Look at attached file
Bye
Gai-Luron

Attachment Size
romance-1.zip 15.28 KB

Comments

• Jul 25, 2011 - 09:06

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.

Reply

• Jul 25, 2011 - 21:32

Hello,

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,

Bye

Gai-Luron

Reply

• Jul 25, 2011 - 22:49
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.

Reply

• Aug 9, 2011 - 19:24

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).

Reply

• Aug 11, 2011 - 15:01

@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

Reply

• Aug 12, 2011 - 19:58

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.

Reply

• Aug 18, 2011 - 21:41

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.

Reply

• Aug 21, 2011 - 21:05

Crash fixed in 0.9.6 revision 4704 (trunk still todo). Note: the attached file romance-1.zip 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.

Reply