7z vs ZIP vs rar

[=Floi=]

Hallo
warum kann nur 7zip gleiche teile erkennen (z.B. in einem word dokument) und diese dann nur 1x in das archiv integrieren? Es wird immer zip oder rar als sehr gut/perfekt hingestellt, aber die können ja nicht einmal so eine simple sache? Warum sind im allgemeinen vergleich diese zwei kostenpflichtigen programme so unterlegen?
Ein andere argument ist ja auch oft, dass die kostenpflichtigen programme besser sind, aber hier ist es ja doppelt peinlich.

[Mr.Magic]

warum kann nur 7zip gleiche teile erkennen (z.B. in einem word dokument) und diese dann nur 1x in das archiv integrieren?

Weil 7zip entsprechend lahmarschig ist, wenn man die Kompressionsrate hochschraubt?!

[Corny]

Hallo
warum kann nur 7zip gleiche teile erkennen (z.B. in einem word dokument) und diese dann nur 1x in das archiv integrieren? Es wird immer zip oder rar als sehr gut/perfekt hingestellt, aber die können ja nicht einmal so eine simple sache? Warum sind im allgemeinen vergleich diese zwei kostenpflichtigen programme so unterlegen?
Ein andere argument ist ja auch oft, dass die kostenpflichtigen programme besser sind, aber hier ist es ja doppelt peinlich.

WinRar kann das doch. Einfach die Option "solides Archiv erstellen" auswählen.

[=Floi=]

warum ist das nicht standardmäßig an? was wird da anderst gemacht?
unter dem begriff verstehe ich etwas anderes.

[pest]

solid archiving erziehlt den selben effekt über mehrere dateien hinweg
also z.B. mehrere versionen eines dokumentes

innerhalb eines dokumentes liegt es an entsprechenden filtern wie gut
sowas erkannt wird, aber poste mal die beispieldatei, dann kann ich mal meine eigenen packer drüberjagen

[Corny]

warum ist das nicht standardmäßig an? was wird da anderst gemacht?
unter dem begriff verstehe ich etwas anderes.

Weil dabei eine einzelne Datei nicht entpackt werden kann, es müssen immer alle entpackt werden (woraus winrar die gewünschte Datei nur verwendet)
Beschädigungen an der Datei sind auch viel gefährlicher.

[pest]

es müssen immer alle entpackt werden

nein das stimmt nicht, es müssen...logischerweise...
nur die dateien entpackt werden die vor der datei im container liegen, die man haben will

[Corny]

nein das stimmt nicht, es müssen...logischerweise...
nur die dateien entpackt werden die vor der datei im container liegen, die man haben will

das kann auch sein, jedenfalls ist es nicht ohne weiteres möglich nur die gewünschte Datei zu entpacken.

[Duran05]

Bei Solid-Archiven werden die Dateien als ein einziger Datenstream betrachtet und daher ist auch die Kompressionsrate höher.
Allerdings kann es dann passieren, das bei einem Fehler, das ganze Archiv unbrauchbar wird, wenn es keine Wiederherstellungsinformationen besitzt.

Um maximale Kompressionsrate zu erreichen sind in der Regel maximale Dictionary Size, Solid-Archive und Multimediakompression erforderlich. WinRAR war zumindest in dem Bereich der Multimediakompression lange Zeit besser, als alle anderen Konkurrenzformate. Dafür kann 7-Zip seit einiger Zeit bei 64 Bit Betriebssystemen, eine extrem große Dictionary Size verarbeiten, was die Kompressionsrate weiter verbessern kann.
Allerdings steigt auch der Speicherverbrauch stark an, beim Packen kann der je nach Einstellung bei mehr als 2 GB liegen.

WinACE oder WinUHA sind auch nicht zu verachten, bei einigen Dateiformaten waren die sogar noch besser als RAR oder ZIP.

[Schimi1983]

7z nutzt bei voler dictionary size bis 14GB Ram aus (bei mir die Standard Pack Einstellung)

[Duran05]

Das ist auf jeden Fall eine gute Methode um eine höhere Kompressionsrate zu erreichen, aber es sollte beachtet werden, das der RAM Bedarf beim entpacken ebenfalls mit ansteigt, das ist zwar deutlich weniger, aber wäre natürlich ärgerlich, wenn die Archive später nur noch auf wenigen Rechnern sinnvoll nutzbar sind. :smile:

Bei extrem großen Dateien sind Solid-Archive auch nicht immer sinnvoll, wenn sich da mal ein Festplattenfehler einschleicht, sind vielleicht alle Daten auf einmal weg und nicht wiederherstellbar. Bei zusätzlich verschlüsselten Archiven wäre das nicht mehr so lustig.

[Rooter]

Um maximale Kompressionsrate zu erreichen sind in der Regel maximale Dictionary Size, Solid-Archive und Multimediakompression erforderlich. WinRAR war zumindest in dem Bereich der Multimediakompression lange Zeit besser, als alle anderen Konkurrenzformate. Dafür kann 7-Zip seit einiger Zeit bei 64 Bit Betriebssystemen, eine extrem große Dictionary Size verarbeiten, was die Kompressionsrate weiter verbessern kann.Ja, Solid können beide, aber 7-Zip fehlt der Multimedia-Preprocessor und RAR das große Dictionary. Wobei ich Letzteres absolut nicht verstehen kann, was macht der Roschal? Die Wörterbuchgröße hochzuschrauben kann doch so aufwendig gar nicht sein. :confused:

WinACE oder WinUHA sind auch nicht zu verachten, bei einigen Dateiformaten waren die sogar noch besser als RAR oder ZIP.ACE war bei mir mal bei PNG Dateien deutlich besser als RAR.
Und bei WinUHA bitte beachten das der IMMER solide Archive erstellt. Dazu gibt's übrigens hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=343521) einen eigenen Thread.

MfG
Rooter

[Duran05]

Es stellt sich wirklich die Frage, ob sich im Bereich der Packprogramme noch etwas tut, weder 7-Zip noch WinRAR haben sich in den letzten Jahren großartig weiterentwickelt. Meist wurden Kleinigkeiten gefixt, an der Oberfläche und den Features hat sich wenig getan.
Das letzte Update bei WinRAR ist schon eine ganze Weile her und war kaum der Rede wert.

