Diskussion:Gleitkommazahlen in digitaler Audioanwendung

Statement

Ich, der Autor dieser wikipediaseite, bin auch der Autor des genannten pdfs. Ich habe diese Arbeit vor knapp einem Jahr geschrieben und hatte immer geplant, sie eines Tages Plattformen wie Wikipedia zur Verfügung zu stellen.

Wie auch auf http://www.zonque.org/sae/facharbeit/ und im pdf auf der letzten Seite beschrieben, habe ich aus diesem Grund das Werk unter die Open Content Licence gestellt. Eine andere freie Lizenz war mir zum Zeitpunkt damals nicht bekannt.

Ich bitte also, weitermachen zu dürfen ;)

Vielen Dank, Daniel Mack

(nicht signierter Beitrag von 212.202.201.126 (Diskussion) Uhrzeit, 18:04, 27. Nov. 2005‎)

Ergänzung Summenbusse

Zu vormaligen Ausführungen im Artikel, Zitat:

Mit Gleitkommaarithmetik fallen diese Effekte weniger ins Gewicht, da die zu erwartenden Rundungsfehler geringer sind und nicht davon ausgegangen werden muss, dass ein Zwischenwert den Rahmen des mit Floating-Point-Zahlen darstellbaren Zahlenraums sprengt. Allerdings können sehr kleine Werte gegenüber sehr großen bei der Berechnung verloren gehen, ein Effekt, der aber gerade in der Audiotechnik eher verschmerzbar ist, da für das menschliche Ohr sehr leise Signale von lauten Signalen meist psychoakustisch verdeckt werden.

Das genaue Gegenteil ist der Fall, wie dargelegt! Gerade die kleinen Werte werden in Gleitkommaarithmetik mit maximaler Auflösung wiedergegeben. Die Rundungsfehler bei Gleitkommaarithmetik sind nur bei niedrigen Pegeln geringer, bei höheren Pegeln überwiegen die Rundungsfehler (im Vergleich zu einer Festkommasummierung) bei weitem, bis zur Reduzierung der Bitauflösung zu 10 bit. Die zitierten Aussagen würden eine höhere Bittiefe voraussetzen, als die Bittiefe der Einzelkanäle. Eine höhere Bittiefe in Festkommaberechnung reduziert die Rundungsfehler jedoch ebenfalls. Von daher ist es nicht indiziert, die Textpassagen weiter zu verwenden.

-- Uwe Martens (Diskussion) 10:24, 6. Jun. 2016 (CEST)

Hidden bit

Der Bearbeitung des IP-Nutzers ist hier entgegenzuhalten: Es wurde nicht "die Registerbreite von AVX mit der Rechengenauigkeit durcheinander geworfen", sondern es war korrekt beschrieben, daß die jeweilige Float-Zahl auf die Registergröße konvertiert und dann z.B. von einem AMD Bulldozer intern mit 256 bit Genauigkeit berechnet wird (auch die Datenbreite hat dann 256 bit bzw. in neueren Systemen sogar 512 bit). Die neuerlich geaddeten ENs tun hier nichts zur Sache. Im übrigen wird die Einheit bit (im Gegensatz zu Byte) klein geschrieben. Nicht dargetan ist ferner, wieso der Hinweis auf den elementaren Unterschied von der Bit-Tiefe der Softwarearchitektur und der Bit-Tiefe der angewandten Gleitkommaarithmetik irrelevant wäre. Adobe Audition hat eine 64 bit Softwarearchitektur, berechnet aber mit 32 bit float, während hingegen z.B. ProTools HD (und aufwärts) und Nuendo 8 (aufwärts) mit 64 bit float berechnen.

Die Ausführungen, "diese Bittiefe sei dabei aber nur bei der Speicherung von Abtastwerden (sic!) über den Programmverlauf hinweg ausschlaggebend" bzw. "einzelne Funktionen der Anwendungen könnten intern temporär höhere Bittiefen verwenden" sind unbelegbare Spekulationen, da sich kein Programmentwickler in die Karten schauen läßt. Bestenfalls trifft dies auf alte 48 bit ProTools Mixer mit 24 bit TDM-Schnittstelle zu, die mit einem internen 56-bit Integer-Register und Shifting arbeiten. Letztlich ginge ein Shifting des Gleitkomma-Zahlenbereiches unter 0 dBFS, also eine Verschiebung der 0 dB-Marke zur Erhöhung des Headroomes, auf Kosten des Rauschspannungsabstandes. Vielmehr ist es so, daß die 0 db in den gängigen Audioeditoren auch tatsächlich 0 dBFS (Full Scale) sowie damit, entsprechend dem AES Convention Paper 7438, intern der Gleitkommerzahl 1 entsprechen (s. Adobe Audition, Monitoring der Aufnahme- und Wiedergabepegel). Die Einzelkanäle bzw. die Busse verfügen dann eben über einen Headroom, während hingegen der Masterbus auf den Export von Festkomma-Dateien ausgelegt ist und bei 0 dBFS endet. Ein Clipping tritt hier aber erst auf, wenn auch eine Datei im Festkomma-Format exportiert wird.

