Warum Kompressoren immer als Insert-, aber nicht als Send-Plugins?

  • Ersteller Mick Rütter
  • Erstellt am
Kannste das nochmal für Begriffstutzige wie mich erläutern?

- Der Sack

ja ich hab die kompressoren auf die Invertierte Spur gepackt und so eingestellt, dass sie nicht arbeiten. Dann die phasengedrehte Spur mit samt der Kompressoren exportiert und wieder reimportiert und die alte, gedrehte spur damit ersetzt.
Das habe ich auch mit einem Effektkanal, auf den ich die Invertierte Spur gesendet habe, gemacht.
Sowohl vor als auch nach dem Bouncing wurden die Spuren komplett ausgelöscht.
 
du nennst weitestgehend fehlerfrei perfekt ?

Mit "weitestgehend" meinte ich: Von einigen Ausnahmefällen mal abgesehen. Wobei auch diese immer seltener werden.


hier haben doch 2 Deppen lediglich darauf hingewiesen, dass es eben nicht immer so perfekt wie gewünscht abläuft.
Aus praktischen Erfahrungen.
Das sind momentane Ereignisse, die sich nicht mal in jedem Fall auf einen bestimmten Grund zurückführen lassen.
Aber sie passieren, deswegen hat pH das sinngemäss als: 'das weiss doch jedes Kind' genannt.

Ihr scheint in der Vergangenheit zu leben.
Heutzutage funktionieren die in diesem Thread angesprochenen Sachen in fast allen Sequenzern a) einwandfrei und b) zuverlässig. Dass das mal anders war, ist mir auch bekannt.
Aber in einem ordentlich konfiguriertem System klappt alles wunschgemäß. Bei mir jedenfalls seit einigen Jahren.

Und wie gesagt, wenn es auf euren Rechnern zu anderen Ergebnissen führt, dann ist etwas faul. Entweder an euren Rechnern oder an der Software. Beides lässt sich mehr oder minder einwandfrei ermitteln.

musst' halt mal etwas über den Tellerrand sehen und nicht so engstirnig sein.

Das hat überhaupt nichts mit "über den Tellerand schauen" zu tun. Es geht um richtig oder falsch, und in diesem Fall ist das eine ganz einfach nachzuprüfende Geschichte.
Nullt es oder nullt es nicht? Einfachst festzustellen. Gibt es einen nicht vorgesehenen Versatz welcher Signale auch immer? Ebenso einfach festzustellen.
Da ist auch nichts zufallsgesteuert.

nach deiner Einstufung von Rechnertechnik und Software müsste so was wie eine Treiberlatenz doch einfach, definiert und nachprüfbar festliegen. Mal vom Hersteller-Mogelfaktor abgesehen...

Natürlich nicht. Man kann ja als User seine Puffergrößen einstellen. Alle anderen Faktoren, wie etwa karteninterne Sicherheitspuffer, werden bei renommierten Unternehmen (etwa RME) angegeben, ansonsten kann man sie einfach selber ermitteln.

Das hat aber dennoch komplett nichts mit der Latenzkompensation innerhalb eines Hosts zu tun. Der Latenzkompensation ist es nämlich höchst schnuppe, ob im Treibermenü deiner Software 64 oder 1024 Samples angegeben sind. Die bekommt vom Plugin die Information "ich benötige jetzt 512 Samples zur Berechnung" und um den Betrag wird alles andere mit einem negativen Delay belegt.

ja ich hab die kompressoren auf die Invertierte Spur gepackt und so eingestellt, dass sie nicht arbeiten. Dann die phasengedrehte Spur mit samt der Kompressoren exportiert und wieder reimportiert und die alte, gedrehte spur damit ersetzt.
Das habe ich auch mit einem Effektkanal, auf den ich die Invertierte Spur gesendet habe, gemacht.
Sowohl vor als auch nach dem Bouncing wurden die Spuren komplett ausgelöscht.

Hm, ok. Klingt mir etwas umständlicher, als man das vermutlich "normalerweise" machen würde - vielleicht auch etwas unsicherer, denn man kann ja nicht zwangsläufig davon ausgehen, dass so ein Kompressor in der Tat gar nix macht, auch bei noch so niedrigem Threshold. Aber unterm Strich kommt dabei heraus, dass die Sache ganz einwandfrei funktioniert. Ist bei mir unter Logic kein bisschen anders (unter Cubase auch nicht, aber das nutze ich kaum noch).

Ich bin übrigens sicher, dass das in deinem Testsong auch noch heute, morgen, übermorgen und in 5 Jahren funktioniert. Oder sogar auf einem ganz anderen Rechner.
Von daher weiß ich nicht, was hier in diesem Thread von irgendwelchen zufallsgesteuerten zeitlichen Versätzen und dgl. geredet wird.

