DaVinci Resolve gibt es für Linux. D astimmt erst mal alles dran. Nur einfach es tatsächlich zum Laufen zu bringen, war es nicht.

Ich wollte meine MKV-Aufnahmen aus OBS unter Fedora schneiden. Kein exotisches Kameramaterial, keine Kinoproduktion, keine acht verschiedenen RAW-Formate. Einfach Aufnahmen aus meinem Stream, dazu eine getrennte Facecam und später automatisch erzeugte Untertitel. Auf dem Papier ist das ein ziemlich überschaubarer Wunsch.

Mein Stand dabei: Fedora 44, eine Nvidia RTX 2070 Super und Resolve als Flatpak. AutoSubs lief bei der Einrichtung zunächst in Version 3.6.2. Bei anderen Versionen können Pfade und einzelne Schritte inzwischen anders aussehen.

In der Praxis musste ich erst Resolve in ein Flatpak verpacken, meine Videos in ein anderes Format umrechnen, Verzeichnisse durch eine Sandbox reichen und am Ende Steam davon überzeugen, einen Port freizugeben, den AutoSubs für sich beanspruchte.

Jetzt läuft es. Und wenn ich mir den Weg dorthin anschaue, ist das entweder eine Erfolgsgeschichte für Linux oder ein ziemlich gutes Beispiel dafür, wie unterschiedlich Menschen das Wort „läuft“ verwenden.

Resolve in eine passende Schachtel packen

Blackmagic Design bietet Resolve zwar für Linux an, richtet sich dabei aber offiziell an eine recht fest umrissene Umgebung. Fedora gehört nicht dazu. Ich hätte nun anfangen können, Bibliotheken auf meinem System passend zu biegen. Das war mir für eine große proprietäre Anwendung allerdings zu heikel.

Meine Lösung wurde resolve-flatpak von pobthebuilder. Das Projekt nimmt den offiziellen Installer von Blackmagic Design und baut daraus ein Flatpak. Resolve landet damit in einer eigenen Umgebung und verteilt seine Erwartungen nicht quer über mein Fedora-System.

Das Projekt beschreibt den grundsätzlichen Bau so:

git clone https://github.com/pobthebuilder/resolve-flatpak.git --recursive
cd resolve-flatpak

flatpak-builder \
  --install-deps-from=flathub \
  --force-clean \
  --repo=.repo \
  .build-dir \
  com.blackmagic.Resolve.yaml

flatpak --user remote-add --no-gpg-verify resolve-repo .repo
flatpak --user install resolve-repo com.blackmagic.Resolve

In meiner Installation heißt die Anwendung com.blackmagic.Resolve. Nicht com.blackmagic.ResolveStudio. Diese kleine Unterscheidung hat mich später beschäftigt, als ich mit remote-info nach einem Update suchen wollte und nur die Meldung bekam, das lokale Repository habe keine Summary-Datei. Denn: Mein resolve-repo war schlicht kein gewöhnlicher Flatpak-Server, sondern das lokale Ergebnis meines eigenen Builds. Ein Update kommt deshalb nicht automatisch über flatpak update. Ich muss das Git-Repository aktualisieren, Resolve neu bauen und die vorhandene Installation ersetzen:

git pull

flatpak-builder \
  --install-deps-from=flathub \
  --force-clean \
  --repo=.repo \
  .build-dir \
  com.blackmagic.Resolve.yaml

flatpak --user install --reinstall resolve-repo com.blackmagic.Resolve

Das ist mehr Arbeit als ein Klick im Software-Center. Dafür weiß ich ziemlich genau, woher das Paket kommt und was bei einem Update passiert. Ich finde diesen Tausch in Ordnung.

Resolve startete danach. Damit war ungefähr die Hälfte des Problems gelöst.

Eigentlich müsste alles laufen... Eigentlich.

Meine OBS-Aufnahme sah technisch vollkommen normal aus: H.264 Main, yuv420p, 30 Bilder pro Sekunde und AAC-Ton mit 48 Kilohertz. Genau die Art von Datei, die auf ziemlich jedem Gerät abgespielt wird, das nicht gerade eine Digitaluhr ist.

Resolve Free unter Linux hat bei H.264 und AAC allerdings eigene Vorstellungen. In der offiziellen Liste der unterstützten Formate für Resolve 19 ist H.264 unter Rocky Linux der Studio-Version mit Nvidia-Grafik vorbehalten. AAC wird dort gar nicht unterstützt. Fedora ist nicht Rocky Linux, aber an der entscheidenden Stelle half mir dieser Unterschied nicht: Mein Material ließ sich nicht so verwenden, wie es aus OBS kam.

Zuerst hoffte ich, ein einfaches Remuxing würde reichen. Dabei wird nur der Behälter gewechselt, ohne Bild und Ton neu zu codieren. Das wäre schnell gewesen und hätte keine zusätzliche Generation erzeugt. Aber ein H.264-Video mit AAC-Ton bleibt auch danach ein H.264-Video mit AAC-Ton.

Die funktionierende Lösung war deshalb FFmpeg und ein Schnittformat, mit dem Resolve unter Linux zuverlässig arbeiten konnte: DNxHR SQ in einer MOV-Datei, dazu unkomprimierter PCM-Ton.

