Cubase 9 vs Studio One 3 (neu)

  • Ersteller musicdevil
  • Erstellt am
Status
Für weitere Antworten geschlossen.
Es geht um Rundungsfehler bei der Berechnung, bzw. Summierung.
Desto genauer (64-bit floating-point) gerechnet wird, umso besser ist letztendlich, aufgrund weniger Rundungsfehler das klangliche Ergebnis.
Das muss nicht dramatisch ausfallen, aber wie so oft kann sich das alles summieren und dann letztendlich tatsächlich hörbar sein.
Genaueres:
http://www.meterplugs.com/blog/2017/02/03/does-64-bit-summing-sound-better.html
https://www.ableton.com/answers/64-bits-floating-point-audio-engine-needwant-when
Da Plugins intern mit 64-bit floating-point rechnen können, würde eine DAW die das nicht kann das Ergebnis letztendlich wieder zunichte machen. Also heutzutage sollte das schon Standard sein und Cubase wäre eher die Ausnahme wenn die DAW das immer noch nicht kann.
Ein Werbeslogan wie "S1 klingt besser", kann dann durchaus seine Berechtigung haben und würde der Wahrheit entsprechen.
So können zb. algorithmische Reverbs von der Sache profitieren. Ist allerdings kein Verdienst von S1, sondern nach meinen Recherchen hatte das Sonar zuerst. Kann man aber mittlerweile als Standard bezeichnen.

Sorry, aber das ist völliger Quark.

Ein Plugin, dem 32-bit Float nicht reichen, arbeitet heute schon intern mit 64-bit und zwar auf allen DAWs. Der DAW ist das völlig wurscht, weil sie überhaupt nicht mitbekommt, was das Plugin intern veranstaltet. Nach draußen übergeben wird dann 32-bit Float, weil in VST(2) gar nichts anderes definiert ist. Auch S1 übergibt die Daten in 32-bit Float und bekommt sie auch in dem Format wieder zurück.

Was du meinst, ist einzig und allein das Summing. Da reichen 32-bit aber heute für 1500dB Dynamik und die raren Fälle in der Praxis, wo eine 64-bit Float Addition wirklich ein anderes Ergebnis bringt, wenn auch nur in der mathematischen Theorie, kann dein Ohr nicht wahrnehmen.

Man macht es heutzutage einfach deshalb, weil es bei 64-bit CPUs mit der nahezu gleichen Performance machbar ist und überhaupt keinen großartigen Aufwand darstellt.

...und weil man es den Fanboys in der Userbase prima als tolles Feature verkaufen kann.

Ich habe mal mit Sonar den Vergleich gemacht, da es dort mal beide Versionen parallel gab und man dann gut vergleichen konnte. Das gerenderte Wave-File war am Ende bei beiden Varianten identisch. Der deutsche Vertrieb hat mir anschließend die Hölle heiß gemacht, weil sie das Feature großartig als "klingt besser" vermarkten wollten. Sic!
 
Man macht es heutzutage einfach deshalb, weil es bei 64-bit CPUs mit der nahezu gleichen Performance machbar ist und überhaupt keinen großartigen Aufwand darstellt.
Nichts anderes wollte ich in meinem Posting eigentlich ausdrücken. Geht mit heutigen Mitteln problemlos, also warum nicht machen. War möglicherweise unglücklich formuliert.
 
Bei der 64 Bit Mixer-Summierung ist das Grundrauschen viel niedriger als bei 32 Bit. Hören kann man das nicht, da sich der Unterschied erst bei ca -135 dBFS bemerkbar macht. Außerdem ist das Rendering mit 64 Bit viel schneller.
 
hts anderes wollte ich in meinem Posting eigentlich ausdrücken. Geht mit heutigen Mitteln problemlos, also warum nicht machen. War möglicherweise unglücklich formuliert.

Weiß ich doch ;)
Ich hatte ja auch nicht dich gemeint, sondern mit Absicht den Devil zitiert ;)
 
(edit: was schreib ich hier noch. ich halt mich raus :) )

muss jetzt mal mein 32bit float rauschen denoisen gehen :)
 
Nach draußen übergeben wird dann 32-bit Float, weil in VST(2) gar nichts anderes definiert ist.

Das stimmt so aber auch nicht.
processDoubleReplacing() gibt's schon in VST 2.4

Ein statement dazu vom Reaper dev.:

Most hosts these days will look for ProcessDoubleReplacing first, and if the plugin supports it, send a double-precision audio stream. If the plugin doesn't support it, the host will call ProcessReplacing instead and send a single-precision audio stream.

A few hosts still support only single-precision audio streams, those hosts will only call ProcessReplacing.
http://forum.cockos.com/showpost.php?p=381261&postcount=4
 
