PDA

Vollständige Version anzeigen : Richtig mit Winrar packen



Sheldon
27.06.2010, 14:13
Ich hab mir jetzt mal eine gepackte .rar-Datei runtergeladen, die eine Größe von knapp 8MB (7.968 kb) besaß.

Als ich sie entpackte, war ich doch sehr erstaunt. Es kamen insgesamt 277 Dateien mit einer Gesamtgröße von 537 MB(!) zum Vorschein.

Erstaunt über so eine Kompressionsrate hab ich einfach mal zurückgepackt und kam trotz mehrfacher Umstellung der Einstellungen auf eine Paketgröße von minimum 30 MB, also knapp das vierfache der ursprünglichen Paketgröße.

Ich benutze die Testversion von Winrar x64 3.93. Wie kann mit Winrar eine so hohe Kompressionsrate erreichen kann ist mir schleierhaft. Es war wie gesagt eine .rar-Datei, die ich mir runtergeladen habe und nicht etwa eine .uha-Datei.

Weiß da vielleicht einer einen Rat?

Sterntaler
27.06.2010, 14:19
sei doch froh.

twoxego
27.06.2010, 14:26
Ich hab mir jetzt mal eine gepackte .rar-Datei runtergeladen, die eine Größe von knapp 8MB (7.968 kb) besaß.

Als ich sie entpackte, war ich doch sehr erstaunt. Es kamen insgesamt 277 Dateien mit einer Gesamtgröße von 537 MB(!) zum Vorschein.

Erstaunt über so eine Kompressionsrate hab ich einfach mal zurückgepackt und kam trotz mehrfacher Umstellung der Einstellungen auf eine Paketgröße von minimum 30 MB, also knapp das vierfache der ursprünglichen Paketgröße.

Ich benutze die Testversion von Winrar x64 3.93. Wie kann mit Winrar eine so hohe Kompressionsrate erreichen kann ist mir schleierhaft. Es war wie gesagt eine .rar-Datei, die ich mir runtergeladen habe und nicht etwa eine .uha-Datei.

Weiß da vielleicht einer einen Rat?

mit der kostenlosen variante kannst Du wol den grad der komprimierung nicht regeln.
versuche es einmal damit. das kostet ebenfalls nichts.

