Everything comes up as "Text"
I have scanned XML's & when I load them into MS2 (& recent MS3) it can identify the Title and Composer etc. The same XML's in the latest MS says everything is just 'Text'. 422.xml
I have scanned XML's & when I load them into MS2 (& recent MS3) it can identify the Title and Composer etc. The same XML's in the latest MS says everything is just 'Text'. 422.xml
Do you still have an unanswered question? Please log in first to post your question.
Comments
MuseScore 3.5.0 imports the title/composer etc too, but places it at the end of the score, 3.4.1 and 2.3.2 at it's start. And indeed with the wrong types in 3.5.0.
So we have yet another 3.5 regression it seems...
Relates to #270643: [EPIC] MusicXML import/export issues
Please file this in the issue tracker
FWIW, other MusicXMl files import as expected, so I suspect it has something to do with the specific way the MusicXML was constructed by your scanning software. But I don't know enough to say what the issue might be. I can guess the change in how we handle it is connected to https://github.com/musescore/MuseScore/pull/5666
In reply to FWIW, other MusicXMl files… by Marc Sabatella
No. Because the same file is Ok in older versions of Ms.
In reply to No. Because the same file is… by Craig Mac
Understood, I'm not saying it isn't a bug. But everything I wrote is true - others files do import titles correctly. So somehow, your file is formatted differently from others. It might indeed be that even though different, it's also correct, and that we are not handling it correctly anymore. But it might also be that it is actually incorrect and we were simply ignoring the error before but not anymore. As I said, I don't know enough about MusicXML to say. More investigation is needed by someone who understands MusicXML better.
In reply to FWIW, other MusicXMl files… by Marc Sabatella
that PR was supposed to fix #104731: Text lost when musicXML file imported and indeed is new in 3.5, so likely the culprit for this regression
In reply to that PR was supposed to fix … by Jojo-Schmitz
@Jojo, you are right, this is indeed a consequence of PR5666. As the previous behaviour was incorrect and the current implementation behaves exactly as I designed it, I am reluctant to call this a regression. I do agree there may be an opportunity for further improvements.
@Craig, unfortunately, the previous MuseScore releases are not right at all. They did try to detect title, subtitle, composer and lyricist, but failed quite often. If you open your file in 3.4.2, you will notice that the title is detected correctly, but the copyright line is detected as subtitle. The remaining footer texts are incorrectly detected as composer and lyricist. The underlying reason is that MusicXML contains text position and formatting, but not the text type. As of 3.5.0 the guessing has been removed, all text present in the MusicXML file is imported as correctly formatted but unstyled text into vboxes at the correct location.
In case anyone has a suggestion how to improve on this, I'd be interested to know. Keep in mind that MusicXML does not contain the meaning of a text. Furthermore, text locations are fixed page locations, meaning they will probably be incorrect after a relayout. Finally, it would be quite hard to detect headers and footers in MusicXML and non-trivial to fit those into MuseScore's header and footer, due to the way those are designed.
In reply to @Jojo, you are right, this… by Leon Vinken
One thing I forgot to mention: the MusicXML file explicitly specifies the text position as at the bottom of the page. Once again, feel free to suggest improvements, but be aware those would have to work correctly for most MusicXML files found in the wild, not just for a single specific case.
In reply to @Jojo, you are right, this… by Leon Vinken
I'd call it a regression on the grounds that something that worked before doesn't any longer.
It may still be 'by design', so not a bug though, but a feature request ;-)
In reply to I'd call it a regression on… by Jojo-Schmitz
Most important is to try to find improved algorithms to handle this the best way we can. Arguing about bug versus features is also fun, though, sometimes I can't resist :-).
In reply to Most important is to try to… by Leon Vinken
Agreed ;-)
In reply to I'd call it a regression on… by Jojo-Schmitz
A feature request perhaps. But Leon stated quite clearly:
"The underlying reason is that MusicXML contains text position and formatting, but not the text type."
So MusicXML itself has to evolve in order to apply different identifiers (text type) to all these "text" elements used in the title preliminaries - like dedication, title, subtitle, composer, lyricist, translator, opus number, instrumentation, dates of birth and death. Until then we can't expect a resolution or a more effective fix from Leon.
In reply to A feature request perhaps. … by DanielR
that MusicXML file contains... so more a bug in the exporting program it seems?
Sibelius in this case:
In reply to that MusicXML file contains… by Jojo-Schmitz
The MusicXML schema allows it as of MusicXML 3.0, by using the credit-type element. Its content is free format text, which leaves room for compatibility problems, but Finale (using Dolet) exports sane values (title, composer etc.).
Sibelius does not export this information (lets call that a deficiency instead of a bug as the spec does not require it).
MuseScore also does not yet support this on either import or export, submitted #309702: [MusicXML import/export] support credit-type element
In reply to that MusicXML file contains… by Jojo-Schmitz
We need to see the export of the same file made with the Dolet plugin.
Because SibeIius' direct export (xml) is usually for exchanging files between different versions of the same software (due to the change in the sib file format or simply because the file version is larger).
In reply to We need to see the export of… by Ziya Mete Demircan
@Ziya Mete Demircan - Haven't seen you in a while.
In reply to Ziya Mete Demircan - Haven't… by Rockhoven
I see you :)
In reply to We need to see the export of… by Ziya Mete Demircan
Dolet for Sibelius does not export credit words at all (at least: none of the examples I have).
Created two more issues for the things mentioned in this thread:
#309949: [MusicXML import] guess page one credit words type
#309950: [MusicXML import] fix title frame position
Please provide further feedback in these issues. Note that I am perfectly willing to fix things, but only after we have reached consensus on what to do.
In reply to Created two more issues for… by Leon Vinken
I can't claim to be an expert, but as regards MusicXML imports my view is:
#309949: [MusicXML import] guess page one credit words type
Title should be the largest font used.
Lyricist is on the left.
Composer is on the right.
Dedication is a lot more difficult: it's often absent, often in the smallest font used, often (but not always) at the top.
#309950: [MusicXML import] fix title frame position
The title info properly belongs at the top, and I cannot imagine why the Sibelius developers thought it appropriate to relegate this info to the end...
[OT] And as regards MusicXML exports, we should use the credit words to the maximum extent, so that MuseScore leads the field!
In reply to I can't claim to be an… by DanielR
Will be implementing this on short notice.
Also see:
#309953: [MusicXML import] incorrect lyric vertical order
#309954: [MusicXML import] lyrics with duplicate numbers are not imported
In reply to Also see: #309953: [MusicXML… by Leon Vinken
Solution implemented. Pull request: https://github.com/musescore/MuseScore/pull/6542.