Es gab in der Vergangenheit (die zugegebenermaßen noch nicht *sooo* lange her ist) diverse Dinge, warum es, besonders im Timing-Bereich, oft tatsächlich arge Probleme gab. Grund dafür waren fast immer schlecht programmierte Treiber und/oder eine noch schlechtere interne Clock der Soundkarte. Die Auswirkungen waren dennoch eigentlich immer andere als ein unkontrollierbarer Versatz irgendwelcher paralleler Signale. Eigentlich hatte man es da eher mit Dingen wie zufallsgesteuerten Aufnahmeversätzen und dgl. zu tun. Schlimmer geht's kaum. Aber wie gesagt, die Latenzkompensation hat damit eigentlich nie etwas zu tun gehabt. Die gab es nur streckenweise noch gar nicht, oder sie war nur inkomplett implementiert, so dass bspw. Busse nicht mit einbezogen waren (wie etwa lange Zeit in Logic). Da kann dann sowas wie Parallelkompression natürlich nicht funktionieren.
Aber das ist alles schon ganz schön lange her. Mittlerweile sind die Hostprobleme eigentlich auf ganz anderen Baustellen zu suchen.

- Der Sack
 
- So'n Bounce ist, wenn nix kaputt ist, immer taktgenau (bzw. fängt der halt exakt am Anfang der Bouncing Range an). Und das zwar samplegenau. Wenn du jetzt digital mitschneidest, dann ist der Anfang des Files vermutlich nicht identisch mit dem Startpunkt des Bounces. Heißt, dass man die zwei aufgenommenen Signale erst einmal in Phase mit den beiden gebouncten bringen muss. Ist aber kein wirklich riesengroßes Problem, als ich noch richtig heiß auf's Testen war, habe ich sowas tatsächlich ein paar mal gemacht.
- Auch wenn es eigentlich komplett digital läuft, so musste ich doch ab und an gewisse Lautstärkeunterschiede zwischen Bounce und digital aufgenommen feststellen. Woran das liegt ist sehr schwer zu sagen. An sich sollten zwei korrekt digital verbundene Audiokarten da ein identisches Ergebnis liefern, aber anscheinend läuft da nicht immer alles ganz koscher ab.

Woher kommen denn auf einmal diese Ungenauigkeiten? In einem perfekt funktionierenden System dürfte das so nicht auftreten.
Ich weiß aus der Praxis, was du meinst, jedoch in diesem Kontext hier betrachtet scheint es die nicht in allen Randbedingungen testbare weil zu große Komplexität des Systems zu untermauern.
Beim Test von Software neigt man sehr gern dazu, einzelne abgeschlossene Funktionalitäten zu testen und freizugeben, ohne die Wechselwirkung mit allen anderen indirekt beteiligten und unter Umständen ungeplant beeinflussten Komponenten betrachtet zu haben.

Dieses Thema ist ziemlich heikel, weil wirtschaftlich/ökonomisch extrem relevant. Da kannst du auch gern selbst drüber lesen, z.B.:

http://books.google.de/books?id=dUKsxRJGM9MC&pg=PA244&lpg=PA244&dq=Softwaretests+optimistisch&source=bl&ots=p3X2A7V8xx&sig=xV-7Z8gAcr2bD56jMSv78J9fCh8&hl=de&sa=X&ei=4y1jT4zDNOfV4QT214GVCA&ved=0CHYQ6AEwCQ#v=onepage&q=Softwaretests%20optimistisch&f=false

Wie dem auch sei, solltest du wirklich auf diesen 4 Files bestehen und sind sie dann sauber getrimmt (so dass der Anfangspunkt in der Tat identisch ist), dann werden die danach in einem Mehrspurprogramm des Vertrauens (nunja, die Herren Telefunky und Hjalmarson kennen da vermutlich keines...) nebeneinandergelegt, und zwar auf komplett neutralen Spuren, einzig zulässig ist eine absolut identische Gainänderung. Danach werden Phasen einzelner Files gedreht. Wenn das Zusammenspiel des nicht gedrehten und gedrehten Files lautlos ist, dann sind die Files identisch.
Verstehe ich das richtig, dass du die Files, die du wie oben beschreiben bereits manuell korrigiert hast, jetzt als Testobjekte verwendest?
Welchen Aussagewert soll das denn noch haben?

Ich halte all das aber für absolut nicht notwendig. Ok, einen zeitlichen Versatz sollte man u.U. per externer Aufnahme überprüfen. Aber auch nur vielleicht, denn wenn das Bouncen funktioniert, dann wird auch der zeitliche Versatz mitgebounct. Und ob das Bouncen generell funktioniert, hat man selbstverständlich vorher getestet.
Welcher zeitliche Versatz? Den dürfte es doch von vorn herein gar nicht geben, wenn ich seiner zugrunde liegenden These folge...

