File formats are part technical and part subject specific. Knowing how a file format is encoded often doesn’t give you much unless you understand the purpose of the software which made it. Take music software, I can dig into the bytes and tell you some interesting details about patterns and metadata, but I really don’t know much of what it means. If there is one subject I was born with zero natural ability, it is music. We have covered formats such as Finale and Sibelius on this blog before, for which I have the same problem. Luckily they had fairly neat understandable byte sequences to work with. Not so much with the next on my list to discuss.
Music software came in the early days of the Macintosh. Finale came in 1988, but so did another score writer, NoteWriter. NoteWriter was written by Dr. Keith Hamel, a Canadian composer, in late 1988. He later wrote:
The main flaw in existing notation software is that the designs of the systems do not adequately encompass the scope and variety of musical notation. … In order to design a music-editing and printing system which could accommodate the entire corpus of existing music notation, the system must permit a variety of notation syntaxes.
NoteWriter was easy to use and fast, according to those who knew how to write music. Around 1996, NoteWriter was replaced with NoteAbilityPro, which was original written for NextStep computers and later for the Macintosh and MacOS X. More on it later.
NoteWriter worked a little differently than other score writing software, it used a graphics-oriented method of writing music. Often referred to as the MacPaint or MacDraw of music. This is important because each document produced by the software will also contain the images used to display the notes.
Let’s start by looking at the bytes of a sample file.
% hexdump -C NW269-s01 | head
00000000 00 60 00 c0 01 20 01 80 01 e0 02 40 02 a0 03 00 |.`... .....@....|
00000010 03 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.`..............|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 00 00 00 01 00 01 00 02 00 02 00 03 00 03 00 04 |................|
00000060 00 04 00 05 00 05 00 06 00 06 00 07 00 07 00 08 |................|
00000070 00 08 00 09 00 09 00 00 00 00 00 00 00 00 00 00 |................|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000000a0 00 00 00 58 00 30 02 f8 00 09 03 30 04 20 00 08 |...X.0.....0. ..|
Here is another.
% hexdump -C NoteWriter\ II\ Samples/Early\ Music | head
00000000 00 1d 00 71 00 d5 01 29 01 8d 01 e1 00 00 00 00 |...q.?.)...?....|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 00 00 00 01 00 02 00 03 00 04 00 05 00 06 00 07 |................|
00000060 00 08 00 09 00 0a 00 00 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000000a0 00 00 00 00 00 30 03 00 00 0a 03 30 04 20 00 08 |.....0.....0. ..|
000000b0 00 17 01 13 00 e6 00 01 00 26 00 2d 00 49 00 01 |.....?...&.-.I..|
000000c0 00 02 00 60 03 c0 00 03 00 00 00 00 00 00 00 00 |...`.?..........|
You may notice the samples don’t have much in the way of human readable strings or a consistent set of bytes at the beginning of the file. This will make identification more difficult. After comparing a few files together, I was unsure what to use as a pattern for a signature, so I decided to try a new approach. I reached out to the author.
Dr. Keith Hamel was kind enough to help me understand some of the bytes I was looking at. It turns out there is a 366 byte FileData section at the beginning of the file. This is where my lack of music ability becomes a problem. I was introduced to terms like “Staves”, “Flat Key”, “CMajor”, “Staff” starts and ends, etc. I struggle understanding what each of these terms meant on the page, let alone how they might affect a document.
I decided to start making new sample files while changing a few of these parameters. This helped me understand where in the 366 byte header each of these changes reside. Changing the number of pages, for example, changed the last two bytes of the header. Changing the number of “Staves”, which I now know is the basic line of music, changes a 2 byte value at offset 168.
Since the document can have so many different variations, using number of pages can vary, the page size might be different outside the US, margins can change, etc, so I need to find something more simple or static.
In the documentation provided to me, there are a few values which seem to stay constant. One is a dummy value at offset 190, which is always 1, and the MSVersion, which indicates the version of the format. I was told, that there was an early version but it was quickly replaced, so majority if not all the files in the wild should conform to version 2. I also found there is a default indent and where the page “rectangle” starts on the top/left of every document all seem to stay static. I could just use the dummy value and version, but 00010002, seems like it may not be enough to be definitive.
Looking at a sample to see these values:
% hexdump -C NW269-st1
*
000000a0 00 00 00 58 00 30 02 f8 00 09 03 30 04 20 00 08 |...X.0.?...0. ..|
000000b0 00 17 01 8c 01 9b 00 01 00 26 00 2d 00 49 00 01 |.........&.-.I..|
000000c0 00 02 00 60 00 30 00 03 00 01 00 01 00 01 00 01 |...`.0..........|
000000d0 00 01 00 01 00 01 00 01 00 01 00 00 00 00 00 00 |................|
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
So to break it down:
- Orange = Indent ( 00 30 )
- Yellow = Outside Rectangle Top/Left ( 00 08 00 17 )
- Blue = Dummy ( 00 01 )
- Purple = MSVersion ( 00 02 )
If we were to write this in the PRONOM syntax it would be: 0030{8}00080017{12}00010002 This should make a decent signature, it works for all my samples. 🤞 If you have any Notewriter samples, please let me know if they follow this pattern.
Coming next, NoteAbilityPro and its NextStep roots.