Ich möchte einen Audio-Editor in C oder C ++ unter Windows und Linux implementieren. Ich kann nicht herausfinden, wie die Wellenform in der vollständig verkleinerten Ansicht schnell genug angezeigt werden kann. Ich suche keine Informationen über schnelle Bildpuffertechniken. Dies ist eine Frage zu Algorithmen und Datenstrukturen, um effizient zu bestimmen, was angezeigt werden soll.

Say Ich möchte einen 24-Bit-Sound mit 5 Kanälen und 48 kHz bearbeiten können, der 2 Stunden lang ist. Das sind 5 Gigabyte Beispieldaten. Ich möchte in der Lage sein, aus einem Pixel pro Sample herauszuzoomen, bis alle Sample-Daten gleichzeitig sichtbar sind. Ich möchte, dass die Anwendung auch auf einem langsamen Computer anspricht, z. B. einem Atom mit 1 GHz. Wenn ich responsive sage, möchte ich, dass die GUI-Aktualisierungen im Allgemeinen innerhalb von 1/30 Sekunde nach der Benutzereingabe erfolgen.

Bei einer naiven Implementierung wird jedes Sample in der gesamten Wellenform gescannt, wenn entschieden wird, was für die vollständig herausgezoomte Ansicht gerendert werden soll. Es müssen die maximalen und minimalen Sample-Werte für alle Samples ermittelt werden, die von jeder Pixelbreite der Anzeige "abgedeckt" werden. Ich habe eine einfache App geschrieben, um die Geschwindigkeit dieses Ansatzes zu testen. Ich habe mit meinem 2015er 3,5-GHz-Xeon ein einstündiges Mono-16-Bit-44,1-KHz-Sample getestet. Es dauert 0,12 Sekunden. Das ist hunderte Male zu langsam.

Sie können sich vorstellen, einen Cache mit herausgezoomten Daten beizubehalten, aber ich weiß nicht, wie Sie vermeiden können, dass Sie den gesamten Cache nach den meisten Einfügungen oder Löschvorgängen neu berechnen müssen. Es fühlt sich so an, als gäbe es einen besseren Weg.

Hier ist ein Diagramm, das zeigt, was ich erreichen möchte:

So funktioniert die Anzeige in den meisten derzeit verfügbaren Audio-Editoren. Benutzer erwarten dieses Verhalten wahrscheinlich. Ich habe es mit Audacity getestet und es funktioniert auf diese Weise (obwohl es auch den Mittelwert der Samples in einer helleren Farbe anzeigt). Es kann beliebige Einfügungen in große Sounds scheinbar sofort verarbeiten. Ich werde die 75 Megabyte Quellcode nicht lesen, um herauszufinden, wie es funktioniert.

BEARBEITEN

Verschiedene Personen haben Schemata vorgeschlagen, bei denen nur eine Teilmenge der Beispiele berücksichtigt wird, wenn die verkleinerte Ansicht angezeigt wird. Ich bin zu dem Schluss gekommen, dass ich das nicht tun möchte, weil es zu viele nützliche Informationen verliert. Das Einbeziehen aller Samples ist beispielsweise wichtig, wenn Sie nach einer Störung im Sound suchen, z. B. nach einem Klick in einer Vinylkonvertierung. Im schlimmsten Fall, wenn die Störung nur ein Sample lang ist, möchte ich dennoch die Garantie haben, dass sie in der vollständig herausgezoomten Ansicht angezeigt wird.