PROCEDURES AND CONVENTIONS FOR THE MUSIC-ENCODING SFSTUDY Donald Byrd, Indiana University, rev. 23 Oct. 2005 FILE AND FOLDER NAMES The OMR Page Test Status spreadsheet acts as a key to what's what as well as a running status report, so file/folder names can be simpler. Give all music files--whether notation-program files (originals or groundtruth files), scanned images, OMR program output, notation-program files, or MusicXML--names like this (excluding the extension): tttttnnPpp_ddd where ttttt is the title or type of work; nn is its number, if any; pp is the "Test Page No." (in the Status spreadsheet). ddd depends on the type of file: see the appropriate section below for details. Notice that the composer's name and the edition do not appear at all. That's because, in all cases other than temporary files on the VirtualPC, the files will be in folders and sometimes subfolder that give the composer's name and (where we're using more than one edition) the edition; they may also describe the work, at least in part. For example, the "BachSoloStrings" folder contains a "SuitesBarenreiter" subfolder that contains files like "Suite1P7-8_300.tif" (cello suite no. 1, Test Page nos. 7 and 8, scanned at 300 dpi). SCANNING Scan music in using the Mac G5 and Epson 1640XL scanner on the 3rd floor of the Music Library. * You can use either of two programs, Epson Scan or Adobe PhotoShop (with the Import Epson Scan menu command). They're almost identical, but Photoshop allows rotating the image after scanning in minute increments: very useful if the staves aren't really horizontal on the page. * In the scanning control panel, choose Text/Line Art; set Destination to Other, to allow setting the resolution (for us, normally either 300 or 600 dpi). Setting Grey Scale should give the 8-bit setting we want automatically. * Be sure the staves in the scanned image are horizontal; if not, rotate the image until they are. * Save the image as a TIFF, with IBM byte order. (We also need greyscale .bmp's and black-and-white .bmp's, but the TIFFs can be converted to .bmp form later.) * Move the TIFF to the G5, and put it in ~/Documents/Scans in a folder named unambiguously for the work, e.g., "BeethovenTrio". If we're using more than one edition, use a subfolder that identifies the edition. In the filename, ddd is the dpi resolution, followed by the string "bw" for black and white; no suffix indicates 8-bit greyscale. * Record what you've scanned in the "OMR Page Test Status" spreadsheet, in the notebook next to the G5. * For our artificial test pages, prepared with a notation program, it's probably OK to use directly-generated image files, rather than printing them out and reading them back in. * In cases where we don't have the physical pages but have been sent high- resolution scans by people elsewhere, it's OK to reduce resolution by an integer ratio, especially 2, in software; expert opinion (in e-mail of mid- June) is it should give results so close to rescanning at the lower resolution that it wouldn't matter. ----------------------------------------------------------------------- CONVERTING TIFFS TO .BMP'S On Windows, PhotoScore(?) requires .bmp's, preferably greyscale (like our TIFFs). SharpEye accepts either TIFFs or .bmp's, but actually uses only black-and-white images. If you give it a greyscale image, it converts it black-and-white as it opens it, but the manual recommends converting files in advance so you have more control of what is interpreted as black. This definitely seems to be a good idea, if only because SharpEye freezes when it tries to open full-page 600-dpi greyscale images, and--at least running on Virtual PC!--it's so slow as to be nearly unusable even with 300-dpi greyscale. Use the Mac utility GraphicConverter to convert TIFFs to .bmp's. Converting our greyscale TIFFs to greyscale .bmp's is very straightforward. Converting them to black-and-white .bmp's (for SharpEye) is not so easy unless you give up the aforementioned control and accept its default conversion; however, the results we've gotten from that have been so bad - with thousands of black specks on the page - that SharpEye couldn't handle it. Steps to generate a good black-and-white .bmp are: 1. Open the .tif, say xxxxx.tif. 2. Do Picture > Zoom > View 100%. 3. Do Effect > Black & White > Threshhold. With "full-screen preview" checked, move the slider as appropriate (the best setting seems to vary from file to file). Click OK. 4. Save the new version of the image as xxxxxbw.bmp. Record what you've converted in the "OMR Page Test Status" spreadsheet, in the notebook next to the G5. ----------------------------------------------------------------------- RUNNING OMR PROGRAMS Although our G5 has SmartScore and PhotoScore installed for OS X as well as for Windows (via Virtual PC), always use the Windows versions for OMR'ing to be saved. * If the page is not the first of the movement, it probably doesn't start with a time signature. If not, to avoid potentially-serious problems in later steps, add the correct time signature at the beginning of the page with the OMR program's editor. * With SharpEye, always use B&W input files instead of greyscale, and convert files in advance instead of letting SharpEye do it! (See "Converting TIFFs to .BMP's" above for rationale and directions.) Let Don know if you can't get good results. Exception: for very small files (much less than a full page of music), it's okay to let SharpEye do the conversion. * It's OK to spend up to 5 min. per page on "tweaking", e.g., helping PhotoScore find staves and adding the initial time signature with the OMR program's editor. Converting to B&W for SharpEye counts against the time limit. * Copy the OMR output file (.enf for SmartScore, etc.) from Virtual PC to the G5 file system, and put it in ~/Documents/SFS_documents/OMRResultFiles. In the filename, ddd indicates both resolution and which OMR program was used: "ps", "se", or "ss". For example, you might have "Suite1P7-8_300_ps.tif". * Record what you've OMR'd in the "OMR Page Test Status" spreadsheet, in the notebook next to the G5. If you've changed any of the settings of any of the OMR programs, let Don and the rest of the team know ASAP! What settings to use for each program is an undecided question, pending input from experts; rhythm handling settings are undoubtedly one of the most important options, at least PhotoScore and SharpEye (I suspect SmartScore has something like this, but it's not clear yet). ----------------------------------------------------------------------- CREATING MUSICXML FILES We're using MusicXML as input to the "music diff" program; it can also be used to print results from SharpEye (see below). With SharpEye or PhotoScore, just save the output directly as MusicXML. With SmartScore, you'll have to open the .fin file in Finale, then use Dolet to create a MusicXML file. In the filename, ddd again indicates both resolution and which OMR program was used: "ps", "se", or "ss". For example, you might have "Suite1P7-8_300_ps.xml". Caveat: PhotoScore sometimes writes MusicXML files that don't accurately represent what it found (as shown in what it displays and prints). For example, we've seen it interpret several normal 16ths in a measure as dotted 16ths; its MusicMXL makes the situation worse by putting the end of the measure after the duration indicated by the time signature, thereby forcing the last notes into the next measure. ----------------------------------------------------------------------- RULES AND GUIDELINES FOR HAND COUNTING ERRORS These rules and guidelines are intended for counting errors from printed (CMN) results, not from an abstract representation like MusicXML. A major rationale for some of the rules is to localize errors as much as possible and avoid counting "secondary errors" that result from a program failing to recognize a symbol. General Guidelines * Always do hand counting on hardcopy (paper) copies, and mark errors with colored pencils, following the codes in KeyForHandCountOMRErrors.RTF; that way, we'll have a record we can easily refer back to. * If at all possible, print the music directly from the OMR program, to avoid the chance of anything changing before it's printed. Unfortunately, this is a non-trivial consideration with both SharpEye and SmartScore. Since SharpEye doesn't even have a print command, you have no choice but to use another program to print its results. Saving as MusicXML and printing via Finale, with its excellent support for MusicXML, is the obvious choice; but Finale tries to keep measure durations from exceeding what the time signature indicates (very much along the lines of PhotoScore's MusicXML files), and this can result in missing notes in the printed results that SharpEye actually identified correctly. Be careful! On the other hand, SmartScore has a print command, but it tries to print its version of the music in the exact area of the original image; as a result, it's hard to get it to keep everything on a single page and in the area a printer can actually print on. Counting Rules 1. Differences from the original created by the program that printed the OMR'd music but that the OMR process is clearly not responsible for should be ignored. Examples we've seen include which measures have measure numbers; adding a default instrument name like "Nylon Guitar"; font changes; and even rhythm changes, the latter caused by Finale spacing things so that notes that don't fit the duration the measure "should" have appear to be in the following measure. Less clear-cut cases include secondary errors resulting from other errors, like anticipatory key signature changes for beginning-of-system "key signature changes" invented by the OMR program. 2. Count errors even in symbols that really carry any information, i.e., that should be redundant. For example, we've seen cases where--despite the fact that there are no key signature changes on the whole page--an OMR program gets the wrong signature in just one system in the middle of the page: that error should be counted. 3. Separate graphical symbols that don't correspond to anything in the original: count as "extra element", even if they aren't clearly recognizable as any musical symbol. This applies, for example, to little squiggles superimposed on beams that the OMR program might have intended to be slurs. 4. Dotted slurs in the original: ignore; also ignore anything that evidently results from them, e.g., staccato or augmentation dots. The rationale is the assumption that originals shouldn't have any dotted/dashed slurs. This is reasonable because recognizing curved dotted/dashed lines seems to be well beyond the state of optical pattern recognition. 5. Missed (or added) fingerings: ignore rather than counting as missing symbols (or extra elements). The rationale is that--for most purposes--fingerings aren't very important; we could count them as, say, 1/20 as much as a missing note, but it's not worth the effort. 6. Missed (or added) accents, articulation marks, etc.: ignore rather than counting as missing symbols (or extra elements). The rationale is that--for most purposes--they aren't very important; we could count them as, say, 1/10 as much as a missing note, but it's not worth the effort. 7. Key signature only partly correct: count as misinterpreted symbol. For example, a key signature of three flats interpreted as two flats and a sharp is one misinterpreted symbol. 8. Text string only partly correct: count as misinterpreted symbol. This applies to cases of extra, missing, and wrong characters in the string. In multi-line blocks, consider each line as a separate string. 9. If a note's pitch is wrong for any reason, including missing or extra accidentals, count it as just pitch error. Do not count these situations as missing symbols or extra elements. Exceptions: if the pitch is wrong because of a missing or extra octave sign, count the octave sign itself as a missing symbol or extra element; do not count the pitch as wrong for the affected notes. If a missing or extra accidental results in several following notes having the wrong pitch, count only the first note as having wrong pitch. 10. If a note's duration is wrong for any reason, including missing or extra augmentation dots, count it as just duration error. Do not count these situations as missing symbols or extra elements. Exceptions: if the duration is wrong because of a missing or extra tuplet sign, count the tuplet sign itself as a missing symbol or extra element; do not count the duration as wrong for the affected notes. 11. Missing extender (dashed line) following text: ignore. However, if pieces of the extender turn into accent marks, ornaments, etc., count them as misinterpreted symbol. 12. "Notes" are just that; treat rests and grace notes as "other symbols", not as notes. 13. Note with stem recognized as barline: count as both misinterpretation and missing note. There's certainly misinterpretation here, but missing a note is too important not to count it as such. Similarly, barline recognized as note with stem counts as both misinterpretation and extra note.