Epic: Integration des Mitschnittes
Einleitung
Wir möchten den Mitschnitt und die LOHROthek weiter verzahnen um zunehmend automatisiert Mitschnitte des laufenden Programmes für die Redakteur:innen vorzubereiten. Es soll zunächst eine Lösung gefunden werden, welche die minimale Funktionalität erfüllt aber bereits bekannte Erweiterungsmöglichkeiten strukturell vorsieht.
Bestandsaufnahme - Wie kommen aktuell Mitschnitte des laufenden Programmes in die LOHROthek?
Der Prozess ist recht manuell
- Digispot nimmt den Mitschnitt 24/7 kontinuierlich in Form von 10 Minuten MP3 Dateien auf.
- Die Dateien liegen lokal und werden in tagesspezifischen Ordner abgeleget. Das Schema für eine Datei ist
2023-04-19/13-50-00.mp3
, die nächste2023-04-19/14-00-00.mp3
usw... - Es gibt auch schräge Starts wie
2023-04-19/12-13-44.mp3
wenn der Digispot Dienst mal neu gestartet wird oder Schluckauf hat.
- Die Dateien liegen lokal und werden in tagesspezifischen Ordner abgeleget. Das Schema für eine Datei ist
- Diese einzelnen Dateien können aktuell durch zwei Dienste auf die Sekunde genau zu einer MP3 zusammengeschnitten werden:
- In Digispot selbst in der propritäten, nativen Windows Oberfläche.
- Durch den Dienst "boje" der für Mitmachende online aufrufbar ist und keine Anwesenheit vor Ort erfordert
- Beide Dienste ermöglichen den Mitschnitt nur durch "heraushören" der entsprechend Schnittkanten und manuelles Suchen des Schnittzeitpunktes.
- Boje normalisiert die MP3 Datei bei Export, ein manuelles Nacharbeiten in einer Schnitsoftware ist damit immerhin nicht zwangsweise notwendig
- Die finale Datei wird durch die Redakteur:in auf ein lokales Gerät herunter geladen. Da es zumeist hunderte Megabyte für eine Sendeausgabe sind, dauert das.
- Die Datei wird anschließend händisch über das Interface in die LOHROthek geladen. Das Hochladen ist üblicherweise noch langsamer.
- Der Prozess erfordert von der Redakteur:in um die 10 Minuten Aufmerksamkeit.
Was kann optimiert werden?
- Generierte Mitschnitte direkt in der LOHROthek zur Auswahl bereit stellen
- Das Interface wird direkt aus der LOHROthek bedient
- Im besten Fall liegt der Mitschnitt normalisiert und sauber geschnitten wenige Minuten nach Abschluss einer Sendung als Vorschlag vor.
Welche Informationsquellen gibt es?
- Wann lief eine Sendung?
- Die LOHROthek hat den aktuellen Programmplan mit Start- und Endzeiten. Als einzige Schnittstelle existiert dafür aktuell die thekno API.
- Wann wurde welches Audioelement live ausgespielt?
- Digispot legt die Liste der aktuell ausgespielten Audio-Elemente zusammen mit Zeitstempeln in einer XML-Datei ab (das ist aktuell die Quelle für den "trackservice"). Diese Elemente verschwinden, sofern die Ausspielung beendet ist.
- Ein rudimentärer und sehr abgehangener Trackservice enthält die Startzeitpunkte aller abgespielten Dateien. Endzeitpunkte gibt es nicht, die Komponente ist sehr alt und gehört ersetzt.
- Ein Websocket basierter Dienst (https://git.hack-hro.de/lohro/lohrothek/lohro-track-api) greift ebenfalls diese Datei ab und bereitet sie für die Thekno PWA auf.
- DHD-Ereignisse des Studio-Mixers (Anschaltung des Mikrofons, ...)
- Implementierungsstart eines Python DHD Modules: https://git.hack-hro.de/lohro/dhd/python3-dhdmixers
- Informationen stehen bisher nicht zur Verfügung, da nicht fertig.
Welche Projekte / Ansätze gibt es bereits
-
Boje Mitschnittservice (https://git.hack-hro.de/lohro/boje)
-
Recording API https://git.hack-hro.de/lohro/lohrothek/recording-api
- Ansätze einer REST-API für einen Mitschnitt-Dienst, der auf Anfrage einen Mitschnitt anhand eines Start- und eines Endzeitpunkts ausliefert
-
LOHROcorder https://git.hack-hro.de/lohro/lohrothek/lohrocorder
- Ansatz eines Dienstes der aufzeichnet und die Recording API anbietet. Code aus heutiger Sicht keine gelungene Grundlage (oyla ;) )
- Als Ersatz für die Aufnahme durch Digispot angedacht gewesen mit eben API Funktionalität
-
Recorder Projekt von AURA (https://gitlab.servus.at/aura/engine-recorder)
- Im Grunde der LOHROcorder Gedanke ohne API
- Der Gegebene Funktionsumfang wird aktuell durch Digispot aber bei uns erfüllt
-
BFR API https://git.hack-hro.de/lohro/bfr-api
- Ansätze einer gemeinsamen Schnittstelle der Radiosender.
- Präsentation in welcher unter anderem eine Visualisierung von Events vorhanden ist die den Gedanken unten recht nahe kommen könnten in der Visualisierung https://git.hack-hro.de/lohro/lohrothek/publicity/-/blob/master/bfr-api.pdf
Lösungsansatz
Module
Schnittkannten können abstrakt aus Events hergeleitet werden (basierend auf Informationsquellen)
Die folgenden Diensten könnten wahrscheinlich eine sinnvolle Aufteilung des Problems ergeben:
- (A) Zusammenführung verschiedener Quellen von Ereignissen (digispot-Ausspiel-Log, Mischpult-Ereignisse, ...) und Auslieferung via API.
- siehe "Welche Informationsquellen gibt es?"
- (B) Abholung eines Mitschnitts basierend auf Start- und Endzeitpunkt.(~ Recording API)
- (C) "Empfehlung" von Schnittzeitpunkten für eine Sendung (Auslieferung via neuer API):
- aus der Sendung ergeben sich ungefähre Start- und Endzeiten
- anhand der Ereignisse lassen sich Zeitpunkte vorschlagen (z.B. ein der Sendung zugeordneter Start-Jingle oder die Anschaltung des Studio-Mikrofons)
- die trivialste Implementierung würde einfach alle Ereignisse rund um den geplanten Start- und Endzeitpunkt ausliefern (ohne Empfehlung, ohne Kontext)
- (D) User-Interface zur Auswahl/Bestätigung von empfohlenen Schnittzeitpunkten für eine Sendung
(A) und (B) sind unabhängig von Informationen in der lohrothek
. Beide Dienste lassen sich später auch für nicht-digispot-Setups anpassen.
(C) und (D) könnten Teil der lohrothek
sein, da sie Kontext-Informationen zu Sendungen benötigen (geplante Sendezeit, eventuell ein manuell definierter Start-/Stop-Jingle).
Alternativ würde ein separater Dienst die zur Sendung gehörigen Daten über die lohrothek-API abholen und anschließend die Mitschnitt-Datei zur Sendung hochladen.
Grobe Skizze
flowchart TB
subgraph Events
direction TB
EventBundler("Event Bundler (A)")
EventBundler --> EventSource1("EventSource1 (DHD Sendepult)")
EventBundler --> EventSource2("EventSource2 (Digispot Playout)")
EventBundler --> EventSource3("EventSource3 (...)")
end
subgraph Recordings
direction TB
LOHROcorder("LOHROcorder (B)")
LOHROcorder -- "generates one file from" --> Files
Files((Raw Files)) -- "recorded by" --> DigispotRecorder
Files
end
subgraph LOHROthek
direction TB
lohrothek("LOHROthek \n (HTML native / vue.js interface)")
SuggestionService("Recording Suggestion Service (C)")
SuggestionService -- EventAPI --> EventBundler
lohrothek --> SuggestionService
lohrothek -- "RecordingAPI" --> LOHROcorder
end
Implementierung des Webinterface:
- Nutzer:in wählt die Aktion "Mitschnitt erzeugen" für eine Sendung
- Nutzer:in wählt aus einer Liste von vorgeschlagenen Start-Zeitpunkten einen aus
- Nutzer:in wählt aus einer Liste von vorgeschlagenen End-Zeitpunkten einen aus
- Nutzer:in bestätigt Auswahl -> Mitschnitt wird abgeholt und später der Sendung zugeordnet
- Im einfachsten Fall ist das Interface reines HTML
- Mit Blick auf die zukünftige Vorhörfunktion, welche in der Praxis sehr wichtig ist als Orientierung, sollte vielleicht vorbereitend direkt auf vue/API Kombination gesetzt werden. (Diskussion)
Grober Ablauf im Backend
sequenceDiagram
Note over LOHROthek: Suggestion for Broadcast triggered
LOHROthek->>Suggestion Service (B): Suggest some Datetimes for Start- and End for Broadcast ID
activate Suggestion Service (B)
Suggestion Service (B)->>Event Bundler (A): Events between datetime A and B
activate Event Bundler (A)
Event Bundler (A) -->> Suggestion Service (B): Events
deactivate Event Bundler (A)
Note over Suggestion Service (B): (Filtering and additional analysis)
Suggestion Service (B)-->>LOHROthek: Some suggestions for Start- and Endtime
deactivate Suggestion Service (B)
Note over LOHROthek: User decision via Interface (D)
LOHROthek ->> LOHROcorder (B): Recording from Timestamp X to Y in Format Z
activate LOHROcorder (B)
LOHROcorder (B) -->> LOHROthek: Yes this will work. Here is your Job ID.
LOHROthek ->> LOHROcorder (B) : Get Recording of ID
LOHROcorder (B) -->> LOHROthek: Please wait, still generating.
deactivate LOHROcorder (B)
LOHROthek ->> LOHROcorder (B) : Get Recording of ID
activate LOHROcorder (B)
LOHROcorder (B) -->> LOHROthek: URL to File
deactivate LOHROcorder (B)
Note over LOHROthek: Backend adds Audiofile to `RadioReport`
Zukünftige Erweiterungsmöglichkeiten
- Ersatz des Boje Services
- Die Grundfunktionalität "Mitschnitt von Zeitpunkt A bis B" wäre schon komplett vorhanden und die Bindung an das Erzeugen von Mitschnitten für Sendeausgaben (wie sie zunächst implementiert wird) ist eher ein Zusatz. Die geschaffenen Komponenten sollten mit wenig Mehraufwand für sich einfach einen manuellen Mitschnitt ermöglichen können und an allgemeiner Stelle als klassisches Interface nochmal dargestellt werden können.
- Multiple Quellen: Nicht immer gibt es nur einen einzigen Mitschnitt. Es kann mehre Instanzen geben - z.B. Aufnahmen aus unterscheidlichen Studios oder ein Mitschnitt der explizit keine Musikspuren enthält.
- Dass es mehrere Recorder geben kann sollte grob mitbedacht werden
- Der Mitschnitt ohne Musikspuren ließe sich als Filterung basierend auf den Zeiten, in denen ein Mikrofon im Studio angeschaltet war, erstellen. Dieser Komfort ist natürlich nur möglich, wenn die Sendung nicht vorab aufgezeichnet wurde (und somit nur als Tondatei vorliegt).
- Mehrere Bereiche für den Mitschnitt definieren (Automatische Entfernung für Musik)
- Die exakten Schnittpositionen lassen sich wahrscheinlich über interessante Audio-Filter/Analysatoren bestimmen (z.B. Suche nach einer kurzen Pause).
- Eine Vor-Hör-Funktion rund um den Start- und Endzeitpunkt (ähnlich wie bei der Boje) - daraus ließe sich dann ein Offset für den gewählten Start-/End-Zeitpunkt festlegen.
- Mehr Ereignisquellen einbinden (z.B. für nicht-digispot-Setups).
- Aufgrund von früheren Auswahlen für eine Sendung erkennen, was das typische Start-/Ende-Signal ist (z.B. automatische Ermittlung des Start-Jingles).
Nächste Schritte
- Allgemeines Konzept diskutieren
- Minimales Featureset festlegen.
- Aufwandsabschätzung
- Untertickets anlegen
- Schnittstellen definieren
- Neue Projekte im GIT anlegen / Vorhandene Projekte aufräumen falls sinnvoll
- Implementieren