64bit Floating Point Signalfluss

[ModulationMatrix]

hast du wahrscheinlich ironisch gemeint, aber genau so ist es. kannste selber ausprobieren: nimm ein 16bit sample, jage es durch die daw im tollen 64bit setting und speichere es in derselben auflösung ab. das resultierende file ist grösser. dass die zusätzliche grösse durch lauter nutzlose stellen erzeugt wurde, ist dem file egal.

ironischerweise bringt das auch die sinnhaftigkeit (bzw mangel derselben) einer 64bit float mixing engine im vergleich zu einer 32bit float mixing engine ganz hübsch auf den punkt

diese Stellen sind ja allenfalls im ersten Moment sinnlos. Es sind zwei paar Schuhe eine Zahl nur darzustellen oder Hunderte und Tausende von Rechenoperationen auf X verschiedenen Zahlen zu machen um dann zu einem Ergebnis zu kommen. für die Rechnerei zahlen sich viele Stellen aus, für die Präsentation des Input und des Endergebnisses braucht man die nicht unbedingt.

 

[Nachtschicht]

hast du wahrscheinlich ironisch gemeint, aber genau so ist es. kannste selber ausprobieren: nimm ein 16bit sample, jage es durch die daw im tollen 64bit setting und speichere es in derselben auflösung ab. das resultierende file ist grösser. dass die zusätzliche grösse durch lauter nutzlose stellen erzeugt wurde, ist dem file egal.

ironischerweise bringt das auch die sinnhaftigkeit (bzw mangel derselben) einer 64bit float mixing engine im vergleich zu einer 32bit float mixing engine ganz hübsch auf den punkt

diese Stellen sind ja allenfalls im ersten Moment sinnlos. Es sind zwei paar Schuhe eine Zahl nur darzustellen oder Hunderte und Tausende von Rechenoperationen auf X verschiedenen Zahlen zu machen um dann zu einem Ergebnis zu kommen. für die Rechnerei zahlen sich viele Stellen aus, für die Präsentation des Input und des Endergebnisses braucht man die nicht unbedingt.

absolut. in dem moment wo mit dem 16bit file irgendeine berechnung durchgeführt wird (mal kurz den fader bisschen verstellt) hast du es mit einem waschechten 32 (oder whatever) bit file zu tun.
der punkt war nur der dass dem rechner die sinnhaftigkeit egal ist und er auch eine gänzlich unbearbeitete 16bit datei "vierfach aufgebläht" wie es hier genannt wurde speichern würde

 

[Sascha Franck]

@Nachtschicht, ich stelle mit Bedauern fest, dass du immer noch nicht gelesen hast, was ich geschrieben habe.

So ist es. Sie werden im 64 Bit Format im RAM abgelegt und in diesem Format in Berechnungen prozessiert.

Genau das ist ja der Sinn der Sache, denn wenn sie in 16 Bit auch bei Berechnungen verarbeitet würden würden schon merkliche Rundungsfehler entstehen, bei 64bit Berechnungen eben nicht.

So. Wir gehen das jetzt mal per Logik an, ok? Davon bin ich ein großer Freund.
Also, ihr beiden geht davon aus, dass die in welcher Bitrate auch immer aufgenommenen Files im vom Sequenzer benutzten Format im RAM abgelegt werden, korrekt?
Das ist ja per se schon mal ein dicker Hund, denn dann frage ich mich, wie ich bereits vor 15 Jahren auf meinem Rechner 100+ Stereo-Spuren abspielen konnte, wo der doch nur über 1GB RAM verfügte und davon ca. die Hälfte schon weg waren, wenn Windows und Logic gestartet waren. Aber gut, nehmen wir trotzdem an, ihr hättet Recht. Kann ja sein. Zauberei gibt's ja immer wieder. Waren ja auch *nur* 32bit Files, bei 100 Spuren kommt da ja fast nix zusammen... ähem. Aber wie gesagt, wir bleiben bei der Annahme, dass diese (quasi in Echtzeit?!?) konvertierten Files fein säuberlich im RAM liegen.

Ok, weiter im Kontext. 15 Jahre später, jetzt können wir zwischen 32 und 64 bit (double precision, wowee!) umschalten. Geht, zumindest in Logic Pro X, auch ohne Probleme.
Eurer Logik zufolge müssten die Files bei 32bit Betrieb auch in diesem Format im Speicher abgelegt sein. Seid ihr da mit mir? Prima!
Desweiteren müssten sie ja bei 64bit Betrieb in der höheren Auflösung im Speicher abgelegt sein. Immer noch bei mir? Perfekt!
Was hätte das zur Folge? Korrekt, einen *deutlich* höheren RAM-Bedarf. Ich denke, dass es da, zumindest nach eurer Denkart, absolut keine andere Möglichkeit gibt (aber ihr korrigiert mich, wenn ich falsch liege, ja? Danke!).