KLICK (http://www.7-zip.org/)

Sloth
27.06.2010, 14:26
In der Tat erstaunlich!
Es liegt aber nicht an WinRaR, sondern am Format der gepackten Dateien. Manche lassen sich um 90 % komprimieren, manche nur um 1%. Einige wenige sind komprimiert sogar größer.

Das liegt an der Struktur der Datei. Ein BMP Bild läßt sich gut komprimieren, ein JPG Bild garnicht. Es ist ja schon komprimiert.

Leila
27.06.2010, 14:27
Dr. Murkes gesammeltes Schweigen.

twoxego
27.06.2010, 14:29
jenes höhere wesen rarte vermutlich nicht.

twoxego
27.06.2010, 14:30
gruselig.

Leila
27.06.2010, 14:34
Gepackte Bundestagsdebatte: Bla.

dZUG
27.06.2010, 14:37
CRC Verfahren :D

Sheldon
27.06.2010, 14:48
In der Tat erstaunlich!
Es liegt aber nicht an WinRaR, sondern am Format der gepackten Dateien. Manche lassen sich um 90 % komprimieren, manche nur um 1%. Einige wenige sind komprimiert sogar größer.

Ich habe denn Ordner unangetastet gelassen, es waren dieselben, wie beim 8MB-Packet


mit der kostenlosen variante kannst Du wol den grad der komprimierung nicht regeln.
versuche es einmal damit. das kostet ebenfalls nichts.

KLICK (http://www.7-zip.org/)

Denn Komprimierungsgrad kann man auch in der Gratisversion einstellen und ich hab sie auf "beste" Stufe gestellt. Ausserdem hab ich ein solides Archiv erstellt, das nochmal eine Menge Platz einspart. Das höchste, was ich mit Winrar erreicht habe, waren 30 MB.

7zip ist da schon leistungsstärker. Mit einem Speicherbedarf von 2GB (mehr geht bei mir nicht) und der Kompressionsstärke ULTRA komm ich damit auch auf die 8 MB, auch wenn die Geschwindigkeit arg darunter zu leiden hat. :)

Aber es war ja keine .7z- Datei, sondern eine .rar. Und mit .7z kann man keine .rar-Datei erzeugen.

dZUG
27.06.2010, 14:57
Das Paket rar hab ich grad in Linux installiert.


m<0..5> Set compression level (0-store...3-default...5-maximal)


Hier gibt es 5 Komprimierung Levels :D :D

*Edit* es gibt noch einen Schalter


mc<par> Set advanced compression parameters

Keine Ahnung was man damit anstellen kann :D

dZUG
27.06.2010, 15:13
Mit dem mc Switch ist es möglich anhand der zu komprimierenden Daten noch etwas heraus zu holen.


A - audio compression;
C - true color (RGB) data compression;
D - delta compression;
E - 32-bit x86 executables compression;
I - 64-bit Intel Itanium executables compression;
T - text compression.


Beispiel:


rar -m 5 -mc T Textzumkompri.txt Ausgangsrar.rar

So in etwa würde man es in Linux eingeben für Text :hihi:

Hier der Link zur Manpage http://forum.ge/?act=Attach&type=post&id=6169516
:D :D :D :D

Marathon
27.06.2010, 17:40
Optionen "Create Solid Archiv" und "Compression Method: best" anhaken.

Bei solid wird nicht jede Datei einzeln komprimiert, sodnern ein einziger Datenstrom über sämtliche Dateien erzeugt. Dadurch kann die Kompressionsrate deutlich erhöht werden.

Der Nachteil eines solid-Archives ist allerdings, dass CRC-Fehler in einer Datei auch Auswirkungen auf folgende Dateien haben.
Bei Archiven, wo höchste Datensicherheit gefragt ist, sollte man die solid-Option besser nicht anhaken.

Sheldon
27.06.2010, 17:59
Optionen "Create Solid Archiv" und "Compression Method: best" anhaken.


Hab ich genau so gemacht, so kam die 30MB-Datei zustande.

Marathon
27.06.2010, 18:17
Es gibt auch noch den Trick, dass man WAV-Dateien erst nach der Dekomprimierung aus MP3-Dateien erzeugen lässt.

Dazu muss man ein SFX-Archiv erzeugen und in den SFX-Optionen "Run after extraction" ein Programm starten lassen, welches eben diese Dekomprimierung von MP3 zu WAV durchführt.

Es muss sich nicht um MP3 und WAV handeln, sondern kann sich auch um jpg und BMP etc handeln.

Welche Dateien haben denn in deinem ausgepackten Archiv den meisten Platz beansprucht?

Marathon
27.06.2010, 18:27
Man könnte auch die Wörterbuchgröße erhöhen mit dem -m Schalter (-md4096) oder "Multimedia-Kompession" (-mm) einschalten.

versuche mal diese Parameter:
-m5 -md4096 -s
-mm -md4096 -s

Denkpoli
27.06.2010, 18:29
7zip ist da schon leistungsstärker. Mit einem Speicherbedarf von 2GB (mehr geht bei mir nicht) und der Kompressionsstärke ULTRA komm ich damit auch auf die 8 MB, auch wenn die Geschwindigkeit arg darunter zu leiden hat. :)

... und wenn du die Kommandozeile benutzt geht's noch stärker. Die Einstellmöglichkeiten sind der absolute Wahnsinn.
Es gab sogar mal eine Version, bei der man 7zip mit einer größenmäßig fixierten Auslagerungsdatei überlisten konnte, virtuellen Arbeitsspeicher als echten zu akzeptieren. Leider brach die Geschwindigkeit so ein, dass das nicht sonderlich praktikabel war, davon abgesehen, dass tagelanges ununterbrochenes Bewegen des Lesekopfes die Lebensdauer der Festplatte nicht gerade erhöht. Leider habe ich die Version nicht mehr, denn mit der SSD sollte das deutlich besser funktionieren.


Aber es war ja keine .7z- Datei, sondern eine .rar. Und mit .7z kann man keine .rar-Datei erzeugen.