UHA gab es schon, da waren noch viele Pentium I/II/III Systeme im Einsatz und das Internet nur über Modem/ISDN zu erreichen. Aber auch die Entwicklung scheint eingestellt zu sein, was wirklich schade ist, da dieses Format großes Potential hatte und mit heutigen Rechnern ziemlich schnell wäre. Der Core i7 müsste eigentlich die besten Ergebnisse zielen, dank DDR3 und integriertem Speichercontroller.
Gäbe es eine 64 Bit und Multithreading Version, wäre das definitiv eine Alternative. :eek:

ACE hat sich offenbar damit abgefunden, nur ein Konkurrenzformat zu sein. Als es damals herauskam wurde noch an der Leistung geschraubt und mit der Formatkompatibilität des Programms geworben, mittlerweile ist auch von denen wenig zu hören.
Hat sich auf dem Markt der experimentellen Packer etwas getan?

[HeldImZelt]

was macht der Roschal? Die Wörterbuchgröße hochzuschrauben kann doch so aufwendig gar nicht sein. :confused:
Erstmal wird er wohl die Scherben seines Schlüsselalgorithmus zusammenfegen müssen. Zum anderen scheint da aber schon länger nichts weltbewegendes zu passieren bei rar. Sie decken ihre primäre Kundschaft wahrscheinlich genügend ab.

[MrMostar]

Es stellt sich wirklich die Frage, ob sich im Bereich der Packprogramme noch etwas tut, ...

So kann ich das wirklich nicht stehenlassen, im Moment sind einige SEHR vielversprechende Projekte in der Pipeline:

1. Heute kam die Version 1.00 des Packer-Baukastens heraus: zpaq100.zip (http://cs.fit.edu/~mmahoney/compression/zpaq100.zip). Hier darf sich der Interessierte User aus Standardbestandteilen von Packprogrammmen (ISSE, MIX, LZP...) sein eigenes Packscript erstellen. Es kann auch Archive zukünftiger Packroutinen entpacken. (unglaublich aber wahr!)

2. In Sachen Effizienz (hier: Kompression durch Laufzeit) kaum zu schlagen: Nanozip (http://www.nanozip.net/), aktuell in der Version 0.06 alpha, mit einfach zu bedienender Oberfläche.

3. Für Performancejunkies zu empfehlen: Freearc (http://freearc.org/Default.aspx) (noch in einem sehr frühen Stadium)

Na dann viel Spaß mit den neuen Packern!

Es gibt Dutzende von Packern, die leistungsfähiger sind als die im Startthread genannten, für den Anfang ist z.B. www.maximumcompression.com (http://www.maximumcompression.com/data/summary_mf.php) hilfreich.

[pest]

was macht der Roschal? Die Wörterbuchgröße hochzuschrauben kann doch so aufwendig gar nicht sein. :confused:


bringt nich viel, zusätzlich zu den höheren rechenzeit-kosten, musst du bei LZ77 ja den Speicherplatz zur Indizierung vergrößern.


ACE war bei mir mal bei PNG Dateien deutlich besser als RAR.


multimedia-preprocessing ist sowieso immer nur ein kompromiss

[clockwork]

Warum kann/macht sowas eigentlich nicht das OS (windows/osx)?

[Rooter]

Es stellt sich wirklich die Frage, ob sich im Bereich der Packprogramme noch etwas tut, weder 7-Zip noch WinRAR haben sich in den letzten Jahren großartig weiterentwickelt.Bei 7-Zip tut sich ja durchaus noch was. Die neueren Methoden vom Original PKWare ZIP und WinZip werden z.B. jetzt unterstützt. Aber was die 7-Zip Kompression selber angeht tut sich atm eher wenig, leider. Er müsste halt mal die Oberfläche etwas aufhübschen und vor allem wirkungsvolle Preprozessoren für Multimedia entwickeln. Ich hoffe das noch eine Version 5 kommt die das bringt.

Erstmal wird er wohl die Scherben seines Schlüsselalgorithmus zusammenfegen müssen.Was meinscht? Er verwendet doch schon ewig AES.

bringt nich viel, zusätzlich zu den höheren rechenzeit-kosten, musst du bei LZ77 ja den Speicherplatz zur Indizierung vergrößern.Wenn man solide Archive erstellt kann es sehr viel bringen. Sonst nur bei großen Dateien, klar. Und ich dachte der Speicherplatz zur Indizierung IST das Wörterbuch!?

multimedia-preprocessing ist sowieso immer nur ein kompromiss:confused:

EDIT:
Warum kann/macht sowas eigentlich nicht das OS (windows/osx)?Seit XP hat Windows doch ZIP eingebaut.

MfG
Rooter

[HeldImZelt]

Was meinscht? Er verwendet doch schon ewig AES.
Winrars ECC (Elliptic Curve Cryptosystems) Algorithmus wurde praktisch repliziert. Die Integrität der Schlüssel/Archive ist nicht mehr sichergestellt (Signierung/Authentifizierung). Die nächste Version dürfte kein 'minor update' werden.

[pest]

Wenn man solide Archive erstellt kann es sehr viel bringen.


die ertragskurve ist eine fallende exponentialfunktion ;)


Und ich dachte der Speicherplatz zur Indizierung IST das Wörterbuch!?


:confused: LZ77 arbeitet nach dem folgenden Prinzip

aus "hallowelthallo" wird "hallowelt[-9,5]" wobei [-9,5] bedeutet gehe 9 schritte zurück und übernehme 5 zeichen. umso größer das wörterbuch
desto größer ist der benötigte speicherplatz für den index. das heißt man benötigt trickreiche heuristiken damit die erhöhung des wörterbuches nicht ins negative umschlägt.
kürzer zurückliegende strings werden eh bevorzugt, d.h. die wahrscheinlichkeit das ein älterer string wirklich verwendet wird,
ist sehr gering, auch wenn man die wörterbuchgröße extrem hoch wählt, da nicht alle strings durchsucht werden,
zumindest in den algos die ich mir so angeschaut habe. 7-Zip scheint zumindest, was das suchverhalten angeht optimierter zu sein und
verwendet verschiedene dynamisch verkette hash-arrays, und nicht nur eins wie winrar.
außerdem ist die codierung effizienter, da ein arithmetischer codierer verwendet wird, im gegensatz zu huffman bei winrar.


:confused:


das multimedia-preprocessing beruht auf einem einfachen prinzip
zusammenhänge zu entfernen die für das LZ77-Modell schwer zu erkennen sind, also z.B. lineare korrelation wie z.B. a[i] = alpha * a[i-1].
auf den auswurf der filter wird der übliche algorithmus angewendet.

besser wäre es aber von vornerherein ein angepasstest model zu benutzen wie es z.B. in PAQ und WinRK der fall ist.

[HeldImZelt]

7zip ist bei 'low difference duplicates grouping' aufgrund der Wörterbuchgröße ungeschlagen. Absoluter Optimalfall für 'solid archiving' aufgrund der mehrfach wiederholenden Bitmuster.
http://goodmerge.sourceforge.net/Statistics.php

[e.v.o]

Sehr informativer Thread.

Könnt ihr euch bitte noch mehr Fragen und Antworten stellen?

[MrMostar]

Zum aktuellen Status von 7zip:

Igor arbeitet gerade am LZMA2 codec, eine alpha Version kann man im 7zip Forum herunterladen:

http://sourceforge.net/forum/forum.php?thread_id=2965956&forum_id=45797

[Duran05]

Das klingt nicht schlecht, vorallem dieser Punkt:

Better compression ratio for data than can't be compressed.

Vielleicht sind damit Dateitypen gemeint, die bereits komprimiert vorliegen?

Bei den anderen Formaten stellt sich wie üblich das Problem der Praxistauglichkeit. Alpha oder Betaversionen sind kaum empfehlenswert, da nie absehbar ist, wie sich die Programme weiterentwickeln und ob dann noch die vorher erstellten Archive lesbar sind.
Leider sind die meisten Projekte recht schnell eingestellt worden, da nur ein oder zwei Entwickler daran beteiligt waren.
Das Format SQX existiert auch schon sehr lang, hat sich dort etwas getan?

Hier (http://www.squeezechart.com/) gibts auch noch eine Liste mit Vergleichsergebnisse.

[Rooter]

Vielleicht sind damit Dateitypen gemeint, die bereits komprimiert vorliegen?


Stimmt:
LZMA2 provides the following advantages over LZMA:
1) Better compression ratio for data than can't be compressed.
It can store such blocks of data in uncompressed form.
Also it decompresses such data faster.
2) Better multithreading support. If you compress big file, LZMA2 can split
that file to chunks and compress these chunks in multiple threads.Nicht komprimierbare Stellen werden wohl einfach 1:1 übernommen anstatt sie durch den Kompressor zu jagen was 1. (Rechen-)Zeit beim komprimieren und dekomprimieren kosten und 2. die Datenmenge am Ende womöglich sogar noch vergrössert würde.

Davon abgesehen finde ich die Änderungen für LZMA2 jetzt nicht so dramatisch. Hoffe da kommt noch mehr.

MfG
Rooter

[albix64]

Seit XP hat Windows doch ZIP eingebaut.
Seit Windows Me. ;)

[Duran05]

Dieses ARC scheint nicht schlecht zu sein, wenn es noch weiterentwickelt werden sollte. In der Anleitung steht, das es mindestens die Kompressionsrate von 7z, RAR oder UHA erreichen kann und noch darüber hinaus geht, wenn die besten Einstellungen genutzt werden.
Außerdem kann die Dictionary Größe offenbar auf mehrere Gigabyte eingestellt werden. Ein großer Nachteil ist allerdings der riesige Speicherverbrauch, der beim entpacken genauso groß sein kann wie beim Packvorgang. :eek:
http://666kb.com/i/b77k1b3fvx7fp5345.gif

[pest]

einen Packer zu schreiben der besser als 7-Zip oder WinRAR ist, ist wirklich keine Kunst, hatte ich auch schon ;)
die meiste Entwicklungszeit nimmt die Entwicklung der Umgebung/API ein, und der Support.

