Cubase 6.5 Timing Problem Mixdown

[Gast92251]

Das kann durchaus möglich sein. Der Timestretch/Pitchshift-Algo Elastique der Firma ZPlane wurde mit den Versionen in Cubase angepaßt und ebenso upgedated.

 

[BenHalen]

Sehr gut, dann weiß ich jetzt bescheid
Danke euch.

 

[PlanNine]

Genau, sehr gut, danke.
Und die Tatsache, dass Cubase 9.5 deutlich genauer gearbeitet hat, liegt vermutlich an einem etwas neueren/besseren Algorithmus, oder?

Das ist die Frage? Es ist eigentlich egal wie gut der Algorithmus arbeitet. Er kann nach dem Zufallsprinzip arbeiten oder nicht. Ich vermute das die unterschiede die eingangs erwähnt wurden durch die verwendeten Effeckte zustande kommen.

Was mal festgestellt wurde das es am Anfang des Arranger bei Midisignalen bzw. bei erzeugung des Audios einen Jitter gab. Die aufnahme 2 mal gemacht und eine phasengedreht löschten sich nicht aus. Bei Ableton hat das geklappt.
Einfach mal testen. 2 mal einen mixdwn machen en und die müssen gleich sein. Wenn es einen Unterschied zwischen dem Orginal von dem aus ein Mixdown gemacht wird gibt dann wird es an den Effeckten liegen. Bei Lautstärke an aus erwarte nicht das eine welle abgeschnitten wird, mindestens muss ein Nulldurchgang abgepasst werden.

 

[BenHalen]

Es sind doch gar keine Effekte drauf... Oder meinst du Audio Warp?

 

[Loop_Breaker]

Die Soundkarte und die Buffersize der Soundkarte haben keinen Einfluss auf den Mixdown.
C9.5.40

Ich habe 3 Mixdowns gemacht mit einem VST2 effeckt.
Driver Ein Weihnachtsgeschenk von NI. NI Ist immer gut für VST2
1. Ohne Soundkarte.
2. Asio4ALl 512 Buffersize.
3 Asio4All 2048 Buffersize,
Die ergebnisse sind alle gleich und wenn ich 2 vergleiche und
die Phase drehe löscht sich das Signal aus.


Wenn das Resultat unterschiedlich ist so würde ich mein Augenmerk
auf die verwendeten Effekte lenken.

Edit: Ich habe nochmal die Überschrift gelesen. Es geht um C 6.5. Aber ich denke das es dort das gleiche Ergebniss geben wird. Denn es macht einfach keinen Sinn den Mixdown von der Soundkarte abhängig zu machen. Die Soundkarte ist für die Sound Ein und Ausgabe zuständig.

Ich gebs jetzt auf. Habs mehrmals hier geschrieben. Sogar einen thread mit screenshots gemacht und hier verlinkt und einen steinberg artikel zitiert...

 

[PlanNine]

Es sind doch gar keine Effekte drauf... Oder meinst du Audio Warp?

Audiowarp verändert das Signal.

Es gibt einiges was das Signal verändern kann. Quantiseriung, Swing, Humanizer etc.
Auch gibt es Sampler die nicht jedes mal das gleiche Sample abspielen. Es können unterschiedliche sein.

 

[Loop_Breaker]

Zitat von vorheriger Seite:
1) Erstelle eine Audiospur, und tu diese Sample drauf: Vergleich der Genauigkeit von Automationen, bei verschiedenen DAWs (ist einfach ein gerader Strich in der Wellenformdarstellung...
2) Nimm ein VST2 Plugin, was Stille macht (z.B. Compressor wo Ausgang auf -inf geregelt ist)
3) Automatisiere den Bypass des Plugins (was Stille macht) so, dass es innerhalb des Samples mehrfach bypasst und un'bypass macht.
4) rendere das Automatisierte Sample mit:
- höchsten ASIO Puffer
- niedrigsten ASIO Puffer
- ganz ohne ASIO Treiber

