Musical Information (Mus 253)
mro2score

mro2score is a program written by Christian Fremerey at the University of Bonn, Germany. The program converts SharpEye .mro data files into .mus (binary) and .pmx (ASCII) files for use in the SCORE music typesetting program. This program allows for musical data derived from scanned typeset music to be imported directly into SCORE without the need for user input mode in SCORE to generate musical data.

This page demonstrates how to convert SharpEye .MRO files into SCORE .MUS/.PMX files using as an example "Spinning Song" for piano by Felix Mendelssohn (Song without Words, Op. 67, No. 4). At the bottom of the page, parallel results using the MusicXML export for SharpEye are given as a comparison in various notation programs.

Here is the starting scanned music: scan.pdf.

Here is the final output from SCORE: spinning.pdf (after correcting raw output files from mro2score).

For your listening pleasure, here are some online recordings of performances of the music:

Scans and SharpeEye 2.68 .MRO file:

As a starting point, sheet music is scanned in black & white. 300 DPI is usually the best scanning resolution, unless the music is printed in a small format (in which case 600 DPI should be used).

Here is a PDF of the scanned music, consisting of the following 5 TIFF images used in SharpEye:

The above images files were batch processed in SharpEye and most music notation identification errors corrected in the following .MRO file (the native file format for storing data in SharpEye):

.MRO files are ASCII files so you can directly view the contents of the .mro file in a text editor or web browser.

