Ripping data from .afs format

[Chu]

There's a game I'm trying to extract data from (audio, CGs, script, the works) but they're all packed in .afs, which I don't know anything about. I tried AFS extract but all of the CGs are in .cel format, so I can't view them. Is there a better program, or a way to convert the images to a viewable format?

[Asceai]

I've never even heard of that one before. Throw a .cel or two this way. (and a PNG of the image as a screenshot, if you can guess which one it is from the scripts you extracted or something)

[Chu]

I have absolutely no clue which images are which ^^; So there's some guess work involved.

http://www.u-chan.org/spare/C11B2M2.cel

[Minagi]

I think that might be an animation file and not CG. What other files are in the game?

Quick look at it and it's:

Header (0xf0 bytes, don't care enough to figure out what everything means)
I'm going to guess 0xC is the amount of files in the cel file, but I can't tell from just one file.


IMAG block, 32 bytes:
IMAG 4 byte
End of LZ file 4(maybe 8?) bytes
(24 bytes I don't feel like figuring out)

LZSS File:
LZ 2 bytes
Uncompressed file size 4(6?) bytes
Size of file without header 2(4?) bytes
LZSS data

Something like that.

[zalas]

Upon quick glance, I think that DWORD after the chunk name doesn't necessarily mean the end of the LZ chunk. I think it's a generic chunk length thing, and it points to the next chunk in the list of chunks. Why they chose to do it that way instead of length beats me. Maybe they intended to load the entire thing into memory...

As for the first header, it has 0100 0300 0200 0800. Not sure about the 0100, but the 0300, 0200 and 0800 probably refer to the number of ENTR, ANIM and IMAG chunks, respectively. The DWORD at offset 0x10 looks like the size of the file and the DWORD following might be the size of the file after decompression of all the chunks? It could also be a CRC32, but who knows...

EDIT: It's probably more likely the CRC32, since the files don't really expand to something that large. I find it funny how the LZ chunks are stored in bigendian format while the rest of the file is in little endian.

[Asceai]

Post more files. As a general rule, full-screen CG is often ~1mb or so, depending on the resolution. These .CEL files seem to be tiny on-screen animations, like what haruoto and ef use.

[Chu]

It looks like it packed animations and CGs all in the same .afs, so I just picked out the largest one and uploaded it.

http://www.u-chan.org/spare/EV083_1.cel (assuming this one is an event CG)
http://www.u-chan.org/spare/BG002_1.cel (assuming this one is a background CG)

[Minagi]

It looks like this now:

IMAG block
IMAG 4 bytes
Start of next chunk/end of current chunk (it's still there even with 1 file) 4 bytes
Null 4 bytes
Height 2 bytes
Width 2 bytes
? 12 bytes
Size of file 4 bytes

(When LZ is present)
LZ header
LZ 2 bytes
4 bytes big endian decompressed file size (probably wouldn't have noticed it was in big endian so thanks zalas :3)
4 bytes big endian compressed file size
LZ Data (Maybe it's not standard? It looks messed up after decompression)

Messing around with the uncompressed file in InfranView, I was able to come up with this from BG002_1.cel with the settings 640x480 32 BPP BGR Interleaved:


From EV083_1.cel (doesn't use an LZ file, it's a straight up raw image). Same settings as BG002_1.cel except it's 640x960:

[Chu]

How exactly did you get them like that? I downloaded the program but I just get errors when I try to open them.

Er. Also, is there possibly an easier way to do that? ^^;; because I have like...six hundred of these buggers.

[Minagi]

Try this: http://www.sendspace.com/file/ci8513

It'll extract both LZ and raw files from .cel files.

Usage: cel.exe [flag] (files)

flags:
x - extract
d - decompress (only works on LZ files)

You can use a wildcard to open the files, so cel.exe x *.cel and then cel.exe d *.lz would work best for processing a lot of files. A small note though, things that use the LZ compression might come out a little funny. I used the standard LZ code (besides a small part I added in to skip the header) but I think they might've changed things up in their compression.

What game is this for anyway?

[Chu]

I'm not exactly sure how to use this program... When I give it a cel, it says 'could not open'.

The game is Akai Ito. Technically the event CGs have already been ripped, I'm mostly trying to get at the character images.

[zalas]

Hahah, amusingly enough the first time I saw AFS was in Akai Ito. Still haven't fully figured out how to re-encrypt the data files so that the trial version would run the full version files. If that were finished, then an Akai Ito translation that would run on PC wouldn't be out of the question <_<;

I guess if I have time I could dig around the PC executable to find the LZ decompression code. Though, I really should get more work done on my image code for Python so that I can write plugins for various game formats in it and have it be able to export/import TIFF files or something -_-;

[Chu]

Originally Posted by zalas

Hahah, amusingly enough the first time I saw AFS was in Akai Ito. Still haven't fully figured out how to re-encrypt the data files so that the trial version would run the full version files. If that were finished, then an Akai Ito translation that would run on PC wouldn't be out of the question <_<;

Ahaha, that was *exactly* what I was going to try and do! Since someone is already translating it (and finished two character routes) I thought that if I could figure out how to run it on the PC I could edit the script.

[Minagi]

Originally Posted by Chu

I'm not exactly sure how to use this program... When I give it a cel, it says 'could not open'.

The game is Akai Ito. Technically the event CGs have already been ripped, I'm mostly trying to get at the character images.

Throw the exe in the same folder as the .cel files. That's how I always ran it.

[zalas]

for the first image in C11B2M2.

That image is an index-color image. The first four bytes are 00 01 00 00. The next 1024 bytes are BGRA tuples, each 1 byte each, for the palette entries. The rest is the image data, 1 byte per pixel. The image I posted does not have the color-palette on and is just using a default grayscale mapping.



BGRA ordering

Basically the LZ algorithm is as follows, as far as I know:

[L][Z][decompressed size:DWORD(BE)][compressed size:DWORD(BE)]

The LZSS implementation uses a 0x400(1024) byte window, with the starting offset at 0x3EE into the window (where the first lookback data will be written).

Flag bytes are used to denote lookback(bit=0) or verbatim(bit=1). Bits are read from LSB in the flag byte.

For verbatim, one byte is copied and placed into window

For lookback, two bytes are read. Let's say the two bytes are byte0 and byte1. The start of the read-back from the window is at offset ((byte1&0xf0) << 4) | byte0. The length of the read-back is (byte1 & 0xf)+3.

Hope this helps.

EDIT: So what's this about a translation already done for 2 routes? The ROFS CVM format is kind of annoying for Akaiito in particular because it uses a scrambled form. roxfan figured out the descrambling needed, but I still don't know exactly what fields correspond to what in the CVM and have been too busy to sit down and figure it out. Akaiito's code is massively painful to go through, since it uses lots of optimizations -_-;