[Duran05]

Die größte Kunst ist eigentlich ein effektives Packformat bei gleichzeitig hoher Geschwindigkeit zu entwickeln.

Überhaupt stellt sich die Frage, wie stark Daten noch komprimiert werden können. Gibt es bei steigender Rechenleistung und genügend Speicher überhaupt eine absehbare Grenze?
Vielleicht wird es in ein paar Jahren normal sein, ganze Dateien nur noch stark komprimiert abzulegen, weil der Vorgang on the fly geschieht. Die NTFS-Kompression ist eher schwach und trotzdem bereits seit vielen Jahren massentauglich.
Wäre es nicht sogar besser, wenn die Dateien komprimiert vorliegen, wenn das Interface (in Hinblick auf SSD) die Datenrate limitiert? Selbst SATA 3.0 wird nicht ewig ausreichen. :smile:

[pest]

Gibt es bei steigender Rechenleistung und genügend Speicher überhaupt eine Grenze?


selbstverständlich


Vielleicht wird es in ein paar Jahren normal sein, ganze Dateien nur noch stark komprimiert abzulegen, weil das on the fly möglich wird.


ich glaube es ist eher rückläufig. früher, d.h. so 1996 habe ich auch noch mit zig packprogrammen rumgespielt. aber jetzt ist es egal ob das archiv nun 5% größer ist.
und...was nützt einem das mehr an packrate wenn man keine multiplatformunterstütung hat..z.B.
die entwicklungen bewegen sich auch eher im 0.x bereich.
ich sehe das eher als spielerei an, aber eine interessante spielerei.
weil es kein universelles (praktikables) modell für daten gibt, und jeder algorithmus verschiedene stärken besitzt. sich damit auseinanderzusetzen ist schon sehr spannend imo

[Duran05]

Multiplattformsupport sieht so schlimm eigentlich gar nicht aus, das ist lediglich bei in der Entwicklung befindlichen Programmen so.
7-Zip ist schon jetzt für Windows, Linux und MacOS verfügbar und dürfte das auch mit LZMA2 sein.

Schon die NTFS-Kompression leistet bei einigen Dateitypen gute Dienste und ist ziemlich schnell. In ein paar Jahren dürfte es eigentlich kein Problem sein, das Niveau von Zip oder besser zu erreichen. Bei herabsetzen der Einstellungen sind die schon jetzt ziemlich schnell.
Allerdings stellt sich überhaupt erstmal die Frage, wann neue Dateisysteme zum Einsatz kommen werden.

[Rooter]

Seit Windows Me. ;)Ah so. :D

einen Packer zu schreiben der besser als 7-Zip oder WinRAR ist, ist wirklich keine Kunst, hatte ich auch schon ;)Wenn du mit "besser" maximale Kompression meist stimmt das sicher, siehe WinRK u.Ä. Aber Geschwindigkeit und Speicherverbrauch ist ja auch noch ein Punkt, weshalb sich sowas wie WinRK nicht durchsetzt.

Gibt es bei steigender Rechenleistung und genügend Speicher überhaupt eine absehbare Grenze?Logisch, die Grenze ist mathematisch beweisbar, Pest kann da sicher mehr zu sagen ;). Sonst könntst du ja irgendwann 1 Gigabyte in ein Byte runterkomprimieren... ;)

