Infima - Neue Losslesstechnologien

Tja, dann bist du bei uns wohl der erste, der's bemerkt hat - also :daumen: für den Hinweis.

{ Vorsicht - Theorie! }

Tja ... jeder Informatiker lernt in den ersten Semestern bereits die Grundlagen der "Informationstheorie" von Claude Shannon, die mit Hilfe von Robert Fano und David Huffman verfeinert wurde und letztlich über den Begriff der Entropie (der Wahrscheinlichkeit des Auftretens spezieller Zustände im Vergleich zu allen möglichen Zuständen) schließlich zur Entwicklung der Entropiecodierung führte.

Der Grundsatz von Shannon war, dass bei der Verwendung kürzerer Codes für wahrscheinlichere Daten eine Platzersparnis gegenüber gleichlanger Codes für alle möglichen Daten erreicht werden kann. Es wurde bereits mathematisch bewiesen, dass die Technik von Huffman (ein Schüler von Shannon), den Wahrscheinlichkeitsbaum rückwärts (von den Blättern zur Wurzel) aufzubauen, mindestens gleich gute und meist bessere Codierung ermöglicht als die Vorwärtserstellung, die Shannon zunächst erfand, und von Fano etwas modifiziert wurde.

Aber bereits der triviale Ansatz der Delta-Komprimierung, der Lauflängenkomprimierung, und ähnlicher "Präkodierungen" - bis hin zu den beiden Lempel-Ziv-Verfahren, Burrows-Wheeler-Transformation und Ansätzen der Automatentheorie (z.B. "Prediction by Partial Matching" durch die Anwendung der Markov-Ketten) - zeigen deutlich, dass statistische Analysen zum Erkennen und Entfernen von Redundanzen ("überflüssigen" Wiederholungen in den Ausgangsdaten) vor der Entropiecodierung zu einer effizienteren Kompression führen.

In der Arbeit zur speziellen Implementation "LZP" konnte gezeigt werden, dass einer der beiden Lempel-Ziv-Techniken ein Trivialfall des PPM-Modells mit kleinster Ordnung ist.

{ Genug Theorie... }

Die Praxis hat gezeigt, dass es immer wieder gelungen ist, durch geschickte Analyse und Umstrukturierung der Ausgangsdaten eine immer bessere Kompression zu finden. Letztendlich wird man sich aber nach allgemein verbreiteter Ansicht höchstens einem "eigentlichen Informationsgehalt" im Datenstrom annähern können, eine ewige Verbesserung der Komprimierbarkeit ist nicht zu erwarten.

Wenn also jemand behauptet, die Komprimierbarkeit geradezu revolutioniert zu haben, dann sollte man höchst skeptisch sein und genauestens testen: Meist werden Optimalfälle veröffentlicht, die bei speziell konstruierten Ausgangsdaten erreicht werden.

Ich kann zum Beispiel problemlos eine MP3-Datei noch mal auf die Hälfte komprimieren -- wenn diese ein paar Stunden Stille enthält und auf hohe Bitrate gezwungen wurde, und dadurch jede Menge überflüssiges Füllmaterial enthält. Aber im Allgemeinen müsste eine MP3-Datei, die hörbares Material enthält, beispielsweise derart unterschiedliche Daten enthalten, dass sie (ohne Kenntnis des Inhaltes) als "guter Rauschgenerator" verwendet werden könnte, denn sie enthält bereits das Ergebnis einer Entropiecodierung (Huffman), und deren Ergebnis-Bitstrom ist nachweislich recht zufällig verteilt. { Sorry, doch noch etwas Theorie zwischendurch. }
__

Um das ganze also zusammenzufassen:

Ich habe mich als Betatester angemeldet und werde in Kürze berichten, was Vergleichstests mit praxisnahen Testdaten ergeben. Dabei werde ich Testdaten verwenden, die allgemein bekannt und als geeignet angesehen sind (z.B. die von Gilchrists Archive Comparison Test).

Ich zweifle allerdings jetzt schon, die komplette Software (inklusive aller "Plugins" zur Analyse bestimmter typischer Datenquellen) erfordert einen Download eines Installers von fast 17 MB! Da war 7-zip doch etwas kleiner...

hast Du den Installer runterladen können? Die schreiben zwar es kommt mal ne Mail mit der URL, aber bis jetzt 0.

Vielleicht auch drauf achten das die Dateien nach dem dem entpacken noch bitgleich sind. Nicht das man da eine verlusbehaftete Kompression untergschoben bekommt , wie bei UHA.

Ich habe mittlerweile den Komplett-Installer 2x heruntergeladen. Und zusätzlich noch die Einzel-Installer. Aber: Sie alle stürzen bei mir sofort bei Aufruf ab (die Installer - allesamt)! Bisher also noch kein Testen möglich.
__

Wo konkret komprimiert UHA mit Verlusten?

Inzwischen wurde herausgefunden, dass diese "bahnbrechnede" Technologie ausschließlich aus verschleierter GPL Software zusammengeschustert ist.

http://forum.doom9.org/showthread.php?t=109709

:nein:

Um genau zu sein:

Zitat

Look, the big sh*t, the program uses the nexts tools:

