Eine Funktion, die mir ebenfalls sehr am Herzen liegt ist der Audio-Analyzer. In der täglichen Übepraxis (vor allem im Duo) habe ich bereits vor Monaten den Wunsch nach einem zuverlässigen Tool zum Aufnehmen und Analysieren der Stücke verspürt. Bisher musste ich immer auf das Diktiergerät des Handys ausweichen, welches leider nicht sehr geeignet ist.

Daher habe ich mich an die Konzeptionierung eines Audio Recorder / Analyzers gemacht. Das Tool besteht aus drei Komponenten:

  • Audio Recorder (Aufnahme des Stücks)
  • Audio Liste (Verzeichnis der Aufnahmen)
  • Audio Analyzer (Wiedergabe und Analyse der Aufnahmen)

Bevor ich mit der Programmierung der ersten Komponente (Audio Recorder) anfing, habe ich einen Versuch gestartet, der alle drei Teile des Tools abdeckt. Für die Audio-Wiedergabe nutze ich das Nativescript-Audio Plugin. Mithilfe des Plugin-Demo-Codes habe ich nach der Installation des Plugins alle wichtigen Funktionen (Aufnahme, Wiedergabe etc.) erfolgreich testen können. Dem Audio Recorder / Analyzer Tool stand nichts mehr im Wege. Fast nicht… Denn wie beim Übezeit-Diagramm kann Nativescript keine Audio-Bars oder Ähnliches darstellen. Auch hier gäbe es ein Plugin, jedoch nur für iOS.

Audio Recorder

Den Audio Recorder hätte ich an den Übezeit-Tracker anlehnen können: Start-Button zur Aufnahme, Timer, Stopp-Button… Ich habe mich aus zwei Gründen dagegen entschieden:

  • Der Übezeit-Tracker und Audio-Recorder sollen namentlich, Layout-technisch und funktionell möglichst gegensätzlich aufgebaut werden. Bereits bei der Namensgebung bestand Verwechslungsgefahr: Piece-Recorder & Audio-Recorder. Um die Funktionen besser auseinandernhalten zu können entschied ich mich im Laufe der Entwicklung daher für Übezeit-Tracker und Audio-Recorder. Dementsprechend gegensätzlich versuche ich auch die Komponenten an sich aufzubauen.
  • Die App soll interessant sein, man soll sie gerne benutzten. Um dieses Gefühl zu stärken setzte ich beim Audio Recorder daher auf Interaktion: Ich möchte die Audio-Lautstärke in Form von Audio-Bars in Echtzeit darstellen. Klingt kompliziert, ist mit dem Plugin und der Erfahrung aus dem Bau der Übezeit-Statistik-Komponente aber realisierbar.

Um den Echtzeit-Audiometer (Audio-Bars) zu realisieren nutze ich die getMeters() Methode des Plugins. Jede 500ms wird der aktuelle Audiopegel ausgemessen und in einen Array gepusht. Gleichzeitig aktualisiert sich die ListView welche einen Balken generiert. Die Breite des Balkens (Audio-Bar) entspricht dem aktuellen Audiopegels des Arrays. Ich wende somit eine ähnliche Methode, wie beim Diagramm (Übezeit-Statistik) an, nur dass der maximale Wert immer fest bei 32’767 liegt (Nebenbei: Wieso diese Zahl als Maximalwert? Das liegt an der Architektur der Variable. Mehr dazu hier).

Nachdem die Audiodatei aufgenommen wurde kann der Nutzer seine Aufnahme beschriften und einen Aufnahme-Typen wählen: „Practice“ oder „Concert“. Ich biete diese Unterscheidung bereits jetzt an, da Apphoven in (mehr oder weniger ferner) Zukunft ausgewählte Aufnahmen zu Stücken öffentlich für andere User zugänglich machen wird. Da ich als User aber auch die Möglichkeit haben möchte nur Teile eines Stücks aufzunehmen und zu analysieren (evtl. später mit dem Klavierlehrer zu besprechen) ist nicht jede Aufnahme für eine Veröffentlichung geeignet.

Ausserdem sollen Aufnahmen in Zukunft gefiltert werden können (z.B. „Nur Practice-Aufnahmen“, „Nur Concert-Aufnahmen“). Um solche Funktionen in Zukunft jederzeit aktivieren zu können, bedarf es einer schnellstmöglichen Implementierung. Es wäre schade, wenn Nutzer bereits viel Audiomaterial aufgenommen haben und zum Release der neuen Funktionen alle Aufnahmen zur Selektierung erneut durchgehen müssten. Daher bereits jetzt die „Practice / Concert“-Unterscheidung. Standardmässig eingestellt ist der „Practice“-Typ.

Anschliessend kann der Nutzer die Aufnahme mit einem seiner Stücke aus der Übeliste verknüpfen. Ein äusserst einfach und schnell zu bedienendes Wählrad macht diesen Vorgang in UX-Hinsicht sehr angenehm. Die Aufnahme kann nun gespeichert werden.

Audio Liste

Die Audio Liste ist das Verzeichnis aller Audio Aufnahmen. Interessant ist hierbei die Namengebung. Einer der Leitsätze, der sich über die Entwicklung dieser App zieht ist unteranderem: „Jeder soll Apphoven nutzen, wie er will“. Daher erlaube ich beim Speichervorgang einer Aufnahme (Audio Recorder) das Feld „Aufnahme-Titel“ freizulassen. Nutzer, die wenig Zeit haben oder einen eigenen Titel zum Wiederfinden der Aufnahme nicht benötigen kommen auf Ihre Kosten: Ist kein eigener Titel definiert wird der Stück-Name (Kombination aus Satz- und Werktitel) angezeigt. In Kombination mit der Datumsangabe darunter lässt sich die Aufnahme somit auch ohne benutzerdefinierten Titel wiederfinden.

