Welchen Archivtyp verwendet ihr?



  • Nimm ein Format, das robust gegen Bitfehler ist.

    D.h. nimm nen Hexeditor und suche dir ein Byte aus, danach lasse davon ein oder mehrere Bits kippen und dann prüfe nach, welches der Formate die Datei noch fehlerfrei entpacken kann.

    Wichtig:
    Zum Testen muß vom Dateiinhalt vorher eine Prüfsumme gebildet werden, damit du später vergleichen kannst und du nicht auf falsche positive hereinfällst.

    Zip ist zumindest gegen 1 Bit Fehler robust, das habe ich schon getestet.
    Bei den anderen weiß ich es nicht.



  • .tar.xz ist gerade das beste.

    http://en.wikipedia.org/wiki/Xz

    Nachtrag:
    Der grundlegende Algorithmus ähnelt dem von 7zip.

    - Vor allem besser bei Binärdaten als die alten Algorithmen (rar, zip, gz).
    - Schnelles Entpacken.
    - Packen kann allerdings länger dauern als bei zip und Co.

    2. Nachtrag:
    Als Beispiel mal das Binary von GIMP:

    stephan@eddie:~$ time gzip -c gimp > gimp.gz
    
    real	0m0.473s
    user	0m0.468s
    sys	0m0.008s
    stephan@eddie:~$ time bzip2 -c gimp > gimp.bz2
    
    real	0m0.777s
    user	0m0.752s
    sys	0m0.020s
    stephan@eddie:~$ time xz -c gimp > gimp.xz
    
    real	0m3.639s
    user	0m3.580s
    sys	0m0.052s
    stephan@eddie:~$ ls -l gimp*
    -rwxr-xr-x 1 stephan stephan 4693608 2011-10-23 10:39 gimp
    -rw-rw-r-- 1 stephan stephan 1599487 2011-10-23 10:41 gimp.bz2
    -rw-rw-r-- 1 stephan stephan 1752982 2011-10-23 10:41 gimp.gz
    -rw-rw-r-- 1 stephan stephan 1359416 2011-10-23 10:41 gimp.xz
    


  • earli schrieb:

    Nachtrag:
    Der grundlegende Algorithmus ähnelt dem von 7zip.

    - Vor allem besser bei Binärdaten als die alten Algorithmen (rar, zip, gz).
    - Schnelles Entpacken.
    - Packen kann allerdings länger dauern als bei zip und Co.

    Scheint wohl zu stimmen - mit tar.xz wird das Ganze anscheinend verlustfrei archiviert und auf 50% zurechtgestutzt. Ein 102 Megabyte-Paket wird so auf 50 MB gebracht. Und das bequeme ist: tar unterstützt die Option --xz zum direkten Erstellen solcher Dateien.

    Mal sehen, wie sich die anderen Brocken schlagen werden ... 😃



  • Der aus dem Westen ... schrieb:

    earli schrieb:

    Nachtrag:
    Der grundlegende Algorithmus ähnelt dem von 7zip.

    - Vor allem besser bei Binärdaten als die alten Algorithmen (rar, zip, gz).
    - Schnelles Entpacken.
    - Packen kann allerdings länger dauern als bei zip und Co.

    Scheint wohl zu stimmen - mit tar.xz wird das Ganze anscheinend verlustfrei archiviert und auf 50% zurechtgestutzt. Ein 102 Megabyte-Paket wird so auf 50 MB gebracht. Und das bequeme ist: tar unterstützt die Option --xz zum direkten Erstellen solcher Dateien.

    Mal sehen, wie sich die anderen Brocken schlagen werden ... 😃

    In meinem Test wurd es sogar auf 29 % gedrückt (71 % Ersparnis). Das hängt aber ganz stark von den Daten ab. Ein Executable Binary File hat halt Binärdaten und Textsymbole gemischt. Bei reinem Text wird die Kompression noch stärker sein. Bei einem Video, das schon mit H264 kodiert ist, wird auch .xz nichts rausholen können.

    Beispiel: IRC-Chatlog:

    stephan@eddie:~$ xz -c free.log > free.log.xz
    stephan@eddie:~$ ls -lh free*
    -rw-r--r-- 1 stephan stephan  13M 2011-10-23 11:18 free.log
    -rw-rw-r-- 1 stephan stephan 3.0M 2011-10-23 11:19 free.log.xz
    

    Ergebnis: 24 % (Ersparnis: 76 😵

    Was war dein Testfall?

    Und ja, deshalb denke ich auch, dass xz die beste Wahl wäre: Es ist der neue Standard in der GNU/Linux-Welt. Das heißt, es wird auch in langer Zeit kompatibel bleiben und mit Updates versorgt werden. Viele Projeke sind schon darauf umgestiegen, um ihre Quelltextpakete anzubieten.



  • Bitfehler schrieb:

    Nimm ein Format, das robust gegen Bitfehler ist.

    D.h. nimm nen Hexeditor und suche dir ein Byte aus, danach lasse davon ein oder mehrere Bits kippen und dann prüfe nach, welches der Formate die Datei noch fehlerfrei entpacken kann.

    Wichtig:
    Zum Testen muß vom Dateiinhalt vorher eine Prüfsumme gebildet werden, damit du später vergleichen kannst und du nicht auf falsche positive hereinfällst.

    Zip ist zumindest gegen 1 Bit Fehler robust, das habe ich schon getestet.
    Bei den anderen weiß ich es nicht.

    Wenn du Fehlerkorrectur willst, solltest du lieber auf gut erforschte Error Correction Codes zurück greifen statt auf zufällige Tests mit dem Hexeditor.

    Da hab ich aber leider gerade keinen parat. Google fand folgendes, ich hab aber keine Erfahrung damit:

    http://pypi.python.org/pypi/zfec



  • Der aus dem Westen ... schrieb:

    Mir wäre eine nicht verlustbehaftete Archivierung lieber.

    Komprimierung ist nicht generell verlustbehaftet. Es gibt verlustbehaftete Komprimierung und verlustfreie.



  • earli schrieb:

    .tar.xz ist gerade das beste.

    Was die Kompressionsrate angeht, ist xz ziemlich weit vorne (nicht das beste). Dafür ist die Kompressionszeit aber ziemlich miserabel. Dann würde ich eher bz2 nehmen.

    BTW: Gibts eigentlich keine Fotos von dir online?



  • knivil schrieb:

    Der aus dem Westen ... schrieb:

    Mir wäre eine nicht verlustbehaftete Archivierung lieber.

    Komprimierung ist nicht generell verlustbehaftet. Es gibt verlustbehaftete Komprimierung und verlustfreie.

    Verlustbehaftete Kompression macht doch sowieso nur Sinn bei Daten, die man genau kennt, und wo man weiß, welcher Verlust nicht schmerzt. Zum Beispiel Video- oder Audio-Dateien. Man denke nur mal daran, wie groß die MP3-Sammlung wäre, wenn es nicht komprimiert wäre. Bei Filmen sollte man sich das lieber gar nicht erst vorzustellen versuchen. 🙂



  • Michael E. schrieb:

    earli schrieb:

    .tar.xz ist gerade das beste.

    Was die Kompressionsrate angeht, ist xz ziemlich weit vorne (nicht das beste). Dafür ist die Kompressionszeit aber ziemlich miserabel. Dann würde ich eher bz2 nehmen.

    Wie gesagt: Packen dauert lange. Entpacken geht dafür schnell. Dies ist auch in den meisten Fällen sinnvoll, da in der Regel einer die Datei packt, und dann viele die Datei herunterladen und entpacken.

    Für das persönliche Archiv vielleicht unpraktisch. Eventuell lässt sich an den Optionen von xz was drehen.

    BTW: Gibts eigentlich keine Fotos von dir online?

    Warum willst du das denn wissen?



  • earli schrieb:

    Bitfehler schrieb:

    Nimm ein Format, das robust gegen Bitfehler ist.

    D.h. nimm nen Hexeditor und suche dir ein Byte aus, danach lasse davon ein oder mehrere Bits kippen und dann prüfe nach, welches der Formate die Datei noch fehlerfrei entpacken kann.

    Wichtig:
    Zum Testen muß vom Dateiinhalt vorher eine Prüfsumme gebildet werden, damit du später vergleichen kannst und du nicht auf falsche positive hereinfällst.

    Zip ist zumindest gegen 1 Bit Fehler robust, das habe ich schon getestet.
    Bei den anderen weiß ich es nicht.

    Wenn du Fehlerkorrectur willst, solltest du lieber auf gut erforschte Error Correction Codes zurück greifen statt auf zufällige Tests mit dem Hexeditor.

    Da hab ich aber leider gerade keinen parat. Google fand folgendes, ich hab aber keine Erfahrung damit:

    http://pypi.python.org/pypi/zfec

    XZ benutzt per default CRC64. Siehe man xz. Dies ist allerdings nur Feherlerkennung, nicht Fehlerkorrektur.

    http://en.wikipedia.org/wiki/Crc64



  • http://rollingrelease.com/system/2010/12/archive-testing

    -> Die Wahl für hohe Kompressionsraten liegt bei den getesteten Methoden bei xz oder 7Zip + LZMA2. 7Zip hat aber auch noch einen PPMd-Algorithmus zu bieten, der bei mir avi-Filme besser komprimiert hat (wenn auch das Packen sehr langsam war, das Entpacken dafür schnell). Ansonsten kann ich dazu aber nicht viel sagen.

    EDIT: Ich habe gerade gesehen, dass PPMd nur Single-Core-Support hat...



  • wxSkip schrieb:

    EDIT: Ich habe gerade gesehen, dass PPMd nur Single-Core-Support hat...

    xz scheint auch noch ohne Multithreading-Support zu sein. Bei einem Multicore-System lohnt es sich also vielleicht, mehrere Packvorgänge parallel zu starten.



  • earli schrieb:

    Was war dein Testfall?

    Zirka 1.000 JPEG- und PNG-Dateien. Da kommt aber noch viel mehr zusammen, wenn ich nicht nur den Ordner, sondern alles mit hinzurechne.

    knivil schrieb:

    Komprimierung ist nicht generell verlustbehaftet. Es gibt verlustbehaftete Komprimierung und verlustfreie.

    Ist mir auch klar (sonst könnte ich mich kaum einen Programmierer schimpfen). Allerdings sind da nicht nur Bilder, sondern auch noch andere Sachen bei (darunter auch einiges an Audio- und Videodateien, auch ein Werbevideo meiner Firma mit ziemlich hoher Qualität), und hier wäre ein Qualitätsverlust ... sagen wir mal, mein Kopf würde auch mit plastischer Chirurgie nie mehr auf den Körper passen.

    earli schrieb:

    BTW: Gibts eigentlich keine Fotos von dir online?

    Ich vermute, wenn du keine von ihm findest, wird das seine Gründe haben ... verdammt, mein Onkel hatte recht. Facebook gewöhnt uns daran, die Informationen anderer sofort abrufen zu wollen.



  • Der aus dem Westen ... schrieb:

    knivil schrieb:

    Komprimierung ist nicht generell verlustbehaftet. Es gibt verlustbehaftete Komprimierung und verlustfreie.

    Ist mir auch klar (sonst könnte ich mich kaum einen Programmierer schimpfen). Allerdings sind da nicht nur Bilder, sondern auch noch andere Sachen bei (darunter auch einiges an Audio- und Videodateien, auch ein Werbevideo meiner Firma mit ziemlich hoher Qualität), und hier wäre ein Qualitätsverlust ... sagen wir mal, mein Kopf würde auch mit plastischer Chirurgie nie mehr auf den Körper passen.

    Noch mal: Es kann nur dann verlustbehaftet komprimiert werden, wenn bekannt ist, was die Verluste für Auswirkungen haben. Eine Zip-Datei kannst du z.B. nicht verlustbehaftet komprimieren, weil bei einer Veränderung in der Bibliothek die Datei plötzlich inkorrekt würde. Verlustbehaftet sind nur Kompressionen für bestimmte Formate wie Video und Audio und da auch nicht alles. Allgemeine Kompressionen sind nie verlustbehaftet. Wenn es dir nur um eventuelle Übertragungsfehler geht, kann ich dir nicht weiterhelfen.
    Kannst du uns ungefähr sagen, um was für Dateien es sich handelt (natürlich prozentual von der Größe her)? Text? Bilder? Videos? Archive? Binaries?



  • Meistens .zip, da es unter den meisten Plattformen funktioniert. .rar steht auf meiner Hass-Format Liste ganz oben, weil es unter Mac OS nicht von Haus aus unterstützt wird. 👎



  • wxSkip schrieb:

    Noch mal: Es kann nur dann verlustbehaftet komprimiert werden, wenn bekannt ist, was die Verluste für Auswirkungen haben. Eine Zip-Datei kannst du z.B. nicht verlustbehaftet komprimieren, weil bei einer Veränderung in der Bibliothek die Datei plötzlich inkorrekt würde. Verlustbehaftet sind nur Kompressionen für bestimmte Formate wie Video und Audio und da auch nicht alles. Allgemeine Kompressionen sind nie verlustbehaftet. Wenn es dir nur um eventuelle Übertragungsfehler geht, kann ich dir nicht weiterhelfen.

    Gut zu wissen. Und wieder was gelernt. 😉

    wxSkip schrieb:

    Kannst du uns ungefähr sagen, um was für Dateien es sich handelt (natürlich prozentual von der Größe her)? Text? Bilder? Videos? Archive? Binaries?

    Zu viel, würde ich meinen. Ein paar CD-Images, ein Haufen Windows- und Linux-Executables, ein paar zehntausend Bilder, etliche Skripte, noch mehr Texte (reine Textdateien ohne Formatierung, meistens mit gedit, notepad oder vim geschrieben), ein paar Treiber, noch ein paar Videos, etliche Audiodateien (von denen ich bewusst weiß - zum Sortieren komme ich derzeit einfach nicht, wird man an meiner Abwesenheit im Forum unter der Woche gemerkt haben) ... zum Teil richtig wichtiges Zeugs eben, und das blockiert meine Partitionen. Wenn's nur Logging-Dateien oder SQL-Datenbanken wären, die kann man relativ leicht verlustfrei komprimieren, soweit ich weiß (78% Deflation) ... würde insgesamt 100 GB machen.

    @PI: Selber schuld, wenn du Macs verwendest. 😃



  • 314159265358979 schrieb:

    .rar steht auf meiner Hass-Format Liste ganz oben, weil es unter Mac OS nicht von Haus aus unterstützt wird.

    Nicht nur das: Das rar-Programm unter meinem Ubuntu ("RAR 4.00 beta 3") ist kaputt, sobald es UTF8-Dateinamen oder -Ordnernamen zu sehen bekommt, die asiatische Zeichen enthalten. Dann passieren so lustige Dinge wie, manche Ordner werden ins Archiv gepackt, andere werden stillschweigend ausgelassen.

    Für Kompatibilität dürfte unter Linux-Systemen wohl wirklich tar das sicherste Format sein. Wenn es komprimiert wird, wird es natürlich ein bisschen inkompatibler, aber tar.gz, etc. sollten auch noch gehen.

    Verlustfrei komprimierbare Daten haben aber oft auch die Eigenschaft, dass sie unkomprimiert nur wenige Gigabyte in Anspruch nehmen. Das, was tausende Gigabytes oder mehr in Anspruch nimmt, sind bei einem Privatanwender wohl meistens Fotos und Filme, nehme ich an, da erübrigt sich verlustfreie Komprimierung sowieso.

    Mein Rat wär daher für kleines Geld eine 2TB-Platte zu kaufen und nicht weiter über verlustfreie Komprimierung nachzudenken. Ob ein Ordner nun 10GB oder 2GB belegt, ist bei genügend großer Festplatte gar nicht mehr so wichtig.

    Was Komprimierung (bzw. Archivierung) reduzieren kann, ist aber die Dateianzahl. Das kann durchaus relevant sein, wenn du z.B. einen Ordner mit 100000 Dateien oder mehr hast, die sich nie ändern. Wenn du den ganzen Ordner durch ein äquivalentes tar-Archiv ersetzt, ist das fürs Dateisystem viel schonender und beim Kopieren auch viel effizienter.

    edit: Was ich noch erwähnen wollte, war squashfs. Der gewaltige Vorteil daran ist, dass man das Archiv mounten kann und der Zugriff auf einzelne Dateien nur sehr wenig langsamer ist als unkomprimiert. Außerdem komprimiert squashfs multithreaded, es profitiert also von aktuellen CPUs. squashfs ist im offiziellen Linux-Kernel enthalten, insofern sollte die Kompatibilität einigermaßen sichergestellt sein. Allerdings wurde die Kompatibilität bisher bei größeren Versionssprüngen wohl nicht aufrecht erhalten, deswegen ist mir bisher squashfs als Archiv zu riskant.



  • Der aus dem Westen ... schrieb:

    earli schrieb:

    BTW: Gibts eigentlich keine Fotos von dir online?

    Ich vermute, wenn du keine von ihm findest, wird das seine Gründe haben ... verdammt, mein Onkel hatte recht. Facebook gewöhnt uns daran, die Informationen anderer sofort abrufen zu wollen.

    Ich sag mal so, natürlich gibt es Fotos von mir. Aber die findet man nicht, wenn man meinen bürgerlichen Namen nicht kennt.



  • bitte löschen (diesen Beitrag)



  • Christoph schrieb:

    Für Kompatibilität dürfte unter Linux-Systemen wohl wirklich tar das sicherste Format sein. Wenn es komprimiert wird, wird es natürlich ein bisschen inkompatibler, aber tar.gz, etc. sollten auch noch gehen.

    tar macht ja auch nichts anderes, als Dateien aneinander hängen und zwischendurch ein paar Metadaten. So, wie man das früher auf ein Magnetband gemacht hat. tar steht ja für Tape ARchiver.

    Verlustfrei komprimierbare Daten haben aber oft auch die Eigenschaft, dass sie unkomprimiert nur wenige Gigabyte in Anspruch nehmen. Das, was tausende Gigabytes oder mehr in Anspruch nimmt, sind bei einem Privatanwender wohl meistens Fotos und Filme, nehme ich an, da erübrigt sich verlustfreie Komprimierung sowieso.

    Nein, deine Fotos und Videos sind zum Glück schon verlustbehaftet komprimiert. Sonst wären sie noch viel größer.

    Ein einziges Foto von 4000x3000 Pixeln (24 Bit Farbe) wäre sonst 34,3 Gigabyte groß.

    Eine Stunde HD-Video mit 1080p (24 Bit Farbe, 25 Bilder pro Sekunde) wäre 521,4 Terabyte groß.


Anmelden zum Antworten