MusicXML import bad, single eighth note system

I created a new musicxml export from finale latest version and when I imported it into Dorico 5 pro first 2 pages are ok but the rest are messed up.
systems seem to get spilt at the last eighth note to make a new system of just one eighth note.

how do I fix this mess?
Seems to import into MuseScore just fine.

Do you have your signposts turned off? If so, turn them on and see if there are system breaks, then try deleting any that might show up. Or, re-import but deselect the system and frame breaks in the XML import settings.

Tim

1 Like

OK thanks for the tip. I generally hate the signposts, they are so intrusive, but for some reason it had system breaks there, which I could delete. Also tried turn off the system and frame breaks which also fixed this issue but layout still a bit cramped. It seemed to work better by first importing it into MuseScore then re-exporting it to MusicXML and then importing it to Dorico. It looks a lot better now.

I really like how MuseScore imports all the correct title and subtitle in the correct font. It a shame Dorico does not do that and you have to spend time re doing all that.

I get what you say about the signposts. I often have to hide them to do some editing. I have been moving some old files over from Finale to Dorico lately, mainly to get a more consistent look to the pieces I have that get more performances. I’m always surprised how some imports are fine, but others are a mess. Some of them I expect to be a mess, since unmeasured music in Finale was always a work around. I expect those to look bad in any other program. XML doesn’t handle hidden bar lines and meters at all. But some of the simpler stuff has been very odd in how it’s interpreted.

I agree somewhat that MuseScore does an overall better job at import, but as I showed my composition students last week, there’s still a lot of cleanup to do. And some of it is subtle (slurs not going to the correct note, chords made up of different layers not aligning, etc).

I do think the programmers for Dorico are doing starting to make some substantial improvements in 5.1.60 and I expect the next update will be even better. Text blocks are a bit better, and the option to not include formatting is also helpful. I still think that the clean up in Dorico is worth the effort, as I really like the overall look.

1 Like

For the title and subtitle portion, if it is the same as you have done in other files, you can import your page template set from the other files. The page template sets are quite portable, so unless you use a different font/look for the title and subtitle of every piece, there’s not much involved in transferring that from another file.

I think part of what makes the import more complicated into Dorico for the title and subtitle and other front matter is the fact that it has a separate mini-DTP engine within Engrave mode, so it is really two programs in one. You’re already familiar with this concept a bit as you used this DTP engine with your flute piece to bring the content in via a frame-per-bar. This design makes it very powerful but makes import potentially more challenging. To get those parts to import, they would have to divide up the information between the two engines somehow and try and locate the title text and auto replace it with tokens as well. It would essentially have to build a template set from the information in the XML. It might be doable, but it could be a fairly error prone process, so it could take quite a bit of effort to get functioning well.

1 Like

Yeah, I was thinking last night I need to figure out how page template’s works so I don’t have to make the same mods on every page, since changes to one page does not carry through to the others like in Finale for page text elements. I do think the template will be very useful long term. Today’s project I guess.
But separate engine or not, MuseScore proves the data is in there, they just don’t use it. it very simple to make a popup to map data you can’t tell where it should go from that file and you can alway have a skip button if people want to start over. I prefer time savings and no data left behind, then invisible perfection. Here in silicon valley the moto is iteration, get something out the works then tweak it until it is “perfect” and sometime scrap it all and rewrite it once you finally know what it should be doing. If wait until you have the perfect solution to every problem, you end up left behind by your competitors.

Yeah I have seen lots of slur issues with MuseScore and Sibelius. And I have seen MuseScore do weird things on import and givings me one measure for a whole page for some reason. I think I’m now at the point to do mixing and matching some to get me the best results the fastest I can get to move things over to Dorico. Since MakeMusic originally owned the musicxml formate, I assume Finale outputs it correctly and it the others not interpreting it right, but who knows maybe Finale musicxml has lots of errors now causing these issues.

Yeah you should already be working with page templates and avoiding making overrides on individual pages. It saves a ton of time. And you can export your template set, bring it into another file, and then you immediately get that other file with your same appearance. So, assuming you’ve already set up your templates the way you want, you can import any MusicXML from another program, import your template set, and immediately get the headers etc you want. So even though it is not fully automatic, the import of the page template set from the file takes only a few seconds.

The only time I would do overrides for individual pages is possibly where I wanted to use page-attached text.

P.S. Some of the videos to do with page templates and template sets may be titled “master pages” because in older versions of Dorico they were called that instead of page templates.

I’m going to reiterate (now that layout is included in the import options).
If you want Dorico to do all its clever stuff deselect all MusicXML import options.

