Data compression

[TacB0sS]

hey, I have a bunch of data in a few files, and for saving jar size, I would like to both compress them all and split them into a few files, a few of a 20k each or something like that, a size that would not exhaust the phone on loading. is there mechanizem like that for J2Me, or should I learn data compression technics and implement it myself?

[ingsaurabh]

http://www.winterwell.com/software/compressor.php

you can find others by googling it will be more helpfull if you describe your scenario more clearly

As far as if there are multiple files then u could make them concatenate to form less files

[TacB0sS]

I have shrank the my application from 200 files that I had into less then 10, which I must have in separate files for different application components, each file contains 20k - 30k of image and audio data for both game, and other game managing data, such as splash screen and logo, and I was wondering, if I could make these 240k into something smaller, and decompress on the phone, in a loading process of the application?

I would like to both compress them all and split them into a few files, a few of a 20k each or something like that, a size that would not exhaust the phone on loading.

I meant by that, that I want to check if compressing a few files into one compressed file would result in a smaller jar size, by both reducing the amount of files and by compressing the data, sorry if I was not clear before.

[grahamhughes]

Packing many small files (~1k) together makes for better compression. Packing files of 30k+, probably doesn't.

There are two benefits to packing files together:

1. There is a fixed amount of overhead needed in the JAR to hold the file name, size, CRCs, etc. The smaller the file is, the larger this overhead is as a proportion of the total space needed. Therefore, larger files are more efficient.

2. JAR compression works by finding repeated sequences of bytes in each file. Since the compresion is done on each file individually, a sequence of bytes in file B that is identical to a sequence in file A cannot be removed by compression, and both sequences will appear in the JAR. Packing A and B together to create file C will enable the duplicate sequence in C to be removed. However, I think duplicate sequences need to be fairly near to each other (within 32k) to be identified (don't quote me, you'd need to learn about ZLIB to find out for sure). Assuming that's correct, packing two files of 40k each together will probably not improve compression significantly.

The problem with what you suggest is that compression algorithms like ZLIB are sequential.. if you compressed all the data together, then split the result, you would have to re-assemble them to decompress them again (or decompress them in order). You would not be able to decompress only the fifth file, for example, without decompressing one to four first.

Also, you may well end up adding code that takes more space than you save.

I'd suggest that if you have resource files in the region of 20-30k each, then you are getting the best compression you are likely to get (without causing yourself a huge amount of headache).

Graham.

[TacB0sS]

Great, Thanks, I would definitely take all this under consideration...
I would post back of course if I would reach any interesting conclusions...

[TacB0sS]

btw, how much data can I store on the rms? I mean maximal of phones, and I don't mean the new ones that have an unlimited size of everything, this way, I could extract and save the data into a rms and load it from there every time, this would save me repeated decompressing and stuff the question is, could phones support 300k on the rms for a midlet suit???

[grahamhughes]

On a lot of Series 40s, it's less than 100k. It's not a newer device/older device thing... all S60s have unlimited RMS, all S40s have a limit.

Graham.