ACE

Posted on by Thor Leave a comment

Without divulging any youthful indiscretions, I recently was going back through some of my personal archives and came across a disc I burned around 2002 with some music stored on it. Normally I would find MP3 files, but in this case the file had a ACE extension. I remembered the format as an alternative to the common RAR or ZIP format often used to compress content for transporting (sharing) around the internet. I did what I normally do when something is compressed and reached for 7zip. But to my surprise, it threw an error.

% 7z l sample.ace 

Scanning the drive for archives:
1 file, 12501419 bytes (12 MiB)    

Listing archive: sample.ace


ERROR: sample.ace : Can not open the file as archive

7zip usually can handle most common archives but a part of me remembered there was two versions of WinACE back in the day. Version 1 which was a free version and Version 2 which was for paid users of WinACE. How do I know which version I have is the question I frequently find myself asking. First was to check the PRONOM registry.

% sf sample.ace 
---
siegfried   : 1.11.2
scandate    : 2025-09-11T09:01:25-06:00
signature   : default.sig
created     : 2025-03-01T15:28:08+11:00
identifiers : 
  - name    : 'pronom'
    details : 'DROID_SignatureFile_V120.xml; container-signature-20240715.xml'
---
filename : 'sample.ace'
filesize : 12501419
modified : 2025-09-11T09:04:36-06:00
errors   : 
matches  :
  - ns      : 'pronom'
    id      : 'UNKNOWN'
    format  : 
    version : 
    mime    : 
    class   : 
    basis   : 
    warning : 'no match'

Nope, this format is not known to PRONOM. Lets try another tool.

% file sample.ace 
sample.ace: ACE archive data version 20, from Win/32, version 20 to extract, solid

Ok, so the file tool knows it is a version 2 ACE file and requires version 2 to extract. Good info from a file identification tool. Now lets see what we can find to extract this file on MacOS. The website Winace.com is long gone as this compression tool lost popularity and the final release was over 14 years ago. Looking at the website in the WaybackMachine we can see some downloads available. One being UnACE for Mac OS X, which upon further review, only works for the older PowerPC Mac’s. There is an open source version of unace for Linux, but it only supports version 1, the free version of the format.

Below is a screenshot of the DOS version of the ACE software. Created by Marcel Lemke.

It might be good to mention that WinRAR used to support the ACE format, but with WinACE support ending years ago and with some new vulnerabilities and folks using it for malware, support was dropped in 2019.

Luckily, I still have my PowerMac G5 lying around waiting for this very situation. After a quick install, unace was able to unarchive my music and I was able to listen to some of my favorite songs from 23 years ago. I still wanted to find a modern solution and later discovered there is a python project which can read and extract bother versions. Acefile is a pure python, no-dependencies implementation of the UnACE format. I had a little issue installing on an older Catalina laptop, but worked well on later MacOS versions. Acefile has a few features that are helpful in not only extracting, but testing and dumping the headers of an ACE file. I did install WinACE in a Windows XP Virtual Machine to make a few samples, here is one of them.

% acefile-unace --test sample.ace 
success  test.tif
total 1 tested, 1 ok, 0 failed

The test feature works well to ensure the file is complete and can be extracted, but doesn’t give me much to go on for knowing the version. Lets try dumping the header. 

% acefile-unace --header sample.ace 
volume
    filename    sample.ace
    filesize    12501419
    headers     MAIN:1 FILE:1 RECOVERY:0 others:0
header
    hdr_crc     0x4900
    hdr_size    44
    hdr_type    0x00        MAIN
    hdr_flags   0x8100      V20FORMAT|SOLID
    magic       b'**ACE**'
    eversion    20          2.0
    cversion    20          2.0
    host        0x02        Win32
    volume      0
    datetime    0x5b2aae37  2025-09-10 21:49:46
    reserved1   c8 51 62 e3 5b 80 00 00
    advert      b''
    comment     b''
    reserved2   b'\x00e\x9c\xb1\xd8\x00\x03\n\x00\x00@\x08\x00test.'