ffmpeg -hide_banner -y \
  -i "$input" \
  -map 0:v:0 \
  -map 0:a? \
  -c:v dnxhd \
  -profile:v dnxhr_sq \
  -pix_fmt yuv422p \
  -c:a pcm_s16le \
  -f mov \
  "$output"

Das Video wird dabei deutlich größer. Sehr deutlich. Dafür kann Resolve es öffnen, flüssig bearbeiten und samt Ton wiedergeben. DNxHR LB und zusätzliche MOV-Metadaten hatte ich ebenfalls ausprobiert. In meinem Ablauf machten sie Probleme. DNxHR SQ mit PCM funktionierte.

Also blieb es dabei.

Aus dem einzelnen Befehl wurde später ein kleines Skript. Es beobachtet einen Eingangsordner mit inotifywait, nimmt neue MKV-Dateien und legt die umgerechneten MOV-Dateien in einem Resolve-Ordner ab. Dafür braucht es unter Fedora neben FFmpeg die inotify-tools:

sudo dnf install ffmpeg inotify-tools

Das ist zusätzlicher Speicherbedarf und ein weiterer Verarbeitungsschritt. Aber es ist auch eine klare Grenze zwischen Aufnahme und Schnitt: OBS produziert sichere MKV-Dateien, das Skript übersetzt sie automatisch und Resolve bekommt genau das Material, mit dem es umgehen kann.

Nicht elegant im Sinne von „Ich werfe jede Datei hinein und alles funktioniert“. Und leider auch nicht angenehm im Sinne von „Ich muss nicht mehr darüber nachdenken“.

Mein Videoschnitt ist eine Konvertierungsstrecke

Die Skripte nehmen mir die Befehle ab. Das Warten, die großen Zwischendateien und die zusätzlichen Arbeitsschritte bleiben.

Bei einem längeren Video sieht mein Ablauf inzwischen so aus: Ich lade die Aufzeichnung von Twitch herunter, weil ich natürlich immer vergesse, rechtzeitig meine lokale Aufnahme zu starten. Dann konvertiere ich sie in ein Format, das Resolve unter Linux zuverlässig verarbeitet. Genauso wie die Files, die OBS produziert. Ich schneide das Video und exportiere es. Anschließend konvertiere ich den Export noch einmal, damit daraus eine vernünftig große Datei wird, die ich bei YouTube hochladen kann.

Das Video wird also vor dem Schnitt übersetzt und danach wieder zurückübersetzt. Dazwischen liegt die eigentliche Arbeit, wegen der ich Resolve überhaupt geöffnet habe.

Bei Social-Media-Clips ist es nicht besser. Die Videos sind zwar kürzer, aber der Ablauf bleibt: schneiden, exportieren, erneut konvertieren. Ohne den letzten Schritt sind die Dateien für ein paar Sekunden oder Minuten Video erstaunlich unhandlich. Mit dem Schritt sind sie gut zu speichern und hochzuladen. Nur muss ich ihn eben jedes Mal machen.

Das funktioniert inzwischen zuverlässig. Der Workflow steht. Aber ein funktionierender Workflow ist nicht automatisch ein guter Workflow. Ich habe aus einem Kompatibilitätsproblem eine kleine Produktionsstraße gebaut. Sie rattert ordentlich vor sich hin, nur möchte ich eigentlich Videos schneiden und nicht hauptberuflich Dateiformate ineinander umfüllen.

Die Sandbox macht ihren Job

Das Flatpak löste meine Bibliotheksprobleme, brachte aber seine eigene Grenze mit. Eine Anwendung in einer Sandbox darf nicht einfach überall auf meine Dateien zugreifen. Das ist grundsätzlich gut. Beim Videoschnitt fällt es nur sofort auf, wenn das Rohmaterial außerhalb der freigegebenen Verzeichnisse liegt.

Einen Ordner kann ich Resolve gezielt mit Schreibzugriff freigeben:

flatpak override --user \
  --filesystem=~/Streaming/Rohmaterial:rw \
  com.blackmagic.Resolve

Anschließend lässt sich das Verzeichnis in Resolve unter Preferences, System und Media Storage eintragen. Ich gebe damit nicht pauschal mein gesamtes Home-Verzeichnis frei, sondern nur den Ort, an dem Resolve tatsächlich arbeiten soll.

Genau für solche Grenzen mag ich Flatpak. Bis ein Plugin auftaucht, das fest davon ausgeht, Resolve liege unter /opt/resolve und könne selbstverständlich auf /usr/lib zugreifen.

AutoSubs trifft auf zwei verschiedene Welten

Für meine Social-Media-Clips wollte ich AutoSubs verwenden. Das Projekt transkribiert lokal und kann die Untertitel direkt als gestaltete Clips in eine Resolve-Timeline schreiben. Unter Fedora kam AutoSubs 3.6.2 bei mir als RPM auf das System. Resolve lief aber im Flatpak.

Damit lebten beide zunächst nebeneinander her.

Das RPM legte sein Lua-Skript hier ab:

/opt/resolve/Fusion/Scripts/Utility/AutoSubs.lua

Die benötigten Ressourcen lagen unter anderem hier:

