Re: MusicXML conversion

[Reinhold Kainhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Simon,

While musicxml2ly does a good job with simple files, your file contains 
several features, which are not (yet?) properly handled, thus the output 
degrades as musicxml2ly traverses through the file. Below is a detailled list 
of issues I found  (most are issues in musicxml2ly, but some are also issues 
in Finale). It's rather technical and mainly meant for myself as a reminder 
of the remaining bugs of musicxml2ly. I've also put it on my personal page 
for musicxml2ly issues:
http://wiki.kainhofer.com/musicxml2ly/sonata2_issues
http://wiki.kainhofer.com/musicxml2ly/start

Am Donnerstag, 21. August 2008 schrieb Han-Wen Nienhuys:
> At first I was pleasantly surprised because I think the opening pages
> look better in Lily, and the total uses 8 iso. 13 pages, but it
> appears musicxml2ly does not handle the cadenza section.  Reinhold?

There are several issues with the file / with musicxml2ly / with Finale:

- -) In measures 83/84, musicxml2ly messes up the note offsets, so that 
starting 
in measure 84 in the bass staff the offsets are off and chords are no longer 
properly detected (i.e. the < .... > around the notes are missing in the 
lilypond file) and instead the notes of the chords are written out one after 
the other.

- -) In measure 165, the cadenza is not written out by Finale to the .xml file. 
Some of the notes of the cadenza have <type size="cue">16th</type>, while 
others simply have <type>16th</type>. Other than the "cue", there is nothing 
in the xml file that would mark that sequence of notes as a cadenza! 
consequently, I don't have any way to detect these notes as cadenzas. 
Actually, it couldn't find anything in the MusicXML specs about cadenzas... 
Thus, cadenzas are not implemented in musicxml2ly.

- -) In line 92, Finale messes up the staccato dot in its PDF output. That 
happens in a lot of places, e.g. also in the upper staff in measure 130.

- -) In measure 141, lilypond prints the bass clef in the middle of the measure 
rather than right before the bar line:
    <d~ e~ gis~>1 | \barNumberCheck #140
    <d e gis>1 \clef "bass" | % 141
    a,8 [ e'8 c8 e8 ] a,8 [ e'8 c8 e8 ] | % 142

- -) Finale messes up the measure numbering starting at measure 137/138 (bottom 
of page 8). Although Measure 137 is a complete measure, Finale counts the 
whole next measure as the same measure!!!
As a result the third voice (the second bass voice) in lilypond is off by a 
measure...
The same happens in measures 206/207 (last measure of II. Andante and first 
measure of III. Presto), which Finale counts as one measure!

- -) Finale does not export the grace notes in measures 152, 155, etc. (using 
Finale's counting!) to the MusicXML file!

- -) musicxml2ly does not yet convert parenthesized note heads (measure 157 in 
Finale).

- -) Regarding the cadenza: I'm manually trying to adjust the lilypond file to 
see how cadenzas should be converted, but I'm running into all sorts of 
trouble:
  o) R1 in a cadenza is always printed in the middle of the measure
  o) Measure numbering is messed up (it prints as if nothing before the
      cadenza exists!
  o) If I pad the measure with s2. before the cadenza, the cadenza is printed 
      in the NEXT measure
  o) There are some voices without a cadenza, which no longer align with the 
      voices containing the cadenza. It looks as if each voice needs to have
      a cadenza of the same length, otherwise voice aligning will be messed
      up. And no, NR section 1.2.6.2 does not apply, since the "cadenza" there
      does not use \cadenzaOn / \cadenzaOff
How should the lilypond code for Measure 164 (Finale counting) look?

- -) In measure 16, the rests in the lowest voice are messed up. The culprit 
seems to be the dotted quarter rest, during which the key change comes after 
the first eight... This happens in a few places at the beginning of the 
piece.

- -) In measures 25 and , the end of the trill spanner (attached to the grace 
note) is not properly converted by musicxml2ly... Also, the trill is 
converted to \trill\startTrillSpan, which is of course redundant and crates a 
duplicate "tr".

- -) Several spurious \[ ...\] are inserted into the lilypond file.

- -) Markups like "cresc." etc are duplicated (known issue)

- -) The grace notes in measure 109 are not converted at all for some strange 
reason.

- -) No barline is printed in lilypond before the last measure... The reason is 
that the skips in voices three and four at the and of the piece are not 
properly counted...

- -) The handling of skips (s8*.. or s1*...) is less than sub-optimal in 
musicxml2ly. In particular, the skips do not properly align to measure 
boundaries and completely ignore the time signature, so they are very hard to 
read.

- -) For voices with skips, markups are assigned to the wrong position (i.e. if 
there are s4*15 skips and then an s4 skip with a markup attached, the output 
will be s4*16^\markup{...}, which assigns the markup to the very beginning of 
the skips...)

- -) Insertion of \ottava in voices with skips does not work (the pending skips 
are not printed out before the octavation is printed to the .ly file).

- -) Markups consisting of multiple parts, e.g. the "I. Allegro" are split up 
by 
musicxml2ly.

Cheers,
Reinhold

> On Wed, Aug 20, 2008 at 2:52 PM, Simon Bielman <address@hidden> 
wrote:
> > I converted a Finale 2007 document to MusicXML, ran 'musicxml2ly', and
> > ran it through LilyPond.  Here are the results, along with the
> > Finale-imported .XML file and the .XML file itself:
> >
> > http://www.simonbielman.com/pdf/sonata_2_finale.pdf
> > http://www.simonbielman.com/pdf/sonata_2_lilypond.pdf
> > http://www.simonbielman.com/pdf/sonata_no_2.xml
> >
> > I posted this on the IMSLP forums, and was encouraged to post it here to
> > try and help the project out.  Hopefully this is useful!



- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: address@hidden, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIrV1RTqjEwhXvPN0RAjsGAJ0fPjUuT7R43mK5mquza5fKccyBqwCfW4cr
Y+RZLqN8FJl6SJEmlVMUyH0=
=KTVG
-----END PGP SIGNATURE-----