Wie addiert man digitale Audiosignale?

Müßte das dann nicht (a+b)/2 heißen?

Fließ- bzw. Festpunktkommazahlen eignen sich besser für 
Audiooperationen. Am Ende der Bearbeitungskette wird das Ergebnis mit 
einem Faktor, der Verstärkung, multipliziert.

1

float amp = 0.75;

2

3

float a = einlesen8BitA() / 255.0;

4

float b = einlesen8BitB() / 255.0;

5

6

float val = a + b;

7

val = val * amp;

8

9

ausgabe(val);

Wenn val größer als 1.0 ist, dann ist das Signal zu laut und wird 
verzerrt. Die Spitzen werden dann abgeschnitten.

Es ist bei DSP-Arithmetik nicht unüblich, dass ein Zwischenergebnis in 
einer Kette von Operationen mehr Stellen hat als Operanden und 
abschliessendes Resultat. Addition und Skalierung (/2) sind so 
problemlos.

NB: Bei dafür vorgesehenen Prozessoren bzw. Befehlssätzen findet sich 
häufig auch saturierende Rechnung, bei saturierender vorzeichenloser 
8-Bit Rechnung gilt 200+201=255. Das ist in dieser Frage zwar nicht 
angebracht, vermeidet aber immerhin Artefakte durch die sonst übliche 
Modulo-Rechnung.

Hallo,
auch wenn dieser Thread ziemlich alt ist, möchte ich den Beitrag noch 
ergänzen.

Und zwar wird in der Profibereich sich umschaut, geschrieben, das einmal 
paar Bit's als Überstuerungsreserve dazu gegeben werden. zusätzlich wird 
gesagt, das Pro Kanalzug, der zu mischen ist 1 Bit an das Summensignal 
angefügt wird. D.h 10 Kanäle = 10 zusätzliche Bit's, wenn es vollständig 
Digital verarbeitet werden soll.

Besser ist es, das Digitale Siganl in Anaolg zu wandeln, Abmischen und 
weitere Bearbeitung und dann das Mischprodukt wieder Digitaliesieren.
Somit werden auch Phasenfehler vermieden.

> das Pro Kanalzug, der zu mischen ist 1 Bit an das Summensignal
> angefügt wird. D.h 10 Kanäle = 10 zusätzliche Bit's, wenn es vollständig
> Digital verarbeitet werden soll.

Das macht irgendwie keinen Sinn... Bei 8 Bit signed wäre der Maximalwert 
10*-128=-1280, d.h. man kommt mit 12Bit signed (-2048...2047) gut aus, 
also 8+ceil(log2(10)).

André H. schrieb:
> zusätzlich wird gesagt, das Pro Kanalzug, der zu mischen ist 1 Bit an das
> Summensignal angefügt wird.

Ein Bit pro Verdoppelung der Kanalzahl wäre ausreichend. Bei 16 Kanälen 
also z.B. 4 zusätzliche Bits.

Mano W. schrieb:
> Fließ- bzw. Festpunktkommazahlen eignen sich besser für
> Audiooperationen.
Wieso? Audio ist nur EINE Form von Signalverarbeitung und ob sich eine 
bestimte Art der Berechung einfacher oder besser darstellt, hat doch 
nichts mit dem Kontext zu tun, sondern einfach damit, auf welcher 
Plattform man arbeitet. In DSPs mag es einfacher sein, FP zu benutzen, 
weil es einen CO-Pro gibt. Dennoch arbeiten viele Audiosysteme mit 
festen Integerwertbreiten.

Zudem ist die Fragestellung damit noch nicht wirklich angegangen:

André H. schrieb:
> auch wenn dieser Thread ziemlich alt ist, möchte ich den Beitrag noch
Das Thema ist noch älter, als der Thread und zwar ungefähr 10x so alt!

Selbstredend ist es so, daß sich die Amplituden erhöhen, wenn sich 
Signale mischen (= addieren!), sonst würde es auch nicht lauter werden 
;-) - das hat weder was mit Analog noch Digital zu tun. In beiden Fällen 
gibt es damit das Problem der Übersteuerung und um die zu vermeiden, 
brauche ich an jeder Stelle einen ausreichenden headroom!