/usr/lib/autosubs/resources

Resolve im Flatpak konnte mit diesen Orten nichts anfangen. Der erste deutliche Hinweis war:

Could not find the AutoSubs app resources

Mein erster Versuch bestand darin, die Verzeichnisse per Flatpak-Override freizugeben. Das reichte nicht. Innerhalb eines Flatpaks ist /usr Teil der eigenen Laufzeitumgebung. Ein Verzeichnis vom Host lässt sich dort nicht so einhängen, wie ich es zunächst erwartet hatte.

Funktioniert hat ein anderer Weg: Ich habe das Lua-Skript in den Script-Ordner von Resolve innerhalb des Flatpak-Datenbereichs kopiert. Auch die AutoSubs-Ressourcen liegen nun innerhalb dieses Bereichs. Den fest eingetragenen Ressourcenpfad im Lua-Skript habe ich entsprechend angepasst.

Die entscheidenden Orte lagen damit nicht mehr unter /opt und /usr, sondern unterhalb von:

~/.var/app/com.blackmagic.Resolve/

Das ist kein besonders schöner Installationsweg. Er macht aber sichtbar, was hier eigentlich passiert: Das native RPM weiß nichts von der Flatpak-Installation, und das Flatpak weiß nichts von den Dateien des RPM. Ich musste die Brücke selbst bauen.

AutoSubs tauchte danach unter Workspace und Scripts in Resolve auf. Später fehlten noch Teile des Caption-Templates. Auch das war am Ende kein geheimnisvoller Resolve-Fehler, sondern eine unvollständige Ressourcenkette. Lua-Skript, Module, Bilder, Schriften und Fusion-Template müssen gemeinsam in der Umgebung liegen, die Resolve tatsächlich sieht. Nur die Startdatei zu kopieren genügt nicht.

Steam und der Untertitelserver

Als dann alles richtig aussah, meldete AutoSubs trotzdem:

Failed to send Exit via socket

Die Resolve-Integration von AutoSubs startet innerhalb von Resolve einen kleinen Lua-Server. Die AutoSubs-Oberfläche spricht ihn über 127.0.0.1 auf Port 56002 an.

Also habe ich nachgesehen, wer diesen Port benutzte:

ss -tanp | grep 56002

Die Antwort war Steam.

Nicht Resolve. Nicht AutoSubs. Steam hatte zufällig eine lokale Verbindung mit genau diesem Port aufgebaut. Wahrscheinlich war das kein dauerhaft reservierter Port, sondern schlicht Pech bei der automatischen Vergabe. Für AutoSubs war er trotzdem belegt.

Die Lösung war entsprechend unspektakulär:

steam -shutdown
pkill -f /usr/bin/autosubs

Danach habe ich AutoSubs einmal neu gestartet. Es funktionierte.

Es läuft, weil ich die Übergänge kontrolliere

Resolve unter Fedora zum Laufen zu bringen war bei mir nicht die eine Installation mit dem einen geheimen Befehl. Es waren vier Übergänge, die nicht zusammenpassten:

1. Der offizielle Linux-Installer erwartete eine andere Distribution. Das Flatpak gab ihm eine passende Umgebung.
2. OBS und Twitch liefern Material, das Resolve Free unter Linux nicht so verarbeitet, wie ich es brauche. Vor dem Schnitt übersetzt FFmpeg es in DNxHR SQ und PCM. Nach dem Export folgt die Übersetzung zurück in ein handliches Format für YouTube und Social Media.
3. AutoSubs wurde nativ installiert. Skript und Ressourcen mussten in den Datenbereich des Resolve-Flatpaks.
4. Die Verbindung lief über einen lokalen Port. Steam saß zufällig darauf.

Keines dieser Probleme war für sich besonders dramatisch. Zusammen erzeugten sie aber dieses typische Linux-Gefühl: Das Programm ist installiert, das Fenster geht auf und trotzdem beginnt die eigentliche Einrichtung erst jetzt.

Ich würde diesen Weg nicht allen empfehlen. Wer einfach nur Videos schneiden möchte, hat wenig davon, Dateiformate, Sandboxes und lokale Socket-Verbindungen kennenzulernen. Ich mag an meiner Lösung trotzdem, dass ich sie inzwischen verstehe. Meine Aufnahmen bleiben im offenen OBS-Workflow, die Untertitel entstehen lokal und die notwendigen Übersetzungen übernehmen kleine Skripte.

Nur unsichtbar werden die Übersetzungen dadurch nicht. Jede längere Twitch-Aufzeichnung läuft vor und nach dem Schnitt durch FFmpeg. Jeder kleine Social-Media-Clip wird erst exportiert und anschließend noch einmal auf eine handliche Größe gebracht. Die Skripte verhindern, dass ich jedes Mal Befehle zusammensuchen muss. Zeit, Speicherplatz und einen zusätzlichen Schritt kosten sie trotzdem.

Resolve läuft unter Fedora. Ich kann so arbeiten, das am Ende was rauskommt. Es nervt jetzt nur zuverlässig.

Ich streame unter Fedora. OBS läuft, die Kamera läuft, das Mikrofon funktioniert und auch das Stream Deck tut, was es soll. Das war alles deutlich unspektakulärer, als ich vorher gedacht hatte.