Wäre es nicht sogar besser, wenn die Dateien komprimiert vorliegen, wenn das Interface (in Hinblick auf SSD) die Datenrate limitiert?Würde wenig bringen, die meisten (grossen) Dateien bei denen es sinn machen würde lassen sich ja kaum noch weiter komprimieren.

MfG
Rooter

[Duran05]

Würde wenig bringen, die meisten (grossen) Dateien bei denen es sinn machen würde lassen sich ja kaum noch weiter komprimieren.

Pauschalisieren lässt sich das allerdings nicht. Imagedateien lassen sich zum Teil sehr gut komprimieren (Betriebssystem, Programme oder Spiele). Bei ganzen Büchern (z.B. PDF) könnte es ähnlich aussehen.
Die Interfacegrenze von SATA 2 ist zumindest nicht mehr weit entfernt. Ob SATA 3 so viel länger hält, weiß noch keiner so genau.

Ein kleiner Test:
Ausgangsmaterial (Programm und DLL Dateien, Textdateien, Texturen, Audiofiles, Videofiles) 4,49 GB (4.830.794.678 Bytes).
7z (Ultra, LZMA, 64 MB, 273, Solid) 4,08 GB (4.386.067.601 Bytes) ca. 33 Minuten.
ARC (-m7, Solid) 4,04 GB (4.341.026.869 Bytes) ca. 42 Minuten.

Bei beiden Formaten wäre eine Verbesserung durch höhere Einstellungen möglich (64 Bit), vorallem ARC erlaubt als Parameter noch -m8 oder -m9. Dabei ist es immer noch relativ schnell.

[Rooter]

Okay, ist halt die Frage ob die 10% wenigen wirklich den Aufwand wert sind.

MfG
Rooter

[aths]

Die größte Kunst ist eigentlich ein effektives Packformat bei gleichzeitig hoher Geschwindigkeit zu entwickeln.

Überhaupt stellt sich die Frage, wie stark Daten noch komprimiert werden können. Gibt es bei steigender Rechenleistung und genügend Speicher überhaupt eine absehbare Grenze?Ja. Stichwort Entropie.

Mit einem Bit kann man nur zwei Zustände kodieren. Mit acht Bit nur 256. Also kann man Daten auch mit unendlicher Rechenleistung, unendlich viel Speicher und dem besten Algorithmus aller Zeiten nicht zu beliebig kleinen Dateien komprimieren.



Die größte Kunst ist eigentlich ein effektives Packformat bei gleichzeitig hoher Geschwindigkeit zu entwickeln.

Überhaupt stellt sich die Frage, wie stark Daten noch komprimiert werden können. Gibt es bei steigender Rechenleistung und genügend Speicher überhaupt eine absehbare Grenze?
Vielleicht wird es in ein paar Jahren normal sein, ganze Dateien nur noch stark komprimiert abzulegen, weil der Vorgang on the fly geschieht. Die NTFS-Kompression ist eher schwach und trotzdem bereits seit vielen Jahren massentauglich.Bei starker Komprimierung bekommst du Probleme. Man muss in der Lage sein, Blöcke innerhalb einer großen Datei auszulesen ohne die gesamte Datei dekomprimieren zu müssen. Demnach müssen einzelne Blöcke unabhängig voneinander komprimiert werden, was die Komprimierungsrate senkt. Ein Problem ist auch der Zugriff: Bei Nullkomprimierung weiß man, an welcher Stelle Byte so-und-so steht. Bei Komprimierung muss zunächst über einen Index nachgesehen werden, wo man es findet. Dieser Index muss bei Dateiänderung neu erstellt werden. Wenn man einen Block in der Datei ändert, der sich nicht mehr so gut komprimieren lässt, lassen sich die Daten nicht dazwischen schieben so dass sie irgendwoander stehen. Das zieht zusätzliche Bewegung des Schreiblesekopfes nachsich.

[DanMan]

Für mich ist der Hauptnutzen von gepackten Dateien der, dass ich sie schneller übers Netz an andere Leute schicken kann. Wenn die aber dann das Packprogramm nicht haben, dann müsste ich es als selbstentpackende .exe verschicken. Das frisst einerseits den Größenvorteil wieder auf, und andererseits wiederum öffnen vernünftige Leute sowas nur, wenn sie dem Absender vertrauen bzw. ihn kennen. Dann besteht trotzdem noch die Gefahr eines Man-In-The-Middle Angriffs.

Unterm Strich find ich das darum mittlerweile alles recht uninteressant.

[Der_Donnervogel]

Ja. Stichwort Entropie.

Mit zwei Bit kann man nur zwei Zustände kodieren. Mit acht Bit nur 256. Also kann man Daten auch mit unendlicher Rechenleistung, unendlich viel Speicher und dem besten Algorithmus aller Zeiten nicht zu beliebig kleinen Dateien komprimieren.Ist korrekt, allerdings bin ich mir nicht sicher ob jeder schon mal was von Entropie gehört hat und wie das mit den Bit zusammenhängt, deshalb noch mal eine ergänzende Erklärung von mir:

In Dateien sind Daten oftmals redundant gespeichert, das bedeutet Daten kommen öfter vor als sie eigentlich müßten um eine Information zu transportieren. Ein Packalgorithmus versucht nun diese Redundanzen zu reduzieren. Man kann sie allerdings nur bis zu der Grenze reduzieren wenn nur noch die reine Information übrig geblieben ist, die keinerlei überflüssige Wiederholungen (oder andere Muster, etc.) enthält die zusammengefaßt oder anders verkürzt werden können. z.B. die Information der folgenden Rechnung: 3+3+3+3 kann man zu 4*3 komprimieren, ohne dass Information verloren geht. Weiter komprimieren geht aber nicht, denn 12 wäre bereits eine "verlustbehaftete Kompression", da sie nicht mehr eindeutig umkehrbar ist.

[aths]

Ist korrekt, allerdings bin ich mir nicht sicher ob jeder schon mal was von Entropie gehört hat und wie das mit den Bit zusammenhängt, deshalb noch mal eine ergänzende Erklärung von mir:

