kompression von audiofiles

pointercrash() schrieb:

Schon Gegentest mit White Noise und Pink Noise gefahren? Damit kannst Du ausschließen, einer besonderen spektralen Verteilung aufzusitzen.

nee, muss ich aber unbedingt noch machen. das einzige in der richtung war mal der output des einfachen Java zufallsgenerators Math.random(), den ich transformiert und mir das ergebnis optisch angeschaut habe. das sah übrigens ganz und gar nicht mehr wie der output eines zufallsgenerators aus. nach der rücktransformation aber schon. aber ehrlich gesagt, war das alles nur fummelei, ohne jede aussagekraft (übrigens noch bevor ich auf die idee gekommen bin, das zeug zu komprimieren). so richtig getestet habe ich noch nichts.

pointercrash() schrieb:

Welche Optionen schaltest Du bei Winrar zu, welche Optimierungsstufe? WinRar setzt ja eine ganze Latte unterschiedlicher Kompressionsverfahren ein - welche kommen bei Dir zum Zug?

ich klicke immer auf 'best'. welches kompressionsverfahren nimmt er da? oder sucht er sich eins aus?

pointercrash**

~fricky schrieb:

ich klicke immer auf 'best'. welches kompressionsverfahren nimmt er da? oder sucht er sich eins aus?

Mal alles oben ausgenommen, nö, er probiert durch bis auf eine bestimmte Wordbooklänge bzw. Hashtable, ab da wird's kryptisch.

Was machen eigentlich 7Zip, Zippy&Co aus Deiner Dateiwurst?

pointercrash() schrieb:

Was machen eigentlich 7Zip, Zippy&Co aus Deiner Dateiwurst?

weiss ich auch noch nicht, aber das finde ich erstmal nicht interessant. reicht ja, wenn ein packer die datei in 0.83 prozent der vorherigen grösse pressen kann.

btw, was ich auch mal probiert habe: ich hab' ja durch mein verfahren eine folge von 16-bit samples, die sich von ihren nachbarn minimal unterscheiden. also hab' ich mal probiert, erst alle low- und dann alle high bytes zu speichern, in der hoffnung grössere bereiche von gleichen werten zu haben. das ist auch so (zumindest bei den high-bytes), aber trotzdem ist dann das packergebnis schlechter (etwa um 1kB).

Neulich rief mich Harry an und sagte, daß er fliegen kann.
Ich sprach: "Das ist doch glatt gelogen!"
Da flog er los. Er flog ein Stück, doch dann brach er sich das Genick,
und das kommt nur von diesen Drogen.

Oder Ähnlich...
Was nimmst du für Zeug?

dadrinkichdochliebertee schrieb:

Was nimmst du für Zeug?

hehe, das habe ich mich auch gefragt, als ich die dateigrössen verglich. aber dieses eine file wurde definitiv extrem zusammengequetscht. klar, irgendwo muss da ein haken sein. ich mach mal ein paar tests (vielleicht morgen schon). z.b. werde ich ein .wav file mit daten füllen, die das da ausspuckt: http://java.sun.com/j2se/1.4.2/docs/api/java/security/SecureRandom.html
ich wette, dabei versagts. aber warten wir's mal ab.

rapso

du willst random signale komprimieren?

wenn das geht, kannst du mit deiner transformation sicher auch das komprimierte signal komprimieren und das wieder komprimieren. erzaehl uns dann deine glanzleistung, was das letzte byte ist was rauskommt. ich wette 42

hustbaer

ROFL
Einer der dümmsten Threads des Jahres.

Ich bau mir jetzt übrigens nen Apparat mit dem ich mich selbst auf unter Handtaschengrösse komprimieren kann. So kann ich dann im Flugzeug ohne Ticket im Handgepäck meiner Freundin mitfliegen. Ungemein praktisch.
Nächstes Jahr kommt dann Version 2 dran, mit dem ich mich auf Briefmarkengrösse schrumpfe - dann schick ich mich einfach per Postkarte nach Hawaii.

