PIK

As I wrote "Settings are 7z, max, lzma2, 64MB, 192, 4GB and f=bcj2:d15M" 7), is Max. Max, ist default 32MB dictionary. Above, my dictionary is 64MB. Thx. p.s.: But, I mean, all these tests having ... interessting... [i]runs[/i] and results.

of course (64bit). 980MB Tif: 1) 11s, 100% load 2) 17s, 100% load 3) 2m:18s, 65%-75% 4) 2m:27s, 75%-80%, more fast jumps of progress bar, drop of load last ~15s to 35% 5) 2m:39s, 70%-78%, drop to 35% for last ~15s, compressed file is 170MB (wow, all antoher not under 173 MB) 6) 3m:14s, 72%-81% 7) 3m:25s, 73% (?), more fast jumps of progress bar, drop to 35% for last ~20s

Sorry. Files are of course 24bit (8x8x8 bit ;-) )

Hi (sorry for my english) I have a 980 MB 8bit Tiff (no LZW). With 4 core cpu I cant compress it, IF I choose 4 cores for the job. Intel 2500k/4.6 and 8GB superfast RAM. With 3 of 4 cores it works, but is very slow. But 7z do it. Result is a ~175 MB file in 6 minutes and ave. cpu load in task-manager is ~37%. ~2.5 MB/s speed... With 4 cores, the progress bar "flying" in 1 second to 50% and... 7z do nothing more. Also for the next 20 minutes... But I can abort the operation in the GUI. UI is not frozen....

Hi (sorry for my english) I have a 980 MB 8bit Tiff (no LZW). With 4 core cpu I cant compress it, IF I choose 4 cores for the job. Intel 2500k/4.6 and 8GB superfast RAM. With 3 of 4 cores it works, but is very slow. But 7z do it. Result is a ~175 MB file in 6 minutes and ave. cpu load in task-manager is ~37%. ~2.5 MB/s speed... With 4 cores, the progress bar "flying" in 1 second to 50% and... 7z do nothing more. Also for the next 20 minutes... But I can abort the operation in the GUI. UI is not frozen....

Howdy... (and sorry for... you know ;-) ) With 1.0f (2015) and many changes in the format, we... cherish XTS. I have dont understand why. Rogaway himself on page 6 "[...]that the nominally "correct" solution for (length-preserving) enciphering of disk sectors and the like is to apply a tweakable, strong PRP (aka wide-blocksize encryption) to the (entire) data unit. That notion is strong, well-studied, easy to understand, and readily achievable. There are now some 15+ proposed schemes in the literature...

"It was in those cases each time NOT a problem with hardware haywire devices." Mean: Not hardware defect of data carrier self.

Hi (sorry for my english) I heard 2017 accidentally in few threads - world around in some places in Web - that VC (and maybe also TC before?) have a problem with large volumes/containers, respectively big data move in these. In dimension of some Terabytes. The problems thought to be: lost of data integrity. But I also dont know whether regarding of crypto or of filesystem inside crypted volumes. It was in those cases each time NOT a problem with hardware haywire devices. At that time it was uninterested...