Piper TTS braucht Eure technische Expertise

Beim letzten Linux am Dienstag wurde uns Piper TTS vorgestellt, daß in seiner initialen Version schon gute Resultate liefert, aber leider min. einen gravierenden Sprachfehler in den deutschen Modulen hat. Carola konnte natürlich nicht anders und hat die Sprachausgabe schon für sich gekappert 😉

Piper TTS braucht Eure technische Expertise

Laut dem GitHub Issue #52 ist dafür aber ESpeak-NG verantwortlich, weil es min. die Silbe „ch“ nicht richtig ausspricht. So klingen die deutschen Stimmen wie unsere holländischen Nachbarn. Eine provisorische Korrektur später, hatten wir allerdings Turkdeutsch in der Ausgabe, was auf seine Art auch irritierend ist, aber immer noch verständlicher, als wenn CH als ICK ausgesprochen wird 😉

Jetzt kommen die ESPEAK-NG Fachleute unter Euch ins Spiel: Wie bekommt man den Sprachfehler da jetzt raus?

Wenn jemand hilfreiche Tips hat, dann bitte direkt in dem GitHub Issue #52 zum Besten geben, um so schneller kann Piper die Standartsprachausgabe von Linux werden, auch wenn die noch einen weiten Weg hat.

Der Vorteil von Piper ist die komplett lokale Verarbeitung. Es ist zudem auch super schnell, variabel und kann in mehreren Sprachen benutzt werden. Leider fehlt dem TTS System noch jede Form von Betonung durch Satzzeichen, etwas, daß andere TTS wie das von Google oder Mary schon lange beherrschen.

Carola Integration

Das neueste Carola Paket v1.19 hat bereits die nötigen Konfigurationen und den Sprachbefehl mitbekommen. Außerdem könnt Ihr die Piper-RPMs auch im PVA Repo finden. Wer das selbst von Hand nutzen will, kann sich die Files von Github ziehen.

Wenn man eine „nicht-repo“ Version von Carola pimpen will, müßte man die Github-Dateien nach /usr/local/share so installieren:

piper
├── espeak-ng-data
├── libespeak-ng.so -> libespeak-ng.so.1.1.51
├── libespeak-ng.so.1 -> libespeak-ng.so.1.1.51
├── libespeak-ng.so.1.1.51
├── libonnxruntime.so.1.14.1
└── piper
piper-voices
├── voice-de-eva_k-x-low
├── voice-de-karlsson-low
├── voice-de-kerstin-low
├── voice-de-pavoque-low
├── voice-de-ramona-low
└── voice-de-thorsten-low

und dann das piper-say Script (im PVA Github Repo) benutzten: /usr/local/sbin/piper 

#!/bin/bash

NAME=$(mktemp)
TEMPO=0.95

if [ "$VOICE" == "" -o "$VOICE" == "de" ]; then
#VOICE="de-thorsten-low"
#VOICE="de-eva_k-x-low"
#VOICE="de-karlsson-low"
VOICE="de-kerstin-low"
#VOICE="de-pavoque-low"
#VOICE="de-ramona-low"
fi

TEXT="$1"

if [ "$NAME" != "" ]; then

   TEXT=$(echo "$TEXT" | sed -e "s/ch/sch/g" -e "s/ssch/sch/g" | tr -d "\n" )
   echo "$TEXT" | /usr/local/share/piper/piper -m /usr/local/share/piper-voices/voice-$VOICE/$VOICE.onnx -f $NAME 2>/dev/null
   play $NAME tempo $TEMPO 2>/dev/null
   rm -f $NAME
fi

Die kleine Kompensation:

TEXT=$(echo „$TEXT“ | sed -e „s/ch/sch/g“ -e „s/ssch/sch/g“ | tr -d „\n“ )

ist leider nötig, weil wir ja nicht dauernd ICK hören wollen und weil Piper ein entscheidenden Bug hat:

Wenn es auf ein LF im Text trifft, fängt es hinter dem letzten LF erst an zu arbeiten. Ihr könnt Euch vorstellen, was passiert, wenn man Ende vom Text ein „LF“ steht? Genau ..“kritsch“ und das wars 😀

Quelle: https://github.com/rhasspy/piper

Wie komme ich ans Repo dran?

PVA: Carola hat Ihr eigenes Repo bekommen

 

PVA: Die GTTS spricht jetzt anders

Schock in der Morgenstunde: Carola klingt nicht mehr nach Carola.

PVA: Die GTTS spricht jetzt anders

Mit Entsetzen habe ich heute morgen feststellen müssen, daß Google die Spracherzeugung von GTTS geändert hat und das nicht zum Besseren, sondern zurück in die Steinzeit 🙁

Der ganze Charakter der Stimme hat sich geändert, da die zugrundliegende Technik offensichtlich geändert wurde. Die Stimme ist jetzt nicht mehr natürlich, sondern erinnert wieder ganz stark an Pico2Wav.