Das Clipping war ferner bereits in Abs. 3, Quantisierungsfehler und das "hidden bit" bereits in Abs. 4 erklärt. Der Dynamikbereich der Amplitude (einer Halbwelle) kann nur durch den veränderlichen Teil der Mantisse dargestellt werden. Die Erhöhung der Genauigkeit um 1 bit ist in allen Berechnungen bereits impliziert, da man ohne das "hidden bit" nur 22 bit Dynamik zur Verfügung hätte. Die kleinste normalisierte Zahl ist dabei wie dargestellt $2^{-126}$ · 1 (1 = hidden bit) und kann in $2^{-23}$ Schritten (also mit 23 bit Genauigkeit) erhöht werden. Ansonsten wären ja alle hinreichend mit Literatur belegten Dynamikberechnungen hinfällig und der Dynamikbereich wäre verdoppelt.

Als Anmerkung noch: Vor drei Jahren hatte ich ja einen inuse-Baustein gesetzt, habe dann aber wegen der ständigen Querelen hinter den Kulissen hier nicht mehr an dem Artikel weitergearbeitet. Zu ergänzen war noch der ohne Auflösungsverluste nutzbare Gesamtdynamikbereich in 32 bit float, was ich hiermit getan habe. Da das Verstärkungsmaß in dB ein logarithmischer wie relativer Wert ist, ergibt sich für den ohne Auflösungsverluste nutzbaren Headroom also (relativ zum Standard-Dynamikbereich) ein Dynamikbereich von lediglich 6 dB. Dargestellt werden sollen noch die jeweiligen Tabellen für 64 bit float. Das werde ich zu gegebener Zeit nachholen.

-- Uwe Martens (Diskussion) 03:14, 12. Jul. 2019 (CEST)

Ich bin empört. Meine Korrekturen wurden scheinbar mit etwas Verzögerung einfach wieder vollständig entfernt. Ich will gar nicht behaupten dass meine Änderung in Formulierung und Rechtschreibung perfekt waren, jedoch ist der status quo der Wikipedia nicht würdig. Bezüglich der angesprochenen Punkte nehme ich hiermit nochmal Stellung.

"Es wurde nicht "die Registerbreite von AVX mit der Rechengenauigkeit durcheinander geworfen", sondern es war korrekt beschrieben, daß die jeweilige Float-Zahl auf die Registergröße konvertiert und dann z.B. von einem AMD Bulldozer intern mit 256 bit Genauigkeit berechnet wird (auch die Datenbreite hat dann 256 bit bzw. in neueren Systemen sogar 512 bit).": Nein, nein, nein, es ist und bleibt eine Genauigkeit von 32 oder 64 Bit. Also, es gibt einen Befehlssatz der mit 256 Bits auf einmal arbeitet, genannt AVX. Aber diese 256 Bit von AVX beziehen sich ausschließlich darauf, dass mehrere 32 Bit bzw. 64 Bit Gleitkommazahlen auf einmal verarbeitet werden können (ein Implementierungsdetail für bessere Performance). Wenn du dafür eine Quelle willst, empfehle ich einen Blick in die Wikipedia-Artikel zu AVX, SSE und diesen englischen Artikel. Der Bezug auf die CPU-Familie ist außerdem völlig irrelevant, da AVX weit verbreitet und diese genannte CPU-Familie unter vielen weder besonders wichtig ist noch ein Vorreiter war. Und die Genauigkeit ist und bleibt 32 oder 64 Bit. Es ist extrem irreführend, von "256 bit Genauigkeit" zu sprechen, die "konvertiert" würden, wobei "Schon die x87-Intel Coprozessoren [...] mit bis zu 80 bit extended" gearbeitet hätten. Schon? 80 Bit Genauigkeit stirbt aus. Außer dem alten Koprozessor unterstützt keiner der zeitgemäßen Befehlssätze 80 Bit Gleitkommazahlen. Intel selbst rät seit Jahrzehnten davon ab und der Microsoft Visual C++ Compiler hat das 80 Bit Format nie richtig unterstützt.