Da der Aufbau des RAR - Formats selbst bekannt ist, ist es möglich, einen eigenen RAR - Komprimierer zu programmieren, der beispielsweise durch Parallelisierung ganz erheblich mehr Ressourcen nutzen kann. Wenn dann noch die Möglichkeit vorhanden ist, über's Wochenende die IT - Infrastruktur einer großen Intitution ( Schule, UNI ) zu nutzen, sollte es leicht sein, den Original - RAR zu überbieten.

Sterntaler
27.06.2010, 18:39
Kommandozeile ist mir ehrlich gesagt zu Dos-mäßig.

WinRAR "ic=first level" -r c:\*.rar *.txt

Sheldon
27.06.2010, 19:03
Man könnte auch die Wörterbuchgröße erhöhen mit dem -m Schalter (-md4096) oder "Multimedia-Kompession" (-mm) einschalten.

versuche mal diese Parameter:
-m5 -md4096 -s
-mm -md4096 -s

Die Wörterbuchgröße kann man auch im Menü einstellen, und da ist 4096kb als Standard eingegeben.

Zu sagen was für Dateien das sind ist schwer, da es sich um eine rechtliche Grauzone handelt. Deshalb möchte ich diese Aussage lieber verweigern ;)

Marathon
27.06.2010, 20:28
Die absolut beste Packmethode wäre die Stellenangabe des Datenblockes in PI.
Da PI keine Wiederholungen kennt, ist jeder beliebige Datenblock da mit ziemlicher Sicherheit irgendwo drin enthalten.
Gibt man nun lediglich die Startposition dieses Blockes in PI an, so kann man mit dieser einen Zahl den gesamten Datenblock rekonstruieren.

Das Komprimieren dauert natürlich extrem lang, da man diese Anfangsstelle nicht so leicht finden kann.

Sheldon
27.06.2010, 20:30
Die absolut beste Packmethode wäre die Stellenangabe des Datenblockes in PI.
Da PI keine Wiederholungen kennt, ist jeder beliebige Datenblock da mit ziemlicher Sicherheit irgendwo drin enthalten.
Gibt man nun lediglich die Startposition dieses Blockes in PI an, so kann man mit dieser einen Zahl den gesamten Ddatenblock rekonstruieren.

Das Komprimieren dauert natürlich extrem lang, da man diese Anfangsstelle nicht so leicht finden kann.

Was ist PI? 3,141...?

Marathon
27.06.2010, 20:39
Was ist PI? 3,141...?

ja
Die Kreiszahl.
Umfang eines Kreises geteilt durch den Durchmesser des selben Kreises.

Merksatz (Anzahl der Buchstaben gleich Ziffer in PI):
"Ist's doch o Isaac schwierig zu wissen wofür sie steht"
3,1415926535

Sheldon
27.06.2010, 20:48
ja
Die Kreiszahl.
Umfang eines Kreises geteilt durch den Durchmesser des selben Kreises.

Merksatz (Anzahl der Buchstaben gleich Ziffer in PI):
"Ist's doch o Isaac schwierig zu wissen wofür sie steht"
3,1415926535

Wenn die Komprimierung zu lange dauert, ist das eh nichts für mich da ich große Datenmengen mit dieser Methode packen muß. Ich bin zwar bereit, denn Rechner auch mal über Nacht laufen zu lassen, aber nicht über Tage hinweg.

Ich möchte 16 GB mit einer Kompressionsrate von 10% packen, so wie ich dieses auch runtergeladen habe.

Marathon
27.06.2010, 20:59
Du solltest einfach WinRar mit Einstellung "Gut" statt "Beste" benutzen und kein Solid anhaken.
"Beste" braucht nur unnötig viel Zeit für unwesentlich bessere Resultate und "Solid" verschlechtert die Archivqualität im Schadensfalle drastisch.

Für 16 GB braucht ein moderner Quadcore der unteren Klasse (i5 750) nur ca 1-2 Stunden.

Die modernen CPUs haben wirklich mächtig Dampf, was man auch merkt, wenn man mal Karten der Landesvermessungsämter exportiert und umwandelt.
Das geht mit derzeitiger Technik phänomenal schnell, während man sich selbst mit Dual Cores noch einen abbricht, weil es so eklig lange dauert.

Der Wegfall des FSB und der Level-3-Cache bringen enorm was.

