MusicXML round trip results in text boxes being mixed, swapped; page size not preserved
I have thousands of Finale files which I often need to edit or clone. Recent experiences, and a few minutes poking around the MakeMusic website, makes it clear that users should start preparing to move on from Finale.
I tried exporting a few MusicXML files from Finale and importing in MuseScore 4. There were several issues. So I decided to do a "round trip" test of MuseScore's MusicXML import and export. My thinking is that any issue between Finale and MuseScore could be fixed by reverse-engineering the several issues and writing a script or program which would process the MusicXML file exported from Finale before importing into MuseScore. But if a MusicXML file exported from MuseScore and then immediately imported back into MuseScore has issues, the causes need to be fixed within MuseScore / MusicXML.
The result of my round-trip test showed MuseScore failing in two issues: Page size and Text boxes. Text boxes and their formats appear to be swapped if there are several test boxes on a page. I have attached files showing this.
I have read in several-years-old posts on this forum that MusicXML may not properly support Text boxes and am wondering if this still a "bug" (omission) in the current MusicXML specification.
For a quick summary, look at pdf attachments 2- and 5-.
| Attachment | Size |
|---|---|
| 1-Original-created-in-MuseScore.mscz | 25.44 KB |
| 2-Original-exported-from-MuseScore.pdf | 26.16 KB |
| 3-Export-from-original.mxl | 2.4 KB |
| 4-After-importing (round trip).mscz | 21.61 KB |
| 5-After-importing (round trip).pdf | 30.16 KB |
Comments
Maybe, maybe not.
When I open number 3 in Sibelius, it looks just like number 5.
Mxl is never going to be perfect.
In reply to Maybe, maybe not. When I… by bobjp
Thank you. It is interesting that Sibelius imports a MusicXML file the same as MuseScore does. So maybe we could say the problem is MuseScore''s export and/or inconsistencies in MusicXML.
I don't see why MusicXML could never be made perfect, at least in this area of text boxes. MuseScore, Finale and Sibelius all can, or should be able to, place text with any given size, font, justification, and location relative to a measure or a page. If the MusicMXL specification does not support this, it could be amended.
In reply to Thank you. It is… by jerrykrinock
Which is why I would be interested in an mxl from Finale.
In reply to Which is why I would be… by bobjp
Great! Please scroll down to another reply I posted and you shall see Finale Example 1 and Finale Example 2. These zip archives each contain a Finale .musx file, a .mxl export from it, and a pdf export from it (to show what it should look like). All were made with the latest version of Finale, 27.3.0.160.
In reply to Great! Please scroll down… by jerrykrinock
So I worked with the Wedding March. I opened the Finale mxl in Sibelius. The text boxes seemed correct for the most part. But other elements were incorrect. The N.C. symbol was two Cmi chords. The D/S symbol was in the wrong place. It was two pages instead of one. Sibelius complained about this file and said it might not open properly if at all.
In reply to So I worked with the Wedding… by bobjp
Very Interesting, bobjp. I searched the .mxl file for "N.C." and found the element in my first attachment below
Compare that to the "known good" element which apparently correctly symbolizes the Adim chord in my second attachment below. (Sorry I had to post screenshots instead of text because the "code fences" of extended Markdown are apparently not supported by this forum.)
We can spread the blame around. To my knowledge, Finale does not support "N.C." as a chord. (More likely, it does, but I never bothered to search Google to find it :)) ) Maybe I hacked a "C" chord by removing the root text and entering "N.C." for the suffix in the chord definition dialog, because I was in a hurry and "it worked". Anyhow, we somehow ended up with that bastard harmony element being exported from Finale. Unfortunately, Sibelius thought that the root-step value "C" was more important than the missing text (I guess you could argue it either way), but then went further and somehow conjured up that this was two C minor chords. I place most of the blame on Sibelius for this foible.
Anyhow, if and probably when the day comes that I want to script a bulk conversion of my 1,367 Finale files to MuseScore, it should be theoretically possible to make this work by (a) adding missing elements or whatever to the MusicMXL spec, (b) writing a program to patch Finale MusicXML exports (c) patching MuseScore to be self-consistent and compliant to the updated MusicXML spec.
In reply to Very Interesting, bobjp. I… by jerrykrinock
So, what is going on with Finale? I'm trying to figure out MuseScore because I figure that My old Sibelius from 2014 won't work on some future version of Windows. Soon I will see if it works on W11.
As far as I know, the MusicXML specification does not contain anything semantically equivalent to MuseScore's text boxes. In MusicXML files I have seen, the credit element is typically abused for text boxes. Abused because text boxes are supposed to flow with the music, while credits are anchored to locations on the page.
I would be interested in evaluating what exactly fails when transferring your Finale files into MuseScore, could you share specific examples ?
Out of curiosity I have imported the MuseScore export into Finale NotePad (result attached as PDF with page size set to A4). This suggests MuseScore's export is mostly, but possibly not completely, correct.
The only MusicXML change I am aware of is the introduction of the credit-type element in MusicXML 3.0 in 2011.
In reply to As far as I know, the… by Leon Vinken
And I'm suggesting that part of the problem lies with Finale. If number 3 is the original mxl. from Finale, it doesn't open properly in Sibelius or MU4.
In reply to And I'm suggesting that part… by bobjp
No, bobjp. Number 3 is the original mxl export from MuseScore.
Although there may be certainly problems with Finale, my point is that we first need to clean up the issue that a completely MuseScore MusicXML "round trip" does not work. In other words, exporting MusicXML from MuseScore and then importing that exported file right back into MuseScore itself should work perfectly. But we get misplaced and mixed up text boxes.
In reply to No, bobjp. Number 3 is the… by jerrykrinock
Another example of this: https://musescore.org/en/node/294321
In reply to As far as I know, the… by Leon Vinken
Thank you, Leon. I take your word for it that the MusicXML specification does not propely support text boxes. Also, while editing that file in MuseScore I myself was confused by how the text box at the bottom of the page (probably credits) behaved differently than text boxes I had created from scratch. It seems that MuseScore's Text box model is a bit wonky.
Regarding what fails when transferring Finale Files into MuseScore, although I think we need to work out the problems in MuseScore and MusicXML first, I have attached two more examples of Finale files as you requested. (I had to zip them because, this forum does not allow attaching .musx files.)
After unzipping, you can import those .mxl files into MuseScore, compare with the Finale-produced .pdf files and see what I mean. You will see that there are a few other issues too, which indeed may be the fault of Finale. But I think that debugging Finale exports is getting ahead of ourselves, as I will say again, I'd like to see MuseScore perfectly importing its own exports before trying to debug issues in other apps. We need a "known good" actor to test against.
In reply to Thank you, Leon. I take… by jerrykrinock
With respect to MuseScore's import of MusicXML credit elements:
The Tu Muerte example imports correctly: title and composer credit are imported as such and combined in a single vbox.
Same goes for the Wedding March example, but in this case the vbox is not sized correctly, which requires further investigation.
Note: I may be unable to reply quickly for a few weeks.