Archive for November, 2012


[My choral colleague, Steve Roth, contributed the guest post below on how he scans and distributes sheet music to the iPad/tablet users in our chorus.  He includes detailed step-by-step instructions – note that you’ll need to have some proficiency with command-line tools in order to use his process.

Listen to Steve – he’s da man!  I scanned and prepped my 264-page vocal score of Handel’s Messiah using some basic compression methods and it ended up at 57 MB (will write that up later).  Steve scanned and prepped a 175-page vocal score of Bach’s St. Matthew Passion – and it came in at under 7 MB.

Steve, many, many thanks to you for sharing your knowledge with us!]

Hi, folks,

Tech4Singers and I sing in the same chorus, and there’s a steadily growing proportion of iPad sheet music users in the chorus (currently about 20%). We all use forScore, which is a superb sheet music reader for the iPad, and as you’ll see below, there’s considerable advantage in having everyone use the same software. I’m the guy who’s (unofficially) responsible for providing the electronic music for all of those singers. Often that involves scanning paper music. Following up on Tech4Singers’ recent request, I thought I’d share here the full details of how I do the scanning. Please note that I make no claims that this is the best way; it’s just one way that works, using tools I’m familiar with.

Before diving into the details, I have to offer a note on legalities. Most paper music is under someone’s copyright, and scanning the music for use on an iPad is in a legal gray zone. Personally, I content myself with following the spirit of the copyright law: I only scan works for which I actually have a paper copy. If the paper copy is borrowed (e.g. from our chorus library), then I only keep the scan for as long as I have the paper copy checked out. And while I don’t attempt to enforce it, I remind my fellow choristers using my scans that they should do the same. I am not claiming that this is compliant with copyright law; I’m not a lawyer and I haven’t found one that will give me a straight answer. But I do assert that it gives due respect to the copyright holders, and that’s good enough for me.

Most sheet music is in one of three formats:

  • 8½ by 11 inches, single sheets
  • 11 by 17 inches, folded (each side of each sheet has two 8½ by 11 pages of music)
  • 10ish by 14ish inches, folded (each side has two 7ish by 10ish pages)

The single sheet music can be handled by pretty much any scanner with a sheet feeder. For the other two formats, though, you need a scanner that can handle large format paper. In this post I’ll discuss handling a 10 by 14 inch folded score, because that’s the most complex case as well as the most common.

Begin by removing any staples or bindings so that you can feed the sheets through the scanner’s sheet feeder. You should also briefly counter-fold them (fold them the opposite way from the way they came) so that they are relatively flat when they go through the sheet feeder; that helps prevent jams. (By the way, yes, a sheet feeder really is a requirement, and so is removing the binding. If you try to put pages on the scanner glass yourself, I guarantee you your pages will not be exactly straight. It’s even worse if you put a bound score on the scanner glass.) [Editor’s note: there are tools that will help you deskew crooked scans – but it’s preferable not to have them be crooked in the first place.]

My scanner settings are 200dpi, black and white. Color (or even gray scale) is not needed for scores, and it makes them vastly bigger (and therefore slower). I have found 200dpi to be a good compromise between size and sharpness, but you could consider using 300dpi for scores with tiny print. It is critical not to let the scanner use any form of lossy compression (like JPEG). Scans should either be uncompressed or should use some lossless compression (PNG, GIF, TIF).

For the rest of the process, you can use any tool that allows you to make batch changes to large numbers of image files at once. My preference, used in the examples below, is the ImageMagick suite.

Step 1 (if necessary, depending on your scanner’s output format): Separate each side of each sheet into a separate image file. (Assuming your source was folded sheets, each image file will have two pages.)

$ convert +adjoin multisheet-file singlesheet-filename-prefix

Step 2: Crop the images to the appropriate width. Measure the width of the double-page sheet and multiple by the resolution of the scan. For our 10×14 example at 200dpi, that would be 2000 pixels. Crop the height of the images to that amount, keeping the width unchanged.

 $ identify file
 $ mogrify -crop widthxheight+0+0 files...