Note that SharpEye cannot recognize all notation elements in the music. For this example, arpeggios, stem-side staccatos, cresc. and dim. indications, and ottava marks cannot be handled in SharpEye, so therefore must be added later after the data has been converted. In addition, when beaming needs to be corrected in SharpEye, the true beam locations from the scanned music will not be reproduced, and must be corrected later in SCORE (I would recommend postprocessing of mro2score output through Tom Broadhead's BEAM program, especially when many beams need to be corrected/added in SharpEye).

Also note that there are extra rests present in the SharpEye file. I correct music notation in SharpEye using the strict rhythm analysis method. This means that the number of voices on a staff within a measure must remain constant. I add rests which are deleted later in SCORE (or made invisible if you prefer) to keep the number of voices constant. This helps prevent certain types of notational errors from being missed if a laxer rhythmic interpretation of the notation is used in SharpEye. Ideally, SharpEye should allow for invisible rests to be inserted into the data.

Running mro2score

mro2score is a Java-based program which can run on any major operating system without being recompiled. The source code and compiled versions of the programs are availble on Christian Fremerey's hompage at the University of Bonn. The program must be run from the command-line (such as from the MS-DOS prompt which SCORE users should be familiar with): 
   java -jar mro2score-0.2.1.jar -if=spinning.mro -ofs=spin%p

The options used above are:

-if
input filename for an .mro file created in SharpEye (version 2.68).

-ofs
output file scheme. The format for producing filenames for output SCORE data. %p means the current page in a multi-page .mro file.

More command-line options can be found in the documentation for mro2score.

Running the above java command, results in 10 files (5 .mus and 5 .pmx files):

The .mus files are binary and can be loaded into SCORE with commands such as "G spin001". The .pmx files are the ASCII equivalents of the .mus file. The PMX file contents can be viewed in a text editor or a web browser, and they can be loaded into SCORE with commands such as "RE spin001.pmx". The PMX files also contain the precise margin and scaling information related to the original scan's dimensions. This particular information can be used in SCORE's print menu, or stored in a .SCR file loaded in the print menu (although I don't bother preserving this information myself).

Processing mro2score output

Raw output from mro2score represents the original typesetting fairly close: The primary limitations of the conversion are in the notational recognition capabilities of SharpEye listed above. Also, For this example, the following limitations and warnings in mro2score 0.2.1 conversions should be considered when working with the resulting SCORE files:
  • Dots on rests lost (dotted-quarter rests in SharpEye converted visually to quarter rests).
  • Position of 16th-note rests are one step too low. Some 8th-note rests are one step too high (see measures 36 and 76).
  • Rests in secondary voice with notes/rests in primary voice are not P3 aligned.
  • Sometimes chord notes do not have the same P3 value.
  • Slurs are placed where they are localized in SharpEye, with P8 set to 0. A better method would be to give P8 alignment information or use P16/P17/P18 for slur offsets from chords/note P3 values. SharpEye does have problems with precise slur ending localization since slurs often end in sharp points which are distorted by scanning the music.
  • Accidentals before notes are given precise spacing information in SharpEye, which is not always identified accurately; therefore, it is useful to clear out these alteration for a more uniform spacing of accidentals (fractional part of P5 for notes).
  • mro2score uses P10 for staves to space lines of music on the page. This is different from the more common method of using P4 to adjust the spacing between staves.
  • SharpEye independently measures the scaling of each staff on the page. When mro2score converts the music on a page to SCORE data, the P5 for staves will be slightly different from each other. These values should be averaged before any refined editing of the output SCORE files.
Conditional editing commands to fix first two points in the above list:

After further corrections are made in SCORE, the final .mus and .pmx files are:

And the final PDF generated from the above files:

Comparison to MusicXML export from SharpEye 2.68

More information is transferred from SharpEye to SCORE via the internal .mro file than is typically exported via the MusicXML export from SharpEye. In particular, both SharpEye and SCORE specify the absolute location of notes on a staff/page. In MusicXML, the locations are given as a sequence of notes, with absolute positions to be determined by the program which reads the MusicXML data. Therefore, more typesetting work is involved in processing the MusicXML data rather than data derived directly from the .mro file.
  • spinning.xml -- MusicXML data exported from SharpEye 2.68.

Here again is the raw conversion from mro2score into SCORE which should be used as a comparison with the following unaltered PDFs outputs from the various programs:

Below are data files and example unedited PDFs for various notation editors generated from the above MusicXML file, as well as a PDF of the music without any processing from the original score.

SipXML2score

SipXML2score is a program written by Jan de Kloe which converts MusicXML files into SCORE .mus files. It generates one file for each system (30 files for this example), with music given a linear rhythmic spacing. The following three PDFs show some post-processing of the output from SipXML2score (Thanks to Daniel Heiman for providing the output data files from SipXML2score v4.0.0.25 which were used to create the following .pag files). The final post-processed file, spinc.pdf, is the state of the data which should be compared to the raw mro2score output, raw-mro2score.pdf.
  1. spina.pdf: First the music is recombined into pages using the COM command in score, then an identification text is removed with the conditinal editing command "IF P1=16 AND P4=-10 THEN DEL". Individual page files (load into SCORE with the command such as "G spin01a.pag"): spin01a.pag, spin02a.pag, spin03a.pag, spin04a.pag, spin05a.pag.
  2. spinb.pdf: Next, geometric musical spacing is applied to the music using the LJ command: spin01b.pag, spin02b.pag, spin03b.pag, spin04b.pag, spin05b.pag.
  3. spinc.pdf: Finally, the pages are run through Tom Broadhead's BEAM program to adjust the angle and placment of beams: spin01c.pag, spin02c.pag, spin03c.pag, spin04c.pag, spin05c.pag.
Observations on the differences between converting via the SharpEye to MusicXML to SCORE path using SipXML2score:
  1. Notes/rests in MusicXML are not given an absolute horizontal position on a staff (but system breaks are indicated in the example MusicXML file). Therefore the spacing of the music on a system is deferred to the program which loads the MusicXML file. In the SharpEye, the absolute location of notes in the scanned image are identified and stored in the .mro file. Compare the parameters describing the second note in measure 1 of the example music in SharpEye and the exported MusicXML file:
    The string "p 1 accid Flat" indicates that the note is an A-flat.

    Here is the exported MusicXML equivalent for the same note:

    Note that the spacing of the accidental (accid_dc -14) is not transferred into the exported MusicXML data.

  2. Slurs are given an orientation in the MusicXML output from SharpEye, such as the first slur in the piece: <slur type="start" number="1" orientation="over"/> Compare to the more descriptive internal representation of this slur in SharpEye: leftpt -20,188 rightpt -9,1132 radius -1896 , which specifies the left and right endpoints on the page as well as the curvature (radius) of the slur.

    SipXML2score conversion of the MusicXML seems to ignore the orientation of slurs. For example the first slur in measure 1 and 2 should go above the notes, and is so indicated in the MusicXML data exported from SharpEye:

      <slur type="start" number="1" orientation="over"/>

    The exported MusicXML file does not contain stem-length information, so the importing program must provide stem lengths (and beam placement information) automatically. SipXML2score avoids dealing with proper vertical placement of beams, deferring this layout aspect which can mostly be handled automatically by programs such as BEAM.

  3. There is an unusual overlay of an accolade (curley brace) and bracket at the start of systems.

Finale

Long slurs, such as in meausre 25 are improved in Finle 2009 over Finale 2004 (but look at measure 58). Accidentals of two notes in separate voices are incorrectly doubled (see measure 46 for example).

Sibelius

Sibelius 5 automatically repositions staccatos when they are on the stem sides of notes.

Sibelius 5 import of the MusicXML seems to ignore the orientation of slurs. For example the first slur in measure 1 and 2 should go above the notes, and is so indicated in the MusicXML data exported from SharpEye: 

 <slur type="start" number="1" orientation="over"/>

In addition, SharpEye incorrectly indicates some slurs (such as in measure 17) to be between notes from different voices/layers. Sibelius 5 import of the MusicXML has a bug which generates two slurs out of this single cross-voice slur.

MuseScore

There are unusual spacing of measures on the last couple of pages which are probably caused by trying to fill the last page with a full set of systems.

Rests in voices tend to overwrite notes in opposing voice (they are not automatically given a push above or below the default locations based on voicing layout).

Some unusual choices of beam angle (see measure 3).

Mislabeled slurs in SharpEye which switch voices are assigned to the voice to which the left part of the slur is attached.

Missing the first p dynamic in measure 1.

Missing notes in measure 5.
Revised: 9 Feb 2010