Score Perfect to MusicXML converter

Score Perfect was written by Klaus Kleinbrahm and first released for the Atari in 1990. It came in three editions: Education, Standard and Professional. Most people refer to the Professional edition as SPP, and this article does the same. Version 3 (1995) was also available for Windows, possibly running through Atari emulation. Version 5 (2007) was a Windows-only rewrite in Visual Basic 6.

In 2001, PriMus forked from SPP. Both SPP and PriMus can read files created before the split. SPP 5 (2007) introduced a new file format that PriMus could not read. SPP 5 Lite was also available, alongside the Standard and Professional editions.

I also came across a predecessor to SPP 1.0: Score Perfect 1.2-K (1988). It predates the release of SPP 1.0 by two years and uses yet another file format.

There are two versions of the *.SON format, not counting the predecessor: SPP 1–4 and SPP 5–7. The split between the 1–4 and 5–7 formats coincides with the rewrite of SPP in Visual Basic.

After spending countless hours comparing serial communication dumps while turning a managed EV charger into stand-alone, I could now do the same for the file format.

I started with SPP 6 by creating an empty score and saving it. Then I added a single note, saved the file again and compared the differences. Repeating this process lets you build up a list of known bytes. Once you know what to look for, you can search the corpus for those bytes. After a few days of staring at hex dumps, I began to see the basic structure of the format. I then started writing a Python script to parse it.

The file starts with a magic number, followed by blocks containing settings, staff definitions, measures, notes, text objects, parts and, finally, MIDI mixer settings.

SON file
├── Magic
├── Header
├── Settings
├── Staff definitions
├── Measures
│   ├── Measure 1
│   ├── Measure 2
│   └── ...
├── Notes
│   ├── Measure 1
│   │   ├── Note 1
│   │   ├── Note 2
│   │   └── ...
│   ├── Measure 2
│   │   ├── Note 1
│   │   ├── Note 2
│   │   └── ...
│   └── ...
├── Text objects
├── Parts
└── MIDI settings

Some blocks have a fixed length or specify their length at the start. Others can be identified by their magic number. The remaining blocks have neither, so you have to parse their contents to determine where they end. The measures block, for instance, specifies its length in measures rather than bytes, and each measure has a variable length.

Most blocks were already present in SPP 5.0, but some were added by later versions.

An interesting feature of the measures and notes blocks is that they contain a fixed amount of data for each measure (measure number, number of notes and visual width) or note (note number, pitch, duration and horizontal position), followed by zero or more optional tags. Each tag has a single function and a predictable length. I have compiled a list of observed tags, including clef changes, key signature changes, time signature changes, volta brackets, bar lines and several tags whose functions are still unknown.

Some tags can be used with both notes and measures; others are specific to one type.

Most tags were already present in SPP 5.0, but later versions introduced some additional ones.

There are two basic note types. The shorter type can hold only a single quarter, eighth or sixteenth note. The longer type can hold any number of notes of any duration.

And this is just the tip of the iceberg.

I mapped out this structure by hand and built a list of blocks and possible tags. Whenever I thought I had found a new tag, I scanned the entire corpus to see whether the pattern held.

I picked up this project again after I had created new firmware for a cheap relay board, which was my introduction to Claude Code. I used it again for this project, this time to analyse my documentation and the corpus of files. The analysis helped me identify and map missing tags, fields and blocks—work I had previously done by hand. I also used Claude Code to run statistical analyses of which tags appeared, and under what conditions.

A particularly useful demo song turned out to be Objektarten ("object types"). It shows every kind of object SPP supports, with its name alongside it. This became my reference for bar lines, dynamics, articulations, arpeggios, glissandos, ottavas and rehearsal marks.

The full versions of SPP would not accept the (valid) licence keys. I could still use them to some extent by ignoring the pop-up. Mouse input was blocked, but keyboard commands still worked.

I had previously created many test files by hand, each with slight variations, to find where specific data was stored in the file format. This time, I used AI-generated automation scripts for SPP running under Wine. It took some experimentation to get right, but I could then script the on-screen musical keyboard and all the buttons to generate many more test files. I could scan these for differences as well, which sped up the process.

Another way to investigate how things were stored would be to create MusicXML files containing the features I was interested in, import them into SPP, save them in the SPP format and analyse the results. Unfortunately, importing did not work at all in SPP 5, while SPP 6 and 7 imported only notes.

At some point, I knew most of the tags, but it was not always clear what each one did. To investigate, I took a screenshot of the original score in SPP, added or removed a single tag, took another screenshot and compared the two. I could also change tag parameters to see what effect specific values had. For example, I created six versions of the same song, each with a different clef, to work out which value corresponded to which clef.

To investigate the SPP 1–4 format, I installed several SPP 1–4 demos, which came with many more songs. I resaved all the new songs in SPP 5.1 using the SPP automation. This considerably increased the size of the corpus and made it possible to identify more of the 5–7 format.

I also exported the same files via PriMus's son2emil converter. Comparing the three versions of the same file helped me identify the older format.

The 1–4 format is quite similar to the 5–7 format. As it originated on the Atari, values are big-endian and strings mostly use the Atari character encoding. However, the structures are built in more or less the same way as those in the 5–7 format. Tones use the same numbering, which made it easy to locate that part in the files.

Working out the details involved changing individual values and reloading the files to see what had changed, but that was mostly mechanical.