Das gilt für das Eingangssignal, das in der Regel NICHT die volle 
mögliche Bitbreite belegt und auch das Ausgangssignal

> D.h 10 Kanäle = 10 zusätzliche Bit's, wenn es vollständig
> Digital verarbeitet werden soll.
Da müssen wir nochmal nachdenken:

Wenn man z.B. 16 Kanäle addiert, kommt als maximales Ergebnis die 
16fache Vollausteuerung raus. Das sind bei mir dann "nur" 4 Bit mehr!

> Besser ist es, das Digitale Signal in Analog zu wandeln, Abzumischen
> und die weitere Bearbeitung und dann das Mischprodukt wieder
> Digitalisieren.
Abgesehen von der Rechtschreibung, die ich mir im Zitat erlaubt habe, zu 
korrigieren D: sind da zwei Fehler drin: 1. Es gibt hier keine 
"Mischprodukte". Die gibt es beim Mischen in Form der Multiplikation, 
die aber beim Audio nur beim Vibrato auftritt und somit auch kein 
Problem aufwirft, da die beiden Frequenzen weit auseinander liegen. 
Vibrato liegt im Bereich von 5Hz abwärts.

> Somit werden auch Phasenfehler vermieden.
... 2. sind Phasenfehler kein Problem digitialer Mischungen und ich 
wüsste auch nicht, wo die hier aufträte, sodaß sie zu vermeiden wäre. 
Eher schon bringen zusätzliche Wandlungsschritt Latenzen und damit 
Probleme, mehre Quellen und Pfade sychron zu halten, die nur teilweise 
durch einen DSP laufen und teilweise noch durch einen Analogkette 
sollen.

Um das Thema mal zu konkretisieren:

Ein AD-Wandlersignal, wird man bei Einzelstimmen so bemessen, dass der 
Normalpegel von 80dBspl vielleicht bei einer Aussteuerung von maximal 18 
Bit von 24 liegt, was knapp 110dBfs sind. Damit hat man für Piano von 
volle 16 Bit und die hohen Resonanztöne bei z.B. dem Sopran noch 
ausreichend headroom. So gewonnenen Signal kann man schon unbearbeitet 
direkt mischen, ohne an Übersteuerungsgrenzen zu gelangen oder Auflösung 
zu verlieren. Der peak liegt bei einer solchen Einzelstimme dann bei 
vielleicht 110 dBspl und z.B. bei 135dBfs.

Nach dem Mischen mit 16 solcher Stimmen bekommt man z.B. einen 
Mittelpegel von 95dB-100dB (also nicht etwa das 16-fache von fast 
110dB). Diese 100dB sind locker ausreichend, um sie auf die 96dBfs einer 
Audio-CD zu quetschen.

Bei Mehrfachstimmen, also einem Chor kann (und muss!) man sofort mit der 
ersten Aufnahme, die 24 Bit gut treffen, z.B. lautes Einsingen das 23. 
bit ankratzen, weil sonst die Pianissiopassagen zu leise werden, um die 
16 Bit auszulasten,

Bei Klangsynthese ist es wiederum viel einfacher:

Ein sauberer Sinus braucht gerade 12bit "echte Güte", weil er mit 100 
anderen Stimmen zusammengemischt wird und damit sehr rasch die full 
scale 16 Bit einer CD erreicht werden. Daher arbeiten viele ROM-Systeme 
nach wie vor mit 16 Bit Samples an Audiomaterial und könnten trotzdem 24 
Bit Qualität erzielen, z.B. bei Orchestersamples.

c-hater schrieb:
> HildeK schrieb:
>
>> Ja und nein.
>> Ja - wenn du immer in der 8-Bit-Welt bleiben willst/musst.
>
> Nein.

Doch. S.u.


> Man muss einfach nur die richtige Sprache verwenden, dann geht
> sowas auch in der gegebenen Datenwortbreite. Weil in einer richtigen
> Sprache die CPU-Flags verfügbar sind und von kompetenten Programmierern
> auch sinnvoll gebraucht werden können.

Nun die Preisfragen:

1. Welches CPU-Flag kommt hier zum Tragen?

Hint: das Carry-Flag

2. Was macht das Carry-Flag?

Hint: es speichert den Übertrag der Addition.