Bei der 64 Bit Mixer-Summierung ist das Grundrauschen viel niedriger als bei 32 Bit. Hören kann man das nicht, da sich der Unterschied erst bei ca - 135 dBFS bemerkbar macht. Außerdem ist das Rendering mit 64 Bit viel schneller.

Wie kommst du denn darauf?

Im Normalfall haben beide Summierungsarten das exakt gleiche Ergebnis. Nur in extremen Randfällen gibt es überhaupt einen mathematischen Unterschied. Aufgrund der mathematischen Natur ist das de facto zwar Rauschen, aber mit Grundrauschen i.S.v. was der Wandler mal als Quantisierungsrauschen ursprünglich geliefert hat, hat das überhaupt nichts zu tun.

Um solche Rundungsdifferenzen überhaupt zu provozieren, muss man außerdem erst mal eine ganze Menge Aufwand anstellen, so wie etwa 100 Kanäle jeweils extrem zu verstärken. Fährt man dagegen im Normalbereich, kommt exakt das Gleiche heraus.

Das Rendering ist auch mitnichten schneller. Normale FP-Operationen finden bei einer 64-Bit CPU halt in einem 64-Bit Register statt und bei einem 32-Bit Prozessor eben im 32-Bit Register. Die Zahl der Cycles, die eine Operation dann braucht, ist gleich.

Es gibt allerdings ein paar wenige Ausnahmen. Die Intel 64-Bit Architektur sieht zusätzliche Befehle und Register exklusiv für 64-Bit-Verarbeitung vor. Ich habe vor Jahren mal ein paar Tests dazu gelesen und da machte es noch keinen Unterschied bei den Laufzeiten, aber das war auch noch zu einer Zeit, als Intel 64 noch recht neu war und die Compiler noch nicht optimiert waren. Da kann schon sein, dass sich da ein bisschen was ergibt. Aber eben auch nur, wenn diese spezifischen i64-Befehle auch verwendet werden, wovon man bei plattformübergreifenden Applikationen nicht unbedingt ausgehen kann.
 
@Rainer_Hain Hatte ich mal aufgeschnappt:
 
Das stimmt so aber auch nicht.
processDoubleReplacing() gibt's schon in VST 2.4

Tatsächlich, hatte ich so nicht auf dem Schirm. Ich habe zwar mal zur Übung selbst ein VST-Plugin entwickelt, aber das war noch zu VST 2.3 (glaub ich). Da gab es definitiv kein DoublePrecision.
 
Nach draußen übergeben wird dann 32-bit Float, weil in VST(2) gar nichts anderes definiert ist.

Das stimmt so aber auch nicht.
processDoubleReplacing() gibt's schon in VST 2.4

Ein statement dazu vom Reaper dev.:

Most hosts these days will look for ProcessDoubleReplacing first, and if the plugin supports it, send a double-precision audio stream. If the plugin doesn't support it, the host will call ProcessReplacing instead and send a single-precision audio stream.

A few hosts still support only single-precision audio streams, those hosts will only call ProcessReplacing.
http://forum.cockos.com/showpost.php?p=381261&postcount=4

Lieber suboptional: Hast Du vl. noch mehr Infos zu den Thema?
Woher weiß man ob ein VST in der Lage wär, 64bit float weiter zu reichen?
Cubase ist sicher einer der DAWs die nur 32bit float vom Plugin entgegennehmen kann (summiert ja auch nur mit 32bit float), oder?
 
Lieber suboptional: Hast Du vl. noch mehr Infos zu den Thema?
Woher weiß man ob ein VST in der Lage wär, 64bit float weiter zu reichen?
Cubase ist sicher einer der DAWs die nur 32bit float vom Plugin entgegennehmen kann (summiert ja auch nur mit 32bit float), oder?

Ich denke das müsste man mit einem bitscope checken können.
Wenn im Insert vor dem zu testenden plugin 64 bit reingehen (bei hosts die processDoubleReplacing() aufrufen) und im insert nach dem zu testenden plugin auch noch 64 bit vorhanden sind. (hab diese Theorie aber noch nie getestet und bin grad zu faul dafür :D))

http://www.stillwellaudio.com/plugins/bitter/

Mit Cubase kenn ich mich nicht aus.
 
He Super Danke!!! Werd' Berichten wenn mich die Muse packt...
 
Cubase ist sicher einer der DAWs die nur 32bit float vom Plugin entgegennehmen kann (summiert ja auch nur mit 32bit float), oder?
Die internen Steinberg-Plugins in Cubase sind in 64 Bit, Cubase als Programm auch.
Ab C9 sind nur noch 64 Bit Plugins möglich. So wie bei Pro Tools und Logic bereits schon länger.
32 Bit Float ist die MixEngine, das ist aber etwas gänzlich anderes. (siehe Posting zuvor von Rainer)
 
