7Zip: Packen von identischer (CRC) Dateien und die Mathematik ....

Hallo zusammen,

leider weiß ich nicht wie dieser Mechanismus heißt - daher der Betreff nicht so toll.

Folgendes:
Ich komprimiere bei 7Zip mit der Stärke ULTRA (ob ich LZMA nutzen muss weiß ich gerade nicht)
Jetzt nehme ich 2 Dateien:
Datei1.JPG (CRC 123)
Datei2.JPG (CRC 123)
Datei 2 ist eine Kopie der 1. Beide Dateien je 10Mbyte groß.

Ich packe ... Das Ergebnis - Datei.7z ist 10,1Mbyte groß. Rar, Zip etc. bringt hier ca. 19,9Mbyte (JPG lassen sich halt schlecht komprimieren)

Was hier passiert ist eigentlich klar: Warum soll man 2 identische Dateien einzeln komprimieren wenn man Verweise/Links auf eine physikalisch existierende setzen kann:

Datei1.jpg => Datei.jpg
Datei2.jpg => Datei.jpg

Im Zusammenhang mit irgendeinem Dateisystem hab ich von gleichem System gelesen (ich meine jetzt nicht händisch erstellte Links - das ist was ganz anderes!). Lösche ich Datei2.jpg wird nur der Link zu Datei.jpg aufgelöst. Lösche ich dann Datei1.jpg wird der Link aufgelöst und erkannt: Datei.jpg hat keine verweise mehr => löschen.

Egal - weiter:

Jetzt nehme ich zwei völlig unterschiedliche Dateien
Datei 3.jpg = 10 Mbyte (CRC 382)
Datei 4.jpg = 10 Mbyte (CRC 184)
Ich packe -> Datei2.7z => 20Mbyte ... hab ich erwartet! JPG - mies komprimierbar!

Jetzt nehme ich diese 4 Dateien und erstelle das Archiv Datei_neu.7z. Ergebnis: 40Mbyte ... komprimierte Größe: ca. 39Mbyte ....

Warum?
Datei1.7z (Datei1, Datei2) = 10,1Mbyte
Datei2.7z (Datei3, Datei4) = 20Mbyte
Datei_neu.7z (Datei1,2,3,4) = 40Mbyte und nicht 30,1Mbyte. Warum klappt der Mechanismus, der in Datei1.7z, wirkt nur wenn 2 Dateien enthalten sind, aber nicht bei 4?

Das muss ja ein Grund haben. Dateiintegrität?


Grüße


PS: ich kann es leider gerade nicht testen - ich meine ZIP könnte das aber auch - höchste Komprimierung, LZMA usw.

Mit LZMA schaffe ich es noch nciht einmal, dass 7zip "erkennt", dass Datei1 und Datei2 gleich sind.

Ich habe 7zip mit zstandard. Da kann ich LZMA2 als Kompressionsmethode auswählen. Und damit klappt es dann. Und es klappt auch weiterhin, wenn ich neben den beiden gleichen Dateien noch ein paar andere rein schmeiße.

Meine Testdateien waren 256kb groß. Vielleicht hängt der Erfolg von den Dateigrößen ab?
Mit Zstandard als Kompressionsmethode funktioniert es übrigens auch.

Stark vereinfacht:

7Zip prüft (meines Wissens nach) nicht ob Dateien doppelt da sind um diese dann nur einmal zu speichern. Es werden jedoch sich wiederholende Datenstrukturen erkannt. Wobei Datenstrukturen die sich doppeln in einem sogenanntem Wörterbuch abgelegt werden, wo ihnen ein wesentlich kleinere Zahl als Index zugeordnet wird.

Als Beispiel wie 7zip den Spaß ablegen würde (ohne nachzuschauen mit welchen Werten 7zip genau arbeitet):

Wörterbuch: (Aufbau: Daten -> Index)
512KB Datensatz1 -> 1
512KB Datensatz2 -> 2
...

Dateien:
Datei1 besteht aus: 1, 2, 3, 4...
Datei2 besteht aus: 1, 2, 3, 4...

Die die Indizes irgendwo im Bereich 1-4Byte groß sein werden, ist das resultierende Archiv nur minimal größer als eine einzelne Datei.

Damit die Kompression in einem endlichem Zeitraum und mit einer endlichen Menge an Arbeitsspeicher fertig wird ist jedoch das Suchfenster für sich wiederholende Datenstrukturen begrenzt groß, genauso wie die Größe der Wörterbücher eine definiert ist. Mitunter wird also einfach ein neues Wörterbuch angelegt, wenn das Erste voll ist. Entsprechend kann man da mal mit der Wörterbuchgröße spielen.


