64bit Floating Point Signalfluss

[synthpark]

und "Summing Engine" umfasst ja letzendlich den kompletten Signalfluss

die Summing Engine umfasst genau eine Operation: Gewichten der Kanäle (=Fader/Panner) und Summieren, also nicht die interne Verarbeitung in den Plugins.

 

[Sascha Franck]

die Summing Engine umfasst genau eine Operation: Gewichten der Kanäle (=Fader/Panner) und Summieren, also nicht die interne Verarbeitung in den Plugins.

Hm, ich habe zu wenig Ahnung davon, um dem widersprechen zu können (oder gar zu wollen), aber wieso werden dann bspw. in Wavelab 32 und 64bit-fähige Plugins als solche markiert? Wavelab rechnet den internen Signalfluss anscheinend auf 32bit runter, wenn es auf ein 32bit Plugin trifft, danach dann wieder hoch. Und beim Summieren laufen Signale nun einmal auch durch Plugins, streckenweise parallel, stereckenweise seriell - das würde die ganz Geschichte ja mehr oder minder ad absurdum führen.
Ich lasse mich aber gerne eines Besseren belehren.

 

[synthpark]

Hm, ich habe zu wenig Ahnung davon, um dem widersprechen zu können (oder gar zu wollen), aber wieso werden dann bspw. in Wavelab 32 und 64bit-fähige Plugins als solche markiert? Wavelab rechnet den internen Signalfluss anscheinend auf 32bit runter, wenn es auf ein 32bit Plugin trifft, danach dann wieder hoch. Und beim Summieren laufen Signale nun einmal auch durch Plugins, streckenweise parallel, stereckenweise seriell - das würde die ganz Geschichte ja mehr oder minder ad absurdum führen.
Ich lasse mich aber gerne eines Besseren belehren.

Ich kann das nur aus DSP Sicht beurteilen.

Es geht nur darum, daß in der Summe gleichzeitig sehr laute und sehr leise Signale existieren.
Wenn alle gleichleise oder etwa gleichlaut wären, hätte man die Vorteile des Fließkommas, also gehts eher um Fade outs, Hallfahren etc.

Wenn man nun 32 Bit summiert, kann man zum Beispiel alle besonders leisen Signale (die ohnehin eher maskiert werden) getennt summieren. Alle Signale unter -60 dB werden in Summe A summiert, alle drüber in Summe B. Am Ende werden A und B summiert.
Problem gelöst, wenn es überhaupt eins gab, und das mit 32 Bit.

Diese Diskussionen im Rahmen eines Forums sind so grenzwertig und so oberflächlich, weil sie komplett an der eigentlichen Materie vorbeigehen, daß es sich überhaupt nicht ansatzweise lohnt, darüber zu diskutieren. Der Teufel steckt im Detail, und Detail ist nichts, was im Forum eine große Chance hätte.

 

[Sascha Franck]

Danke für die zumindest ansatzweise verständliche Erklärung, @synthpark.
Schleierhaft bleibt mir dann aber dennoch, warum Wavelab das jetzt so zu handhaben scheint - aber hmmpfff, der Schleier würde sich auch inkl. der passenden Erläuterung eher nicht lüften, dafür sind meine Kenntnisse zu bescheiden.

Fest steht desungeachtet, dass das mit der verwendeten Bittiefe für (ja nur etwaig) aufgenommene Audiofiles nix am Hut hat.

 

[ModulationMatrix]

Hm, ich habe zu wenig Ahnung davon, um dem widersprechen zu können (oder gar zu wollen), aber wieso werden dann bspw. in Wavelab 32 und 64bit-fähige Plugins als solche markiert? Wavelab rechnet den internen Signalfluss anscheinend auf 32bit runter, wenn es auf ein 32bit Plugin trifft, danach dann wieder hoch. Und beim Summieren laufen Signale nun einmal auch durch Plugins, streckenweise parallel, stereckenweise seriell - das würde die ganz Geschichte ja mehr oder minder ad absurdum führen.
Ich lasse mich aber gerne eines Besseren belehren.

Ich kann das nur aus DSP Sicht beurteilen.

Es geht nur darum, daß in der Summe gleichzeitig sehr laute und sehr leise Signale existieren.
Wenn alle gleichleise oder etwa gleichlaut wären, hätte man die Vorteile des Fließkommas, also gehts eher um Fade outs, Hallfahren etc.

