PerfectCompress - inkl. PAQ8

[Sentionline]

Home (http://moises-studios.110mb.com/perfectcompress/index.html)
Download (http://moises-studios.110mb.com/perfectcompress/downloads/default.html)
PerfectCompress Screenshots (http://www.softpedia.com/progScreenshots/PerfectCompress-Screenshot-153981.html)

Das PAQ8 Format erreicht immer die maximalste Kompressionsrate (http://www.squeezechart.com/main.html) und ist sogar stärker als WinRK oder UHARC. Per Kommandozeile sind die PAQ8 Versionen nicht leicht zu bedienen, aber per PerfectCompress ist die Bedienung ein Kinderspiel. Das interface ist sehr einfach zu handhaben.

http://www.abload.de/thumb/1k8fd.png (http://www.abload.de/image.php?img=1k8fd.png) http://www.abload.de/thumb/2fkf5.png (http://www.abload.de/image.php?img=2fkf5.png) http://www.abload.de/thumb/3svpt.png (http://www.abload.de/image.php?img=3svpt.png)

Testet es aus und seid gewarnt, das eine PAQ8 Kompression recht lange dauert.

mfg

[(del)]

Das hatten wir schon einige Male. Schöne Technologiestudie, aber PAQ ist einfach nicht wirklich "wirtschaftlich".

[Rooter]

Das hatten wir schon einige Male. Schöne Technologiestudie, aber PAQ ist einfach nicht wirklich "wirtschaftlich".So ist es. Einfach nicht praxistauglich weil es viel zu lange braucht.
Was das angeht sieht dieses NanoZip aber interessant aus... :|

MfG
Rooter

[_DrillSarge]I[]

kann man auch gleich peazip (http://peazip.sourceforge.net/) nehmen. das hat auch noch ne gescheite oberfläche+manager.

[(del)]

Oberfläche? :| Da brauch ich nur einen gescheiten Dialog beim Packen. Plugin für TotalCommander ist vielleicht wichtig. Sonst nichts ;)

[Sentionline]

PAQ8 sollte man ansprechen, wenns um Daten geht, die man längere Zeit nicht braucht und einlagern möchte. Aber möglichst platzsparend in der Ecke der Festplatte oder auf einem Rohling.

In Zeiten Superprozessoren, wo wir definitiv angekommen sind und Arbeitsspeicher kein Thema mehr ist, finde ich schon, das PAQ8 so langsam Thema werden sollte.

mfg

[huha]

In Zeiten von obszön großen und günstigen Festplatten, in denen wir langsam angekommen sind, finde ich durchaus, daß so unpraktikables Zeug wie PAQ8 immer mehr seine Daseinsberechtigung verliert.

-huha

[Sentionline]

Du meinst Verschwendung, je mehr man hat.

Kenn ich...

Microsoft, Hilton, USA.

[(del)]

In Zeiten Superprozessoren, wo wir definitiv angekommen sind und Arbeitsspeicher kein Thema mehr ist, finde ich schon, das PAQ8 so langsam Thema werden sollte.Packen ist eine Sache. Wenn ich aber es dann brauche und dadrin rumwühlen muß und der Packer nicht nur arschlahm ist, sondern auch nahezu symetrisch arbeitet (Zeit packen vs. Zeit entpacken), dann ist das eher witzlos, weil es mich meine Lebens-zeit kostet. Das will ich am meisten "einsparen".

Davon ab haut einen die Rate real live doch nicht so wirklich vom Hocker. Real live ist das was man zusammenpacken will zum einen beachtlichen Teil schon als Format vorgepackt. Egal ob Dokumente (doc(-x), pdf, odt, pps usw.) Bilder (tif, png jpeg), Mucke (mp3, flac), Filme (avchd, mp4, flv, mkv, vob usw.)
So sind die Fälle wo das nenneswert reinhaut eher ausnahmen.

Und das ist natürlich ein absolutes NoGo :uup:
"The problem with PAQ, RZM, CSC, and CCM is that when a file is compressed with a version of those compressors, only the compressor used for compression can be used for extraction."

Ich hab mit dem Zählen der enthaltenen PAQs bei 77 aufgehört. Ja nö, ist klar.

[san.salvador]

Du meinst Verschwendung, je mehr man hat.

Kenn ich...

Microsoft, Hilton, USA.
Vielleicht kaufen manche auch große Platten, damit sie sich genau diese Komprimiererei sparen.

[Rooter]

@ BH:
*fullACK!* (selten genug dass das vorkommt ;))

Vielleicht kaufen manche auch große Platten, damit sie sich genau diese Komprimiererei sparen.Komprimieren ist ja schön und gut, ich bin auch ein Fan davon. Aber dann bitte mit guter Effizienz (http://www.maximumcompression.com/data/summary_mf2.php)!

Ich hoffe wenn M$ mal ein neues Dateisystem bringt wird dessen Kompression zumindest auf gutem ZIP-Niveau sein. Aber für das Meiste was wir auf unseren Datenpartitionen sammeln bringt es eh so wenig dass es sich nicht lohnt zu komprimieren. Bei .txt, .html und einigen Sonderfällen (bei Savegames habe ich teils erstaunliche Ergebnisse erzielt) macht es aber Sinn, bei der Systempartition u.U. auch.

MfG
Rooter

[(del)]

Kann man diesen "test set" irgendwo saugen?

edit:
(mein Fehler :ulol:)

[_DrillSarge]I[]

zumal der refernezkompressor (hat überhaupt mal jemand einen eigenen dazu geschrieben???) bei paq8 nur einen cpu-kern nutzt :freak: (bei paq besonders toll).

[(del)]

Was man nicht vergeßen sollte ist auch die Zuverlässigkeit -> Integrität und die Interoperabilität (Boah eh. Sorry :smile:)

freearc ist schon brutal schnell und merkbar besser als 7-zip, ich würde es aber einfach so nicht benutzen, wenn das nicht milionenfach in the wild getestet und testet wird. Eine effiziente Packroutine ist ja nicht alles.

Davon ab brauch ich meistens etwas was auch andere entpacken könnten. Da sich 7-zip, Winrar und Winzip ab Werk aber gegenseitig verstehen ist alles andere erstmal leider nur ein Experiment.

Freearc erschlägt einen auch gleich mit Optionen die man genausogut in der hintersten Ecke unter Expert platzieren könnte. Wenn man die Leute gleich verschreckt oder nur für Freaks Software baut muß man mit entsprechender Verbreitung rechnen...

Eigentlich schade. Das ist bis jetzt die einzige Soft die 7-zip als Programm mal ausstechen könnte. Die, und nicht die PAQs. PAQs sind Technologiestudien.

[ESAD]

Ich hoffe wenn M$ mal ein neues Dateisystem bringt wird dessen Kompression zumindest auf gutem ZIP-Niveau sein. Aber für das Meiste was wir auf unseren Datenpartitionen sammeln bringt es eh so wenig dass es sich nicht lohnt zu komprimieren. Bei .txt, .html und einigen Sonderfällen (bei Savegames habe ich teils erstaunliche Ergebnisse erzielt) macht es aber Sinn, bei der Systempartition u.U. auch.


die kompression die ms einsetzt ist zip.

[san.salvador]

die kompression die ms einsetzt ist zip.
... und bringt je nach Inhalt auch wirklich anständige Platzeinsparungen. Und beschleunigt die Lesezugriffe nebenbei. :)

[Sentionline]

I[;8192420']zumal der refernezkompressor (hat überhaupt mal jemand einen eigenen dazu geschrieben???) bei paq8 nur einen cpu-kern nutzt :freak: (bei paq besonders toll).
Jo, das ist mir leider auch ein Dorn im Auge. Ich hoffe da tut sich in Zukunft mal was. Wenn wenigstens 4 Threads unterstützt werden würden, wäre das richtig Cool und "rentabel".

Ich beobachte die Entwicklung von ZPAQ im mom. Scheint die einzig wirklich brauchbare lösung mit Abwärtskompatibilität zu sein. Leider gehts nur sehr schleppend voran und 7-Zip steckt auch irgendwie mit seinem Algoritmus in einer Schleife. In Zeiten von Monsterrechnern müsste die Entwicklung neuer Verfahren und Optimierung eigendlich schneller gehen.

mfg

[san.salvador]

Auf der anderen Seite hemmt die mögliche Bandbreite und der unendliche Speicherplatz die Entwicklung.

[Sentionline]

Das glaub ich auch. SSE2/3/4, 64Bit, MultiCore/MultiThread, GPGPU etc. Scheint eine Flut neuer möglichkeiten zu sein. Ich wäre auch überfordert was ich zuerst angehen soll. :freak:

Wobei man 7Zip loben kann das es wenigstens 64Bit unterstützt. Bringt aber gar nichts an Kompressionsraten. Ich merke nur mehr Arbeitsspeicherverbrauch. Fortschrittlich :freak:

ZPAQ mit Cuda unterstützung würde schonmal eine Revolution auslösen und alles in den Schatten stellen. Ich weiss; "wovon träume ich Nachts?".

[ESAD]

... und bringt je nach Inhalt auch wirklich anständige Platzeinsparungen. Und beschleunigt die Lesezugriffe nebenbei. :)

es fragmentiert grauenhaft die daten. da die blöcke zusammengefasst werden und dann dazwischen immer "leeraum" bleibt. ohne defragmentierung bricht die leserate/schreib rate ein wenn was in den zwischenräumen abgelegt wird. prinzipiell allerdings echt eine gute idee. defragmentieren muss man hald.

[(del)]

Wobei man 7Zip loben kann das es wenigstens 64Bit unterstützt. Bringt aber gar nichts an Kompressionsraten. Ich merke nur mehr Arbeitsspeicherverbrauch.Nein. 7-zip ist einer dieser Programme die merkbar schneller unter 64bit laufen. Falls das Medium nicht limitiert.

[Sentionline]

An Geschwindigkeit mangelt es 7Zip nicht. Es muss eben besser Komprimieren. Und es unterstützt nach zig tausend Updates immernoch kein Verfahren Ordner in seperate Archive zu Packen. So schwer kann weiterentwicklung doch nicht sein...:usad:

Alle Kompress Programme sind irgendwie festgefressen seid Jahren. Ausser die Themes, Kiddiekram scheint kein Problem. Ein Dillema.

[(del)]

An Geschwindigkeit mangelt es 7Zip nicht.Naja. Ich hab bei freearc schon kurz gestutzt. Das 10% bessere Ratio erreicht es hier locker und ist auch mind. 40% schneller dabei. http://www.freearc.org/Benchmarks.aspx
Auch wenn man viel davon Pavlov verdanken kann. Nur,
Und es unterstützt nach zig tausend Updates immernoch kein Verfahren Ordner in seperate Archive zu Packen. So schwer kann weiterentwicklung doch nicht sein...:usad:Pavlov macht auf mich zum Teil so einen Eindruck aka Perelman....

Zu deinem Vorschlag frag ich mich erst noch, ob man sowas nicht mit einem Script machen könnte (?) Pavlov ist eh nicht als allgemeiner Genie anzusehen. Er hat und hatte z.B. immer sehr große Mühen mit der GUI =) Dafür wird jedes Bit am LZMA2 10x gedreht und das Problem des Multithreadings beschäftigt ihn mehr als alles andere.

Alle Kompress Programme sind irgendwie festgefressen seid Jahren.Wenn du nicht alleine hinter dem Ratio her bist, wie die PAQs, sondern hinter einer annehmbaren Bilanz aus Ratio und Zeit, stößt du irgendwannmal an Byte/Mhz-Grenzen die sich nicht mehr merkbar weiter überwinden lassen.

Pavlov finde ich als Endanwender nur eben recht unfelxibel. LZMA(2) ist sein Baby und viel mehr existiert nicht für ihn. Das geht mehr so in Richtung Forschung, hat aber im Gegensatz zum PAQ ein massenkompatibles Ergebnis. Ziganshin (freearc) holt sich dagegen das beste aus allen open source Welten und optimiert das Mixen dieser Verfahren.

Ich weiß nicht warum es noch nicht so wirklich aufschlägt :usad:

[Sentionline]

Naja. Ich hab bei freearc schon kurz gestutzt. Das 10% besseres Ratio erreicht es hier locker und ist auch mind. 40% schneller.
Werd ich mir anschauen.

Zu deinem Vorschlag frag ich mich erst noch, ob man sowas nicht mit einem Script machen könnte (?)
Das soll per Commandozeile gehen. Sehr komfortabel. Weiss aber nix gebaues darüber. Eine Checkbox mit dem Kommando dahinter, darauf warte ich seid...mom...8 Jahren. Ich hab 2002 mit 7Zip gestartet und WinRAR aufgegeben. Nach etlichen vergleichen (die ich auch hier im Forum Postete) kam ich zu dem Ergebnis das 7Zip besser packt. Ja, ich kann Ordner verwalten, aber immer jeden Ordner einzeln Packen?

Das kann man doch ganz leicht. 7Zip unterstützt Multithreading, größte Hürde überwunden. Ich markiere 25 Ordner und jeder Ordner wird in einem eigenen Archiv gepackt und für jeden Ordner steht eine CPU zur verfügung. Aber wie gesagt, seid 8 Jahren mach ich das immernoch einzeln und ich warte immernoch (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7075005#post7075005).

Wenn du nicht alleine hinter dem Ratio her bist, wie die PAQs, sondern hinter einer annehmbaren Bilanz aus Ratio und Zeit, stößt du irgendwannmal an Byte/Mhz-Grenzen die sich nicht mehr merkbar weiter überwinden lassen.
Aus diesem Grund braucht PAQ Multithreading. Ich weiss, ist nicht leicht einzubauen so eine Thread aufteilung, deshalb warte ich noch.

mfg

[(del)]

Werd ich mir anschauen.Mit Defaults, wohlgemerkt.

Ich denke das hat Probs sich durchzusetzen, weil 7-zip trotz allem eine viel angenehmere GUI hat (Die Abneigung Pavlos demgegenüber, gepaart mit seinem Verständnis für Benutzbarkeit und der Anlehnung an Winrar, resultiert lustigerweise in einem sehr brauchbaren user interface) und eben daraus, daß #9 wohl gilt.

Technisch gesehen, wenn man die Zeiten in die Bilanz miteinbezieht, ist FreeArc das fortschrittlichste was es momentan gibt. Ich bin aber auch davon überzeugt, daß man viel mehr als die +10% gegenüber 7-zip (die Packzeiten nicht vergeßen) ohne ganz neue mathematische Forschungsergebnisse nicht erreichen kann.

Bis dann mal.

p.s.:
3DC nützt hier nichts. Das ist die korrekte Adresse ;) Hier habe ich z.B. verhindert, daß LZMA mit einem rechtlich schlechten Vertrag an Winzip abgegeben wurde :tongue:
http://sourceforge.net/projects/sevenzip/forums/forum/45797

[Rooter]

die kompression die ms einsetzt ist zip.Quelle? :|

Habe hier eine Textdatei von 955 KB:
Mit der NTFS-Kompression sind es noch 492 KB
Als ZIP-Archiv sind es 246 KB!
Die Blockgröße dürfte wohl in beiden Fällen bei 4 KB liegen. Wie ist der gewaltige Unterschied (nur halb so groß!) also erklärbar?

es fragmentiert grauenhaft die daten. da die blöcke zusammengefasst werden und dann dazwischen immer "leeraum" bleibt.Das stimmt. Als besonders verheerendes Beispiel wurden hier schon mal die Temp-Datein von Filesharingprogrammen genannt die ja erst leer erstellt werden und dann Stück für Stück mit schlecht komprimierbaren Daten gefüllt werden.

An Geschwindigkeit mangelt es 7Zip nicht. Es muss eben besser Komprimieren.Multimedia-Präprozessor ftw! Das anpassen des Algorithmus an die zu komprimierenden Daten ist der einzige Grund warum RAR mit seiner lächerlichen 4 MB Wörterbuchgröße noch immer konkurrenzfähig ist.

Alle Kompress Programme sind irgendwie festgefressen seid Jahren. Ausser die Themes, Kiddiekram scheint kein Problem. Ein Dillema.Außer bei Pavlow. :D

MfG
Rooter

[(del)]

Quelle? :|

Habe hier eine Textdatei von 955 KB:
Mit der NTFS-Kompression sind es noch 492 KB
Als ZIP-Archiv sind es 246 KB!
Die Blockgröße dürfte wohl in beiden Fällen bei 4 KB liegen. Wie ist der gewaltige Unterschied (nur halb so groß!) also erklärbar?Hast du das mit 9, 6 oder 1 komprimiert? :freak:

[Rooter]

Hast du das mit 9, 6 oder 1 komprimiert? :freak:Natürlich 9! :D
Stimmt, das wird die Erklärung sein. Ob die Datei unter Win7 wohl kleiner würde als unter XP? Denn auf den PCs, auf denen das eingesetzt wird, dürfte wohl genügend CPU-Zeit für 9 vorhanden sein...

MfG
Rooter