The *.pack files in the Data folder are infact .exe's and .dll's packed with UHARC with password:
aud2lan.exe: Monkey's Audio Console Front End (v 4.01)
audlan.exe: Lossless Audio Compressor 0.4b
biglan.exe: SBC Archiver 0.970
bmplan.exe: BMF 1.1
classlan.exe: J.Class Optimizer for Windows. Version 1.00
convlan.exe: ImageMagick 6.2.4 09/10/05 Q16
exelan.exe: UPX 1.93 beta
fastlan.exe: gzip 1.2.4 Win32 (02 Dec 97)
jpeglan.dll: library and tools for JPEG images
lan2.exe: DURILCA v.0.4b
lan2plus.exe: Monstrous PPMII compressor based on PPMd var.J, Feb 16 2006
lannor.exe: DURILCA v.0.4b
lannor1.exe: Fast PPMII compressor for textual data, variant J, Feb 16 2006
lanpack.exe: 7-Zip 4.31
mplan.exe: LAME version 4.0 (alpha 14, Sep 25 2005 10:04:14)
palan.exe: PAQ 8g
pgmlan.exe: photo PGM(P5) <=> BMF file convertor, v.2.0
swflan.exe: flasm 1.52 build Sep 30 2004
wtlan.exe: Infima Tranformer 1.0 - Word Replacing Transformation, rebuild of WRT
pdflan.exe: pdftk 1.12
pnglan.exe: InfimaPNG 1.0: Infima Advanced PNG optimizer, rebuild of Optipng
imglan.exe: fCoder Batch Converters
vidlan.exe: FFmpeg version CVS
Nandub.exe

Password: Infima_xxx_Compression_Plugin
Change xxx with name of .pack file.

Alles anzeigen

Ja, suuuuuuper! :ani_lol:

Mal lesen, wie die die Archive überhaupt entpacken konnten...

wie 'UHA' ist verlustbehaftet?
habe ich jetzt meine ganzen daten zerstört?

Also ich hab jetzt doch mal gesucht, konnte aber keinerlei Hinweise finden, dass uharc verlustbehaftet wäre, oder einen solchen Modus hätte.

Eastermeyer: Kannst du das mal klarstellen (Revidieren oder Bestätigen durch Links)?

Jetzt vertraut doch nicht alle soviel auf meine Aussagen
Also ich glaube (~40%) das es in UHA eine sogenannte Multimedia-Kompression besitzt , welche verlusbehaftet , z.B. mit MP3 arbeitet. Aus diesem Grund lässt sich ja z.B. GTA3 mit UHA auf ~250 MB packen.

Ich begebe mich mal auf die Suche nach "Beweisen"...

Zitat von Eastermeyer

Multimedia-Kompression

Die gibt es. Stellt sich nur die Frage, ob sie verlustbehaftet ist. Bzw. wie genau sie funktioniert. (Erkennung von Multimediadaten (Audio, Bilder, Video) und bei diesen dann verlustbehaftete Kodierung?)

Ich such mir jetzt nen paar "Multimedia-Dateien" , packe sie , und vergleiche danach mit fc.
Selbst ist der Mann

WAV:

DAE2B5B02D19663C413D7E77CAD9C1CF Iron Maiden - The Number Of The Beast.wav 57.960.380 Bytes9B292F46EA811F1B26477641111AD615 Iron Maiden - The Number Of The Beast.uha 42.708.227 BytesDAE2B5B02D19663C413D7E77CAD9C1CF Iron Maiden - The Number Of The Beast.wav 57.960.380 Bytes

Kein Unterschied.

BMP:

94ACB6B4D39CBDAAB4154D482AD7E7D5 test.bmp 27.525.510 Bytes
D1EA3C60399145A57FBAE1F4469F261C test.uha 17.738.046 Bytes
94ACB6B4D39CBDAAB4154D482AD7E7D5 test.bmp 27.525.510 Bytes

Kein Unterschied.

Ich glaube , ich hatte wohl unrecht.

Scherzkeks - Originaldaten und Archiv vergleichen...

Man vergleich doch die Originaldatei mit der komprimierten und wieder entpackten Datei, aber nicht mit dem Archiv!

Tu ich doch auch.
Erste Zeile und letze Zeile.

Vor 11:00 jedenfalls noch nicht! :so-nicht:

Zitat von LigH

Vor 11:00 jedenfalls noch nicht! :so-nicht:

Doch, da war ein Edit um 10:52 zeitgleich mit deinem Post.

Habt ihr Mods keine Edit-Übersicht?

puh, da habe ich nochmal glück gehabt *puh*

Zitat von LigH

... { Genug Theorie... }

Es gibt kein zufiel an Theorie, LigH. Danke für die erklährenden Worte! Hier ist eine ausgezeichnete Seite die das sehr gut beschreibt:
http://www.data-compression.com/theory.html

Zitat von LigH

Aber im Allgemeinen müsste eine MP3-Datei, die hörbares Material enthält, beispielsweise derart unterschiedliche Daten enthalten, dass sie (ohne Kenntnis des Inhaltes) als "guter Rauschgenerator" verwendet werden könnte, denn sie enthält bereits das Ergebnis einer Entropiecodierung (Huffman), und deren Ergebnis-Bitstrom ist nachweislich recht zufällig verteilt. { Sorry, doch noch etwas Theorie zwischendurch. }

Na, da ist mir /dev/random als Zufallsgenerator doch lieber.:ani_lol:

Jede Aufzeichnung natürlicher Signale ist aus Sicht der Kryptografie eine bessere Zufalls-Quelle als jeder Algoritmus, der Zufälligkeit simuliert.

Aber wie auch immer:

1) Komprimierbarkeit ist endlich.

2) Mißbrauch von Freeware ist strafbar.