In Dateien sind Daten oftmals redundant gespeichert, das bedeutet Daten kommen öfter vor als sie eigentlich müßten um eine Information zu transportieren. Ein Packalgorithmus versucht nun diese Redundanzen zu reduzieren. Man kann sie allerdings nur bis zu der Grenze reduzieren wenn nur noch die reine Information übrig geblieben ist, die keinerlei überflüssige Wiederholungen (oder andere Muster, etc.) enthält die zusammengefaßt oder anders verkürzt werden können. z.B. die Information der folgenden Rechnung: 3+3+3+3 kann man zu 4*3 komprimieren, ohne dass Information verloren geht. Weiter komprimieren geht aber nicht, denn 12 wäre bereits eine "verlustbehaftete Kompression", da sie nicht mehr eindeutig umkehrbar ist.Ist 4*3 auch nicht. Was ist, wenn "4*3" gespeichert werden soll? Ist das nun in Wahrheit 4*3 oder 3+3+3+3?

Komprimierungsalgorithmen versuchen eben, häufig vorkommende Muster mit möglichst wenig Bit zu speichern. Zur Mustererkennung verwendet man Verfahren, die beim Durchlaufen der Datei Wörterbücher erstellen. Mit anderen Optimierungen weist man dann den oft vorkommenden Einträgen kurze Indizes mit kurzen Bitlängen zu. Dazu gibt es zusätzliche Transformationen, Daten in eine möglichst gut komprimierbare Form zu bringen. Das zu erklären dass man es wirklich versteht erfordert allerdings ein Studium.

Daher gehe ich lieber von der anderen Seite heran: Mit x Bit lassen sich nur 2 hoch x Zustände speichern. Man kann also keinen Komprimierungsalgorithmus entwickeln, der zum Beispiel 257 unterschiedliche Dateien immer auf höchstens 8 Bit komprimieren kann. Egal, wie kurz oder gut komprimierbar die Dateien jeweils sind.

[Darkstar]

Mit zwei Bit kann man nur zwei Zustände kodieren.Korrektur: Mit zwei Bit kann man vier Zustände kodieren.

[Duran05]

Wie weit sind die Entwickler vom Limit denn noch entfernt? Bisher gab es immer noch Verbesserungen am Kompressionsgrad und kaum ein Format bringt alle Vorteile in einem Programm unter.
Selbst wenn das Packformat gut ist, scheint es bei diversen Dateitypen noch von spezialisierten Packern übertroffen zu werden.

7-Zip ist fast das einzige Programm, was solch hohe Kompressionsraten im Praxiseinsatz und unter vielen Plattformen zur Verfügung stellt, aber bei Multimediadateien hat es immer noch Spielraum.

[(del)]

http://nightlies.videolan.org/build/win32/branch-20090315-0103/

WinRAR 3.80 auf max

19.426.806 Bytes in 14s.

=================

7-zip 4.65 Ultra (64MB, 256bit, solid block 2GB) und
0=bcj2 1=lzma:d26 2=lzma:d23 3=lzma:d23 b0:1 b0s1:2 b0s2:3 hcf=on f=off

13.649.820 in 15s.

Wo sackt hier bei einer hochgeschraubten Kompressionsrate 7-zip ab, Mr.Magic :confused:

WinRAR entpackt das auf die Platte in 6s, 7-zip in 4s.

NanoZIP 0.06 braucht mit optimum2 über 60s und das Archiv ist hier danach 14.390.633 Bytes groß. Welche Methode soll man für so einen Vergleich nehmen? Ich meine, auch mal solche bei welcher man weder beim Packen noch beim Entpacken einschläft oder welche die solche Zeiten durch das Ratio auch entschuldigt?

[aths]

Korrektur: Mit zwei Bit kann man vier Zustände kodieren.Genau, es sollte "mit einem Bit" heißen. Habs korrigiert.

Wie weit sind die Entwickler vom Limit denn noch entfernt? Bisher gab es immer noch Verbesserungen am Kompressionsgrad und kaum ein Format bringt alle Vorteile in einem Programm unter.
Selbst wenn das Packformat gut ist, scheint es bei diversen Dateitypen noch von spezialisierten Packern übertroffen zu werden.

7-Zip ist fast das einzige Programm, was solch hohe Kompressionsraten im Praxiseinsatz und unter vielen Plattformen zur Verfügung stellt, aber bei Multimediadateien hat es immer noch Spielraum.Man kann nicht alles prüfen, wenn es schnell genug sein soll.

Die Verbesserungen sind nach LWZ+Entropie-Optimierung (Huffman oder arithmetische Komprimierung) auf Spezialfälle begrenzt. Um einen Datenstrom besser entropieoptimieren zu können, kann man noch eine Burrows-Wheeler-Transformation machen (ggf. mit weiteren anderen Transformationen im Anschluss. Solche Verfahren bieten keine Komprimierung ansich, sondern machen den Datenstrom sogar etwas länger. Doch durch eine geschickte Umsortierung, die vollständig umkehrbar ist, werden die Daten in einen oft besser komprimierbaren Datenstrom umgewandelt. Natürlich funktioniert das nicht, wenn man weißes Rauschen komprimieren möchte, da sich weißes Rauschen, also völliger Zufall, nicht komprimieren lässt.)

Man kann nach der Erstellung des Wörterbuchs dieses noch optimieren, da LZW nicht optimal arbeitet. Aber im Prinzip bleibt allgemein verwendbare Komprimierung auf folgende zwei Faktoren beschränkt:

- Textdateien nutzen nicht den gesamten Zeichensatz, da sie vor allem aus Buchstaben und wenigen Sonderzeichen bestehen. Also kann man ein Zeichen mit weniger als 8 Bit kodieren. Auch andere Dateitypen nutzen bestimmte Zeichen besonders oft, so dass diese mit kurzen Bitfolgen kodiert werden können und man so einen Komprimierungseffekt hat.

- Außerdem ist es möglich, sich wiederholende Zeichenfolgen zu erkennen und Wörterbücher anzulegen. Man speichert dann das Wörterbuch sowie eine Liste die in Reihenfolge angibt, aus welchen Wörter der Datenstrom besteht.

Die Indizes werden oft noch optimiert: Häufig vorkommende Wörter erhalten einen kurzen Index.

Multimedia-optimierte Komprimierung erkennt außerdem Spezialfälle, zum Beispiel wenn ein Wort mit den Zeichen in umgekehrter Reinenfolge vorkommt. Aber allgemeine Dateikomprimierung profitiert davon nur wenig.

Ein Beispiel. Angenommen wir wollen Pi komprimiert speichern und benötigen nur eine bestimmte Genauigkeit. Mit 22/7 kommt man auf drei gültige Dezimalstellen. Man gewinnt also nichts. Mit 355/113 kommt man auf 7 gültige Dezimalstellen, eine mehr als man Ziffern speichern muss (wenn wir mal außer Acht lassen, dass die Länge des Zählers und Nenners auch gespeichert werden muss.)