Gut, da ja @Nachtschicht in einem früheren Posting angemerkt hatte, ich hätte wohl keine Lust, selber diese einfachen Tests durchzuführen, habe ich - nur für euch - keine Kosten und Mühen gescheut und einen Testsong kreiert. In dem laufen 40 (echte, also auf der Festplatte vorliegende) Stereospuren in 24bit/44.1KHz, jede rund 5 Minuten lang, pro Spur grob 108MB, insgesamt etwas über 4GB. Ich denke, dass das den durchschnittlichen Bedarf an Spuren eigentlich eher übersteigt, wollte aber mal zeigen, was in punkto Spendierhosen so geht, im Hause Franck. Der RAM Bedarf sollte, wenn die Spuren erst einmal in 64bit umgewandelt sind, enorm sein, in 32bit aber auch schon ordentlich. Seltsam, dass das dann mit 1GB RAM auch schon ging...
Aber weiter im Kontext. Egal wie man es dreht und wendet, eurer brillianten These zur Folge müsste bei 64bit Betrieb der RAM Bedarf ja bedeutend höher sein, nicht wahr?
Fein, nun bietet dieses wunderbare Betriebssystem, welches ich zu nutzen pflege, ein kleines Tool namens "Aktivitätsanzeige". Die ist auch wirklich ziemlich akkurat. Da kann man sich dann u.a. auch den aktuellen Speicherbedarf einer Anwendung anzeigen lassen. Und halt auch den von Logic.
Ich habe mich also an die Arbeit gemacht. Logic starten,Testsong laden, Logic auf 32bit gestellt, Aktivitätsanzeige geöffnet, RAM Bedarf angeschaut. Logic auf 64bit umgeschaltet, sicherheitshalber neu gestartet, Song geladen, Aktivitätsanzeige laden, dann das Ganze noch ca. 10 Mal von vorne.
Jetzt würde ich mich wirklich sehr freuen, euch mitteilen zu dürfen, dass bei 64bit Betrieb der RAM Verbrauch heftig in die Höhe schnellt. Ich mein', ich überbringe lieber gute als schlechte Nachrichten.
Nur, liebe Leute, leider ist dem nicht so. Der RAM-Bedarf ist in beiden Betriebsmodi so gut wie identisch (bei dem Testsong liegt er ca. bei 270MB), mit Glück kommt man in den unerhörten Genuss, eine minimale Erhöhung des Bedarfs (um vielleicht 5-10MB) im 64bit Betrieb zu beobachten.
Um es auf den Punkt zu bringen: Damit ist eure ohnehin recht wilde Theorie, Audiofiles würden in irgendwelchen hochauflösenden Formaten irgendwo hingeladen werden, leider Gottes komplett den Bach runtergegangen! Das findet einfach nicht statt.

Oh, STOPP! Vielleicht machen das ja die Prozessoren in Echtzeit, oder? Das wäre doch eine hübsche Alternative (wenn schon kein anderer Strohhalm mehr bleibt). Machen die aber auch nicht, diese Schlingel! Jedenfalls zeigen weder Logics interner noch der OSX eigene CPU Monitor irgendeinen merklich erhöhten CPU-Bedarf.

Und last but not least: Auf der Festplatte ist ebensowenig etwas von höherer Aktivität im 64bit Modus festzustellen.

Was machen wir jetzt daraus? Vielleicht habt ihr ja noch ein paar weitere wilde Mutmaßungen auf Lager - die bisherigen sind, nunja, schlichtweg ins Reich der Mythen einzuordnen.

Anm.: Wenn ihr an all dem Zweifel habt, selber mal testen (nicht wahr, @Nachtschicht?)! Ich schieße sonst auch gerne ein kleines Video meines Prozederes, falls da noch Zweifel bleiben.

Ach ja: Ich hätte mir das an sich gerne gespart. Aber auch als Forenneuling ist es nicht wirklich superb, sich gleich mit Vorwürfen a la "Strawman" und "du hast ja keine Ahnung" konfrontiert zu sehen. Vor allem dann, wenn die Gegenseite ja außer Mutmaßungen nichts zu bieten hat. Es ist übrigens bedauerlich genug, dass es überhaupt eine Gegenseite gibt, an sich sollte man sich gegenseitig aushelfen, um den allgemeinen Informationsstandard so hoch wie möglich zu halten. Aber vielleicht ist's einfach geiler, mit Schlägen unter die Gürtellinie zu punkten.

Ich wünsche desungeachtet allen einen schönen Abend.

 

[synthpark]

@Nachtschicht, ich stelle mit Bedauern fest, dass du immer noch nicht gelesen hast, was ich geschrieben habe.

So ist es. Sie werden im 64 Bit Format im RAM abgelegt und in diesem Format in Berechnungen prozessiert.

Genau das ist ja der Sinn der Sache, denn wenn sie in 16 Bit auch bei Berechnungen verarbeitet würden würden schon merkliche Rundungsfehler entstehen, bei 64bit Berechnungen eben nicht.

So. Wir gehen das jetzt mal per Logik an, ok? Davon bin ich ein großer Freund.
Also, ihr beiden geht davon aus, dass die in welcher Bitrate auch immer aufgenommenen Files im vom Sequenzer benutzten Format im RAM abgelegt werden, korrekt?
Das ist ja per se schon mal ein dicker Hund, denn dann frage ich mich, wie ich bereits vor 15 Jahren auf meinem Rechner 100+ Stereo-Spuren abspielen konnte, wo der doch nur über 1GB RAM verfügte und davon ca. die Hälfte schon weg waren, wenn Windows und Logic gestartet waren. Aber gut, nehmen wir trotzdem an, ihr hättet Recht. Kann ja sein. Zauberei gibt's ja immer wieder. Waren ja auch *nur* 32bit Files, bei 100 Spuren kommt da ja fast nix zusammen... ähem. Aber wie gesagt, wir bleiben bei der Annahme, dass diese (quasi in Echtzeit?!?) konvertierten Files fein säuberlich im RAM liegen.