Dann kam der Ton.

Mikrofon, Discord, Spiel, Firebot und die Geräusche vom Stream Deck sollen schließlich nicht nur irgendwie hörbar sein. Sie sollen an den richtigen Stellen hörbar sein. Und an den falschen bitte ausdrücklich nicht.

Ausgerechnet dieses Audiorouting ist inzwischen einer der Teile meines Setups, die mir unter Fedora am besten gefallen. Nicht, weil alles auf Anhieb funktioniert hätte. Das wäre gelogen. Sondern weil ich jetzt ein Skript habe, in dem ziemlich genau steht, was wohin geht.

Kein zusätzliches virtuelles Mischpult mit vielen Knöpfen und einer Konfiguration, an die ich mich drei Monate später nicht mehr erinnere. Ich habe einen Kabelplan, den ich starten kann.

Wer eigentlich was hören darf

Der Stream soll mein Mikrofon hören, die Leute im Discord, Firebot, das Spiel und die Sounds, die ich über das Stream Deck einspiele.

Discord soll dagegen nur meine von OBS bearbeitete Stimme und ausgewählte Sounds vom Stream Deck bekommen. Nicht den Spielton. Nicht Firebot. Und vor allem nicht den Discord-Chat selbst. Sonst hören sich dort alle mit leichter Verzögerung noch einmal.

Ich selbst möchte über den Kopfhörer natürlich mitbekommen, was gerade passiert. Nur meine eigene Stimme möchte ich nicht zeitversetzt hören. Das macht mich innerhalb weniger Sätze vollständig sprechunfähig.

Für diese Trennung legt mein Skript in PipeWire mehrere virtuelle Ausgänge an. Technisch heißen die Dinger Sinks. Das Wort hilft mir beim Verständnis allerdings nur bedingt. Für mich sind das eher beschriftete Räume: Ein Programm wird in den passenden Raum geschickt, OBS nimmt den Raum als eigene Quelle auf und das Skript entscheidet, wer außerdem zuhören darf.

• discord_sink enthält die Stimmen aus Discord. In OBS heißt diese Quelle Discord-Sound. Ich höre sie auf dem Kopfhörer, Discord selbst bekommt sie aber nicht zurück.
• firebot_sounds sammelt die Sounds aus Firebot und dem Browser. In OBS landen sie als Firebot-Sounds, auf meinem Kopfhörer ebenfalls, in Discord nicht.
• soundboard_sounds enthält die Sounds vom Stream Deck. OBS nimmt sie als Soundboard auf, ich höre sie und Discord bekommt eine leisere Kopie.
• game_audio ist für Spiel- und Systemton zuständig. In OBS heißt die Quelle Game-Sound. Ich höre sie, Discord nicht.
• discord_micmix mischt meine bearbeitete Stimme mit der leiseren Soundboard-Kopie. Diesen Mix höre weder ich noch OBS. Er geht nur an Discord.

Discords Ausgabe landet also in OBS und auf meinem Kopfhörer, aber niemals wieder in Discord. Firebot und der Spielton bleiben ebenfalls draußen. Nur das Soundboard bekommt einen zusätzlichen Weg in Richtung Sprachkanal.

Meine Stimme nimmt noch einen kleinen Umweg. Das echte Mikrofon landet zuerst in OBS, wird dort gefiltert, komprimiert und begrenzt und anschließend über das Audio-Monitoring in discord_micmix geschickt.

Normalerweise bedeutet Monitoring, dass man sich selbst auf dem Kopfhörer hört. Genau das möchte ich wegen der Verzögerung nicht. Als Monitoring-Gerät ist in OBS deshalb nicht mein Kopfhörer ausgewählt, sondern DiscordMicMix. OBS überwacht meine Stimme gewissermaßen in Richtung Discord. Bei mir kommt diese Spur nicht noch einmal an.

Dadurch hören Stream und Discord dieselbe bearbeitete Stimme. Das rohe Mikrofon bleibt aus dem Discord-Mix heraus. Würde ich beides verbinden, kämen meine unbearbeitete und meine bearbeitete Stimme gleichzeitig an. Lauter wäre das vermutlich. Besser eher nicht.

Ton da. Discord hört nichts.

Ganz geradlinig bin ich zu diesem Aufbau nicht gekommen.

Zwischendurch sah alles richtig aus. Der Mix enthielt Ton, die Verbindungen waren vorhanden und Discord nahm angeblich das passende Gerät auf. Im Mikrofontest war trotzdem nichts zu hören.

Mit pw-play habe ich deshalb testweise direkt etwas in den vorgesehenen Audioweg geschickt. Diese Wiedergabe erkannte Discord plötzlich als Mikrofon. Der Ton war also da und der Weg grundsätzlich offen. Discord behandelte nur den Monitor des virtuellen Ausgangs nicht so, wie ich es brauchte.

Aus discord_micmix.monitor wurde deshalb über eine Remap-Quelle ein richtiges virtuelles Eingabegerät: discord_microphone. In der Oberfläche heißt es erfreulich eindeutig Discord-Mikrofon.

Das war der Punkt, an dem aus einem scheinbar richtigen Aufbau ein tatsächlich funktionierender wurde.