Wichtig ist auch die Festplattenbandbreite. Man sollte von einer Festplatte nur lesen und auf eine andere Festplatte nur schreiben.
Benutzt man für lesen und schreiben dieselbe Festplatte, dann nützt einem auch ein schneller Prozessor nichts, weil der die nötigen Daten nicht schnell genug geliefert bekommt und die meiste Zeit nur Däumchen dreht.

Sheldon
27.06.2010, 21:39
Ich hab aber keinen Quad sondern nur einen altersschwachen X2-4200. Bis jetzt hat er mir gereicht und ich wollte eigendlich warten bis die X6 oder X8-CPUs in bezahlbare Regionen rücken bevor ich mir einen neuen Rechner zulege.

Denkpoli
14.07.2010, 19:36
Die absolut beste Packmethode wäre die Stellenangabe des Datenblockes in PI.

Das werden wir sehen!


Da PI keine Wiederholungen kennt, ist jeder beliebige Datenblock da mit ziemlicher Sicherheit irgendwo drin enthalten.
Gibt man nun lediglich die Startposition dieses Blockes in PI an, so kann man mit dieser einen Zahl den gesamten Datenblock rekonstruieren.

Davon geht man heute aus.


Das Komprimieren dauert natürlich extrem lang, da man diese Anfangsstelle nicht so leicht finden kann.

Rechnen wir mal nach:

Festlegungen:
1. Als Datenblock benutzen wir deinen Beitrag. Er hat ungefähr 400 Buchstaben, was ich hiermit als Tatsache festlege.
2. Dein Datenblock ist ein gewöhnlicher Text. 100 mögliche Symbole sind mehr als ausreichend, um einen solchen ( einschließlich Ziffern und Sonderzeichen ) darzustellen. Deswegen benutze ich hier als Grundlage das 100er - Zahlensystem, was auch noch den Vorteil hat, dass es so herrlich kompatibel zum 10er - System ist.

Berechnung:
1. Die Wahrscheinlichkeit, dass ein bestimmtes Symbol im Text mit dem einer gegebenen Stelle in Pi übereinstimmt ist 1/100.
2. Die Wahrscheinlichkeit pe ( e steht für Einzelereignis, in dem Fall, dass der gesamte Textblock übereinstimmt ), liegt dann bei 1/100^400 = 10^(-800).
3. Die Verbundwahrscheinlichkeit pv errechnet sich in hier nach: pv=1-(1-pe)^n, wobei n für die Anzahl der überprüften Textblöcke steht.
4. Wenn wir uns nun damit begnügen, dass der Textblock mit einer Wahrscheinlichkeit von nur 50% gefunden wird, gilt: 0,5=1-(1-10^(-800))^n. Als Ergebnis erhalten wir n=6,931E799. Damit sollte klar sein, dass deine Aussage "Das Komprimieren dauert natürlich extrem lang" eine extrem starke Untertreibung darstellt.

Nochwas: Vergleiche mal die Anzahl der Stellen, die du brauchst, um die Zahl abzuspeichern, mit der Anzahl der Stellen, die der unkomprimierte Text hatte.

twoxego
15.07.2010, 12:22
Wenn die Komprimierung zu lange dauert, ist das eh nichts für mich da ich große Datenmengen mit dieser Methode packen muß. Ich bin zwar bereit, denn Rechner auch mal über Nacht laufen zu lassen, aber nicht über Tage hinweg.

Ich möchte 16 GB mit einer Kompressionsrate von 10% packen, so wie ich dieses auch runtergeladen habe.

dann machst Du am besten ein CSO oder ISO daraus.
programme die das können, gibt es wie sand am meer. die können in der regel auch im hintergrund arbeiten.

GAP
15.07.2010, 12:45
dann machst Du am besten ein CSO oder ISO daraus.
programme die das können, gibt es wie sand am meer. die können in der regel auch im hintergrund arbeiten.

In einem solchen Fall empfehle ich sich TrueCrypt anzusehen. Die Daten werden in einer als Laufwerk eingebundenen Datei gespeichert. Die Lese und Schreibvorgänge sind sehr schnell und die Handhabung ist sehr komfortabel.

Schaschlik
15.07.2010, 12:58
(...)


Sehr gute Berechnung. Pi wird sich dafür nicht eignen denke ich.



Nochwas: Vergleiche mal die Anzahl der Stellen, die du brauchst, um die Zahl abzuspeichern, mit der Anzahl der Stellen, die der unkomprimierte Text hatte.