Wenn man nun 32 Bit summiert, kann man zum Beispiel alle besonders leisen Signale (die ohnehin eher maskiert werden) getennt summieren. Alle Signale unter -60 dB werden in Summe A summiert, alle drüber in Summe B. Am Ende werden A und B summiert.
Problem gelöst, wenn es überhaupt eins gab, und das mit 32 Bit.

Diese Diskussionen im Rahmen eines Forums sind so grenzwertig und so oberflächlich, weil sie komplett an der eigentlichen Materie vorbeigehen, daß es sich überhaupt nicht ansatzweise lohnt, darüber zu diskutieren. Der Teufel steckt im Detail, und Detail ist nichts, was im Forum eine große Chance hätte.

Hm so hab ich noch gar nicht drüber nachgedacht. Sollte aber trotzdem ausreichen. Es gibt ja nicht das Problem dass ein großer Wert zu einem kleinen addiert und später wieder abgezogen wird, oder umgekehrt. Zumindest sehe ich nicht wo das passieren könnte.

Ein Genauigkeitsproblem besteht also nur dann, wenn ein 0db Signal und ein -60db Signal gleichzeitig erklingen. Bei 6-9 significant digits fängt in dem Fall die Ungenauikeit schon an. Aber ein -60db Signal neben einem 0db Signal macht halt auch nur einen verschwindenden Anteil am Höreindruck aus. Das Ganze wird sich so in dem Bereich bewegen wie auch Kabelunterschiede o.ä., nur für Goldöhrchen wirklich zu hören.

Test wäre, nen 0db Sinus zu nehmen, dann bei -60db Musik zumischen und munter bearbeiten, am Schluß nen gegenphasigen Sinus zumischen und das resultierende Signal normalisieren. Das sollte die Musik bei double precision deutlich besser überleben als bei single precision.

 

[Loop_Breaker]

Wenn endlich Cubase 10 draussen ist, und ich dann 9.5 am start habe, werd ich mal, versuchen, durch massiv übertriebene Übersteuerung von allen, und dann extrem leiser Masterfader einstellung, zu exportieren, und schaun ob man den Unterschied hört... (zwischen 32 und 64 bit)

 

[Sascha Franck]

Wenn endlich Cubase 10 draussen ist, und ich dann 9.5 am start habe, werd ich mal, versuchen, durch massiv übertriebene Übersteuerung von allen, und dann extrem leiser Masterfader einstellung, zu exportieren, und schaun ob man den Unterschied hört... (zwischen 32 und 64 bit)

Irgendjemand auf Gearslutz oder so hat schon vor geraumer Zeit einen 32 vs. 64 bit Nulltest gemacht (mit irgendeinem recht belebten Mix, soweit ich mich recht entsinne). Hat anscheinend nicht wirklich komplett genullt, aber das Ergebnis der Abweichungen lag wohl bei ca. -140dB. Er meinte dazu, um ein so leises Signal hörbar zu machen, müsse man sich in einen schalltoten Raum begeben und die benutzte Anlage so weit aufdrehen, dass sich, wenn man danach Musik mit nominellen 0dB darüber abspielen würde, einem die Speakerpappen um die Augen wickeln würden (die Ohren schwenken vermutlich bereits deutlich früher die weiße Fahne).

 

[Loop_Breaker]

wieviel dBfs hat DitherNoise?

 

[John_Lennon]

Er meinte dazu, um ein so leises Signal hörbar zu machen, müsse man sich in einen schalltoten Raum begeben und die benutzte Anlage so weit aufdrehen, dass sich, wenn man danach Musik mit nominellen 0dB darüber abspielen würde, einem die Speakerpappen um die Augen wickeln würden (die Ohren schwenken vermutlich bereits deutlich früher die weiße Fahne).

Schlimmer: In einem geschlossenen Raum kann so was mit ganz schweren Gesundheitsschäden enden und im Extremfall sogar tödlich sein. Ab 180 dB (relativ zur Hörschwelle) aufwärts platzen die Lungenblässchen und man stirbt. Allerdings müsste man erst mal einen Lautsprecher finden, der das überhaupt kann/aushält.

Ich habe den Nulltest auch schon gemacht und es hat auch tatsächlich genullt. Allerdings muss man dazu das Dithering ausschalten, da das sonst eine Random-Komponente ist, die immer zu Abweichungen führt.