header
    hdr_crc     0x3626
    hdr_size    39
    hdr_type    0x01        FILE32
    hdr_flags   0x8001      ADDSIZE|SOLID
    packsize    12501328
    origsize    25264236
    datetime    0x5b2aadcd  2025-09-10 21:46:26
    attribs     0x00000080  NORMAL
    crc32       0x9290955a
    comptype    0x02        blocked
    compqual    0x03        normal
    params      0x000a
    reserved1   0x4000
    filename    b'test.tif'
    comment     b''
    ntsecurity  b''
    reserved2   b''

This is very helpful. We can see the output shows the magic bytes, but also the e(xtraction)version and c(creating)version. We can also find this information in the open source unace technical documentation. 

       2      HEAD_CRC      CRC16 over block up from HEAD_TYPE
       2      HEAD_SIZE     size of the block from HEAD_TYPE
                              up to the last byte of this block

       1      HEAD_TYPE     archive header type is 0
       2      HEAD_FLAGS    contains most important information about the
                            archive

                               bit  discription

                                0   0  (no ADDSIZE field)
                                1   presence of a main comment

                                9   SFX-archive
                                10  dictionary size limited to 256K
                                    (because of a junior SFX)
                                11  archive consists of multiple volumes
                                12  main header contains AV-string
                                13  recovery record present
                                14  archive is locked
                                15  archive is solid

       7      ACESIGN       fixed string: '**ACE**' serves to find the
                              archive header

       1      VER_EXTRACT   version needed to extract archive
       1      VER_CREATED   version used to create the archive

I think we have enough to go on to create a signature, we just need to see what the 1 byte versions number look like in an actual file.

