GSoC 2018: Score Comparison Tool — Work Product

This post is a summary of the work that was done on my GSoC 2018 project. Here I’ll try to explain briefly which goals were set for this project, what was accomplished and which tasks are still left for the future work.

Project description

The problem this project is devoted to is a musical score comparison. Comparison of scores (most often different versions of the same score) is needed for a number of applications both in personal and collaborative work on musical score sheets. Concerning that problem this project has two main goals:
1. Altering MSCX file format used by MuseScore for storing scores to make it more usable with regular textual diff tools.
2. Implementing a tool built into MuseScore editor which would provide an user interface for scores comparison.
The second goal has two stages which include creation of textual tool and implementation of a visual selection of differences between scores. The second stage is considered to be optional though it was included to the end of the timeline provided in my proposal.
Some extra information is available at the following locations:
- Original idea for the project.
- Forum discussions (part 1, part 2).
- This blog posts.

Actual results

To make it easier to find the necessary information the results below will be presented as a list including a brief description of changes and some relevant links.
1. Changing MSCX fileformat for better comparability.
Pull request: https://github.com/musescore/MuseScore/pull/3760 (not merged as for August 13)
Changes (mostly described here):
- Eliminating various elements numbering from MSCX code (e.g. measure numbers, spanners or beams IDs, links IDs etc.)
- Identifying spanners endpoints by their positions. To make it more clear, the term “spanner” is the common name for slurs, hairpins, volta marks and other elements that span for some length.
- Eliminating probably all track numbers by enclosing all elements in <voice> tags to define their attachment to the specific voice.
- Renaming <move> tag denoting changes in current position in a score to <location> and changing its syntax to make it use only relative distances. This <location> tag is now used in various contexts where location definition is needed including spanner endpoints identification.
- Miscellaneous minor changes.
2. Score comparison tool
Pull request: https://github.com/musescore/MuseScore/pull/3862 (not merged as for August 13)
Changes:
- Creation of an engine for performing a comparison of scores.
- Creation of a tool built into MuseScore for score comparison. A brief description of the tool is available here.
- Adding command-line options to MuseScore for performing scores comparison in the non-GUI mode.
3. Minor changes
These changes are various bugfixes and other small changes not necessarily directly related to this project. They are contained in the following pull requests (all of them have been merged into MuseScore code):
- https://github.com/musescore/MuseScore/pull/3686
Fixes a crash I experienced while preparing a test case for my code.
- https://github.com/musescore/MuseScore/pull/3712
Backport of the patch I had submitted to the recent version of MuseScore some time before.
- https://github.com/musescore/MuseScore/pull/3719
Fixes a crash related to the code I worked with during the first part of my project.
- https://github.com/musescore/MuseScore/pull/3791
Fixes an old typo which prevented me from making use of score objects’ inheritance tree.

Remaining tasks and issues

While the score comparison tool is already in usable state there is a number of issues which are better to be resolved in the future. Here is a brief list of such issues:
1. Simple textual diff of MSCX code is not as good as it could be.
While after the changes made during this project MSCX format became more friendly for performing a textual comparison it is still not perfect for it. The solution is though probably not in changing MSCX format but in changing the used tools and libraries. There are two kinds of problems:
MSCX is an XML-based format.
- Simple textual diff tools and libraries can produce semantically incorrect output for XML-based formats, and an XML-specific comparison tool is better to be used for comparison of MSCX files.
- One entity can appear several times in MSCX file. For example, one measure’s content is listed in several parts of MSCX file, separately for each staff.
While the score comparison engine tries to address the first issue and the second issue should lead to wrong results in rare cases, these issues are still not fully resolved. It would probably be better to switch to XML-specific diff library in the future. Perhaps some work on overcoming the second issue will also be needed.
2. Human-readable representation of score elements’ properties.
For displaying changes in the score comparison tool various kinds of score elements’ properties should be represented in a human-readable way. MuseScore code contains a framework for a unified handling of various kinds of properties. As a part of this project this framework was extended to provide a unified way for obtaining human-readable representations of various properties but such representations are still not defined for all possible properties types. This work is still to be finished in the future.
3. Visual selection of changes between scores.
The current implementation of the score comparison tool provides a feature providing a visual selection of a chosen score diff item. Based on that a fully visual comparison mode could be implemented to show differences between scores by visual signs only. This is not still implemented and is left for the future work.

Evaluation of results

Making conclusions concerning the project’s completeness depends on a choice of the list of goals. While writing a proposal I included start of a work on the fully visual comparison mode to the project’s plan. My GSoC mentors have always considered this part optional so in the latter descriptions I marked this part optional too. The last part has not actually been completed. I was able to construct a score comparison tool with differences represented in a textual way and was able to get working a visual selection of any specific change but it was never assembled to a fully visual comparison mode. This mode was listed by me in the list of possible future tasks for this projects’ further development.

Anyway, as a result of this project there is a usable score comparison tool and a framework for comparing scores and interpreting comparison results in a way that allows mapping differences to actual objects in the compared scores. This framework should make a development of features like the mentioned visual comparison mode much easier. Resolving the issues mentioned in the previous section should make MuseScore be able to provide high-quality results for comparing almost all kinds of scores though it is already able to yield good results for scores comparison or at least find the relevant area if it still fails to detect changes correctly. Changes made to MSCX file format made it more friendly for performing textual comparison of MSCX-encoded scores and potentially allow both further development of comparison- and versionizing-related features and usage of MSCX scores with traditional version control systems for advanced users.

To sum up, the project can be considered complete if the last part of it is considered optional, and is mostly complete strictly according to the timeline I provided in my initial proposal.

Thank you,
Dmitri Ovodok