$ hd -n 256 common_rel
00000000 4c 5a 53 53 00 14 e5 b0 00 07 4c 61 00 00 00 00 |LZSS......La....|
00000010 ea ed f0 7d e6 f8 0b ed f0 4c 00 00 ab 15 3c ed |...}.....L....<.|
00000020 f0 27 ed f0 03 ec f2 14 eb bf 70 12 00 60 ed f0 |.'........p..`..|
00000030 10 01 01 fd 01 ea f4 05 fc 00 00 0a 80 4a ed f0 |.............J..|
00000040 04 ed f0 01 12 02 e7 f7 a5 2a 00 fd 9c f3 f8 40 |.........*.....@|
00000050 00 00 0d 0c 00 7f 00 18 4c 00 14 a7 14 dc ff fc |........L.......|
00000060 73 0f e5 f9 94 21 ff f0 93 e1 ff 00 0c 7c 3f 0b |s....!.......|?.|
00000070 78 3d 20 d7 00 00 3d 19 00 38 fd f0 90 09 00 a0 |x= ...=..8......|
00000080 00 9f 0f b1 0f c3 0f d5 0f e7 0f f9 0f 0b 1f 00 |................|
00000090 1d 1f 2f 1f 41 1f 53 1f 65 1f 77 1f 89 1f 9b 1f |../.A.S.e.w.....|
000000a0 00 ad 1f bf 1f d1 1f e3 1f f5 1f 07 2f 19 2f 2b |...........././+|
000000b0 2f 00 3d 2f 4f 2f 61 2f 73 2f 85 2f 97 2f a9 2f |/.=/O/a/s/./././|
000000c0 bb 2f 00 cd 2f df 2f f1 2f 03 3f 15 3f 27 3f 39 |./../././.?.?'?9|
000000d0 3f 4b 3f 00 5d 3f 6f 3f 81 3f 93 3f a5 3f b7 3f |?K?.]?o?.?.?.?.?|
000000e0 c9 3f db 3f 00 ed 3f ff 3f 11 4f 23 4f 35 4f 47 |.?.?..?.?.O#O5OG|
000000f0 4f 59 4f 6b 4f 00 7d 4f 8f 4f a1 4f b3 4f c5 4f |OYOkO.}O.O.O.O.O|


First word is obviously a signature; second is 1,369,520, which is about 2.9 times the file's size, so good bet for uncompressed size; third is 478,305 which the file's size; fourth is likely padding, but potentially an offset into the file (minus header).

What I've seen from similar formats was that the header pointed to two sections, one containing raw data and the other containing offset/length pairs, and was followed by a bitmap telling which to read from next. This doesn't have any such pointer, and the following data seems to have quite a few zero bits, actually resembling machine code somewhat for the first few words. The name "common_rel" suggests an executable, so this makes sense. I haven't tried to disassemble it though, so I might be way off there.

As you look further into the file there are some pretty obvious patterns, which is strange for compressed data. Starting around 0x700 looks like some type of uncompressed graphic. Especially you can see a pattern 1C xx xx repeating often... but, sometimes there are three bytes between the 1Cs instead of two. That looks similar to the ASCII text around 0x440, that has readable words with single bytes inserted:
00000480 05 c5 07 e7 77 69 6e e7 00 d5 0c 76 69 72 ef 74 |....win....vir.t|
00000490 75 61 6c bf 0a 73 69 72 ff 65 6e 5f 61 74 6d 6f |ual..sir.en_atmo|
000004a0 73 fe bf 0a 6c 65 76 65 6c 5f 75 f9 70 aa 03 9a |s...level_u.p...|

And there's an obvious bit pattern in some of those. Check this from 0x48E:
EF ;binary 1110 1111
74 75 61 6C ;ASCII "tual" (from "virtual")
BF 0A ;???
73 69 72 ;ASCII "sir" (from "siren"?)

FF ;binary 1111 1111
65 6E 5F 61 74 6D 6F 73 ;ASCII "en_atmos" (siren_atmos, probably a sound file name)

FE ;binary 1111 1110
BF 0A ;???
6C 65 76 65 6C 5F 79 ;ASCII "level_u"

See the pattern... Counting from right to left (least significant bit first), 0xEF has 4 ones, a zero, and three ones. And immediately after it, we see 4 bytes of ASCII, something unusual (BF 0A), and then three bytes of ASCII. The same pattern follows further on: FF followed by 8 ASCII bytes, FE followed by one unknown (BF 0A again) and 7 ASCII bytes. So, obviously these bytes are bitflags, counting from least significant bit upward, where 1 indicates a raw data byte and 0 indicates something else.

I would expect that "BF 0A" is some type of offset, meaning to copy some bytes from elsewhere into the output. I also notice that these are occurring at the end of each string, and 0A is a newline character, but this doesn't seem to repeat further on, so this is probably coincidental.

I'd guess that BF 0A means to copy 0xA bytes from offset 0x0BF. In other formats I've dealt with, those are relative offsets, so this would mean seek 0xBF bytes back in the output buffer and copy from there. It's a bit odd to see the same offset twice if it's relative, though. Another interpretation is 0x0A bytes from 0xBF. More likely, the actual count is 0xC or 0xD, because it takes two bytes to encode this, so there'd be no reason to ever have a count of less than 2. 0xC seems likely, since it's a multiple of 4, so as to align the strings to word boundaries.

If we assume this applies to the entire file after the header, we run into an interesting situation: the first byte is EA, binary 11101010, which means the first bit decoded would be 0, meaning to copy from previous output... but there's no previous output to copy from, so that doesn't make much sense. The pattern does seem to fit, though:

EA ;binary 1110 1010
EDF0 7D E6F8 0B EDF0 4C 00 00
AB ;binary 1010 1011
15 3C EDF0 27 EDF0 03 ECF2 14
EB ;binary 1110 1011
BF 70 1200 60 EDF0 10 01 01
FD ;binary 1111 1101
01 EAF4 05 FC 00 00 0A 80

following the bits from lowest to highest, we reliably encounter pairs that resemble those we saw earlier, and bytes that don't, exactly where we'd expect. So it's reasonable to say that this is the encoding of the entire file; the question being what exactly ED F0 (and BF 0A and so on) means.

Mostly they seem to be twelve bits having a high value (0xEDF, 0xE6F, 0xBF0) and four arbitrary bits. That corresponds well with length/offset pairs, and matches some of Nintendo's older compression formats. I always thought it didn't seem very efficient when the maximum number of bytes that can be repeated is so small, though.

Still, that doesn't tell where the data is coming from, given these offsets don't make any sense for such a large output buffer. (The offsets might be interpreted as 0xFED, 0xFE6, 0x0BF, but they're still too large.) It's possible they're offsets into some separate dictionary. That would make the repeated offsets between strings make sense, too, especially if it's padding and/or metadata. Being an offset into the file itself is another possibility, but it doesn't look that way here.

So, it might be necessary to find a dictionary table that goes with these files.

____________________