- Registriert
- 05.04.11
- Beiträge
- 6.433
- Reaktionen
- 2.169
24bit PCMin was für einem format exportieren wir eigentlich? 32bit fixed?
Kannst du mein Problem mit reaper mal überprüfen?
Bzw. mir ne Antwort geben zu dem Levelproblem? Wäre nett.
Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
24bit PCMin was für einem format exportieren wir eigentlich? 32bit fixed?
Ich denke alles was ein nicht-100%iges nullen auslöst sind interne Gainstagingprobleme
ich habe nicht genau verstanden was du gemacht hast. pegel, panlaw, dithering usw. hast du schon überprüft?Kannst du mein Problem mit reaper mal überprüfen?
Bzw. mir ne Antwort geben zu dem Levelproblem? Wäre nett.
reaper & SAM arbeiten mit 64bit FP (ich denke PT native auch). da gibts quasi kein gainstaging (da aufgrund der floating point architektur nicht benötigt).Ich denke alles was ein nicht-100%iges nullen auslöst sind interne Gainstagingprobleme
rechenfehler beim summieren zweier vektoren? unwahrscheinlich. bei ungenauen werteangaben könnte ich mir folgendes vorstellen:also ungenaue Werteangaben oder von rechenfehlern?
Ich denke alles was ein nicht-100%iges nullen auslöst sind interne Gainstagingprobleme
aber warum gibt es interne gainstagingprobleme? sprechen wir von einem rein optischen, also ungenaue Werteangaben oder von rechenfehlern?
Gerade letztere können ja dann zu großen Problemen innerhalb einer Mischung führen, und erstere einen aufwendigeren DAW -Vergleich absolut unmöglich machen...
du hast das file für reaper exportiert, den vergleich für SAM aber direkt (& sofort, d.h. ohne erneutes exportieren) in SAM gemacht? falls ja, ist die erklärung: du stößt hier an die grenzen der 24bit auflösung. reaper ist in diesem fall dann "benachteiligt", da es mit den 24bit arbeiten muss, SAM hingegen zugriff auf die internen 64bit float hat.Karumba:
Ich hab zwei der bereits gebouncten vergleichsfiles erst "normal" vergleichen; eins verpolen = 100% Auslöschung. Dann hab ich bei einem in den Take properties bzw. im Objekteditor die Lautstärke auf -45dB, beim anderen auf -50dB gesetzt. Den Unterschied von 5dB habe ich dann per Spurfader wieder ausgelichen.
Daraufhin konnte ich in Totalmix bei reaper einen Differenzpegel von etwa -90dB feststellen. In SAM waren es -125dB.
Interessant. Bei mir lässt sich das auch mit SAM vs SAM reproduzieren.Sprich SAM Bounce gegen PT Bounce Gain 0 und Fader 0 löschen sich zu 100 % aus. Absolut kein Differenzsignal zu messen. Wenn ich das SAM File um 6 dB im Clip absenke und dann mit dem Fader 6 db aufhole, dann habe ich fast -45 db Pegel auf der Summe.
Wenn ich dass ganze aber mit ner Kopie des PT Bounce mache, dass ist es sowohl bei Gain 0 Fader 0 als auch bei Gain -6 Fader +6 eine 100 %ige Auslöschung.
Und was sagt mir das jetzt?
nein.du hast das file für reaper exportiert, den vergleich für SAM aber direkt (& sofort, d.h. ohne erneutes exportieren) in SAM gemacht? falls ja, ist die erklärung: du stößt hier an die grenzen der 24bit auflösung. reaper ist in diesem fall dann "benachteiligt", da es mit den 24bit arbeiten muss, SAM hingegen zugriff auf die internen 64bit float hat.
Es geht nur darum die Files ohne Panning zu Summieren und das Ergebnis mit der Summe aus PT und den anderen DAWs zu vergleichen.
Da sich in PT der Panausgleich nicht abstellen lässt, werden alle Monosignal automatisch um 3 db angepasst. Dass muss in den anderen DAWs natürlich ausgeglichen werden, damit es stimmt.
ist das panlaw eigentlich exakt 3.0000dB oder faktor 2 im sinne von 10*log10(2) = 3.0103dB?Da sich in PT der Panausgleich nicht abstellen lässt, werden alle Monosignal automatisch um 3 db angepasst.
bei reaper und SAM nullt es dann wenn ich alle objekte und fader wieder auf 0 stelle, perfekt...Also für PT hab ich den Fehler eingegrenzt. PT scheint beim Clip Gain etwas zu runden. Wenn man das Clip Gain wieder auf 0 hochschiebt, dann nullt es auch nicht mehr. Nur wenn man das File wieder neu importiert dann nullt es wieder.
wo muss man interpolieren, wenn man sample-weise verschiebt? das ändert doch an der vektoraddition nichts. sinc wird afaik für die (etwaige) SRC verwendet.Es liegt an den Delays der Spuren, wenn man welche einfuegt!
Wenn die DAW sauber arbeitet, muss die DAW interpolieren.
Das macht Reaper und deshalb hat Reaper die verschiedenen Qualitaetsstufen zur Wahl.
Zum Beispiel Sinc mit 256 Samples.
Wenn man also einen guten Test machen WILL, dann muss man Spuren nehmen und sagen:
verschiebe diese um 1 ms, jene um 5 ms, usw.
Und DANN vergleichen![]()
Die Frage war, klingen alle DAWs gleich.
Ich wollte gern die Frage beantworten.
Die Antwort lautet: NEIN.
Die Frage war, klingen alle DAWs gleich.
Ich wollte gern die Frage beantworten.
Die Antwort lautet: NEIN.
Es liegt nicht Gain Staging, es liegt nicht am Panning.
Es liegt an den Delays der Spuren, wenn man welche einfuegt!
Wenn die DAW sauber arbeitet, muss die DAW interpolieren.
Das macht Reaper und deshalb hat Reaper die verschiedenen Qualitaetsstufen zur Wahl.
Zum Beispiel Sinc mit 256 Samples.
Wenn man also einen guten Test machen WILL, dann muss man Spuren nehmen und sagen:
verschiebe diese um 1 ms, jene um 5 ms, usw.
Und DANN vergleichen![]()
aber nur für den fall, wenn du files mit verschiedenen sample rates innerhalb eines projekts hast!ich habe frueher nicht verstanden, warum Reaper das anbietet, bis ich drauf gekommen bin, dass JEDE DAW interpolieren muss! Zwischensamples erzeugen, dann, wenn man die Spuren zeitlich verschiebt.
die latenz von VSTs fällt ja immer sample-quantisiert an. und delays werden halt einfach so verschoben, dass die verschiebung auch wieder ins sample-raster fällt. wozu kompliziert machen?Denn Du hast natürlich recht genau in dem Moment der Delays und vor allem auch der Delaykompensation machen sich die Schwächen von ITB Bearbeitungen häufig bemerkbar, weil in der Zeitebene beim Latenzausgleich nur endlich (Sample) genau gearbeitet werden kann und daher minimale zeitliche Unterschiede in der Korrelation der Signale zu einander entstehen.