Vorher lagen ein Nachmittag mit Gerätenamen, Stream-IDs, ziemlich vielen Ausgaben von pactl list und dem leisen Verdacht, alles kaputtrepariert zu haben.

Danach hatte ich eine Lösung, die ich vollständig lesen konnte.

Was mein Skript erledigt

Das Skript heißt streaming-audio.sh und liegt bei mir in ~/bin.

Einmalig richte ich damit die virtuellen Audiogeräte ein:

~/bin/streaming-audio.sh install

Vor dem Stream starte ich OBS, Discord und das Soundboard. Anschließend setze ich das Routing:

~/bin/streaming-audio.sh route

Das Skript prüft und erledigt dabei unter anderem:

• fehlende virtuelle Audiogeräte anlegen
• game_audio als Standardausgang für neu gestartete Spiele setzen
• bereits laufende Programme anhand ihrer Namen auf die passenden Ausgänge verschieben
• die virtuellen Ausgänge mit meinem Kopfhörer verbinden
• alte oder doppelte Verbindungen aus früheren Versuchen entfernen
• das OBS-Mikrofon mit 115 Prozent in den Discord-Mix schicken
• das Soundboard mit 75 Prozent zusätzlich in diesen Mix legen
• das virtuelle Discord-Mikrofon anlegen und als Systemmikrofon setzen
• einen bereits laufenden Discord-Aufnahmestrom auf dieses Mikrofon verschieben

Die 75 Prozent gelten nur für die Kopie des Soundboards, die in Discord ankommt. Im Stream und auf meinem Kopfhörer bleibt der Pegel unverändert. Ich kann einen Sound für die Leute im Sprachchat also leiser machen, ohne ihn gleichzeitig für den Stream verändern zu müssen.

Wenn etwas nicht dort landet, wo ich es erwarte, hilft:

~/bin/streaming-audio.sh status

Damit sehe ich die Standardgeräte, die virtuellen Ausgänge, laufende Wiedergabe- und Aufnahmeströme und die relevanten PipeWire-Verbindungen.

Nach dem Stream kann ich außerdem wieder mein echtes Mikrofon als normales Systemmikrofon setzen:

~/bin/streaming-audio.sh restore-mic

In Discord musste ich Discord-Mikrofon einmal als Eingabegerät auswählen. Seitdem stellt das Skript den Aufbau bei jedem route-Durchlauf wieder her und verschiebt auch einen bereits laufenden Discord-Stream auf das richtige Gerät.

Discord merkt sich die Auswahl. Jedenfalls bislang. Software liest solche Sätze bekanntlich gern als Herausforderung.

Das Feintuning bleibt in OBS

Das Skript kümmert sich um die Wege. Wie die einzelnen Quellen klingen, stelle ich weiterhin in OBS ein.

Unter Einstellungen → Audio → Erweitert ist bei mir DiscordMicMix als Audiomonitoring-Gerät ausgewählt.

In den Erweiterten Audioeigenschaften gilt:

• Mikrofon: Monitor und Ausgabe
• Discord-Sound: Monitoring aus
• Firebot-Sounds: Monitoring aus
• Game-Sound: Monitoring aus
• Soundboard: Monitoring aus

Nur mein Mikrofon darf über das OBS-Monitoring in den Discord-Mix. Die zusätzliche Verbindung für das Soundboard legt das Skript direkt in PipeWire an.

Für mein Mikrofon nutze ich als Ausgangspunkt die Audiofilter von OBS:

1. Rauschunterdrückung
2. bei Bedarf einen Expander statt eines harten Noise Gates
3. einen Kompressor mit ungefähr −28 dB Threshold, 3:1 Ratio, 8 ms Attack, 150 ms Release und 6 dB Ausgangsverstärkung
4. einen Limiter bei ungefähr −5 dB und 80 ms Release

Beim normalen Sprechen liegt mein Signal grob zwischen −18 und −12 dB. Wenn ich lauter werde, darf es Richtung −10 bis −6 dB gehen. Die Kopie meiner Stimme wird auf dem Weg zu Discord zusätzlich auf 115 Prozent gesetzt. Das verändert nur den Pegel in Discord, nicht den im Stream.

Auch Discord-Sound wird in OBS etwas eingefangen. Dort sitzt zunächst ein leichter Kompressor mit ungefähr −20 dB Threshold, 2,5:1 Ratio, 10 ms Attack, 150 ms Release und 2 dB Ausgangsverstärkung.

Dahinter folgt ein zweiter, sehr zurückhaltender Kompressor mit meinem Mikrofon als Sidechain-Quelle. Sobald ich spreche, wird Discord um ungefähr zwei oder drei Dezibel abgesenkt. Das reicht für etwas mehr Verständlichkeit, ohne dass das Gespräch hörbar verschwindet. Ein Limiter bei ungefähr −8 dB fängt Spitzen ab.

Mein Ziel ist, dass Discord ungefähr zwischen −16 und −10 dB liegt und meine Stimme etwas darüber bleibt. Das sind meine Werte für mein Mikrofon, meinen Abstand und meine Stimme. Wer den Aufbau übernimmt, wird an dieser Stelle selbst hören, aufnehmen und nachstellen müssen.