Hat man dann festgestellt, dass es einen Zeitversatz zwischen linker und rechter Seite gibt, dann kann man anfangen, das auszusortieren. Wie ich schon erwähnte, war es in der Vergangenheit nicht selten, dass Plugins falsche Pufferwerte an den Host gemeldet haben. Oder sogar gar keine. Man muss also vorerst schauen, ob's die Plugins sind. Ist das nicht der Fall (also so, dass es mit jedem Plugin auftritt), dann darf man in der Tat mit dem Hostprogrammierer schimpfen, und zwar ganz tüchtig. Wenn da was versaut ist, dann bekommt man eigentlich überhaupt keinen gescheiten Mehrspur-Drummix mehr hin, weil man wegen Phasensauereien nichts auf unterschiedlichen Bussen bearbeiten dürfte.

Ist alles in Butter kann man danach das Bouncen testen. Wobei man das ja vielleicht schon vorher gemacht hat.
Bouncetests sind an sich das Einfachste auf der Welt. Man muss sich nur komplett von allem Dithern und dgl. verabschieden. Einfach rausbouncen, Bounce auf 'ne Stereospur importieren, an die Stelle der Bounce Range setzen, Phase umdrehen, hören. Eigentlich sollte Stille herrschen.
Das testet man übrigens für's Erste niemals mit modulierenden Signalen, folglich auch nicht unbedingt mit einem kompletten Mix.
Warum? Weil es unter Plugin-Entwicklern bisweilen seltsame Sichtweisen zum Thema "Host Sync" oder "free running" zu geben scheint. Wenn der Host Sync nicht immer identisch ist (das kann sein - es gibt Plugins, die sich tatsächlich nach der Framerate zu richten scheinen...), dann hat man natürlich beim Gegenhören ein Problem.
Auch haben zumindest streckenweise einige Entwickler mit wirklich frei laufenden LFOs und dgl. rumgetestet. Weil's halt in der analogen Welt auch sowas gibt. Da klingt's dann, den Bounce mal vollkommen draußen vor gelassen, bei jedem Songstart anders. Eben so wie mit alten analogen MIDI-Kisten.
Unter den Voraussetzungen kann ein Bounce-Test natürlich nicht funktionieren.
In allen anderen Fällen sollte es das aber. Oder es ist eben etwas kaputt. Und dem kann man eigentlich sehr genau auf die Schliche kommen.
Ohne jetzt auf jedes Detail einzugehen, das klingt mir nach allem anderen, aber nicht nach einem "perfekten" System.
Ich würde wirklich gern wissen, ob die Ergebnisse bitgenau sind und befürchte, dass dem nicht so ist. Dass man "alles auch schon in einer schnöden analogen Aufnahme" hören könnte, ist klar. Welchen Wert hat die Aussage? Klar, was ich nicht höre, existiert im Audio-Kontext erst einmal nicht.
Um aber aussagekräftig die These zu untermauern, dass es keine Abweichungen auf Bit-ebene gibt - und das sollte man bei einem perfekten System eigentlich erwarten dürfen - reicht das nicht.
Ich denke, wir brauchen jetzt nicht darüber zu diskutieren, wie groß die digitale Differenz sein muss, damit man sie hörbar wahrnehmen kann.
 
...Ihr scheint in der Vergangenheit zu leben...
oh ja...
zumindest was meine Wenigkeit betrifft tue ich das akustisch durchaus :D
diese modernen Drecksproduktionen sind einfach nicht mein Ding
oder das ultracleane, chirurgische Zeuchs hoher musikalischer Schule *schauder*
(aber das hat mit dem Thema wirklich nichts zu tun) :p

apropos Thema...
du bist derjenige, der es hier kaugummiartig auf Weltanschauungniveau gehoben hat
(ich muss mir leider den Schuh anziehen, drauf eingestiegen zu sein) :redface:
es stört mich nicht die Bohne, wenn du deinen Rechner für perfekt hälst
ich schliesse nicht mal aus, dass er es tatsächlich ist (rein statistisch existiert auch diese Möglichkeit)
aber ich verallgemeinere die Erkenntnis nicht. ;)

aus praktischer Erfahrung sehe ich einiges an Fehlerpotential
habe aber nie behauptet, dass es ein 'Dauerzustand' ist (was du da offenbar hineinterpretierst)
Nur bin ich der Meinung, dass gegenüber der Problematik dauernde Aufmerksamkeit angebracht ist ;)

cheers, Tom
 
Threads wie diese, oder solche zum "Klang von verschiedenen DAWs", laufen in allen Foren nach dem gleichen Schema ab.