Die Sache ist ja die: Man kann zwar mit 64-bit-Float einen Haufen Nachkommastellen mehr berechnen, aber irgendwann muss alles wieder auf 16 oder 24 Bit Float runter, damit der Wandler den Mix abspielen kann. Und dabei werden dann eben jene Nachkommastellen gleich wieder abgeschnitten. Auch bei Dithering wird vorher gerundet und nach Rundung ist der tatsächlich entstandene Wert, der ins Masterfile geschrieben oder an den Wandler übergeben wird, identisch. Selbst wenn man mathematische Unterschiede im Processing zwischen 32- und 64-Bit Float erzeugt (und dazu muss man sich schon sehr anstrengen), dann spielen sich die Unterschiede in den Stellen ab, die ohnehin wieder abgeschnitten werden.

 

[ModulationMatrix]

Schlimmer: In einem geschlossenen Raum kann so was mit ganz schweren Gesundheitsschäden enden und im Extremfall sogar tödlich sein. Ab 180 dB (relativ zur Hörschwelle) aufwärts platzen die Lungenblässchen und man stirbt. Allerdings müsste man erst mal einen Lautsprecher finden, der das überhaupt kann/aushält.

Die Amis ballern ja schon mit 150db durch die Gegend. 180db würden die bestimmt auch schaffen, aber ist ja nicht gewollt die Leute umzubringen.

https://de.wikipedia.org/wiki/Long_Range_Acoustic_Device

 

[Sascha Franck]

Schlimmer: In einem geschlossenen Raum kann so was mit ganz schweren Gesundheitsschäden enden und im Extremfall sogar tödlich sein. Ab 180 dB (relativ zur Hörschwelle) aufwärts platzen die Lungenblässchen und man stirbt. Allerdings müsste man erst mal einen Lautsprecher finden, der das überhaupt kann/aushält.

Der Kollege hier kann 200dB:
https://www.zeit.de/wissen/umwelt/2012-05/tier-knallkrebs

 

[Burkie]

Ich kann das nur aus DSP Sicht beurteilen.

Es geht nur darum, daß in der Summe gleichzeitig sehr laute und sehr leise Signale existieren.

Wie das ein Plug-In intern macht, ist doch Sache des Plug-Ins, und braucht auch die DAW nicht zu interessieren.

Hinein geht und heraus kommt ein Audio-Sample-Daten-Stream. Eigentlich reichen auch 16 Bit, 24 oder 32 Bit sind eine komfortable Sicherheits-Marge.
Und damit ist eigentlich auch alles hörbare abgedeckt.


Irgendwoher aber muss ja immer noch ein Marketing-Gefasel herkommen, um die nächste Version der Software anzupreisen. "Analoger als analog", "noch feiner aufgelöst".
Ja, klar. Für Produktionen, deren effektive Bit-Auflösung kaum über 8 Bit hinausgeht.

Gruss

 

[Sascha Franck]

Hinein geht und heraus kommt ein Audio-Sample-Daten-Stream. Eigentlich reichen auch 16 Bit, 24 oder 32 Bit sind eine komfortable Sicherheits-Marge.
Und damit ist eigentlich auch alles hörbare abgedeckt.

Wie bereits erwähnt, es geht hier NICHT um die Audiobittiefe. Da kannste noch 10 Mal mit deinen audiophilen 16 bit kommen.

 

[ModulationMatrix]

Ich kann das nur aus DSP Sicht beurteilen.

Es geht nur darum, daß in der Summe gleichzeitig sehr laute und sehr leise Signale existieren.

Wie das ein Plug-In intern macht, ist doch Sache des Plug-Ins, und braucht auch die DAW nicht zu interessieren.

Hinein geht und heraus kommt ein Audio-Sample-Daten-Stream. Eigentlich reichen auch 16 Bit, 24 oder 32 Bit sind eine komfortable Sicherheits-Marge.
Und damit ist eigentlich auch alles hörbare abgedeckt.


Irgendwoher aber muss ja immer noch ein Marketing-Gefasel herkommen, um die nächste Version der Software anzupreisen. "Analoger als analog", "noch feiner aufgelöst".
Ja, klar. Für Produktionen, deren effektive Bit-Auflösung kaum über 8 Bit hinausgeht.

Gruss

Für die interne Verarbeitung reicht 16 Bit nicht aus, das würde denke ich merklich Kacke klingen. 16bit taugt nur als End Speicherformat, so gerade eben.