Speichern wir das Quadrat von Pi mit gerundet mit insgesamt drei Stellen (9,87) und ziehen zum Dekomprimieren die Wurzel, erhalten wir vier gültige Stellen, sogar fünf wenn die letzte als korrekt gerundet einrechnet. Nur müsste man, um solche Sachen zu finden, extrem viel probieren. Außerdem muss man ja mitspeichern, welche Rückrechnung erforderlich ist. Hier muss man sich auf eine Auswahl beschränken, da sonst der Umfang der Rückrechnungs-Angabe so groß wird, dass eine solche Komprimierung nicht mehr lohnt. Deshalb lässt man sowas bleiben und prüft nur auf bestimmte Charakteristiken, die bei Bild- und Audio-Dateien öfters vorkommen.

[Duran05]

7-zip 4.65 Ultra (64MB, 256bit, solid block 2GB) und
0=bcj2 1=lzma:d26 2=lzma:d23 3=lzma:d23 b0:1 b0s1:2 b0s2:3 hcf=on f=off

13.649.820 in 15s.

ARC scheint ähnlich effektiv zu sein: 13.673.526 Bytes.
Leider ist beim "-m7" Parameter schluss, alles darüber hinaus setzt wohl schon ein 64 Bit Betriebssystem vorraus. Aber die Geschwindigkeit ist mit ca. 22 Sekunden nicht schlecht gewesen. Neben -m8 und -m9 gibts vielleicht noch weitere Parameter, die die Kompression verbessern, die Kommandozeilenversion ist ziemlich unübersichtlich. ;)
Man kann bei ARC auch festlegen, ob man maximale Kompressionsrate oder einen schnellen und wenig speicherintensiven Entpackvorgang bevorzugt.
Bei mittleren Einstellungen scheint sich auch ein Drittprogramm für Text einbinden zu lassen, was die Kompressionsrate weiter verbessern soll.
Gegenüber anderen Formaten sind die Ergebnisse schon jetzt ziemlich gut.

[Rooter]

7-zip 4.65 Ultra (64MB, 256bit, solid block 2GB) und
0=bcj2 1=lzma:d26 2=lzma:d23 3=lzma:d23 b0:1 b0s1:2 b0s2:3 hcf=on f=off

13.649.820 in 15s.Ausführbarer Code war schon immer eine Domäne von LZMA.

MfG
Rooter

[(del)]

Ausführbarer Code war schon immer eine Domäne von LZMA.Viel bleibt ja auch nicht über. Multimedia und PDF ist meist schon unkomprimierbar bzw. lohnt der Aufwand nur noch selten (außer bei BMP...) und bei Texten, Docs u.ä braucht sich LZMA1 nicht zu verstecken. Selbst WinRAR als alter Textspezi packt nach meinen letzten Tests nur noch ~5% besser als 7-zip.
So oder so sackt 7-zip dabei jedenfalls gegenüber WinRAR oder Winzip nicht ab. Keine Ahnung was Mr.Magic da geträumt hat.

@theSpy
Solche Features bitten die meisten anderen Packer auch. Und mit diesem Kram Bei mittleren Einstellungen scheint sich auch ein Drittprogramm für Text einbinden zu lassen, was die Kompressionsrate weiter verbessern soll. bin ich meist nicht mehr interoperabel.
Der Groß der Benutzer scheint auch das Verhältnis von Effizienz zur Zeit zu schätzen. Was du, wie der andere Kollege bei Nanozip, bei ARC nicht erwähnst. Sonst würde ja jeder mit PAQ8 oder WinRK arbeiten und gut ist.

Viele der Algos sind als Technologiestudien zu verstehen. Es ist schön, daß sich jemand damit beschäftigt, für den täglichen Gebrauch sind aber andere Sachen vom größeren Belang.
Es gibt extrem effiziente Packer und es gibt extrem schnelle Packer. Für den täglichen Einsatz wählt man einen trade-off davon und achtet oft auch noch auf die Interoperabilität.
In dem Fall bleiben von zig Technologiestudien als erwähnenswert nur noch Rar, LZMA und Zip über.

[Duran05]

Es würden bestimmt mehr Nutzer damit arbeiten, wenn sie diese Formate kennen würden. Außerhalb von Foren sind Begriffe wie WinRK und andere gänzlich unbekannt, das ist eines der größten Probleme.
Noch dazu dürfte es stören, das manche Programme sich noch im Alpha oder Betastadium befinden, damit wird keiner arbeiten wollen, der auf Zuverlässigkeit aus ist.

Bei free ARC wird sogar damit geworben, das es bei ähnlicher Kompressionsrate schneller sein soll als Zip, RAR und 7z. Das wäre bereits ein nennenswerter Vorteil, wenn es zusammen mit einer ordentlichen Oberfläche ausgeliefert und dadurch bekannter wird.

[(del)]

Außerhalb von Foren sind Begriffe wie WinRK und andere gänzlich unbekannt, das ist eines der größten Probleme.Wirklich? Ich denke das würde sich schon schnell legen. Andererseits denke ich aber, daß s.g. symetrische Verfahren (like WinRK pder PAQ) die zum Entpacken genausoviel Speicher und Zeit brauchen wie zum Packen NIE einen größeren Benutzungsgrad erreichen werden. Hierzu fehlt korrekterweise die Akzeptanz.

Bei free ARC wird sogar damit geworben, das es bei ähnlicher Kompressionsrate schneller sein soll als Zip, RAR und 7z. Das wäre bereits ein nennenswerter Vorteil, wenn es zusammen mit einer ordentlichen Oberfläche ausgeliefert und dadurch bekannter wird.beim freeARC sehe ich, daß es sich bei bekannten Verfahren über die GPL bedient. Nichts schlimmes bzw. sehr klever, aber nicht gleich ein Geniestreich der Programmierkunst. Es mixt die Verfahren einfach on the fly. Mit eben LZMA im Rücken. Ok. Geht klar.

Nur, meinen Erfahrungen nach packt es zwar im einstelligen Prozentbereich besser als 7-zip, packt im einstelligen Prozentbereich schneller als 7-zip, entpackt aber mindestens 3x so lange.

Bis dann mal.

[Duran05]