% hexdump -C sample.ace | head
00000000  00 49 2c 00 00 00 81 2a  2a 41 43 45 2a 2a 14 14  |.I,....**ACE**..|
00000010  02 00 37 ae 2a 5b c8 51  62 e3 5b 80 00 00 00 65  |..7.*[.Qb.[....e|
00000020  9c b1 d8 00 03 0a 00 00  40 08 00 74 65 73 74 2e  |........@..test.|
00000030  26 36 27 00 01 01 80 50  c1 be 00 6c 80 81 01 cd  |&6'....P...l....|
00000040  ad 2a 5b 80 00 00 00 5a  95 90 92 02 03 0a 00 00  |.*[....Z........|
00000050  40 08 00 74 65 73 74 2e  74 69 66 28 25 a4 89 04  |@..test.tif(%...|
00000060  fa 43 b1 05 49 0c a3 76  8e 16 a9 2c 92 44 34 8c  |.C..I..v...,.D4.|
00000070  2c 12 e7 28 67 68 49 69  a7 92 4a 10 07 da 10 16  |,..(ghIi..J.....|
00000080  9c 16 4a 10 07 2b 9c ae  30 a9 50 c4 0a 69 51 a6  |..J..+..0.P..iQ.|
00000090  c9 64 a7 24 09 93 3d 81  26 31 a9 c2 68 32 c1 33  |.d.$..=.&1..h2.3|

As you can see above, we have our magic bytes **ACE** starting at the seventh byte and taking up seven bytes. Then two bytes after it both with the hex value 14. If we convert that hex value to decimal we get “20”. Let’s look at another:

% hexdump -C sample2.ace | head
00000000  61 67 31 00 00 00 90 2a  2a 41 43 45 2a 2a 0a 0c  |ag1....**ACE**..|
00000010  02 00 50 7c 31 26 d7 2b  c0 48 af 83 ce d9 16 2a  |..P|1&.+.H.....*|
00000020  55 4e 52 45 47 49 53 54  45 52 45 44 20 56 45 52  |UNREGISTERED VER|
00000030  53 49 4f 4e 2a 34 5f 24  00 01 01 80 00 00 00 00  |SION*4_$........|
00000040  35 00 00 00 3c 7c 31 26  10 00 00 00 ff ff ff ff  |5...<|1&........|
00000050  01 05 0a 00 2a 55 05 00  61 75 64 69 6f 45 72 23  |....*U..audioEr#|
00000060  00 01 01 80 00 00 00 00  35 00 00 00 3c 7c 31 26  |........5...<|1&|
00000070  10 00 00 00 ff ff ff ff  01 05 0a 00 2a 55 04 00  |............*U..|
00000080  42 49 54 53 98 14 24 00  01 01 80 00 00 00 00 35  |BITS..$........5|
00000090  00 00 00 3c 7c 31 26 10  00 00 00 ff ff ff ff 01  |...<|1&.........|

Hmm, now we have two different values. “0A” converts to decimal “10” and “0C” converts to decimal “12”. So we can infer this ACE file was created in version 1.2 and requires at least version 1.0 to extract. Let’s try another:

% hexdump -C sample3.ace | head   
00000000  c0 3f 2c 00 00 00 81 2a  2a 41 43 45 2a 2a 0a 14  |.?,....**ACE**..|
00000010  02 00 dc ad 2a 5b 23 52  89 e0 5b 80 00 00 00 65  |....*[#R..[....e|
00000020  9c b1 d8 00 03 0a 00 00  40 08 00 74 65 73 74 2e  |........@..test.|
00000030  92 f3 27 00 01 01 80 54  c3 be 00 6c 80 81 01 cd  |..'....T...l....|
00000040  ad 2a 5b 80 00 00 00 5a  95 90 92 01 03 0a 00 00  |.*[....Z........|
00000050  40 08 00 74 65 73 74 2e  74 69 66 28 25 a4 89 04  |@..test.tif(%...|
00000060  fa 43 b1 05 49 0c a3 76  8e 16 a9 2c 92 44 34 8c  |.C..I..v...,.D4.|
00000070  2c 12 e7 28 67 68 49 69  a7 92 4a 10 07 da 10 16  |,..(ghIi..J.....|
00000080  9c 16 4a 10 07 2b 9c ae  30 a9 50 c4 0a 69 51 a6  |..J..+..0.P..iQ.|
00000090  c9 64 a7 24 09 93 3d 81  26 31 a9 c2 68 32 c1 33  |.d.$..=.&1..h2.3|

Again we have “0A” which converts to decimal “10” and hex 14, which converts to decimal “20”. So made with version 2.0 of the software, but made compatible with version 1.0 for extraction. One more:

% hexdump -C sample4.ace | head
00000000  8b d6 31 00 00 00 90 2a  2a 41 43 45 2a 2a 0b 0b  |..1....**ACE**..|
00000010  02 00 cd b4 3e 26 4a e3  a1 80 32 4b c1 d9 16 2a  |....>&J...2K...*|
00000020  55 4e 52 45 47 49 53 54  45 52 45 44 20 56 45 52  |UNREGISTERED VER|
00000030  53 49 4f 4e 2a aa 08 24  00 01 01 00 00 00 00 00  |SION*..$........|
00000040  00 00 00 00 83 b2 3e 26  10 00 00 00 ff ff ff ff  |......>&........|
00000050  01 05 0a 00 2a 55 05 00  4d 75 73 69 63 77 73 27  |....*U..Musicws'|
00000060  00 01 01 00 00 00 00 00  00 00 00 00 83 b2 3e 26  |..............>&|
00000070  10 00 00 00 ff ff ff ff  01 05 0a 00 2a 55 08 00  |............*U..|
00000080  52 65 73 6f 75 72 63 65  93 75 25 00 01 01 00 00  |Resource.u%.....|
00000090  00 00 00 00 00 00 00 83  b2 3e 26 10 00 00 00 ff  |.........>&.....|

Both extraction and creation version are hex “0B” which converts to decimal “11”. I would have assumed any version 1.0 version could extract anything created with later 1.x versions, but I guess that might not be true. I am not clear on all the versions released, so I am not sure how many versions I should include in a signature. I did look through some of the captured pages on the WayBackMachine and feel the last 1.x version was version 1.32.

When building these signatures, it should be easy to create two signatures based on their extraction version. But should the creation version be a factor? Version 1.0 could look like this:

2A2A4143452A2A(0A|0B|0C|0D)(0A|0B|0C|0D|14)

This accounts for the versions 1.0 through 1.3 for extract version and 1.0 through 2.0 for creation version. Version 2.0 doesn’t seem to indicate minor versions with all 2.0 versions using decimal 14. So a signature could be:

2A2A4143452A2A1414

Both would start from offset 7 from the beginning of the file. Is there a better solution?

I will warn you, there are a couple of ACE formats out there which you may come across. One being an image/texture format for Microsoft Train Simulator. That might be for another day. There is another use of the ACE archive which is worth discussing. The Comic Book Archive file with the extension CBA will use the ACE archive for storing a series of images used in some Comic Book Readers. They are indeed ACE archive files, only having the different extension and a specific purpose. Maybe adding the CBA extension to the signature would be sufficient?

I am sure there are some other properties, seen above, of the ACE format we could discuss, encryption, the differences between Solid and SFX, and dictionary headers, but I think for now, identification of the format and the main version difference is sufficient. For now, check out my Github page for my signature proposal and a few samples I made.

Scheduling EXport

Posted on by Thor Leave a comment

During a recent review of some help files for some older Final Draft software I came across this Q&A.

Needless to say, I was intrigued, but let me give you a pro tip. Googling MovieMagic and “SEX” does not bring back results related to file formats. Also, probably best not to search at work.

Movie Magic refers to software developed by Write Brothers/Screenplay. The main software, Screenwriter is a word processor built specifically for writing screen plays for TV, Movies, theater, etc. The software was first developed in 1983 and quickly replaced typewriters as the favorite for writing the very specific formatting required by screenplays.

Screenwriter version 6 uses the extension MMSW and DEF for templates. Let’s have a look at one under the hood.

hexdump -C Screenwriterv6-01.mmsw | head
00000000  53 63 72 65 65 6e 77 72  69 74 65 72 57 69 6e 56  |ScreenwriterWinV|
00000010  65 72 2e 20 36 2e 30 30  20 00 00 00 00 00 00 00  |er. 6.00 .......|
00000020  00 00 00 0c 4e 4f 4e 41  4d 45 32 2e 4d 4d 53 57  |....NONAME2.MMSW|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000050  00 00 00 00 00 00 00 00  0f 0a 0a 00 00 00 00 0a  |................|
00000060  01 0c 00 00 0f 0a 0a 01  00 00 01 0a 01 0c 00 00  |................|
00000070  19 18 00 00 00 00 04 0a  01 0c 00 00 25 0a 0a 01  |............%...|
00000080  00 00 03 0a 01 0c 00 00  0f 0a 0a 01 00 00 06 0a  |................|
00000090  01 0c 00 00 1e 23 00 00  00 00 05 0a 01 0c 00 00  |.....#..........|

The header is easy to interpret, Version 6 is the latest version of the software. The rest of the file is non-human readable binary so not much to look at. The screenplay website has a chart for figuring out compatibility for all the versions and extensions.

The other major version used the SCW extension. 

hexdump -C ScreenWriter4-s01.scw | head
00000000  53 63 72 65 65 6e 77 72  69 74 65 72 77 69 6e 76  |Screenwriterwinv|
00000010  65 72 2e 20 34 2e 31 31  61 00 00 00 00 00 00 00  |er. 4.11a.......|
00000020  00 00 00 11 53 63 72 65  65 6e 57 72 69 74 65 72  |....ScreenWriter|
00000030  34 2d 73 30 31 00 00 00  00 00 00 00 00 00 00 00  |4-s01...........|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  0f 0a 0a 00 00 00 00 0a  |................|
00000060  00 0c 00 00 0f 0a 0a 01  00 00 01 0a 00 0c 00 00  |................|
00000070  19 18 00 00 00 00 04 0a  00 0c 00 00 25 0a 0a 01  |............%...|
00000080  00 00 03 0a 00 0c 00 00  0f 0a 0a 01 00 00 06 0a  |................|
00000090  00 0c 00 00 1e 23 00 00  00 00 05 0a 00 0c 00 00  |.....#..........|

hexdump -C Screenwriterv6-01.scw | head
00000000  53 63 72 65 65 6e 77 72  69 74 65 72 57 69 6e 56  |ScreenwriterWinV|
00000010  65 72 2e 20 34 2e 39 30  00 00 00 00 00 00 00 00  |er. 4.90........|
00000020  00 00 00 0c 4e 4f 4e 41  4d 45 32 2e 4d 4d 53 57  |....NONAME2.MMSW|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Files from the earlier version appear to be structured the same way. Although files generated on a Macintosh still seem to retain the “win” in the header, but with a capital “Win” and “Ver”. Looking at the older ScriptThing format it is similar.

hexdump -C NONAME1.SCR | head
00000000  53 63 72 69 70 74 54 68  69 6e 67 20 56 65 72 2e  |ScriptThing Ver.|
00000010  20 32 2e 31 39 00 00 00  00 00 07 4e 4f 4e 41 4d  | 2.19......NONAM|
00000020  45 31 2e 53 43 57 00 00  00 00 00 00 00 00 00 00  |E1.SCW..........|
00000030  00 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 07 00 01  |................|
00000050  00 0f 49 0b 00 00 0f 49  0b 01 01 19 3b 01 00 04  |..I....I....;...|
00000060  25 49 0b 01 03 0f 49 0b  01 06 1e 30 01 00 05 0f  |%I....I....0....|
00000070  49 0b 01 02 0f 49 0b 01  0a 0f 49 0b 01 0b 0f 49  |I....I....I....I|
00000080  0b 04 14 00 00 02 02 02  02 02 00 00 01 02 00 37  |...............7|
00000090  0b 28 43 4f 4e 54 49 4e  55 45 44 29 00 0a 43 4f  |.(CONTINUED)..CO|

hexdump -C MULTIMEDIA DEMO.SCW | head
00000000  53 63 72 69 70 74 54 68  69 6e 67 20 57 69 6e 56  |ScriptThing WinV|
00000010  65 72 2e 20 31 2e 32 35  64 00 08 44 49 43 54 46  |er. 1.25d..DICTF|
00000020  49 4c 45 1a 4d 75 6c 74  69 6d 65 64 69 61 20 44  |ILE.Multimedia D|
00000030  65 6d 6f 20 53 63 72 69  70 74 2e 53 43 52 00 00  |emo Script.SCR..|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  0a 0e 0a 00 00 00 00 0a  |................|
00000060  00 0c 00 00 0a 0d 0a 01  00 00 01 0a 00 0c 00 05  |................|
00000070  14 1b 00 00 00 00 04 0a  00 0c 00 00 20 0d 0a 01  |............ ...|
00000080  00 00 03 0a 00 0c 00 00  0c 17 0a 01 00 00 06 0a  |................|
00000090  00 0c 00 01 19 26 00 00  00 00 05 0a 00 0c 00 00  |.....&..........|

Screenwriting software is very specialized, the formatting is important as well as keeping track of characters, locations, props, etc. An important part of filming a movie based on a script is to schedule the different scenes and which characters are needed for each scene. This scheduling can be generated by generating a Scheduling EXport. Not sure who decided on this extension, but there it is. 

hexdump -C Screenwriterv6-01.sex | head
00000000  53 53 49 2a 00 23 00 00  00 e2 00 00 00 00 43 61  |SSI*.#........Ca|
00000010  73 74 20 4d 65 6d 62 65  72 73 00 45 78 74 72 61  |st Members.Extra|
00000020  73 00 53 74 75 6e 74 73  00 56 65 68 69 63 6c 65  |s.Stunts.Vehicle|
00000030  73 00 50 72 6f 70 73 00  53 70 65 63 69 61 6c 20  |s.Props.Special |
00000040  45 66 66 65 63 74 73 00  43 6f 73 74 75 6d 65 73  |Effects.Costumes|
00000050  00 4d 61 6b 65 75 70 00  4c 69 76 65 73 74 6f 63  |.Makeup.Livestoc|
00000060  6b 00 41 6e 69 6d 61 6c  20 48 61 6e 64 6c 65 72  |k.Animal Handler|
00000070  00 4d 75 73 69 63 00 53  6f 75 6e 64 00 53 65 74  |.Music.Sound.Set|
00000080  20 44 72 65 73 73 69 6e  67 00 47 72 65 65 6e 65  | Dressing.Greene|
00000090  72 79 00 53 70 65 63 69  61 6c 20 45 71 75 69 70  |ry.Special Equip|

Scheduling Export files begin with “SSI“, which I assume refers to Screenplay Systems, Inc. They begin with listing all the different things which need scheduling in plain text. In Screenwriter 6 there are a couple of export types with the same extension. One called Gorilla Scheduling and another called CompanyMOVE ShowPlanner, but both are identical to the Movie Magic file, so I am not quite sure their purpose. Maybe there would be more to discern from a whole script instead of the simple samples I made for this purpose.

This was a fun format to research, although I had to be careful of the terms I used! You can check out my proposed signatures and samples on my GitHub.

Beef & Babe’s

Posted on by Thor 1 Comment

The 1990’s was a an exciting time for Desktop Publishing. I got my first taste of design in the early 90’s with Aldus PageMaker. QuarkXPress was king in commercial publishing world. For the most part designers and commercial printers used Macintosh computers which QuarkXpress catered to. For those who could not afford the high prices, or used a PC, there was a few options. Microsoft Publisher, TimeWorks Publish It!, and Express Publisher were a few. There was many debates during that time on which software was the best.

I have submitted signatures to PRONOM for many of these:

Express Publisher was proving elusive for finding software and sample files. Express Publisher was developed by Power Up who had been developing a DOS version since the late 1980’s. At one point Power Up decided to sue QuarkXPress for the use of the name XPress. In 1991 Power Up sold all their assets to Spinnaker around the time they released the first Windows version of Express Publisher.

When I first took a look at some samples from the Windows version 1.0 of Express Publisher, the magic header looked familiar.

If it looks familiar to you it is similar to the famous, well nerd famous, JAVA Class file format.

The story goes that James Gosling needed a magic number for his new class format and was in a place they called Cafe Dead when he realized CAFE was a hex value, he soon used CAFEBABE and CAFED00D for his new formats. JAVA was released by Gosling in 1995 for SUN Microsystems.

File Format magic numbers are often used when designing a file to be used with software. Often times it is meant to be a sequence of hex values or a string indicating the file supported by certain software, this is more accurate than the simple extension at the end of most files. They are not required to be there, in fact there are a few formats which are difficult to identify as they don’t use this type of magic number in the header. To learn more read Ross Spencer’s post on magic numbers for digital preservation.

CAFED00Ds and CAFEBABEs

At first I thought it was some sort of homage to the JAVA Class format until I realized the Express Publisher file format was released 3 years earlier. Just a coincidence? I am sure whomever developed this format probably has an interesting story behind it.

These formats are not in PRONOM so lets take a look at what is needed.

The document format for Express Publisher version 1 for Windows 3 uses the EWD extension, as well as EWT for templates. Magic numbers work best for a signature when they are at least 4 bytes long, this gives enough to have little chance of conflicting with another file format. So our PRONOM signature byte sequence would look like this:

  <ByteSequence Reference="BOFoffset">
    <SubSequence MinFragLength="0" Position="1" SubSeqMaxOffset="0" SubSeqMinOffset="0">
      <Sequence>CAFEBEEF</Sequence>
      <DefaultShift>5</DefaultShift>
      <Shift Byte="CA">4</Shift>
      <Shift Byte="FE">3</Shift>
      <Shift Byte="BE">2</Shift>
      <Shift Byte="EF">1</Shift>
    </SubSequence>
  </ByteSequence>

In looking at the earlier DOS versions of Express Publisher they used the extension EPD for a document and EPT for templates. I only have a few samples of version 2 and version 3, but they have different headers.

Version 2 & 3 has consistent bytes starting at offset 4, version 2 using the string PAGES, and version 3 the string EP300. I will have to dig a little more to see if I can find some samples of version 1 to see how they compare and then should be able to submit a PRONOM signature for them.

For the time being, adding “CAFEBEEF” to PRONOM will be a good addition. I wonder if there are any other “CAFE” formats out there, if you know of any, let me know!

UPDATE – There is another format, AnFX Movie, which uses the magic header “CAFEBEEF”. More research is needed to distinguish the two formats.