Ansonsten warte ich dann in Zukunft auf den ersten Streaming Dienst der 64bit Dateien als Premium Dienst anbietet.

 

[ModulationMatrix]

Wie bereits erwähnt, es geht hier NICHT um die Audiobittiefe. Da kannste noch 10 Mal mit deinen audiophilen 16 bit kommen.

Natürlich geht es um Audio Bittiefe, die Daten verwandeln sich ja während des Prozesses nicht in was anderes, es bleibt immer Audio. trotzdem ist es ein riesen Unterschied jegliche Berechnung und Operation in 16 Bit durchzuführen, oder nur das Endergebnis in 16 Bit zu speichern.

 

[Sascha Franck]

Natürlich geht es um Audio Bittiefe

Nö. Es geht um die Auflösung bei der Verarbeitung. Um die Genauigkeit, mit der irgendwelche Berechnungen angestellt werden. Mit Audio Bittiefe hat das erstmal nix am Hut. Dass da dann Audiomaterial durch die Geschichte gesendet wird, ist 'ne andere Sache.

 

[synthpark]

Die Sache ist ja die: Man kann zwar mit 64-bit-Float einen Haufen Nachkommastellen mehr berechnen, aber irgendwann muss alles wieder auf 16 oder 24 Bit Float runter, damit der Wandler den Mix abspielen kann. Und dabei werden dann eben jene Nachkommastellen gleich wieder abgeschnitten. Auch bei Dithering wird vorher gerundet und nach Rundung ist der tatsächlich entstandene Wert, der ins Masterfile geschrieben oder an den Wandler übergeben wird, identisch. Selbst wenn man mathematische Unterschiede im Processing zwischen 32- und 64-Bit Float erzeugt (und dazu muss man sich schon sehr anstrengen), dann spielen sich die Unterschiede in den Stellen ab, die ohnehin wieder abgeschnitten werden.

Die Sache ist die: die Anzahl der signifikanten Rundungen zu beschränken ...

 

[synthpark]

Hm so hab ich noch gar nicht drüber nachgedacht. Sollte aber trotzdem ausreichen. Es gibt ja nicht das Problem dass ein großer Wert zu einem kleinen addiert und später wieder abgezogen wird, oder umgekehrt. Zumindest sehe ich nicht wo das passieren könnte.

Wenn du addierst, musst die die Exponenten angleichen. Dadurch schieben sich die Mantissen.

Eine sehr kleine Zahl wird dann schon mal vorweg gerundet und dann zur großen addiert. Da kann dann unter Umständen nicht viel von der kleinen Zahl übrigbleiben. Wenn du erstmal alle sehr kleinen Zahlen addierst, so zB 50, und anschließend die Summe angleichst, hast du in manchen Fällen statt 50 Rundungen, die zum Rauschen beitragen, nur eine signifikante Rundung gemacht.

 

[Nachtschicht]

am ehesten an 16bit angelehnt dürfte in diesem zusammenhang die "beispielrechnung" des rundungsfehlers in diesem video sein, und 16bit ist da noch grosszügig formuliert. das ist so dermassen an jeglichen realitäten einer 32bit float mixengine vorbei, da muss ich erst noch nach einem passenden sarkastischen satz suchen um das angemessen zu kommentieren

aber wir können das auch sehr schön weg aus der theoretischen ebene holen und mal kurz - ich weiss, verrückte idee - in die praxis rüberwechseln.

beispielsweise: probier doch mal, den besagten "rundungsfehler" in einem mixsetup nachzubauen. 3 geteilt durch 2 ist 1,5, gerundet aber 2, wieder mal 2 gleich 4, hilfe ein rundungsfehler! dürfte doch ein kinderspiel sein, das im mixer nachzubauen, nicht wahr?

probiers einfach mal.

Das Beispiel ist ein Beispiel für die Art und Weise, wie Rundungsfehler zustandekommen. Wenn du in der Schule die Addition erlernst, fängst du auch erst einmal mit 1+1 an. Damit Anfänger nicht gleich von zig Stellen erschlagen werden. Genauso ist das Video gehalten, es erklärt dem Anfänger, wie es zu Rundungsfehlern kommt. Um jemandem das Prinzip des Otto-Motors zu erklären, braucht man auch keine hochgezüchtete Formel 1 Kiste. Abgesehen davon, um das Beispiel für die Rundungsfehler in einer höheren als der 2bit Auflösung (2stellige Werte) zu präsentieren, hätte es deutlich mehr Bildschirmplatz benötigt. Das Beispiel per se ist eigentlich tatsächlich exzellent.

