Useful programs

[kj911]

Found very old (13 years ago) LRZIP 32bit console compressors from net. Attached in below. Working from WinXP! Newest 32bit versions not available??

Description:

Long Range ZIP or Lzma RZIP

This is a compression program optimised for large files. The larger the file
and the more memory you have, the better the compression advantage this will
provide, especially once the files are larger than 100MB. The advantage can
be chosen to be either size (much smaller than bzip2) or speed (much faster
than bzip2). Decompression is always much faster than bzip2.

Lrzip uses an extended version of rzip which does a first pass long distance
redundancy reduction. The lrzip modifications make it scale according to
memory size.
The data is then either:
1. Compressed by lzma (default) which gives excellent compression
at approximately half the speed of bzip2 compression
2. Compressed by lzo which on most machines compresses faster than disk
writing making it as fast (or even faster) than simply copying a large file
3. Leaving it uncompressed and rzip prepared. This form improves substantially
any compression performed on the resulting file in both size and speed (due to
the nature of rzip preparation merging similar compressible blocks of data and
creating a smaller file).
4. Compressed by bzip2 as an rzip-like compression format.

The major disadvantages are:
1. It only works on single files. To get the best performance out of the
compression it is best to tarball all your files together.
2. It requires a lot of memory to get the best performance out of, and is not
really usable (for compression) with less than 256MB. Decompression requires
very little ram and works on small ram machines.
3. Does not work on stdin/stdout.

[Joe Forster/STA]

Originally Posted by kj911

Found very old (13 years ago) LRZIP 32bit console compressors from net. Attached in below. Working from WinXP! Newest 32bit versions not available??

Its latest source is available at https://github.com/ckolivas/lrzip and you can download the binary as part of Cygwin.

[danthespal]

WinDirStat is a disk usage statistics viewer

[BLACKFIRE69]

Quick File Hashing v1.0

.

[KaktoR]

Is there a tool to null file contents (replace with zeros from beginning to end of file), especially if you have multiple files?

I know I can do it with HxD but if you have many files this will get odd.

[Masquerade]

Originally Posted by KaktoR

Is there a tool to null file contents (replace with zeros from beginning to end of file), especially if you have multiple files?

I know I can do it with HxD but if you have many files this will get odd.

I asked Razor and FitGirl this a while back and they both said to use fsutil to create files of a defined size.

[KaktoR]

Thanks for the hint with fsutil, took me a bit to understand as I have never worked with it. Here is a working batch

FOR /R %%a IN ("*.bk2") DO (fsutil file setzerodata offset=0 length=%%~za "%%a")

It fills all selected files by file extension in current and sub folders with zeroes, beginning from first offset to last.

[shazzla]

Works or not ,i dont know :

https://github.com/hpxro7/wwiseutil

[kj911]

The very old and very simple 7zSFX file splitter....

Separately saves the 7zSFX file, installation configuration (simple TXT) and 7z archive.

[kj911]

Quick tested in freshly new ListExt from WinXP! Nice and found the file size reports bug. Listed results 100* bigger than real. (Missing "." or "," characters.)

[BLACKFIRE69]

Originally Posted by kj911

Quick tested in freshly new ListExt from WinXP! Nice and found the file size reports bug. Listed results 100* bigger than real. (Missing "." or "," characters.)

does this work?

[kj911]

Originally Posted by BLACKFIRE69

does this work?

Testing now!

Previous days (2023.03.16. build): This file size reports bug, available from Win7 SP1 x64!

Last days (2023.03.17. build): File size report fully works!! (WinXP and Win7)

[L33THAK0R]

An excerpt, from the wiki page:

StuffIt Image Format (SIF)

"Early in 2005, a new JPEG compression system was released that regularly obtained compression in the order of 25% (meaning a compressed file size 75% of the original file size) without any further loss of image quality and with the ability to rebuild the original file, not just the original image. (ZIP-like programs typically achieve JPEG compression rates in the order of 1 to 3%. Programs that optimize JPEGs without regard for the original file, only the original image, obtain compression rates from 3 to 10% (depending on the efficiency of the original JPEG). Programs that use the rarely implemented arithmetic coding option available to the JPEG standard typically achieve rates around 12%.)