where width is the width of the sheet reported by the identify command and height is the desired height. Note this keeps the top part of the image and discards the bottom; that should be correct for most sheet-fed scanners.

Step 3: Examine each image and rotate them all to the proper orientation. Typically the even-numbered sheets go one way and the odd-numbered sheets go the other. Clockwise rotation is

 $ mogrify -rotate 90 -page +0+0 files...

Counter-clockwise uses negative 90.

Step 4: Measure the height of the sheet, less any margin you want to discard, multiply by the scan resolution, and crop that much out of the middle of the images:

$ mogrify -crop widthxheight+0+offset -page +0+0 files...

where width is the height calculated in step 2 (we’ve rotated it since then); height is the desired height, and offset is the offset needed for that height to be taken from the center of the image, generally half of the difference between current and desired heights (but possibly different if the part you want to keep is off-center).

Step 5: Split the double-page images into single-page images:

$ convert +adjoin -crop widthxheight files... output-file-prefix

where width is half the current image width and height is the (unchanged) current image height. The resulting files will be named with your specified prefix and a numeric suffix. We also need to tell ImageMagick to reset the page bounding box to the image bounding box:

$ mogrify -page +0+0 output-file-prefix*

Step 6: Manually examine the pages and renumber them to correct order. Sorry, it’s tedious, but I haven’t found a good way to avoid it.

Step 7: Create the PDF, using CCITT Group 4 compression (which does a much better job on monochrome, line-art-like images than any other I’ve seen).

$ convert files... output-file.pdf

Step 8: If you’re preparing for use in forScore, add metadata to the PDF so that forScore knows the name and composer of the piece. Use any PDF editing tool for this purpose, setting the “Title” and “Author” metadata respectively. Personally, I use pdftk:

$ pdftk input.pdf dump_data output info-file

[Editor’s note: PDF Info for Windows is another free and slightly more user-friendly tool for doing this.]  Edit the info-file to add key/value pairs for Title and Author.

$ pdftk input.pdf update_info info-file output output.pdf

In our chorus’s case, we’re usually distributing an entire concert’s worth of music at one time, so I take some additional steps to make this easy for our users. I put all of the individual PDFs on a web server and load them into my forScore using its browser. I go through each of them and add any annotations that everyone will want (such as advance markings from the director, or Links for handling repeats).  [Editor’s note: Adding links to the PDF score prior to distribution is an extremely helpful thing for a choral librarian to do.  During a read-through, it saves singers from having to scramble to find the first page of a repeat section, 1st/2nd endings, etc.]  In some cases, for multi-movement works, I’ll make chapters within the PDF file so that it’s easy to jump to a movement. Then I make a forScore “setlist” containing all of the pieces (in the proper order if that’s known), and use forScore’s Dropbox feature to upload the setlist to my Dropbox, turning on the switch that tells it to include the scores as part of the setlist file. The resulting “.4ss” file is a single file our users can install in their forScore and get the entire concert’s scanned music, with annotations. (I occasionally see odd errors with this import, but they go away if forScore is killed and restarted.)

I’m sure there are lots of ways that all of this could be streamlined, and maybe better tools to use for all or part of it. Nevertheless, this is what I’ve been doing, and I hope it will at least give you some ideas.

Related Posts:

Credit: Samsung Belgium

The Brussels Philharmonic is replacing sheet music with tablets – Samsung Galaxy Note 10.1 tablets, to be precise.  This is the first I’ve heard of a performing arts organization of this size embracing 100% adoption of tablet-based digital sheet music for its musicians.  It will be interesting to see where this leads and how successful the initiative is.

They are using NeoScores as their music reading app.  It’s not yet available to the public, but there’s a demo that works on my desktop web browser but not on my iPad (as of 11/11/12).  You can also sign up for updates.

BBC has a video news segment that shows the orchestra playing from the tablets (and also has a sound bite from the timpani player about trying not to mess up the page turns): Brussels Philharmonic replaces sheet music with tablets

CNET also has an article: Orchestra swaps sheet music for the Galaxy Note 10.1