I been using the defaults mostly, but I do see that cause me more work at times cause it get note values wrong, from what I want. And various other choices that Dorico makes that are incorrect for the music being imported. It more trial and error to get it to import in away that causes the least amount of work correcting all issues with the import.
Man, one time it switch all my 7/8 measure to be the same grouping which was not what I wrote. Now some of these pieces are from the early 90’s so Finale didn’t have pickup measures and things like that back then, so you did work arounds which don’t import well. This is why I tell people not to wait to long to move music. Cause you can update them in Finale to fix issue with import, as that can be faster way to fix things. One case it lost 90% of my music cause of triplets over the bar, remove that in finale is a lot faster then re entering all the music.

In this particular case, you are probably best off importing without “Import System and Frame Breaks” checked. One of Dorico’s strengths is the auto formatting, so often the imported system and frame breaks can cause more problems than they solve (as is the case in your topmost post). Things often look quite fine in Dorico without any manual system or frame breaks.

For the groupings, yes if you overrode the beam groups and you need that, you probably want to have it checked. As an alternative though, you might also want to consider creating custom 7/8 groupings within dorico, which you can enter into the popover with things like “[3+2+3]/8” (but it shows as 7/8). In the long term, this can sometimes be a better solution than forcing the beaming in a certain way because it makes edits easier. But obviously if you don’t plan on making revisions to the piece later, you may elect to have “Beam Groups” checked on import.

Also, if you are hiding your signposts for proofreading purposes (to avoid the clutter when you are proofing), you might also consider using the hotkey that when you hold it down it hides the signposts and shows the music as it would print or export. On Windows that is the backslash key \ and on Mac that is the backtick/tilde key ` ~, usually to the left of the number 1 and exclamation mark key. When you hold this key down, it hides all non printing characters, basically giving you a view of the file as it would show up when exported to PDF or printed. It is very handy for this purpose and has very often replaced hiding signposts for me.

Yeah I tried the off importing as @tmrolls suggested it worked but the music was way to crapped for some reason, best results for least amount of work came from Importing into MuseScore (which looked great for this piece), exporting MusicXML, then importing that. Still a little tight then I would like, but matches closer to what my publisher decided to do with it, originally.

Yeah, that how I fixed the incorrect beaming, cause I noticed later after I spent a lot of time fixing other things. Wish I would have caught it earlier, I could have imported it differently. Older Finale files, with work arounds for missing features causing the issue for sure. Really hate being back to have to use work arounds for missing features.

Good tip on the hotkey thanks!

I’m reminded of the old adage “garbage in, garbage out”.

It seems that most of your problems are caused by Finale’s original workarounds and poor encoding of musicXML. If MuseScore can sort out a few of them, great, use it.

Definitely some of this is from this being older music in Finale, but not all and remember MusicXML was MakeMusic baby, so I still betting that the latest version is exporting MusicXML correctly to spec and why MuseScore opens it so clean and correctly matching the original.

We were dealing with an issue in another thread the other day where someone had a relatively simple bar with a dotted quarter followed by a dotted half (basically in 9/8), and things went a little crazy on the import. Digging into the MusicXML 4.0 exported by Finale, we found that the dotted half was being exported with no note type, with duration one less than the dotted half should have (767 instead of 768) and was followed by a 1024th rest of duration 1. These didn’t appear in Finale at all - it just displayed it as a dotted quarter followed by a dotted half and no rest. Dorico malfunctioned a bit after hitting that. MuseScore handled the situation only slightly better - it silently erased the dotted half note while adding a series of rests to end in the 1024th rest. In that case we were able to fix the MusicXML file by hand-editing it to remove the 1024th rest and increase the dotted half to duration 768, then it imported perfectly.

So there can be issues with the original Finale file that impact the MusicXML export even with the latest version. How the destination program handles those issues can be quite variable. Some issues won’t faze one program but will thoroughly confuse the other.

EDIT: As an aside, the other thing that we found out through that thread is that Dorico is the only major notation program that can properly import XML with additive meters from Finale. When I said it was “basically in 9/8”, the actual time was 1/4+3/8+1/4+1/4. Both Sibelius and MuseScore imported it as 1/4 with each bar being overfull, and only Dorico imported it correctly with the additive time signatures. I just found that interesting because in many situations (I wouldn’t necessarily say “most”) I find MuseScore does tend to import MusicXML better, but this was a case where the opposite happened.

2 Likes

It is true I have seen some MuseScore imports go weird on me as well. Only thing it constantly does better is title, subtitle, fonts, ect. It is trial and error for each piece to find an effective method of getting it into Dorico. Which is frustrating, and one of dozens of thing I warn people about on trying to save their music.