Knuddlbaer

rapso schrieb:

ich wette 42

rapso schrieb:

erzaehl uns dann deine glanzleistung, was das letzte byte ist was rauskommt. ich wette 42

wenn man's auf die spitze treibt, könntest du recht haben.
hier mal ein paar testwerte...

schon erwähntes musikstück
--------------------------
original: 1,94 MB (2.039.808 Bytes)
gepackt: 816 KB (835.584 Bytes)
transformiert und gepackt: 17,2 KB (17.679 Bytes)

sinussignal
-----------
original: 1,83 MB (1.921.024 Bytes)
gepackt: 1,46 KB (1.505 Bytes)
transformiert und gepackt: 22,6 KB (23.172 Bytes) <--- schlechter!

und jetzt, - festhalten -

java SecureRandom
-----------------
original: 1,83 MB (1.920.044 Bytes)
gepackt: 1,39 MB (1.460.108 Bytes)
transformiert und gepackt: 30,7 KB (31.499 Bytes) <--- 42 oder was?

die files findet ihr hier:
http://www.mediafire.com/?sharekey=e25205bbef49eb94d2db6fb9a8902bda

rapso

~fricky schrieb:

rapso schrieb:

erzaehl uns dann deine glanzleistung, was das letzte byte ist was rauskommt. ich wette 42

... <--- 42 oder was?

mein held, du solltest das rekursiv machen.

Unix-Tom

dann erstelle mal ein programm um deine musik wieder zurückzutransformieren.
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .

So sieht deine Musikdatei aus im Adobe Audition 3.0
das sich das so komprimieren lässt ist ja klar.
der beweis ist dann erbracht wenn du uns zeigst das daraus wieder das original wird. für meine zwecke muss es ja nicht mal ganz original werden aber zumindest annähernd.

Unix-Tom schrieb:

der beweis ist dann erbracht wenn du uns zeigst das daraus wieder das original wird. für meine zwecke muss es ja nicht mal ganz original werden aber zumindest annähernd.

die originaldatei ist 'music.wav'. die zurücktransformierte datei ist 'music_inverse_frickytransform.wav'. die transformierte datei 'music_frickytransform.wav' ist nur zum packen da. die kannst du zwar abspielen, aber du wirst nix hören. die lautsprechermembran wird sich kaum bewegen.

rapso

du transformeirst zu deinem format und transformierst wieder zurueck innerhalb der applikation? also ohne sie neu zu starten?

ich seh's schon kommen

rapso schrieb:

du transformeirst zu deinem format und transformierst wieder zurueck innerhalb der applikation? also ohne sie neu zu starten?

nein, keine angst, ich kann eine transformierte datei jederzeit wieder hörbar machen. nichts bleibt im programm gespeichert, was dazu nötig wäre.

Unix-Tom

Dann Glückwunsch. Du wirst reich.

Solange aber der beweis nicht angetreten ist glaube ich nicht daran.

geloescht

Ich versteh nicht, was ihr darauf so rumhackt. So manche Transformation verbessert die Leistung einer darauf folgenden Komprimierung. Niemand hat gesagt, dass das rekursiv funktioniert.
Fakt ist nur: Ohne ein Programm, das Hin- und Rücktransformation beliebiger Audiosignale durchführen kann und das veröffentlicht wird, kann nicht nachgewiesen werden, dass es funktioniert. Es ist dem Threadersteller selbst überlassen, das entweder zu tun oder weiter belächelt zu werden.

Moin,

ich beschäftige mich selber ein bissel mit Komprimierung.
Ich habe mir mal (mit Win-Editor) die Unterschiede bei der Musik-Datei angeschaut.
Mir ist aufgefallen, dass dort keinerlei Informationen (Header) über das Ordnen stehen.
Sprich, du hast zwar die Daten geordnet (16Bit), aber keinerlei Informationen angegeben um es wieder zudekomprimieren. Solche Informationen würden sich stark vom geordneten unterscheiden, was hier nicht der Fall ist.