und Vergleiche anschließend die Wellenformen untereinander und mit der Automation wie es eigentlich sein sollte:
Du wirst feststellen, dass es mit niedrigsten Puffer viel genauer ist, als mit höchsten Puffer.
Aber wie genau es, ohne Treiber ist, wäre ich sehr gespannt...

Leider kann ich das in den nächsten Tagen wahrsch. nicht machen weil ich nicht nach Hause komme...

 

[Gast92251]

Leider kann ich das in den nächsten Tagen wahrsch. nicht machen weil ich nicht nach Hause komme...

Was hast du denn jetzt wieder angestellt? Und hast du vielleicht irgendwie WLAN in der JVA?

 

[BenHalen]

Hmmm, ich kann mir eigentlich nicht vorstellen, dass Audiowarp nach dem Zufallsprinzip arbeitet. Könnte man mal testen.

 

[Nachtschicht]

Genau, sehr gut, danke.
Und die Tatsache, dass Cubase 9.5 deutlich genauer gearbeitet hat, liegt vermutlich an einem etwas neueren/besseren Algorithmus, oder?

genau. die meisten daws kaufen diese algorithmen ein. die zplane algorithmen werden auch nicht nur von cubase verwendet, und die sind in 9.5 in einer neueren version als im ja doch sehr alten 6.5 ("jetzt neu zplane algorithmus x.0!" ist ein von allen gerne verwendeter werbeslogan, aber frag mich jetzt bloss nicht bei welcher versionsnummer man jetzt gerade angekommen ist...aber sie ist in 9.5 höher als damals in 6.5 )

 

[Nachtschicht]

Genau, sehr gut, danke.
Und die Tatsache, dass Cubase 9.5 deutlich genauer gearbeitet hat, liegt vermutlich an einem etwas neueren/besseren Algorithmus, oder?

Das ist die Frage? Es ist eigentlich egal wie gut der Algorithmus arbeitet. Er kann nach dem Zufallsprinzip arbeiten oder nicht. Ich vermute das die unterschiede die eingangs erwähnt wurden durch die verwendeten Effeckte zustande kommen.

Was mal festgestellt wurde das es am Anfang des Arranger bei Midisignalen bzw. bei erzeugung des Audios einen Jitter gab. Die aufnahme 2 mal gemacht und eine phasengedreht löschten sich nicht aus. Bei Ableton hat das geklappt.
Einfach mal testen. 2 mal einen mixdwn machen en und die müssen gleich sein. Wenn es einen Unterschied zwischen dem Orginal von dem aus ein Mixdown gemacht wird gibt dann wird es an den Effeckten liegen. Bei Lautstärke an aus erwarte nicht das eine welle abgeschnitten wird, mindestens muss ein Nulldurchgang abgepasst werden.

daws sind sehr komplex, deswegen muss man diese themen immer aufdröseln, um nicht den wald vor lauter bäumen nicht mehr zu sehen. hier im thread werden grad mehrere themen bisschen verwirrend durcheinandergewürfelt.

1. nein, solche stretchalgorithmen arbeiten nicht zufällig. aber sie arbeiten dynamisch, heisst, sie stretchen mehr an stellen wo es nicht auffällt, und stretchen weniger wo es mehr auffallen würde (üblicherweise um die transienten herum). früher war timestretching ein starrer prozess. das war im timing berechenbarer, aber klang halt scheisse. vielleicht findet sich netz irgendwo ein klangbeispiel für zyklisches timestretching, aber falls nicht: es klang auf jeden fall sehr schnell so als würde man ein signal einmal durch die mülltonne jagen und moderne algorithmen oszillieren sprichwörtlich um einen sweet spot herum, der eine ideale balance zwischen timingfestigkeit und artefaktarmut findet. ab einem gewissen punkt ist das dann auch bisschen ansichtssache, weswegen du z.b. bei den zplane algorithmen ja auch verschiedene settings hast die die priorität eher auf timingtreue oder pitchtreue legen.

