MusicXML: problems with generated MusicXML when Title frame has a "Dedication" field

• Nov 26, 2019 - 14:48
Reported version
S4 - Minor

For the OpenScore Lieder Corpus project, we try to include the original dedication of the song where possible. So far we have used a separate vertical frame for the dedication text, placed above the usual title frame. This works well visually in MuseScore 2 and 3.

However, it turns out that information can be lost when a user wants to download such a score in MusicXML format. Three test files were created in MS 3.3.2, showing the degree of data loss with a MusicXML download. The test files can be accessed in this set:

In summary, this is what happens when a downloaded MusicXML file is opened in MS 3.3.2:

single Vertical Frame:
dedication, title, subtitle are all preserved with correct font size - but vertical positioning is lost (all text is overlaid)
One vertical frame used.png

two Vertical Frames:
dedication is preserved with correct font size; but title, subtitle, lyricist, composer are all discarded
Two vertical frames used.png

If it is not possible to use two vertical frames for this scenario, we can change our method for the Lieder Corpus to use only a single vertical frame. But it would be good if the vertical positioning problems can be fixed for the MusicXML export.


Status needs info active

OK. That's probably related to any number of places we don't export position info, mostly on purpose I think. But since I don't understand all the ins and outs, I leave this open.

"... probably related to any number of places we don't export position info, mostly on purpose"
In the case of the primary Title frame, the MusicXML successfully places lyricist name on the left and composer name on the right. And the Dedication, Title and Subtitle are correctly centred - but the three texts lose their vertical separation and are all overlaid on each other. See the first image in the original issue above.

Surely this is a fault?

Saving alignment info is different from saving position info. As I said, we generally don't save much position info at all - such as for score markings that were manually positioned - because the default positions are going to be different from program to program so manual positioning info generally won't make sense to carry over. So that much is by design. Whether or not there are some special cases where exceptiosn could be made and whether or not this is one of them, I cannot say, I'm not familiar enough with the issues involved. Just in general, I know not to expect much in the way of layout info to be preserved across import/export - it's more about preserving content.

In reply to by Marc Sabatella

Result of a quick investigation:

The "single Vertical Frame" issue is a regression (created issue #297893: [MusicXML import] subtitle placed incorrectly). Note that the positioning is correct in the MusicXML file generated, it is incorrectly interpreted on import.

The "two Vertical Frames" issue is by design (took the easy way out long ago and decided to export only the first vbox). This is indeed #20766: [MusicXML] Export keeps text from first frame only. Exporting all boxes above the first system is trivial, but leads to minor styling issues on import into MuseScore. If we feel it is worthwhile to support the OpenScore Lieder Corpus project on this and accept the import issue, I can implement this quickly.


Exporting all frames has been requested previously (probably multiple times), e.g. #291758: [Musicxml Export] - Tbox and Vbox after measure 1 don't export. This takes somewhat more effort than exporting all boxes above the first system, as it also requires exporting correct system positioning.

Due to differences in features between MuseScore and MusicXML, it is exceedingly difficult to reliably export/import frames to/from MusicXML in MuseScore. The frame concept used in MuseScore does not exist in MusicXML. Header and footer text in MusicXML is simply explicitly formatted text ("credit-words") at a specified location on a page. MuseScore uses explicitly styled text within a frame. Currently MuseScore tries to guess the meaning of the various credit-word element based on format and position, which works well only if the layout closely matches one specific style.

In reply to by Leon Vinken

"Currently MuseScore tries to guess the meaning of the various credit-word element based on format and position..."
As regards the OpenScore Lieder Corpus, we have tried always to place the Dedication above the Title (=song cycle ID, Op.No.) and Subtitle (=Song No. and title of individual song). In almost all cases this Dedication used a completely separate vertical frame with a Text entry for the dedication - placed above the standard vertical frame used for Title, Subtitle, Lyricist, Composer.
If it is possible to stick with the "two frames" solution, this will save a lot of rework on songs in the Lieder Corpus. It also means that the dedication is entirely separate from the standard fields as held in the Score Properties fields.
Leon, I am happy to standardise the approach used for the Lieder Corpus templates when a decision has been reached about the best path to follow.

Please find attached the export of the "two frames" version after implementing my proposed fix plus a screenshot of how it imports into Finale NotePad. I believe all header text fields are exported correctly.

When importing the MusicXML file into MuseScore (and after manually working around #297893), there will be a single vbox containing all texts. This is to be expected, as the vbox information is lost when exporting. The topmost text line (the dedication) will be styled title, the next two lines will be styled subtitle. This is an existing import (non) issue, caused by guessing which credit-words element would be title or subtile. Visually it looks OK anyway.

IMHO, we should fix the export anyway. Will submit a PR. Please realise that if the MusicXML files on are indeed generated on upload, you will have to upload files with two boxes in the header (again) after the fix has been deployed to musescore,com.

In reply to by Leon Vinken

Status fixed PR created

"... you will [probably] have to upload files with two boxes in the header (again) after the fix has been deployed to"

It's a small price to pay, and in many cases we will be re-uploading anyway in order to convert older Lieder Corpus scores from MS 2.3.2 to MS 3. Leon, thank you very much for implementing this fix!

Fix version