Das stimmt so aber auch nicht.
processDoubleReplacing() gibt's schon in VST 2.4
Richtig und wenn das Plugin in der Lage ist mit 64 Bit Float zu rechnen, dann gibt es das Ergebnis auch bei einer DAW (die das kann) so aus.
Cubase gehört momentan nicht dazu, das hat immer noch ne 32 Bit Float Audio Engine, mitsamt Rundungsfehlern. Nutzt nichts wenn das Plugin intern so rechnet, aber die DAW nicht. Wenn ich mich recht erinnere, hat rkdk aber schon geschrieben, dass es in Nuendo schon geändert wurde und Cubase demnächst folgt. Anscheint hinken sie da eben bissel hinterher.
 
Anscheint hinken sie da eben bissel hinterher.

da wird mit einem Quellcode-Befehl einmal mit 32 Bit und einmal mit 64 Bit gerundet.
Die Umstellung kostet nen Hunni. Also die Änderung eines Befehls bringt Abermillionen Euro.
 
Cubase ist sicher einer der DAWs die nur 32bit float vom Plugin entgegennehmen kann (summiert ja auch nur mit 32bit float), oder?
Die internen Steinberg-Plugins in Cubase sind in 64 Bit, Cubase als Programm auch.
Ab C9 sind nur noch 64 Bit Plugins möglich. So wie bei Pro Tools und Logic bereits schon länger.
32 Bit Float ist die MixEngine, das ist aber etwas gänzlich anderes. (siehe Posting zuvor von Rainer)
Cubase ist sicher einer der DAWs die nur 32bit float vom Plugin entgegennehmen kann (summiert ja auch nur mit 32bit float), oder?
Die internen Steinberg-Plugins in Cubase sind in 64 Bit, Cubase als Programm auch.
Ab C9 sind nur noch 64 Bit Plugins möglich. So wie bei Pro Tools und Logic bereits schon länger.
32 Bit Float ist die MixEngine, das ist aber etwas gänzlich anderes. (siehe Posting zuvor von Rainer)
Mir geht es nicht darum ob cubase plugins "in 64 bit compiliert sind" sondern ob cubase in der lage ist einen 64bit audiostream von einen insert an den nächaten weiter zu geben (was theoretisch auch bei einen 32bit plugin funktionieren sollte)

ACHTUNG: die bittiefe des plugin outputs bzw im innneren des plugins (32float oder 64bit float) hat NICHTS mit den bits zu tun für welche systematchitektur stehen (32bit=i86, 64bit=amd64).


Jetzt postet suboptional einen link, wo behauptet wird, dass schon seit vst2irgendwas, 64bit float signal von vst's unterstützt werden kann.
VST ist ja bekanntlich eine steinbergsche erfindung und drum interessiert es mich, aus reiner neugierde, ob cubase zumindest bis zum summieren den 64bit stream (zumindest zwischen den inserts) weiterreicht oder auf 32bit float wandelt.

Werd mal hergehen: in cb ein reaper-vst zu laden (in der annahme das es versucht 64bit audiostream auszugeben) und mit den von suboptional verlinkten tool schauen was passiert...

Das alles aus rein technischer neugierde, denke nicht mal im entferntesten daran, mein cubase gegen irgend etwas anderes einzutauschen...
 
Zuletzt bearbeitet:
Hierzu müsstest du aber auch in 64 Bit aufnehmen um dieses 64 Bittige Signal dort durchzuschicken....
Hast du solch einen Wandler? ^^
 
Aber vsts die 32bit float ausgeben und deshalb meist 32bit float in den projekteinstellungen.

24bit (flac) mach ich nur bei audioaufnahme sessions. (Weil es solange man nichts ins file reinrechnet KEINEN unterschied macht, da ja 24bit wandler)

Sobald aber ein 32bit float signal auf 24bit fixed runtergerechnet wird kommt es i.d.R. immer zu quantisierungsrauschen, was wenn man den vorgang mit starken gain änderungen mehrfach wiederholt, also das signal mutwillig zerstört, deutlich hören kann.

Arbeite haupsächlich mit vsti und vsts drum hab ich relativ wenig audio und gönne mir den genuss des "verlustfreien spuren renderns" (was 0 sinn macht wenn man nur mit 24bit audio non-destruktiv arbeitet, was wohl die meisten machen werden // wenn man aber 32bit effekte auf 24bit audio rendert würden 32bit float der datenqulität wahrscheinlich dienlich sein, ob es platztechnisch sinn macht ist wieder ein ganz anderes kapitel...)
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.

Oft gelesene Themen

Zurück
Oben