OpenScore: Happy Birthday Gabriel Fauré!

Gabriel_Fauré_302.jpg

Gabriel Fauré (12 May 1845 – 4 November 1924)

We went public with OpenScore back in February at FOSDEM 2017, when we told the world about our plan to liberate public domain sheet music. Since then, we’ve been really busy spreading the word, meeting up with partners and other interested parties, creating demos and showcase projects, and generally getting everything ready for the upcoming launch of the Kickstarter campaign (not long to wait now!).

Pilot transcription

While all that’s been going on, we’ve also been running a small pilot to make sure the whole transcription process is as smooth as possible. A small number of MuseScore.com members were invited to take part in a trial transcription of Fauré’s Requiem. As today is Gabriel Fauré’s 172nd Birthday, we thought it would be appropriate to share it with you now. (Please be aware that this is an unfinished preview version and as such is likely to contain lots of errors and layout problems. We need your help to get it ready for final release! More on this below.)

https://musescore.com/user/16916841/scores/3896176

Process

Starting with a PDF scan of the original score from IMSLP, we divided it up into small chunks, each just a few pages in length. These were sent out to the volunteer transcribers, along with an empty MuseScore template document with all the instruments already added. The transcribers were given a few days to complete their pages and upload them to be checked by a member of the admin team. If no errors were found then transcription was accepted straight away and the transcriber was rewarded with a month of MuseScore PRO membership. If errors were found then score was sent back to the transcriber along with comments about what they needed to improve, and they were given a bit more time to make those improvements and get the reward.

We were really impressed with what we saw, and in one or two cases we were able to accept the transcription straight away. However, in most cases there were at least a few mistakes, or places where the transcriber hadn’t been aware that there was a better way to do whatever it was that they had been trying to do. However, they all did a great job of making the changes we asked for, and we didn’t have to reject any transcriptions!

Guidelines

If you are interested in transcribing then you might like to take a look at this set of guidelines which I put together to help transcribers. The guidelines describe the most common errors we saw in transcriptions and explain how to avoid them.

Peer review

Once the transcriptions have been collected and joined together, it's time to check the full score to look for:

  • Errors that escaped notice during the first check
  • Inconsistencies between sections transcribed by different people
  • Issues that arise during the joining process

We'll need your help to be able to spot all these things and put them right. We'll soon launch a new tool for MuseScore.com which will allow you to click on the exact part of a score where a problem lies and leave a comment to bring it to our attention.

Publishing an OpenScore Edition

The final step in the process of creating an OpenScore Edition is to give it a nice cover page. For this purpose, we're teaming up with Nicholas Rougeux, a digital artist and web designer based in Chicago. Nicholas created visualisations of sheet music for his Off The Staff project, and he has agreed to create a visualisation of each OpenScore Edition.

Faures_Requiem_600.png

Visualisation of Fauré’s Requiem by Nicholas Rougeux

The visualisation should be read clockwise starting from the 12 o’clock position. Each circle represents a note in the score; the size of the circle represents the duration of the note, while the pitch is indicated by the distance from the centre of the image.

Read on OpenScore blog: https://www.openscore.cc/blog/2017/5/15/openscore-happy-birthday-gabriel...

Previous Section Next
OpenScore: Join the transcription effort! shoogle's blog OpenScore: First editions available! How to submit...

Comments

"you might like to take a look at this set of guidelines which I put together to help transcribers" where?

I was a bit naughty and submitted the post unfinished just before midnight so it would still be Faure's birthday. It looks like you caught me! We didn't actually realise it was his birthday until about 3pm so then it was a race to get everything ready. ;)

You still have almost five more hours here. I guess it only counts as his birthday as long as it's today in France though. :B

The link is there now, and I like it :-). Probably you'll figure out other additions as you get more submissions and realize what other common errors you see. But I think this - the project as a whole, and the guidelines in particular - is off to a great start!

