pirate – Obsolete Thor

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.

Ok, confession time.

There is only a couple moments in my tech history which had a profound effect on me, enough to sear the memory of the moment into my brain. When I was in college around 1997 I had a decent CD collection and I had learned how to copy those AIFF files off the disc and use them on my trusty PowerCenter Pro. These files were huge, at the time. I knew a regular size song would take up around 50MB on my hard drive. This was a lot of space back in 1997, but I could then mix them with other songs, something I did sometimes for friends I had on the dance team. I didn’t have a CD burner at the time so I would transfer them to cassette tape. I know, but remember this was the 1990’s when everything was changing and expensive.

One night I was exploring the world wide web and I happened across someone sharing a few songs. I assumed they were just clips as they were only 5MB in size, a tenth the size they should be. I downloaded the song, which of course still took a few minutes back in those days. When I played the song, I was dumbfounded, it was the whole song. I was completely confused. How could they take a 4+ minute song and compress it down to under 5MB? This was amazing.

I started grabbing every song I could find. Before long I had quite the collection. And before you judge me for downloading music from the web, this was a couple years before the advertisement we all remember reminding us that we wouldn’t steal a car so why would we steal music.

The files I found on the internet were MP3 files, the same we are familiar with today. Back then creating MP3 files wasn’t easy. MP3 was actually a licensed product so you had to get a little creative in order to make them. On my Macintosh PowerCenter Pro, there were even fewer options. I was already familiar with the sound editing application from Macromedia called SoundEdit 16, it was the tool I used to do all my editing. I found there was a plugin you could add which allowed export to a format called Shockwave Audio. This was meant for use in Macromedia’s Director application to add sound to the growing Flash animation industry. Once I got the plugin and installed I couldn’t stop making files and I made them as fast as I could. For a whole album this could take over an hour on my hardware, but it was worth it. Before long I had a large collection of popular music ready to play at a moments notice. My player of choice was MacAMP, a sibling of the popular WinAMP. I even borrowed some equipment from a friend who DJ’d on the weekends and DJ’d a college dance. I lugged my whole PowerCenter Pro tower and 17in trinitron monitor over to the school. It was so much fun and folks didn’t understand when they asked to see my CD collection.

Enough about transgressions from my youth, lets talk about the Shockwave Audio format.

To create a SWA file you would first need SoundEdit 16 Version 2. Then the plugins to enable export. This would only run on PowerPC computers running Macintosh OS or Classic in Mac OS X. For this post I pulled out my trusty PowerBook G4 Titanium running MacOS 9 and MacOS X 10.2. Installed SoundEdit 16 and the plugins in the Xtras folder and we are good to go.

Before you export you need to set what bitrate you prefer for the final file, giving you the option of 8KBits up to 160KBits per second. The higher the bitrate the longer it took and made larger files.

SoundEdit 16 had a native audio format and also frequently used the SoundDesigner II format to save the uncompressed files. On a Macintosh you had to be careful as these formats did not travel well to other systems on account of the resource forks associated with the data.

Because these SWA files were meant to be used in websites and other non-Mac systems, they did not have a resource fork, but had the Creator/Type codes, SwaT/SHCK. An extension wasn’t necessary for use on your Macintosh, but it was best to use .swa.

Here is what the data looks like for a SWA file.

Even though the SWA format uses MPEG compression, this is not a typical header you might see in a MP3. There was no ID3 tags at the time so not much in terms of metadata.

General
Complete name                            : tone2.swa
Format                                   : MPEG Audio
File size                                : 80.7 KiB
Duration                                 : 5 s 166 ms
Overall bit rate mode                    : Constant
Overall bit rate                         : 128 kb/s
FileExtension_Invalid                    : m1a mpa mpa1 mp1 m2a mpa2 mp2 mp3

Audio
Format                                   : MPEG Audio
Format version                           : Version 1
Format profile                           : Layer 3
Format settings                          : Joint stereo / MS Stereo
Duration                                 : 5 s 172 ms
Bit rate mode                            : Constant
Bit rate                                 : 128 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 kHz
Frame rate                               : 38.281 FPS (1152 SPF)
Compression mode                         : Lossy
Stream size                              : 80.7 KiB (100%)

ffprobe -i tone2.swa 
[mp3 @ 0x155704a60] Format mp3 detected only with low score of 25, misdetection possible!
[mp3 @ 0x155704a60] Skipping 324 bytes of junk at 0.
[mp3 @ 0x155704a60] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from 'tone2.swa':
  Duration: 00:00:05.15, start: 0.000000, bitrate: 128 kb/s
  Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 128 kb/s

There are a few consistencies among all my files. They all begin with the hex values “00000140000000030000” for the first 10 bytes and all of them seem to have the string “MACRZ” at offset 36. I haven’t been able to find a open specification for this file format, so we will have to go with what we can find in the samples. According to ffprobe from above, there is 324 bytes of a header before the first MP3 frame starts.

MPEG signatures are difficult, there are no headers, just a sequence of frames. This is why there are often so many identification conflicts with the MP3 format. These SWA files indeed identify as MP3 files, but with a mismatch extension.

filename : 'tone2.swa'
filesize : 82661
modified : 1970-01-01T00:00:00-07:00
errors   : 
matches  :
  - ns      : 'pronom'
    id      : 'fmt/134'
    format  : 'MPEG 1/2 Audio Layer 3'
    version : 
    mime    : 'audio/mpeg'
    class   : 'Audio'
    basis   : 'byte match at 0, 4088 (signature 5/9)'
    warning : 'extension mismatch'

If we wanted to distinguish an SWA from an MP3 we would need to create a new signature and give it priority over the MP3 signature. There is enough of a header this would be possible and easier, but since they are, in reality, just MP3 files does it matter? Trying to play a SWA on a modern computer is only possible if you change the extension to MP3.

If you want to take a look at some samples you can grab a couple I made on my GitHub page or check out some commercially made files for an awesome Star Trek Starship Creator game.