Da gibt es Leute wie Dummer Sack (meistens in der Minderheit), die wissenschaftlich argumentieren, viele Dinge detailreich ansprechen und diese auch fundiert begründen.
Und dann Leute wie pHjalmarson oder Telefunky, die behaupten, irgendwas zu hören, und dass es deswegen so sein muss, weil sie es ja so hören (oder sich einbilden es zu hören).

Im Grunde genommen wären solche Diskussionen hinfällig, wenn Leute wie Telefunky und pHjalmarson einfach nur sagen würden: "Ich kann hier einen Unterschied hören, und deswegen verwende ich dieses System/Plug-in/was-auch-immer".
Fein. Ihr hört einen Unterschied, also verwendet einfach euer Zeug, und gut ist.

Das Problem ist aber, dass sie sagen: "Ich höre einen Unterschied, und deswegen IST er auch da".
Und diese Aussage ist ohne jeglichen wissenschaftlichen Nachweis einfach schwachsinnig.

Es gibt unzählige wissenschaftliche Untersuchungen, die ganz klar belegen, dass unsere Sinne uns (oft!) täuschen können, und sehr stark von unseren Überlegungen/Vorurteilen beeinflusst werden. So ist die Beurteilung von klanglichen Unterschieden NUR in Blindtests zulässig und aussagekräftig.
Wenn man weiß, dass Klangbeispiel A aus Cubase, Klangbeispiel B aus Pro Tools ist, ist der Vergleich absolut sinnlos.
(Wohlgemerkt, bei Themen wo es um absolute klangliche Nuancen geht!)

Meistens werden diese Leute in solchen Threads (wie auch hier) dann dazu aufgefordert, auch nur EIN konkretes Beispiel für ihre These zu liefern, so dass andere es nachvollziehen können. Das ist der Punkt, wo es dann schnell still wird. Bisher habe ich es in keinem solcher Threads erlebt, dass dann auch tatsächlich was gebracht wurde.
In der Regel wird dann die Frage nach einem Beispiel (wie auch hier) einfach ignoriert, oder, wenn die Gegenseite (Dummer Sack) lange genug darauf beharrt, kommen dann Aussagen wie: "Brauche ich nicht beweisen, denn hört ja eh jedes Schwein" :mad::bang:

Die besondere und abschließende Pointe, die in solchen Threads dann meistens noch dazukommt (so wie auch hier), dass die Leute, die nur daherschwafeln, wie pHjalmarson, dann mangels Argumenten beginnen, der Gegenseite Dinge vorzuwerfen, die eigentlich ihnen selber vorzuwerfen sind.
Wie etwa, dass Dummer Sack auf nichts konkretes eingehen würde, wo er in Wahrheit hier auf so ziemlich jede Aussage der Gegenseite ausführlichst (!) eingegangen ist, und pHjalmarson sogar zugibt, dass er ganze Posts nicht einmal gelesen hat :bang:

Das ist ganz einfach nicht ernst zu nehmen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: 4 Benutzer
Die bekommt vom Plugin die Information "ich benötige jetzt 512 Samples zur Berechnung" und um den Betrag wird alles andere mit einem negativen Delay belegt.
- Der Sack

was meinst du jetzt mit negativem Delay. Verlängern oder Verkürzen der anderen Spuren?

Ich denke, wir brauchen jetzt nicht darüber zu diskutieren, wie groß die digitale Differenz sein muss, damit man sie hörbar wahrnehmen kann.

Bei meinem Beispiel hat ein Versatz von bereits einem Sample ausgereicht, um es wieder deutlich hörbar zu machen. Vorher war alles still.

Hm, ok. Klingt mir etwas umständlicher, als man das vermutlich "normalerweise" machen würde - vielleicht auch etwas unsicherer, denn man kann ja nicht zwangsläufig davon ausgehen, dass so ein Kompressor in der Tat gar nix macht, auch bei noch so niedrigem Threshold.

Und trotz der 8 Kompressoren mit einem Threshold von 0db hatte ich eine komplette Auslöschung der Spuren. Ich habe es deswegen so kompliziert gemacht, um möglichst viele Fehlerquellen einschließen zu können.


Ich glaube, dass ihr hier einfach deutlich anneinander vorbei redet. In meinem Beispiel gab es keinen Sampleversatz. Heißt also der Computer der Host und die Plugins haben einfwandfrei gearbeitet. Allerdings schließe ich nicht aus, dass es bei Erhöhung der Systemlast und dem Verwenden von verschiedenster Plugins zu Sampleversatz kommen kann.
 
Zuletzt bearbeitet:
du scheinst aber auch nur flockig quergelesen zu haben... ;)
...Im Grunde genommen wären solche Diskussionen hinfällig, wenn Leute wie Telefunky und pHjalmarson einfach nur sagen würden: "Ich kann hier einen Unterschied hören, und deswegen verwende ich dieses System/Plug-in/was-auch-immer".
Fein. Ihr hört einen Unterschied, also verwendet einfach euer Zeug, und gut ist.