Was du auf Dateisystemebene meinst nennt sich Deduplikation. Im Vergleich zur Kompression wie es 7zip durchführt gibt es da feine, aber wichtige Unterschiede: https://de.wikipedia.org/wiki/Deduplikation (der englische Artikel ist besser!)

Haggis schrieb:

Meine Testdateien waren 256kb groß. Vielleicht hängt der Erfolg von den Dateigrößen ab?

Zum Vergrößern anklicken....

Jop, Wörterbuchgröße erhöhen sollte helfen.

wie gesagt: ob es lzma1/2 oder so war - weiß ich nicht.

Haggis schrieb:

Und es klappt auch weiterhin, wenn ich neben den beiden gleichen Dateien noch ein paar andere rein schmeiße.

Zum Vergrößern anklicken....

Mhhh

Dann vielleicht ein Bug in der 7-Zip 16.02 (4) (64bit)? Mhhhh

Haggis schrieb:

Meine Testdateien waren 256kb groß. Vielleicht hängt der Erfolg von den Dateigrößen ab?

Zum Vergrößern anklicken....

Aber warum soll die Dateigröße entscheiden sein ob es geht oder nicht? 7Zip schreibt in das Archiv eh die CRC und da muss ja erkannt werden: identisch. Ob jetzt 100Kbyte oder 100Mbyte?! Würde ich jetzt nicht als Ursache handeln ...

Zstandard ist der 7-Zip-Clone? Hab jedenfalls in der Auswahl bei 7-Zip 16.0x kein zstandard. Teste ich später




Edit:

wupi schrieb:

Jop, Wörterbuchgröße erhöhen sollte helfen.

Zum Vergrößern anklicken....

Die liegt glaub bei Standard. Aber warum geht das mit 2x10Mbyte-CRC123 aber nicht mit 4x10Mbyte (wo nur 2 identisch sind)?

Piktogramm schrieb:

Stark vereinfacht:

Zum Vergrößern anklicken....

ah gerade überschnitten.

Danke!

Also die Lösung wäre dann wirklich größeres Wörterbuch (aktuell glaub 16Mbyte)? Das sind ca. 50-200 Dateien á 3-6Mbyte ... 2-3 Dateien (die identischen) sind ~10Mbyte groß. Ob der jetzt zum komprimieren 30sek oder 2min braucht ist mir Latte ... Wie wirkt sich das den beim dekomprimieren aus? Es geht hier genau genommen um Comics - im CB7-Format - was ja einfach nur ein umbenanntes 7z ist. Lesegerät ist also ein Tablet - "normale" 500-600Mbyte CBZ (ZIP; 7Z/CB7 nutze ich noch nicht - war aber angedacht) lassen sich instant öffnen - Seiten cached der Reader (2 vor, 2 zurück). Power"zappen" von Seite 1 auf Seite 5 klappt nicht Cache sache. Wenn aber der initiale Start wegen größeren Wörterbuch viel länger braucht - dann lohnt sich das eher nicht umzustellen/re-komprimieren.

Was willst du mit CRC und der Fehlerkorrektur? Du scheinst da grundlegend Sachen durcheinanderzubringen.

CRC ist nicht zur Überprüfung der Integrität geeignet.
Da wären dann Hashmethoden angebracht.

Fehlerkorrektur/Datenintegrität interessiert mich hier nicht.

Wir kommen hier aber vom Thema ab ...

CRC auf gut deutsch: Redundanzprüfung. AllDup z.b. nutzt das um Dateien auf duplikate zu prüfen. Nennt das ganze Prüfsummenmethode und bietet hier z.b. SHA256 an. 7-Zip kann auch Prüfsummen erstellen - im Kontextmenu - auch z.b. SHA256 - aber auch CRC32.

CRC32 wird auch im 7z-Archiv ausgewiesen. Die Dateien um die es hier geht bieten auch bei SHA256 die gleiche Prüfsumme. Wobei Prüfsumme nicht mit Hash zu verwechseln ist. Aber von Hash hab ich nie geredet. Nur von CRC als Methode zu prüfen ob 2 Dateien identisch sind.

-------------------

Ich hab das System jetzt verstanden

Ich hab jetzt mal probiert:
2 Dateien je 16,6Mbyte
Ultra | LZMA2 | 64MByte Wörterbuch | 64 Wortgröße (Standard bei mir)
=> .7z => 16,6Mbyte

