Welchen Archivtyp verwendet ihr?
-
Wieso einfach nicht die Platte bzw. Verzeichnisse inkl. dessen Inhalt komprimieren? Das erspart eventuelle Entpackungsarbeit. Ebenso wenn Du dann die Daten auf einen Anderen PC schiebst.
-
Weil manche meiner Daten Verluste bei der Komprimierung erleiden können. Mir wäre eine nicht verlustbehaftete Archivierung lieber. Außerdem kann man ein Archiv mal eben von A nach B verschieben, kein Problem - aber das gleiche kann bei mehreren tausend Dateien schon was dauern.
Rar ist nicht portabel? Wäre mir neu - ich habe auf der Maschine sowohl Rar als auf Zip druff.
-
Der aus dem Westen ... schrieb:
Weil manche meiner Daten Verluste bei der Komprimierung erleiden können. Mir wäre eine nicht verlustbehaftete Archivierung lieber. Außerdem kann man ein Archiv mal eben von A nach B verschieben, kein Problem - aber das gleiche kann bei mehreren tausend Dateien schon was dauern.
Rar ist nicht portabel? Wäre mir neu - ich habe auf der Maschine sowohl Rar als auf Zip druff.
Wieso soll es Datenverlust bei einer Dateisysteminternen Komprimierung geben?
Klar kann man Archivdateien einfach kopieren aber das entpacken ist dann eben doch immer noch Arbeit.
-
provisorisch_anonymous
schrieb:
Wieso soll es Datenverlust bei einer Dateisysteminternen Komprimierung geben?
Klar kann man Archivdateien einfach kopieren aber das entpacken ist dann eben doch immer noch Arbeit.Weil du nicht weißt, um welche Daten es sich handelt, und du daher davon ausgehen musst, dass ich meine guten Gründe dafür habe, nicht über eine gewöhnliche Komprimierung nachzudenken.
-
Der aus dem Westen ... schrieb:
provisorisch_anonymous
schrieb:
Wieso soll es Datenverlust bei einer Dateisysteminternen Komprimierung geben?
Klar kann man Archivdateien einfach kopieren aber das entpacken ist dann eben doch immer noch Arbeit.Weil du nicht weißt, um welche Daten es sich handelt, und du daher davon ausgehen musst, dass ich meine guten Gründe dafür habe, nicht über eine gewöhnliche Komprimierung nachzudenken.
Du hast als Begründung genannt, dass es bei meiner vorgeschlagenen Variante zu Datenverlust käme. So etwas ist mir bei dieser Komprimierungsvariante nicht bekannt. Zumindest nicht bei Linux. Gleiche Risiken, keine Wiederherstellungsmöglichkeit zu haben, mangeln fehlender Indizien, hättest Du dann ebenso auch bei Archivdatei-Komprimierungsarten. Man kann aber so wohl dort als auch bei der anderen Art festlegen, wie viel Wiederherstellungsinformationen gespeichert werden sollen.
-
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:
-
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:
XZ benutzt per default CRC64. Siehe man xz. Dies ist allerdings nur Feherlerkennung, nicht Fehlerkorrektur.
-
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.