2. bei midi wirds schnell kompliziert. prinzipiell sind VST instrumente nur noch auf dem papier "midi" und in der praxis samplegenau. aber es gibt natürlich ausnahmen. manche plugins sind nicht samplegenau. entweder via design (etwa weil freilaufende oszillatoren) (wie so glückliche schafe auf der wiese, die klingen besonders gut ), oder wie im falle von spectrasonic vorn paar jahren wegen eines bugs. dann gibts natürlich, wurde hier ja schon erwähnt, sampler mit round robin, die löschen sich auch nicht in der phase aus, obwohl der vorgang an sich samplegenau abläuft. und dann gibts natürlich noch effekte, die per definition nicht nulltest-fähig sind. ein chorus z.b. hat üblicherweise 1-32 LFOs, und die laufen üblicherweise weder gesynct zum hosttempo noch zum transport start/stop, warum sollten sie auch. halleffekte haben eine randomisierung im wölkchen. viele delayeffekte vermenschlichen ihre delaytaps auch mit bisschen drift. viele zerrer haben bisschen randomisierung im algorithmus. die liste ist ziemlich endlos.

3. und dann gibts noch das sonderthema "automation". da ist es in der tat ein bestehendes problem, dass die präzision der automationsausführung im bounceprozess in relation zum asiopuffer steht. das ist ganz klar ein bug.

allerdings einer, der im alltag meines erachtens nicht wirklich ins gewicht fällt, dass der jahrelang niemadem aufgefallen ist sagt ja schon auch was aus

 

[Gast92251]

Guter Mann, der Nachtschicht! Es lohnt sich, hier zu sein.

 

[Loop_Breaker]

Denke nicht, dass das mit den vst2 automationen ein bug ist, betrifft ausserdem z.B. auch den Vollfader in Cubase... und leute die viel mit automation arbeiten fällt (schon seit zeiten wo ich selber noch gar nicht mit automationen gearbeitet habe), das sehr wohl auf mit den verschiedenen puffern beim export...


Hab hier mehrermals einen thread verlinkt der sich der auflösung von automationen widmet.

Zitat von: https://www.steinberg.net/de/suppor...ow/details-on-asio-guard-in-cubase-and-nuendo
"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."

gibt noch Andere Steinberg-Artikel wo darauf hingewiesen wird...

 

[Loop_Breaker]

Leider kann ich das in den nächsten Tagen wahrsch. nicht machen weil ich nicht nach Hause komme...

Was hast du denn jetzt wieder angestellt? Und hast du vielleicht irgendwie WLAN in der JVA?

Bei der JVA hab ich leider hausverbot, hab mich zu oft über schlechte automatisierung der abläufe beschwert...

 

[PlanNine]

@Loop_Breaker
Gut das du nicht doch nicht aufgegeben hast.
Dann war mein Messaufbau nich ausreichend um das abzubilden.

 

[Loop_Breaker]

Danke PlanNine!

 

[Nachtschicht]

Denke nicht, dass das mit den vst2 automationen ein bug ist, betrifft ausserdem z.B. auch den Vollfader in Cubase... und leute die viel mit automation arbeiten fällt (schon seit zeiten wo ich selber noch gar nicht mit automationen gearbeitet habe), das sehr wohl auf mit den verschiedenen puffern beim export...


Hab hier mehrermals einen thread verlinkt der sich der auflösung von automationen widmet.

Zitat von: https://www.steinberg.net/de/suppor...ow/details-on-asio-guard-in-cubase-and-nuendo
"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."

gibt noch Andere Steinberg-Artikel wo darauf hingewiesen wird...

nun gut, nennen wir es statt bug eine etwas suboptimale implementation einer funktion in einem pluginformat von 2004

nein, das ist in der praxis jahrelang so gut wie niemand aufgefallen. hier im forum z.b. ist es so gut wie nie thema gewesen, letztes jahr gabs mal nen längeren thread. in anderen foren ist mir das thema auch so gut wie nie begegnet. sagen wir mal so, wenn es vielen aufgefallen wäre, wäre das dann seit 2004 doch etwas häufiger und mit einer anderen dringlichkeit zur sprache gekommen