User:LCantoni/Draft Revised Music Guidelines
The following are guidelines for DP projects containing music notation, with specific advice to:
Portions of these Guidelines are included or cited in the DP Official Documentation. See the Music Guidelines for Proofreaders, the Content Providing FAQ, the Project Managing FAQ, and the Post-Processing FAQ.
- 1 Introduction
- 2 Guidelines for Content Providers
- 3 Guidelines for Project Managers
- 3.1 Planning the Project
- 3.2 About Music File Formats
- 3.3 Writing the Project Comments
- 3.4 Adding Music to the Project Files
- 4 Guidelines for Proofers
- 5 Guidelines for Formatters
- 6 Guidelines for Post-Processors
- 7 Guidelines for Music Transcribers
- 8 Online Resources
While not required, having links to audio and other music-related files in an e-book provides a very rich experience for the reader. Depending on what files are provided, readers can listen to the music, print out sheet music, and download notation source files to edit and use for their own purposes.
Why do this when the original books didn't have sound? Here's why: In the days before recording and radio and other forms of sound transmission, there were far fewer ways for people to hear music other than by going to a concert, and many had few opportunities of doing even that. But most educated people had access to a piano or other musical instrument. Knowing this, authors and publishers put passages of music notation in their books so that readers could play it for themselves and enrich the experience of what they were reading.
You don't have to know music to handle a music project. DP's Music Team and Music Coordinator, LCantoni, are always ready to advise you and to help transcribe music (i.e., turn music notation into sound files). And these Guidelines are designed to help you every step of the way.
Guidelines for Content Providers
Choosing a Project
Music-related books are always welcome at DP, but you should be aware that pure music projects, such as those consisting entirely of scores or sheet music, are not feasible for DP. They are not adaptable to the distributed proofreading model, mainly because there are so few DPers who can commit to transcribing large amounts of music.
Preparing the Images
Music notation has a lot of very tiny symbols that are very important (e.g., a dot after a note, lengthening its time value; a dot over a note, indicating that it should be played short). So, to ensure that these are visible, music images should be scanned at the highest, crispest resolution possible.
If you are cropping the music images, be sure not to crop them too closely. Very often, music symbols, text directions, and even lyrics appear outside the staff boundaries. Better to have too much than too little.
Guidelines for Project Managers
Planning the Project
When you're the PM for a new project containing music, the first thing you should do is set up a plan for how you want the music to be handled by the proofers, formatters, and post-processor. The DP Music Coordinator and/or the DP Music Team can help you with your plan.
It's a good idea to get a music-capable PPer in advance who can help you decide how the project should look (and sound), and who may even be able to transcribe the music himself/herself during PP.
Failing that, try at least to get a volunteer to transcribe the music in advance, while the project is going through the rounds. A post in the Music Team forum should get reasonably quick results. The music files can then be added to the project so that they're safely stored and ready for the future post-processor.
In the final HTML e-book, the easiest way of representing music is simply to use the original image with a link to an audio file. Some PPers like to provide multiple audio formats (e.g., MP3 and MIDI); some also like to provide a PDF of the music image that can be printed out to use as sheet music; and some also like to provide a MusicXML file so that the music notation can be downloaded and imported into any music notation software. It's a good idea to work with the PPer and/or music transcriber to make these decisions in advance.
The next section explains the differences among the various music file formats.
About Music File Formats
Some PMs have specified that they want the music transcribed using a particular notation program, such as Lilypond. This is not advisable, as specifying a particular program or format will reduce considerably the already-small pool of available music transcribers. If you are tempted, you should at least be aware of the advantages and disadvantages of the most commonly used formats before you decide to do this. See the sections on Music Notation Software and Longevity for information on the most commonly used programs and the future utility of their output.
Below is a review of some of the most common audio/visual formats for music in DP projects. All of them are accepted at PG as of this writing (April 2020).
The high-quality sound of MP3 (.mp3) files makes them ideal, especially where the music is more complex (e.g., orchestral music), and a more realistic and reliable sound is desirable. MP3 files are WYHIWYG - what you hear is what you get. Unlike with MIDI, the sound of an MP3 file is not dependent on the particular sound fonts a listener might have installed - it will sound the same on any device.
MP3 files are significantly larger than MIDI files, but significantly smaller than WAV files.
See Johann Sebastian Bach: The Organist and His Works for the Organ for an example of the use of MP3s in a PG e-text.
MIDI files (.midi or .mid) are universally playable and their file size is small, making them a practical choice for representing music in an e-book.
But, given the current popularity of MP3 and the increased bandwidth of most people's Internet connections, MIDI is no longer ideal for that purpose. While MIDI is capable of reproducing a wide range of instrumental sounds, the quality of those sounds will depend entirely on the individual user's sound card and sound fonts. This is because a MIDI file is not really an audio recording; it's actually a set of digital commands telling a computer what sounds to play and how. That makes MIDI highly flexible for professional composing and sound editing, but that's not as important for our e-book purposes. In short, unlike with MP3 and other audio file formats, what you hear when you play a MIDI file is not necessarily what someone else will hear.
There is nothing wrong with providing MIDI in a project, especially if that's the only format a music transcriber can provide with his or her particular music software, but you should be aware of this limitation.
MIDI files can be imported into a number of music notation programs in order to create an editable score, but the user will have to do significant editing and add in all the text elements. MusicXML is better for this purpose.
Note also that some browsers these days won't automatically play MIDI files. The user may have to adjust some browser settings, install a plugin, or download the file to play in an external media player.
See Navaho Legends for an example of a music project with both MIDI and MP3 files.
WAV (.wav) audio files have high quality sound, much like MP3, but with a very large file size that make them less practical for use with e-books.
Some full-featured music notation programs, like MuseScore, Finale, and Sibelius, generate high-quality audio files in .wav format. It would be wise to use audio-conversion software (such as the free audio editor Audacity) to convert WAV files into MP3 files before including them in a project.
MusicXML (.mxl, formerly .xml) is now the primary Internet standard for sharing music notation code. It is readable and/or writable by over 240 music programs, enabling music notation to be widely shared, making it ideal for PG e-books. It means that just about anyone can download the notation to their preferred software to correct any errors in the music or use the music for whatever purpose they wish.
A MusicXML file contains nearly all the musical and text elements in a music piece. The code can be viewed in any text editor and most browsers, and there are plug-ins allowing browsers to play/display MusicXML files as music. (Theoretically, a MusicXML file can also be created from scratch in a text editor, but it would be a very laborious process.)
While MusicXML import/export is generally very good, some elements may not be automatically generated, so the user who downloads a MusicXML file to his/her preferred music software is likely to have to do some editing.
See Johann Sebastian Bach: The Organist and His Works for the Organ for an example of the use of MusicXML in a PG e-text.
PDF files (.pdf) are downloadable, printable versions of the engraved music that the reader can use as sheet music. They can be created with many music notation programs.
PDFs are most useful where the book contains complete music pieces. See Indian Story and Song for an example of a project with PDF files created from Finale music notation software.
The original music images can also be combined into a PDF file for use as sheet music. This can be useful where there are many pages of music, and the PPer wants to avoid long image-loading delays in the HTML. In Music and Some Highly Musical People, for example, there were 149 pages of music. The PPer opted to display in the HTML just the first page of each piece, with a link to a PDF containing the original images of the full piece.
Other Notation Files
Proprietary notation source files for certain music programs are also accepted at PG, including Lilypond (.ly), Finale (.mus), and Sibelius (.sib) files. But it will rarely be necessary or even advisable to include these file formats when MusicXML enables virtually universal notation sharing.
One of the concerns about music files in DP projects is whether they'll be usable by the largest number of people for the longest possible time. Some call this "the 100-year rule." Among audio formats, MIDI and MP3 certainly meet this test; their use is widespread, and they've both been around for decades. MusicXML, which has been in existence for over 16 years, has also become a long-lasting Internet standard for music notation, because it is XML-based and, as noted above, is now readable and/or writeable by over 240 music notation programs.
There was once a belief that Lilypond, being open-source and text-based, met the "100-year-rule." But unfortunately that's not the case. While Lilypond is an excellent program, one of its major drawbacks is that it's not backwardly compatible, i.e., code created in older versions of Lilypond is not automatically readable by newer versions. There is a conversion utility to update Lilypond files, but it isn't perfect; a fair amount of code-tweaking is necessary, and the older the original version, the less likely it is that the automatic conversion will be successful. Moreover, if the old source file doesn't contain a \version statement, the conversion utility will not work at all. A case in point: The Liberty Minstrel was transcribed in Lilypond around 2004, but didn't come into PP until 2007. Lilypond had gone through several incarnations in the interim. There were no version statements in the old source files, so the conversion utility couldn't be used to update them. Volunteers had to re-transcribe over 70 songs by hand to make them compatible with the current version of Lilypond.
PMs and PPers concerned about future utility should keep these factors in mind when deciding what music notation files to include in a project.
A Note about E-Pub and Mobi
Note that, as of this writing (May 2020), many e-reading devices that use the epub or mobi e-book format don't support links to external files, which means that readers using such devices won't be able to hear, view, or download music-related files. But PMs and PPers should still include sound and other music-related files in their projects, at least to enhance the HTML version, and in the hope that someday, epub and mobi will catch up to HTML in providing a rich e-book experience with external resources.
Writing the Project Comments
Once you have a plan in place, your Project Comments should be very specific about what you expect from the proofers, formatters, and PPer. Again, getting a PPer on board beforehand will be very helpful in formulating clear instructions. The DP Music Team can also help you with this.
Look through the project:
- How much music is there?
- Are the music illustrations snippets, or full pieces, or a combination?
- Does the music have lyrics, titles, composer credits, or other text elements that should be proofed?
- Has the author put music illustrations in the middle of a sentence or paragraph to illustrate a point?
- Are there music symbols (flats, sharps, and so forth) in the text?
The Project Comments must be clear on how to handle these issues.
Writing Instructions for Proofers
Music images are treated as illustrations, so the proofers won't be involved in formatting the markup. But if the music illustrations have text elements, you'll want them proofed.
The common practice is to have the proofers proof only:
- composer, arranger, lyricist, or other credits
- copyright information or other text information about the piece
- captions such as "Fig. 1" or "(2)" or the like
Purely musical directions, such as tempo markings (e.g. Allegro), instrument designations (e.g. Voice, Piano), and dynamics (e.g. crescendo) are generally excluded from proofing.
Specify in the Project Comments what the proofers can expect to find and what you want proofed.
Lyrics present special issues. In music notation, syllables are hyphenated to match the notes, and dashes or long ellipses are often used to indicate a held note. Proofers frequently ask questions on how to handle these, so it's important to be clear about what you (and/or the PPer) want.
There are two schools of thought on how lyrics should be proofed:
- Ignore hyphens, dashes, and ellipses. For example, if the lyrics in the original read, "Ma-ry had a lit-tle lamb whose fleece was white as snow......" they are proofed as "Mary had a little lamb whose fleece was white as snow." Some people prefer this method because it's much easier to read, and because, in the plaintext version of the e-book, syllable divisions won't make sense without a music illustration. Moreover, hyphenation is often erratic or even wrong in the original, because it's often dependent on how much room the printer had.
- Match the scan. All hyphens, dashes, and ellipses are rendered as they appear in the original. Some people prefer this method because it is as close as possible to the original and easy for the proofers to follow (just match the scan). Also, music notation programs usually require the addition of hyphens for the lyrics to appear correctly under the notes. This method allows the music transcriber to simply copy and paste the pre-hyphenated lyrics into the notation program (editing to add missing hyphens or correct wrong ones in the original).
If you don't specify what you want, the default instructions for proofers (essentially, match the scan except for ellipses) are in the official Music Guidelines for Proofreaders.
Music symbols in the text will require special handling, as they'll need to be represented somehow in the plaintext version, and the PPer will need to be able to find them for HTML treatment.
Some suggested methods for proofing common music symbols:
- Sharp (♯): [sharp]
- Flat (♭): [flat]
- Natural(♮): [natural]
- Double sharp (): [double-sharp]
- Double flat (♭♭): [double-flat]
- Time signatures expressed in numbers, like
- Time signatures expressed in symbols: 𝄴 [common time], 𝄵 [cut time]
The Project Comments should also mention that other music symbols in the text should be proofed with the name in brackets if the proofer knows what it is, e.g. [crescendo], or simply with [**music symbol] so the PPer can find it and add the name in later. For example:
62. The sign [crescendo-decrescendo] over a note indicates that the tone is to be begun softly, gradually increased in power, and as gradually decreased again, ending as softly as it began. In vocal music this effect is called <i>messa di voce</i>.
There are also two methods of representing musical notes in text that can be useful in providing a text description, if desired, of a one- or two-note music example:
which is G above middle C, could be represented in text as [Music: G4] or [Music: g´].
This may be a bit too advanced for the proofers, however, so it is probably best to leave it up to the PPer (with the assistance of a music transcriber, if needed) to include this information. (Note: The PPer should also include a transcriber's note explaining the system used.)
Writing Instructions for Formatters
The formatters will be concerned with three issues:
- Adding [Music] markup.
- Marking lyrics as poetry, where appropriate.
- Determining whether the music illustration should remain in its original place, or be moved to the nearest paragraph break.
The [Music] Tag
While some PMs and PPers prefer to have music notation images marked with the [Illustration] tag, there are great advantages to giving music notation its own markup, [Music]. This makes the music easier to find so that the PPer knows where to add links to the music files. Be sure to specify this in the Project Comments for the formatters.
Text elements in the music (title, composer, lyrics, copyright, etc.) that aren't musical directions should be included within the [Music] tag. For example:
[Music: MAKING BUTTER. <sc>Emilie Poulsson.</sc> <sc>C.C. Roeske.</sc> /* 1. Skim, skim, skim, With the skimmer bright; Take the rich and yellow cream, Leave the milk so white. */ ]
For music continued on or from another page, formatters can use the same convention used for continued footnotes, i.e. *[Music] or [Music]*.
It's important to specify in the Project Comments how lyrics should be formatted. In general, multiple-line lyrics should be marked up as poetry, using /* tags as in the example above. Single-line lyrics will not need /* markup.
You should also specify in the Project Comments whether you want the formatters to insert poetry line breaks in multiple-line lyrics, or simply match the scan. As can be seen in the "Making Butter" example above, and the "Lauriett" example below, line breaks in the lyrics depend on the length of the musical staff; one line of music may encompass more than one line of lyrics.
If you want the formatters to create line breaks, give them a guide as to how to do it. Usually a new line of lyrics begins with a capital letter. The rhyming scheme is also helpful in determining where the line breaks should go. Sometimes additional verses are set forth in text below the music image; these can also be a good guide as to where line breaks should go.
If the music image has multiple verses of lyrics, you need to specify how you want them formatted: separate them, or match the scan. For example, the lyrics in this image:
can be formatted to match the scan:
/* 1. Lauriett! Ah! my 2. Fare thee well! Ah, my dearest, I will often think of thee, When dearest, Wilt thou often think of me, When I'm */
/* 1. Lauriett! Ah! my dearest, I will often think of thee, When 2. Fare thee well! Ah, my dearest, Wilt thou often think of me, When I'm */
or separated with poetry line breaks:
/* 1. Lauriett! Ah! my dearest, I will often think of thee, When 2. Fare thee well! Ah, my dearest, Wilt thou often think of me, When I'm */
Whichever you choose, the important thing is to make sure the instructions in the Project Comments are clear.
Music in the Middle of a Paragraph
Sometimes music illustrations, like regular illustrations, are moved to the nearest paragraph break. But the Project Comments should be clear that music illustrations that are used in the middle of a sentence or paragraph to illustrate a point (if they exist in your project) should NOT be moved. For example:
101. Other varieties of measure sometimes found are 9/8 and 12/8, but these are practically always taken as three-beat and four-beat measures respectively, being equivalent to these if each group of three tones is thought of as a triplet. [Music] is identical in effect with [Music]
Writing Instructions for Post-Processors
Even if you've engaged a PPer in advance, you should lay out your PPing requirements in the Project Comments, in case the project is later reassigned to another PPer. Many PMs simply ask that at least audio files be included, and leave the rest up to the PPer. If you do have further requirements for the final product, include them in the Project Comments. Most importantly, you should specify all the file formats you want included in the e-book, such as MP3 and MusicXML (see Music File Formats above).
The best and easiest way of representing music in the HTML is the original image with a link to an audio file. Not only does that stay true to the original book, it also avoids the PPer and music transcriber having to worry unnecessarily about recreating the appearance of the music.
That said, if the original images are hard to read, due to poor quality, or an archaic notation style like medieval neumes, you might like to have a clean music image in modern notation to include with the project in addition to the original images. If you do, be sure to say so in the Project Comments.
Remember, the more you require, the more work for the PPer and the music transcriber, and the longer it will take for the project to get posted. Before you insist on images created from notation software, or the use of a particular notation program, think about whether it's justified. Here's a summary of the basic guidelines:
- The original music image should always be used.
- Where the original image is of poor quality, it can still be used along with a clean image created by notation software. Bear in mind, however, that while most notation software can engrave modern notation very well, attempting to reproduce old-style or non-standard notation may not be successful, and could incur a disproportionate amount of effort.
- If the original image contains archaic notation, the addition of an image of modern notation created by notation software, while not required, can be useful to the reader.
- PDF files can also be a useful addition where the music is a complete piece, and you want the reader to be able to view or print a piece out as sheet music.
- Avoid requiring the use of particular notation software. As noted above, you'll reduce the already small pool of potential music transcribers if you do. See the Music Notation Software section for the advantages and disadvantages of different programs.
Adding Music to the Project Files
If you've asked for music to be transcribed in advance, it's important to have a safe repository for the music files. Keeping them on someone's home computer is far from optimal; people leave DP, their hard drives die, things get accidentally erased. And while your DPScans folder is one way to store these files, there's still the possibility of accidental deletion.
To solve this problem, you should ask Db-req to add the music files to the project's extra files. The PPer will then be able to download the music files along with all the other project files.
Here's how to do it:
- Make sure the music file filenames are all lower case.
- Zip up the music files, naming the zip file with the project ID number and the word "music", e.g., projectIDxxxx_music.zip. (Copy and paste the project ID number from the project page to avoid typos.)
- Put the zip file in your DPScans folder. If you don't have one, upload the zip file to online external storage, such as your personal webspace or Dropbox, so that a db-req Squirrel can download it. Do NOT send it as an email attachment to db-req!
- Send an e-mail to db-req asking that the music files be added to the project's extra files. Be sure to include your DP username, the project name and ID number, and the location of the zip file, e.g. DPScans, Dropbox, etc. For Dropbox or other external locations, be sure to provide the direct link for downloading the zip file.
- If you're the PM, put a note in the Project Comments telling the future PPer that the music files are in the project's extra files. If you're not the PM, mention in your email to db-req that the PCs should be updated. You can also post in the Project Discussion that you've asked db-req to add the files.
- Do not delete the zip file until you've confirmed that the music files have been added to the project.
Guidelines for Proofers
The primary directive for proofers, as for any project, is to follow the Project Comments and read the Project Discussion. The PM will, ideally, have given specific instructions on how to proof any text elements in the music.
In the absence of specific instructions, proofers should do the following when encountering music in a project:
- Treat music illustrations as illustrations; that is, leave the markup to the formatters.
- Proof text elements such as the title, composer, and any lyrics.
- Lyrics are often hyphenated to indicate that the syllables are to be sung on different notes; leave the hyphens in, unless otherwise instructed.
- You may also encounter ellipses or long dashes in lyrics, indicating that a single syllable is to be sung on more than one note (a "melisma"). These can be ignored.
- Ignore text elements that are actually part of the music, such as tempo and dynamic markings (e.g., Allegro, rit., cresc., p, f, dim., etc.). If you're not sure, leave it in, with a [**note].
- Mark music symbols in the text as [**music symbol], or, if you know the name of the symbol, include it, e.g., [**crescendo].
- Ask in the Project Discussion, or leave a [**note], for anything you're not sure of.
- See Music Guidelines re: Writing Instructions for Proofers for more information.
Guidelines for Formatters
The primary directive for formatters, as it is for proofers, is to follow the Project Comments and read the Project Discussion.
If the PM has not given specific instructions on formatting music, formatters should follow these basic guidelines:
- Mark music illustrations as [Music].
- Include any text elements (title, composer, lyrics) within the [Music] tag, e.g., [Music: Liebestraum].
- Format any lyrics as poetry, using /* markup, and match the original line breaks unless otherwise instructed. Multiple verses (usually numbered 1, 2, etc.) should be separated.
- If the music appears in the middle of a sentence or paragraph as part of the text, leave it there. Standalone music illustrations can be moved to the nearest paragraph break.
- Do not add music notation code, such as Lilypond. The music may already have been done, or is planned to be done in a different manner. If you'd like to transcribe the music — and your help would be most welcome! — contact the PM, the PPer, the DP Music Coordinator (LCantoni), or the DP Music Team, before you do anything.
- Ask in the Project Discussion, or leave a [**note], for anything you're not sure of.
- See Writing Instructions for Formatters for more information.
Guidelines for Post-Processors
Most of the considerations discussed above in the Guidelines for Project Managers apply with equal force to PPers, especially where the PM has deferred to the PPer's preferences. Please review the Guidelines for Project Managers before you start the PP process.
It's also a good idea to browse through all the page images to make sure you know where all the music images are, including music symbols in the text, before you start PPing.
Explain in a Transcriber's Note how musical symbols in the text are represented. (The proofers may have already taken care of inserting the symbol names.) While you can use a generic [musical symbol] tag, it'll be a much richer experience for the reader if you give a more specific description, such as [crescendo] or [flat]. The Dolmetsch Chart of Musical Symbols is a handy resource, or, if you're still not sure, post in the Music Team forum.
For accessibility purposes in the HTML, be sure that the text elements of the music (title, composer, lyrics, etc.) are laid out in the main text of the HTML. See Our Old Nursery Rhymes for an example.
Lyrics can be placed either directly below the music image, or in a separate section at the end of your document (in which case be sure to place a clear "go to lyrics" link from the area of the original image).
It's best to use the original images, unless they're of unacceptable quality. Nothing represents the original better than the original.
Don't crop music images too closely; keep a sharp eye out for music and text elements (such as lyrics) that are outside the staff margins.
Make sure the image resolution and size are sufficient for the reader to clearly see all of the music, including the little dots and so forth. You can display a small image and link to a larger one if necessary. Don't make the images too big, or they'll overwhelm the page. An image width of no more than 600px (where the music extends the full width of a page in the original) usually does the trick.
A simple border around the music image can be attractive. See Our Old Nursery Rhymes for an example.
When preparing the HTML version of the e-book, create a separate "music" folder containing the audio files (mp3 or midi) you want to include.
Then, in the HTML, create visible links to the audio files near the music notation image. You may also want to link to MusicXML, PDF, notation source, or additional image files. Explain these links in a Transcriber's Note at the beginning of the HTML file. See Our Old Nursery Rhymes for an example of how this can be done.
As noted above, at the time of this writing (May 2020), music file links will not work in mobile e-book formats like epub or Kindle/mobi. You may want to note this in a Transcriber's Note for users who are reading the e-book in one of these formats.
There are a few Unicode glyphs for common musical symbols that can be used in the HTML text:
- flat (♭)
- sharp (♯)
- natural (♮)
- quarter note (♩)
- eighth note (♪)
You can use in-line illustrations for other symbols. See Music Notation and Terminology for an example.
Finding a Music Transcriber
If you need volunteers to transcribe the music for you, post in the Music Team forum. And please be sure to ask the transcriber whether and how he or she should be listed in the credit line, e.g., "Music transcribed by X."
Guidelines for Music Transcribers
Note: Although you need not be a professional musician to transcribe music at DP, these guidelines assume that you can read music notation, at least at an elementary level.
Before you transcribe music for a DP project:
- Look over the music and make sure that your music notation software is capable of rendering it. If you're not sure about something, post in the Music Team forum, with a link to the music page.
- Check whether the music continues on the following page(s). A single piece of music spanning several pages has to be transcribed as one piece, so that you can produce a single audio file.
- Review the text pages surrounding the music for additional clues as to how it should be handled (tempo, instruments, etc.), if this information is not apparent from the music itself.
- Use online resources to help determine how the music is supposed to sound, if it's not already familiar to you. For example, if the music is by a classical composer whose works are in the public domain, the IMSLP/Petrucci Music Library has a huge selection of free scores in PDF format, which you can use to double-check possible printer errors in the project, determine the correct tempo, etc. YouTube is also a great resource for actual performances of just about any kind of music.
- Don't be shy about asking for credit. You worked hard on the music and deserve kudos for it. Let the PM or PPer you're working with know how you want to be listed in the project credits (e.g., with your real name or your DP name), or, on the other hand, that you'd prefer not to be credited at all.
- Please don't take it upon yourself to transcribe music for a project without checking with the PM, the PPer, or the DP Music Team first. It may well be that the music is already being, or has already been, transcribed. You don't want to duplicate efforts.
Music Notation Software
If you're an old hand at transcribing music on a computer, you already have your favorite notation software (also known as scorewriters). For those who are new at it, or who want to try something different, here is a short guide to some popular programs. This is by no means a complete list - there are many, many notation programs out there. You can find a comparison of a number of them here.
MuseScore is a free, open-source, WYSIWYG notation program with a user-friendly interface quite similar to professional programs like Finale. It can handle just about any of the music likely to be encountered in DP projects.
- Free and open-source
- Easy-to-use graphical interface
- Operable on Windows, MacOS, Linux, and other platforms
- Available in many different languages
- Note entry via computer keyboard, mouse, MIDI keyboard, or virtual piano keyboard
- Can handle complex music, including jazz, percussion, and early music notation
- Can export MP3 and WAV audio files, among others
- Can import and export MIDI and MusicXML, among others
- Supports Unicode fonts for text and lyrics
- Extensive, easy-to-read documentation
- Active community support forums
- Extendable with free plugins
- Free mobile score viewer/player
- No direct user support
- No built-in integration with music-scanning software
- Mobile app has no editing function
- Some users have reported poor-quality audio results
Lilypond is a free, open-source, text-based notation program. Using any text editor, you type in the codes for the notes and other music features, save the file with an .ly extension, and run it with the Lilypond software to produce a PDF file with the music image and a MIDI file with the sound. It can handle just about any of the music you're likely to encounter in a DP project.
- Free and open-source
- Produces attractive, clear engraving in a PDF file
- Generates MIDI files
- Can handle most complex music
- Operable on numerous OS platforms
- Extensive documentation
- Active user mailing list for support, with archives
- Can import MIDI and MusicXML
- Accepts Unicode fonts for text and lyrics
- Very time-consuming to learn and use
- No built-in graphical interface
- Code is complex and continually changing
- Documentation is not always clear, and it can be difficult to find what you need in the manual
- Not backwardly compatible — older Lilypond files will not run in later versions
- Converter program to update older Lilypond files does not perform a complete conversion, and automatic conversion is impossible if the older file does not contain a version statement, so code will have to be re-entered manually
- Some features are not reproducible in MIDI
- Cannot create MusicXML files
The lack of a graphical interface is a pretty big downside: You can't see what you've done until you compile the code, and if you make certain kinds of errors, the code will not compile at all (though the error will be listed in a log file). There are, however, some free third-party applications that provide a graphical interface for Lilypond, such as Denemo and Frescobaldi.
Important Note: It is essential that Lilypond files contain a \version statement so that the source files can be converted for use with later versions of Lilypond.
Professional Notation Programs
- Easy to learn and use
- WYSIWYG interface
- Easy entry of music via mouse, computer keyboard, or midi instrument
- Can handle any kind of music, no matter how complex
- Can import and export MIDI and MusicXML
- Supports music OCR — printed music can be scanned and converted to editable notation
- Can create high-quality audio files, like MP3 or WAV
- Includes high-quality, realistic instrument sounds in addition to the MIDI instrument set
- Can play back music as you work
- Can create image and PDF files
- Powerful page-layout controls
- Backwardly compatible
- Extensive documentation and user forums
- Many other features too numerous to mention here
- Windows and Mac only
- Special music fonts, such as for medieval neumes and figured bass, must be purchased separately from third parties
Both Finale and Sibelius have a variety of less expensive or free incarnations, such as Finale PrintMusic, Finale Notepad, Sibelius First, and Sibelius Scorch. Though not as powerful as the full-featured versions, these "light" versions have many useful features and can be more than adequate for most DP music work.
Optical Music Recognition
Formerly known as "music OCR," optical music recognition, or "OMR," is the process of digitally recognizing musical symbols from a scanned music image and turning it into editable notation.
There are a number of commercially available OMR programs, but you should be aware that OMR is nowhere near as reliable as OCR - and we know from our work at DP that even OCR, as highly developed as it is, has its drawbacks.
User experience with OMR has shown that in many instances it is much quicker just to enter the notation manually than it is to edit the OMR output. The error rate tends to increase dramatically with complex music or the kind of low-resolution score images we often encounter in older books.
Given these factors, at this time the use of OMR is not recommended for anything but the simplest music with the clearest images.
Handling Printer Errors
Just as with text, there can be printer errors in music. Unlike with text, however, it may not be possible to just leave the error in place - the audio file may sound terrible if you don't correct the error.
First, however, make sure it's an error. Sometimes dissonances are deliberate. Sometimes a bar deliberately contains more fewer beats than the key signature indicates (as in cadenzas, or in partial or pickup bars). If you're not sure, post in the Music Team forum, with a link to the music page.
As you work, keep a running list of printer errors and embody them in a transcriber's note that the PPer can include in the project. Describe exactly where the error is (giving system, bar, and beat numbers), why it's an error, and what (if anything) you did to correct it.
The transcriber's note can be in a separate text file, or you can add it to the MusicXML file for the particular piece.
Because we work with older books at DP, you'll frequently come across archaic music notation symbols, such as old-style clefs, rests, and time signatures. If you're not sure what a symbol stands for, check the Dolmetsch Chart of Musical Symbols, or post in the Music Team forum.
Depending on your notation software, you may not be able to reproduce these symbols exactly as they appear in the original. In cases where you're creating only an audio file, that doesn't matter, as long as you can accurately reproduce the intended sound in modern notation.
If, however, you've been asked to produce a MusicXML or image file, you should note in a Transcriber's Note that your software cannot reproduce the symbol, and that you've used a modern equivalent instead.
Medieval Notation (Neumes)
You may also come across medieval music notation, also known (in its various forms) as neumes, Gregorian chant, or mensural notation. Here's an example:
In most instances, in order to create an audio file from medieval notation, you'll have to enter modern notes in your notation program. Note that, because medieval transcribers often assumed familiarity with note durations based on custom, the durations may have to be guessed. Here's how the example above would look in modern notation, with a Transcriber's Note regarding note durations:
If you can't read medieval notation, post in the Music Team forum to find someone to help you.
Note: Some handwritten medieval notation may be too unclear to decipher accurately, or may require expertise beyond our volunteers' capability. In that case, it may not be possible to create an audio file. If the tune is well-known, however, an Internet search may come up with a modern image or a sound file to help you decipher the notation.
In the Baroque period, figured bass was a shorthand way of representing accompaniment in the bass staff, by placing just one note in the staff, with one or more numbers underneath it representing the other notes in a chord or figure. Here's an example:
As with medieval notation, there is limited, if any, support for playable figured bass in most notation programs. If your software doesn't support it, the solution is to create the audio file by entering the full accompaniment into your notation software. Here's an example of figured bass in modern notation (note the use of multiple voices):
If you need help interpreting (the technical term is "realizing") figured bass, post in the Music Team forum.
Below are just a few of the vast number of music resources on the Internet.
Dolmetsch Online has an extensive collection of music resources, including:
- Chart of Note Ranges (scroll down to the two staff lines near the bottom of the page) - This is extremely helpful in rendering notes in plaintext, using either scientific notation (middle C is C4), or Helmholtz notation (middle C is c´). It's also helpful in identifying notes that are far above or below the staff line.
Scores and Performances
- IMSLP/Petrucci Music Library - Huge selection of free, public-domain scores and recordings of classical music. Helpful for error-checking or where a scan is unclear.
- Choral Wiki - Large selection of free, public-domain choral scores.
- YouTube - Free videos of music performances in all genres. Helpful in determining tempo and feel.
- OperaGlass - Large selection of opera libretti. Very useful for checking opera lyrics.
- Art Song Central - Archive of free, public-domain art-song sheet music, managed by DP Music Team founder David Newman.