[gelöst] 7zip schlechte Kompression

[Patsche]

Hallo Leute.

Ich habe hier ein Frage. Ich benutzte das Paket p7zip-full und möchte gerne einen Ordner(Inhalt eine avi-Datei) komprimieren. Ich dachte mir mal Zeit sich mit Kompressionsverfahren auseinander zu setzten.
Gelesen habe ich nur gutes über das Format 7zip.
Jetzt habe ich folgenden Befehl benutzt:

Code: Alles auswählen

7z a -mx=9 "Film.7z" "Film"

und das Ergebins ist gerademal 3MB kleiner als das Original.
Dann habe ich mal folgendes probiert:

Code: Alles auswählen

7z a -mx=9 -tZIP "Film.zip" "Film"

Dieses Ergebnis zeigt eine Verkleinerung von 8MB.
Wieso ist zip kleiner, als 7zip?
Und wieso ist die Kompression so schlecht?
Ich hatte mit einer Verkleinerung von min. 30MB gerechnet.
Kann mir das jemand erklären?
Habe in den Befehlen oben schon die höchste Kompressionsrate gewählt.
Danke für Eure Hilfe und Anregungen.

[DeletedUserReAsG]

Und wieso ist die Kompression so schlecht?

Weil so Videodateien von sich aus komprimiert sind, und komprimierte Dateien sich nunmal schlecht komprimieren lassen (tatsächlich kann man’s so weit bringen, dass die komprimierten Dateien wieder größer als die Quelldateien sind).

[Patsche]

Aah okay...klingt einleuchtend. Hatte hier auch nochmal probiert einen Ordner mit MP3's zu komprimieren. (17 Dateien / 427,7MB)
Ergebnis (7zip):
422,2MB => 5,5MB => Verkleinerung von ca. 1,7%
Ergebnis (zip):
422,3MB => 5,4MB => Verkleinerung von ca. 1,26%
Ich hatte bisher immer von einer 50%-igen Steigerung von -7z gegenüber .zip gelesen.
Wo macht sich das denn besonders bemerkbar die Kompression? Dokumente oder Bilder? Hab das wirklich noch nie so genau beobachtet.

[Dogge]

Textdateien lassen sich wohl am besten komprimieren. Also txt, odt sind auch schon komprimiert. Bei Bildern kannst du bmp bestimmt noch komprimieren, bei jpg und png ist nicht viel zu holen. Ich würd einfach mal ne große Textdatei, wie z.B. ne SQL-Datenbank packen:

Code: Alles auswählen

 du -h backup-13-11-10.sql*                  
33M	backup-13-11-10.sql
7,5M	backup-13-11-10.sql.7z
11M	backup-13-11-10.sql.gz

[mistersixt]

Code: Alles auswählen

7z a -t7z -m0=lzma -mmt=on -mx=9 -mfb=64 -md=32m -ms=on /pfad/archiv.7z /pfad/zu/packendes/verzeichnis/

Damit bekomme bei Executables etc. sensationell gute Packraten. Ansonsten - wer viele Cores hat - sollte mal pbzip2 (parallel bzip2) ausprobieren, wenn da beispielsweise alle 16 oder 24 cores am Werkeln sind, geht das Packen sensationell schnell .

Gruss, mistersixt.

[wanne]

Also für texte komprimiert irgendwas mit vorangestellten Burrows–Wheeler am besten.
xz bzw. 7z spielen ihre stärken vor allem bei großen zusammenhängenden Strukturen aus. Große raw Bilder würden mir auf Anhieb einfallen. Allerdings gibt's dafür besser png. (Das führt am Ende im übrigen deflate (also den algorithmus den auch gz oder zip nutzen) aus.

Im schnitt gilt aber für die kompression:
Huffman < Arithmetische Codierung < LZSS (zip/gz) = LZ78 (compress) < Burrows–Wheeler+? (bzip(2))< LZMA (xz/lzma/7z) < Auf das Format optimierte Kompression (gif,png,flac) < verlusbehaftete Kompression (h264,opus,jpeg,quantisized png)

