Block Kompremierung

[Christian O. (reflexx)]

Hallo zusammen,

hat vielleicht jemand Erfahrung mit der Kompremierung und 
Dekompremierung von Datenblöcken?

Konkret folgender Fall:

µController tastet mit 8-Bit Auflösung und 11025hz Sprache über den 
internen Ad Wandler ab (Microfon).
Bei 250 Samples wird das Frame in einen TCP-UDP Rahmen kopiert und als 
Broadcast an andere Stationen gesendet.
Das funktioniert alles, und man kann die Sprache auch gut verstehen.

Allerdings nur, wenn auch mit der entsprechenden Lautstärke gesprochen 
wird.
Um die Tonqualität noch zu verbessern, wollte ich gerne auf 10 Bit 
Auflösung  gehen.
Das Problem, nu brauche ich 2Bytes pro Sample, und das bekomme ich mit 
dem Controller gerade nicht mehr übers Netzwerk weg.

Kennt jemand (möglichst freie) Algo's um so einen Block zu kompremieren, 
und am Empfänger wieder zu dekompremieren? das ganze halt in Echtzeit.

Ich erwarte nicht den Frame auf 10% zu packen, sondern vielleicht um 
10-20%. Das könnte dann gerade reichen.

Aber vielleicht bin ich auch auf dem Holzweg, und das Berechnen dauert 
viel zu lange?


Hardware ist ein 32Bit UC3 - Series ohne FPU




Gruß Ch.O

[Marek N. (Gast)]

Differenzielle Kodierung, d.h. nur die Unterschiede zwischen 
benachbarten Sampels übertragen.
Aber 10 Bit wird dir nichts bringen. ISDN quantisiert mit 8 Bit und 8 
kHz und niemand beschwert sich. Das Geheimnis ist die nichtlineare 
Dynamik-Kompression.

Beste Grüße, Marek

[Karl H. (kbuchegg)]

Bei 250 Sampels pro Frame könntest du mal versuchen nicht die Samples 
selber zu übertragen, sondern

a) den ersten Samplewert
b) für alle weiteren 249 Samples immer nur die Differenz zum 
vorhergehenden Wert.

[Falk B. (falk)]

@ Marek N. (bruderm)

>Aber 10 Bit wird dir nichts bringen. ISDN quantisiert mit 8 Bit und 8
>kHz und niemand beschwert sich.

Nicht ganz.

>Das Geheimnis ist die nichtlineare
>Dynamik-Kompression.

Genau. Dabei wird aber zuerst mit 12 Bit quatisiert und dann nichtlinear 
komprimiert. Im einfachste Fall mit einer passenden Tabelle mit 4096 
Einträgen a 8 Bit.

http://de.wikipedia.org/wiki/A-law

[Christian O. (reflexx)]

Erstmal danke für die Antworten.

Bei der Differenz fehlt mir noch die Vorstellung der Organisation.

Beispiel:
Also erstes Byte im Frame sagen wir Wert 700, nächstes Sample ist auch 
700, also  Differenz 0. die nächsten 2 Samples unterscheiden sich 
angenommen auch nur minimal.

ergibt also z.B als Frame

1+2 Byte 700
3tes Byte 0

jetz muß irgendeine Kennung kommen um am Ziel zu wissen, dass das 
nächste Sample kommt, und kein 2 Byte Wert.
Wie soll ich da "sparen"?

ich kann natürlich auch die 10 Bit immer aufschieben, so dass ich nicht 
16 sondern 10 bit pro sample nehme.

Ich glaube aber nicht, dass das rumgeschiebe an jedem Sample schneller 
ist.

[Christian O. (reflexx)]

@ Falk

danke für den Link, danach habe ich schonmal gesucht, aber es nicht 
gefunden.
Werde ich mir mal in Ruhe ansehen, ob sowas auf dem Controller anwendbar 
wäre.


Gruß Ch

[holger (Gast)]

Such mal nach ADPCM. Das bekommt auch ein AVR noch hin.
Ich glaub da gab es auch mal eine AppNote bei Atmel.

[Falk B. (falk)]

@ Christian O. (reflexx)

>jetz muß irgendeine Kennung kommen um am Ziel zu wissen, dass das
>nächste Sample kommt, und kein 2 Byte Wert.

Der 1. Wert ist immer 10 Bit, also 2 Byte
Die Differenz wird IMMER als 8 Bit vorzeichenbehaftet kodiert, fertig.

>ich kann natürlich auch die 10 Bit immer aufschieben, so dass ich nicht
>16 sondern 10 bit pro sample nehme.

Geht auch, wobei man eher nicht schiebt sonder clever zusammenkopiert. 
Z.B. 3:2, sprich 12 Bit / Sample, wobei 2 Samples je in 3 Bytes kopiert 
werden. Das ist recht einfach mit moderatem Rechenaufwand machber.

[Maik M. (myco)]

Vielleicht helfen dir diese beiden:
http://de.wikipedia.org/wiki/%CE%9C-law
http://de.wikipedia.org/wiki/A-law

Diese wurden unteranderem für genau deine Problemstellung geschaffen, 
und haben sich bewehrt.

Edit: gerade gesehen, dass Falk auch darauf verwiesen hat.