Samsung has an official press release as well as a photo set on Flickr showing the orchestra using the tablets.  The Brussels Philharmonic has their own official press release too.

Technology in Music Education (where I first got wind of this) has some good commentary about it here: Brussels Philharmonic uses Samsung Galaxy Tablets for Performing  He astutely points out that most of the above video footage and photos of the Brussels Philharmonic is from a staged photo op – not too surprising, given how prominently the Samsung marketing people are featured.  I was fantasizing that the “civilians” seated on stage among the musicians were usability experts from Samsung or NeoScores studying the players’ interactions with the tablets for ways to make them smoother and easier.  But I suppose they’re just Samsung execs.

Here’s another video that doesn’t show much of the tablets, but does show a lot of interesting footage about the whole process of preparing parts for an orchestra:

Brussels Philharmonic Rewrites Music History with GALAXY Note 10.1 (4:10)


Related Posts:


When reading a PDF music score on a iPad/tablet, it’s beneficial to crop out the page margins so that the printed music will expand to fill as much screen space as possible and be easier to read.  Some PDF score-reading apps like forScore for iPad have a sort of “virtual cropping” feature that displays the pages as if they had been cropped.  Also, several PDF software tools will actually process a PDF document to crop the margins on either individual pages or the document as a whole.

I particularly like two tools, Briss and PDF Scissors, because they can do bulk margin cropping of all pages in a PDF file, and even better, they have a transparent stacked-page preview mode that lets you see at a glance whether your cropped document will include all the page numbers, rehearsal letters, bass clef notes/staff, and other important information that tends to live near the margins of the page (see screenshots below).  If you’ve ever gone into a rehearsal with a cropped PDF score and realized too late that those pieces of information got cropped too, you’ll understand just how useful this is.  And, (more…)


This is a follow-on to my earlier post, When smaller means slower: performance of Acrobat-optimized PDF files in forScore, which is about how certain PDF data compression options can slow down the loading and page-turning of your PDF music score files, even though they shrink the file size.

My singer colleague Steve R. shared some helpful information for making PDF scores small AND fast.  He is in the process of scanning a 175-page vocal score of a large-scale choral work.  That’s a lot of pages, so he needs a way to shrink it down to a small file that will load up quickly on an iPad or other tablet and not be sluggish and unusable in rehearsal and performance.  One of his steps is to scan the score in black-and-white at 200 dpi resolution.

The other step is to use an option known as Fax Group 4 data compression, or G4.  Here are some technical details about G4:

  • G4 is a data compression method originally designed for older fax machines with limited computing power.  That’s why it works so well on today’s tablets – it requires minimal computing power to decompress the file, which keeps it from slowing down the tablet.
  • G4 is optimized for black-and-white images.
  • G4 is lossless, meaning that it will shrink the file without degrading the image quality.
  • Steve tried all of the data compression options available with his scanning tools, and G4 yielded the smallest file.

I’m not sure what hardware or software Steve used to access the G4 option (Steve, maybe you can fill us in?). [UPDATE 11/9/12: @Lorskyfink reports: “I noticed that Acrobat Pro’s “Save As…Optimized PDF” has the option of using CCITT 4 for the monochrome images.”  (CCITT 4 is a type of G4 encoding.)]

And thanks, Steve, for sharing your findings with us!

Related Posts:

Just a quick post to share this tweet from @Lorskyfink.  (You can view a larger image of the iPad mini with sheet music here.) [UPDATE 11/9/2012: @Lorskyfink made the further comment: “Well, to be fair, some feel the regular iPad isn’t big enough for sheet music. You have to have the eyes for it. :-)” I replied that the photo reminds me of one of those paperback-book-sized study scores, which not everyone may find big enough for performance use.] [UPDATE 12/19/2012: This post has another photo from @Lorskyfink that shows a regular iPad and an iPad Mini side-by-side displaying the same sheet music.]

In case anyone was wondering, the iPad is actually big enough and clear enough for sheet music.

Credit: @Lorskyfink on Twitter

Related Posts: