> qq-Phonem

Was ich meine ist der "glottal stop" im englischen, im Deutschen "stimmloser glottaler Plosiv genannt" (mehr dazu hier: http://de.wikipedia.org/wiki/Stimmloser_glottaler_Plosiv ). Am Beispiel der Wörter "Veranstaltung" und "Veranda" kann man das sich gut veranschaulichen. Nach dem "Ver" bei "Veranstaltung" setzt man beim Sprechen quasi kurz ab (ist linguistisch jetzt natürlich nicht ganz sauber erklärt) während bei "Veranda" eher verschliffen wird. Der glottale Plosiv ist auf jedenfall hier http://goofy.zamia.org/voxforge/de/dict/dict-ipa.txt noch häufig zu finden.

Im Voxforge-PocketSphinx-Dictionary wird das meistens als qq-Phonem kodiert. Ich bin nun schon auf einige Paper gestoßen, wo der glottal stop weggelassen wurde. Man kann sich darüber streiten, ob ein Phonem für den glottalen Plosiv innerhalb des Wortes Sinn macht oder nicht. Meiner Meinung nach kann man ihn ruhig weglassen, so dass der glottale Plosiv einfach den benachbarten Phonemen zugeordnet wird. Ich würde mal vermuten, dass dieser Laut in der Spektralansicht auch gar keine wirkliche eigentliche Charakteristik aufweist. Was definitiv keinen Sinn macht ist allerdings den glottalen Plosiv am Wortanfang mit aufzuführen.

> Was müsste man denn da tun?

qq-Phonem am Wortanfang einfach per Regex rauslöschen. Es kann aber sein, dass du mit deinem Skript dieses Phonem bereits ignorierst und hier auch überhaupt kein Problem entsteht.

Was mir noch aufgefallen ist beim stichprobenartigen Durchhören: Die meisten Sprecher vernuscheln die "en"-Endungen. Nehmen wir mal das Wort "Statuten". Steht im Dictionary (XSAMPA) mit "Sta-'tu:-t@n". Das ist eine Aussprache, die du wahrscheinlich höchstens noch bei Tagesschausprechern oder Schauspielern, die ein entsprechendes Sprechtraining durchlaufen haben, hören können wirst. Die meisten umgangssprachlichen Sprecher sprechen aber "Sta-'tu:-tn". Ich gebe zu, das ist das Sahnehäubchen. Aber hier könnte man auch relativ leicht per RegEx ran. Stellenweise taucht das vernuschelte "en" aber auch mitten im Wort auf.

> da wollte ich versuchen, ein entsprechendes tool zu bauen

Finde ich eine prima Idee! Es gibt ja bereits Open-Source-Transkriptionstools, die das Ganze erleichtern und dann die transkribierten Texte mit Zeitstempel im XML-Format speichern. Wenn man es schaffen könnte das zu nutzen, im Anschluss per Skript über die XML-Datei zu gehen, zu schneiden (mittels sox oder so) und als Trainingsdateien für Sphinx, HTK oder was auch immer aufzubereiten, dann hätte man ne ziemlich komfortable Lösung, mit der man auch massenhaft Hörbücher transkribieren könnte.

Ein so ein Projekt, dass ich mir mal angeschaut habe, ist TranscriberAG

http://transag.sourceforge.net/

Leider läuft das derzeit nicht auf meinem Debian-System. Ich habe mal einen Abend lang versucht es aus den Quellen zu kompilieren aber es gab' da ein paar Abhängigkeiten, die ich auf die Schnelle nicht auflösen konnte. Ggf. läuft aber die Windows-Version noch. Ansonsten müsste man die Entwickler mal anschreiben. Ich hoffe ich mache da kein zu großes und zu kompliziertes Fass auf. Aber wenn man derart große Mengen an Audiomaterial transkribieren möchte, ist ein kleines Tool vielleicht ganz hilfreich.

Viele Grüße

Grilli

Habe das Thema Audiobooks als Quelle fuer neues Material man etwas genauer untersucht. TranscriberAG sieht beeindruckend aus - ich muss aber sagen, dass das nicht ganz die sorte Tool ist, die mir vorschwebt.

Ich dachte da eher an einen Satz von Kommandozeilentools - ohne aber sagen zu wollen, dass das praktikabel ist.

Was ich mir zwischenzeitlich ergoogelt habe (immer mit dem Ziel, moeglichst korrekt und einfach Librivox Audiobuecher zerlegen zu koennen):

http://www.voxforge.org/home/dev/autoaudioseg

enthaelt ganz gute Ansaetze - aehnlich wie dort beschrieben ist denke ich die Hauptarbeit erstmal, den Text aufzubereiten und das Lexikon um die fehlenden Woerter plus Aussprache zu ergaenzen, ehe man ueberhaupt das Audiomaterial an sich zerlegen kann - ich denke, dafuer koennte man ein erstes Tool bauen.

Fuer die Segmentierung an sich gibt es bei den CMU Sphinx Leuten einige Tools und Hinweise, z.B.

http://cmusphinx.sourceforge.net/wiki/speakerdiarization

http://cmusphinx.sourceforge.net/wiki/longaudioalignment

Pocketsphinx und Audacity koennten auch gute Dienste leisten - Pocketsphinx kann z.B. ein Segmentation File ausgeben in dem dann Zeitstempel drinstehen, an welcher Stelle welches Wort erkannt wurde - daraus koennte man ein Label-File fuer Audacity machen koennte fuer Kontrollzwecke oder zur leichteren Nachbearbeitung, falls noetig.

Nur so meine Gedanken - und ich wollte die Links mal notiert haben :)

Wir haben unser Material mal an folgender Adresse gesammelt:

http://messe2media.com/files/aktMaterial/

Das umfasst Sprachmodell, akustisches Modell, Wörterbuch und Pocketsphinx-Aufruf.

Unser Aufruf wurde lange optimiert, allerdings auf umgangssprachlichem Fließtext mit sehr umfangreichem Wörterbuch. Außerdem habe ich unsere Aufrufe der Techniken MLLR und MAP rausgenommen, weil ihr wahrscheinlich nicht in der Lage seid, den Sprecher ein paar Trainingssätze vorab sagen zu lassen. Bei Interesse kann ich das nachliefern, der Ablauf ist allerdings ziemlich umfangreich.

Hallo,

mir fiele da nur kurz ein, dass man die Audiodateien bei zunehmender Datenbankgröße vielleicht besser über einen Hash-Wert identifiziert so wie das bei manchen P2P-Tauschbörsenprogrammen der Fall ist. Es kann ja immer mal passieren, dass beim Herumkopieren irgendwelcher Daten etwas durcheinander kommt und irgendetwas nicht mehr an seinem Platz ist. Vielleicht nur so als Sahnehäubchen für ne Implementation, die später von vielen zur Klassifizierung der Audio-Dateien genutzt werden kann.

Sind die Erkenntnisse oder Entscheidungen hier eigentlich soweit gediehen, dass man sie auf der DEV-Seite von voxforge einstellen könnte? Hier wurde ja schon viel Gutes gesagt. Und auch guenters Vorstoß ist ja Gold wert. Ich fürchte nur, dass diese Früchte der Erkenntnis im unvermeidbaren Kreuz-und-Quer dieses Threads untergehen werden.

Viele Grüße

Grilli

Ohja, das mit dem Hash-Wert ist eine sehr gute Idee! Mir sind selber auch schon Pannen passiert beim Umgang mit den Dateien.

Es kommt allerdings noch dazu, dass die Dateien ja waehrend der Modellrechnung konvertiert werden - ich gehe dabei in zwei Schritten vor, erst konvertiere ich nach 16 kHz, danach nach MFCC. Die 16kHz Dateien hebe ich nicht auf, wohl aber die MFCC Dateien, um bei spaeteren Laeufen Zeit zu sparen - es waere gut, einen Mechanismus zu haben, der auch die MFCC Dateien ueberwacht und damit sicherstellt, dass diese sowohl zu den WAVs/FLACs als auch zu den Prompts passen.

DEV-Seite von VoxForge: das halte ich fuer eine sehr gute Idee! (Freiwillige? :-D ). Ich muss gestehen, ich weiss sehr wenig ueber VoxForge - sind das Wikis, in die Jeder schreiben kann oder wie ist das? Wie funktioniert das mit der DB/Softwareinfrastruktur, gibt es aktive Projekt-Admins, Entwickler, die man kontaktieren koennte, wenn man da ein Stueck zentrale Infrastruktur aufbauen wollte?

Noch kurz ein Statusupdate von mir: Ich bin inzwischen kraeftig am Modell-Rechnen, Audio aufnehmen und natuerlich auch am Reviewen. Ich schiebe immer mal wieder meine aktuellen Modelle und Dumps auf

http://goofy.zamia.org/voxforge/de/

hoch, falls jemand Interesse daran hat. Das aktuelle Modell hat diese Abmessungen:

STATS: total     25170 files, total    length:  2107.07min
STATS: reviewed   4706 files, reviewed length:   342.87min
STATS: good       4241 files, good     length:   307.94min

> Nachverfolgungsmöglichkeit für WAV (original), WAV (16 kHz), MFCC

Das ist sehr, sehr anspruchsvoll. Das eine lässt sich nicht eindeutig aus dem anderen Errechnen. Beim Downsampling wird wahrscheinlich jeder Algorithmus ein Bit ein bisschen anders setzen. Die MFCCs sind ja auch nochmal von diversen Parametern abhängig. Dementsprechend werden sich die Hashes für die beiden letztgenannten Dateien von Anwender zu Anwender unterscheiden. Und identifiziert werden soll ja lediglich die Originaldatei, weil diese ja auch bewertet/klassifiziert wird.

Man könnte einen Kompromiss vorsehen und drei verschiedene Hashes verwenden. Man kann das ja vielleicht in der SQL-Tabelle namentlich abgrenzen: source_hash, corresponding16khz_hash und correspondingmfcc_hash. So dass irgendwie deutlich wird, dass die letzten beiden noch temporär sind und der wichtige Identifikator der source_hash ist.

Und wo du das erwähnst: Der Hash sollte sich bei Sound-Dateien bestenfalls auch nur auf die Rohdaten beziehen, damit ein Ändern des Headers und der damit verbundenen Tags (ID3, Hastenichgesehen...) den Hash nicht beeinflusst.

> Wiki? Freiwillige vor!

Grad hab' ich wenig Zeit. Müsste sich aber nächste Woche entspannen. Es geht ja nur mal darum die Erkenntnisse rauszulesen, reinzuschreiben und evtl. andere nochmal drübergucken zu lassen. Kann ich machen. Erinnert mich vielleicht nochmal dran. Muss dann mal schauen, ob ich überhaupt Schreibzugriff aufs Wiki hab'.

Ich bin leider auch gerade sehr eingespannt, sonst hätte ich längst ein bisschen Daten eingestellt. Sollte aber ebenfalls nächste Woche besser werden. Sollte jemand eine Dev-Seite erstellen, schaue ich gerne nächste Woche mit drüber (kenne mich leider mit Voxforge auch wenig aus).

Ich hab mal kurz drüber geschaut. Dev Seiten sind für unsere Zwecke eher ungeeignet.

Es sind eher Trac Ticket Systeme und dienen zur Entwicklung von Code. Wir bräuchten aber erstmal eine vernüftige Austauschplattform wo man die Thread etwas übersichtlicher darstellen lassen kann

So. Ich bin wieder da. Hier hat sich ja schon was getan. Exisitiert schon eine Webseite wo man sehen kann, welche Audio Datein kontrolliert wurden ?

Ich hab die Text mal überflogen. Und es stimmt. Es wird ein wenig unübersichtlich