Das Problem ist aber, dass sie sagen: "Ich höre einen Unterschied, und deswegen IST er auch da".
das ist, mit Verlaub, deine ganz private Interpretation dessen, was ab post #14 folgte
es ging nie um einen gehörten Unterschied ' besser oder schlechter' und schon gar nicht auf Produkte bezogen.
Ich unterstelle einem 'modernen' Sequencer-System eine gewisse Ungenauigkeit, die es laut Sack nicht haben kann.
das ist bereits alles...

cheers, Tom
 
du scheinst aber auch nur flockig quergelesen zu haben... ;)

das ist, mit Verlaub, deine ganz private Interpretation dessen, was ab post #14 folgte
es ging nie um einen gehörten Unterschied ' besser oder schlechter' und schon gar nicht auf Produkte bezogen.
Ich unterstelle einem 'modernen' Sequencer-System eine gewisse Ungenauigkeit, die es laut Sack nicht haben kann.
das ist bereits alles...

cheers, Tom

Und diese Unterstellung hast du woher abgeleitet? Indem du etwas gehört hast, oder?
Du hast ja selbst z.B. geschrieben, dass DSP-gestützte Systeme "tighter" klingen sollen.

Bring bitte ein Beispiel, so dass wir es nachvollziehen können.
 
was meinst du jetzt mit negativem Delay. Verlängern oder Verkürzen der anderen Spuren?
es wird einfach die Abspielposition verschoben...
ich nehme mal den Transient Designer, der braucht bei mir exakt 41 Samples.
dann muss dessen Spur entweder um diesen Betrag vorgezogen werden, oder der gesamte Rest nach hinten
alles easy...
witzig wird das aber in Effektketten, speziell wenn sidechaining aus anderen Bussen zum Einsatzu kommt
man kann da schon recht schnell in einen Bereich kommen, wo die 'engine' echte Entscheidungsprobleme hat
(deswegen meine Unterstellung potentieller Fehlerquellen)
das ist aber akustisch in vielen Fällen lange nicht so relevant, wie es im ersten Moment scheinen mag
(Kirche im Dorf lassen - bei Bändern war das völlig normal)

cheers, Tom

---------- Post hinzugefügt um 14:48:38 ---------- Letzter Beitrag war um 14:35:11 ----------

Du hast ja selbst z.B. geschrieben, dass DSP-gestützte Systeme "tighter" klingen sollen.
klar, zu der Aussage stehe ich auch - aber ich bedaure, sie in diesem Kontext gemacht zu haben.
es ist mein Eindruck auf meinem System wenn ich zwischen komplett VST und komplett DSP wechsele
da gibt es keinen Grund irgendetwas zu beweisen oder gar zu rechtfertigen
(mir doch egal wer worauf was macht)
ich habe mir halt meine Gedanken dazu gemacht (das an anderer Stelle auch als für mich ausreichend bezeichnet)
(wenn irgendjemand für sich einen anderen oder wissenschaftlichen Grund sucht, ist mir das Latte)
steck dir 'ne gebrauchte Creamware Karte für 100 Euro in den Rechner und hör's dir an ;)
oder auch nicht

wenn du's quantitativ magst: etwa in der Grössenordnung wie ein Neumann 102 zu einem 103
aber das hat mit der Fragestellung nichts zu tun

erwähnt habe ich das nur, weil das System ausschliesslich manuellen Laufzeitausgleich bietet
(habe ich auch begründet warum)
ergo bin ich mit der Fragestellung vertraut - und gelegentlich überrascht worden, dass da Fehler auftauchen.
die Mixer Plugins sind von Haus aus auf diese Problematik hin entsprechend korrigiert.
und trotzdem springt irgendwann mal ein Kanal 1-2 Samples raus, nicht regelmässig, kein Muster, Zufall

daraus und der Tatsache, dass dieses DSP System seinen Job völlig ungestört machen kann, habe ich bei einer Desktop CPU ein höheres Fehlerpotential abgeleitet - imho ein durchaus zulässiger Schluss. Für andere anscheinend ein Sakrileg :D

cheers, Tom
 
wobei das vorziehen nur dann funktioniert, wenn das Audiomaterial bereits vorhanden ist.
Ich denke ( und zumindest ist es bei Cubase so) wird die Latenzkompensation immer in die positive Richtung arbeiten. Heißt also, dass alle Spuren in ihrer Latenz and die Spur mit der größten Latenz angeglichen wird. Verlängerung also.
Es geht ja eigentlich auch nicht anders. Nehmen wir mal einen externen Synth oder externe Effekte. Es kann nicht etwas vorhanden sein, was noch gar nicht passiert ist, und somit kann man einen externen Synth auch nicht vorziehen. Richtig?
 