3. Wie macht es das?

Hint: Der Übertrag ist ein Bit. Das Carry-Flag speichert ein Bit. 
Überraschung: es ist hier also das neunte Bit!


> Beispiel: Mittelwertbildung von zwei "unsigned" 8-Bit-Samples auf einem
> AVR8:
>
>  add reg0,reg1
>  ror reg0
>
> Zwei Takte und das Äquivalent von C'isch (a+b)/2 ist schon fertig...

Es ist davon auszugehen, dass dieser Term in C zu genau jenem 
Assemblercode führt...

Mathias A. schrieb:
> Hint: Der Übertrag ist ein Bit. Das Carry-Flag speichert ein Bit.
> Überraschung: es ist hier also das neunte Bit!

Es bleibt aber immer das Problem, dass zwei Signale insgesamt die 
doppelte Amplitude liefern können und damit die Auflösung, die ja hier 8 
Bit sein soll, beschränkt ist. Also geht Dynamik dahin.

Jürgen S. schrieb:
> Mathias A. schrieb:
>> Hint: Der Übertrag ist ein Bit. Das Carry-Flag speichert ein Bit.
>> Überraschung: es ist hier also das neunte Bit!
>
> Es bleibt aber immer das Problem, dass zwei Signale insgesamt die
> doppelte Amplitude liefern können und damit die Auflösung, die ja hier 8
> Bit sein soll, beschränkt ist. Also geht Dynamik dahin.

Das stimmt. Meine Antwort bezog sich auf das Posting von c-hater, der 
meinte dass man mit Assembler den Mittelwert zweier 8-Bit-Werte 
berechnen, und dabei innerhalb 8 Bit bleiben könne. Das stimmt so eben 
nicht, da durch das Carry ein neuntes Bit dazukommt. Bzw es ist in C 
genauso, auch da kommt in dem Fall das neunte Bit dazu, ohne dass man 
Datentypen mit mehr als 8 Bit verwenden müsste.

Mathias A. schrieb:
> Das stimmt. Meine Antwort bezog sich auf das Posting von c-hater,

…das er vor 3 Jahren verfasst hat…

> der meinte dass man mit Assembler den Mittelwert zweier 8-Bit-Werte
> berechnen, und dabei innerhalb 8 Bit bleiben könne. Das stimmt so eben
> nicht, da durch das Carry ein neuntes Bit dazukommt.

Er hat eigentlich nirgends behauptet, dass seine Berechnung das 
Carry-Flag nicht benutzt.

> Bzw es ist in C genauso, auch da kommt in dem Fall das neunte Bit dazu, ohne
> dass man Datentypen mit mehr als 8 Bit verwenden müsste.

Wie soll das denn funktionieren?

Beim Mischen sorgt man In der Regel für einen Headroom von 6db dann 
passt das auch nach der Addition ob nun 8bit oder mehr. 6db ist halber 
Pegel somit passt das Ergebnis wieder zur Bitbreite ganz ohne Clipping.

Jens U. schrieb:
> Rolf M. schrieb:
>>> Bzw es ist in C genauso, auch da kommt in dem Fall das neunte Bit dazu, ohne
>>> dass man Datentypen mit mehr als 8 Bit verwenden müsste.
>>
>> Wie soll das denn funktionieren?
>
> Impliziter Überlauf?

Was meinst du damit?
Abgesehen davon werden in C alle Berechnungen automatisch mindestens mit 
int durchgeführt. Man kann also gar nicht verhindern, dass ein Datentyp 
mit mehr als 8 Bit verwendet wird.

Thomas Z. schrieb:
> Beim Mischen sorgt man In der Regel für einen Headroom von 6db dann
> passt das auch nach der Addition ob nun 8bit oder mehr. 6db ist halber
> Pegel somit passt das Ergebnis wieder zur Bitbreite ganz ohne Clipping.

Allerdings nur dann, wenn du dich darauf beschränkst, nur genau zwei 
Signale zusammenzumischen.
Am Ende ist es aber auch eigentlich egal, ob du das Bit schon von vorne 
herein ungenutzt lässt, indem du 6 dB Headroom lässt oder ob du vor der 
Addition das Bit entfernst durch Division durch 2.