Oh my god... NOBODY on a fucking COMPRESSION NEWSGROUP (supposedly
frequented by Ph.Ds) gave the right advice for a simple and OBVIOUS
task, except Jim Leonard. WOW. Next person who calls me a troll/newb
will be force-fed his own testicles.

On Jan 12, 9:21 am, Industrial One <industrial_...@hotmail.com> wrote:

At the risk of tasting my own testicles, I could mention that
comp.compression was created primarily as a discussion for new
compression methods and techniques, as illustrated by its charter:http://www.faqs.org/ftp/usenet/news.announce.newgroups/comp/comp.comp...
So it's not entirely unreasonable that people here would rather attack
the problem from a theoretical or analytical standpoint. 15 years
later, it is still primarily a group for discussion of methods and not
necessarily a utility support group.

the problem from a theoretical or analytical standpoint. 15 years
later, it is still primarily a group for discussion of methods and not
necessarily a utility support group.

Industrial One wrote:
The problem was that nobody gave the OP the correct
advice, which is to use solid compression.

Because it isn't [the] correct advice. Using one dictionary for one file of
10 MB IMO will result in poor compression. When the dictionary is

discarded and rebuilt during compression of one such file, it will be
rebuilt for every following file as well. The windows in other

compression methods also are much smaller than one such file. Please
name a compression method, that will analyze and compress chunks of 100 MB.

DoDi

Industrial One wrote:
The problem was that nobody gave the OP the correct
advice, which is to use solid compression.

Because it isn't a correct advice. Using one dictionary for one file of
10 MB IMO will result in poor compression. When the dictionary is
discarded and rebuilt during compression of one such file, it will be
rebuilt for every following file as well. The windows in other
compression methods also are much smaller than one such file. Please
name a compression method, that will analyze and compress chunks of 100 MB.

DoDi

The problem was that nobody gave the OP the correct
advice, which is to use solid compression.

7-Zip uses 32-bit pointers, IIRC, so that would make the window 4Gig.

Jim Leonard wrote:
7-Zip uses 32-bit pointers, IIRC, so that would make the window 4Gig.

How that?

Thanks, I'll have a look at that.

10 MB is nothing. As Jim said, 32-bit pointers, 2^32 = 4,294,967,296
bytes.

This doesn't say anything about the usage of such pointers. You also
ignore the fact, that the *total* address space is less than 4GB.

DoDi

discarded and rebuilt during compression of one such file, it will be
rebuilt for every following file as well. The windows in other


The thing is... it doesn't. Why the hell would it? Solid compression
is basically combining all files into one and compressing. If I
manually joined ten 10 MB files into one and compressed normally --
what do you think would happen? Would the dictionary keep re-adapting
and discarding itself as you claim?

Whenever I think of
"comp.compression" I imagine retrocomputing, using old GZIP and shit,
and it seems accurate when I see people unable to grasp basic new
compression concepts.

compression methods also are much smaller than one such file. Please
name a compression method, that will analyze and compress chunks of 100 MB.

DoDi


LZ77. As I said, I compressed fifty 32 MB files (1.5 GB total) to 56
MB

10 MB is nothing. As Jim said, 32-bit pointers, 2^32 = 4,294,967,296
bytes.

I did not see how to turn on the "solid" option in p7zip.
Maybe it is not implemented for compressing?
but at least it extracted successfully the 28Mb from created with 7-
Zip

Using 7-Zip (32Mb dictionary, Solid block-size: 4GB): 28 Mb !!!
Using p7zip (the unix 7-Zip equivalent): 211 Mb  :(

I did not see how to turn on the "solid" option in p7zip.
Maybe it is not implemented for compressing?
but at least it extracted successfully the 28Mb from created with 7-
Zip