Wrong interpretation of MusicXML by MuseScore 2.0.2!
MusicXML has two ways to define chords (Harmony)
Example:
Ebm6/Bb
Can be defined in MusicXML as (I reversed opening signs into > in the examples):
>harmony .......>
>root>
>root-step>E >/root-step>
>root-alter>-1>/root-alter>
>/root>
>kind>minor-sixth>/kind>
>bass>
>bass-step>B>/bass-step>
>bass-alter>-1>/bass-alter>
>/bass>
>/harmony>
Or:
>harmony .......>
>root>
>root-step>E>/root-step>
>root-alter>-1>/root-alter>
>/root>
>kind text="m6/Bb">other>/kind>
>/harmony>
In fact if no harmony definition is available like "minor-sixth" because it was not yet defined in MusicXML (since everyone can define a new seldom used combination) then a possibility has been added to add "other" and define in a text your own harmony. In fact the text=".." possibility has also been available for programs that hadn't yet implemented detection of all the available harmony's that have been developed in time.
In practice it means that if a >kind> has been defined that you should only read the >kind>.. >/kind> content and if the kind shows "other" you should read the text="..." content. If both are present you should only detect the >kind>...>/kind> content. Not both. Imho it is fundamental mistake in the detection implemented by Finale as well as in the new MuseScore2.0. Sibelius and MuseScore 1.3 do both a good job. It will read one or the other not both. In fact MuseScore 1.3 does the best job because if there is no kind definition is available but the /bass note info has been added also only one bass note is shown and not 2 like in Sibelius.
With other words any double info should not lead to doubling the shown result. Both ways of defining harmonys has been a developed in time in MusicXML and some programs cannot detect yet all types of >kind> definitions that has been developed in time.
Here it leads to Ebm6/bb/Bb, which should have been Ebm6/Bb.
The double info is also especially present since not all programs detect all available definitions!
Compare results in
Compare PDFtoXML_MS1.3vs2.0.png
Here the 3 pictures left original pdf, mid MuseScore 1.3, right 2.0.2
And also:
Compare PDFtoXML_Sib7vsFin2014.png
Left original, mid Sibelius, right Finale 2014.
So please implement the MuseScore 1.3 detection.
Rob
| Attachment | Size |
|---|---|
| Compare PDFtoXML_MS1.3vs2.0.png | 129.57 KB |
| Compare PDFtoXML_Sib7vsFin2014.png | 509.14 KB |
Comments
I am not crazy about the idea of MuseScore lying. If the MusicXML file does not identify the chord as a minor sixth, I don't think it should try to turn it into one. Do you have real world use cases - real world programs that produce this erroneous input? Can you attach an actual MusicXML file produced by an actual program that shows a problem, and tell us what program produced this file?
MuseScore tries very hard to produce chord symbols that make semantic sense and whose text is parseable to reorduce those same semantics. Arbitrary text in an imported chord symbol cannot generally be honored or it would produce a chord symbol that is either unparseable or would parse to something else entirely.
In reply to I am not crazy about the idea by Marc Sabatella
Marc,
You didn't particular comment on my explanation, which includes picture examples.
The real world program is "PDFtoMusic Pro", which translates vectorised PDF that have been exported by notation programs into MusicXML. They do a very good job in translation chords. MusicXML has defined a number of chord symbols but not all of which you might think of. So "minor-six" is a defined chord identified as (kind>minor-six(/kind>.
(btw. I did write "(" instead of a reversed ">" to be able to show it here since it aren't recognizable html symbols. After a reversed ">" text stops)
So to make it possible to identify chord symbols that are not (yet) defined, but are randomly used, MusicXML has introduced the definition "other" meaning if you do create your own invented typical chord symbol you can read it as "text" added in the opening sign (kind text="....">. So if minor-six had been a not yet defined symbol it could be written as: (kind text="m6">other(/ kind>.
Since not all notation programs use the newest definitions some decided to use only the text="m6" content, other programs never read the text content and only use the known MusicXML kind definitions. In order to give credit to as many notation programs as possible PDFtoMusic adds both info. So the chances you can read your chords from the MusicXML file are maximised. This is not an erroneous input. That means if you identify "minor-six" you should ignore the text unless you identified "other". Both "Finale" and "MuseScore 2.0.2" do mixup the text="...." and and the "minor-six" which leads many times more to very strange interpretations. Not only in this example.
I attached the MusicXML as produced by "PDFtoMusic Pro" for this example.
In reply to Marc, You didn't particular by Robipad
I didn't comment earlier because there is almost no insight I can get from just a picture - I needed the actual score to be able to examine data structures, etc.
The problem has nothing to do with the specifics of this being a minor sixth chord. The error is the "bb", which should not have been incldued in the kind text. "Bb" is the alternate bass note and this is already accounted for by the "bass" element. There is a "bb" in the kind text, and MuseScore is dutifully including that in the chord symbol itself, but then there is also a bass element, so MuseScore is also dutifully including that. This is, as far as I can tell, completely correct. It is the input that is wrong. Kind text is not supposed to include information about the bass note - only about the kind.
In reply to I didn't comment earlier by Marc Sabatella
The kind "text" should only be included if "other" was mentioned as defenition. MuseScore should NOT dutifully include it if "other" is NOT defined. I can understand that the interpretation of the MusicXML might lead to different opinions about this issue. I've been always very satified with the MuseScore 1.3. and the Sibelius interpretation. If not "other" has been defined they both ignore the text like they should.
What you want is that at the input side the text is NOT available if a bass element and kind definitions are available. However the problem is that not all notation programs can handle all kind definitions (yet) and are also dependent on text info. The text info is not meant as addition to an already existing kind definitions of chord symbols (which includes degrees and the bass element).
The text is meant as a complete replacement if NO chord symbol definitions are (yet) available!
So again MuseScore should NOT include it if definitions are available.
In reply to The kind "text" should only by Robipad
No, this is not how the MusicXML spec reads. Kind text is supposed to be honored if present, and it is supposed to refer to the kind only, not to the root or the alternate bass note.
If you can find an explicitly described exception to this general rule somewhere in the MusicXML spec, feel free to point me to the relevant section of the specification and explain why it applies here.