Die Technik an der richtigen Stelle

Natürlich lässt sich ein vergleichbares Setup auch unter Windows bauen. Dort hatte ich dafür virtuelle Audiokabel, Mischpulte und zusätzliche Programme. Unter Fedora ist meine Lösung nicht weniger technisch. Eher im Gegenteil.

Die Technik sitzt für mich jetzt nur an einer angenehmeren Stelle.

Mein Audiorouting besteht aus Text. Ich kann es sichern, verändern, vergleichen und nach einem Neustart wieder anwenden. Wenn ich wissen möchte, weshalb Discord das Soundboard hört, gibt es dafür eine konkrete Verbindung. Wenn Firebot nicht im Sprachkanal landen soll, existiert dieser Weg einfach nicht.

Das Skript kann keine schlechte Mikrofonposition ausgleichen und auch nicht entscheiden, ob eine Stimme angenehm laut ist. Dafür ist weiterhin OBS zuständig. Es stellt aber reproduzierbar die Verkabelung her.

OBS läuft. Das Stream Deck läuft. Und das vermeintlich komplizierteste Stück meiner Streaming-Einrichtung ist inzwischen der Teil, den ich am liebsten mag.

Ich habe keinen Zustand in einem virtuellen Mischpult mehr, den ich mir merken muss.

Ich habe einen Kabelplan, den ich starten kann.

Ich bin gerade etwas verwirrt. Also auf moralische Weise, auf ethische. Nicht so wie sonst. Denn ich weiß überhaupt nicht, ob ich das darf, obwohl es mir gefällt. Aber von vorne.

Vor zwei Wochen war ich auf Norderney. Das war in mehrfacher Hinsicht fantastisch, denn das war das Ziel der diesjährigen Harzreise vom Round Table 89 Göttingen.

Das Konzept ist so einfach wie bestechend: Einmal im Jahr organisiert jemand eine Fahrt, meines Wissens ging es bisher nur einmal wirklich in den Harz, und niemand sonst weiß, wo es hingeht. Dieses Jahr: einen Tag Oldenburg. Einen Tag Norderney. Und dann wieder zurück.

Weshalb das für mich doppelt fantastisch war? Weil ich gerade Walter Moers lese und seine Insel der Tausend Leuchttürme, goone. Und ich bin mir ziemlich sicher, dass das niemand so beschreiben würde, obwohl ich wirklich sagen muss, dass ich das Buch so toll finde, dass ich es so lange herauszögere fertig zu lesen, wie möglich. Ich habe es in Kur angefangen und wusste nicht, worum es geht. Außer, dass es in Zamonien spielt. Und tatsächlich handelt es sich um eine Satire auf die Kurorte: die Menschen, die dort sind, die Ärzte, die spezielle Kur-Industrie, die sich darum bildet. Großartig! Und bevor ihr nicht fragt: Nein, normalerweise weiß ich, was ich lese. Aber da hat es mir wirklich gereicht zu wissen, dass es ein weiterer Zamonien-Roman ist.

Und die Insel, auf der es spielt, ist keine andere als Eydernorn. Eydernorn, ihr versteht? Ein Moers-Anagramm. Genauso wie Ojahnn Golgo von Fontheweg oder einer der Lieblinge meiner Frau, Zank Frakfa. Und ehrlich gesagt liegt Woski Ejstod noch ungelesen auf meinem Pile of Shame. Auf jeden Fall strotzt das Buch nur so vor Fabulierlust und meistens trifft es genau das, was mir Spaß macht. Zum Beispiel die Geschichte, warum auf Eydernorn in Cafés oft noch Makrelen serviert werden. Großartig!

Als vor hunderten von Jahren der Inselkönig Indoltepp Aan der Große (er soll auffällig kleinwüchsig gewesen sein) einmal über seine Insel wandelte, traf er ein paar hungernde Untertanen, die ihn um Brot anbettelten. Das war Indoltepp so peinlich und unangenehm, dass er Folgendes verfügte: Fortan soll jeder, der sich auf der Insel Eydernorn befinde, sei es Einwohner oder Besucher, kostenlos und an jedem Tag eine geräucherte Makrele erhalten - auf dass niemand in seinem Reich jemals mehr Hunger leiden müsse, basta!

Und da das ein wenig aus der Zeit gefallen ist, man aber noch Angst hatte, dass wegen Missachtung des Makrelengesetzes Indoltepp, ansonsten ein größenwahnsinniger Tyrann, zürnt, hat sich die Gastro was einfallen lassen:

Daher sind mit der Zeit etliche Lokale dazu übergegangen, die kostenlosen Makrelenportionen zu reduzieren. Und nur noch kleine Makrelenhäppchen, Makrelengebäck oder lediglich symbolische Makrelen aus Papier zu kredenzen, die man als Serviette benutzen kann. Aber ganz ohne Makrele läuft es nirgendwo!

Ich finde die Vorstellung so witzig, wie Moers in einem Café sitzt, sich über die kleinen Plätzchen lustig macht, die es zum Kaffee gibt, und diese Geschichte dazu erfindet.

Und jetzt war ich unerwartet auf dieser Insel. Ich freute mich über mögliche Eigenheiten, wollte mir ganz genau anschauen, wie und ob Moers das Norderneyer Marketing verballhornt, und wollte natürlich einen Leuchtturm sehen.