Den ganzen Ordner mit 897Mbyte bekomme ich auf 890Mbyte gepackt. War ja nach neusten Wissen zu erwarten .

Wörterbuchgröße hochschrauben ... schwer ... mehr als 128Mbyte geht bei dem System gerade nicht. Ich wähle also mal 129Mbyte an Daten aus (inkl. der beiden identischen Dateien)

64Mbyte Wörterbuchgröße, 273 Wortergröße => 128Mbyte Dateigröße
128Mbyte Wörterbuchgröße, 273 Wortergröße => 112Mbyte Dateigröße - AHA!
Die Differenz kommt mir bekannt vor

Ich hab jetzt auch mal ZIP getestet:
Gleichen Dateien - 128Mbyte Wörterbuchgröße oder 192Mbyte - es bleibt bei 128Mbyte.
Ich hab aber kein WinZip - sondern nutze 7-Zip. Bringt hier also eher nichts. Ich teste mal die Winzip-Demo wie die ist.

Und dann auch mal RAR 5 ... RAR hat eine extra Option um Duplikate mit Verweise zu belegen:
1Mbyte Wörterbuchgröße, Duplikate suchen => 112Mbyte Dateigröße (ohh)
128Mbyte Wörterbuchgröße, Duplikate suchen => 112Mbyte Dateigröße
1Mbyte Wörterbuchgröße, keine Duplikate suchen => 128Mbyte
128Mbyte Wörterbuchgröße, keine Duplikate suchen => 128Mbyte (mhhh)

Für meine Dateien wäre also RAR eigentlich die bessere alternative. Die Option das auf Duplikate geprüft wird, fehlt bei 7-Zip - leider. Dann hätte ich mit kleiner Wörterbuchgröße, bei großen Archiven trotzdem ein besseres Resultat.

Was jetzt noch offen ist:
Wie sieht die Performance beim Dekomprimieren aus (Schwaches System)?
Vernachlässigbar?


Edit:
WinZip ... OMG was haben die aus dem Tool gemacht selten ein Programm so schnell wieder deinstalliert
WinZip hat eigentlich nichts zum Einstellen - soweit ich das sehen konnte. Ich kann zwischen .zip wählen (128Mbyte) und .zipx (120Mbyte).
Nach dem Schock mit WinZip gehe ich jetzt erstmal einen trinken ....................

Mach ein Test mit deinen Daten zum Entpacken auf besagtem System. Die allgemeinen Aussagen dazu sind meist nicht so viel wert, da die Streuung im realem Anwendungsfall oft schlicht zu groß ist.

Piktogramm schrieb:

Mach ein Test mit deinen Daten zum Entpacken auf besagtem System.

Zum Vergrößern anklicken....

Ist schwierig - vorallem weil ich gerade gemerkt habe das 7z gar nicht vollständig unterstützt wird - vom Zielsystem schon - aber dazwischen liegt Calibre (eBook-Verwalter) und der kann in 7z nicht reinschauen (und auch nichts reinschreiben etc.) - das macht keinen sinn ... Ich gucke mal ob ich irgendwann mal ein 7z auf das Tablet schiebe und damit teste - da Calibre damit nicht sauber umgehen kann ist das jetzt nur noch nebensache :| RAR ist proprietär - daher kann Calibre da nichts reinschreiben - auslesen geht. Doof ... egal ... denn:

wenigstens was dazu gelernt ... Ziel verfehlt, trotzdem zufrieden Danke an alle


EDIT: ahh ... 7z: erst die Duplikate packen - den Rest dazu schieben - das klappt ... also mal nachfragen was mit sauberen 7z-Support in Calibre ist

Wulfman_SG schrieb:

Zstandard ist der 7-Zip-Clone? Hab jedenfalls in der Auswahl bei 7-Zip 16.0x kein zstandard. Teste ich später

Zum Vergrößern anklicken....

Das ist einfach eine 7z-Version mit Zstandard-Support:
https://github.com/mcmilk/7-Zip-zstd


Ich mache regelmäßig Backups von meinen VMs. Die Diskimages lassen sich ganz gut komprimieren. Mit den üblichen Methoden dauert das aber sehr lange. Zstandard komprimiert sehr schnell und gut genug.
Neben Zstandard ist in er Version auch LZ4, LZ5 und Brotli verfügbar, was in der offiziellen 7zip-Version auch nicht drin ist.