Well, what I can tell is that there really has been a major overhaul on XML export. It was really deficient and is now correct. Of course, there’s still room for improvement. I just wanted to make things more fair.
1 Like
The issue is that it is too many things. Or rather, that the specifications are ambiguous enough that different vendors interpret them differently. Dorico is probably the least forgiving-- including on the import side. But none of the products are very reliable. The worst I have seen is the PDF2Music app. It has such great promise, particularly considering how much music is distributed on directly-written (not scanned) PDFs. But the imports into Dorico can be a real mess, particularly when tuplets are involved. And it isn’t that much better with MuseScore and Finale.
In every industry, it is difficult to get vendors to prioritize work that allows products to work together. They naturally want to put their resources on their own product function. But this is a case that badly needs industry cooperation. As it stands, IMHO, MusicXML is about as close to useless as is possible. It is better than nothing, but only barely.
1 Like
It is my understanding that with hardware and software standards there is often some way in which a vendor can test their compliance and be certified. Is this kind of thing more common when the standards relate to the products of huge companies making enormous profits rather than smaller ones? Is there any similar resource for MusicXML?
One thing which surely cannot continue if it currently does is the user wondering whether a failure is due to the ambiguity or confusing nature of the standard - or the failure of the implementer. It’s the same situation as one with which we are all familiar - when a user uses their own modem instead of the ISP’s modem to access the internet there is much finger pointing. But when the ISP supplies the modem responsibility lies solely with them.
If there are no test resources is there any reason why companies cannot open source their import and export code so that more technical types can identify and report bugs - and work towards excellent shareable code? Can MusicXML go open source?
Or is the issue a mismatch between what MusicXML standardises and what music notation companies want to offer in their apps - leading to vendors not seeing the format as helpful in facilitating what they want to achieve - is this why vendors are not all in? If so I want to suggest that whatever is helpfully common in the MusicXML spec be kept but that new infrastructure be built on top of it - this work could be done as part of creating a universal audio, MIDI and notation file format (which allows the import and export of less than all three) which recognises the relationships that programs are making between audio, MIDI and notated components (the notation and MIDI treated separately).
I defer to people who know more on the subject - I am just wondering about these kinds of issues.
1 Like
XML is an open standard and commands no royalty fee, which is partly why it has seen such wide adoption. With any open standard, the spec is published and it is up to individual developers to support it to whatever degree.
You can learn more about it here:
2 Likes
Thanks very much @Romanos .
I have now found out about the Lilypond test suite. Are these test files effective for identifying ALL kinds of issues with import and export - do they lead to the kind of reliability that some kind of formal test system would otherwise provide? Are the problems between apps mostly to do with not sharing compliance up to the same version number of MusicXML? I presume not - that there are other issues with varying implementation? I am reading past threads but it is difficult to build a picture.
To see a possible suggestion for how people can be more effectivey kept up to date regarding MusicXML progress see my next post.
https://web.mit.edu/music21/doc/developerReference/musicxmlTest.html
That seems like an excellent starting point. I wonder if anybody at Steinberg can comment on how well Dorico does with the ± 100 tests defined in that suite.
Apparently, you don’t know much about MusicXML. That’s ok—it’s a bit of a mystery to most of us.
In short, it’s a toolkit. How well it performs depends on its implementation by app developers. Then there are the various builds. Finale 27, for example, lets you export to any of 6 builds (1.0, 1…1, 2.0, 3.0, 3.1 & 4.0).
Sibelius never implemented v.3.1 but I read in Scoring Notes that Dolet 8 is in Beta and will add MusicXML 4.0 to Sibelius. This should be good news for many.
Notion 6 handles it quite well but again, v. 3.0. Perhaps now that Fender has acquired Presonus, development can begin again—or not.
I do agree that its implementation in MuseScore is a mess but it’s not unuseable — Finale handles pretty well and it saves me many hours on projects.
Ha! No argument there. I wish that app was good but it sure isn’t.
Anyway, I have not upgraded to Dorico 4 yet — perhaps this afternoon. It will be nice if its xml handling is improved but not a deal killer since Finale and Notion are very good.
1 Like
Since Mr. Good and his team are employed by Make Music, the notion that anything other than Finale 27 should be the current benchmark for MusicXML strikes me as odd — and Lilypond? Yikes!
Oh wait, Finale 27 is not free—but it does have tech support and .xml problems are escalated to the team responsible for the source code.
1 Like
Congratulations on your sleuthing. Lilypond is a well established format (marmite perhaps?). The music21 test suite just demonstrates how well music21 can interpret Lilypond files. But Lilypond is not a standard. Just open.
Perhaps you have also discovered other open source notation formats: ABC, Humdrum, Vexflow, MEI?
All these convey notation information to varying degrees of complexity. All are useful. None is a standard.
1 Like
Other than the MusicXML problems (*) the recognition can be excellent, but only if you select the right set of options, and I find them utterly bewildering. The defaults have always produced unacceptable results for me. I really want to love that app, and it seems like it isn’t that far from being very useful. But the author just doesn’t seem to get the importance of the options being sensible and intelligible.
(*) Other than that, Mrs. Lincoln, how did you enjoy the play?
I don’t really understand the significance of that statement. It seems to me that test suite serves a very good purpose by breaking the various compliance points down to individual elements. I’m not sure where Lilypond fits in, but surely there should be a standard library of MusicXML that vendors could use to benchmark their compliance.
1 Like
No.
Again, it’s a toolkit. How MusicXML is implemented depends on any app’s developer(s), what features they chose to include/exclude and how well they do it.
On another board, one member, after complaining that Encore should have been able to handle import/export of Lyrics and Expressions, never failed to remind everyone that it should have worked because MusicXML v. 1.3 supported that functionality. But those features were never implemented by Gvox or Passport Designs so what .xml supported doesn’t matter.
Dolet 8 has now been released to add Mxml v. 3.1 and 4.0 to Sibelius.
Scoring Notes article — Dolet 8
Which brings us back to Dorico. The only real test of its MusicXML compatibility will be between D4 and Finale 27. or Sibelius with Dolet 8. I hope it’s great but not a deal killer if it isn’t.
I am trying to import XML files and been having absolutely terrible results! Here is the situation: I started with Dorico years ago , don’t remember the exact version, but it may have been before Dorico 3. I was able to successfully import some XML files at that time, using PDF2MusicPro to import my PDF files. PDF2MP created the XML files, which did work fairly well. In fact, I recall that Daniel Spreadbury had a dialog with Didier at PDF2MP specifically about improving some issues.
Fast forward to today. I now have Dorico 4 and the latest version of PDF2MP, which is 1.7.4c build 24295. Basically, here is what happens; I can get PDF2MP to open my PDF files, and they look perfect in the app (ie, they look exactly like the original PDF). I then created the XML file within PDF2MP. When I import them into Logic Pro, they play, not perfectly, but close. But when I try to open them in Dorico 4, they are unusable! For example, if I import a piano piece, I will get about five notes and that’s it! However, all the measures come through, ie, if there were 100 measure, they all come through, but they are blank. It is basically useless! What went wrong?
I am stuck with using PDF2MP because I have 100s of files done in Graphire Music Press, and there will be no translation app for those. Any help will be most appreciated. Thanks!
The xml will have badly formed tuplets, and probably different tuplets in different voices (eg triplets in voice1 against 5:4 in voice2).
Try importing your xml to MuseScore, which might give you a listing of the errors in the xml file. These usually occur as bars that are incomplete because the tuplets don’t add up to complete bars.
A workaround: locate the bar where Dorico fails to import. Go back to PDF2MP and edit that bar to be a bar rest. Try the import again, and if successful, just manually correct the missing bar.
Yes, it seems to have an extraordinary amount of difficulty on tuplets. As I recall PDF2Music has some options that improve that, but I can’t make any sense out of any of the options. By default, the product does seem to work better with MuseScore and Finale.
I would dearly like to see this work. Clearly there is something that is monumentally wrong between these two products (PDF2Music and Dorico). As it stands, I have far better results using SmartScore, which should not be the case. Actually, PDF2Music is completely unusable with Dorico, as far as I can see.
Hmm, I know you must on to something, because there are no tuplets in my score, And so I went into PDF2MP and unchecked the “allow tuplets” and actually, that worked, in that the piece was notated almost until the end of the piece, when evidently some other problem must have occurred. So, then I went back to PDF2MP and experimented with unchecking various settings in the PDF2M Corrections menu, So, still not perfect, but I feel like I am getting somewhere! So, thanks!
MusicXML is, as yet, an immature format. You cannot guarantee that program X will export a file that program Y will interpret correctly. And the problem may lie at either end, or both!
For complex scores my safest route is: PDF>PhotoScore>Sibelius (Dolet plugin)>Dorico!
Once again, MusicXML is a set of tools as in a toolkit. It’a not a format or application or (fill in the blank). How well it works and what features are supported depends on its implementation by an app’s developer(s).
To my knowledge, only Finale 27 and Sibelius with Dolet 8 support MusicXML 4.0.
I had a need to convert a 2016-era Finale file to Dorico this afternoon. It actually went pretty well. An issue I see coming up often really isn’t about whether or not a particular feature is implemented, but rather different interpretations of the standard.
The issue appears when a Finale file has a meter change (in this case from 3/4 to cut time). The last measure of 3/4 had 4 beats when imported into Dorico, yet the cut time symbol did not appear until the next measure. I did get the funny red signpost on the bar in error.
This doesn’t happen on every meter change (thankfully) but it comes up often.