Wie es so kommen musste, ist dies nicht wirklich geschehen, da die Zeit eher in geschlossenen Räumen mit Zapfanlage stattgefunden hat. Ein Strandspaziergänger hatte es dann auch am Tag unserer Abreise so schön auf den Punkt gebracht: Es ist sehr bedauerlich, dass wir nichts von der Insel gesehen haben, aber verständlich.

Vor unserem Hotel stand jedenfalls das Kaiser-Wilhelm-Denkmal, das, wie ich gerade gelernt habe, auch Klamottendenkmal genannt wird, weil ja Klamotte auch „größerer Stein, Gesteinsbrocken“ heißen kann.

Jedenfalls hätte ich gerne hier dann ein paar Bilder hochgeladen, die ich schon so vor Augen hatte, als ich das ursprüngliche Foto gemacht habe.

Ja, es wirkt ähnlich wie Zeichnungen von Moers. Ja, der Künstler bekommt keine Kohle, wenn ich es hier veröffentliche. Und ja, mir ist bewusst, wie viel Energie und Wasser für die Erstellung dieses Gags draufgegangen ist.

Aber es trifft die Stimmung mehr, die ich hatte, als ich durch die Gassen der Insel schlenderte oder nachts vor meinem inneren Auge schon diese Zeichnung gesehen habe:

Ich könnte mir jetzt Zeichnen beibringen, klar. Ich könnte mich hinsetzen und versuchen, etwas im Stil von Moers zu kreieren. Aber wir wissen ja: Das passiert nicht. Und statt seine Gedanken dann hier auf dem Blog ein bisschen laufen zu lassen, würde ich wahrscheinlich einfach was anderes machen.

Und ich frage mich wirklich: Darf ich das hier nutzen?

Wobei „Darf ich das?“ natürlich auch schon wieder eine ziemlich bequeme Frage ist. Denn sie klingt nach Moral, meint aber oft: Kann mir bitte jemand eine argumentativ stabile Brücke bauen, über die ich trockenen Fußes zu dem Ergebnis komme, das ich sowieso gern hätte?

Jedenfalls tendiere ich dazu, zu sagen: Ja, schon. Es muss irgendwie klar sein, dass es KI-generiert ist. Es muss eine eigene Idee darin stecken, etwas Eigenes, ein Grund, warum dieses Bild mehr ist als nur: „Mach mal hübsch.“

Denn was macht den nervigen AI-Slop aus? Unkreative, einfach erstellte, professionell in die Kamera lächelnde und auf Produkte zeigende Menschen. Aber das hat mich auch schon früher aufgeregt, wenn Kundinnen und Kunden trotz besseren Wissens die lächelnde Frau mit Headset vor Tastatur als Foto für den Support-Bereich ihrer Webseite genutzt haben. Das ist eine der rätselhaftesten Figuren der späten Dienstleistungsgesellschaft. Sie lächelt seit ungefähr 1998 in Support-Bereiche hinein, ohne je ein Ticket gelöst zu haben. Neben ihr steht manchmal ein Mann mit Klemmbrett, der auf etwas zeigt, das außerhalb des Bildes liegt. Beide zusammen haben vermutlich mehr Webseiten verschandelt als jede generative KI bisher.

Man nutzte Stock-Fotos, die es, wenn man suchte, ebenso kostenlos, manchmal auch in CC0-Lizenz, an vielen Ecken im Netz zum Angebot gab und gibt. Haben die das Netz oder die Nutzererfahrung besser gemacht? Ich glaube nicht. Haben sie jemandem geschadet? Meistens auch nicht. Konnte man an den Fotos mit Models definitiv festmachen, dass man sie mit gutem Gewissen verwenden konnte? Ganz einfach: nein.

Aber der große Aufschrei blieb da immer aus. Häme gab es, Kritik an der uninspirierten Auswahl, klar. Aber das Spielchen, wie ich es so mitbekommen habe, jemanden mit dem Äquivivlent von #aislop zu taggen, wenn jemand ein uninspiriertes Stock-Foto benutzt hat, um etwas zu kreieren, das gab es und gibt es, soweit ich weiß, nicht.

Und nicht vergessen: Ich rede hier nicht von politischer Kommunikation. Ich rede noch nicht einmal von kommerzieller Kommunikation. Ich rede davon, dass ich mir über die Maßen Gedanken mache, ob ich in meiner kleinen Butze hier ein paar KI-Fotos an die Wand hängen darf oder nicht, ohne dafür gleich kritisiert zu werden. Und dass ich mir da so sehr drüber Gedanken mache, dass ich mich fast schon selbst wieder über mich ärgere.

Wenn ich nämlich jetzt die Bilder moralisch und ethisch, vielleicht auch irgendwann juristisch, hier nicht nutzen kann, die ich aus meinen Fotos in eine Moers-ähnliche Richtung habe verwandeln lassen, darf ich dann auch das hier nicht nutzen?