Geschwindigkeit dagegen:
Arithmetische Codierung > Huffman > LZ78 > LZSS > LZMA > Burrows–Wheeler+?

Alle nicht verlusbehafteten können maximal bis zum informationsgehalt komprimieren. (vollständig zufällige daten wie z.b. in bits codierte münzwürfe haben z.b. genau den gleichen informationsgehalt wie ihre größe und können dementsprechend nicht komprimiert werden.) Dementsprechen kann man beim 2. mal komprimieren eben maximal schwächen des voherigen Algorithmus ausbessern. => Es lohnt sich nur bei schlechter kompression nochmal zu komprimieren.
verlusbehaftete Kompressionsverfahren haben am Ende im Normalfall ein nicht verlusbehaftetes Kompressionsverfahen

Im Übrigen konvertieren die meisten auf das Format optimiere Verfahren im Normalfall schlicht zuerst in ein gleichgroßes/größeres gut komprimierbares format (sorgen dafür dass ähliche Sachen ähnliche bit-repräsentationen haben und nahe beieinander liegen) und komprimieren dann das mit einem der genannten algorithmen.
Verlustbehaftet Verfahren sortieren davor nach wichtig (Bild: Durchschnittshelligkeit) /unwichtig (Bild: rotunterschid zwichen Pixel 1,1 und 1,2) und nimmt es dann mit den nicht so wichtigen Daten nicht so genau

[Patsche]

Mit den mfb und md Zahlen habe ich auch schon gespielt -=> keine nennenswerte Unterschiede.
Mit den mehmals packen habe ich auch schon gehört, dass die Dateigröße nach einer gewissen Anzahl von Komprimierungen wieder zu steigen beginnt.
Hatte nur im Hinterkopf, dass Komprimierungen mit 7z schon recht gut sein sollten und hatte da wohl mehr erwartet.
Ich bedanke mich für die ausführliche Aufklärung bei Allen.
Super Forum mit netten und hilfbereiten Menschen.

[wanne]

Wie gesagt, wie gut der 2. Algoithmus ist, ist weniger wichtig. Ist der 1. gut wird der 2. nichts mehr verbessern können. Egal wie gut er ist.
Zypisches Beispiel:
Grundgesetz:
164 kiByte /164985 UTF-8-Zeichen
Geschtzter Informationsgehalt (für typishce Englische Texte 1,8Bit pro zeichen. Nehme an das es für deutsche ähnlich ist):
36 kibyte
Nach xz-Kompression:
39 kiByte
Ensprechen kann der beste Algorithmus (den noch keiner gefunden hat) nicht mehr mehr als zusätzlich 3 kiBit herausholen.

[uname]

Ich habe ja keine Ahnung vom Thema aber spielt die http://de.wikipedia.org/wiki/Entropiekodierung eine Rolle für ein optimales Komprimierungsverfahren je nach Datensatz?

[wanne]

Ich habe ja keine Ahnung vom Thema aber spielt die http://de.wikipedia.org/wiki/Entropiekodierung eine Rolle für ein optimales Komprimierungsverfahren je nach Datensatz?

Entropiecodierungen codieren jedes Zeichen für sich und ignorieren, dass man anhand der vorherigen Zeichen das nächste oft schon raten kann. Die beste Entropiecodierung ist Huffman. Aber man kann eben weit besser komprimieren als ausschließlich mit Entropiecodierungen. Dementsprechend kennt man das beste kompressionsverfahren eben nicht.
Entropiecodierungen spielen trotzdem noch oft eine Rolle, weil sie am einde vieler komplizierterer Verfahren eingesetzt werden. (z.B. jpeg,gif)

[Patsche]

Wollte nochmal ein Feedback geben für Leute, die diesen Thread später nochmal ansehen.
Ich habe gerade ein Wiki-Snapshot mit Hilfe von httrack gemacht mit Bildern und allesa drum und dran.
Insgesamt war der Ordner ca. 325,1 MB groß.
Nach der Komprimierung im 7z-Format nur noch 55,2 MB.
Eine Verkleinerung von ca. 275 MB. => 84,59%
Sehr beachtlich!
Und Danke nochmals für die Antworten!