Über das Zahnrad der Listeneinträge lässt sich die jeweilige Aufnahme löschen. Hierbei werden zum einen die Metadaten von Firebase und die Audio-Datei an sich vom Gerät gelöscht.

Audio Analyzer

Mindestens genauso cool wie das Diagramm der Übezeit-Statistik ist der Analyzer! Er gefällt mir sehr gut: Einfache Bedienung und interaktive Marker machen echt Spass die App zu nutzen!

Um auch hier wieder die Audio-Meter-Line (Audio-Bars) darstellen zu können, verwende ich die Daten aus dem Audio-Recorder Array, welcher in Firebase abgespeichert wird. Nur über diesen Umweg ist es mir derzeit möglich die Audio-Meter-Line darzustellen, da der Audio-Player keine Funktion zur Audio-Meter-Ausgabe besitzt.

Die gesamte Player-UI an sich wurde komplett von mir selbst programmiert, da es keine Unterstützung von Nativescript und keine Plugins für Android dafür gibt. Die Audio-Bars sind wieder Balken, die Zeitleiste ein einfacher Slider, den ich jede Sekunde update. Interessant am Slider: Der maximale Wert entspricht der Länge der Audio-Datei (Aufnahme). Die Länge der Audio-Datei kann bei der Initialisierung per Plugin ausgelesen werden.

Analyzer Funktion 1

Auch das Vor- und Zurückspulen der Audiodatei (ohne zwischendurch pausieren zu müssen) ist gar nicht so einfach zu realisieren gewesen. Der Sliderwert ist an ein Two-Way-Databinding gekoppelt. Das bedeutet, dass der Slider zum einen Werte empfängt (jede Sekunde erhöht sich der Sliderwert um 1000ms). Andererseits sendet der Slider Werte (wenn der User den Slider bewegt: Vor- und Zurückspulen). Da es sich hierbei um die selbe Sliderwert-Variable handelt kam es zu einem Problem: Jede Sekunde würde das Abspielen der Aufnahme kurz zurückgesetzt werden, da das Vorrücken um 1000ms auf dem Slider gleichzeitig ein Setzten auf die vorgerückte Zeit bedeutet. Diese kurzen Aussetzer sind jedoch unangenehm hörbar.

Daher programmierte ich einen Mechanismus, welcher zwar jede Sekunde den Sliderwert um 1000ms erhöht, beim Vor- und Zurückspulen des Sliders jedoch eine Bestätigungs-Eingabe verlangt. Tatsächlich wird der User gar nicht merken, dass er sein Vor- und Zurückspulen bestätigen muss: Die Audio-Wiedergabe wird nur Vor- oder Zurückgespult, wenn die App zwei dieser Spul-Anfragen innert 200ms erhält. Dies trifft in so gut wie allen Fällen zu, da der Slider nicht getippt, sondern gezogen wird. Dabei werden innert weniger Millisekunden mehrere Anfragen zum Vor- oder Zurückspulen gesendet und der Bestätigungs-Mechanismus greift.

Nun zur Funktion der Komponente, die ihren Namen „Analyzer“ rechtfertigt. Während dem Abspielen der Datei (oder durch Vor- und Zurückspulen) kann durch das Antippen der Pinn-Nadel ein Marker gesetzt werden (Siehe App-Demo-Walkthrough: Analyzer Funktion 1).

Folgendes Szenario:
Ich habe aufgenommen, wie ich ein frisch gelerntes Stück durchspiele. Als ich mir die Aufnahme im Analyzer anhöre, merke ich, dass ich an einer Stelle plötzlich unbewusst schneller gespielt habe als gewollt. Durch das Tippen auf die Pinn-Nadel erstelle ich einen Marker mit dem Text „Nicht zu schnell“. Dieser Marker wird der aktuellen Sekunde der Player-Zeitleiste zugewiesen. Wenn ich das nächste Mal übe, kann ich mir im Analyzer ansehen, wo noch Problemstellen vorhanden sind. Dieses Markier-Funktion eignet sich auch für den Klavierunterricht, wenn man nach dem Durchspielen eines Stücks gewisse Stellen markieren möchte, die Zuhause beim Üben ausgebügelt werden sollen.

Das schöne an den Markern ist nicht nur die einfache Bedienung (Hinzufügen / Löschen), auch das Aufblicken der Marker zur richtigen Zeit ist eine tolle Funktion. Erreicht man in der Audio-Wiedergabe die Stelle eines Markers blinkt dieser rot auf. Durch diese Signalisierung wird dem Nutzer klar: „An dieser Stelle hast du etwas markiert“ (Siehe App-Demo-Walkthrough: Analyzer Funktion 2).

Analyzer Funktion 2

Ich denke, dass der Audio-Analyzer noch viel Potential für künftige Updates hat. In Zukunft soll es möglich sein Recordings mit anderen Apphoven-Nutzern zu teilen. Diese sollen Markierungen einsehen und weitere selbst erstellen können, um dadurch gegenseitig Tipps zu geben oder Lob auszusprechen. Auch eine Integration in den Klavierunterricht und in die Übepraxis wäre bestens möglich.

Für die Ferne Zukunft bieten auch Funktionen wie die „Beat-Detection“ interessante Möglichkeiten. Es wäre möglich Aufnahmen auf einen Beat hin zu analysieren und Temposchwankungen in der Audio-Meter-Line grafisch darzustellen. Eine Java-Bibliothek zur Beat-Detection wird bereits von der Universität Ghent angeboten. Die Implementierung in Android, speziell Nativescript ist hingegen ein grosses Unterfangen für sich. Dennoch wäre es die Mühe wert!