J
John_Lennon
- Registriert
- 23.12.11
- Beiträge
- 1.398
- Reaktionen
- 1.250
- Punkte
- 5.159
Dann will ich das mal auflösen:
Ich hatte meine letzten Postings gestern Abend auf der Couch mit dem Smartphone geschrieben und offenbar sind die Smileys dabei abhandengekommen. So klingt mein Posting an dich viel patziger, als es eigentlich gemeint war.
Ich hatte eigentlich augenzwinkernd 7- und 14-Bit Integer erwähnt, weil ich dachte, dass dann jeder hier sofort weiß, was gemeint ist: MIDI nämlich.
Das ist nämlich auch ein Beispiel dafür, dass in einem Plugin ganz unterschiedliche Datentypen und Zahlenformate benutzt werden können. Niemand wird einen simplen Button mit zwei Zuständen als 32- oder gar 64-Bit Float Wert codieren, es gibt immer mehrere Datentypen und Zahlenformate in einem Plugin parallel und die haben wiederum zunächst nichts (oder wenig) mit dem Adressraum zu tun. Darauf wollte ich hinaus.
Ein konkretes Beispiel: Ein Sampler wird als 64-Bit Plugin zunächst mal einen 64-Bit Speicherraum adressieren, was auch nötig ist, wenn das Plugin Librarys mit mehr als 4 GB laden soll. Die einzelnen konkreten Samples an sich liegen aber mit maximal 24-Bit im Speicher, werden von MIDI-Daten in 7-Bit Auflösung getriggert und als 32-Bit Float Wert in den Puffer geschrieben, den der Host dem Plugin zur Verfügung stellt. Wenn das Plugin nun eine 64-Bit Float Audioengine unterstützt, dann schreibt es den Wert halt in einen 64-Bit Puffer und füllt die Leerstellen mit Nullen auf, mehr passiert da nicht. Schon 32-Bit Float würde mehr als ausreichen, um den Wert des Samples darzustellen, eine Erhöhung der Bittiefe bringt da überhaupt nichts, außer dass man einen Haufen zusätzlicher Nullen über den Bus schaufelt. Damit erklärt sich auch der leichte Anstieg der benötigten Rechenleistung, die @Realist bei seinem Test festgestellt hat. Eine 64-Bit CPU mit ihren 64-Bit Registern rechnet im Idealfall einen 64-Bit Wert genauso schnell wie einen 32-Bit Wert (bzw. in der gleichen Zahl der Taktzyklen), so dass man an der Stelle keinen Nachteil hat, aber auch keinen Vorteil. Allerdings schiebt man eben doppelt so große Datenpakete über den Bus und das passiert nicht "kostenlos".
Bei einer Audiospur ist das nicht viel anders: Auch hier liegen die Ausgangsdateien mit maximal 24-Bit Integer im Speicher und werden in 32-Bit Float umgewandelt, bevor sie dann in dem Format durch die einzelnen Bearbeitungsstufen gereicht werden. Dabei reicht der Zahlenraum von 32-Bit Float in der Praxis völlig aus, um auch hunderte von Kanälen zu addieren, ohne an die Grenzen des Datenraums zu kommen. Eben deshalb hat man ja 32-Bit Float überhaupt als Format für moderne Mix-Engines genommen.
Das Gegenteil wäre eine Fixed-Point Audio-Engine, wie bei Pro-Tools TDM. Da spielt es tatsächlich eine Rolle. Das Datenformat der Kanäle und Plugins war da durchgehend 24-Bit Integer (für Audio, Buttons haben die damals auch schon nur binär codiert
). Das Format ergab sich durch die native Auflösung der Motorola DSPs. Da man hier aber ohne große Mühe schon die Kanäle übersteuern konnte (im Gegensatz zu 32-Bit Float, wo das quasi unmöglich ist), brauchte man für den Bus eine höhere Auflösung. Es ist sehr lange her und ich habe das nicht mehr im Detail im Kopf, aber ich meine, der TDM Bus hätte mit 48-Bit Integer summiert.Fixed- und Float Summierung musst du ganz sauber trennen und da liegt auch der Denkfehler, den du machst - glaub' ich wenigstens. Um es mal plastisch auszudrücken (auch wenn folgender Vergleich hinkt wie alle Vergleiche): Eine Fixed-Point Engine besteht aus vielen Wassereimern (Kanälen) mit einem festen Fassungsvermögen in Litern (Bittiefe). Wenn die Eimer nun halbvoll sind, dann braucht man schon ab dem dritten Eimer (Kanal) ein größeres Zielgefäß (Master), wenn man alles zusammenkippen (Summierung auf dem Bus) will.
Float Summierung dagegen besteht nicht aus festen Eimern, sondern aus elastischen Ballons, die sich zusammen mit dem Inhalt flexibel ausdehnen und wieder zusammenziehen können. Du nimmst da als Zielgefäß den gleichen Wasserballon, der sich dann eben entsprechend ausdehnt.
An der Stelle werden jetzt alle, die Kinder haben und mit Wasserbomben spielen, sagen: Aber irgendwann platzt jeder Ballon. Das stimmt, auch 32-Bit Float hat Grenzen. Allerdings sind die so weit, dass man im Alltag nie an den Rand kommt. Oder anders ausgedrückt: Man hat einfach nie so viel Wasser, dass der Ballon platzt.
Warum dann der Sprung auf 64-Bit Float? Gibt es dafür überhaupt eine sinnvolle Anwendung? Für die allermeisten Processing-Arten und Algorithmen nicht. Wenn ich einen beliebigen Algorithmus auf eine 24-Bit Integer Zahl loslasse, dann passt das Ergebnis 99 Prozent der Fälle in die Grenzen von von 32-Bit Float, weshalb die Algorithmen auch in einer 64-Bit-Float-Engine effektiv in der 32-Bit Auflösung bleiben. Mathematisch kann man natürlich auch die 32-Bit-Grenzen beliebig sprengen, nur hat das für Audioalgorithmen keine Bedeutung, es sei denn, man versteht unter "Processing" die Erzeugung von DC am Ende des Zahlenbereichs
Als einzigen theoretischen Anwendungsfall wird in der Literatur (und DSP-Foren) immer wieder Hall genannt. Da kann man tatsächlich die Auflösung beliebig hochfahren und auch 64-Bit locker mit etwas sinnvollem vollschreiben. Das wurde auch ganz früher tatsächlich mal gemacht (ich erinnere mich an ein Hallplugin auf der Pulsar/Scope Plattform, das auf 64-Bit Präzision umschaltbar war). Der praktische klangliche Nutzen ist aber fraglich, denn eines muss man immer im Hinterkopf behalten und damit komme ich dann am Ende zu dem Thema des Threads zurück:
Nach dem Master muss alles am Ende wieder zu 16-Bit Integer werden (CD) oder maximal 24-Bit (Wiedergabe über den Wandler). Und dazu werden all die vielen schönen Bits mit den unglaublich präzise ausgerechneten Daten ganz schnöde abgeschnitten. Dithering ändert daran nichts, das streut nur ein bisschen Rauschen ein, damit bei voller Ausnutzung der 16-Bit Dynamik, sich ganz leise Signale nicht aus den Quantisierungsartefakten erheben (oder darunter begraben werden), sondern aus Rauschen und das ganz einfach besser klingt. Aber selbst das ist bei der Aussteuerung, die wir hier typischerweise verwenden, völlig irrelevant. Wir sind einfach nicht leise genug, damit Dithering überhaupt eine Rolle spielt.
Wenn man also den Masterfader runterzieht, dann ist das eine simple Multiplikation mit einem Zahl kleiner 1. Die 32-Bit Float Auflösung reicht locker, um das ohne Probleme auszurechnen. Wenn es nämlich Rundungsfehler gibt, dann spielen sich diese in den Nachkommastellen ab, die bei der Konvertierung in Integer und der Bitreduzierung sowieso wegfallen. Der Integer-Wert, der dann tatsächlich am Ende ausgegeben oder in eine Datei geschrieben wird, bleibt davon unberührt. Er sinkt ganzzahlig, keine Rundung, kein Fehler, es wird einfach nur leiser
Zuletzt bearbeitet:
