Klingen alle DAWs gleich?

[Akai31]

in was für einem format exportieren wir eigentlich? 32bit fixed?

24bit PCM

Kannst du mein Problem mit reaper mal überprüfen?

Bzw. mir ne Antwort geben zu dem Levelproblem? Wäre nett.

 

[Akai31]

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...

 

[karumba]

Kannst du mein Problem mit reaper mal überprüfen?

Bzw. mir ne Antwort geben zu dem Levelproblem? Wäre nett.

ich habe nicht genau verstanden was du gemacht hast. pegel, panlaw, dithering usw. hast du schon überprüft?

Ich denke alles was ein nicht-100%iges nullen auslöst sind interne Gainstagingprobleme

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).

also ungenaue Werteangaben oder von rechenfehlern?

rechenfehler beim summieren zweier vektoren? unwahrscheinlich. bei ungenauen werteangaben könnte ich mir folgendes vorstellen:
der fader zeigt nur 2 nachkommastellen an, z.b. 1.23dB, in wirklichkeit sind es aber 1.23231241.... dB, da der faderweg "ge-smoothed" wird & der fader-wert quasi auf 2 stellen gerundet anzeigt. fänd ich zwar eine etwas seltsame designentscheidung, ist aber dann letztlich auch kein rechenfehler. bei voxengoplugins werden auch nur 2 nachkommastellen angezeigt, wenn man mit STRG+mausrad dreht, ändert sich manchmal der wert nicht, aber es tut sich klanglich was (in extremfällen, wenn man z.b. differenzsignale anhört).

 

[BasstianvH]

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...

PT ist übrigens noch schlimmer, wenn ich da im Clip 6 db runtergehe und dann im Fader 6 db wieder rauf, bekomme ich nen Fehler von fast -45 db.

 

[BasstianvH]

Ab jetzt wird es spannend, der Fehler passiert nur, wenn ich den SAM Bounce von Akai nehme.

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?

 

[Akai31]

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.

 

[karumba]

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.

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.

 

[Akai31]

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?

Interessant. Bei mir lässt sich das auch mit SAM vs SAM reproduzieren.
Bei reaper vs reaper liegt die Differenz bei -110dB.
bei pt vs pt bei 100dB

Unter SAM nullt sich PT vs PT nur bis 110dB.

 

[Akai31]

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.

nein.
ich hab die files alle gebounced und dann in ein neues projekt geladen.

 

[synthpark]

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.

danke!

 

[BasstianvH]

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.

Und auch bei PT Files funktioniert das nur ein einziges Mal. Clip auf -6 Fader auf +6 nullt, aber wenn ich dann bei wieder zurück schiebe nullt es nicht mehr und auch der RMS Pegel ist dann unterschiedlich. PT schien also auf Clipebene irgendwas zu runden.

 

[synthpark]

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.

Verschieben heisst ja nicht verschieben um ganzzahlige Samples! Das reicht nicht.

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

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.

 

[karumba]

Da sich in PT der Panausgleich nicht abstellen lässt, werden alle Monosignal automatisch um 3 db angepasst.

ist das panlaw eigentlich exakt 3.0000dB oder faktor 2 im sinne von 10*log10(2) = 3.0103dB?

 

[Akai31]

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.

bei reaper und SAM nullt es dann wenn ich alle objekte und fader wieder auf 0 stelle, perfekt...

 

[karumba]

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

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.

//edit: achso, du meinst nicht sample-genaues verschieben. das ist praxisfremd - wer braucht das schon in einer DAW

 

[synthpark]

Ich hab meinen Text noch modifiziert, ganzzahlig verschieben reicht doch nicht. Das gibt immer noch Phasenprobleme im HF Bereich. Eine gute DAW muss mehr koennen, so wie Reaper.

Das ist doch nicht praxisfremd! Wenn ich Drumaufnahmen verschieben will, um phasen zu matchen, dann will ich genau 1 ms verschieben, und nicht 1.0034 ms oder so!

Verschieb mal einen Kanal einer Stereoaufnahme um ein Sample. Dein HF Bereich geht floeten. Manchmal musst du um 0.5 Samples verschieben.

 

[RefinedRough]

Die Frage war, klingen alle DAWs gleich.

Ich wollte gern die Frage beantworten.

Die Antwort lautet: NEIN.

Nun ja, egal was da noch fürn technischer Bimbam (was mein Intellekt eh übersteigt) passiert, klingen sie doch alle gleich, oder gibt es Menschen, die sowas hören? Wohl kaum

 

[BasstianvH]

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

Das ist übrigens ein sehr sehr guter Einwand. Die Frage hätte entsprechend lauten müssen: Summieren alle DAWs gleich? 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.

 

[karumba]

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.

aber nur für den fall, wenn du files mit verschiedenen sample rates innerhalb eines projekts hast!

 

[karumba]

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.

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?