Außerdem kann man in jedem Ort, wo es Modems gibt, auch ISDN beziehen Und da kann man ja wenn es mal schnell gehen muss, beide Kanäle zuschalten und kommt dann immerhin auf 128 kbit/s...

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Na ich denke mal man kann mit gutem Gewissen alle Formate benutzen die Winrar entpacken kann ... denn wer benutzt noch das originale WinZip??? also ich kenne da niemanden (außer unsre Schule, aber da is auch alles schon restlos veraltet )

Und zur Not kann man auch entsprechende Downloadlinks für die Entpacker bereitstellen so wie es doch auch dauernd mit PDF-Dateien gemacht wird ...

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

also ich benutz das gute alte Winzip noch recht häufig Winrar bietet einfach kein Drag&Drop und das vermisse ich nunmal schmerzlich

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Also ich benutz es zwar nicht, aber Winrar unterstützt auch Drag n Drop ...
Aber davon mal abgesehen entnehme ich deinem Post, dass du Winrar trotzdem besitzt und somit in der Lage bist nicht-zip-archive zu entpacken ... und das is ja eigentlich das wichtige

_________________
Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)

Jaja, streu nur noch mehr Salz in meine Wunden, Phobeus... was würde ich tun für DSL 16000, nein, für DSL 3000, nein, für DSL 2000, nein, für DSL 1000, nein, für DSL 768, nein gebt mir doch wenigstens DSL Light....

_________________


"User Error. Replace User and hit Continue."

Es ist doch eigentlich egal wer was besser hält, da Extrawurst ja auf kompremierungstärke und nicht auf geschwindigkeit aus ist. Hierfür finde ich sind bzip und zlib mit einer wavelet datenconvertierung am besten geeignet.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also nun muss ich doch mal meinen Senf dazu geben. Der Begriff wavelet hat mich ständig gestört und ist für verlustfreie Kompression ziemlich ungeeignet. Sie treten bei der Fouriertransformation/Synthese auf und sind eine spezielle Basiswahl, um Wellenformen zu speichern - exzessiv eingesetzt z.B. beim MP3 Format.
Bzip arbeitet auf Blockumsortierungen und Huffman Kodierung. Zlib arbeitet auf einem ähnlichem System, aber den "Technical Details" ist kein Name zu entnehmen. Ich hab ihn jedenfalls nicht entdeckt.

Wenn man wavelet Bildcompremierung z.B. bei Jpeg2000 verwendet wird folgendes gemacht.
Es werden jeweils zwei 2bytepaare genommen, es wird der durchschnitt des 1. Wertepaars und dann der des 2. errechnet.
Also sind die neuen erste 2 bytes der durchschnitt vom 1. und 2. Bytepaar, dann werden die durschnittswerte mit dem jeweiligen ersten byte jedes Bytepaares subtrahiert und man bekommt den offset. Wenn man nun die offsetwerte grafisch darstellen würde hätte man eine Wellenartigen Graphen(eventuell). Diese prozedur kann man nun mit den kompletten daten machen und dies auch beliebig oft. Gebracht hat es bis hier garnichts da unsere Daten genauso groß bis im schlimmsten fall doppelt so groß sind. Wenn man sich die Daten in gesammten ansehen würde, nachdem man diese berechnung ein paar mal gemacht hat fällt auf das sich nun die offset extrem häufig ähneln. Grund ist mit jeder weiteren Iteration werden alle Zahlen immer kleiner, da sie mit den offset dann verrechnet werden.

Jpeg2000 benutzt ja eine verlustbehaftete blockcompremierung diese wird nun auf die daten angewandt und da die Daten vorher verändert wurden wirkt sich dies nicht groß sichtbar aus. Erstmal wird festgelegt ab wann ein wert zu 0 abestufft wird z.B. 0,3. Nun geht man alle werte durch und offsets die unter 0,3 liegen werden 0. Wenn man später die zahlen zurück rechnen würde hätte man zwar andere zahlen aber die weichen, bei diesem Schwellenwert, so wenig ab das es kaum auffallen sollte. Wo nun jedemenge nullen und sowie mehrfaches vorkommen anderer niedriger Zahlen haben kann ein algorythmus der auf wiederholung basiert viel reißen und einer der auf Muster basiert würde das Bild auf eine größe bringen die ist schon lächerlich.

Meine versuche mit Png,jpeg und einem Wavelet based Format endeten damit das ich mit so gut wie keinen verlust die größe von png ung jpeg locker unterbot. Ausserdem ist die gebrauchte zeit um das bild in RGB für opengl umzuwandeln auch gering größer.

Dies war ne verlust behaftete kompremierung, was bei ein archive nicht sein darf aber selbst wenn man keinen Schwellenwert nutzt, um eventuelle Kommawerte zu vermeiden, so sind die daten doch effektiver zu kompremieren.
Jpeg 2000 hat noch zig Technicken intus die dank Wavelet möglich sind. So ist z.B. eine Wertereihe die fehlerhaft im Speicher ankam nicht so dramatisch wie bei anderen formaten, da zwar der fehler sich durch das ganze bild zieht aber wenig auffällt. Ein weißer Block im Bild fällt schon auf aber etwas hellere Pixel im Bild nimmt man weniger war.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004