Amadeus

November 5, 2026 by Thor Leave a comment

Rock me Amadeus! Yes, another music format. Or two? Happy #WDPD2026!

I have found in my research that generally when a format format is needed for software, an extension is chosen based on a recognized pattern that fits with the software’s name or purpose and also something unique to keep confusion limited. Extensions are often three characters long, but over the years with modern operating systems some formats are given four or more characters. So would would think with using more than three characters the extension should be more unique. But there are always exceptions!

For today, I am looking into the extension AMAD. It seems clear this extension belongs to software such as Amadeus. While this is true, there is still some confusion on which Amadeus we are discussing.

Chiptune

The first format to discuss is based on Chiptune technology. This refers to the early intersection of electronic music used in video games and synthesized music. Early arcade games used programmable sound hardware to create complex sound effects and musical compositions. These hardware systems could generate musical waveforms in real time. Later when sound used in video games and other hardware was true recorded music, the need for sound chips was used less, but many still wanted to retain the original simple sounds used earlier.

This led to the AY Amadeus chiptune format. It is a subtype of the AY music file format, which was developed to preserve and reproduce music originally written for the ZX Spectrum’s AY-3-8910 sound chip in the mid 1980’s. The significance of AMAD is that it preserves the original music data and playback requirements rather than simply storing a recording of the resulting sound. You can read more about this format here.

Let’s take a look at some samples.