Es ist nicht notwendig Pi zu speichern, da diese Zahl jeder neu berechnen kann, wass freilich einen enormen zusätzlichen Aufwand bedeutet. Gespeichert werden nur die Startpositionen und Länge der einzelnen Datenwörter "auf Pi".

Allerdings könnte man sich fragen, warum überhaupt PI verwenden und nicht eine Mandelbrotmenge mit fester Definition. Sollte vom Prinzip her genauso funktionieren und ist bzgl. der zugrunde liegenden Berechnungen für heutige Rechner schneller zu ermitteln.


Und überhaupt: warum sollte man denn (wenn man es schon so macht) jedes einzelne Datenwort "auf Pi" kodieren? Man könnte ebenso den ganzen Text auf Pi "irgendwo" zusammenhängend finden....

Da sind wir dann schnell bei den Affen und Shakespeare (http://de.wikipedia.org/wiki/Infinite-Monkey-Theorem) ;)

Denkpoli
15.07.2010, 18:59
Pi wird sich dafür nicht eignen denke ich.

Es eignet sich auch keine andere Zahl. Eine Kompression ist nur durch das gezielte Ausnutzen von Redundanzen möglich. Man kann nicht einfach willkürlich die Codierung der Information ändern und erwarten, dass man dann ( im Durchschnittsfall ) weniger Speicherplatz braucht. Das wäre das Perpetuum Mobile der Informatik.


Es ist nicht notwendig Pi zu speichern, da diese Zahl jeder neu berechnen kann, wass freilich einen enormen zusätzlichen Aufwand bedeutet. Gespeichert werden nur die Startpositionen und Länge der einzelnen Datenwörter "auf Pi".

Da habe ich mich falsch ausgedrückt. Natürlich wird Pi nicht mitgespeichert. Das würde auch gar nicht gehen. Selbst wenn man zum Speichern eines Buchstabens nur ein Atom bräuchte, wäre die Anzahl der Atome im Universum, verglichen mit der Anzahl der Atome dieses Superspeichers, geradezu winzig.
Was man, wie du schriebst, wirklich abspeichern muss, sind die Startposition und die Länge des jeweiligen Datenblocks. Das sind aber auch wieder Zahlen, die selbst Speicherplatz benötigen. Und wie viele Stellen braucht man denn, um 6,931E799 exakt abszuspeichern?
Und nun bedenke: Das ist nicht der Durchschnittswert, sondern der Wert, den du bekommst, wenn du dich mit einer Trefferquote von 50% zufrieden gibst. Das ist sowas wie die Halbwertszeit eines radioaktiven Atomkerns. Die durchschnittliche Lebensdauer ist aber länger.


Allerdings könnte man sich fragen, warum überhaupt PI verwenden und nicht eine Mandelbrotmenge mit fester Definition. Sollte vom Prinzip her genauso funktionieren und ist bzgl. der zugrunde liegenden Berechnungen für heutige Rechner schneller zu ermitteln.

Und selbst wenn du es fertig bringst, den Berechnungsprozess und den Faktor hundert Quadrillionen zu beschleunigen ist das bei diesen Zahlen kein großer Unterschied zu vorher, davon abgesehen, dass wir inzwischen wissen, dass der Algorithmus nicht funktioniert.


Und überhaupt: warum sollte man denn (wenn man es schon so macht) jedes einzelne Datenwort "auf Pi" kodieren? Man könnte ebenso den ganzen Text auf Pi "irgendwo" zusammenhängend finden....

Genau das habe ich bei meinem Beispiel doch getan! ?(

Schaschlik
16.07.2010, 11:10
Oh, ein Missverständis! Ich habe Dich nicht widerlegen wollen, auch keine gangbare Alternative aufzeigen wollen, sondern ich habe Dich lediglich um für mich interessante Aspekte ergänzt.

Mir ist schon klar, dass sowas nicht möglich ist und den Gedanken der Kompression ad absurdum führen würde ("Perpetuum Mobile der Informatik").



P.s.: Der Hinweis auf den ganzen Text statt Datenwörtern bezog sich auf den Beitrag, auf welchen auch Du Dich bezogen hast. War wohl etwas redundant von mir ;)