doch, kann man - ich habe einen ollen Roland Sampler, der so was macht.
Im Prinzip loopt der ununterbrochen eine kurze Aufnahmeschleife, auch wenn nix scharfgeschaltet ist...
problematisch sind eher Effektketten mit internen Abhängigkeiten

cheers, Tom
 
wobei das vorziehen nur dann funktioniert, wenn das Audiomaterial bereits vorhanden ist.
Ich denke ( und zumindest ist es bei Cubase so) wird die Latenzkompensation immer in die positive Richtung arbeiten. Heißt also, dass alle Spuren in ihrer Latenz and die Spur mit der größten Latenz angeglichen wird. Verlängerung also.
Es geht ja eigentlich auch nicht anders. Nehmen wir mal einen externen Synth oder externe Effekte. Es kann nicht etwas vorhanden sein, was noch gar nicht passiert ist, und somit kann man einen externen Synth auch nicht vorziehen. Richtig?

Ich kann jetzt nur von Logic reden, da ist es so, dass der channelstrip mit dem latenzlastigen PlugIn im Timing vorgezogen wird.
Anders im AUX: Wenn da ein latenzlastiges PlugIn hängt, werden die anderen Kanäle zeitlich verzögert.
 
was meinen Ansatz bestätigt. Im ersten Fall ist das Audiomaterial bereits vorhanden. Im zweiten Beispiel kommt es ja in Abhängigkeit der Hauptspur.

doch, kann man - ich habe einen ollen Roland Sampler, der so was macht.
Im Prinzip loopt der ununterbrochen eine kurze Aufnahmeschleife, auch wenn nix scharfgeschaltet ist...
problematisch sind eher Effektketten mit internen Abhängigkeiten

cheers, Tom

OK das ist natürlich aber etwas Anderes. Da ist ja das Audiomaterial schon vor dem Abspielen vorhanden ;)


Ich denke, man kann es so runterbrechen. Wenn wirklich alles ITB gemacht wird und nur die CPU beteiligt ist, kann das System ohne Sampleversatz arbeiten. Bei DSP Systemen kommen ja noch "externe" Chips zum Einsatz. Da kann es natürlich immer zu Asynchronität kommen.

Bestes Beispiel sind doch 2 Grafikkarten, die im SLI oder Crossfire modus arbeiten. Dort wird dann z.b. die eine Karte die obere Bildhälfte berechnen und die 2te Karte die untere. Das läuft nicht immer synchron und es kommt zu Tearing. Läuft also nicht perfekt.
 
ja... ich hab da auch 2x drüberlesen müssen, was genau sie sich dabei gedacht haben... :D
 
Moin!

Hier einmal die versprochenen files. Es handelt sich um einen Arp aus dem Popgenre.
Um dem blechernen sound entgegen zu steuern proberite ich verschiedene plugins in Kombo mit dem 550B aus, letztlich duplizierte ich die Spur um doch einbisschen vom original zu behalten (zu viel ist zu viel :D). Das 550 Modul auf beiden ITB vorsummierten Spuren zur Einheit.
Was passierte könnt ihr euch selber anhören. Es sind 4 Spuren, jeweils 1x mit und 1x ohne Effekt (der API ist auf bypass) auf Parallelspur je 2x nativ und 2x TDM.
Endauflösung: 44.1kHz, 16bit.

Nativ Roh
Nativ Effekt
TDM Roh
TDM Effekt

So viel Spaß damit :)

PS.: Es wurde nicht gebounced, alles RT (ginge ja auch nicht anders). Das ist das extremste Beispiel was ich finden konnte, sonst macht die DK eig. einen guten Job und verhindert sonen Phasenbrei. Aber komplet Latenzen wegzaubern kann sie IMHO (noch) nicht.
 