Das kann sein, dafür haben sie wahrscheinlich die Option eingebaut, um einstellen zu können, was wichtiger sein soll.
Der Speicherverbrauch ist natürlich ebenfalls wichtig, da es sonst passieren kann, das bestimmte User die Dateien nicht mehr öffnen können, wenn sie nicht über die gleichen Vorraussetzungen verfügen.

Eigentlich sind alle wichtigen Funktionen schon mit drin, mal sehen, wie sich das entwickelt in nächster Zeit.
Bei der Oberfläche sollten sie vielleicht die Parameter weglassen, viele können damit eh nichts anfangen. ;)
http://freearc.org/screenshots/freearc-windows.png
http://freearc.org/screenshots/freearc-linux.png

[pest]

Komprimierungsalgorithmen versuchen eben, häufig vorkommende Muster mit möglichst wenig Bit zu speichern. Zur Mustererkennung verwendet man Verfahren, die beim Durchlaufen der Datei Wörterbücher erstellen. Mit anderen Optimierungen weist man dann den oft vorkommenden Einträgen kurze Indizes mit kurzen Bitlängen zu. Dazu gibt es zusätzliche Transformationen, Daten in eine möglichst gut komprimierbare Form zu bringen. Das zu erklären dass man es wirklich versteht erfordert allerdings ein Studium.


ich gehe einfach mal davon aus, das du weißt das das nur ein kurzer Ausschnitt ist, moderne (Allzweck-)Verfahren arbeiten auf PPM Basis
genauso wenig verstehe ich deine "Indexoptimierung". Häufige Wörter erhalten automatisch kurze Indizes, da sie kürzer zurück liegen. Man kann natürlich LRUs anlegen
aber das bringt nicht viel. Nur WinRK hat da imo ne deutliche Verbesserung gezeigt, weiß aber leider nicht wie, denke aber auch über eine PPM-Komponente.



Die Verbesserungen sind nach LWZ


(LZW-)Verfahren wird nicht verwendet!


Um einen Datenstrom besser entropieoptimieren zu können, kann man noch eine Burrows-Wheeler-Transformation machen (ggf. mit weiteren anderen Transformationen im Anschluss.


man kann nicht alles miteinander beliebig mixen, nach der bw-transformation erfolgt die entropie-kodierung, und vor der bw-transformation wird auch kein lz77 oder lzw verwendet,
das wäre total unsinnig weil die kontext-information zerstört sind

[MrMostar]

ARC scheint ähnlich effektiv zu sein: 13.673.526 Bytes.
Leider ist beim "-m7" Parameter schluss, alles darüber hinaus setzt wohl schon ein 64 Bit Betriebssystem vorraus...

Die aktuelle Version von gestern ist etwas besser und aufgeräumter: 13580944 Bytes.
Parameter -mx, Version siehe Screenshot:

[FlashBFE]

Packer werden immer uninteressanter, weil immer mehr Platz da ist, Datenraten weiter steigen und vor allem immer mehr Datenformate in sich schon gepackt sind. Das ist bei Multimediadateien schon länger so und seit nicht allzulanger Zeit auch bei z.B. Text: PDF, ODF und DOCX.
Ich benutze Winrar auch meistens nurnoch, um aus vielen Dateien ein Paket zu schnüren oder um etwas passwortgeschützt zu verschicken.

[aths]

ich gehe einfach mal davon aus, das du weißt das das nur ein kurzer Ausschnitt ist, moderne (Allzweck-)Verfahren arbeiten auf PPM BasisWas meinst du mit PPM?

Wir hatten im Studium LZW (und einige Vorgänger), Burrows-Wheeler / Move-to-Front, Fano, Huffman, Arithmetische Komprimierung.

man kann nicht alles miteinander beliebig mixen, nach der bw-transformation erfolgt die entropie-kodierung, und vor der bw-transformation wird auch kein lz77 oder lzw verwendet,
das wäre total unsinnig weil die kontext-information zerstört sindJa, BW wird auf die zu komprimierenden Daten gemacht.

[pest]

Was meinst du mit PPM?


http://de.wikipedia.org/wiki/Prediction_by_Partial_Matching

WinRAR und WinZIP benutzen den PPMd Algorithmus (Autor ist mir grad entfallen), WinRK und PAQ erweitern die Idee
der Basisalgorithmus von WinRAR, ACE und 7-Zip ist eine LZ77-Variante.

[Duran05]

Packer werden immer uninteressanter, weil immer mehr Platz da ist, Datenraten weiter steigen und vor allem immer mehr Datenformate in sich schon gepackt sind.

Es steigen nicht nur Speicherplatz und Datenraten, sondern auch Rechenleistung und Dateigrößen.
Videos werden auch nicht unkomprimiert über das Internet übertragen, nur weil es möglich wäre. Speicherplatz und Traffic kosten immer noch Geld und daher wird, wenn möglich gespart. Beim Internet gehts oft darum, Zeit zu sparen.
Statt einem unkomprimierten Audio oder Videofile, könnte ein lossless Format oder andere Komprimierung zum Einsatz kommen, der Aufwand ist kaum vorhanden, also wozu etwas verschenken?

[=Floi=]

Andere programme nützen nichts, weil deren markanteil gegen 0 gehen dürfte und der andere oft eben auch diese programme nicht besitzt. Komprimieren macht auch sinn, weil man so auch problemlos einen ordner sicher verschicken kann und platz ist zwar günstig, nicht aber bandbreite. Bei emails zählt noch immer jedes KB.
Für mich ist deshalb die kompressionsrate noch immer wichtiger wie die geschwindigkeit.


ot
der ut2004 ordner lässt sich übrigens sehr gut komprimieren. :)

[san.salvador]

Ein für mich sehr praktisches Element ist auch die kinderleichte Verschlüsselung mehrerer Files.

[Der_Donnervogel]

Ist 4*3 auch nicht. Was ist, wenn "4*3" gespeichert werden soll? Ist das nun in Wahrheit 4*3 oder 3+3+3+3?