Ok, weiter im Kontext. 15 Jahre später, jetzt können wir zwischen 32 und 64 bit (double precision, wowee!) umschalten. Geht, zumindest in Logic Pro X, auch ohne Probleme.
Eurer Logik zufolge müssten die Files bei 32bit Betrieb auch in diesem Format im Speicher abgelegt sein. Seid ihr da mit mir? Prima!
Desweiteren müssten sie ja bei 64bit Betrieb in der höheren Auflösung im Speicher abgelegt sein. Immer noch bei mir? Perfekt!
Was hätte das zur Folge? Korrekt, einen *deutlich* höheren RAM-Bedarf. Ich denke, dass es da, zumindest nach eurer Denkart, absolut keine andere Möglichkeit gibt (aber ihr korrigiert mich, wenn ich falsch liege, ja? Danke!).


Gut, da ja @Nachtschicht in einem früheren Posting angemerkt hatte, ich hätte wohl keine Lust, selber diese einfachen Tests durchzuführen, habe ich - nur für euch - keine Kosten und Mühen gescheut und einen Testsong kreiert. In dem laufen 40 (echte, also auf der Festplatte vorliegende) Stereospuren in 24bit/44.1KHz, jede rund 5 Minuten lang, pro Spur grob 108MB, insgesamt etwas über 4GB. Ich denke, dass das den durchschnittlichen Bedarf an Spuren eigentlich eher übersteigt, wollte aber mal zeigen, was in punkto Spendierhosen so geht, im Hause Franck. Der RAM Bedarf sollte, wenn die Spuren erst einmal in 64bit umgewandelt sind, enorm sein, in 32bit aber auch schon ordentlich. Seltsam, dass das dann mit 1GB RAM auch schon ging...
Aber weiter im Kontext. Egal wie man es dreht und wendet, eurer brillianten These zur Folge müsste bei 64bit Betrieb der RAM Bedarf ja bedeutend höher sein, nicht wahr?
Fein, nun bietet dieses wunderbare Betriebssystem, welches ich zu nutzen pflege, ein kleines Tool namens "Aktivitätsanzeige". Die ist auch wirklich ziemlich akkurat. Da kann man sich dann u.a. auch den aktuellen Speicherbedarf einer Anwendung anzeigen lassen. Und halt auch den von Logic.
Ich habe mich also an die Arbeit gemacht. Logic starten,Testsong laden, Logic auf 32bit gestellt, Aktivitätsanzeige geöffnet, RAM Bedarf angeschaut. Logic auf 64bit umgeschaltet, sicherheitshalber neu gestartet, Song geladen, Aktivitätsanzeige laden, dann das Ganze noch ca. 10 Mal von vorne.
Jetzt würde ich mich wirklich sehr freuen, euch mitteilen zu dürfen, dass bei 64bit Betrieb der RAM Verbrauch heftig in die Höhe schnellt. Ich mein', ich überbringe lieber gute als schlechte Nachrichten.
Nur, liebe Leute, leider ist dem nicht so. Der RAM-Bedarf ist in beiden Betriebsmodi so gut wie identisch (bei dem Testsong liegt er ca. bei 270MB), mit Glück kommt man in den unerhörten Genuss, eine minimale Erhöhung des Bedarfs (um vielleicht 5-10MB) im 64bit Betrieb zu beobachten.
Um es auf den Punkt zu bringen: Damit ist eure ohnehin recht wilde Theorie, Audiofiles würden in irgendwelchen hochauflösenden Formaten irgendwo hingeladen werden, leider Gottes komplett den Bach runtergegangen! Das findet einfach nicht statt.

Oh, STOPP! Vielleicht machen das ja die Prozessoren in Echtzeit, oder? Das wäre doch eine hübsche Alternative (wenn schon kein anderer Strohhalm mehr bleibt). Machen die aber auch nicht, diese Schlingel! Jedenfalls zeigen weder Logics interner noch der OSX eigene CPU Monitor irgendeinen merklich erhöhten CPU-Bedarf.

Und last but not least: Auf der Festplatte ist ebensowenig etwas von höherer Aktivität im 64bit Modus festzustellen.

Was machen wir jetzt daraus? Vielleicht habt ihr ja noch ein paar weitere wilde Mutmaßungen auf Lager - die bisherigen sind, nunja, schlichtweg ins Reich der Mythen einzuordnen.

Anm.: Wenn ihr an all dem Zweifel habt, selber mal testen (nicht wahr, @Nachtschicht?)! Ich schieße sonst auch gerne ein kleines Video meines Prozederes, falls da noch Zweifel bleiben.

Ach ja: Ich hätte mir das an sich gerne gespart. Aber auch als Forenneuling ist es nicht wirklich superb, sich gleich mit Vorwürfen a la "Strawman" und "du hast ja keine Ahnung" konfrontiert zu sehen. Vor allem dann, wenn die Gegenseite ja außer Mutmaßungen nichts zu bieten hat. Es ist übrigens bedauerlich genug, dass es überhaupt eine Gegenseite gibt, an sich sollte man sich gegenseitig aushelfen, um den allgemeinen Informationsstandard so hoch wie möglich zu halten. Aber vielleicht ist's einfach geiler, mit Schlägen unter die Gürtellinie zu punkten.