% hexdump -C ghostbusters.amad | head
00000000  5a 58 41 59 41 4d 41 44  00 00 00 00 00 19 00 00  |ZXAYAMAD........|
00000010  00 00 00 02 00 04 00 38  47 68 6f 73 74 42 75 73  |.......8GhostBus|
00000020  74 65 72 73 00 46 72 61  6e 74 69 73 65 6b 20 46  |ters.Frantisek F|
00000030  75 6b 61 2c 20 6f 72 69  67 2e 20 62 79 20 52 61  |uka, orig. by Ra|
00000040  79 20 50 61 72 6b 65 72  20 4a 72 2e 00 00 f9 b0  |y Parker Jr...??|
00000050  1f 01 24 60 ff 40 00 01  00 01 02 03 b6 f9 90 fb  |..$`?@......??.?|
00000060  8e fc 87 ea fd 86 a9 fe  24 30 20 30 1f 30 1e 30  |.?.??.??$0 0.0.0|
00000070  1d 30 27 30 87 b0 fd 23  60 84 14 85 00 82 08 2f  |.0'0.??#`....../|
00000080  01 00 05 83 85 08 87 00  fe 86 4e fe 84 09 85 00  |........?.N?....|
00000090  82 08 28 06 83 87 b0 fd  84 1f 85 00 8a 82 20 53  |..(...??...... S|

% hexdump -C popcorn.amad | head     
00000000  5a 58 41 59 41 4d 41 44  00 02 00 00 00 14 00 30  |ZXAYAMAD.......0|
00000010  00 00 00 02 00 04 00 4c  50 6f 70 63 6f 72 6e 00  |.......LPopcorn.|
00000020  50 61 74 72 69 6b 20 52  61 6b 2c 20 6f 72 69 67  |Patrik Rak, orig|
00000030  2e 20 62 79 20 4b 69 6e  67 73 6c 65 79 00 53 70  |. by Kingsley.Sp|
00000040  61 63 65 20 43 72 75 73  61 64 65 72 73 2c 20 28  |ace Crusaders, (|
00000050  43 29 20 31 39 39 31 20  53 63 6f 72 70 69 6f 6e  |C) 1991 Scorpion|
00000060  00 00 c0 00 1f 01 0a 28  00 00 00 64 00 03 02 01  |..?....(...d....|
00000070  88 c0 06 c0 0b c0 00 00  80 06 c0 86 58 c1 87 51  |.?.?.?....?.X?.Q|
00000080  c1 00 14 82 02 82 04 88  02 81 50 c0 83 88 05 81  |?.........P?....|
00000090  60 c0 88 00 81 60 c0 82  02 88 02 81 50 c0 83 83  |`?...`?.....P?..|

The first four bytes use the hex values “5A 58 41 59” or “ZXAY” in ASCII. Then according to the specifications, the next four bytes indicate these are the “AMAD” file type. Seems pretty straight forward.

The other Amadeus.

Not too long after, there was a clever developer designing software for the early Macintosh to edit sound waves. Martin Hairer is a professor of pure mathematics. He developed the Amadeus software when he was a teenager in the early 1990’s.

The early version of Amadeus and the later Amadeus II was made for the classic MacOS, but later worked on MacOSX as well. In these early versions, there was no native format for the software. You would simply open or save as one of the popular audio formats of the time. On a Macintosh, this would often be the Audio Interchange File Format (AIFF).

Then around 2007, Martin developed a more modern universal binary version of Amadeus which could run on the intel platform. He called this version Amadeus Pro which added many more features. With this upgrade, also came a native file format to store all the software’s features without restriction. Unfortunately, he also used the AMAD extension.

Let’s take a look at this format as well.

% hexdump -C AP10-s01.amad | head
00000000  61 6d 61 64 00 00 00 00  00 00 04 70 74 72 63 6b  |amad.......ptrck|
00000010  00 00 00 00 00 00 03 28  66 6f 72 6d 00 00 00 00  |.......(form....|
00000020  00 00 00 08 47 2c 44 00  00 02 00 02 6f 66 66 73  |....G,D.....offs|
00000030  00 00 00 00 00 00 00 08  00 00 00 00 00 00 00 00  |................|
00000040  65 6e 64 6e 00 00 00 00  00 00 00 04 00 00 00 02  |endn............|
00000050  76 6f 6c 73 00 00 00 00  00 00 01 9c 62 70 6c 69  |vols........bpli|
00000060  73 74 30 30 d4 01 02 03  04 05 06 07 0a 59 24 61  |st00?........Y$a|
00000070  72 63 68 69 76 65 72 58  24 76 65 72 73 69 6f 6e  |rchiverX$version|
00000080  54 24 74 6f 70 58 24 6f  62 6a 65 63 74 73 5f 10  |T$topX$objects_.|
00000090  0f 4e 53 4b 65 79 65 64  41 72 63 68 69 76 65 72  |.NSKeyedArchiver|

% hexdump -C AP15-s01.amad | head 
00000000  61 6d 61 64 00 00 00 00  00 00 04 e8 76 65 72 73  |amad.......?vers|
00000010  00 00 00 00 00 00 00 02  00 01 74 72 63 6b 00 00  |..........trck..|
00000020  00 00 00 00 03 54 66 6f  72 6d 00 00 00 00 00 00  |.....Tform......|
00000030  00 08 47 2c 44 00 00 02  00 02 6f 66 66 73 00 00  |..G,D.....offs..|
00000040  00 00 00 00 00 08 00 00  00 00 00 00 00 00 65 6e  |..............en|
00000050  64 6e 00 00 00 00 00 00  00 04 00 00 00 01 76 6f  |dn............vo|
00000060  6c 73 00 00 00 00 00 00  01 c8 62 70 6c 69 73 74  |ls.......?bplist|
00000070  30 30 d4 01 02 03 04 05  08 2e 2f 54 24 74 6f 70  |00?......./T$top|
00000080  58 24 6f 62 6a 65 63 74  73 58 24 76 65 72 73 69  |X$objectsX$versi|
00000090  6f 6e 59 24 61 72 63 68  69 76 65 72 d1 06 07 54  |onY$archiver?..T|

% hexdump -C AP23-s01.amad | head 
00000000  61 6d 61 64 00 00 00 00  00 00 07 be 74 72 63 6b  |amad.......?trck|
00000010  00 00 00 00 00 00 06 1a  66 6f 72 6d 00 00 00 00  |........form....|
00000020  00 00 00 08 47 2c 44 00  00 02 00 04 6f 66 66 73  |....G,D.....offs|
00000030  00 00 00 00 00 00 00 08  00 00 00 00 00 00 00 00  |................|
00000040  65 6e 64 6e 00 00 00 00  00 00 00 04 00 00 00 01  |endn............|
00000050  65 66 66 73 00 00 00 00  00 00 00 ec 62 70 6c 69  |effs.......?bpli|
00000060  73 74 30 30 d4 01 02 03  04 05 06 14 15 58 24 76  |st00?........X$v|
00000070  65 72 73 69 6f 6e 58 24  6f 62 6a 65 63 74 73 59  |ersionX$objectsY|
00000080  24 61 72 63 68 69 76 65  72 54 24 74 6f 70 12 00  |$archiverT$top..|
00000090  01 86 a0 a3 07 08 0d 55  24 6e 75 6c 6c d2 09 0a  |..??...U$null?..|

% hexdump -C AP30-s01.amad | head 
00000000  61 6d 61 64 00 00 00 00  00 00 07 fe 74 72 63 6b  |amad.......?trck|
00000010  00 00 00 00 00 00 06 5a  66 6f 72 6d 00 00 00 00  |.......Zform....|
00000020  00 00 00 08 47 3b 80 00  00 02 00 04 6f 66 66 73  |....G;......offs|
00000030  00 00 00 00 00 00 00 08  00 00 00 00 00 00 00 00  |................|
00000040  65 6e 64 6e 00 00 00 00  00 00 00 04 00 00 00 01  |endn............|
00000050  65 66 66 73 00 00 00 00  00 00 00 ec 62 70 6c 69  |effs.......?bpli|
00000060  73 74 30 30 d4 01 02 03  04 05 06 07 0a 58 24 76  |st00?........X$v|
00000070  65 72 73 69 6f 6e 59 24  61 72 63 68 69 76 65 72  |ersionY$archiver|
00000080  54 24 74 6f 70 58 24 6f  62 6a 65 63 74 73 12 00  |T$topX$objects..|
00000090  01 86 a0 5f 10 0f 4e 53  4b 65 79 65 64 41 72 63  |..?_..NSKeyedArc|

There is a few things to point out with this format. It is different than the Chiptune format for sure. Should be easy to distiguish between the two, even with them using the same four character extension. The first four bytes are the same as the extension. They are also lowercase so the hex values are different from the Chiptune format, another helpful difference so they two are not confused.

The rest of the format has some similarities with each of the versions, some which could be used to enhance a signature, but the first four bytes should be enough. One of the things things within the format to notice is the bplist00 string. These are binary property lists and are important as they are also a recognized format itself. They contain serialized data, which is a topic I have referenced recently and need to finish a post about that.

So for signatures, I’m thinking:

AY Amadeus chiptune format 5A584159(414D4144|454D554C)

Amadeus Pro Document 616D6164

I am not sure how two completely different developers chose to use the same four character extension for their sound format. I searched for any connection, but couldn’t find one. Seems like a low probability, but Amadeus is a popular historical musical figure, so maybe it wasn’t too hard for these two formats to clash. Let me know what you think. Samples and signature here.

NoteWriter

October 23, 2026 by Thor Leave a comment

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.

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.

Ready, Set, Go!

July 31, 2026 by Thor Leave a comment

By the title you might think this was a post about racing. But this is a file format blog, so we will keep on that topic. When I was in school many years ago, I remember using desktop publishing tools like PageMaker for the first time. When I got a job working for a local commercial printer in the early 1990’s, I was introduced to QuarkXPress. This became a career and I spent the next decade and a half working in the PrePress field. I got to know tools like Quark and InDesign extremely well. But even before these layout tools became what they are today, there was an early entry into the desktop publishing market.

Ready, Set, Go! was the “Ultimate Page Processor” released in 1985 for the Macintosh by Manhattan Graphics Corp. But had started advertising as early as Summer 1984.

For a few years it was one of the best layout tools on the market and was not very expensive. It continued to add features which rivaled the more expensive tools. Aldus PageMaker also come out shortly after in 1985, but was almost $500 when released. The software was sold to Letraset in 1987 and used it to replace their MacPublisher/LetraPage product and shortly afterwards released version 4.0 of Ready, Set, Go!. Letraset made some improvements and even tried to make a pro version called DesignStudio in 1989. When sales started to stagnate and Tools like Pagemaker and Quark owning most of the market, Letraset gave the software back to Manhattan Graphics in the USA in 1992 who then released a small update combining the two products back together into version 5.0. Then they released version 6.0 later that year. In 1996 the international rights were sold to Diwan, a company who could make use of the very foreign language capabilities of the software.

Ready, Set, Go! had a great history of foreign language support, thanks in part to the Apple Quickdraw GX software which helped render other language glyphs and writing directions. There were special versions for languages like Hebrew. A GX version of the software was released in 1996 that supported many other languages.

Because of and in spite of the craziness of the software’s ownership, the file format used with the software changed frequently, but mostly kept the same basic structure. Identification of the different versions will be difficult, but that is why we are here, let’s take a look. Remember, these were all very early Macintosh programs, meaning there is no extension and their identification is based on Type/Creator codes. Luckily, there is no Resource Forks we need to account for in their identification or preservation.

Here is a look at a file from version 1.

 % 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 RSG2-s01 | head
00000000  00 78 00 02 00 00 00 48  00 48 00 00 00 00 02 d8  |.x.....H.H......|
00000010  02 28 ff e0 ff e2 02 f8  02 46 03 07 05 28 03 fc  |.(.......F...(..|
00000020  00 02 00 00 00 48 00 48  00 00 00 00 02 d8 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 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 01 00 13 00 04  |................|
00000080  00 10 00 1c 00 04 00 10  00 10 00 01 00 01 00 00  |................|
00000090  00 03 17 54 00 06 14 9e  00 05 08 ae 00 01 50 ec  |...T..........P.|

% getfileinfo RSG2-s01
file: "RSG2-s01"
type: "RSGI"
creator: "MART"
attributes: avbstclInmedz
created: 04/17/1986 17:31:32
modified: 04/28/1986 10:53:01

% hexdump -C RSG3 | head
00000000  00 1e 00 00 00 86 00 01  b8 2a 00 01 00 03 00 02  |.........*......|
00000010  00 01 b8 12 00 01 b8 1e  00 01 b8 4e 00 00 00 01  |...........N....|
00000020  b8 0a 00 00 80 00 00 00  80 00 00 00 80 00 00 00  |................|
00000030  80 00 00 00 40 00 00 00  40 00 00 04 00 02 00 01  |....@...@.......|
00000040  b8 06 ff fd 52 53 47 33  00 6c 65 64 00 ff ff f0  |....RSG3.led....|
00000050  1f ff ff f0 1f ff ff f0  00 00 00 10 00 00 34 42  |..............4B|
00000060  41 50 50 4c 00 00 00 ff  00 00 00 10 00 00 00 22  |APPL..........."|
00000070  44 52 57 47 00 01 00 ff  00 00 00 10 00 00 00 00  |DRWG............|
00000080  00 10 43 54 00 02 00 01  ff 00 ff ff 00 00 00 78  |..CT...........x|
00000090  00 03 00 00 00 48 00 48  00 00 00 00 02 f0 02 40  |.....H.H.......@|

% hexdump -C RSG4-s01 | head
00000000  01 90 00 00 01 e6 00 00  01 e2 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00 00 00 00 cc  00 04 5b a0 00 01 00 03  |..........[.....|
00000070  00 02 00 04 5b 68 00 04  5b 70 00 04 5b 7c 00 00  |....[h..[p..[|..|
00000080  00 04 5b 5c 00 00 00 04  5b 64 00 00 80 00 00 00  |..[\....[d......|
00000090  80 00 00 00 80 00 00 00  80 00 00 00 40 00 00 00  |............@...|
000000a0  40 00 00 04 00 02 ff 00  00 04 5b 60 ff fe 08 52  |@.........[`...R|
000000b0  53 47 34 2d 73 30 31 00  00 00 00 00 00 00 00 00  |SG4-s01.........|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

% getfileinfo RSG4.5 
file: "RSG4.5"
type: "RSGR"
creator: "MEMR"
attributes: avbstclInmedz
created: 11/16/2021 13:39:34
modified: 11/16/2021 13:39:34

If you would like to play around with some samples from version 2. You can download them from here:

We can look at the hexadecimal for all the files, but this table will better explain the differences between versions.

Version	Type	Creator	First two Bytes	Developer	Year
1.0.1	RSGF	MART	0078	Manhattan Graphics Corporation	1985
2.0	RSGI	MART	0078	Manhattan Graphics Corporation	1985
3.0	RSGJ	MRSN	001E	Manhattan Graphics Corporation	1986
4.0	RSGK	MRSN	0190	Letraset	1987
4.5	RSGR	MEMR	138B	Letraset	1988
Design Studio 1.0	RSGS	MRJN	13C9	Letraset	1989
Design Studio 2.0	DSTD	MRJN	13E4	Letraset	1991
6.0.2	MG6F	MROS	1770	Manhattan Graphics	1993
7.0.5 Intl	MG7F	MRDN	1B61	Diwan	1996
7.2.8	MG6F	MROS	1BBC	Diwan	2002
7.7.8	MG6F	MROS	1BBC	Diwan	2011

This table is what I know currently, there is probably many more I can add as I locate samples, such as Version 5.0 and 5.1.

It amazes me how often the Creator code changes, usually this is fairly stable, but since it did change hands a lot, it makes a little sense. The Type code can often indicate changes in file format, so we can see version 1 & 2 are probably compatible, and later versions 6 & 7, but there own read me files helps us understand the compatibility. Version 2 added multiple page support, so it might have more differences.

Ready,Set,Go! 6.0 can open files created with Ready,Set,Go! 4.5, 4.5a, 5.0, and 5.1, and DesignStudio 1.0, 1.01 and 2.0. It cannot open files created with versions 1, 2, 3 or 4 of Ready,Set,Go! Registered users can obtain a special version of RSG 4.5 to open files created with earlier versions of Ready,Set,Go! to convert them to Version 6.0.

Ready,Set,Go! will open an old RSG document down to version 4 and a DesignStudio document down to version 1.0. Ready,Set,Go! 7.1 will automatically save it with the name ‘Copy of (filename)’ in order not to overwrite the old document. Whereas Ready,Set,Go! 7.2 or later can save documents that are compatible with Ready,Set,Go! versions 6 and 7.0.

So it seems you need version 4.5 to open earlier files and version 6 to open versions 4.5 to 5.1, then in 7.2 a change happened separating versions 6-7.1 and 7.2 and greater. Sounds like we will need at least 4 signatures to identify all the major changes.

Here is the problem, the main differences between the versions is the first two bytes. This is not enough to make a strong signature in PRONOM. Let look at some options.

% hexdump -C RSG4-s01 | tail
00000160  00 00 02 da 02 28 00 01  00 00 00 64 00 00 00 01  |.....(.....d....|
00000170  00 01 01 01 00 00 00 01  27 0f 00 01 00 01 00 00  |........'.......|
00000180  00 00 00 00 00 00 00 00  00 00 00 02 00 19 01 90  |................|
00000190  00 00 00 00 00 40 00 00  00 00 00 00 00 00 00 01  |.....@..........|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 2a 00 00 00 00  00 00 00 00 00 00 00 00  |...*............|
000001c0  00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 01 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 ff ff ff ff ff ff  |................|

Many since version 3 end with at least two bytes of the values FF FF, but that is also pretty common.

% hexdump -C RSG4.5 | head
00000000  13 8b 00 00 04 10 00 00  04 0c 00 00 04 14 00 00  |................|
00000010  04 18 00 00 04 1c 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  |................|
*
00000060  00 00 00 00 00 00 01 88  17 62 e1 d4 00 01 00 03  |.........b......|
00000070  00 02 17 62 e1 d0 17 62  e1 dc 17 62 e1 e8 00 00  |...b...b...b....|
00000080  17 62 e1 cc 00 00 17 62  e1 c8 00 00 80 00 00 00  |.b.....b........|
00000090  80 00 00 00 80 00 00 00  80 00 00 00 40 00 00 00  |............@...|
000000a0  40 00 00 04 00 02 ff 00  17 62 e1 50 ff fd 06 52  |@........b.P...R|
000000b0  53 47 34 2e 35 65 64 00  00 00 00 00 00 00 00 00  |SG4.5ed.........|

The header generally contains two bytes, then 00 00, then repeats for a few bytes, but adding 00 00 to a signature is also not very robust. Comparing version 3 to version 4 file doesn’t show much in common except for zeros. It may not be possible to combine signatures, they may need individual signatures for each version.

But the versions after 6, have an interesting segment of bytes. “050102030102060102030102060102030102060102030102060102030102070102090102070102030102070102090102070102090102070102090102070102090102060102030102060102030102060102030102060102030102050102030102050102030102050102030102050102030102050102030102050102030102060102030102050102030102050102030102050102030102”

% hexdump -C /Users/thorsted/Downloads/ReadySetGo\ \(1\)/RSG6       
00000000  17 70 00 00 34 70 00 00  34 6c 00 00 34 74 00 00  |.p..4p..4l..4t..|
00000010  34 78 00 00 34 90 00 00  34 a4 00 00 38 fe 00 00  |4x..4...4...8...|
00000020  39 20 00 00 39 68 00 00  3b 40 00 00 3b 44 00 00  |9 ..9h..;@..;D..|
00000030  3b 44 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |;D..............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  00 03 01 01 00 ff 00 00  00 00 05 01 02 03 01 02  |................|
000001d0  06 01 02 03 01 02 06 01  02 03 01 02 06 01 02 03  |................|
000001e0  01 02 06 01 02 03 01 02  07 01 02 09 01 02 07 01  |................|
000001f0  02 03 01 02 07 01 02 09  01 02 07 01 02 09 01 02  |................|
00000200  07 01 02 09 01 02 07 01  02 09 01 02 06 01 02 03  |................|
00000210  01 02 06 01 02 03 01 02  06 01 02 03 01 02 06 01  |................|
00000220  02 03 01 02 05 01 02 03  01 02 05 01 02 03 01 02  |................|
00000230  05 01 02 03 01 02 05 01  02 03 01 02 05 01 02 03  |................|
00000240  01 02 05 01 02 03 01 02  06 01 02 03 01 02 05 01  |................|
00000250  02 03 01 02 05 01 02 03  01 02 05 01 02 03 01 02  |................|
00000260  00 09 20 60 00 08 80 00  00 0b 00 00 00 01 00 00  |.. `............|
00000270  00 02 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000280  00 00 00 00 00 ea 04 b0  00 64 03 e8 00 00 00 00  |.........d......|
00000290  17 97 50 6c 00 00 00 00  00 3c 00 3d 00 3e 00 3f  |..Pl.....<.=.>.?|
000002a0  00 40 00 41 00 42 00 43  00 64 00 05 00 00 00 00  |.@.A.B.C.d......|
000002b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

It is in all the samples I have for version 6+, most have the same 150 bytes, all starting around the 458th byte (0x1CA). I have no idea what it means, but it makes up for the weak bytes available in the older versions. If anyone out there knows the significance in this byte sequence, I would like to understand. Visually it looks the most interesting in a 3 column view, and some files do have one byte difference.

Ok, so for now, it looks like the best option is to group the signatures into Version 3-4, Version 6-7, and DesignStudio 1-2. I will look at what is best for Version 1-2 of ReadySetGo in the future. For now, you can see my samples and suggested signature on my GitHub page.

BE DEAD

April 24, 2026 by Thor Leave a comment

If you remember the older post about Cafe Beef, you’ll appreciate the file format we explore in this post which uses using the Hex values “BE DEAD”. I guess they jinxed themselves because the software didn’t survive a refresh in 2009 and died. At one point the software was considered remarkable software being awarded 4.5 Mice by Macworld Magazine in August 2002.

When a colleague reach out to me recently with a file they were not familiar with I jumped in. I love a good challenge. The file had no extension, but was thought to have come from a Windows system. With a little digging I was able to identify the file as a Now Contact file which does have a Windows and Macintosh version, but with no extension, my money was on the file coming from the Mac.

I started my search with the obvious, the first few bytes. Since I only had one file, I wasn’t sure if this would be helpful, but looking at the bytes, I figured it was significant.

% hexdump -C "CONTACT FILE" | head
00000000  be de ad 01 00 00 00 03  00 1d 5f a9 00 7d d1 8e  |.........._..}..|
00000010  00 00 0e d8 98 89 d7 4b  00 8f 31 fd 00 00 3b f0  |.......K..1...;.|
00000020  00 de 76 56 be de ad 00  e6 02 b4 af 63 64 62 68  |..vV........cdbh|
00000030  00 00 00 00 00 00 01 8e  90 8f 56 13 00 0d 09 b4  |..........V.....|
00000040  00 0d 0b e0 00 0d 0c 50  00 0d 0b e8 00 0d 0c 58  |.......P.......X|
00000050  00 00 00 00 ba f3 fa eb  00 00 27 12 00 00 00 00  |..........'.....|
00000060  e6 02 b4 76 00 00 00 00  00 00 00 00 00 00 00 00  |...v............|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

The first three bytes are “BE DE AD“, BE DEAD seems to be done on purpose. A quick search on the web showed no results, no mention of this unique header. I even turned to AI, asking grok if it know the source of this byte sequence. It had no idea. I began digging through the file looking for clues to its software source. The ASCII text I could see indicated some sort of customer database, that along with the file name of “CONTACT FILE” seemed to confirm. I found some dates from 2002 and started looking at popular CRM and PIM software at the time. I then found a reference to a note the user left saying they opened the file on a different Power Tower Pro. I owned one of these clones back in college, so I immediately knew they were using a Macintosh! A quick search of popular contact management software from the early 2000’s revealed a few suspects. I took a look at a product from Now Software, Now Up-to-Date & Contact version 3.9 and I found the header I was looking for! Had the file sent to me retained its extended attributes from the Mac, I would have found this software much quicker.

Now Software has been around since 1990 and was purchased at one point by PowerOn Software. Now Up-to-Date came around in 1992, but Now Contact wasn’t added until 1994. Version 1.0 of the software was standalone and was popular, but simple, when Now Software bundled it with the Now Up-to-Date software in 1995, they skipped version 2 to be in sync.

The Now Contact software has a few functionalities including a Word Processor, but lets stick to the contact manager for now. Let’s take a look at a sample file from version 1.

% hexdump -C "Sample Contact File" | head 
00000000  00 00 4c 47 00 00 00 03  a8 ee f6 c6 a8 ef 9b 95  |..LG............|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  12 bc 00 2b 73 74 61 74  00 00 00 01 00 00 00 04  |...+stat........|
00000110  00 00 00 fc 73 74 61 74  00 00 00 02 00 00 01 00  |....stat........|
00000120  00 00 06 44 4b 6e 44 42  00 00 00 00 00 00 07 44  |...DKnDB.......D|
00000130  00 00 04 68 4b 6e 44 42  00 00 00 01 00 00 0b ac  |...hKnDB........|
00000140  00 00 06 12 4b 6e 44 42  00 00 00 02 00 00 13 ac  |....KnDB........|
00000150  00 00 00 70 4b 6e 44 42  00 00 00 03 00 00 15 ac  |...pKnDB........|
00000160  00 00 00 b6 4b 6e 44 42  00 00 00 05 00 00 16 64  |....KnDB.......d|

This file does not have the “BE DE AD” header, but something else. I do see a repeated pattern of the text “KnDB” which also happens to be the Type code used on the Macintosh.

% getfileinfo "Sample Contact File"
type: "KnDB"
creator: "NIC!"
attributes: avbstClinmedz
created: 10/23/1993 13:57:10
modified: 10/24/1993 11:18:58

Another sample

% hexdump -C NC1-s02 | head
00000000  00 00 36 20 00 00 00 03  e6 03 e7 1a e6 03 e7 41  |..6 ...........A|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  0c dc 00 26 73 74 61 74  00 00 00 01 00 00 00 04  |...&stat........|
00000110  00 00 00 fc 73 74 61 74  00 00 00 02 00 00 01 00  |....stat........|
00000120  00 00 06 44 4b 6e 44 42  00 00 00 00 00 00 07 44  |...DKnDB.......D|
00000130  00 00 04 68 4b 6e 44 42  00 00 00 01 00 00 0b ac  |...hKnDB........|
00000140  00 00 00 00 4b 6e 44 42  00 00 00 02 00 00 0b ac  |....KnDB........|
00000150  00 00 00 20 4b 6e 44 42  00 00 00 03 00 00 0b cc  |... KnDB........|
00000160  00 00 00 b6 4b 6e 44 42  00 00 00 05 00 00 0c 84  |....KnDB........|

These version 1 files don’t seem to have a static header, but they do have common bytes sequences. I will need to make more samples to get a proper signature constructed.

Now Contact skipped version 2 so the next version to be released was 3.0. What do these files look like?

% hexdump -C "Sample Contact File" | head
00000000  be de ad 01 00 00 00 03  00 00 a7 62 00 00 03 fc  |...........b....|
00000010  00 00 00 19 00 01 6e 9a  00 00 36 94 00 00 00 55  |......n...6....U|
00000020  00 01 42 ea be de ad 00  b4 25 c0 65 00 01 63 6b  |..B......%.e..ck|
00000030  00 00 00 87 00 00 00 6c  fc 63 8e a8 6f 62 6a 65  |.......l.c..obje|
00000040  00 00 00 81 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 01 00 00 00 80 00 00  00 36 63 6d 6e 74 00 00  |.........6cmnt..|
00000060  00 80 00 00 00 00 00 00  00 00 00 00 00 00 00 03  |................|
00000070  63 64 61 74 00 00 00 04  b4 25 c0 65 63 74 68 74  |cdat.....%.ectht|
00000080  00 00 00 00 63 73 65 6c  00 00 00 04 00 00 00 00  |....csel........|
00000090  be de ad 00 b4 25 c0 a4  44 4c 54 7a 00 00 00 ed  |.....%..DLTz....|

They have the same header as the file I received. Let’s try and open my file in Now Contact 3.9.

Oops, that didn’t work. There must be something in my file which tells the software it is from a newer version. After some digging in the file I can see some possible version text.

% hexdump -C "CONTACT FILE"
00000000  be de ad 01 00 00 00 03  00 1d 5f a9 00 7d d1 8e  |.........._..}..|
00000010  00 00 0e d8 98 89 d7 4b  00 8f 31 fd 00 00 3b f0  |.......K..1...;.|
00000020  00 de 76 56 be de ad 00  e6 02 b4 af 63 64 62 68  |..vV........cdbh|
00000030  00 00 00 00 00 00 01 8e  90 8f 56 13 00 0d 09 b4  |..........V.....|
00000040  00 0d 0b e0 00 0d 0c 50  00 0d 0b e8 00 0d 0c 58  |.......P.......X|
00000050  00 00 00 00 ba f3 fa eb  00 00 27 12 00 00 00 00  |..........'.....|
00000060  e6 02 b4 76 00 00 00 00  00 00 00 00 00 00 00 00  |...v............|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000003a0  00 50 00 21 00 f1 01 cf  00 00 00 82 00 00 00 34  |.P.!...........4|
000003b0  6b 65 79 73 00 00 00 82  00 00 00 00 00 00 00 00  |keys............|
000003c0  00 01 00 00 00 01 6b 65  79 68 00 00 00 15 76 34  |......keyh....v4|
000003d0  30 30 00 00 00 01 00 00  00 00 00 00 00 00 00 00  |00..............|
000003e0  00 00 00 00 be de ad 00  ba 42 cd 51 05 00 64 62  |.........B.Q..db|
000003f0  00 00 00 02 00 00 00 18  00 00 00 00 00 00 00 00  |................|
00000400  00 be de ad 00 b9 d0 15  aa 02 00 66 6c 00 00 00  |...........fl...|
00000410  14 00 00 00 2d b1 0b 27  34 76 34 30 30 00 00 00  |....-..'4v400...|

The file has some repeated text with v400. Sure enough opening the file in version 4 has no problems and I am able to view all the contacts and even allows me to export as a CSV. Looking at a sample file from a version 4 install confirms the version information.

% hexdump -C "Sample Contact File" | head
00000000  be de ad 01 00 00 00 03  00 07 5c 06 00 01 23 40  |..........\...#@|
00000010  00 00 00 10 00 17 9c 42  00 01 10 92 00 00 00 63  |.......B.......c|
00000020  00 10 37 3a be de ad 00  b7 39 82 7b 00 01 63 6b  |..7:.....9.{..ck|
00000030  00 00 00 80 00 00 5d 62  52 66 a1 a9 6f 62 6a 65  |......]bRf..obje|
00000040  00 00 00 86 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 06 00 00 00 81 00 00  00 34 6b 65 79 73 00 00  |.........4keys..|
00000060  00 81 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|
00000070  6b 65 79 68 00 00 00 15  76 34 30 30 00 00 00 01  |keyh....v400....|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 82 00 00 00 b4 6e 6f  74 65 00 00 00 82 00 00  |......note......|

Now Software updated the software for the a few years in the early 1990’s. There was Windows versions as well and the format is the same except one detail.

% hexdump -C NC452-Win-s01.NCT | tail
00004ff0  00 00 00 00 00 00 00 00  00 00 00 00 00 08 00 32  |...............2|
00005000  00 32 01 90 01 90 00 00  00 08 00 4f 00 32 02 01  |.2.........O.2..|
00005010  03 11 00 00 01 00 00 00  01 18 00 00 00 18 00 00  |................|
00005020  00 32 00 00 00 00 00 00  00 00 00 1c 00 32 00 00  |.2...........2..|
00005030  64 65 52 65 00 00 00 0a  00 01 ff ff 00 00 00 0c  |deRe......??....|
00005040  00 00 00 00 00 00 4e fa  69 da 88 7b 00 00 50 54  |......N?i?.{..PT|
00005050  77 69 6e 73                                       |wins|

It appears in version 4, the final bytes would indicate “wins” or “macs”. This continued in version 5 which came out in 2005.

% hexdump -C NC501-s01.nct | head
00000000  be de ad 01 00 00 00 03  00 00 02 cf 00 00 1e 14  |?ޭ........?....|
00000010  00 00 00 11 00 00 5c 93  00 00 43 7e 00 00 00 50  |......\...C~...P|
00000020  00 00 59 da 00 00 00 34  00 00 00 2c 00 00 05 5e  |..Y?...4...,...^|
00000030  00 00 02 cc be de ad 00  e6 02 e9 89 01 00 64 62  |...̾ޭ.?.?...db|
00000040  00 00 00 02 00 00 00 18  00 00 00 00 be de ad 00  |............?ޭ.|
00000050  e6 02 e9 91 63 64 62 68  00 00 00 00 00 00 01 8e  |?.?.cdbh........|
00000060  be 63 10 4d 00 7f 63 c8  00 7f 65 64 00 7f 66 d0  |?c.M..c?..ed..f?|
00000070  00 7f 66 bc 00 00 00 00  00 01 00 00 e6 02 e9 8a  |..f?........?.?.|
00000080  00 00 27 11 00 00 00 00  e6 02 e9 91 00 00 00 00  |..'.....?.?.....|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00005ad0  00 00 00 00 00 00 00 00  00 00 00 00 01 00 00 00  |................|
00005ae0  01 00 00 00 00 00 00 00  00 1e 00 00 00 00 00 00  |................|
00005af0  00 00 00 1c 00 1e ff ff  00 00 00 00 00 00 00 00  |......??........|
00005b00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 08  |................|
00005b10  00 32 00 32 02 4f 03 11  00 00 59 da 57 7e a0 f3  |.2.2.O....Y?W~??|
00005b20  00 00 5b 28 6d 61 63 73                           |..[(macs|

Also in the version 5 samples, we still see the v400 text, so it appears the format was not changed.

% hexdump -C /Volumes/File\ Formats/Now/NC531-s01.nct       
00000000  be de ad 01 00 00 00 03  00 00 04 90 00 00 1e 14  |?ޭ.............|
00000010  00 00 00 11 00 00 54 83  00 00 43 7e 00 00 00 50  |......T...C~...P|
00000020  00 00 53 5e 00 00 00 34  00 00 00 2c 00 00 05 5e  |..S^...4...,...^|
00000030  00 00 02 cc be de ad 00  e6 04 44 0e 01 00 64 62  |...̾ޭ.?.D...db|
00000040  00 00 00 02 00 00 00 18  00 00 00 00 be de ad 00  |............?ޭ.|
00000050  e6 04 44 5c 63 64 62 68  00 00 00 00 00 00 01 8e  |?.D\cdbh........|
00000060  41 f7 ad 20 cc 8e b5 01  74 8f b5 01 e8 00 b6 02  |A?? ?.?.t.?.?.?.|
00000070  e4 00 b6 02 00 00 00 00  01 00 00 00 0e 44 04 e6  |?.?..........D.?|
00000080  11 27 00 00 00 00 00 00  5c 44 04 e6 00 00 00 00  |.'......\D.?....|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 be de  |..............??|
000001f0  ad 00 e6 04 44 0e 02 00  66 6c 00 00 00 03 00 00  |?.?.D...fl......|
00000200  00 2d b1 0b 27 34 76 34  30 30 00 00 00 01 00 00  |.-?.'4v400......|
00000210  00 00 00 00 00 00 00 00  00 00 00 be de ad 00 e6  |...........?ޭ.?|
00000220  04 44 0e 02 00 66 6c 00  00 00 05 00 00 00 2d b1  |.D...fl.......-?|
00000230  0b 27 34 76 34 30 30 00  00 00 01 00 00 00 00 00  |.'4v400.........|

Now Up-to-Date & Contact released version 5.3 around 2008 which finally provided support for Intel processors. It was the last version released before Now Software attempted a full re-write of the software in 2009 named Now X (code-named “NightHawk”). The software did not receive good reviews and by 2010 the company ceased operations. So far I have come up empty in getting a copy of this doomed version, but I will update this post if I am able to get my hands on a copy.

For now, you can take a look at some sample files on Github, which I will also add some PRONOM signatures to soon.

iView

February 13, 2026 by Thor Leave a comment

It seems to be a common theme through the history of software that some titles, get bought, sold, rebranded, integrated, and discontinued by a number of companies. I find it interesting to find out a popular software title’s humble beginnings. Often when a piece of software gets bought, the file formats don’t change much, at least at first.

A little shareware program called iView started out by a company called Script Software in 1996. They later changed their name to Plum Amazing. iView then became iView Multimedia, then an iView MediaPro version before it was bought by Microsoft where they changed the name to Expression Media. After a couple years the software was bought by Phase One and then discontinued. Let’s take a look at the history.

iView, according to their website in 1997, is simply the easiest and fastest way to view and catalog pictures for the Mac. The software initially only worked on the Macintosh and the Catalog file it produced did not have an extension. But they did have a Type/Creator code. A catalog produced by version 2 of the iView software was IVWc/IVW2.

% hexdump -C iView2-s01 | head
00000000  00 00 00 05 30 32 35 69  47 4f 53 58 3a 4c 69 62  |....025iGOSX:Lib|
00000010  72 61 72 79 3a 41 70 70  6c 69 63 61 74 69 6f 6e  |rary:Application|
00000020  20 53 75 70 70 6f 72 74  3a 41 70 70 6c 65 3a 69  | Support:Apple:i|
00000030  43 68 61 74 20 49 63 6f  6e 73 3a 46 72 75 69 74  |Chat Icons:Fruit|
00000040  3a 47 72 65 65 6e 20 41  70 70 6c 65 2e 67 69 66  |:Green Apple.gif|
00000050  03 46 44 63 00 00 0f ef  03 46 44 63 08 93 65 58  |.FDc.....FDc..eX|
00000060  00 01 5c 50 00 01 5a c8  68 ff f7 40 08 93 65 4b  |..\P..Z.h..@..eK|
00000070  08 13 9a c0 ff d1 3a 80  00 a3 c8 a0 00 00 28 00  |......:.......(.|
00000080  00 05 48 64 00 00 a0 24  00 00 39 ec 00 00 00 0a  |..Hd...$..9.....|
00000090  08 93 65 64 44 00 00 24  3d 14 51 84 3d 9d 74 bc  |..edD..$=.Q.=.t.|

The iView format is a proprietary binary format used to store a catalog of multimedia formats with their metadata and thumbnail. The media viewer had support for quite a few popular formats. The file seems to have paths to each of the files it has cataloged, so some of these iView files can get pretty large.

In 2003 the iView software was ported to Windows. With that brought a formal extension to the catalog format. This was also the time the iView software made the switch from the classic MacOS to MacOSX and extensions were also encouraged at this time. iView had two different version a standard shareware version and a Media Pro version, each had their own version numbers. iView MediaPro was not compatible with Macintosh 68K machines or systems earlier than 8.6. The last Media Pro version was version 3.8.6. You can get most of the old software versions here.

% hexdump -C iViewPro302-s01.ivc | head
00000000  00 00 00 00 30 32 35 69  46 53 4d 21 00 00 00 2e  |....025iFSM!....|
00000010  66 6c 64 72 00 00 00 2e  00 00 00 00 00 00 00 06  |fldr............|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  3c 72 6f 6f 74 3e 42 4c  |........<root>BL|
00000040  44 4f 00 00 00 0c 31 00  02 00 00 00 01 01 00 00  |DO....1.........|
00000050  00 00 55 53 46 33 00 00  00 02 01 03 43 4d 52 53  |..USF3......CMRS|
00000060  00 00 01 ed 01 00 00 02  0a 01 00 00 00 00 00 00  |................|
00000070  00 02 f2 01 00 00 00 00  00 00 00 00 a2 01 00 00  |................|
00000080  00 00 02 01 03 00 00 00  a1 01 00 00 00 00 00 00  |................|
00000090  00 00 48 00 00 00 00 00  00 00 00 00 03 01 00 00  |..H.............|

This time with an extension, IVC, but with a familiar pattern at the beginning. The string 025i, hex values “30323569” at byte 4. The iView files from previous versions have the same bytes, but only version Media Pro 2 & 3 files match an existing PRONOM identification.

% sf iViewPro302-s01.ivc 
filename : 'iViewPro302-s01.ivc'
filesize : 3757
modified : 2025-09-17T17:39:27-06:00
errors   : 
matches  :
  - ns      : 'pronom'
    id      : 'fmt/647'
    format  : 'Microsoft Expression Media'
    version : '2'
    mime    : 
    class   : 'Presentation'
    basis   : 'extension match ivc; byte match at [[4 4] [3737 16]]'

These are iView Media Pro files, why are they identifying as Microsoft Expression Media files? That is because Microsoft bought iView Media Pro on June 27, 2006. Microsoft rebranded the software as Expression Media, not to be confused with Expression Studio. It was available for Windows and Macintosh, but not everyone was happy with the purchase. Version 1 of Expression Media was released the next year and was a free upgrade for iView Media Pro users. The format doesn’t appear to have changed much at all. In fact a comparison of an iView Media Pro 3 file with no content and an Expression Media 1 file are practically identical.

% hexdump -C Expression1-s01.ivc | head
00000000  00 00 00 00 30 32 35 69  46 53 4d 21 00 00 00 2e  |....025iFSM!....|
00000010  66 6c 64 72 00 00 00 2e  00 00 00 00 00 00 00 06  |fldr............|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  3c 72 6f 6f 74 3e 42 4c  |........<root>BL|
00000040  44 4f 00 00 00 0c 31 00  02 00 00 00 01 01 00 00  |DO....1.........|
00000050  00 00 55 53 46 33 00 00  00 02 01 03 43 4d 52 53  |..USF3......CMRS|
00000060  00 00 01 ed 01 00 00 02  0a 01 00 00 00 00 00 00  |................|
00000070  00 02 f2 01 00 00 00 00  00 00 00 00 a2 01 00 00  |................|
00000080  00 00 02 01 03 00 00 00  a1 01 00 00 00 00 00 00  |................|
00000090  00 00 48 00 00 00 00 00  00 00 00 00 03 01 00 00  |..H.............|

The next year brought a version 2 of Expression Media, often found bundled with a Special Edition of Office 2008 for Mac, but also a standalone product for Windows. But the catalog format remained the same.

% hexdump -C Expression2-s01.ivc | head       
00000000  00 00 00 04 30 32 35 69  3a 43 3a 5c 44 4f 43 55  |....025i:C:\DOCU|
00000010  4d 45 7e 31 5c 41 4c 4c  55 53 45 7e 31 5c 44 4f  |ME~1\ALLUSE~1\DO|
00000020  43 55 4d 45 7e 31 5c 4d  59 50 49 43 54 7e 31 5c  |CUME~1\MYPICT~1\|
00000030  53 41 4d 50 4c 45 7e 31  5c 57 69 6e 74 65 72 2e  |SAMPLE~1\Winter.|
00000040  6a 70 67 00 00 00 00 00  00 00 00 00 00 00 00 00  |jpg.............|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Even though all of these versions have the same 4 bytes at the beginning, not all of them match the current PRONOM signature. fmt/647 is specifically for Expression Media version 2 files, but also identifies iView Media Pro 2 & 3 and Expression Media 1 files. It doesn’t identify earlier files because the signature is also looking for some bytes near the end of the file.

% hexdump -C iViewPro302-s01.ivc | tail       

00000e90  00 00 00 00 00 00 00 00  00 53 56 61 72 00 00 00  |.........SVar...|
00000ea0  04 00 00 01 f4 30 32 35  69 00 00 00 08           |.....025i....|

There is the same 4 bytes at the end of the file as well. There is also a string used in the signature at the end, “SVar”. Not sure what the string is used for but it is not in earlier versions.

% hexdump -C iView157-01 | tail 

00000420  00 00 00 00 00 00 00 00  00 00 00 00 30 32 35 69  |............025i|
00000430  00 00 00 08                                       |....|

And the even earlier versions are missing the “025i” at the end.

% hexdump -C iView2-s01 | tail

000062b0  2a ae ed d4 1a eb d4 04  c4 88 76 88 c4 d6 d4 04  |*.........v.....|
000062c0  c4 79 69 79 c4 d6 d4 04  c4 78 67 78 c4 ec d4 04  |.yiy.....xgx....|
000062d0  81 d4 f1 d4 00 ff                                 |......|

Microsoft Expression Media was short lived. Microsoft decided to sell off the software to Phase One in 2010. Phase One is the developer of Capture One, a professional photo editing program. It makes sense they would want a cataloging tool to go with their flagship product. Phase One retained the name Media Pro from the original iView Media Pro software.

Phase One took the software and did make modifications, starting with the extension used to store the catalogs. They also decided to adjust the format slightly, changing the “025i” bytes to “030i”.

% hexdump -C PhaseOneMediaProv1.mpcatalog | head 
00000000  00 00 00 05 30 33 30 69  4a 4d 61 63 31 30 37 3a  |....030iJMac107:|
00000010  4c 69 62 72 61 72 79 3a  41 70 70 6c 69 63 61 74  |Library:Applicat|
00000020  69 6f 6e 20 53 75 70 70  6f 72 74 3a 41 70 70 6c  |ion Support:Appl|
00000030  65 3a 69 43 68 61 74 20  49 63 6f 6e 73 3a 46 72  |e:iChat Icons:Fr|
00000040  75 69 74 3a 47 72 65 65  6e 20 41 70 70 6c 65 2e  |uit:Green Apple.|
00000050  67 69 66 00 00 00 00 00  00 00 00 00 00 00 00 00  |gif.............|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

The Phase One Media Pro software uses the extension MPCATALOG, but can also open the older IVC catalogs as well.

% sf PhaseOneMediaProv1.mpcatalog 

filename : 'PhaseOneMediaProv1.mpcatalog'
filesize : 21353
modified : 2025-09-16T20:37:07-06:00
errors   : 
matches  :
  - ns      : 'pronom'
    id      : 'fmt/648'
    format  : 'Media View Pro'
    version : 
    mime    : 
    class   : 'Presentation'
    basis   : 'extension match mpcatalog; byte match at [[4 4] [21329 16]]'

MPCATALOG files are identified in PRONOM using a similar signature as the one used for the IVC files. Although the name of the format isn’t quite right, MediaPro is probably a better name.

So it seems the identification is already available in PRONOM for the later MediaPro files, both iView MediaPro and Expression Media, and a second identification for the PhaseOne catalog. So we will need to either adjust the identification to include the earlier iView versions and adjust the names or we can create a new signature for the older versions. It would be good to find out what version added the change to the format, but with all the different software versions, it might be hard to nail down.

Enjoy some samples.

Scrivener

March 21, 2025 by Thor 1 Comment

Word Processors are everywhere and have some of the most recognizable file formats. Some are very simple in that they just contain plain text, others are more complex. There are formats which allow for images and others which can handle different languages and writing directions.

A writing platform I recently learned about is called Scrivener. It was first released in 2007 by a company called Literature & Latte Ltd, and has a Macintosh and Windows version. The software is marketed toward writers as there is some features that help with note taking, research and much more. It also allows for adding multimedia and even full webpages.

This is accomplished by a file format which uses a non-traditional method for storing all the data needed to render the format.

tree Scrivener3-s01.scriv
Scrivener3-s01.scriv
├── Files
│   ├── Data
│   │   ├── 921B4A08-54C0-4B69-94FD-428F56FDAB89
│   │   │   └── content.rtf
│   │   └── docs.checksum
│   ├── binder.autosave
│   ├── binder.backup
│   ├── search.indexes
│   ├── styles.xml
│   ├── version.txt
│   └── writing.history
├── Scrivener3-s01.scrivx
└── Settings
    ├── recents.txt
    ├── ui-common.xml
    └── ui.ini

Scrivener uses a folder structure to store all the data used in the format. The folder has an extension, .scriv. The format includes some rich text, backups, indexes, version history and more. One unique format within the folder is an XML file with the extension .scrivx. This makes the format proprietary and can only be rendered using the Scrivener software.

cat Scrivener3-s01.scrivx | head
<?xml version="1.0" encoding="UTF-8"?>
<ScrivenerProject Template="No" Version="2.0" Identifier="DF5DA7F0-27DB-4815-A050-B4D6F23CABA7" Creator="SCRWIN-3.1.5.1" Device="DESKTOP-JMM4K7M" Modified="2025-03-14 22:15:28 -0600" ModID="B4A944C3-FF79-49F6-A737-158BEB4E58BB">
    <Binder>
        <BinderItem UUID="17807D28-117A-409E-B12D-B34922B6CC6F" Type="DraftFolder" Created="2025-03-14 22:15:17 -0600" Modified="2025-03-14 22:15:17 -0600">
            <Title>Draft</Title>
            <MetaData>
                <IncludeInCompile>Yes</IncludeInCompile>
            </MetaData>
            <Children>
                <BinderItem UUID="921B4A08-54C0-4B69-94FD-428F56FDAB89" Type="Text" Created="2025-03-14 22:15:17 -0600" Modified="2025-03-14 22:15:23 -0600">

The XML has enough to be able to identify them apart from other XML files. The signature would be straight forward. Earlier versions of Scrivener sometimes have the SCRIVX file but also sometimes has a
.scrivproj extension. This file on a Macintosh is in a Binary plist format, which is different than earlier Windows versions. Seems they may have unified them under version 2 or 3, where version 1 & 2 for Windows uses Project version 1 and version 3 uses project version 2.

hexdump -C Scrivener1-s01.scriv/binder.scrivproj | head
00000000  62 70 6c 69 73 74 30 30  d4 00 01 00 02 00 03 00  |bplist00........|
00000010  04 00 05 00 1d 01 d8 01  d9 54 24 74 6f 70 58 24  |.........T$topX$|
00000020  6f 62 6a 65 63 74 73 58  24 76 65 72 73 69 6f 6e  |objectsX$version|
00000030  59 24 61 72 63 68 69 76  65 72 dc 00 06 00 07 00  |Y$archiver......|
00000040  08 00 09 00 0a 00 0b 00  0c 00 0d 00 0e 00 0f 00  |................|
00000050  10 00 11 00 12 00 13 00  14 00 15 00 16 00 17 00  |................|
00000060  18 00 19 00 1a 00 15 00  1b 00 1c 5a 4c 61 62 65  |...........ZLabe|
00000070  6c 54 69 74 6c 65 59 4c  61 62 65 6c 4c 69 73 74  |lTitleYLabelList|
00000080  5e 42 69 6e 64 65 72 43  6f 6e 74 65 6e 74 73 5f  |^BinderContents_|
00000090  10 0f 44 65 66 61 75 6c  74 4c 61 62 65 6c 54 61  |..DefaultLabelTa|

Since the developers of Scrivener decided to make the SCRIV format simply a folder with different content within, something special happens on the MacOS. The Scrivener software registers all the extensions is uses with the MacOS launch services. This process then changes the way the SCRIV folder is displayed in the MacOS Finder. They now appears as a single file and given a file type. This is called a Document Package format.

By right-clicking on the “file” you can then browse the package contents. There is nothing in the folder itself or hidden in any attributes which causes this to happen, it is all controlled by what extensions have been registered with the launch services database. We can however ask the MacOS to give us some extended metadata details about the package, as long as the file is on a Apple filesystem like HFS or APFS.

mdls Scrivener3-s01.scriv 
_kMDItemDisplayNameWithExtensions      = "Scrivener3-s01.scriv"
kMDItemContentCreationDate             = 2025-03-15 04:15:17 +0000
kMDItemContentCreationDate_Ranking     = 2025-03-15 00:00:00 +0000
kMDItemContentModificationDate         = 2025-03-15 04:15:18 +0000
kMDItemContentModificationDate_Ranking = 2025-03-15 00:00:00 +0000
kMDItemContentType                     = "com.literatureandlatte.scrivener3.scriv"
kMDItemContentTypeTree                 = (
    "com.literatureandlatte.scrivener3.scriv",
    "public.directory",
    "public.item",
    "com.apple.package",
    "public.content",
    "public.composite-content"
)
kMDItemDateAdded                       = 2025-03-21 04:38:48 +0000
kMDItemDateAdded_Ranking               = 2025-03-21 00:00:00 +0000
kMDItemDisplayName                     = "Scrivener3-s01.scriv"
kMDItemDocumentIdentifier              = 0
kMDItemFSContentChangeDate             = 2025-03-15 04:15:18 +0000
kMDItemFSCreationDate                  = 2025-03-15 04:15:17 +0000
kMDItemFSCreatorCode                   = ""
kMDItemFSFinderFlags                   = 0
kMDItemFSHasCustomIcon                 = (null)
kMDItemFSInvisible                     = 0
kMDItemFSIsExtensionHidden             = 0
kMDItemFSIsStationery                  = (null)
kMDItemFSLabel                         = 0
kMDItemFSName                          = "Scrivener3-s01.scriv"
kMDItemFSNodeCount                     = 3
kMDItemFSOwnerGroupID                  = 20
kMDItemFSOwnerUserID                   = 501
kMDItemFSSize                          = 31155
kMDItemFSTypeCode                      = ""
kMDItemInterestingDate_Ranking         = 2025-03-15 00:00:00 +0000
kMDItemKind                            = "Scrivener Project"
kMDItemLogicalSize                     = 31155
kMDItemPhysicalSize                    = 69632

There is a lot of additional details available using the MDLS command, this includes the content type of “com.apple.package“. This tools works with any files in MacOS and can be a very useful tool in getting all the information you may need for preservation needs.

Until the tools we use for format identification can recognize package formats, tools like this may be needed to gather the neccessary metadata for preservation. But in the meantime, identification of the package content is the best we can hope for. Creating a signature for the XML based SCRIVX format is the first step.

Stay tuned for more on the package format as I will be bring it up more in the Digital Preservation community.

HFE

September 27, 2024 by Thor 2 Comments

Last week I had the pleasure of attending the 20th annual iPres conference on Digital Preservation in Ghent, Belgium. I enjoyed hearing from many of my respected colleagues on many aspects of preservation including one of my favorite topics, floppy disks. There was tutorials, lightning talks, and even a workshop, presented by Leontien Talboom, Elizabeth Kata, Chris Knowles, and myself. We titled the workshop “A Guide to Imaging Obscure Floppy Disk Formats“. The workshop was conceived by a mutual interest in imaging Wang 5.25in word processor disks, but expanded to include imaging of Amstrad 3in disks, 240K Brother Typewriter Disks, and Macintosh 400/800k disks.

I brought my hand soldered FluxEngine board and others brought their Greaseweazle board to show off how imaging obscure and uncommon disks can be done on a budget.

Photo of workshop taken on a Mavica Floppy Disk camera — Image taken during workshop on a Mavica FD200 Floppy Disk Camera.

During the conference we talked a bit about the different type of hardware that can be used and the difference between a disk image and flux image. There seems to be quite the exhaustive list of different types of file formats, some specific to a platform and others more generic. I recently did a blog post on the formats used by the Applesauce software, which have some unique features.

There are many disk image types which should be researched and added to PRONOM and other format description sites, but today lets take a look at a generic format used by many tools.

The HxC Floppy Emulator file format which the extension HFE is a popular format used with floppy drive emulators. There is a lot of complexity with what is included in many of these image formats, some are simply a raw sector representation of the binary data on a disk, others contain the complete flux readings from a floppy disk. The HFE format contains a little more than a raw image, including a header, a track lookup table, and the bitstreams for each track all with the purpose of emulating the physical media. The HFE format contains only a single pass over the data, where other formats may contain multiple reading of each track to get more complete data which can be helpful for damaged or purposely copy-protected disks. You can read more on Ashley’s blog, Library of Congress format description.

When using the HxC Floppy Emulator software, you can open and save to many different formats. The main format being their HFE native format. It comes in 5 versions.

hexdump -C test01.hfe | head
00000000  48 58 43 50 49 43 46 45  00 53 02 00 e8 01 00 00  |HXCPICFE.S......|
00000010  07 01 01 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

Above is a hexdump of the main SDCard HxC Floppy Emulator file format. The format specification shows the 8 byte header “HXCPICFE”. This is a very unique pattern and should be all we need to make a robust signature for the format, but we do need to take into account the other HFE “versions” and see if they might clash or need to be identified separately.

hexdump -C test02-a2.hfe | head 
00000000  48 58 43 50 49 43 46 45  00 53 02 00 d0 03 00 00  |HXCPICFE.S......|
00000010  07 01 01 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

The “A2” version of the format has the same header but some different bytes further into the file.

hexdump -C test03-rev2.hfe | head
00000000  48 58 43 50 49 43 46 45  01 53 02 00 00 00 00 00  |HXCPICFE.S......|
00000010  07 01 01 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

The “Rev 2” version also has the same header. But if you look at the 9th byte you can see the value changed from 00 to 01, which according to the specification, this is the revision byte.

hexdump -C test04-rev3.hfe | head 
00000000  48 58 43 48 46 45 56 33  00 53 02 00 e8 01 00 00  |HXCHFEV3.S......|
00000010  07 01 01 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

With “Rev 3” we see a change in the header with “HXCHFEV3” which appears to be referred to as HFEv3.

hexdump -C test05-stream.hfe | head 
00000000  48 78 43 5f 53 74 72 65  61 6d 5f 49 6d 61 67 65  |HxC_Stream_Image|
00000010  00 00 00 00 00 00 00 00  00 18 00 00 00 02 00 00  |................|
00000020  00 1a 00 00 53 00 00 00  02 00 00 00 40 9c 00 00  |....S.......@...|
00000030  07 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

This last format seems to be a special HxC stream image.

It seems the best option is to make three signatures to identify the three main headers. Additional software can be used to further parse the disk image. If you would like to see some sample images, you can download a bunch here. You can also take a look at my GitHub repository to see additional samples and a proposed set of signatures.

A2R / MOOF / WOZ

August 16, 2024 by Thor 2 Comments

There seems to be a never ending growing list of disk image formats. Many have features which are specific to the media and format. If you have ever imaged an older Macintosh floppy you know they are special. If you add in copy-protection which many early Apple II floppies have, and you need special drives, hardware, and a special format to store the floppy data.

When imaging special media, especially with unique media, it is best practice to image the floppies at the magnetic flux level.

Floppy disks contain magnetic fluctuations which are measured and recorded using specialized equipment. A popular method is using a Kryoflux board, floppy drive, and software. The software communicates with a custom controller board connected to a floppy drive through USB. If you are interested in the different controller boards, a good list has been compiled here.

A Kryoflux, fluxengine, greaseweazle, all can image specialized disks like a Macintosh 800k floppy, but the best controller board for them is an Applesauce setup. They are specifically designed to for the task. With that task, comes a few specialty formats.

A file format which can store flux data is a bit different than a regular disk image format. The flux data contains all the low-level recordings which can then be interpreted into disk images much like the original floppy. In the case of an Applesauce flux image, it can contain all the small nuances of the original floppy, this includes recording any copy protection or other creative methods used by software vendors throughout the years. The format used for storing this flux data is the A2R format.

A2R is in its third iteration. Let’s take a look at the basics of the format.

hexdump -C Samplev3.a2r | head
00000000  41 32 52 33 ff 0a 0d 0a  49 4e 46 4f 25 00 00 00  |A2R3....INFO%...|
00000010  01 41 70 70 6c 65 73 61  75 63 65 20 76 31 2e 38  |.Applesauce v1.8|
00000020  38 2e 35 20 20 20 20 20  20 20 20 20 20 20 20 20  |8.5             |
00000030  20 02 01 01 00 52 57 43  50 e9 49 6e 01 01 24 f4  | ....RWCP.In..$.|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 43 01 00  |.............C..|
00000050  00 01 27 3a 25 00 91 d9  00 00 21 20 21 21 21 21  |..':%.....! !!!!|
00000060  1f 21 21 21 21 1f 24 5e  24 1f 21 21 20 21 24 5c  |.!!!!.$^$.!! !$\|
00000070  24 20 21 21 21 1f 24 5c  25 21 21 1f 21 21 23 5b  |$ !!!.$\%!!.!!#[|
00000080  25 20 21 21 21 1f 21 22  23 3f 41 3f 26 3e 43 3f  |% !!!.!"#?A?&>C?|
00000090  43 5f 41 27 3d 61 41 27  3d 61 3f 28 3e 61 3f 26  |C_A'=aA'=a?(>a?&|

hexdump -C Samplev2.a2r | head
00000000  41 32 52 32 ff 0a 0d 0a  49 4e 46 4f 24 00 00 00  |A2R2....INFO$...|
00000010  01 41 70 70 6c 65 73 61  75 63 65 20 76 31 2e 31  |.Applesauce v1.1|
00000020  2e 36 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |.6              |
00000030  20 02 01 01 53 54 52 4d  75 17 5d 01 00 01 e6 da  | ...STRMu.].....|
00000040  00 00 83 a9 12 00 12 1e  11 13 1e 13 1e 13 11 1f  |................|
00000050  21 1f 11 13 1c 14 1e 30  14 20 1e 14 1e 14 1c 14  |!......0. ......|
00000060  1c 13 11 20 21 1f 11 11  0f 13 1e 14 1c 14 2e 21  |... !..........!|
00000070  13 1e 13 1e 14 1e 11 11  20 21 1f 11 11 13 1e 1f  |........ !......|
00000080  13 20 30 21 11 11 0f 13  1e 13 11 30 1f 21 20 13  |. 0!.......0.! .|
00000090  11 30 1f 14 1e 30 14 1e  11 11 11 1e 13 11 1e 14  |.0...0..........|

The A2R format uses a chunk system to store the various pieces to the format. Earlier versions used a STRM Chunk to store all the raw flux data. Version 3 changed to a RWCP Chunk to store all the raw flux data. Applesauce uses a 2-pass imaging process, doing a rapid imaging to determine where on the media surface track data exists and then a second pass that captures longer durations for processing and error correction.

Once the full raw flux data has been captured that data can be interpreted as a disk image. The Applesauce software is able to make a regular disk image, a Disk Copy 4.2 file, which are well known and identify in PRONOM as fmt/625, but can also create a couple of special disk image formats which allow for special nuances on an original disk.

The WOZ Disk Image format is an offshoot of the Applesauce project. Capturing highly accurate bit data is of no use if you don’t have a container to hold the data. The WOZ format was designed to be able to contain every possible Apple ][ disk structure and layout. It can be so accurate that even copy protected software can’t tell that it isn’t an original disk.

The WOZ format has become very popular in the Apple II community and is ideal for emulating all the old games and software titles popular in the early 1980’s. You may have guessed where the name comes from. The internet archive has a large collection of WOZ disks in their WOZ-a-Day collection. The file format of a WOZ disk image is also a chunk based format similar to the A2R format, it has two versions. Let’s take a look.

hexdump -C WOZ 1.0/Blazing Paddles (Baudville).woz | head
00000000  57 4f 5a 31 ff 0a 0d 0a  f6 f5 92 d6 49 4e 46 4f  |WOZ1........INFO|
00000010  3c 00 00 00 01 01 00 01  01 41 70 70 6c 65 73 61  |<........Applesa|
00000020  75 63 65 20 76 30 2e 32  36 20 20 20 20 20 20 20  |uce v0.26       |
00000030  20 20 20 20 20 20 20 20  20 00 00 00 00 00 00 00  |         .......|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  54 4d 41 50 a0 00 00 00  00 00 ff 01 01 01 ff 02  |TMAP............|
00000060  02 02 ff 03 03 03 ff 04  04 04 ff 05 05 05 ff 06  |................|
00000070  06 06 ff 07 07 07 ff 08  08 08 ff 09 09 09 ff 0a  |................|
00000080  0a 0a ff 0b 0b 0b ff 0c  0c 0c ff 0d 0d 0d ff 0e  |................|
00000090  0e 0e ff 0f 0f 0f ff 10  10 10 ff 11 11 11 ff 12  |................|

hexdump -C WOZ 2.0/Blazing Paddles (Baudville).woz | head
00000000  57 4f 5a 32 ff 0a 0d 0a  21 da c2 c8 49 4e 46 4f  |WOZ2....!...INFO|
00000010  3c 00 00 00 02 01 00 01  01 41 70 70 6c 65 73 61  |<........Applesa|
00000020  75 63 65 20 76 31 2e 31  20 20 20 20 20 20 20 20  |uce v1.1        |
00000030  20 20 20 20 20 20 20 20  20 01 01 20 00 00 00 00  |         .. ....|
00000040  0d 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  54 4d 41 50 a0 00 00 00  00 00 ff 01 01 01 ff 02  |TMAP............|
00000060  02 02 ff 03 03 03 ff 04  04 04 ff 05 05 05 ff 06  |................|
00000070  06 06 ff 07 07 07 ff 08  08 08 ff 09 09 09 ff 0a  |................|
00000080  0a 0a ff 0b 0b 0b ff 0c  0c 0c ff 0d 0d 0d ff 0e  |................|
00000090  0e 0e ff 0f 0f 0f ff 10  10 10 ff 11 11 11 ff 12  |................|

Unlike a common disk image, a WOZ image contains more than the bits on the disk, it contains a mapping of all the tracks and the associated data, this is how it can even contain copy-protection usually only possible with a physical disk. The ‘TMAP’ chunk contains a track map and the ‘TRKS’ chunk contains all the data.

What the WOZ is for the Apple II, MOOF was made for the Macintosh. You may wonder what is with the funny name, but there is a long history around “Clarus the Dogcow”. I’m sure this factoid will help you impress your friends or win at trivia night. Again, the purpose of the special format for Macintosh disks is to allow for emulating disks, even with copy protection. You can also find quite the collection of old Macintosh software in the MOOF format on the Internet Archive, even emulate your favorite game, such as Dark Castle, which I played for hours as a kid. Also a chunk based format, let’s take a look at the header.

hexdump -C Dark Castle v1.0 - Disk 1.moof | head
00000000  4d 4f 4f 46 ff 0a 0d 0a  b5 75 f9 4e 49 4e 46 4f  |MOOF.....u.NINFO|
00000010  3c 00 00 00 01 01 00 01  10 41 70 70 6c 65 73 61  |<........Applesa|
00000020  75 63 65 20 76 31 2e 37  33 20 20 20 20 20 20 20  |uce v1.73       |
00000030  20 20 20 20 20 20 20 20  20 00 13 00 00 00 00 00  |         .......|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  54 4d 41 50 a0 00 00 00  00 ff 01 ff 02 ff 03 ff  |TMAP............|
00000060  04 ff 05 ff 06 ff 07 ff  08 ff 09 ff 0a ff 0b ff  |................|
00000070  0c ff 0d ff 0e ff 0f ff  10 ff 11 ff 12 ff 13 ff  |................|
00000080  14 ff 15 ff 16 ff 17 ff  18 ff 19 ff 1a ff 1b ff  |................|
00000090  1c ff 1d ff 1e ff 1f ff  20 ff 21 ff 22 ff 23 ff  |........ .!.".#.|

All three formats created for imaging and emulating Apple and Macintosh software are well documented and open. They are also well suited for preservation as they can contain extensive metadata in the INFO chunk which gives provenance information on the source of the files. The Applesauce software even has a camera to photograph the disk itself for archiving. All of this makes these formats great for preservation and emulation. Take a look at my proposal for a signature on my Github.

PROmotion

May 3, 2024 by Thor 1 Comment

The 1990’s was an amazing time for multimedia. Compared to what is possible today, the graphics were more simple but there were many software titles leading the charge in Animation. Macromedia Director, along with Flash, dominated the interactive multimedia market for quite some time. Eventually being picked up by Adobe and discontinued in 2013. Quite a few multimedia disc’s out there were built using Director.

Competing with Director, another company had a strong product. Motion Works International was an early pioneer in the multimedia CD-ROM scene. Rumor has it, Motion Works was started by a 12 year old. Motion Works had been making software for use with the highly successful HyperCard software since 1988. In 1992 they released the successor to their ADDmotion software, a path based animation tool called PROmotion.

PROmotion was used with with many Multimedia titles, some in cooperation with the Corel Home series. In addition to commercial titles PROmotion was a great tool for the creation of animation clips and other marketing material. I came across some stand-alone marketing files for old scriptwriting software called ScriptWare. When I unarchived the HQX file and Installed the Demo, I was presented with a set of files with the .MW extension.

ls -l@
total 10232
-rw-r--r--@ 1 tyler  staff  1392 May  1 23:17 Read me first!
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	 452 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 begin_here.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	158901 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 characters.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	387029 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 cinovation.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	189509 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 cut paste.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	608405 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 formats.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	289698 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 modify formats.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	486730 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 notes.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	319250 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 overview.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	376854 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 scene shuffle.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	359746 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 script elements.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	279052 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 sw_menu.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	421836 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 title page.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	236614 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 transitions.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	471462 
-rw-r--r--@ 1 tyler  staff     0 May  1 23:17 try it.MW
	com.apple.FinderInfo	  32 
	com.apple.ResourceFork	622312 

getfileinfo sw_menu.MW 
file: "sw_menu.MW"
type: "APPL"
creator: "AMvw"

Looking at the files in the directory with their extended attributes I can see all the .MW files have no data fork (0 bytes), only a resource fork. This is common for any Application on the MacOS systems prior to MacOS X. At first the MW extension made me thing of MacWrite, but launching one of these MW files brought up an interactive menu. The type being APPL, which is Application.

What I thought would be a demo of the application Scriptware was actually interactive animations demonstrating the software. By dumping the resource fork of one of the MW files I found some information which helped me know what software created these interactive demos.

derez Scriptware\ Demo\ folder/sw_menu.MW

data 'vers' (1) {
	$"0103 8000 0000 0531 2E30 2E33 2941 4D20"            /* ..?....1.0.3)AM  */
	$"5669 6577 6572 2031 2E30 2E33 0DA9 2031"            /* Viewer 1.0.3.? 1 */
	$"3939 3320 4D6F 7469 6F6E 2057 6F72 6B73"            /* 993 Motion Works */
	$"2049 6E74 6C2E"                                     /*  Intl. */
};

data 'vers' (2) {
	$"0103 8000 0000 0531 2E30 2E33 1E50 6C61"            /* ..?....1.0.3.Pla */
	$"7962 6163 6B20 6279 204D 6F74 696F 6E20"            /* yback by Motion  */
	$"576F 726B 7320 496E 746C 2E"                        /* Works Intl. */
};

data 'STR#' (1250, "ADDmotion HC strings") {
	$"000A 1641 4444 6D6F 7469 6F6E 5F65 7870"            /* ...ADDmotion_exp */
	$"6F72 745F 6672 616D 650E 4144 446D 6F74"            /* ort_frame.ADDmot */
	$"696F 6E5F 696E 666F 1141 4444 6D6F 7469"            /* ion_info.ADDmoti */
	$"6F6E 5F73 7573 7065 6E64 1041 4444 6D6F"            /* on_suspend.ADDmo */
	$"7469 6F6E 5F72 6573 756D 650E 4144 446D"            /* tion_resume.ADDm */
	$"6F74 696F 6E5F 7175 6974 0E41 4444 6D6F"            /* otion_quit.ADDmo */
	$"7469 6F6E 5F70 6C61 790E 4144 446D 6F74"            /* tion_play.ADDmot */
	$"696F 6E5F 7374 6F70 0F41 4444 6D6F 7469"            /* ion_stop.ADDmoti */
	$"6F6E 5F70 6175 7365 0000"                           /* on_pause.. */
};

Makes sense, MW stood for “Motion Works”. ADDmotion was another software title developed by Motion Works, most will remember it as an add-on for Hypercard for adding animation to stacks. These MW files are created using PROmotion and exporting them as a stand-alone animation which includes the “AM Viewer” built in. A regular PROmotion file, however, did not include a viewer and requires the software in order to open and run.

-rwx------@ 1 tyler  staff      0 Apr 25 15:51 Example Animation
	com.apple.FinderInfo	   32 
	com.apple.ResourceFork	495272

The PROmotion file format also is Resource Fork only, making them difficult to manage outside of a Macintosh.

getfileinfo Example\ Animation
file: "Example Animation"
type: "ADDm"
creator: "ADDm"

The files do have a Type/Creator code of “ADDm”, but with no data fork, identification through standard means is not possible. They also do not have the “vers” string to help identify them within the Resource Fork. Since standard methods of identification are impossible, I hope in the future there will be more tools available to read the Type/Creator codes while on the Mac, or in a disk image, or within a container and return back the Software which created the file and the file type.

The products from Motion Works where significantly cheaper than animation tools such as Director, but were still pretty powerful for its day. I was surprised when I found the company didn’t last much longer than 1998 before disappearing. There are probably many stories like PROmotion, coming onto the scene with new and exciting features before thought impossible only to die out as other tools dominate the market.

If you are interested in looking at the files yourself, here is a link to some original files, and the same files encoded in MacBinary.