Datenkompression-Formate

    Zitat von slut-hunter

    Und für einen Test kann man sich ja das neue drauftun, ist ja nicht so das dann die alte nicht mehr funzt.

    Probiere ich dann vielleicht bei Quake aus, vorerst warten wir auf LigHs Ergebnis.

    PAQ hab ich weggelassen - Komprimierer, die nicht in der Lage sind, Verzeichnisstrukturen zu verarbeiten, sind für mich nicht alltagstauglich. Umgehen könnte man das über den alten Unix-Trick mit ".tar.z / .tar.gz / .tar.bz2" (erst mal ein unkomprimiertes Archiv, dann die Archivdatei komprimieren).
    __

    Noch wird hier mit mehreren Methoden gepackt und verglichen. Aber es müsste "noch heute" ein PDF kommen, in dem man gut vergleichen kann, welcher Packer welchen Typ von Daten mehr oder weniger gut beherrscht.

    Ebenfalls war für mich interessant, wie gut der Gewinn beim "Solid-Komprimieren" war, wenn der Packer das beherrscht. Sehr merkwürdig dabei: Bei einigen Packern gab es sogar Verschlechterungen. Vielleicht weil die eine Art von Daten das Wörterbuch bereits mit für folgende Dateien unbrauchbaren Daten gefüllt hatte.
    __

    @ matthiasb:

    Quake komprimieren - wie schon gesagt: Die *.pak-Dateien sind schon PKZIP-komprimiert. Komprimierte Archive noch mal zu komprimieren macht keinen Sinn, weil der vorherige Komprimierer vielleicht nicht optimal gearbeitet hat, und eventuell solche Strukturen dadurch zerstört, die der andere Komprimierer besser erkannt hätte.
    __

    Also, bis später...

    Zitat von LigH

    PAQ hab ich weggelassen - Komprimierer, die nicht in der Lage sind, Verzeichnisstrukturen zu verarbeiten, sind für mich nicht alltagstauglich.

    Habe gerade bemerkt, dass er relative Pfade doch beherrscht, nur erstellt er die passenden Ordner beim enpacken nicht. :nein:

    Selbst mit BuntGUI wäre der Kompressor nicht alltagstauglich, schon gemerkt wie lahm der ist wenn er gute Leistung erzielen soll? :ani_lol:

    Na, es gibt noch einige Packer mehr, die ziemlich lange brauchen können, wenn man sie entsprechend einstellt. Das kann unter Umständen auch daran liegen, dass sie dann zum Komprimieren so viel Zwischenspeicher brauchen, bis sie selbst die Auslagerungsdatei noch mit benutzen müssen - und das wird dann tödlich.

    Hier ein paar Beispiele für Kommandozeilen-Optionen (sortiert, beste Kompression zuletzt):

    ... (^ noch schlechtere, und Details: Siehe PDF im Anhang)
    HA 0.999ß: a012r
    UC 2.37ß: A -S -TST
    7zip 4.23 (BZip2): a -t7z -r -mx=9 -m0=BZip2
    IMP 1.12: a -1 -m3 -mm -r -s65536k -u256
    7zip 4.23 (PPMd): a -t7z -r -mx=9 -m0=PPMd:mem=27
    CABARC 1.00.0601: -m LZX:21 -r n
    UHArc 0.6a (LZP): a -r+ -ed- -pr -mz -mm+ -md+ -md32768 -b32768
    7zip 4.23 (LZMA): a -t7z -r -mx=9 -m0=LZMA:a2:d24
    ARHANGEL 1.40: a -r -mt -mz -1 -2 -mm -mp63 -c31900 -l31900
    WinAce 2.6b5: a -s -d4096 -m5 -r
    WinRAR 3.42 a: -m5 -mdg -r -rr-
    UHArc 0.6a (ALZ-3): a -r+ -ed- -pr -m3 -mm+ -md+ -md32768 -b32768
    SBC 0.97: c -m3 -r
    UHArc 0.6a (PPM): a -r+ -ed- -pr -mx -mm+ -md+ -md32768 -b32768

    Ich habe darauf geachtet, dass der Kompressionsspeicher nicht größer als 1/2 - 2/3 des Arbeitsspeichers wurde; bei mir sind das ja leider bloß gerade mal 256 MB... (was red ich da, "640 KB sollten für jeden genug sein" {B.G.})

    Wow! :eek:
    Was fürn Rechner hast Du bitte? Meiner bräuchte einen Monat dazu. :lol:
    Die meisten Packer kenn ich nicht einmal (oberes Feld).

    Ist super, danke. Wenn ich mal was bestimmtes komprimiere kann ich nachschlagen anstatt alle Packer durchzuprobieren.

    Bitte? Ich werde mit meinem Duron-800 doch wohl ein paar Mal je 50 MB packen können. Insbesondere, wenn das bei den meisten Uralt-Programmen (PAK, ARC, ARJ, SQZ, HYPER - die meisten können noch nicht mal lange Dateinamen) gerade mal Minütchen dauert. Und mit einer FOR-Schleife schafft der hintereinander mehrere Verzeichnisse automatisch.

    Zitat von HQ-LQ

    naja relative pfade wäre nicht schlecht...

    lassen sich die commands auch mit platzhalter nutzen?
    z.B.: "%1" , für meine *.bat-drop-cmd's

    würde z.B.: das gehen?:

    Sorry, hq-lq den Post hätt ich fast überlesen! :redface:

    Das %1 wird zum absoluten Pfad, wieder nichts für PAQ, leider...

    So, das Dokument wurde noch mal überarbeitet (hatte bei WinAce vergessen, Recovery-Records auszuschalten).
    __

    Und noch ein zusätzlicher Test:

    - Alle compilierten Units (*.dcu) der Jedi Libraries (JCL + JVCL): 31,8 MB ausführbarer Code
    - Alle Quelltexte selbiger Units (*.pas): 35,8 MB Object-Pascal-Quelltexte
    - "Gigi d'Agostino: Bla Bla Bla" von der Maxi-CD in 4 Varianten (mono/stereo, 8/16 bit): 74,3 MB WAVs
    - Je Bild 1 und 111 aus den 10 VQEG-PAL-Clips als unkomprimierte 24-bit-Bilder: 23,8 MB TGAs

    Code und Texte werden normalerweise vor allem von Algorithmen gut komprimiert, die in der Lage sind, die Wahrscheinlichkeit von Zeichen einer "Sprache" zu modellieren, auch abhängige Wahrscheinlichkeiten (nicht nur "wie oft im Text", sondern auch "wie oft nach anderen Zeichen") - da schlägt PPM oft jede LZ-Variante. Ebenfalls sehr effizient dafür: Die Burrows-Wheeler-Transformation, Basis von BZip2.

    Bei TGA und WAV dagegen ist vor allem wichtig, wie gut ein Packer erkennt, dass es sich um Multimedia-Daten handelt, wie groß die Wortgröße der Samples ist, wie viele Kanäle es gibt... - und dann natürlich, welche Art von Komprimierung und welche Daten-Vorbearbeitung sich lohnt; meist sind hier Differenzen (Delta-Komprimierung) und Vorhersagen nützlich. Ich denke, es ist klar zu sehen: Ein Programm, das keine Multimedia-Analyse beherrscht (z.B. 7-zip), versagt im Vergleich zu anderen Packern trotz Verwendung komplexer Algorithmen und großem Pufferspeicher.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden