Buffer Size und Audio Mixdown Qualität

[musicdevil]

Hab früher nicht geglaubt, wenn jemand sagte, dass sein exportierter Mix anders klang, als vorher in der DAW (bestimmt habt ihr das auch schon mal gelesen)....kann natürlich damit zusammenhängen. Bei ner höheren Buffersize und viel Automation kann das schon schwanken.

 

[M73]

@ musicdevil: Die 4096 Samples gefallen mir am besten Signal ist einfach mal weg Im Prinzip wie bei meinem Test in Post # 108

 

[musicdevil]

Ha, ich glaub ich hab für Studio One die Lösung gefunden (Wer brachte mich hier drauf?).
Man kann in S1 die interne Blockgröße entriegeln und auf 32 Samples stellen, auch wenn die eigentliche Blockgröße auf zb. 4096 steht. Das Ergebnis sieht dann schon ganz okay aus.

 

[Bassmacher]

Auch lange Lautstärken-, Paning-, Filterfahrten- Automationen sind dann bei hohen Buffergrößen schön treppenförmig.

 

[Bassmacher]

Ha, ich glaub ich hab für Studio One die Lösung gefunden (Wer brachte mich hier drauf?).
Man kann in S1 die interne Blockgröße entriegeln und auf 32 Samples stellen, auch wenn die eigentliche Blockgröße auf zb. 4096 steht. Das Ergebnis sieht dann schon ganz okay aus.

Ich!

 

[drewsocial]

.

 

[musicdevil]

Ha, ich glaub ich hab für Studio One die Lösung gefunden (Wer brachte mich hier drauf?).
Man kann in S1 die interne Blockgröße entriegeln und auf 32 Samples stellen, auch wenn die eigentliche Blockgröße auf zb. 4096 steht. Das Ergebnis sieht dann schon ganz okay aus.

Ich!

Danke, das bewirkt anscheint tatsächlich, dass S1 irgendwie intern mit ner Buffersize von 32 arbeitet und auch exportiert, unabhängig von der eigentlich eingestellten Buffersize. Die Latenz ändert sich damit nicht. Hab mich immer schon gefragt, wozu diese Option nützlich sein könnte
Wie das mit anderen DAWs ist, weiß ich nicht, aber für S1 scheint das die Lösung zu sein.
Muss da mal noch paar Sachen testen, aber momentan scheint es so.

 

[Gast92251]

Gibt es bei Cubase PC ähnliche Optionen die Besserung verschaffen?

Die Blockgröße geht wohl in den jeweiligen Treiber/Asio Systemsteuerung.

aber Asio Guard hat wohl auch noch Einfluss:

Da ASIO-Guard in Cubase 8 weiter optimiert werden konnte, sind noch geringere Latenzen als bisher möglich. Dabei sollte beachtet werden, dass der Zeitraum, der für die Berechnung von Offline-Audio-Mixdown, Freezing und Render in Place benötigt wird, von der Größe des Buffers und damit von der Latenz abhängt. Je niedriger die Latenz, desto länger dauern diese Prozesse.
Durch die Erhöhung der Latenz lassen sich Audio-Mixdown, Freezing und Render in Place beschleunigen. Allerdings kann dies eine Verringerung der Auflösung der Automation zur Folge haben. VST2-Plug-ins berechnen pro ASIO-Block (entspricht der Buffer-Größe in Samples) einen Automationswert. VST3-Plug-ins entscheiden hingegen selbst, ob sie ihre Automationsdaten blockweise, samplegenau oder mit einer selbstdefinierten Auflösung berechnen.
https://www.steinberg.net/de/suppor...ow/details-on-asio-guard-in-cubase-and-nuendo

Was ist mit dem letzten Hinweis hier?

.

 

[Bassmacher]

Ha, ich glaub ich hab für Studio One die Lösung gefunden (Wer brachte mich hier drauf?).
Man kann in S1 die interne Blockgröße entriegeln und auf 32 Samples stellen, auch wenn die eigentliche Blockgröße auf zb. 4096 steht. Das Ergebnis sieht dann schon ganz okay aus.

Ich!

Danke, das bewirkt anscheint tatsächlich, dass S1 irgendwie intern mit ner Buffersize von 32 arbeitet und auch exportiert, unabhängig von der eigentlich eingestellten Buffersize. Die Latenz ändert sich damit nicht. Hab mich immer schon gefragt, wozu diese Option nützlich sein könnte
Wie das mit anderen DAWs ist, weiß ich nicht, aber für S1 scheint das die Lösung zu sein.
Muss da mal noch paar Sachen testen, aber momentan scheint es so.

Wäre ja cool, wenn das die Lösung ist. Mit 32 samples Buffersize könnte man ja auf jeden Fall mit gutem Gewissen leben.

 

[M73]

@ rkdk

Danke!

Hast du nen Link zu dem Text?

 

[M73]

Ha, ich glaub ich hab für Studio One die Lösung gefunden (Wer brachte mich hier drauf?).
Man kann in S1 die interne Blockgröße entriegeln und auf 32 Samples stellen, auch wenn die eigentliche Blockgröße auf zb. 4096 steht. Das Ergebnis sieht dann schon ganz okay aus.

Och man, ich auch haben will!!!

 

[M73]

VST2-Plug-ins berechnen pro ASIO-Block (entspricht der Buffer-Größe in Samples) einen Automationswert. VST3-Plug-ins entscheiden hingegen selbst, ob sie ihre Automationsdaten blockweise, samplegenau oder mit einer selbstdefinierten Auflösung berechnen.(steinberg.net)

D.h. wenn mans bei VST3 genau wissen will, muss man jedes Plugin testen da es jedem Hersteller frei gestellt ist wie er die Daten abgreift...

 

[drewsocial]

.

 

[Gast92251]

Hast du nen Link zu dem Text?

geht Link oben im Posting nicht? sonst mach copypaste

 

[M73]

Hast du nen Link zu dem Text?

geht Link oben im Posting nicht? sonst mach copypaste

Wurde nicht als Link erkannt und bei mir stand da nur "steinberg.net". Aber nun gehts mit Copy/Paste

 

[Gast92251]

VST2-Plug-ins berechnen pro ASIO-Block (entspricht der Buffer-Größe in Samples) einen Automationswert. VST3-Plug-ins entscheiden hingegen selbst, ob sie ihre Automationsdaten blockweise, samplegenau oder mit einer selbstdefinierten Auflösung berechnen.(steinberg.net)

D.h. wenn mans bei VST3 genau wissen will, muss man jedes Plugin testen da es jedem Hersteller frei gestellt ist wie er die Daten abgreift...

Ja, denke,so schaut´s tatsächlich IMHO aus.

Und nicht nur das:
Man müsste das mal in einem vollausgelasteten Song (!) mit kompletter Pluginmischung, VSTis und diversen Automationen probieren.
Denn das ist ja das, was wir wissen wollen - und nicht irgendeine einzelne Sinussägezahnwelle gerendert. ^^ Müsste dann ja überall schlimmer werden. hm. das check ich mal.

Irgendwo las ich, dass man bei der von Devil S1 Blockgröße (Häkchen+Änderung) besser nicht rumfummeln sollte, da es zu Dropouts oder Verrechnungsfehler o.ä. kommen KÖNNTE. Das wohl verstärkt in Abhängigkeit des verwendeten Asiotreibers/Soundkarte. Hm. nochmal checken.. spannend.
.


.

 

[M73]

So, Link mal gecheckt. Sehr interessant! Danke nochmal fürs verlinken.


Ich versuche jetzt mal folgendes:

Ich setzte den ASIO-Guard auf die höchste Stufe, sodass er möglichst viel Zeit zum Rechnen bekommt. Dies wirkt sich ja nur auf Spuren aus, die gerade nicht aktiv sind also nicht Live gespielt werden. Dann suche ich mir eine Spur welche hohe Anforderungen an den Treiber und die CPU stellt, schalte diese aktiv und schraube die Latenz so weit runter wie es mein System zulässt.

Das True-Peak-Meter kann sich ja dann aufführen wie es will, solange es nicht in den Overbereich kommt.

Bin gespannt wie weit runter ich die Buffersize mit Hilfe des ASIO-Guards schrauben kann. Mein Rechner ist ja potent genug.

Das habe ich so noch nie getestet. Mein System lief bisher immer mit meiner festgefahrenen Buffersize von 384 Samples (= ca. 8,7 ms).

 

[drewsocial]

.

 

[Gast92251]

Tja, nicht immer nur auf die Wellenform-Darstellung im Arrange verlassen - auch auf die OHREN verlassen ^^
Messen kann man ja vieles... Aber vieles verwirrt auch und kann wiederum unsicher machen.

Im Ernst mal, wer zoomt denn nach jedem Rendern wie wild bis auf eine Halbwelle hinunter - um Gerendertes haargenau bis auf den Mikro-Sample gegenzuchecken. Das ist doch irgendwie befremdlich.. ^^

Ha, was haben die Studioleute bloß früher gemacht, als sie überall per langer Kabelwege, analoger Mehrspurbandgeräte und Overdubs usw. versteckte Latenzen & Co. hatten, und Rauschen und Knistern auch noch hinzu kamen.... Wie war Musik nur möglich damals!!!

(/Ironiemodus OFF)



Zurück zum Thema.

.

 

[drewsocial]

.