(...) Das zu erklären dass man es wirklich versteht erfordert allerdings ein Studium.Genau aus dem Grund habe ich es versucht einfach darzustellen, denn die Grundrechenarten sollten die meisten beherrschen. ;) Natürlich würde man bei einem echten Kompressionsprogramm nicht so arbeiten, da dazu der Algorithmus ja die Semantik von "+" verstehen müßte um eine Addition in eine Multiplikation umwandeln zu können. Das geht natürlich nur wenn der Algorithmus Zusatzwissen über die Daten hat (z.B. Multimediadatenkompression). Das Prinzip ist aber vergleichbar und auch für Leute recht anschaulich die sich nicht tagtäglich mit Informatik und Informationstheorie beschäftigen.
Daher gehe ich lieber von der anderen Seite heran: Mit x Bit lassen sich nur 2 hoch x Zustände speichern. Man kann also keinen Komprimierungsalgorithmus entwickeln, der zum Beispiel 257 unterschiedliche Dateien immer auf höchstens 8 Bit komprimieren kann. Egal, wie kurz oder gut komprimierbar die Dateien jeweils sind.Doch, man könnte einen Kompressionsalgorithumus entwickeln der 257 Dateien auf 8 Bit abbildet. Sowas nennt sich dann "verlustbehafteter Kompressionsalgorithmus". ;)
Komprimieren macht auch sinn, weil man so auch problemlos einen ordner sicher verschicken kann und platz ist zwar günstig, nicht aber bandbreite. Bei emails zählt noch immer jedes KB.
Für mich ist deshalb die kompressionsrate noch immer wichtiger wie die geschwindigkeit.Also um jedes KB ringe ich zumindest bei Mails schon lange nicht mehr. Seit eh praktisch jeder ADSL oder Kabel hat muss man da nicht mehr so aufpassen wie noch zu Modem-Zeiten. Was ich aber praktisch finde ist, falls man ganze Ordner/Ordnerstrukturen verschicken will, kann man das mit Packprogrammen sehr einfach machen. Allerdings ist es wirklich ein Problem dass vor allem die Upload-Bandbreite selbst mit hochwertigen ADSL-Anschlüssen noch sehr langsam ist (zumindest verglichen mit Festplatte und LAN).

[aths]

Genau aus dem Grund habe ich es versucht einfach darzustellen, denn die Grundrechenarten sollten die meisten beherrschen. ;) Natürlich würde man bei einem echten Kompressionsprogramm nicht so arbeiten, da dazu der Algorithmus ja die Semantik von "+" verstehen müßte um eine Addition in eine Multiplikation umwandeln zu können. Das geht natürlich nur wenn der Algorithmus Zusatzwissen über die Daten hat (z.B. Multimediadatenkompression). Das Prinzip ist aber vergleichbar und auch für Leute recht anschaulich die sich nicht tagtäglich mit Informatik und Informationstheorie beschäftigen. Die Erklärung mit 4*3 halte ich trotzdem für verwirrend da nicht ersichtlich ist, wieso 4*3 noch eindeutig sein soll und 12 nicht.

Doch, man könnte einen Kompressionsalgorithumus entwickeln der 257 Dateien auf 8 Bit abbildet. Sowas nennt sich dann "verlustbehafteter Kompressionsalgorithmus". ;)Darum geht es hier ja nicht.

[Rooter]

Die Erklärung mit 4*3 halte ich trotzdem für verwirrend da nicht ersichtlich ist, wieso 4*3 noch eindeutig sein soll und 12 nicht.Stimmt. Dann sagen wir halt mit "12" ist das Minimum in diesem Beispiel erreicht, noch weiter verringern läßt es sich nicht.

MfG
Rooter

[Der_Donnervogel]

Die Erklärung mit 4*3 halte ich trotzdem für verwirrend da nicht ersichtlich ist, wieso 4*3 noch eindeutig sein soll und 12 nicht.Nun gut, dann ist es halt verwirrend, damit kann ich auch gut leben. Ich glaube es lohnt sich nicht wegen dem Beispiel noch weiter zu diskutieren.Darum geht es hier ja nicht.Ja, das ist mir schon klar. Deshalb habe ich dahinter auch den ";)" gemacht und gedacht es ist dadurch klar, dass das scherzhaft gemeint war.

[HeldImZelt]

Weil 12 keine Rückschlüsse auf die eindeutig definierten Elemente (3+3+3+3) erlaubt. 12 könnte auch 2*6, 1*12, 24/2.. sein. Entscheidend ist nicht das Ergebnis als Zahl, sondern die Rekonstruktion der 4 bestimmten Ziffern. '4 mal 3' darf nicht als Rechenoperation gesehen werden, sondern als Anweisung einen String oder eine Zahlenfolge zu erschaffen. Genau so könnte man sagen 5*G statt GGGGG.

[aths]

RLE würde ich aber anders erklären, nicht mit +. 3, 3, 3, 3 kann als 'Wiederhole 4 mal: 3' gespeichert werden.

[HeldImZelt]

Sondern?

[aths]

Steht da doch. "3, 3, 3, 3 kann als 'Wiederhole 4 mal: 3' gespeichert werden."

[HeldImZelt]

Mein Fehler.. Der Punkt hat irritiert, habe die Aussage nicht erkennen können...

Dann hat sich das ja erledigt. Scheinbar haben alle das Gleiche gemeint.

[albix64]

Ich habe es mal geschafft eine 20MB große AVI-Datei auf 0.5MB zu komprimieren, mit 7Zip Ultra. War erstaunt das das soweit geht.

[Schimi1983]

war bestimmt eine unkomprimierte avi... von schätzungsweise 1sec länge :D

sonst wäre ich auf einen "beweis" gespannt

[HeldImZelt]

Wenn es danach geht, kann ich auch 4.3GB auf 600KB drücken. :D


Sack voll Nullen (http://www.speedshare.us/uploads/Luftpumpe789180.7z)

[Rooter]

war bestimmt eine unkomprimierte avi... von schätzungsweise 1sec länge :D

sonst wäre ich auf einen "beweis" gespannt
Doch, das kann gehen, es gibt einen Codec für Bildschirmaufnahmen der sich ziemlich heftig komprimieren läßt. Weis aber beim besten Willen nimmer wie der hies... :(

EDIT: Glaube es war Cinepak (FourCC: CVID) :uponder:

MfG
Rooter

[Duran05]

Bei Videos die vorallem Standbilder oder eine Art Diashow zeigen, ist das durchaus möglich.
Bei sich schnell verändernden Szenen (Filme, Sport) ist es so gut wie unmöglich. ;)

[HeldImZelt]

In diesem Fall nicht, da fließen nur mehr Bits und die Datei wird größer. Diese typischen Kompressoren können mit ihren schwachen Methoden nicht mehr raus holen. 'Microsoft Video 1' (MSVC/CRAM) z.B. ist so einer. Lässt sich sehr gut mit den Standardpackern nachpressen. Der Codec wurde damals mit VfW eingeführt und eignet sich heute evtl. noch als Screencapture Kompressor. Er verbraucht dafür nur sehr wenig CPU Power, ist aber auf 8bit/16bit pro Pixel beschränkt.