Title says it all. Some XML files do import and some don’t with the message “Invalid file format”. The invalid ones were created last year in Sibelius. The one that did was created this morning with PhotoScore. Suggestions?
Are these MusicXML files compressed, i.e. with the file extension .mxl? If so, we’ve seen a couple of reports of this, though Dorico can normally open them without problems. I suggest you zip up the offending MusicXML files and attach them here, or send them to me in a PM if you don’t want them posted publicly, and we’ll take a look.
Thanks, Daniel, I attach a typical one of these. Note that its extension is .xml, not .mxl.
Bill Conable
VdG2iv.xml.zip (70.4 KB)
That “MusicXML” file is actually a Sibelius score with a .xml file extension, I’m afraid, so that would certainly explain why Dorico can’t open it. Sorry!
Well, well! No idea how that occurred. Thanks for quick reply.
Last night I tried saving a Photoscore Ultimate [7.02] file as an XML and importing it to Dorico. It totally crashed the program. I was hoping that Photoscore would work with Dorico. If I send the file to Sibelius, then export to XML from there, it imported into Dorico just fine. Are there any issues with Photoscore XML files?
~Dennis
It would be interesting to see the MusicXML file exported from PhotoScore, if you want to zip it up and attach it here or send it to me.
Historically speaking, the team at Neuratron haven’t devoted a huge amount of attention to the MusicXML export features of PhotoScore and AudioScore because they have tended to be little used, since the transfer of data between their software and Sibelius, with which their products are used 99% of the time, is handled by way of the dedicated OPT file format. So my suspicion would be that the MusicXML exported by PhotoScore is a little wonky and Dorico can’t cope with its specific brand of wonkiness.
Daniel, I’ve just exported an XML file from Finale, which uses the .musicxml extension. That’s not recognised by Dorico. It’s no problem to change the extension, of course.
I believe you should be able to drag a .musicxml file onto Dorico’s Dock icon to open it, even if you can’t open it via the FIle > Open picker. There’s still some debate about whether or not the .musicxml file extension will be adopted formally in the W3C community group, but we will probably support that file extension fully in due course.
Thanks for the helpful comments. Here is the Photoscore XML file for review.
~Dennis
Lift Up Your Voice - Carlson (Photoscore).zip (8.21 KB)
Thanks, Dennis. One of our developers, András, has looked at the file and discovered the reason for the crash, and has implemented a fix that will make its way into the next minor update. If you encounter any other files that cause similar problems, please let us have them, as we may be able to fix those problems.
Daniel,
I too have had a problem importing an xml generated in Finale 25.4 (Windows).
Here are screenshots of a passage successfully reimported in Finale, one imported into Dorico, and a zip of the xml excerpt I used for both
.
makeMyMarkFragm170630.zip (14.5 KB)
It looks to me like something about the rhythm in bar 7 is getting knackered in a way that Dorico can’t cope with. I’ve asked our resident MusicXML guru to take a look.
From Richard, our MusicXML guru:
The MusicXML file contains some very questionable rest durations: one in b.7 of P7 (Vln 2) and one in b.8 of P13 (drums). These rests look like some sort of mathematical rounding error - both of them have a duration of 1 but no , and both of them have extreme default-x values (more than a billion). The file imports fine if you comment them out.
So this looks like an export problem rather than an import problem, really.
Finale has always had problems counting the correct number of beats in bars, right back to the first versions released 
But if you design notation software so that each bar of each staff is an independent “music frame”, that’s probably an inevitable side effect - even if you try to patch it up by letting notes flow from one frame into the next.
Could it be related to Finale/XML handling of triplets?
I note that I have a heck of time trying to delete these rests in the Dorico rendition even w/ Insert on, but I will try to make sense of them in an XML editor.
EDIT:
And please send my thanks to Richard. I found the places he mentioned, corrected them, and the file imported fine. In the long term, though, (I hope through W3C compliance) Finale files will need to import smoothly for an ideal workflow, if only for legacy files.
The implementation of MusicXML import in Finale is designed to be as forgiving as possible, but unfortunately we don’t have the kind of time that would be needed to make Dorico’s import as forgiving of inconsistent or problematic data as Finale’s obviously is. So if there’s that kind of data in the file, Dorico will most likely choke on it – “garbage in, garbage out”, as they say.
Daniel, I realize that Dorico, being structured differently from Finale, must depend of a stricter adherence to the XML standard than Finale does for its own self-generated XML. I’ll keep my fingers crossed that Finale doesn’t diverge too far from the standard in its XML creation and reaches full compliance.
Again, thank you for your (and Richard’s) help.
I suspect that the only reason the MusicXML file has dodgy data in it is because of some edit you made to the Finale document at some point in the process of authoring it, and so the MusicXML exporter is doing its best to capture every bit of data from the file, including these nonsensical rests which I daresay you cannot even see in the original Finale file.
Anyway, my desire is not to point the finger: it’s obviously admirable that Finale’s MusicXML importer does such a good job of doing its best to interpret weird and wonderful data. But it is the product of many years of dedicated work by the creator of MusicXML himself, and if anybody has a vested interest in making sure that the interchange works as well as possible, it’s Michael! Finale users now get to reap the benefits of his years of hard work. Unfortunately there’s no shortcut to building a MusicXML importer that is as forgiving as Finale’s is: I bet that Michael’s importer is absolutely full of special cases designed to handle all manner of quirks from many different applications’ export.
Realistically speaking, I cannot foresee the time when we will have sufficient spare engineering time to start writing these special cases into our MusicXML importer. Dorico expects the MusicXML data to be schema-valid and musically sensible, otherwise all bets are off.
I’ve filed a support case with MakeMusic in the hope that they can either find my error or correct theirs. Thanks for your patience and your help on this.