Da wir beim PVA die erzeugten Texte Cachen gibt es jetzt natürlich die kuriose Situation, daß neue Sprachausgaben anders klingen als die bisherigen. Leider gibt es keine Einstellung, mit der man das ändern könnte, jedenfalls nicht offiziell.

Man könnte zwar über Google’s Cloud System an die Stimme in alter Qualität kommen, und andere, aber das wäre nicht mehr „free“ wie bei gTTS. Es würden sich zwar nur Cents am Tag ansammeln und die Kosten könnte jeder locker stemmen, aber ich denke, es wird Zeit Mimic3 auf Fedora umzusetzen.

Da sind auch rudelweise gute Stimmen dabei.

Falls das mit der Google Cloud einer braucht:

curl -X POST https://texttospeech.googleapis.com/v1beta1/text:synthesize -d ‚{„audioConfig“: {„audioEncoding“: „LINEAR16″,“effectsProfileId“: [„medium-bluetooth-speaker-class-device“],“pitch“: 0,“speakingRate“: 1.23},“input“: {„text“: „Testsatz für die 2023 eingeführte Stimme.“ }, „voice“: {„languageCode“: „de-DE“,“name“: „de-DE-Wavenet-A“}}‘ -H „Authorization: Bearer $(gcloud auth application-default print-access-token)“ -H „Content-Type: application/json; charset=utf-8“

Da muß Eurer Key hin.

PVA: Carola trifft auf ChatGPT 4

Na, heute schon den Mount Everest bestiegen? Wo war der doch gleich noch mal? Kein Problem mehr für Carola.

PVA: Carola trifft auf ChatGPT 4

Die neueste Funktionserweiterung für Carola erlaubt die Integration von ChatGPT in Euren Alltag. Natürlich nur, wenn ihr das wollt, denn einfach so ist weder aktiviert noch funktional. Ihr braucht nämlich einen eigenen API Key von open.ai . Sofern Ihr willens seid, irgendeine SMS fähige Telefonnummer anzugeben, ist das nur eine Sache von Minuten.

Im neusten GitHub Stand ist alles drin, was Ihr dazu braucht. Z.Z. ( 26.3. 15 Uhr ) ist Github allerdings gerade am zusammenbrechen, da müßt Ihr warten bis das wieder da ist 😉

Einrichtung ChatGPT

Im Terminal startet Ihr einmal ai.py und folgt der Anweisung. Alternativ könnt Ihr auch das „chatgpt“ Script in /usr/local/sbin/ so ändern, daß der API KEY per Umgebungsvariablen übermittelt wird. Eure Wahl.

Jetzt passen wir noch die Defaultkonfig an. Abweichend von den Einstellungen die ansonsten in der Datei sind, ändert Ihr das hier:

chatgpt:“enable“,“true
chatgpt:“mode“,“keyword
chatgpt:“keyword“,“emma

enable“ dürfte selbsterklärend sein 😉 Den Modus muß ich aber kurz erklären, da gibt es drei von: freetalk, keyword und gapfiller . Da alle Modi private Informationen an externe Datenkraken übermitteln, ist das Modul per se deaktiviert.

Im Freisprechenmodus ( freetalk ) wird alles im Raum, das keine Reaction oder nicht als Kommando identifiziert ist, genommen und an ChatGPT übermittelt. Es ist also die natürlichste Form mit dem Botsystem zu sprechen. Da aber alles an Open.AI übermittelt wird, ist es der datenschutztechnisch bedenklichste Modus von allen.

Im Schlüsselwortmodus (keyword) muß man ein selbstgewähltes Schlüsselwort benutzen, ich habe da mal „emma“ genommen, weil das in normalen Sätzen nicht vorkommt, aber das könnt Ihr machen, wie Ihr wollt 😉 Datenschutztechnisch ist es der beste Modus, weil nichts ungewollt rausgeht.

Der ggf. beste Kompromiss zwischen Datenschutz & Handhabung ist der Lückenfüllermodus. Wenn Eurer Sprachassistent über sein Schlüsselwort mit einem Kommand beauftragt wird, es aber nicht erkennt, z.b. weil es gar keins ist, wird ChatGPT gefragt. Es füllt also die Lücke von Kommandos auf. Das hat den Vorteil, daß man nur ein Schlüsselwort braucht und es auch genannt sein muß. Es wird also nicht alles Gesprochene automatisch bei Open.ai landen. Nachteil: Wenn Euch eine Anweisung z.B. „spiele video xxxxxx ab“ durch die Lappen geht, weil die Spracherkennung Mist gemacht hat, dann landet das auch bei Open.AI. Das könnte peinlich enden 😉

Startet PVA neu und fertig. Viel Spaß damit 🙂