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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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
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.
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.
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.
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”
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.
There was a lot of CAD programs in the 1980’s through the 1990’s. Some titles might be TurboCAD, DesignCAD, Generic CADD, KeyCAD, SwiftCAD, CADKEY, VersaCAD, MiniCAD, EasyCAD, and of course AutoCAD. Also, many file formats. Some had chosen the common DXF exchange format, but most chose their own way to do things.
AutoCAD is software made by AutoDesk, but is one of many software tools made by them. AutoCAD has its own native file format, DWG, as is well documented, but there was a little brother to AutoCAD marketed for a few years and it also had its own format(s).
AutoSketch was a less powerful version of AutoCAD and only supported 2D models, but still found a good following of users. Unlike its big brother, the AutoSketch native format(s) don’t have much documentation and are not supported in any AutoDesk product today. The PRONOM entry for the SKF (fmt/306) is missing a signature, it is an outline entry only. In addition, SKF, AutoSketch had an earlier format that needs to be documented and a signature created. Let’s take a look.
The first version of AutoSketch came out in 1986 for DOS and files stored in RAM which could be written out as a SKD file. Looking at a saved file, we see a very easy to identify file.
Most formats don’t make it this easy. Having the ASCII string “AutoSketch drawing database” makes identification very easy. Lets see if this pattern stays true with the next version, version 2.0 for DOS.
Turns out AutoDesk made a change to the SKD format and you can see the version number at 473rd byte (0x1D9). This version of SKD is required for later versions of AutoSketch to open and use the format. A special version of AutoSketch, 2.1fc, was released with limited features to allow users to open earlier versions of the SKD format and convert them to the second version of the format. The readme file for the 2.1fc version has this statement:
This limited release of AutoSketch has been provided for file conversion purposes only. All functionality other than opening and saving files has been removed from this release.
Please follow the steps below to perform a drawing file conversion for files created in AutoSketch Release 2.0 for Windows, or earlier. Once drawing files have been converted, you will be able to open them in AutoSketch Release 5.0 and later.
AutoDesk released the first version of AutoSketch for Windows in 1992. This first version for Windows used the new SKD format as well. Even though it was version 1.0 for Windows, the new version of the format is known as the v2.x format.
This is the format used through version 2.1 for Windows which was released in 1996. It was after this version AutoDesk made a major change to the software. In version 5, skipping 3 and 4, an entirely new drawing engine was used, changing the software and the file format. This new format is actually the format used by the software the new drawing engine came from, DrafixCAD. AutoDesk purchased the software company Softdesk Drafix and used the DrafixCAD software, originally developed by Foresight Resources Corp., for this new version of AutoSketch.
Let’s compare a couple of DrafixCAD files to an AutoSketch 5 and 6 file.
You can see the similar pattern in the first 8 bytes. Just the 2nd and 7th byte being different. The 8th byte is consistent with all SKF files, and the 9th and 10th bytes turn out to be in sequence depending on the version.
Looking at the next few versions of AutoSketch we see:
Version 10 was the final version released of AutoSketch in 2008. It appears the SKF files from version 7 & 8 share the same format and 9 & 10 share one as well. This seems to be confirmed in the save as dialog in version 9 which lumps version 7 & 8 together.
So, if we wanted to make one signature for all SKF files, it might look something like:
0A000000000B0334(30|31)(31|32|33)
Or we can choose to split out versions if needed. For now, adding this signature to the existing PRONOM entry for SKF would be helpful. As for the earlier SKD format, we clearly need two signatures, one for the first version and one for the second.
Here is a small timeline of the different versions of AutoSketch.
AutoSketch Release 1.0 DOS 1986-10 AutoSketch Release 1.01 DOS 1987-02 AutoSketch Release 1.02 DOS 1987-09 AutoSketch Release 1.03 DOS 1988-02 AutoSketch Release 2.0 DOS 1989 AutoSketch Release 3.0 DOS 1990 AutoSketch Release 3.1 DOS 1991 AutoSketch Release 1.0 Windows 1992 AutoSketch Release 2.0 Windows 1994 AutoSketch Release 2.1 Windows 1996 AutoSketch Release 5 Windows 1997-11 AutoSketch Release 6 Windows 1998-10 AutoSketch Release 7 Windows 1999 AutoSketch Release 8 Windows 2001 AutoSketch Release 9 Windows 2004-09-20 AutoSketch Release 10 Windows 2008-11
I need to do a little more research on the DrafixCAD format, but I will update the signature when I do. As always take a look at my samples and suggested signatures on my GitHub page.
In honor of the 25th of May, aka #525FloppyDay, I have a few thoughts on 5.25″ Floppy Disks, more specifically, the sleeves that protect them.
This year marks the 50th anniversary of the 5.25″ Floppy Disk. Prior to 1976, Floppy Disks were a massive 8 inches square which also used sleeves. It wasn’t until the need to make the disk smaller or “mini-diskette” in 1976 that the media became more popular and used in most desktop computers systems in the 1980’s. I won’t get into all the different ways data was encoded on these diskette’s as that is a massive topic, so today we will look at an often overlooked feature of the media. The protective sleeve.
For the sake of consistency, I will call this protection a sleeve, but may also be referred to as an envelope, jacket, or a pouch. Pouch being used by the folks down-under. The sleeve was mainly used for storage of the disk, but was also a great marketing tool and on the backside a reminder of the proper care of the disk. Floppy disk manufacturers and software companies would use the sleeve to print their logo and other important information about the disk, some opting for blank or generic graphics. Today we will look at some of the creative and not so creative uses.
Sleeves for floppy disks were made of a few different types of material. Plain paper sleeves were very common, many of which have yellowed over time. Some were very thin, others quite thick to offer more protection. One type of material often used for a sleeve is called Olefin. Kind of a cross between paper and plastic, this spun bonded material was used by many manufactures because of this superior durability an its ability repel water. This material made by Dupont was named Tyvek and has many uses, one use being found protecting the walls of your home.
As far as I know there is no “archive” documenting all floppy disk sleeves. There is a website called the Original Disk Sleeve Archive started years ago and has many sleeves referenced, but hasn’t been updated in awhile. Jason Scott at the Internet Archive has also uploaded scans he has made, here and here.
Today I would like to share my collection of Sleeves with you. I scanned them myself from my collection at a massive 1200 dpi so you can explore all the details and find creative uses for them.
You will find most of the sleeves have a logo or name on the front, but the back may have some interesting icons. These icons helped remind us of the fragile nature of floppy disks and the care needed to make them last. The icons can be understood without any explanation, using familiar images. Some having the typical circle with a line through it, indicating to NOT do something, others would use simple words in a few languages to get the meaning across. Then you have some who decided to go with humor or clever phrases to get the message across. In all, the messages were clear and understood, but as the floppy disk lost its usefulness over time, the icons and messages disappeared to time as well.
You might noticed many of the different sleeves in my collection have a common set of icons, which were probably bought instead of designing their own by many companies. Others spent some time and effect into designing their own.
Generally they all follow they same message, Do not bend, only use soft tip pens or markers, never use paper clips, don’t touch the magnetic media with your hands, and most of all, keep magnets away from the disk. Others would indicate to be sure to insert into the drive carefully and not to force them. Many list the proper temperature and humidity to store the disks, which is a very wide range.
The sources of magnetism are very different from what we might find today in a typical office or home. No longer do we see large heavy telephones which huge magnets inside, or huge CRT monitors, nor do many of us keep large multimedia speakers at our desks, but these were real dangers when floppy disks were in use. For those who use floppy disks today, we have new unknown dangers to contend with, the modern laptop and cell phone which can be deadly to magnetic media. I explore this and other myths in a paper submitted to iPres this fall, stay tuned!
One of my favorite practical back sides is this one from Elephant Memory Systems. Don’t touch the shiny Parts! Also a reminder of making a copy of your data if it’s important, a good preservation principle.
There are some slightly humorous instructions, like not letting your disk drink or smoke.
Or this clever set of instructions. Letting us know to avoid letting our disks die an agonizing death and to keep them happy.
But of course the the most famous of all disk care backside instructions go to the Beagle Bros. They decided to go with something less practical and more humorous to get their point across.
The Beagle Bros were a software company and distributor who mainly distributed Apple II software in the 1980’s. The art is credited to Fred Crone, an artist for the Beagle Bros, who with is wife Sara created much of the art used by the software company. The warnings were so popular, they got asked frequently if the warnings could be reprinted and permission was happily given. You can find more images and history at the Beagles Bros Repository. Which is your favorite?
If you happen to catch me at a conference or send me a nice message below, I might part with a few stickers I have made using many of the icons and warnings you find on the back of these sleeves. Enjoy.
I found myself in the same situation again with a colleague asking me for help identifying an unknown file. The file in question did not have an extension and to make things harder, the file could not be shared with me, only the header. So not having much to go on I started with some assumptions. Not having an extension leans toward the file being from an early Macintosh system. My favorite. I asked some follow up questions and learned the file was from around 2002, but no longer had any extended attributes that might contain a type creator code to help with identification. There was also mentioned of layers and fonts later in the file I was told.
Looking at the header sent to me, there was an obviously first choice to look into.
cd cd 20 07 43 41 4e 56 (ÍÍ CANV)
With the ASCII text “CANV“, the initial thought was this file was related to the popular Canvas software. I did a post on the Canvas formats a couple years ago so I went back through my files and could not find any match. Most uncompressed Canvas files use “CANVAS5” or “CANVAS6”, nothing which was shortened to CANV. I check all the samples I have from many versions. Back to square one.
I looked at other graphics and desktop publishing programs from the time period, I even asked AI to help me narrow it down. AI also recommended Canvas, but also many others I was already aware of and had dismissed. AI did not know what to make of the CANV string in the header, it was not too helpful. I did follow a couple of leads it gave me, but they led to dead ends. One title I looked into was called Desktop Publisher Pro. Files from this software also had a unique header, but nothing resembling what I was looking for. Maybe I will do another post of this software in the future.
So the next step in my process was to scan through all my sample data sets for something that matched or was close. I made a simple signature with the CANV header, but also one with the “CDCD” hex values as it seemed unique as well. I set the scan to run overnight on my sample set and the next morning I was met with disappointment. Not one match. I decided to run the same signatures across a few of my other drives of personal files, just for good measure. The next morning I had a surprise. Within the 10’s of thousands of files scanned, one file popped. The file the scan found also had no extension and the software that created it was no longer on my computer so the file was not associated with any software. But luckily in my case, the Type/Creator code was still attached!
There it is! The header with CANV. Looking up the Creator code “ARTD” in my TCDB tool, I learned the creator of the file.
% python3 TC-lookup-draft-uni.py "MC Wrap" Type Code: DISC Creator Code: ARTD Size of Data Fork: 18483930 bytes Size of Resource Fork: 0 bytes Rows with Type Code b'DISC' and Creator Code b'ARTD': Row index: 11828 File Name: Discus—Disc Lable File Type: DISC Creator: ARTD Comments: Discus Category: nan Extension: nan Dup: Data by Ilan Szekely, Jerusalem: nan ------------------------------
The database of Type/Creator codes identified the file as being created by the Discus software. A little search and I remembered the file in question was created by Discus RE which was included with Roxio Toast, a CD/DVD buring software popular on the Macintosh for many years. Discus RE was labeling software bundled with Toast for a few versions, lastly Toast version 7.
I happen to have Toast 6 on my older PowerMac G5 machine which included Discus RE 2.74. I made a few samples to compare.
You may have noticed both my file and this sample have a slightly different header, my samples have “CDCD007” while the header sent to me has “CDCD2007”. A slight difference I am not sure of the meaning. I need to see more samples. Since this was a sample from Discus version 2, I tracked down samples from version 3 and 4.
Version 3 seems to have the same structure. Version 4 is a little different and also has an extension this time. The first two bytes are the same, but has 0008 and is missing the CANV, replaced by PREV.
I learned the Discus software was created by a software company called Magic Mouse Productions. Discus was written by Edward de Jong, the founder of Magic Mouse Productions, who has also created many other software titles. Discus sold millions of copies, many of which were bundled, but also full versions which unlocked many other label templates and a lot more artwork. The Discus software also included a large selection of artwork which could be used in the label design. Looking at a sample from the full version, I was hoping to see the CDCD2007, but found them to be similar to the other samples.
I actually reached out to Edward de Jong and asked him about the file format. His response,
The Discus file format is fairly straightforward
The first four bytes are the signature of a Discus file
The Discus software was built for the PowerPC chip for the Macintosh, but also for Windows. The last couple of updates to Discus version 4 added Intel chip support, but then no new versions where created. Edward explained….
I still use Discus myself, but on the Macintosh it stops running after OSX 10.14 because Apple cruelly discontinued their emulator for older operating systems and the Intel instruction set.
After Toast version 7, Roxio used a different labeling software bundled with their burning software. This and many others still need some research and documentation. For now, a signature for Discus will help in weeding out these labels some might find un-needed, but other may find invaluable.
Take a look at some samples and my signature proposal and let me know what you think.
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.
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.
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.
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.
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?
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.
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.
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.
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 ceasedoperations. 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.
With all the different file formats that are found in everyday computing, most formats which find their way to my archive have historical value. We know we can’t keep everything and have to assign value to all we decide to keep in for the long term. Some files have sensitive data and we have to follow guidelines for their proper handling. Identification of files helps us know what type of data might be kept inside the format, so often I need to also identify formats we don’t plan on keeping.
I was recently looking through a large digital collection and a report on the files which did not identify in the initial scan. A few popped out to me because of their extension, TAX. Tax records are one thing we need to identify so we can properly handle them, but not likely keep in our repository.
These tax files come from the popular US based TurboTax software. The software gets a new version for every year as tax laws are constantly changing. The software has also been around since 1984, so there are many versions to be aware of. Add to the fact there are personal and business versions along with DOS, Windows, and Macintosh versions, identification might get complicated. None of which are documented in the PRONOM registry. Wikidata is aware of a couple of the extensions, but does not have any signatures to help in identification.
Luckily, this collection of files I was processing had a number of years worth of records. Using them and a few others I was able to put together a decent timeline of formats used, at least from the early 1990’s on. The format seemed to settle on the .TAX extension around the 1994 Windows version. Before this, a group of files in DOS together stored the data. Let’s look at a sample of the 1994 file from Windows.
The nice easy to read header is gone, but some other patterns start to appear. It seems most of the files from these early versions also used a code near the beginning that may help. “S1995US1040PER”, is similar to the “S1994US1040” in the 1994 file. One could assume the “1040” is the tax form most Americans are used to, along with “US” preceding the number. Then at the end of the string we see “PER”. This may refer to different versions of the Tax software, a Personal for the individual, and a possibly other versions for business as well. I believe TurboTax also had versions for Canadians as well, so there may be many variations on this string. This could get complex. Let’s jump ahead to a 1999 file.
The same string is visible, but if course with the year “1999”. We can also see a pattern with the first 4 bytes, “c0 45 01 5f” which seem to be consistent with the 1995 file. The file I have for 1998 is consistent as well. Jumping to the new millennium, we see a change.
Two changes we see with this file. One, the ASCII string is different. S2000US1120, 1120 being the U.S. Corporation Income Tax Return. So this version of the software was different. The other change is the first 4 bytes. They changed to “c0 45 01 64”, with the last byte changing from 5F to 64. Jumping to 2003, we see the same values.
Back to a 1040 form, but with the same header as the 2000 file. I am removing some lines, just to be safe and not exposing any personal data. In 2004 we see a major change in the format.
% hexdump -C TurboTax2004.tax | head 00000000 54 54 46 4e 01 01 6f 68 dc 62 00 00 00 00 4b 01 |TTFN..oh.b....K.|
Again, removing some lines to ensure safety. This header is very different and their is no human readable ASCII in the file, which means it is binary and probably encoded. This header is new, TTFN is what I assume references TurboTax format? file? or possibly, “Turbo Tax Financial Network“?
This header is then used for the next few years ending in 2013, but before we get there, the extension makes a change as well. In 2008, instead of the simple .TAX extension, the software begins to save the tax file with the extension .TAX2008. I don’t have a 2008 document, but I do have a sample 2009 document.
2014 is where I get a little confused. I have one file which uses the TTFN header and another which uses what becomes the standard going forward. But definitely in 2015, the format starts using the ZIP container as a structure for the format. Here is a sample from 2015
The files all seem to have a manifest.xml and a unique identifier. 7-Zip also mentions a header issue with the ZIP files. Something maybe done on purpose? Now comes the odd part, the manifest.xml file does not render as an XML file, it is binary.
% hexdump -C TurboTax2017/manifest.xml | head 00000000 a1 b1 fe fb 37 18 dd 9c 08 2d 9c 86 23 00 10 fa |....7....-..#...| 00000010 12 60 92 bb dc 92 a5 df 1a 24 16 4e a9 28 89 80 |.`.......$.N.(..| 00000020 64 33 66 55 c5 93 f0 68 44 d0 7c f9 56 86 42 2c |d3fU...hD.|.V.B,| 00000030 80 ba 8a 95 2a 82 6d 32 75 84 b1 f1 e2 18 93 5c |....*.m2u......\| 00000040 82 4d 18 f9 ed 23 4f dc d6 b5 7f f2 20 1e 30 59 |.M...#O..... .0Y| 00000050 d5 7f 47 7d aa f5 8d bd 8b 10 20 ec 8a c7 43 df |..G}...... ...C.| 00000060 52 90 a9 70 4d 68 b4 76 fa c8 37 85 f5 56 25 82 |R..pMh.v..7..V%.| 00000070 ea 16 06 54 b0 b4 bc 43 16 fb 70 7b 7a 79 a5 8b |...T...C..p{zy..| 00000080 3c 79 7d ef ac 32 fc 35 ce 0f fa a2 6f e7 c3 a4 |<y}..2.5....o...| 00000090 92 a1 a4 c8 83 dd 9f 32 f4 ea d3 1a eb 89 15 a3 |.......2........|
Of the samples I have which have a manifest.xml, they all begin with “a1 b1 fe fb”. Which apparently is the header for an AES CBC encrypted file. A clever person was able to decrypt the file to reveal the actual XML.
TurboTax isn’t sold on physical disk anymore, but you can download the current tax year version from their website. I am not a user of their product so I am not sure if the latest version still saves files in the same way. If you do use it currently, I would love to know if it is still the same.
So to recap, the headers are:
1994 “TurboTax Format=WIN Version=13
1995-99 “C045015F”
2000-03 “C0450164”
2004-13 “TTFN”
2014-current “ZIP Container”
This should be enough to create five new signatures for identification. Extensions will be a problem since they change very year, but we can add them to the list. With these signatures we can now identify all the tax files we have and set them aside if not needed.
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.
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.
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.
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.
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.
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”.
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.
The main subject of these posts is about Obsolete software and file formats. I prefer to focus on older software titles and collect them when I can. I have also found older Macintosh software to be particularly interesting as many of the qualities of early Macintosh use is lost today. In researching a very early Macintosh title, I came across an article from 1999 written by the Washington Post, the article, now 26 years old, was already commenting about “antique” software which was less than 20 years old at the time. Is there a term for even more antique? The title of the article? “Old Enthusiasts Are Scouring the Web to Find ‘Antique’ Software”. I feel this hasn’t changed, I still scour the web to find old software, and if the enthusiasts were “old” 26 years ago, then I am ancient.
The files created by ThinkTank are plain text with the ASCII “HEAD”. There was also a DOS version of ThinkTank, but the files used were .DB and .SAV, although the templates in the .TXT format did use this same format.
Turns out this was a special format they called “dot-head“, aptly named for the head of the file. It was used as an interchange format to move outlines between ThinkTank, another program called Ready!, and the later product MORE.
MORE was developed to be multiple tools in one. Meant to “Unite idea processing technology with the desktop publishing revolution“. MORE replaced ThinkTank in 1986 and promised more flexibility by creating charts and presentations quickly from your outline. MORE used the same dot-head format initially, also the ASCII could be in lowercase.
In 1987 Living Videotext was purchased by Symantec. Shortly after Symantec released MORE II and a rebranded DOS application called GrandView based on ThinkTank.
Let’s take a look at GrandView, it was built from the DOS version of ThinkTank and compatible with the same formats. It had great reviews at the time and provided the first outliner for Symantec. It was written by the developer, John Friend, who created PC Outline which was often bundled with WordStar.
GrandView could import and export into any of the other products.
GrandView was also compatible with the Macintosh counterpart, MORE.
Symantec then released a new version of the MORE software for the Macintosh in 1988, adding new presentation features. MORE II went away from the dot-head format and used a new proprietary format.
The MORE 3 format got a new header but appears similar in structure to the previous version. And the new companion tool MORE Graph had yet another format.
Luckily these early Macintosh based formats didn’t use a resource fork, making them fully compatible with their PC counterpart.
One of the coolest parts of this long list of outline software, is that years later, after Symantec discontinued the product, the original creator, Dave Winer, petitioned Symantec to allow him to release the antique software free and clear to the public. How cool is that? I would really like to see this happen more as other software titles die and get swept under the rug leaving the community to try and find copies, preserve them and make sense of the formats. Not only were the early versions made available, a tool was built to migrate the MORE format to more open XML, allowing the ideas trapped in these ancient formats to be re-imagined.
MORE 3.1 was the final version of the software to be released by Symantec. The files produced by MORE 3.1 have an identical header to the standard 3.0 version. Probably only need one signature for the two versions.
If you would like to try out the MORE software, download this disk image, and drag onto the Macintosh emulator below. The image will automatically mount and you should be able to take MORE 3.1 for a spin!
Outlining software still has a good place in idea generation and presentation. OmniOutliner can probably trace its roots to these “Antique” titles! Stay tuned for some PRONOM signatures to go along with these many format examples. For now you can gather some of the samples from my Github page.
For the sake of consistency, I will call this protection a sleeve, but may also be referred to as an envelope, jacket, or a pouch. Pouch being used by the folks down-under. The sleeve was mainly used for storage of the disk, but was also a great marketing tool and on the backside a reminder of the proper care of the disk. Floppy disk manufacturers and software companies would use the sleeve to print their logo and other important information about the disk, some opting for blank or generic graphics. Today we will look at some of the creative and not so creative uses.