Zuletzt bearbeitet:
also wie genau bist du da jetzt vorgegangen`?:gruebel:
 
@dummer sack: nun bist du dran, du bist auf meine zweite Bitte deinen vorgeschlagenen Beweis zu tätigen noch nicht mal eingegangen..

@Reflex: Hörs dir an, vergleiche und dann urteile über meine Aussage okay? ;)

@Novik: in PT (org Projekt) einfach beide Spuren auf solo (da noch eines der Delays der Stimmspuren darauf geroutet war) und vom Kanal-DO abgefangen. Die Rohspuren sind auch je beide, allerdings ist jetzt auf dem Duplikat das plugin aus. In Nuendo das gleiche, nur dass ich lediglich die zwei Spuren in mein Mixtemplate eingefügt und den Rest der Schaltung ausm org Projekt nachgebaut habe.
 
Langsam wirst du echt frech Junge..
Nur weil du deine Postion nicht mehr glaubwürdig durchsetzen kannst heißt das nicht, das du damit anfangen solltest.

Was genau ist nicht glaubwürdig?
Und was ist frech? Etwa sowas wie "This is Sparta"?

Angeboten - lol
Und ich hab geantwortet, dass ich das gerne sehe möchte. Ist was gekommen? Nö! Du bist der größte Spinner der hier immoemnt rumirrt hab ich langsam das Gefühl.

Möchtest du einen Logic oder einen Cubase Song?

Was ich auf Facebook für Bider habe kann dir jawohl scheiß egal sein oder seh ich das falsch? Der link ist nur für OT Fragen o.ä. gedacht, nicht zum rumschnüffeln für neugierige Leute ;)

Ich schnüffele, so viel ich will. Wenn dir das nicht passt, nimm den Link hier raus.

Bringst in jedem Post den gleichen Mist ohne auf konkrete Sachen einzugehen.

WiE BITTE? Worauf genau bist du denn bisher konkret eingegangen?

Last but not least: Am besten verkneifen wir uns das einfach persönlich zu werden okay? Das bekommt dir glaube ich nicht besonders gut ;)

Ach so, verstehe - wegen "This is Sparta", oder?

Woher kommen denn auf einmal diese Ungenauigkeiten? In einem perfekt funktionierenden System dürfte das so nicht auftreten.
Ich weiß aus der Praxis, was du meinst, jedoch in diesem Kontext hier betrachtet scheint es die nicht in allen Randbedingungen testbare weil zu große Komplexität des Systems zu untermauern.

In dem speziellen Fall hatte es der eine Soundkartenhersteller anscheinend nicht so genau genommen, was den Pegelangleich an den digitalen Ausgang angeht.

Beim Test von Software neigt man sehr gern dazu, einzelne abgeschlossene Funktionalitäten zu testen und freizugeben, ohne die Wechselwirkung mit allen anderen indirekt beteiligten und unter Umständen ungeplant beeinflussten Komponenten betrachtet zu haben.

Da gebe ich dir vollkommen recht. Aber genau deshalb testet man eigentlich einzelne Funktionalitäten.

Verstehe ich das richtig, dass du die Files, die du wie oben beschreiben bereits manuell korrigiert hast, jetzt als Testobjekte verwendest?
Welchen Aussagewert soll das denn noch haben?

Die sind nur insofern korrigiert worden, als ich wissen wollte, ob das digital aufgenommene File mit dem gebouncten soundtechnisch identisch ist. Dafür muss man es leider manuell korrigieren, weil es einem kaum gelingt, den Startpunkt der Aufnahme samplegenau identisch mit dem Startpunkt des Bounces hinzubekommen.

Welcher zeitliche Versatz? Den dürfte es doch von vorn herein gar nicht geben, wenn ich seiner zugrunde liegenden These folge...

Äh, wessen These jetzt?

Ohne jetzt auf jedes Detail einzugehen, das klingt mir nach allem anderen, aber nicht nach einem "perfekten" System.
Ich würde wirklich gern wissen, ob die Ergebnisse bitgenau sind und befürchte, dass dem nicht so ist. Dass man "alles auch schon in einer schnöden analogen Aufnahme" hören könnte, ist klar. Welchen Wert hat die Aussage? Klar, was ich nicht höre, existiert im Audio-Kontext erst einmal nicht.

Bitgenau kann man nur bei einem Bounce feststellen. Einen zeitlichen Versatz bei quasi jeder Aufnahme, speziell aber dann, wenn sie digital gemacht wurde.

Um aber aussagekräftig die These zu untermauern, dass es keine Abweichungen auf Bit-ebene gibt - und das sollte man bei einem perfekten System eigentlich erwarten dürfen - reicht das nicht.

Wenn ich einen Bounce in ein Projekt reimportiere und invertiere, danach Stille rauskommt, dann reicht das durchaus vollkommen.

du bist derjenige, der es hier kaugummiartig auf Weltanschauungniveau gehoben hat

Mitnichten. Ich habe nach Beispielen gefragt, die belegen würden, was du sagst. Bei mir laufen sowohl Latenzausgleich wie auch Bounce problemlos und bestehen jeden Nulltest.

Ich glaube, dass ihr hier einfach deutlich anneinander vorbei redet. In meinem Beispiel gab es keinen Sampleversatz. Heißt also der Computer der Host und die Plugins haben einfwandfrei gearbeitet. Allerdings schließe ich nicht aus, dass es bei Erhöhung der Systemlast und dem Verwenden von verschiedenster Plugins zu Sampleversatz kommen kann.

Mit der Systemlast hat das an sich nicht viel zu tun. Wenn die Last ansteigt, gibt's Knackser oder komplette Aussetzer.

Ich unterstelle einem 'modernen' Sequencer-System eine gewisse Ungenauigkeit, die es laut Sack nicht haben kann.

Mein Sequenzer-System ist genau. Das kann ich nachweisen. Du hingegen kannst die ungenauigkeiten, von denen du redest, nicht nachweisen. Dabei sollten sich Ungenauigkeiten viel einfacher nachweisen lassen.

klar, zu der Aussage stehe ich auch - aber ich bedaure, sie in diesem Kontext gemacht zu haben.
es ist mein Eindruck auf meinem System wenn ich zwischen komplett VST und komplett DSP wechsele
da gibt es keinen Grund irgendetwas zu beweisen oder gar zu rechtfertigen

Wenn man so steif und fest auf etwas besteht, sollte man das auch nachweisen können.

daraus und der Tatsache, dass dieses DSP System seinen Job völlig ungestört machen kann, habe ich bei einer Desktop CPU ein höheres Fehlerpotential abgeleitet - imho ein durchaus zulässiger Schluss. Für andere anscheinend ein Sakrileg :D

"Abgeleitet"? Also doch nicht gehört? Geschweige denn nachweislich zur Hand?

Ich kann jetzt nur von Logic reden, da ist es so, dass der channelstrip mit dem latenzlastigen PlugIn im Timing vorgezogen wird.
Anders im AUX: Wenn da ein latenzlastiges PlugIn hängt, werden die anderen Kanäle zeitlich verzögert.

Das stimmt nicht ganz so. Logic verzögert bei Vorhandensein latenzlastiger Plugins immer auch alle live eintreffenden Signale. Dafür gibt es ja auch diesen Tacho-Button, der dann, wenn man trotz solch vorhandener Plugins, etwas per Softwaremonitoring einspielen möchte, diese aus dem Signalweg des Live-Signals nimmt. Ist übrigens ziemlich gut gelöst so.

Im ersten Fall ist das Audiomaterial bereits vorhanden. Im zweiten Beispiel kommt es ja in Abhängigkeit der Hauptspur.

So ist es. Wobei "Hauptspur" natürlich auch ein Bus sein kann.

Ich denke, man kann es so runterbrechen. Wenn wirklich alles ITB gemacht wird und nur die CPU beteiligt ist, kann das System ohne Sampleversatz arbeiten. Bei DSP Systemen kommen ja noch "externe" Chips zum Einsatz. Da kann es natürlich immer zu Asynchronität kommen.

Prinzipiell sollte das nicht so sein. Nehmen wir als Beispiel die UAD Karten. Die teilen über die Plugin-Schnittstelle dem Host ebenfalls ihre Latenz mit, so dass unterm Strich wieder alles samplegenau passt. Bzw. passen sollte. Es gibt wohl den ein oder anderen UAD Anwender, bei dem das zur Verärgerung geführt hat. Dazu kann ich persönlich keine Aussage treffen.



Hier einmal die versprochenen files.

Würdest du jetzt bitte auch noch erklären, was genau diese Files jetzt demonstrieren sollen? Die Unterschiede sind offensichtlich, aber was genau bezweckst du damit zu beweisen? Dass ein TDM Plugin anders als ein natives klingt? Oder was sonst noch?

@dummer sack: nun bist du dran, du bist auf meine zweite Bitte deinen vorgeschlagenen Beweis zu tätigen noch nicht mal eingegangen..

S.o. Logic oder Cubase?

- Der Sack
 
Hatte ich schonmal gesagt, gerne beides!

Nein, dass es einen Sampleversatz geben kann. Darum gings ja schließlich. Und der ist bei beiden deutlichst zu hören. Auf der nativen IMHO sogar noch etwas deutlicher (subjektiv). Man kann das sehr leicht korrigieren, aber zu aller erst steht da nunmal der Versatz.

Was ist denn daran frech? xD Das beschreibt nur, wie ich bei persönlichen Beleidigungen empfinde. So dürfte es auch jedem Mann gehen, der eine lässt es raus der andere staut es an^^
Du hingegen hast mit deinen Sätzen versucht, mir Unfähigkeit zu unterstellen bzw. mich als Idiot darzustellen. Da ist ein großer Unterschied.
 
Wenn da ein Sampleversatz ist, dann funktioniert dein System nicht. Was daran nicht funktioniert, wer soll's wissen, wenn nicht du?
 
  • Gefällt mir
Reaktionen: 2 Benutzer

Ähnliche Themen


Unser weiteres Online-Angebot:
Bassic.de · Deejayforum.de · Sequencer.de · Clavio.de · Guitarworld.de · Recording.de

Musiker-Board Logo
Zurück
Oben