"Die neuerlich geaddeten ENs tun hier nichts zur Sache": Sorry, was genau meinst du damit?

"Im übrigen wird die Einheit bit (im Gegensatz zu Byte) klein geschrieben.": Aha, interessant. Das war mir nicht bewusst. Wobei scheinbar im Fließtext beide Optionen möglich sind, da 17 Bit analog 17 Pflaumen wohl doch wieder wieder groß schreiben werden können (Bit#Schreibweise). Auf anderen Wikipedia-Artikeln wird es in diesem Fall scheinbar groß geschrieben. Ich glaube, bei meiner Änderung hatte ich mich daran orientiert. Siehe zum Beispiel IEEE 754, Advanced Vector Extensions, Byte.

"Nicht dargetan ist ferner, wieso der Hinweis auf den elementaren Unterschied von der Bit-Tiefe der Softwarearchitektur und der Bit-Tiefe der angewandten Gleitkommaarithmetik irrelevant wäre. Adobe Audition hat eine 64 bit Softwarearchitektur, berechnet aber mit 32 bit float, während hingegen z.B. ProTools HD (und aufwärts) und Nuendo 8 (aufwärts) mit 64 bit float berechnen.": Weil es prinzipiell grundverschiedenene Dinge sind die nichts miteinander zu tun haben. Ob es eine gute Idee ist, gerade deshalb explizit darauf hinzuweisen kann man wohl unterschiedlicher Auffassung sein. Aus meiner Perspektive bietet es eher unnötiges Verwirrungspotential für Leser die nicht wissen was "x Bit Architektur" eigentlich bedeutet. Für alle die mit dem Wort etwas anfangen können sehe ich eigentlich nicht so große Gefahr die Breite der Speicheraddressierung mit der Größe von Abtastwerte durcheinander zu bringen. Schließlich ist es kein Geheimnis, dass z.B. auch eine 64 Bit Anwendung auch noch 16 Bit Wave-Dateien speichern kann und in (beinahe) jeder Programmiersprache die eingebauten Datentypen feste Größe unabhängig der Architektur haben (Auch in C & C++ ist es de facto fixiert bis auf, teilweise, "long").

"Die Ausführungen, "diese Bittiefe sei dabei aber nur bei der Speicherung von Abtastwerden (sic!) über den Programmverlauf hinweg ausschlaggebend" bzw. "einzelne Funktionen der Anwendungen könnten intern temporär höhere Bittiefen verwenden" sind unbelegbare Spekulationen, da sich kein Programmentwickler in die Karten schauen läßt": Nein, soweit ich das da geschrieben habe, ist es doch keine Spekulation. Jedem Programm steht es selbstverständlich frei eine höhere Präzision zu verwenden. Eigentlich behauptet der ursprüngliche Artikel das doch auch. Es wird zu Beginn behauptet, dass die Werte in eine höhere Präzision "konvertiert" würden. Bezüglich der Frage, wann das genau gemacht wird: Ja, das wissen wir jetzt nicht. Tatsache ist aber, dass es gemacht wird. Es gibt z.B. auch eine Reihe Open Source Lösungen wie Audacity bei denen man nachschauen kann. Ein rascher Blick in den Quellcode verrät schnell, dass das Mixing immer mit 32 Bit Floats gemacht wird (Siehe "Mix.cpp", "MixBuffers"). Zum Zeitpunkt als ich den Artikel angepasst habe, habe ich auch selbst an einer Software-Bibliothek für Audio-Bearbeitung gearbeitet und kann das aus erster Hand bestätigen. Es bringt eigentlich eine Menge Probleme (und kaum Vorteile) die internen Verarbeitungsroutinen für jedes Format zu spezialisieren. Deshalb würde ich davon ausgehen, dass es sogar in den genannten Produkten der Fall ist. Unabhängig davon wann es gemacht wird, sollten wir auf keinen Fall den Eindruck des Gegenteils erwecken. Insbesondere da am Ende des Artikels auch nochmal auf Dateiformate eingegangen wird, wollte ich da klar unterscheiden.

"Das Clipping war ferner bereits in Abs. 3, Quantisierungsfehler und das "hidden bit" bereits in Abs. 4 erklärt. Der Dynamikbereich der Amplitude (einer Halbwelle) kann nur durch den veränderlichen Teil der Mantisse dargestellt werden. Die Erhöhung der Genauigkeit um 1 bit ist in allen Berechnungen bereits impliziert, da man ohne das "hidden bit" nur 22 bit Dynamik zur Verfügung hätte.": Ich glaube hier liegt ein Denkfehler vor. Ohne Hidden Bit wären es 23 Bit, mit sind es 24 Bit. Die 1 ist das Maximum des Abtastwerts und kann exakt dargestellt werden. Für Audio-Samples z.B. im Intervall [1/2, 1[ beträgt der führende Exponent bereits -1 wodurch sich die Genauigkeit um ein Bit erhöht. Bei noch kleineren Zahlen erhöht sich die Genauigkeit weiter. Im Intervall [1, -1] liegt auf jeden Fall immer eine Genauigkeit von 24 Bit vor, d.h. es können Inkremente von $2^{-24}$ exakt dargestellt werden obwohl die Mantisse nur 23 Bit groß ist. Zum Beispiel beträgt der Abstand der IEEE-Zahlen 0x3f800000 (1) und 0x3f7fffff (0.999999940395355224609375) genau $2^{-24}$.

"Die kleinste normalisierte Zahl ist dabei wie dargestellt $2^{-126}$ · 1 (1 = hidden bit) und kann in $2^{-23}$ Schritten (also mit 23 bit Genauigkeit) erhöht werden.": Das stimmt so leider nicht. Die Zahl erhöht sich (wenn der Exponenten -126 beträgt) in $2^{-149}$ Schritten. Erst ab $2^{-125}$ in $2^{-148}$ Schritten und so weiter bis schlussendlich zwischen 0.5 und 1 die $2^{-24}$ Schritte folgen.

"Ansonsten wären ja alle hinreichend mit Literatur belegten Dynamikberechnungen hinfällig und der Dynamikbereich wäre verdoppelt.": Einige der Berechnungen zur Dynamik sind für mich nicht nachvollziehbar. Ich denke man könnte das allgemeinverständlicher formulieren, aber ich möchte gar nicht sagen das sie falsch sind. Es ist offen gestanden auch einfach nicht meine Expertise. Meine Änderung bezog sich daher eigentlich auf die Bemerkungen im Artikel bezüglich Bittiefe und Präzision. Ich gebe zu, dass man besser auch den gesamten Abschnitt prüfen und ggf. auch die Rechnungen anpassen sollte. An vielen Stellen im Artikel wird mit -24 und -25 im Exponenten gerechnet. Es scheint das Hidden Bit (und gegegebenfalls Vorzeichen) sind an diesen Stellen tatsächlich mit eingerechnet. Auch die mehrmals genannten -144db für den Dynamikumfang sind richtig.

Konkret meine Kritikpunkte: "23 bit Amplitudenauflösung", "23 bit Auflösungsvermögen pro Halbwelle", "Die einzelnen Stufen der Integerwerte der Festkommazahl entsprechen dann den Stufen der Gleitkommazahl der Größe 1 : $2^{23}$ ≈ 1 · $10^{-7}$" und so weiter sind einfach falsch. Das Inkrement ist $2^{-24}$ und nicht größer. Mit dem Hidden Bit hat man also 24 Bit Auflösung. Das "Hidden Bit" steckt implizit im Exponenten. (Abgesehen vom Hidden-Bit ist im letzten Zitat auch noch das Vorzeichen im Exponenten falsch)

Zuletzt: Ich bin immernoch der Meinung, dass die aktuelle Einleitung in das Thema ungeeignet ist. Es werden verschiedene Audio-Anwendungen aufgelistet ohne dem Leser zu erklären wozu Gleitkommazahlen in digitaler Audioanwendungen überhaupt gut sind. Ich hatte deshalb einen Abschnitt vorangestellt um in das Thema einzuführen und die verschiedenen wichtigen (Software unabhängigen!) Vorteile von Gleitkommazahlen in Audioanwendungen kurz zusammenzufassen und zu erläutern. 2A02:810D:4BC0:3F84:9595:32BD:375D:1497 21:25, 18. Okt. 2019 (CEST)

Nun, der Thread hier ist verstaubt, ich hatte mich längere Zeit aus diesem Projekt ausgeklinkt. Aber um das hier für den interessierten IP-Benutzer noch im Einzelnen klarzustellen:

• Stichpunkt "256 bit Genauigkeit": Deine Links zielen ins Leere, da ich im Artikel auf den AMD Bulldozer verwiesen und verlinkt hatte. Aus dessen Abschnitt Modul ergibt sich eben, daß mit der 256-Bit-FPU sehr wohl intern mit höherer Genauigkeit gerechnet wird, s.a. Fused multiply-add. Das hat nichts mit 256 bit Registern zu tun.
• Stichpunkt "Einheit bit": Der Artikelbestand ist projektweit nicht einheitlich, das heißt aber nicht, daß wir hier die mathematischen Maßgaben ignorieren. Die lautet für Einheiten: Byte groß, bit klein.
• Stichpunkt "Hinweis 64 bit Softwarearchitektur": Eben um Verwechslungen/Gleichsetzungen von CPU- bzw. Software-Architektur einerseits und der zur Darstellung der Audiowerte verwendeten Gleitkommaarithmetik andererseits zu vermeiden, ist der Leser zwingend aufzuklären. Die Fähigkeit der Software, Dateien in Festkommazahlen (WAV-Dateien) auszugeben, tut hier nichts zur Sache.
• Stichpunkt "hidden-bit": Das hidden-bit entspricht der 1 vor dem Komma der entsprechenden Dezimalzahl. Wie hier bereits erklärt, ist das hidden-bit also nicht Teil des Dynamikbereiches, der ausschließlich vom veränderlichen Teil der Mantisse (bzw. von den Zahlen nach dem Komma der entsprechenden dezimalen Zahl) dargestellt wird, und das sind nun mal bei 32 bit Gleitkomma 23 bit (+ 1 Vorzeichenbit und 8 bit für den Exponenten). Ohne das hidden-bit, also mit der ständigen 1 in der Mantisse, würden nur 22 bit Dynamikauflösung bereit stehen. Bez. der Dynamikberechnungen ergeben sich die 24-bit-Auflösung übrigens aus dem zusätzlichen Vorzeichenbit (nicht aus dem hidden bit), siehe Statement "Bei der Berechnung der Gesamtdynamik bzw. der Gesamtauflösung ist zu bedenken, dass sich die Amplitudenauflösung lediglich auf den vorzeichenfreien Wert der Amplitude (eine Halbwelle) bezieht.". Die 25 bit ergeben sich aus dem zusätzlichen Headroom ≤ 2 (6 dBFS).
• Stichpunkt "Vorzeichen im Exponenten falsch": Du übersiehst, daß die $2^{23}$ im Nenner steht, weswegen der Exponent der entsprechenden Zehnerpotenz selbstverständlich negativ ist.
• Stichpunkt "kleinstmögliche Auflösung": Ich zitiere Dich: "Das stimmt so leider nicht. Die Zahl erhöht sich (wenn der Exponenten -126 beträgt) in $2^{-149}$ Schritten. Erst ab $2^{-125}$ in $2^{-148}$ Schritten und so weiter bis schlussendlich zwischen 0.5 und 1 die $2^{-24}$ Schritte folgen." Du hast vollkommen recht, je niedriger die Zahl wird, desto feiner wird die theoretisch mögliche Auflösung. Es ist dabei allerdings nicht so, daß sich mit jedem negativen Exponenten die Aufösung um ein Bit erhöhen würde, sonst hätten wir ja im kleinsten Teilwertebereich 23 + 126 bit = 149 bit Auflösung. Abgesehen davon, daß sich meine diesbezüglichen Ausführungen hier auf der Disk ja nur auf das hidden-bit bezogen, beziehen sich die von mir in der Tabelle dargestellten 23 bit Auflösung eben nur auf den jeweiligen Teilwertebereich, der durch einen einzigen Exponenten dargestellt wird, und dieser Teilwertebereich wird wiederum maximal mit den 23 bit der Mantisse aufgelöst. Daß der jeweilige Teilwertebereich mit jedem negativen Exponenten mehr jeweils ein nur halb so kleines Intervall umfaßt und die mögliche absolute Auflösung damit immer feiner wird, spielt aber, abgesehen von der immer kleiner werdenden Streuung bei kleinen Pegeln wie dargestellt, so gut wie keine Rolle, da diese Feinauflösung von max. 149 bit allein die internen Rechenoperationen betreffen würde. Gleitkomma-AD-Wandler gibt es nämlich nicht, und letztlich ist es immer eine Integerzahl, die hier linear aufgeteilt wird. Die feinste Auflösung ergibt sich dann eben rein rechnerisch durch die 23-bit-Auflösung der Amplitude (Halbwelle) eines 24-Bit-Festkommawertes bzw. praktisch durch dessen Quantisierungsrauschabstand. Interne Rechenoperationen, die ja mitunter mit bis zu 256 bit Genauigkeit in der FPU berechnet werden, sind hier aber irrelevant. Deswegen stehen diese theoretischen Werte auch nicht in der Tabelle.

-- Uwe Martens (Diskussion) 22:56, 3. Feb. 2021 (CET)