SOMI:SE A bit of compression would have been nice

I'm just doing a trial run using PAQ8 on SOMI:SE's monkey1.pak file to see how it would have compressed using a good, LOSSLESS compression in addition to the current one (I'm not trying to compress audio, since they already are compressed and streaming can be more difficult if you use other compressions in addition to what the framework natively supports).

So far, I have to say that the results are well, shocking.

The compression is still running, so the results aren't final and will very likely get a little worse towards the end of the file, but it is a pretty clear indicator.

The first 400MB so have turned into 42MB, and that's not even using the highest compression that PAQ8 supports (which uses too much memory).

That's 10:1 for god's sake!
(The monkey1.pak file makes up around 65% of SOMI:SE's footprint, so even if the compression would end up being 5 to 1, that would still mean that SOMI:SE would be around half it's current size).

Comments

  • edited July 2009
    lol thats rediculous - with that large 2+ gigs download size they could be alienating allot of players.
  • edited July 2009
    Interesting. Wonder why they didn't bother to compress the game more.
  • edited July 2009
    Just ran a Lossless check on the Uncompressed Speech files, the archive supplied with the game is 799MB, all PCM WAVE files extracted equal to 795MB, these files when compressed with a Lossless Codec comes out to 459MB. A 336MB Saving!
  • edited July 2009
    They didn't compress it because they didn't think of it, good job.
  • edited July 2009
    Well, the compression is still running (PAQ8 is insanely slow during compression, but decompression is reasonably fast), but so far there has been no significant change in compression rate. I'm at 600MB now and the compressed output is at almost precisely 60MB.

    Naturally using standard ZIP would not have been quite as efficient, but my guess would be that it would still save at least 65% for the PAK file.
  • edited July 2009
    Almost forgot to post the results.
    MONKEY1.PAK

    compressed from
    1,242,812,968 bytes
    to
    129,882,200 bytes

    or in other words a compression ratio of
    9.6 to 1

    Add to that the 336MB Ash735 got just by converting the speech to flac and you'll see that even with stock tools, LA could have easily saved 1.5GB!!!!
  • edited July 2009
    I'm glad it wasn't compressed. The audio was nice and clear.

    There are so many people complaining of compression on Telltale games that I find it surprising that people are now complaining something isn't compressed.

    I guess if you have a bandwidth cap it would have been nice, but I prefer it the way it is.
  • edited July 2009
    No, we're just talking about LOSSLESS compression here. Not a single bit was harmed during this process.
  • edited July 2009
    No, we're just talking about LOSSLESS compression here. Not a single bit was harmed during this process.


    Ah I see. Makes no difference to me though like I said, would have been nice for people with bandwidth caps.
  • edited July 2009
    Exactly, we're talking about Lossless compression, no quality is lost, in Audio terms anyway, Lossless is more akin to Zipping the original Wave but more efficent. The only downside is that it will require more CPU power to decode and playback these files, but considering they done the game engine again anyway, they could of really worked on it to support a Lossless format instead of Full PCM.

    Also, yes it is surprising we're talking about this, seems neither TellTale or LucasArts can't get it right, I'm in favour of LucasArts though, I'd rather have uncompressed than over compressed.
  • edited July 2009
    Part of me is simply amazed at how much redundancy must exist in the data to allow for such a compression ratio. 10 to 1 !!! A normal ratio is 2, in special cases 4 to 1.
  • edited July 2009
    Maybe it's a trick! They wanted to see just HOW desperate we are :-)))
  • edited July 2009
    Or maybe somebody forgot to clean out his temp folder before building the PAK file (yes, I've actually seen this happening before) ;)
Sign in to comment in this discussion.