Science Fiction Pharao des Eisens - Das Gizeh-Protokoll

[Telliminator]

Stapelverarbeitung und Grütze im Audio - neuer Zwischenstand

Ich hasse es langsam wirklich. Die ganze Zeit lässt mich das System im Glauben ich würde Audio vom Server als Rückmeldung erhalten, wenn ich der API den Auftrag gebe einen Text in Sprache umzuwandeln. Nein, in Wahrheit bekomme ich lediglich einen Textcontainer in dem drin steht, in welches Verzeichnis der Server vom TTS-System die Datei abgelegt hat.

Zuvor hieß es, ich erhalte das Audiofile als binäres Datenpaket vom Server retour. Dieses vermeidliche Audio wurde nach allen Regeln der Kunst auf Fehler wie Artefakte, leeres Audio, ZeroCross-Level. Schrabbeln, Rauschen usw. überprüft. Ich hatte mich über diese katastrophalen Werte gewundert, die das Audio als schlecht identifiziert haben. Um so spannender ist es, weil es auch Positiv Meldungen gab, welche brav im Gesamt-WAV zusammengeführt wurde, das komischerweise Audio zum Teil drin hatte, wo auch immer er sich das hergenommen hat. Jedenfalls muss ich die Logik nun leicht umbauen und das erzeugte Audio, was definitiv Fehler enthalten kann, neu einlesen und dann verprüfen und entscheiden, du bist so schlecht, wir schicken den Text nochmal zur Genierung ans TTS-System. Ein Problem gibt es jedoch noch - das Dateiformat.

Der Befehl zum Audioeinlesen nutzt im Hintergrund ffmpeg, welches das Audio klangheimlich auf 16Bit ändert statt es auf 32 Bit zu belassen. Es wirft so schon wieder komische Werte, die in keinster Weise nutzbar für die Audio-Qualitäts-Prüfung sind.. Also Hirnschmalz anwerfen und das erzeugte File vom Server Binär von Platte zu laden...

Ich sags Euch er, erkennt wieder viel Müll und ich erhalte trotzdem so nie ein fertiges Audio aus dem Text.

 

[Telliminator]

Zwischenstand/Update - Es wird.

Wieder ein Tag voller Dinge getan, von denen ich keine Ahnung habe. Es gab ein Update der XTTS Engine. Und wie es zu erwarten war ging danach erst mal gar nix mehr. Script um Script bis hin zur Neuinstalltione der gesamten Pyfhon- Umgebung und der Engine selbst war erforderlich. Dann konnte ich endlich wieder am eigentlichen Autonatisierungsscript weiter werkeln.

Wir haben jetzt noch ein seltsames Geister-Ton Phänomen. Manchma passt es ganz gut in die Stimmung der Geschichte. - es stört trotzden. Das Abwürgen und Abbrechen von Sätzen im Audio scheint seit dem Update scheinbar ein Ende gefunden zu haben. Jetzt kann ich mich vielleicht mal um bisschen Regiearbeit bemühen und Stimmenzuordnung vornehmen und das Buch per Stapelverarbeitung generieren lassen.

Erster Test mit der neuen Engine.

Es gibt noch Fehler:
- Geleier
- Geschwindigkeitsverlust
- Pausen
- Geisterton
- Komische Aussprache von Wörtern / Verzerrungen

Es steht und fällt mit der Qualität der Basis, der jeweiligen Stimme.

Ziel:
Weitere Audioprüfroutinen in das Ablaufscript einbauen, um den Server dazu zu bringen den Satz erneut zu berechnen. Zun Glück habe ich davon noch viel weniger Ahnung. Das wird spannend herauszufinden wann eine Aufnahme geleiert hat oder Geisterton enthält. Bei Stille wirds vielleicht einfacher, wenn´s denn wirklich Stille ist und nicht irgendein ein tiefes oder sehr hohes leises Frequenzgekrummel was man nur nicht hören kann. Analyse geht weiter. Aber das nächste Buch kann schon mal kommen ...

 

[Telliminator]

Der Automatisierungsworkflow

Buch / Geschichte auswählen (manuel Userl)
Text-Format umwandeln PDF->TXT (manuell online / PDF24 Tools)
Text-Analyse handelnde Figuren/Rollen Kontextanalyse (manuell online / K.I.)
Text-Analyse Dialoge erkennen und wer spricht (Script & manuell online / K.I.)
Text-Splitting Erzähler/Erzählertext, sprechende Rolle/Dialogtext (Script & K.I)
Casting / Überlegung welche Rolle, erhält welche Stimme (User manuell)
Script-Anpassung Rollenzuordnung - Stimme (manuell User)
Rollen-Textdatei umwandeln in Audio (Script mit localem TTS-System)
Audioprüfung der fertigen Datei (manuell User)

Das Script zur UmWandlung

Spoiler

Klar, dröseln wir das Skript auf! Im Grunde ist das ein hochentwickeltes TTS-Generierungsskript (Text-to-Speech) für ein Hörbuch, das eine Besonderheit hat: Es vertraut der KI nicht blind.

