TypeStyler

August 21, 2026 by Thor 1 Comment

I make a lot of sample files. Whenever I have access to software I haven’t sampled before, I immediately make a few files to keep for reference. If I am making a signature for those files, I try and find as many versions of the software out there and make sample files from each. This way I can ensure the signature is accurate and possibly distinguish between important version changes. This process works well, but takes some time.

I discovered a flaw in my process recently, which illustrates the need for enough variation in samples to make sense of the file format. I recently made a bunch of samples from an old Macintosh software tool called TypeStyler. It is a pretty amazing early Desktop Publishing tool, with a neat past. The problem turned out to be more revealing about the format than I realized.

TypeStyler was the product of two brothers, Dave and Ken Stillman developed in 1988. It was a very incredible program that helped the Macintosh be a leader in Desktop Publishing and design. They had already made a program called PosterMaker which they sold to Broderbund, and TypeStyler did well under the same Publisher. When the Macintosh turned its focus to MacOS X, the software stalled for a number of years, finally coming back under the Strider Software name.

Let’s take a look at one of the files from version 1.0 of the software.

% hexdump -C TS1-s02 | head
00000000  02 da 02 28 00 00 00 00  00 00 02 35 02 da 02 28  |.?.(.......5.?.(|
00000010  00 00 00 64 02 da 02 28  00 00 00 00 ff ff ff ff  |...d.?.(....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 00  |????????????....|
000000b0  00 01 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |.........x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

The first thing I noticed was a repeating pattern. 02 DA 02 28. This pattern seemed important. I could also see it in later versions, but not always exactly the same.

% hexdump -C TS3-s01 | head
00000000  02 d8 02 28 25 21 00 01  00 00 02 db 02 d8 02 28  |.?.(%!.....?.?.(|
00000010  00 00 00 64 02 d8 02 28  00 00 00 00 ff ff ff ff  |...d.?.(....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 80  |????????????....|
000000b0  00 10 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |.........x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 d8 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

I could see this pattern in many of the samples but not all of them, but it seemed inconsistent, not following a pattern based on version. It was then I realized I had seen the pattern before. Specially the pattern seen on line 200 or the 516th byte.

% hexdump -C TS1-s02 | head
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

If you look back at two of the other formats I have discussed on this blog. MORE and Ready, Set, Go! you would see the same pattern in those sample files as well.

% hexdump -C RSG1-s01 | head
00000000  00 78 00 03 00 00 00 48  00 48 00 00 00 00 02 da  |.x.....H.H.....?|
00000010  02 28 ff e1 ff e2 02 f9  02 46 03 47 05 28 03 fc  |.(????.?.F.G.(.?|
00000020  00 02 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000030  00 01 00 00 00 64 00 00  00 01 00 01 01 01 00 00  |.....d..........|
00000040  00 01 27 0f 00 01 00 01  00 00 00 00 00 00 00 00  |..'.............|
00000050  00 00 00 00 00 02 00 19  01 90 00 00 00 00 00 40  |...............@|
00000060  00 00 00 00 00 00 00 00  00 01 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 01 00 01 00 48  |...............H|
00000080  00 48 00 48 00 48 00 01  00 00 00 01 00 00 00 01  |.H.H.H..........|
00000090  00 00 00 01 00 00 00 00  00 00 00 00 00 00 00 00  |................|

% hexdump -C MORE3-s01 | head
00000000  00 06 4d 4f 52 33 00 80  00 00 00 80 00 00 00 78  |..MOR3.........x|
00000010  00 00 00 f8 00 00 01 b4  00 00 02 ac 00 00 00 a8  |...?...?...?...?|
00000020  00 00 11 16 00 00 00 32  00 00 11 48 00 00 00 20  |.......2...H... |
00000030  00 00 11 68 00 00 00 00  00 00 11 68 00 00 00 10  |...h.......h....|
00000040  00 00 11 83 00 00 00 0c  00 00 11 68 00 00 00 00  |...........h....|
00000050  00 00 00 00 00 00 03 54  00 00 0d c2 00 00 11 78  |.......T...?...x|
00000060  00 00 00 0b 00 00 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  |................|
00000080  00 03 00 00 00 48 00 48  00 00 00 00 02 d8 02 28  |.....H.H.....?.(|
00000090  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

How can this same pattern be found in three completely different software titles, from three different developers? Granted they are all originally Macintosh software, but still, there shouldn’t be any common encoding between them. I will admit it took me a minute to figure it out, and I did employ the use of AI to help brainstorm the pattern.

I should have seen it sooner as my background is in commercial printing and I have been using desktop publishing tools for years. You see the most common value in printing with Postscript is the value “72”. 72 is the number of points in an inch which all started with the development of Postscript, originally on a Macintosh. The hexadecimal “00 48” is 72 in decimal in big endian systems like the Macintosh. So the first part of the pattern seen in all three formats is 72×72 values indicating the unit of measurement. The next 4 bytes happen to be the page size in points. “02 DA” is decimal 730 and “02 28” is decimal 552. If you add 60 points used in margins, then you get roughly 8.5×11 letter sized page size. You can see the change here if I save a letter size page out with one portrait and one landscape.

% hexdump -C TS-Letter-Vert | head
00000000  02 da 02 28 00 00 00 00  00 00 02 3d 02 23 01 9e  |.?.(.......=.#..|
00000010  00 00 00 4b 02 da 02 28  00 00 00 00 ff ff ff ff  |...K.?.(....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 a3  |????????????...?|
000000b0  00 20 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |. .......x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 da 02 28  |.....H.H.....?.(|
00000210  ff e1 ff e2 02 f9 02 46  03 47 05 28 03 fc 00 02  |????.?.F.G.(.?..|

% hexdump -C TS-Letter-Horz | head
00000000  02 28 02 da 00 00 00 00  00 00 02 3d 01 9e 02 23  |.(.?.......=...#|
00000010  00 00 00 4b 02 28 02 da  00 00 00 00 ff ff ff ff  |...K.(.?....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 a3  |????????????...?|
000000b0  00 20 00 00 00 00 00 00  00 78 00 00 00 00 00 00  |. .......x......|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 03 00 00 00 48 00 48  00 00 00 00 02 28 02 da  |.....H.H.....(.?|
00000210  ff e2 ff e1 02 46 02 f9  03 45 05 28 03 fc 00 02  |????.F.?.E.(.?..|

The bytes are swapped! Very cool to figure out, but not so helpful in identification as the values could be different in every file. You may have noticed the values in the 4th set of 4 bytes was different in these samples. A little experimentation and it looks like those 4 bytes are the value of what level of zoom is displayed in the software. If at 100%, which is often default, then the values would be the same as the page size, at 50%, they would be half. So also not helpful in identification, but helpful to document.

There are other bytes we can use for identification, the 3rd set of 4 bytes, after many samples made, appear to be representative of the version of software that created the file. The value increases with each version.

% hexdump -C TS1-s01 | head
00000000  02 d0 02 40 00 00 00 00  00 00 02 35 00 b4 00 90  |.?.@.......5.?..|

% hexdump -C TS2-s01 | head
00000000  02 d8 02 28 00 00 00 01  00 00 02 3b 02 22 01 9e  |.?.(.......;."..|

% hexdump -C TS3-s01 | head
00000000  02 d8 02 28 25 21 00 01  00 00 02 db 02 d8 02 28  |.?.(%!.....?.?.(|

% hexdump -C TS372-s01 | head
00000000  02 d8 02 28 00 00 00 00  00 00 02 f9 02 d8 02 28  |.?.(.......?.?.(|

TypeStyler 3.7.2 was the last version before the 9+ year gap before the next release, version 10. So these files will all have the value “00 00 02” then 34 through the hex values up to F9. Many of the point releases I have been able to make samples of have values spanning this gap.

Version	Value	Version	Value	Version	Value
1.0 Beta	00000234	2.0.1	0000023B	3.46.3	000002DB
1.0	00000235	3.2.1	0000023D	3.5.8	000002DC
1.5.2	00000239	3.43.2	000002DA	3.7.2	000002F9

These values are probably a little short for a solid identification. If you have been paying attention, you might have noticed each TypeStyler file also has a large sequence of “FF” values. Majority have 144 bytes worth, starting at offset 28 or 0x1C, there are a random couple files which are slightly different. I think with the two parts, a fine signature can be made and not accidentally identify one of these other desktop publishing formats.

Well, in 2009, the Strider Software company released their TypeStyler software built for MacOS X intel computers after a long hiatus. They added many more features which also meant a change to the file format. No longer did they use a single file to store the graphics, they used the commonly used Apple Package format. In essence a folder with an extension, which when registered with the Mac, appears as a single file. This way you can add all the files you like to the folder and it stays together. Seemed like a good idea at the time.

% tree TypeStyler11-s01.tsdx 
TypeStyler11-s01.tsdx
├── QuickLook
│   └── Thumbnail.png
├── Template
└── contents
    ├── PkgInfo
    ├── TSDoc.tsx
    └── TypeStyler Document.xml

4 directories, 4 files

This new package format has a structure with thumbnail and a contents folder. This folder has an extension of TSDX and within the contents folder an XML file, a PkgInfo, and a TSX file. Let’s look at each of them.

% cat TypeStyler11-s01.tsdx/contents/PkgInfo 
????????%  

% cat TypeStyler11-s01.tsdx/contents/TypeStyler\ Document.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Application Version</key>
	<string>10.0</string>
	<key>images</key>
	<dict/>
</dict>
</plist>

% hexdump -C TypeStyler11-s01.tsdx/contents/TSDoc.tsx | head
00000000  03 18 02 64 24 03 00 01  00 00 03 36 03 18 02 64  |...d$......6...d|
00000010  00 00 00 64 03 18 02 64  00 00 00 00 ff ff ff ff  |...d...d....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 bf  |????????????...?|
000000b0  00 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |. ..............|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000e0  00 00 00 00 00 00 00 00  00 00 32 5c 0c 5c 5f 64  |..........2\.\_d|
000000f0  64 64 64 64 64 64 19 19  5c 5c 5c 46 1e 00 42 c8  |dddddd..\\\F..B?|

The PkgInfo file is unhelpful. The XML is semi-helpful, but considering this was a version 11.6 file, the XML displays only 10.0 which I think is in all the samples I have.

The best identification comes from the TSX file, which excitingly looks like the previously format. We have pages sizes in the same place as well as the 144 bytes of “FF” and the values for the version show “00 00 03 36”. This seems to make sense with 03 being a natural increase to the 02 used in the previous versions. Looking at a sample from version 10:

% hexdump -C TyperStyler10-s01.tsdx/contents/TSDoc.tsx | head
00000000  03 18 02 64 00 00 00 01  00 00 03 30 03 18 02 64  |...d.......0...d|
00000010  00 00 00 64 03 18 02 64  00 00 00 00 ff ff ff ff  |...d...d....????|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |????????????????|
*
000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff 01 01 00 3c  |????????????...<|
000000b0  00 20 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |. ..............|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  b3 08 00 00 00 00 00 4d  00 22 01 59 02 33 00 4c  |?......M.".Y.3.L|
00000210  00 21 01 58 02 33 cc d3  e2 06 10 00 00 00 00 00  |.!.X.3???.......|

The version pattern starts fresh with 30! The TypeStyler software is still available, but appears to have stalled again. Version 11.6 was the last version released in 2019, so another 7 year hiatus. Ken Stillman passed away in 2023, further adding to the uncertainty of the future of TypeStyler.

This was a fun exploration of a format beyond the simple identification I usually focus on. With some of the variations I found I came up with this signature for Versions 1-3 of the TypeStyler Document format starting from offset 8

000002[30:FF]{16-20}FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

This signature takes into account the hex values 30 through FF to cover all the incremental updates. Instead of using all 144 bytes of “FF”, I limited it to just 64 bytes to allow for the couple of variations I found. I am not addressing versions 10-11 yet, ther eis no great way of identifying package formats with PRONOM yet. I may add the TSX format by itself, but for now you can find the signature and sample files on my Github page.

Finale

February 9, 2024 by Thor 4 Comments

The amazing Ashley recently did a little writeup on the Sibelius music notation software. I thought I would take the opportunity to talk about another music notation software which needs a little update. Finale was created in 1987 for the Macintosh by a company called Coda Music and became quite popular with musicians and composers. The ability to use a computer to typeset a musical score was a huge advancement. This was all possible by the use of music notation fonts.

Finale was originally written by Coda Music Technology, owned for a time by Net4Music, now currently owned by MakeMusic. Over the years there has been additional products developed along side Finale.

The first version of Finale was developed for the Macintosh and didn’t have an extension. But by version 3.5 there was a comparable Windows version and the use of the extension .MUS. In order to share the files between the different platforms Finale also created an ETF file, which instead of the binary MUS the ETF is a plain text “transportable” file.

Both formats are based on the Enigma or “Environment for Notation Intuitive Graphic Music Algorithms” format. These formats were last used with Finale 2012 when a new format took over in 2014. Let’s start from the beginning.

hexdump -C Finale1-s01 | head
00000000  46 69 6e 61 6c 65 aa 20  31 2e 30 2e 30 20 45 4e  |Finale. 1.0.0 EN|
00000010  49 47 41 20 53 74 72 75  63 74 75 72 65 73 20 43  |IGA Structures C|
00000020  6f 70 79 72 69 67 68 74  20 31 39 38 37 20 62 79  |opyright 1987 by|
00000030  20 43 6f 64 61 2e 20 41  6c 6c 20 72 69 67 68 74  | Coda. All right|
00000040  73 20 72 65 73 65 72 76  65 64 2e 20 50 61 74 65  |s reserved. Pate|
00000050  6e 74 20 50 65 6e 64 69  6e 67 00 00 00 00 00 00  |nt Pending......|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

This is a sample of the very first version of Finale. Currently not identifiable by PRONOM. You may also noticed in this version it was called ENIGA.

hexdump -C Finale2.6.3 | head
00000000  46 69 6e 61 6c 65 28 54  4d 29 20 31 2e 38 20 43  |Finale(TM) 1.8 C|
00000010  6f 70 79 72 69 67 68 74  20 31 39 38 37 20 62 79  |opyright 1987 by|
00000020  20 43 6f 64 61 2e 20 41  6c 6c 20 72 69 67 68 74  | Coda. All right|
00000030  73 20 72 65 73 65 72 76  65 64 2e 00 00 00 00 00  |s reserved......|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  01 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  00 00 00 09 00 00 02 00  00 00 46 4e 50 65 74 72  |..........FNPetr|

A file from version 2.6.3 shows a different format structure, also not currently identified by PRONOM.

hexdump -C F35-s01.mus | head
00000000  45 4e 49 47 4d 41 20 42  49 4e 41 52 59 20 46 49  |ENIGMA BINARY FI|
00000010  4c 45 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |LE..............|
00000020  46 69 6e 61 6c 65 28 52  29 20 33 2e 35 20 43 6f  |Finale(R) 3.5 Co|
00000030  70 79 72 69 67 68 74 20  28 63 29 20 31 39 39 35  |pyright (c) 1995|
00000040  20 43 6f 64 61 20 4d 75  73 69 63 20 54 65 63 68  | Coda Music Tech|
00000050  6e 6f 6c 6f 67 79 00 00  00 00 00 00 00 00 00 00  |nology..........|
00000060  00 02 00 00 00 00 7c 02  08 00 00 00 03 03 50 03  |......|.......P.|
00000070  46 49 4e 00 57 49 4e 00  02 04 50 03 03 03 50 03  |FIN.WIN...P...P.|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 7c 02 08 00  |............|...|
00000090  00 00 03 03 50 03 46 49  4e 00 57 49 4e 00 02 04  |....P.FIN.WIN...|

By Version 3 we see the format stabilize and this header is used until Finale 2012. There was other various products which also used the format so there is some variation.

hexdump -C Tutorial1a.mus | head
00000000  45 4e 49 47 4d 41 20 42  49 4e 41 52 59 20 46 49  |ENIGMA BINARY FI|
00000010  4c 45 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |LE..............|
00000020  50 72 69 6e 74 4d 75 73  69 63 28 52 29 20 32 30  |PrintMusic(R) 20|
00000030  31 30 20 43 6f 70 79 72  69 67 68 74 20 31 39 39  |10 Copyright 199|
00000040  38 2d 32 30 30 39 20 4d  61 6b 65 4d 75 73 69 63  |8-2009 MakeMusic|
00000050  20 49 6e 63 2e 00 00 00  00 00 00 00 00 00 00 00  | Inc............|
00000060  00 02 0e 01 00 00 6a 02  0e 00 00 00 04 02 02 0b  |......j.........|
00000070  46 49 4e 00 57 49 4e 00  03 04 02 0b 0d 02 00 0b  |FIN.WIN.........|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 6d 08 0d 00  |............m...|
00000090  00 00 31 02 00 0f 4e 54  52 00 4d 41 43 00 10 02  |..1...NTR.MAC...|

The current PRONOM identification for fmt/397 is looking for the “ENIGMA BINARY FILE” bytes but also the string “Finale(R)”, so this PrintMusic variation is not identified correctly.

Another format that is a little more rare to see, but is part of the Finale formats collection. Finale Performance Assessment File (.fpa) is an older format discontinued in 2007, but has a similar format. It was a tool similar to the current SmartMusic tool.

hexdump -C Tuba.FPA | head
00000000  46 49 4e 41 4c 45 20 50  45 52 46 4f 52 4d 41 4e  |FINALE PERFORMAN|
00000010  43 45 20 41 53 53 45 53  53 4d 45 4e 54 00 00 00  |CE ASSESSMENT...|
00000020  46 69 6e 61 6c 65 28 52  29 20 32 30 30 35 20 43  |Finale(R) 2005 C|
00000030  6f 70 79 72 69 67 68 74  20 28 63 29 20 31 39 38  |opyright (c) 198|
00000040  37 2d 32 30 30 34 20 4d  61 6b 65 4d 75 73 69 63  |7-2004 MakeMusic|
00000050  21 20 49 6e 63 2e 00 6f  6c 6f 67 79 00 00 00 00  |! Inc..ology....|
00000060  00 02 06 00 00 00 68 06  09 00 00 00 16 02 00 09  |......h.........|
00000070  46 49 4e 00 57 49 4e 00  01 04 01 09 16 02 00 09  |FIN.WIN.........|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 68 07 0d 00  |............h...|
00000090  00 00 0a 01 00 0a 46 49  4e 00 57 49 4e 00 03 03  |......FIN.WIN...|

As for the Enigma Transportable File, there is a couple variations.

hexdump -C Finale1-s02.etf | head
00000000  45 4e 49 47 4d 41 20 74  72 61 6e 73 70 6f 72 74  |ENIGMA transport|
00000010  61 62 6c 65 20 66 69 6c  65 0d 45 4e 49 47 4d 41  |able file.ENIGMA|
00000020  20 53 74 72 75 63 74 75  72 65 73 20 43 6f 70 79  | Structures Copy|
00000030  72 69 67 68 74 20 31 39  38 37 20 62 79 20 43 6f  |right 1987 by Co|
00000040  64 61 2e 20 41 6c 6c 20  52 69 67 68 74 73 20 52  |da. All Rights R|
00000050  65 73 65 72 76 65 64 2e  20 50 61 74 65 6e 74 20  |eserved. Patent |
00000060  50 65 6e 64 69 6e 67 2e  0d 0d 5e 6f 74 68 65 72  |Pending...^other|
00000070  73 0d 5e 46 4e 28 30 29  20 22 50 65 74 72 75 63  |s.^FN(0) "Petruc|
00000080  63 69 22 0d 5e 49 55 28  30 29 20 31 20 30 20 2d  |ci".^IU(0) 1 0 -|
00000090  38 30 20 32 20 30 20 2d  33 31 36 20 0d 5e 49 55  |80 2 0 -316 .^IU|

hexdump -C Finale37-Sample.etf | head
00000000  45 4e 49 47 4d 41 20 54  52 41 4e 53 50 4f 52 54  |ENIGMA TRANSPORT|
00000010  41 42 4c 45 20 46 49 4c  45 0d 0d 5e 68 65 61 64  |ABLE FILE..^head|
00000020  65 72 0d 5e 30 31 20 22  46 69 6e 61 6c 65 28 52  |er.^01 "Finale(R|
00000030  29 20 33 2e 37 20 43 6f  70 79 72 69 67 68 74 20  |) 3.7 Copyright |
00000040  28 63 29 20 31 39 38 37  2d 31 39 39 36 20 43 6f  |(c) 1987-1996 Co|
00000050  64 61 20 4d 75 73 69 63  20 54 65 63 68 6e 6f 6c  |da Music Technol|
00000060  6f 67 79 22 0d 5e 30 32  20 31 20 30 20 30 20 30  |ogy".^02 1 0 0 0|
00000070  20 0d 5e 30 33 20 31 32  30 20 31 31 20 39 20 0d  | .^03 120 11 9 .|
00000080  5e 30 34 20 22 22 0d 5e  30 35 20 35 37 36 37 32  |^04 "".^05 57672|
00000090  32 30 34 20 0d 5e 30 36  20 22 46 49 4e 22 0d 5e  |204 .^06 "FIN".^|

The current signature of ETF files is only able to correctly identify the later version of the string in all caps. The fmt/398 PRONOM ID could use an alternate signature to ensure all variations are identified correctly. There is a couple versions of the specification out there, but does not add much to what is known.

Starting in 2014 Finale starting using a new file format to store its notations. The native format now uses the MUSX extension. This new format uses a ZIP container to store all the data. Let’s take a look at the inside.

Path = Finale26-s01.musx
Type = zip
Physical Size = 98608

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2022-12-19 16:28:36 .....           34           34  mimetype
2022-12-19 16:28:36 .....          252          168  META-INF/container.xml
2022-12-19 16:28:36 .....          347          218  NotationMetadata.xml
2022-12-19 16:28:36 .....         1163          821  presets/10001.preset
2022-12-19 16:28:36 .....          649          544  presets/1.preset
2022-12-19 16:28:36 .....        96140        96155  score.dat
------------------- ----- ------------ ------------  ------------------------
2022-12-19 16:28:36              98585        97940  6 files

The mimetype file appears to be “application/vnd.makemusic.notation”

The NotationMetadata.xml file stores much of the information needed and begins with the root tag.

<metadata version="26.2" xmlns="http://www.makemusic.com/2012/NotationMetadata">

It seems the presence of the NotationMetadata.xml file and the mimetype would be sufficient for identification in a container signature.

The current version of Finale can export to a few different “Music XML” versions. This includes MUSICXML, regular XML, and a compressed MXL file. The only one needs attention is the compressed MXL file and added to PRONOM. It already has a PUID, fmt/897, but no signature. Here is what it looks like inside the ZIP container.

Path = Finale27-s01.mxl
Type = zip
Physical Size = 4737

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2024-02-07 23:55:50 .....           34           34  mimetype
2024-02-07 23:55:50 D....            0            2  META-INF
2024-02-07 23:55:50 .....          202          144  META-INF/container.xml
2024-02-07 23:55:50 .....        18004         1996  Finale27-s01.musicxml
2024-02-07 23:55:52 .....        17554         1953  p1.musicxml
------------------- ----- ------------ ------------  ------------------------
2024-02-07 23:55:52              35794         4129  4 files, 1 folders

Looks like a standard identifiable MUSICXML file within the container with a mimetype of “application/vnd.recordare.musicxml”. The MUSICXML file will be impossible to use for identification because of the variable file name, but the mimetype should do just fine.

Hopefully that covers all the major formats that need identification. I saw on a list that I will soon be working on an old Macintosh which has hundreds of Finale files, I hope these updates cover those needs! Take a look at my GitHub for my signatures and plenty of samples.