Meine Frau (links) und ich (rechts) waren in der Woche nach Norderney zu zweit in Hamburg unterwegs. Wir waren zuerst in der Heinrichstraße und haben uns da die Örtlichkeiten der Rocketbeans angeschaut und sind danach mit einem Uber, den man ja, glaube ich, auch moralisch eigentlich nicht nutzen dürfte, in das Zurück in die Zukunft-Musical gefahren.

Ich muss sagen: Ich war skeptisch. Ich liebe den Film, denn er hat Klein-Flo an Science-Fiction herangebracht und hatte, glaube ich, einen ziemlich großen Einfluss auf mich. Lange Zeit habe ich zum Beispiel auch gedacht, dass es nicht nur übelst cool, sondern auch bequem ist, so zu schlafen, weshalb ich mir das unbedingt angewöhnen wollte. Und dazu ein Musical?

Ich mag Musicals. Sehr. Wenn man Musik und ein Orchester dazu nutzen kann, Emotionen noch mehr zu verstärken, dann macht das! Hab ich Bock drauf. Aber bei Marty und Doc? Ich war mir unsicher. Bis die ersten zwei Takte vom Theme vom Orchester gespielt wurden und ich mir meine Augen abwischen musste.

Tolle Inszenierung, tolle Ideen. Generell ein Tipp von meiner Seite, sich das mal anzuschauen. Spannend war auch zu sehen, wie sie, obwohl sie ziemlich stringent, mit der ein oder anderen Änderung, die Original-Handlung nacherzählten, Jan Kersjes’ Doc Brown viel mehr Impact gegeben haben und Marty dadurch eher als fremdbestimmter Charakter wirkt. Was er für mich im ersten Teil des Films definitiv nicht war. Verpeilt, ja. Falsche Entscheidungen, ja. Aber eben aus sich heraus getroffen.

Jedenfalls stand in der Lobby vom Musical ein halbdurchgeschnittener DeLorean, für Insta und so. Und wir hatten aufgrund unserer Armbändchen und der längeren Rocketbeans-Führung ein zeitliches Problem: Wir mussten insgesamt mindestens vier Aperol trinken, damit sich für uns die Getränke-Flat auch lohnte. Das Armbändchen am Handgelenk war dabei der Schlüssel zum orangenen Glück. Deshalb war für das Foto relativ wenig Zeit geblieben, ich glaube, es ist nach dem zweiten Gong entstanden.

Beleuchtung, Abstand, Posen konnten deshalb vorher nicht probiert werden. Ich habe deshalb mein Chatty angesetzt. Weißabgleich, Farben etwas knalliger machen und Perspektive so ändern, dass unsere Gesichter besser zu sehen sind; ohne etwas an den Gesichtern zu ändern.

Hätte ich das in Photoshop hinbekommen? Klar. Ich hätte dann auch noch geschaut, ob ich mit Frequenztrennung was reißen kann. Natürlich nur bei meinem Gesicht, bei meiner Frau ist da absolut keine Nachbearbeitung notwendig. Hatte ich aber keine Lust zu, weil ich viel schneller ein Ergebnis für meine Zwecke über meine generative KI bekomme.

Und keine Ahnung, ich vereinfache jetzt natürlich sehr. Aber oben die Fotos von Norderney beruhen auf meinen Fotos und wurden dann durch KI bearbeitet. Unten das Foto aus Hamburg auch. Ab wann wird es denn dann böse, KI zu nutzen, um Bilder zu bearbeiten, zu verfremden oder neu zu generieren?

Ich will gar nicht so tun, als hätte ich die große Antwort. Ich will nur nicht mehr so tun, als wäre jede KI-Nutzung automatisch Slop und jedes alte Stockfoto automatisch harmlos. Vielleicht beginnt die ehrlichere Unterscheidung nicht bei der Technik, sondern bei der Absicht: Will ich etwas ersetzen, verschleiern und billig aufblasen? Oder will ich etwas zeigen, das vorher nur in meinem Kopf war?

Und genau da lande ich dann wieder bei Norderney.

Ich habe diese Insel nicht wirklich gesehen. Jedenfalls nicht so, wie man eine Insel sieht, wenn man vernünftig ausgeschlafen, nüchtern und mit Wanderschuhen unterwegs ist. Ich habe sie eher durch Walter Moers gesehen, durch Zapfanlagen, durch ambitionierte Zeitplanung, durch ein Denkmal vor dem Hotel und durch diese innere Erwartung, dass hinter der nächsten Ecke vielleicht doch irgendwo ein Stück Eydernorn steht.

Vielleicht zeigen die KI-Bilder also nicht, wie Norderney war. Vielleicht zeigen sie, wie ich Norderney im Kopf hatte.

Und vielleicht ist genau das der Unterschied, der mir wichtig ist: Ich benutze sie nicht, um Wirklichkeit zu ersetzen. Ich benutze sie, um eine Vorstellung sichtbar zu machen. Ein Bild zu einem Gefühl, das ich ohne dieses Werkzeug wahrscheinlich nicht gezeigt hätte.

Ob das als Antwort reicht? Keine Ahnung. Vermutlich nicht für alle. Vielleicht auch nicht für mich an jedem Tag.

Aber für diesen Text, für diese kleine Butze hier, für diese Mischung aus Reise, Moers, Denkmal, schlechtem Gewissen und innerem Makrelengebäck reicht es mir erst einmal.