Oh, very excellent transcription already! As a blind musician, I can use NVDA to read most of things in it, and convert it into braille via Musicxml. But there's one problem with dynamic signs: When I navigate to a vocal part at the very beginning, NVDA reads the dynamic as "other dynamic", and the xml export doesn't generate any appropriate dynamic signs. This will make both your and my braille transcription incomplete, since I don't know whether the dynamic is ppp or fff or mp or other. Why Musescore treat it as "other"? Or it's not a dynamic at all? Just a question, because I'm also launching a braille music project, and will use some of the Open Scores too, to make a very detailed and carefully-edited braille publication. The project is also open and free.

Regards
Haipeng

Looks like this was entered manually as "pp sostenuto". I guess we currently look at the text to see if it matches one of the standard choices and if not, we internally classify it as "other". Probably we should improve the screenreader to read the actual text in those cases.

Yes, I found a non-standard tag in the musicxml pointing as sostenuto, entered in the other dynamics field. THis is not a standard property, and can't be read and imported by other softwares, including braille transcription tools. If one enters such long words in dynamics field, we should put them into the standard w element. In Sibelius, we enter text by categories, and dynamics are in Expression. If we type "pp sostenuto", then either the whole text goes into tag, or "pp" in Dynamics, and Sostenuto in "words". Both can be imported and translated in other formats, including braille. Now I should first sum up such texts in the xml and make lots of search and replace tasks, removing < (lt) and > (gt) sings, creplacing dynamicPiano to p, to to let BrailleMuse recognize them.

Haipeng

I just look into the score again, and the braille transcription server was just updated today. It can export tag, but there are lots of < > signs enclosing things like "dynamicPiano". In fact, if just using pp sostenuto in this field, I can still get the correct braille now. The current code can't be correctly recognized by any softwares.

How will the choice be made when there are various editions of a composition to chose from?

IMLSP may have an urtext edition, early editions and various editions revised by authorities on the composer.
Sometimes IMSLP may not highlight that there are notation differences in the available pieces - with further background information also not available. E.g. Melody in F by Rubinstein is on the IMSLP but each piece has slight differences. I cannot find any information on which edition might be seen as an authoritative edition - otherwise I would have created a version for upload by now. http://imslp.org/wiki/2_M%C3%A9lodies,Op.3(Rubinstein,_Anton)

Will there be a commentary created to highlight necessary corrections and editorial decisions?

The OpenScore edition will be made from the "best" version available on IMSLP. Once the best version has been chosen, it will be reproduced as faithfully as possible; no corrections (except perhaps for the most blatant mistakes, like typos in lyrics), and certainly no editorial decisions (except for global editorial decisions like using a separate staff for each instrument).

If you take two different editions of the same work I would expect at least 80% of the symbols and 95% of the notes to be the same, so selecting the "right" edition is not perhaps as important as it might seem. The main concern is "how easy is it to transcribe?", so when determining the best version we give most consideration the quality of the scan and the readability of the notation. We also pay attention to the score's 5 star rating on IMSLP and the number of times it has been downloaded.

These choices have been made to ensure consistency and make the job easier for the transcribers, the goal being to maximise the accuracy of the transcriptions and the speed with which they are produced. We are not trying to make beautiful engravings or the ultimate critical editions, but we see the OpenScore editions as a starting point for other people who want to take them and do just that. If someone wants to create a transcription based off a different edition, or multiple editions, they can take the OpenScore edition and would only need to change at most 20% of the symbols and 5% of the notes.

Will you be able to add musescore transcripts on the IMSLP site?

http://imslp.org/wiki/Category:User_MuseScore ?
eg.:
http://imslp.org/wiki/6_Sonatas_for_2_Bassoons,Op.6(Braun,_Jean-Daniel)

@chiosa IMSLP will be fetching a feed from the scores uploaded on the OpenScore account on MuseScore, and download the uploaded and revised scores onto their servers. So the answer is yes, all OpenScore files will be made available on IMSLP as well.

Thanks, though, but I was wondering if the imslp site will also be available .mscz files (or maybe they are present and have not seen them)

Syndicate content