Ich wünsche desungeachtet allen einen schönen Abend.

Ich bin kein großer Freund von Logik, aber aber warum sollen die Spuren vollständig im Ram abgelegt sein? Das sind doch immer nur kurze Abschnitte.

 

[Sascha Franck]

[
Ich bin kein großer Freund von Logik, aber aber warum sollen die Spuren vollständig im Ram abgelegt sein? Das sind doch immer nur kurze Abschnitte.

Frag das nicht mich, ich habe das nicht gesagt. Abgesehen davon wird da aber ohnehin nicht mehr im RAM abgelegt als ohnehin schon. Und die aufgenommenen Audiofiles werden de facto nicht in ein anderes Format gewandelt, andernfalls müsste man zwingend irgendwo einen höheren Resourcenbedarf feststellen, wenn man von 32bit zu 64bit umschaltet (RAM, CPU oder Festplatte).

Nach meinem Kenntnisstand werden, so wie du sagst, sowieso immer nur kleine Teile der Audiodatei in den RAM vorgeladen, der Rest kommt dann Stück für Stück von der Festplatte.
Und was da geladen wird, befindet sich im Format der Aufnahme, nicht in irgendwelchen höherwertigen Aggregatzuständen.

 

[synthpark]

[
Ich bin kein großer Freund von Logik, aber aber warum sollen die Spuren vollständig im Ram abgelegt sein? Das sind doch immer nur kurze Abschnitte.

Frag das nicht mich, ich habe das nicht gesagt. Abgesehen davon wird da aber ohnehin nicht mehr im RAM abgelegt als ohnehin schon. Und die aufgenommenen Audiofiles werden de facto nicht in ein anderes Format gewandelt, andernfalls müsste man zwingend irgendwo einen höheren Resourcenbedarf feststellen, wenn man von 32bit zu 64bit umschaltet (RAM, CPU oder Festplatte).

Nach meinem Kenntnisstand werden, so wie du sagst, sowieso immer nur kleine Teile der Audiodatei in den RAM vorgeladen, der Rest kommt dann Stück für Stück von der Festplatte.
Und was da geladen wird, befindet sich im Format der Aufnahme, nicht in irgendwelchen höherwertigen Aggregatzuständen.

Sobald es geladen wird, müsste es ins Arbeitsformat konvertiert werden, also 32 Bit oder eben 64 Bit. Einfach nur weil Plugins es auch so erwarten gemäß VST, aber auch weil 24 Bit ein Integer Format ist, da kann man keine Floating Point Arithmetik mit machen. Aber ob jetzt die Konvertierung erst beim Auslesen aus dem Ram oder schon vorher beim Einlesen gemacht wird, ist ja letztlich einerlei.

Die MPC Live zB lädt und hält sämtliche Samples in 32 Bit, weshalb einige User schon moniert haben.

 

[ModulationMatrix]

@Nachtschicht, ich stelle mit Bedauern fest, dass du immer noch nicht gelesen hast, was ich geschrieben habe.

So ist es. Sie werden im 64 Bit Format im RAM abgelegt und in diesem Format in Berechnungen prozessiert.

Genau das ist ja der Sinn der Sache, denn wenn sie in 16 Bit auch bei Berechnungen verarbeitet würden würden schon merkliche Rundungsfehler entstehen, bei 64bit Berechnungen eben nicht.

So. Wir gehen das jetzt mal per Logik an, ok? Davon bin ich ein großer Freund.
Also, ihr beiden geht davon aus, dass die in welcher Bitrate auch immer aufgenommenen Files im vom Sequenzer benutzten Format im RAM abgelegt werden, korrekt?
Das ist ja per se schon mal ein dicker Hund, denn dann frage ich mich, wie ich bereits vor 15 Jahren auf meinem Rechner 100+ Stereo-Spuren abspielen konnte, wo der doch nur über 1GB RAM verfügte und davon ca. die Hälfte schon weg waren, wenn Windows und Logic gestartet waren. Aber gut, nehmen wir trotzdem an, ihr hättet Recht. Kann ja sein. Zauberei gibt's ja immer wieder. Waren ja auch *nur* 32bit Files, bei 100 Spuren kommt da ja fast nix zusammen... ähem. Aber wie gesagt, wir bleiben bei der Annahme, dass diese (quasi in Echtzeit?!?) konvertierten Files fein säuberlich im RAM liegen.

Ok, weiter im Kontext. 15 Jahre später, jetzt können wir zwischen 32 und 64 bit (double precision, wowee!) umschalten. Geht, zumindest in Logic Pro X, auch ohne Probleme.
Eurer Logik zufolge müssten die Files bei 32bit Betrieb auch in diesem Format im Speicher abgelegt sein. Seid ihr da mit mir? Prima!
Desweiteren müssten sie ja bei 64bit Betrieb in der höheren Auflösung im Speicher abgelegt sein. Immer noch bei mir? Perfekt!
Was hätte das zur Folge? Korrekt, einen *deutlich* höheren RAM-Bedarf. Ich denke, dass es da, zumindest nach eurer Denkart, absolut keine andere Möglichkeit gibt (aber ihr korrigiert mich, wenn ich falsch liege, ja? Danke!).


Gut, da ja @Nachtschicht in einem früheren Posting angemerkt hatte, ich hätte wohl keine Lust, selber diese einfachen Tests durchzuführen, habe ich - nur für euch - keine Kosten und Mühen gescheut und einen Testsong kreiert. In dem laufen 40 (echte, also auf der Festplatte vorliegende) Stereospuren in 24bit/44.1KHz, jede rund 5 Minuten lang, pro Spur grob 108MB, insgesamt etwas über 4GB. Ich denke, dass das den durchschnittlichen Bedarf an Spuren eigentlich eher übersteigt, wollte aber mal zeigen, was in punkto Spendierhosen so geht, im Hause Franck. Der RAM Bedarf sollte, wenn die Spuren erst einmal in 64bit umgewandelt sind, enorm sein, in 32bit aber auch schon ordentlich. Seltsam, dass das dann mit 1GB RAM auch schon ging...
Aber weiter im Kontext. Egal wie man es dreht und wendet, eurer brillianten These zur Folge müsste bei 64bit Betrieb der RAM Bedarf ja bedeutend höher sein, nicht wahr?
Fein, nun bietet dieses wunderbare Betriebssystem, welches ich zu nutzen pflege, ein kleines Tool namens "Aktivitätsanzeige". Die ist auch wirklich ziemlich akkurat. Da kann man sich dann u.a. auch den aktuellen Speicherbedarf einer Anwendung anzeigen lassen. Und halt auch den von Logic.
Ich habe mich also an die Arbeit gemacht. Logic starten,Testsong laden, Logic auf 32bit gestellt, Aktivitätsanzeige geöffnet, RAM Bedarf angeschaut. Logic auf 64bit umgeschaltet, sicherheitshalber neu gestartet, Song geladen, Aktivitätsanzeige laden, dann das Ganze noch ca. 10 Mal von vorne.
Jetzt würde ich mich wirklich sehr freuen, euch mitteilen zu dürfen, dass bei 64bit Betrieb der RAM Verbrauch heftig in die Höhe schnellt. Ich mein', ich überbringe lieber gute als schlechte Nachrichten.
Nur, liebe Leute, leider ist dem nicht so. Der RAM-Bedarf ist in beiden Betriebsmodi so gut wie identisch (bei dem Testsong liegt er ca. bei 270MB), mit Glück kommt man in den unerhörten Genuss, eine minimale Erhöhung des Bedarfs (um vielleicht 5-10MB) im 64bit Betrieb zu beobachten.
Um es auf den Punkt zu bringen: Damit ist eure ohnehin recht wilde Theorie, Audiofiles würden in irgendwelchen hochauflösenden Formaten irgendwo hingeladen werden, leider Gottes komplett den Bach runtergegangen! Das findet einfach nicht statt.

Oh, STOPP! Vielleicht machen das ja die Prozessoren in Echtzeit, oder? Das wäre doch eine hübsche Alternative (wenn schon kein anderer Strohhalm mehr bleibt). Machen die aber auch nicht, diese Schlingel! Jedenfalls zeigen weder Logics interner noch der OSX eigene CPU Monitor irgendeinen merklich erhöhten CPU-Bedarf.

Und last but not least: Auf der Festplatte ist ebensowenig etwas von höherer Aktivität im 64bit Modus festzustellen.

Was machen wir jetzt daraus? Vielleicht habt ihr ja noch ein paar weitere wilde Mutmaßungen auf Lager - die bisherigen sind, nunja, schlichtweg ins Reich der Mythen einzuordnen.

Anm.: Wenn ihr an all dem Zweifel habt, selber mal testen (nicht wahr, @Nachtschicht?)! Ich schieße sonst auch gerne ein kleines Video meines Prozederes, falls da noch Zweifel bleiben.

Ach ja: Ich hätte mir das an sich gerne gespart. Aber auch als Forenneuling ist es nicht wirklich superb, sich gleich mit Vorwürfen a la "Strawman" und "du hast ja keine Ahnung" konfrontiert zu sehen. Vor allem dann, wenn die Gegenseite ja außer Mutmaßungen nichts zu bieten hat. Es ist übrigens bedauerlich genug, dass es überhaupt eine Gegenseite gibt, an sich sollte man sich gegenseitig aushelfen, um den allgemeinen Informationsstandard so hoch wie möglich zu halten. Aber vielleicht ist's einfach geiler, mit Schlägen unter die Gürtellinie zu punkten.

Ich wünsche desungeachtet allen einen schönen Abend.

Ich bin kein großer Freund von Logik, aber aber warum sollen die Spuren vollständig im Ram abgelegt sein? Das sind doch immer nur kurze Abschnitte.

von mir aus kann es auch on-the-fly konvertiert werden, Buffer für Buffer, das ändert doch nichts.

 

[Sascha Franck]

von mir aus kann es auch on-the-fly konvertiert werden, Buffer für Buffer, das ändert doch nichts.

Da wird nichts konvertiert, Punkt.
Ansonsten würde die CPU-Last merklich in die Höhe gehen, wenn man von 32 auf 64 bit umschaltet. Tut sie aber nicht.

 

[synthpark]

von mir aus kann es auch on-the-fly konvertiert werden, Buffer für Buffer, das ändert doch nichts.

Da wird nichts konvertiert, Punkt.
Ansonsten würde die CPU-Last merklich in die Höhe gehen, wenn man von 32 auf 64 bit umschaltet. Tut sie aber nicht.

Diese Konvertierung macht doch keinen wesentlichen Anteil an der CPU Last, das sind doch elementare Befehle, mehr oder weniger. Aber ich weiss jetzt nicht mehr, um was es bei der Diskussion eigentlich geht oder ging ...

 

[Ran]

Der Ram ist mit der CPU verbunden, die Festplatte aber nicht direkt. Die geht erst den Umweg über das Mainboard durch den Ram in die CPU.

 

[Sascha Franck]

Diese Konvertierung macht doch keinen wesentlichen Anteil an der CPU Last, das sind doch elementare Befehle, mehr oder weniger. Aber ich weiss jetzt nicht mehr, um was es bei der Diskussion eigentlich geht oder ging ...

Also, ich bin zwar kein Programmierer, aber Audiofiles zu konvertieren kostet entweder Zeit oder, vor allem, wenn es schnell geschehen muss, Rechenleistung. Nichts dergleichen ist festzustellen, wenn ich Logic von 32 auf 64 umstelle. Alles läuft exakt wie vorher, die Aktivitätsanzeige zeigt ebenfalls nichts anderes.

 

[suboptional]

Da wird nichts konvertiert, Punkt.
Ansonsten würde die CPU-Last merklich in die Höhe gehen, wenn man von 32 auf 64 bit umschaltet. Tut sie aber nicht.

Die Daten der Audiofiles werden aber schon in Flieskomma konvertiert, sonst wären sie nicht VST-kompatibel, wie @synthpark das sagt.

Hier, sobald ich am Trackfader schraube (die Audio-Engine ins Spiel kommt), kommt hinten von meinem 16 bit Audiofile 64 bit (float) raus.

 

[Sascha Franck]

Die Daten der Audiofiles werden aber schon in Flieskomma konvertiert, sonst wären sie nicht VST-kompatibel, wie @synthpark das sagt.

Hier, sobald im am Trackfader schraube (die Audio-Engine ins Spiel kommt), kommt hinten von meinem 16 bit Audiofile 64 bit (float) raus.

Das kann ja alles sein - also, dass der Signalfluss intern mit einer höheren Auflösung stattfindet. Aber die eigentlichen Audiodaten erfahren keine Konvertierung, ansonsten müssten sie auch irgendwo so vorliegen, was nicht der Fall zu sein scheint. Und Leistung kostet die Geschichte ebenfalls nicht (was ja auch bereits behauptet wurde).

 

[Nachtschicht]

Also, ihr beiden geht davon aus, dass die in welcher Bitrate auch immer aufgenommenen Files im vom Sequenzer benutzten Format im RAM abgelegt werden, korrekt?

wie du inzwischen selber gemerkt hast: nein. audiodateien streamen von festplatte. es gibt die funktion in manchen daws, audio absichtlich komplett ins ram zu laden, falls die festplatte einen flaschenhals darstellt. protools z.b. konnte bzw kann das. logic hat ein solches setting meiner erinnerung nach nicht, ist aber ne ganze weile her dass ich logic benutzt habe. aber ist heutzutage im zeitalter von SSDs auch vollkommen wurscht, die langweilen sich nämlich selbst bei hohen trackcounts und spielen nebenher heimlich spider solitaire

Das ist ja per se schon mal ein dicker Hund, denn dann frage ich mich, wie ich bereits vor 15 Jahren auf meinem Rechner 100+ Stereo-Spuren abspielen konnte, wo der doch nur über 1GB RAM verfügte und davon ca. die Hälfte schon weg waren, wenn Windows und Logic gestartet waren.

da die audiodateien nur gestreamt werden, ist es auch kein dicker hund

Aber gut, nehmen wir trotzdem an, ihr hättet Recht. Kann ja sein. Zauberei gibt's ja immer wieder. Waren ja auch *nur* 32bit Files, bei 100 Spuren kommt da ja fast nix zusammen... ähem. Aber wie gesagt, wir bleiben bei der Annahme, dass diese (quasi in Echtzeit?!?) konvertierten Files fein säuberlich im RAM liegen.

da die grundannahme deines szenarios falsch war, ist diese "zauberei gibts ja immer wieder"-polemik bisschen unfreiwillig albern...

Ok, weiter im Kontext. 15 Jahre später, jetzt können wir zwischen 32 und 64 bit (double precision, wowee!) umschalten. Geht, zumindest in Logic Pro X, auch ohne Probleme.
Eurer Logik zufolge müssten die Files bei 32bit Betrieb auch in diesem Format im Speicher abgelegt sein. Seid ihr da mit mir? Prima!

...sind wir nicht mit dir, also nicht "prima!"...

Desweiteren müssten sie ja bei 64bit Betrieb in der höheren Auflösung im Speicher abgelegt sein. Immer noch bei mir? Perfekt!

...immer noch nicht mit dir, also auch nicht "perfekt!"...

Was hätte das zur Folge? Korrekt, einen *deutlich* höheren RAM-Bedarf. Ich denke, dass es da, zumindest nach eurer Denkart, absolut keine andere Möglichkeit gibt (aber ihr korrigiert mich, wenn ich falsch liege, ja? Danke!).

wir dir inzwischen mitgeteilt und auch dir selbst aufgefallen ist, ist der bedarf nicht "deutlich" höher sondern nur unmerklich, da eben im regelfall daws *nicht* sämtliche audiofiles komplett von vorne bis hinten ins ram laden.

Gut, da ja @Nachtschicht in einem früheren Posting angemerkt hatte, ich hätte wohl keine Lust, selber diese einfachen Tests durchzuführen, habe ich - nur für euch - keine Kosten und Mühen gescheut und einen Testsong kreiert.

ich bin mir jetzt nicht ganz sicher, ob du nun absichtlich oder versehentlich meinen testvorschlag auf deine fehlgeleitete "alle spuren landen komplett im ram"-theorie uminterpretiert hast. auf jeden fall ist der test sozusagen ein weiterer strohmann, weil du schon wieder etwas widerlegst, was ich nicht behauptet habe. aber lassen wirs gerne einfach als missverständnis stehen. mein tatsächlicher testvorschlag war ein ganz anderer, nämlich mal die rundungsfehler von 32bit float selber auszuprobieren. diesen test empfehle ich weiterhin. testmethode siehe in der ungefähr vorvorigen post

Aber weiter im Kontext. Egal wie man es dreht und wendet, eurer brillianten These zur Folge müsste bei 64bit Betrieb der RAM Bedarf ja bedeutend höher sein, nicht wahr?

auch süffisantes wie "eure brilliante these" ist jetzt natürlich bisschen unfreiwillig albern...

Um es auf den Punkt zu bringen: Damit ist eure ohnehin recht wilde Theorie, Audiofiles würden in irgendwelchen hochauflösenden Formaten irgendwo hingeladen werden, leider Gottes komplett den Bach runtergegangen! Das findet einfach nicht statt.

...jo, herzlichen glückwunsch zum erlegen eines weiteren bösartigen strohmanns.

Oh, STOPP! Vielleicht machen das ja die Prozessoren in Echtzeit, oder? Das wäre doch eine hübsche Alternative (wenn schon kein anderer Strohhalm mehr bleibt). Machen die aber auch nicht, diese Schlingel! Jedenfalls zeigen weder Logics interner noch der OSX eigene CPU Monitor irgendeinen merklich erhöhten CPU-Bedarf.

das ist für eine heutige CPU ja auch vollkommen pillepalle. heutige CPUs bleiben noch im schnarchmodus, wenn du 100 renaissance compressoren lädst, und so ein renaissance compressor ist im vergleich zur übersetzung einer 16bit datei in 32 oder 64bit float ja richtig doll kompliziertes DSP. da ist die übersetzung von 100 audiostreams ein kinderfasching dagegen (zumal du zwangsläufig nur die übersetzung in 32bit float vs übersetzung in 64bit float vergleichen kannst). kurz: das alles kratzt deine CPU in keiner nennenswerten weise, und das ist ja auch sehr schön so.

Und last but not least: Auf der Festplatte ist ebensowenig etwas von höherer Aktivität im 64bit Modus festzustellen.

natürlich nicht, denn von der festplatte wird im theoretischen szenario "ich bearbeite 16bit audiostreams in einem 32- oder 64bit mixer" ja weiterhin nur das 16bit file geladen, und erst danach in der CPU übersetzt. für höheren festplattenbedarf müsstest du die files im vorfeld konvertieren und dann in 64bit von festplatte streamen.

Was machen wir jetzt daraus? Vielleicht habt ihr ja noch ein paar weitere wilde Mutmaßungen auf Lager - die bisherigen sind, nunja, schlichtweg ins Reich der Mythen einzuordnen.

ins reich der mythen gehörte bei dieser post nur die grundannahme, dass daws audiofiles komplett von vorne bis hinten ins ram laden.

Anm.: Wenn ihr an all dem Zweifel habt, selber mal testen (nicht wahr, @Nachtschicht?)! Ich schieße sonst auch gerne ein kleines Video meines Prozederes, falls da noch Zweifel bleiben.

da das alles auf einer fehlannahme basierte, lohnt sich weder eine wiederholung solcher tests für mich, noch eine videoreproduktion dieses sinnlosen tests für dich. bei meiner empfehlung an dich, mal die praxisrelevanz von rundungsfehlern in 32bit float zu testen, bleibe ich allerdings. ich habe solche tests vor langer zeit schon gemacht. deswegen beeindruckt mich das ganze 64bit-PR-gelaber auch nicht. ich bin nicht das US-militär und habe insofern zumindest mittelfristig nicht vor, mich mit lebensgefährlichen pegelsprüngen zu beschäftigen

Ach ja: Ich hätte mir das an sich gerne gespart. Aber auch als Forenneuling ist es nicht wirklich superb, sich gleich mit Vorwürfen a la "Strawman" und "du hast ja keine Ahnung" konfrontiert zu sehen.

ja, diese runde hätten wir uns jetzt wirklich ersparen können. ich verstehe auch, dass der hinweis auf das strohmannargument dich provoziert und das hätte ich sicherlich höflicher formulieren können - dafür pardon. aber ein strohmannargument ist halt nunmal ein strohmannargument. wir reden hier über sinn und unsinn von 64bit auflösung und du kommst mit wehenden fahnen an und belehrst uns über ein angebliches missverständnis, dem wir nicht aufgesessen sind - das ist nunmal ein strohmann.

und um den elefanten im raum nochmal anzusprechen: so, wie du ständig von einem fundamentalen unterschied zwischen rechentiefe im mixer und bittiefe im audiofile sprichst, muss man halt einfach annehmen, dass du dich nicht so wirklich gut damit auskennst. ich entschuldige mich gerne für meinen tonfall, aber ich weiss erstens nicht genau, wie ich das jetzt netter ausdrücken sollte, und fühlte mich zweitens ehrlich gesagt ob des tonfalls dieser diskussion auch nur so mittelinspiriert dazu.

aber betrachte das mal als handreichung. lass mal probieren, den tonfall bisschen runterzufahren, ok?
sollten wir doch hinkriegen.

Vor allem dann, wenn die Gegenseite ja außer Mutmaßungen nichts zu bieten hat. Es ist übrigens bedauerlich genug, dass es überhaupt eine Gegenseite gibt, an sich sollte man sich gegenseitig aushelfen, um den allgemeinen Informationsstandard so hoch wie möglich zu halten.

ich versichere dir, dass du es hier nicht mit mutmassungen zu tun hast, und es tatsächlich um "informationsstandard" geht. dass eine daw nicht audiofiles komplett ins ram lädt, das hast du jetzt ja selber erkannt. dass daws einen audiostream in echtzeit in die höhere auflösung des mixers konvertieren, hat man dir jetzt ja ebenfalls demonstriert (danke @suboptional für das hart auf den punkt gebrachte video ). dass die rechentiefe des mixers und die bittiefe eines audiofiles nicht sowas fundamental unterschiedliches ist wie du anzunehmen scheinst, kriegt dir vielleicht auch noch jemand besser als ich erklärt, und wie gesagt, ich lege dir wirklich ans herz, mal den praxistest zur relevanz von rundungsfehlern in 32bit float im echten leben zu machen. überhaupt nicht aus polemik oder als "schlag unter der gürtellinie". was hab ich denn davon. einfach nur, um dir zu zeigen wie weit dieses rundungsfehler-rechenbeispiel aus dem von dir verlinkten video von jeglichen realitäten im tontechnischen alltag entfernt ist. mehr nicht. denn das ist, wie du selber sagst, ja letztlich eine gute nachricht

Ich wünsche desungeachtet allen einen schönen Abend.

gleichfalls.

 

[Signalschwarz]

Als der Thread zunächst keine Aufmerksamkeit erfahren hatte, hatte ich ihn ja mal angestupst, weil ich mir dachte, dass es hier gut abgehen würde. Das Ergebnis, also was jetzt hier abläuft ist allerdings noch schlimmer und trauriger als ich erwartet habe.

 

[ModulationMatrix]

Das kann ja alles sein - also, dass der Signalfluss intern mit einer höheren Auflösung stattfindet. Aber die eigentlichen Audiodaten erfahren keine Konvertierung, ansonsten müssten sie auch irgendwo so vorliegen, was nicht der Fall zu sein scheint. Und Leistung kostet die Geschichte ebenfalls nicht (was ja auch bereits behauptet wurde).

Lies dir doch mal deinen eigenen Post durch wie widersprüchlich der ist. der Signal Fluss findet irgendwie in 64-bit statt aber die 16 bit Daten werden auf keinen Fall konvertiert - wie soll das gehen? 16-Bit Daten bleiben so wie sie sind und werden mit 64-bit prozessiert ? Äh ja.

natürlich erfahren die eigentlichen Audiodaten eine Konvertierung, anders geht es doch gar nicht. mag sein dass sie weder auf der Platte noch komplett im RAM konvertiert werden, sondern immer nur der jeweilige Buffer von 128 Bytes oder whatever. konvertiert wird aber, muss ja zwingend.

ich habe gerade das Gefühl du willst argumentieren es werde mit double precision gerechnet ohne double precision zu benutzen.

oder du willst argumentieren wenn man nicht das ganze file konvertiert sondern nur Schnipselweise, dann ist es gar keine Konvertierung mehr.

Beides wäre ne ziemlich schräge Auffassung.

 

[Sascha Franck]

Bin ma raus hier. Diese Selbstgefälligkeit ist ja widerwärtig.

 

[ModulationMatrix]

Ist echt gruselig dass eine Diskussio trotz Fakten so enden kann dass jemand nicht an die Fakten glaubt.
Wenn du im Programmiercode eine Variable als Double definierst dann wird sie 64 Bit speicher benötigten. Wenn du einen 16-Bit Wert von Platte liest und in diese double variable ablegst, dann wird entweder vom Compiler automatisch für die Konvertierung gesorgt, oder du musst es per Prozedur explizit tun. aber die Konvertierung ist Fakt, unumgänglich. Frag jeden Informatiker auf der Welt: wenn du 16 Bit Audiodaten mit 64 Bit prozessiert werden sie an irgendeiner Stelle konvertiert.

 

[Nachtschicht]

projektion. je nun, was solls.

 

[Froschkapitaen]

Das Ergebnis, also was jetzt hier abläuft ist allerdings noch schlimmer und trauriger als ich erwartet habe.

Wenn du heute noch nicht gelogen hast....