The new technique was implemented as a StuffIt X format option in their StuffIt Deluxe product. They have also proposed a new image format known as SIF, which simply consists of a single JPEG file compressed using this new technique.

Pending filing of their patent, they retain knowledge of the details of this algorithm as a trade secret. Some details are disclosed in: the high JPEG recompression is achieved by undoing the last step of the JPEG compression itself (the Huffman encoding of quantized transform coefficients). Instead, the transform coefficients are compressed by a more efficient algorithm (a predictive model based on the DC coefficients of neighboring blocks). Similar techniques are also applied for other image file formats such as GIF and TIFF and even the MP3 music file format. By means of decomposition, the relatively high compression rates for individual file formats can also be achieved for container file formats such as PDF, PSD and even ZIP."

Attached below is an archive containing, what I believe to be all the appropriate resources needed to create an StuffIt archive, a sample jpeg and a simple batch script to test packing. I haven't experimented with every available switch, so don't take the sample script as being the most optimal method of packing. Theres a plethora of other resources that are created when installing this software but I'm pretty confident that, at least in testing only these files are needed to create a StuffIt archive.

Preliminary tests have shown uninmpressive results, in contrast to a typical compression chain of srep & lolz

Source: 32 MiB JPEG

StuffIt -> 27.3 MiB
S + L   -> 15.1 MiB

It's entirely possible I failed to configure the compressor properly but thought I'd share it regardless in case anyone would like to test it for themselves.

[kj911]

L33THAK0R: This test image sets, publicable?? (32MB -> 15MB)

The 'S + L methods' = Stuffit+LOLZ?

The compressor, not user friendly in takes very long commands and more options! The compressor, says message: "StuffIt Deluxe is not installed. To obtain StuffIt Deluxe visit..." Resolve, use registration code added from registry before compression and delete its after compression in finished. Or make VBOX-ed EXE-package from to ONE exe files, from (de)compress... Few dll's properly injectable the main executable files, reducing files counts. Upload to my package?

UPDATE: Checked my package, not injected more dll's to main EXE files... The "sitx.dll" readable to "plugins" dir.
The registration code problem its mininally harderly resolve from newer than WinXP OS, aka SysWOW6432 related issues.
More problems, finding optimal, best and hardware scalable (dict. size and cpu threads related) compreesion commands achieve overall best compreesion ratio.

My results from "test.jpg" file: 5 420 967 byte

[L33THAK0R]

Originally Posted by kj911

L33THAK0R: This test image sets, publicable?? (32MB -> 15MB)

The 'S + L methods' = Stuffit+LOLZ?

The compressor, not user friendly in takes very long commands and more options! The compressor, says message: "StuffIt Deluxe is not installed. To obtain StuffIt Deluxe visit..." Resolve, use registration code added from registry before compression and delete its after compression in finished. Or make VBOX-ed EXE-package from to ONE exe files, from (de)compress... Few dll's properly injectable the main executable files, reducing files counts. Upload to my package?

UPDATE: Checked my package, not injected more dll's to main EXE files... The "sitx.dll" readable to "plugins" dir.
The registration code problem its mininally harderly resolve from newer than WinXP OS, aka SysWOW6432 related issues.
More problems, finding optimal, best and hardware scalable (dict. size and cpu threads related) compreesion commands achieve overall best compreesion ratio.

My results from "test.jpg" file: 5 420 967 byte

my mistake, I had put together the test suite rather quickly and hadn't even thought to test it on a fresh VM. I definitely should have clarified, "S + L" was "Srep + Lolz". I'm afraid my brain might be a bit fried because I can't really understand the rest of your post. I'll start trying to put together a functioning testing suite.

EDIT:
If you don't mind me asking how were you able to achieve your 5mb result?