Mit 16bit hat übrigens gar nichts in dem Video etwas zu tun. Eben weil es NICHT um die Auflösung deiner Audiofiles geht.
Und deine 32bit float Mischmaschine hat ebenfalls REIN GAR NICHTS mit der Auflösung deines Audiomaterials zu tun. Sondern mit der Auflösung, die deine Prozessoren für ihre internen Berechnungen benutzen.
Und oho, es gibt sie ja sogar nochmal, die 32-vs-64 bit Geschichte, nämlich bei Betriebssystemen. Auch da geht es NICHT um die Auflösung irgendwelcher Audiofiles - oder möchte das ebenfalls jemand behaupten?

Unterm Strich kann es deshalb nicht nur gut sein, sondern ist tatsächlich *vollkommen* alltäglich, dass in einem Audiorechner ein 24bit File durch eine 32bit float Mischmaschine in einer 64bit Betriebssystemumgebung läuft. Drei Paar Schuhe. Haben nichts miteinander zu tun. Werden hier aber trotzdem ganz munter durcheinandergewürfelt. Und wenn man das mal so anmerkt, wird einem erzählt, das wäre dummes Gequassel. Aufschlussreich, wirklich sehr aufschlussreich!

du weisst, dass dein gegenüber aufm rückzug ist, wenn er sich hinter einem riesengrossen strohmannargument versteckt

ich habe hier nix durcheinandergewürfelt. wenn du dich fragst, warum plugins in cubase für 64bit fähigkeit markiert werden, habe ich eher das gefühl, du weisst nicht so ganz genau, wovon du redest, dann da geht es selbstverständlich nicht um den signalfluss sondern darum ob das plugin ein 64bit plugin ist, oder ein 32bit plugin welches in einem 64bit host nur über interne bridge angesprochen werden kann, wobei es in diesem fall nur um die grösse der addressierbaren speichers geht. das hat mit dem signalfluss exakt überhaupt nichts zu tun. und ist übrigens inzwischen vom tisch, weil steinberg die interne bridge deaktiviert hat.

das gebouncte audiofile hingegen hat mit dem signalfluss schon sehr viel mehr zu tun, denn während die mixengine und der finale bounce zwei getrennt zu betrachtende fragen sind, gibt es ja auch noch, surprise!, den nicht-finalen bounce, etwa render in place, oder wenn du spuren zu submixen zusammenfasst, denn dann landen die ja wieder im mix und machen somit die auflösung des bounces zum teil des signalwegs. das ist eigentlich (wie alles hier im thread) wurscht, aber: damit kannst du übrigens auch sehr gut die "auflösungsprobleme" von 32bit float selber ausprobieren. bounce einfach mal ein signal so richtig schön doof ausgesteuert. deutlich zu niedrig oder deutlich zu hoch, egal. dann ziehste das file wieder in deinen mixer und korrigierst die aussteuerung um denselben wert wieder nach oben oder nach unten und machst einen nulltest.

da du offenbar einen widerstand verspürst, solche sachen einfach mal selbst in der praxis auszuprobieren, hier die kurzzusammenfassung: solange du dich ausserhalb gänzlich absurder bereiche (wie etwa der tödlichkeitsdiskussion mit rainer ) bewegst, hat sichs was mit 1,5-aufgerundet-auf-2-mal-2-gibt-4.

das ist hübsch zur veranschaulichung, was ein rundungsfehler an sich überhaupt ist, da hast du recht. da es aber ein szenario ist, das in dieser form in der praxis dir nicht begegnen wird, ist es gleichzeitig massiv irreführend.

vielleicht kann rainer uns ja nochmal vorrechnen, wo genau mathematisch das endergebnis anfängt sich zu unterscheiden. so für diejenigen, denen ein ergebnis von -140 im praxistest noch nicht reicht und es ganz genau wissen wollen

 

[Nachtschicht]

Achja, nebenbei: Die 64bit Betriebssystemumgebung sowie die 32bit "mixing engine" des Sequenzers kommen auch (und zwar genauso deutlich oder undeutlich) zum Tragen, wenn man gar keine Audiofiles benutzt, sondern ausschließlich virtuelle Instrumente. Huch, was nun?

huch, das nun: der unterschied zwischen audiofiles und virtuellen instrumenten ist deiner mixengine wurscht