Statt den generierten Ton einfach zu speichern, jagt das Skript das Audio durch eine brutale physikalische Qualitätskontrolle, um typische KI-Fehler (Rauschen, Fiepen, Rumpeln, abgehackte Sätze) sofort zu erkennen und den Satz im Zweifel so lange neu zu generieren, bis er perfekt klingt.

Hier sind die einzelnen Schritte, aufgeteilt in den logischen Ablauf:

1. Initialisierung & Konfiguration​

• Stimmen-Zuordnung: Das Skript definiert ein Dictionary (voices), das verschiedenen Rollen (z. B. Erzähler, Figur 1 weiblich, Figur 2 männlich) eine spezifische .wav-Referenzstimme für die AllTalk-TTS-API zuweist.
• Dateipfade: Es wird festgelegt, wo die API die temporären Dateien ablegt (OUTPUT_FOLDER).

2. Text-Einlesen und Vorbereitung​

Das Skript startet als Hauptprogramm und liest eine Textdatei (Pharao_Rollen_Text.txt) Zeile für Zeile aus:

• Fortsetzungs-Check: Findet es eine hoerbuch_partiell.wav, fragt es dich im Terminal, ob es dort weitermachen soll (Absturzsicherung).
• Parsing: Es trennt jede Zeile am |-Zeichen auf, um die Rolle und den gesprochenen Text zu isolieren.
• Text-Säuberung: Unnötige Zeichen wie Anführungszeichen oder Auslassungspunkte (...) werden entfernt oder korrigiert, damit die KI nicht stolpert.

3. Die Generierung & Der "Parallel-Wächter"​

Jetzt wird es spannend. Für jeden bereinigten Satz startet eine Schleife mit bis zu 10 Versuchen:

• API-Anfrage:
  Das Skript schickt den Text an lokale AllTalk-TTS-API (generiere_einzelne_api_anfrage).
• Der Master-Vergleich:
  Es generiert gleichzeitig denselben Satz einmal mit der Problem-Stimme und einmal mit einer stabilen Master-Stimme (""). Warum? Wenn die Master-Stimme auch fehlschlägt, weiß das Skript: Der Text selbst bringt die KI zum Abstürzen, nicht die Stimme.
• Sicherer Festplatten-Lesezyklus:
  Das Skript wartet aktiv darauf, dass die Datei von der API fertig auf die Festplatte geschrieben wurde, liest die Rohdaten präzise aus (lade_audio_praezise) und wandelt sie sauber in ein pydub-Audioobjekt um.

4. Die "Nackt-Inspektion" & Qualitätskontrolle​

Bevor ein Satz akzeptiert wird, muss er durch ein ganzes Arsenal von mathematischen Filtern:

• inspiziere_audio_nackt:
  Gibt die technischen Eckdaten (Abtastrate, Kanäle, die ersten 10 Sample-Werte) im Terminal aus.
• diagnostiziere_audio & ist_audio_brauchbar:
  Hier schlägt die Physik zu.
  Das Skript prüft:
  • Lautstärke: Ist es zu leise? Gibt es Clipping (Verzerrung)?
  • Crest-Faktor: Ist die Dynamik zu flach ("KI-Soundwand")?
  • ZCR (Zero Crossing Rate): Gibt es hochfrequentes digitales Fiepen oder Rauschen?
  • Länge: Ist das Audio im Verhältnis zum Text unnatürlich lang oder viel zu kurz (Verschlucken)?
  • Infraschall-Rumpeln: Gibt es tieffrequentes Ploppen (oft ein Problem bei KI-Stimmen)?
  • Pausen & Hektik: Schweigt die KI zu lang oder rattert sie den Text unnatürlich schnell herunter?

5. Das "Notarzt"-Protokoll (in generiere_audio)​

Falls ein Satz fehlschlägt, hat das Skript verschiedene Eskalationsstufen für die nächsten Versuche:

• Versuch 2: Es tauscht Punkte gegen Ausrufezeichen (!), um der KI mehr "Sprechenergie" einzuhauchen.
• Versuch 3 & 4: Es schraubt an der API-Temperatur (Chaos- vs. Sicherheitsmodus).
• Versuch 5–7 (Der Notarzt): Wenn der Satz zu lang/komplex ist, spaltet das Skript den Satz am Komma oder in der Mitte auf, generiert beide Teile in separaten Unterschleifen einzeln, schneidet die Stille weg (strip_silence) und klebt sie perfekt wieder zusammen.

6. Zusammenbau & Notfall-Rettung​

• Erfolgsfall: Ist das Audio eines Satzes "brauchbar", wird es an eine Liste (alle_segmente) angehängt. Am Ende werden alle Sätze mit einer kurzen Pause (400ms) dazwischen zu hoerbuch_komplett.wav zusammengefügt.
• Notfall-Sicherung: Wenn du das Skript per STRG+C abbrichst oder ein unlösbarer Fehler auftritt, fängt der except-Block das ab. Das Skript exportiert sofort alle bis dahin generierten Sätze in die Datei hoerbuch_partiell.wav, damit deine Rechenzeit und deine Token nicht verloren sind.