Aus dem Grund fällt es dem WinRAR auch sehr leicht die modifizierte Version zu komprimieren. Schreib mal 16Bit Werte von 1-65536 in eine Datei und lass die Komprimieren. Das Ergebnis ist seeehr klein.

Naja, also mich überzeugst du nicht

Unix-Tom schrieb:

Solange aber der beweis nicht angetreten ist glaube ich nicht daran.

musst du auch nicht. ich wollte euch nur mal zeigen, auf welche erstaunlichen sachen man stossen kann, wenn man etwas mit audiofiles und winrar herumspielt.

KörperKlaus schrieb:

Ich habe mir mal (mit Win-Editor) die Unterschiede bei der Musik-Datei angeschaut.
Mir ist aufgefallen, dass dort keinerlei Informationen (Header) über das Ordnen stehen.
Sprich, du hast zwar die Daten geordnet (16Bit), aber keinerlei Informationen angegeben um es wieder zudekomprimieren. Solche Informationen würden sich stark vom geordneten unterscheiden, was hier nicht der Fall ist.

warum sollte ich zusatzinformationen speichern? stell dir vor, ich hätte alle samples einfach durch 3 geteilt. dazu müsste ich auch nichts zusätzlich speichern, weil ich ja weiss, dass ich beim zurücktransformieren alles mit 3 multiplizieren muss.

KörperKlaus schrieb:

Naja, also mich überzeugst du nicht

ich überzeuge hier niemanden, aber das war mir schon klar, als ich den ersten beitrag gepostet habe. aber darum ging es mir auch nicht. ich wollte im prinzip nur wissen, ob die von mir erzielte kompressionsrate aussergewöhnlich ist, oder ob einer sagt: 'lächerliche sache, das musste nur so oder so machen, das ist ein alter hut, usw.'

rapso

geloescht schrieb:

Ich versteh nicht, was ihr darauf so rumhackt. So manche Transformation verbessert die Leistung einer darauf folgenden Komprimierung.

~fricky schrieb:

mir ist vorhin, ..., gelungen, ein .wav-file ... auf ein 120'stel, ohne hörbare verluste, zu komprimieren.

Fakt ist nur: Ohne ein Programm, das Hin- und Rücktransformation beliebiger Audiosignale durchführen kann und das veröffentlicht wird, kann nicht nachgewiesen werden, dass es funktioniert. Es ist dem Threadersteller selbst überlassen, das entweder zu tun oder weiter belächelt zu werden.

Russell's Teapot

~fricky schrieb:

warum sollte ich zusatzinformationen speichern? stell dir vor, ich hätte alle samples einfach durch 3 geteilt. dazu müsste ich auch nichts zusätzlich speichern, weil ich ja weiss, dass ich beim zurücktransformieren alles mit 3 multiplizieren muss.

Wenn du den Inhalt einer "ungeordneten Datei" ordnest und dabei bezweckst, diese Ordnung wieder in Ihr Urspuchgszustand zuversetzen ((De-)Komprimierung), aber keine Informationen über den ursprünglichen Zustand speicherst, dann weist du bzw. Programm ja nicht, wie es vorher ausgesehen hat. Hier wären also Informationen verlorengegangen.

~fricky schrieb:

ich überzeuge hier niemanden, aber das war mir schon klar, als ich den ersten beitrag gepostet habe. aber darum ging es mir auch nicht. ich wollte im prinzip nur wissen, ob die von mir erzielte kompressionsrate aussergewöhnlich ist, oder ob einer sagt: 'lächerliche sache, das musste nur so oder so machen, das ist ein alter hut, usw.'

Hey, ich wollte auch nichts dergleichen behaupten