Talk:Solid compression

Cab files

I believe that Cabinet (file format) is also Solid, so merits addition, and it's pretty common, as every Windows system has .CAB files on it. Hobart 16:37, 18 May 2005 (UTC)

Is tar.gz / tar.bz2 solid?

I think it might be incorrect to say that tar.gz and tar.bz2 archives are solid. If I understand the concept correctly -- and I'm not sure I do -- then it could be said that a tar file is solid. All the individual files have been coalesced into a single block of bytes. Note that it doesn't necessarily mean that the file is compressed! It might be interesting to note that a gzip of a tar file would be solid, but a tar files of a number of gzipped files would NOT be solid. The difference between those two archive sizes might represent the difference between a solid and non-solid archive.

Indeed, but by definition a .tar.gz extension means that the tar step has been applied before the gzip step, so this is a solid archive. A "tar of gzipped files" (which would be pretty unusual) would have the extension .tar. A tar file itself is not solid because it isn't compressed and the individual files can be recovered easily (tar files are just concatenated header-data-header-data-... - there is no overall header or trailer which is required to be there). Richard W.M. Jones 14:20, 10 August 2006 (UTC)

History of solid compression

It would be nice to see some information about the first codec to feature solid compression.

This might have been the RAR format/codec appearing in the early 1990's.

But if you count unix's tar -z (tar compressed by the external compress programm) as a codec, this one should have been first. -- Juergen 89.54.108.20 12:31, 15 October 2006 (UTC)

faulty grammer

I don't know what this sentence is trying to say using the word "ostensibly" as a noun, so someone who has an idea should change it (it's in the opening paragraph): "The term is ostensibly because the data is compressed..."

It means more or less the same as: "The term is apparently because..." Otus (talk) 10:55, 24 January 2010 (UTC)

Block size limits

Now that there are 7-zip parameters that limit the solid block size window (by size, number of files, and file extension) there are additional aspects that should be explained. If a set of files is processed as one vast block, the order of processing the files may not matter much. But now the order of processing matters a lot. It is an important optimization to process similar files together. How do 7-zip and other programs decide on file processing order, and what options does the user have to control this?-96.233.30.57 (talk) 12:54, 6 May 2011 (UTC)

http://www.7-zip.org/history.txt

9.04 beta      2009-05-30
-------------------------
- 7-Zip now can update solid .7z archives.

4.45 beta      2007-04-17
-------------------------
- Now it's possible to specify the size of solid block and the number 
  of CPU threads in "Add to archive" dialog box. 

3.11           2003-10-06
-------------------------
- 7-zip now use limitations for solid block size
  for increasing the speed of random file decompressing:
    - in Store mode:     0  B
    - in Fast mode:     16 MB
    - in Normal mode:  256 MB
    - in Maximum mode:   1 GB 
    - in Ultra mode:     4 GB 

http://docs.bugaco.com/7zip/MANUAL/switches/method.htm
-m (Set compression Method) switch
s=[off | on | [e] [{N}f] [{N}b | {N}k | {N}m | {N}g)]

Enables or disables solid mode. The default mode is s=on. 
In solid mode, files are grouped together. 
Usually, compressing in solid mode improves the compression ratio.

e	Use a separate solid block for each new file extension
{N}f	Set the limit for number of files in one solid block
{N}b | {N}k | {N}m | {N}g	Set a limit for the total 
size of a solid block in bytes

Duplicate files

If a set of files contains exact duplicates, a compressed archive would be much smaller if it just stores one copy. (See Data deduplication) Which archiving tools and formats are best at doing this, under what conditions? It seems that 7zip is good at this, but could still be improved? [1] [2] -96.233.30.57 (talk) 14:33, 6 May 2011 (UTC)

Intro phrasing

wherein all the compressed files are concatenated and treated as a single data block

I would rather say, "all the files to be compressed" (not compressed yet) are concatenated. Unless I missed the whole point? Ripounet (talk) 20:53, 26 May 2011 (UTC)

my understanding is they are concatenated before compress, i.e., treated as a continuous data stream. Handy for lots of similar small files Best to check the source. — Preceding unsigned comment added by 122.108.150.123 (talk) 13:33, 2 June 2011 (UTC)