flag 11 compressions?

Discussion in 'NDS - ROM Hacking and Translations' started by psycoblaster, Dec 18, 2008.

Dec 18, 2008

flag 11 compressions? by psycoblaster at 12:23 PM (1,176 Views / 0 Likes) 5 replies

  1. psycoblaster
    OP

    Member psycoblaster Divine

    Joined:
    Jan 26, 2008
    Messages:
    2,132
    Location:
    Seoul.. (in Korea)
    Country:
    Korea, South
    Many games released these days, mainly from SquareEnix, such as Chocobo Tales, the Dragon Quest series and more, many files seem to be compressed with a compression with a flag of 11.
    The compression seems similar to LZ77, so I'm guessing it is another form of LZ.
    Is there any way to decompress these, or do any of you know what type of compression it is?
     
  2. Noitora

    Member Noitora ::

    Joined:
    Aug 9, 2007
    Messages:
    3,768
    Location:
    Athens
    Country:
    Greece
    The Korean romhacking community doesn't know?
     
  3. psycoblaster
    OP

    Member psycoblaster Divine

    Joined:
    Jan 26, 2008
    Messages:
    2,132
    Location:
    Seoul.. (in Korea)
    Country:
    Korea, South
    nope
     
  4. Noitora

    Member Noitora ::

    Joined:
    Aug 9, 2007
    Messages:
    3,768
    Location:
    Athens
    Country:
    Greece
    Too bad :/
     
  5. KiC

    Newcomer KiC Member

    Joined:
    Jul 22, 2007
    Messages:
    43
    Country:
    Germany
    Just a custom compression, like so many others. Learn assembly and how to debug, and the problem is gone.
     
  6. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,746
    Country:
    United Kingdom
    I have not done any work on this type but if it is similar to LZ as you say then it could simply mean that the flag term is 11 (guessing that is hex) as opposed to the usual type or it could deal with the actual compression:

    LZ compression is a sliding window compression as follows.
    You get the file and have a "window" wherein you look for repeated sections, the size of your window affects speed/resource requirements and level of compression achieved.

    If a repeat is encountered a flag is sent up along with a distance to travel back to get what you need.

    There is no set method for flag (traditional/common is 4/12 4 for length of string and 12 for position).
    You can however use many others, my guess is is it 5/11 (no reason to use more than 2 bytes and I am assuming they were not as silly as to use something other than a multiple of 8.

    More on the actual implementation here:
    http://www.romhacking.net/docs/281/
    http://wiki.xentax.com/index.php?title=LZSS


    I will however have a look as this sort of thing interests me, have you tried any of the BIOS compatible decompression tools yet? (it is not the first time the BIOS functions have been eschewed in favour of another).

    edit: pulled apart a rom. Do you mean the 11 hex that starts the files?

    edit 2: going with the 11 as the flag for a given compression it appears to go as follows. Pulling apart .pak.z files in 3151 Chocobo to Mahou... from BAHAMUT.
    11; signal for compression (I often see LZ or similar starting files in earlier roms).
    Next 3 bytes (which with the flag and accounting for the first part of the compression makes it aligned) I guess are the uncompressed size of the thing. Next is the start of the file (usual 4 ASCII magic stamp here)

    Edit again.
    If indeed the unaligned bytes are sizes some things compress really well. More interestingly stuff appears to have the same uncompressed size across what the file names would indicate are similar files (all palette files are generally similar sizes ......)

    I have given up typing edit now, I will just get on with it.
    Some other files have 10 (the card.z and card.nscr.z files), if indeed it is related to the type of flag it could prove interesting [/wild speculation]

    OK that was too much of a coincidence. Just decompressed a file with the usual http://www.gbadev.org/tools.php?showinfo=56
    File in question was an unmolested Balcony1.pak.z
    \data\field\balcony1 ---- now confirmed for other files.
    Decompression was obviously wrong (I lost most of the data I could "see" in favour of junk) but the size matched exactly. Removing the 11 and next few bytes did not go so well (all junk was made).
    I am guessing now it was a specialist type of compression (not the usual 4,12), fortunately the tool I linked is open source, unfortunately I think my copy of autoit is the limit of the dev tools on this machine.
     

Share This Page