VoxForge
VoxForge
kurzes Update: bin nun mit allen im Dokument von Binh genannten Submissions durch - ich habe jeweils allerdings nicht nur die genannten einzelfiles sondern jeweils mindestens gleich die ganze Submission (typischerweise 10 Wavs) oder alle Submissions aus der Quelle durchgehoert - dazu noch ein paar meiner eigenen (und ja, auch da habe ich Fehler gefunden :o) )
Aktuell sieht die Statistik so aus:
[guenter@dagobert speech]$ ./audio-stats.py
STATS: total 24576 files, total length: 2070.30min
STATS: reviewed 895 files, reviewed length: 64.29min
STATS: good 652 files, good length: 45.73min
Ich finde die Vorstöße und die Initiative hier gut, habe aber noch ein paar Vorschläge in Form von Senf:
Die Erklärung zum Attribut "noise level" finde ich nicht ganz eindeutig. Im Hintergrund kann ein Radio auch kaum hörbar dudeln. Wie wird das File dann klassifiziert? "background speakers" oder "low"? Ich glaube ich weiß was gemeint ist aber vielleicht gibt es eine eindeutigere Formulierung für die Beschreibung?
Beim "audio level" ist es ähnlich: Die Sprachaufnahme kann sehr laut und dennoch verzerrt sein. Ich würde Punkt drei einfach streichen und dafür plädieren, dass man bis zur Unkenntlichkeit verzerrte Sprachdateien gar nicht erst in die Datenbank aufnimmt.
Zu "pronunciation": Über die Abgrenzung von Hochdeutsch zu Akzent kann man sich wunderbar streiten. Wenn wir Tagesschau-Maßstäbe ansetzen, hat wahrscheinlich jeder von uns einen Akzent. Mein Vorschlag wäre dieses Variantenreichtum der deutschen Sprache mitzunehmen und nur zwischen Hochdeutsch und Dialekt differenzieren. Da wird's noch genug Potential für Unklarheiten und Streit geben. Sonst haben wir hier (meiner Meinung nach) eine Scheingenauigkeit im System.
Vielen Dank trotzdem für diesen Vorstoß. Nichts ist mehr Wert als die anfängliche Initiative. Weiter so!
Viele Grüße
Grilli
> Die Erklärung zum Attribut "noise level" finde ich nicht ganz eindeutig.
> Im Hintergrund kann ein Radio auch kaum hörbar dudeln.
> Wie wird das File dann klassifiziert? "background speakers" oder "low"?
kommt wirklich auf den jeweiligen Fall an - "low" wuerde ich eher nicht nehmen, eher zwischen "noticable" oder "background music/other speakers" schwanken.
Aktuell stelle ich mir an solchen Stellen immer die Frage, ob ich so eine Submission in mein Modell einrechnen wollen wuerde oder nicht - "1 - noticable" akzeptiere ich noch fuer mein Modell, "2 - background music/other speakers" lasse ich weg.
Wenn es aber Vorschlaege fuer besser formulierte Kriterien gibt: nur her damit :)
> Beim "audio level" ist es ähnlich: Die Sprachaufnahme kann sehr laut
> und dennoch verzerrt sein. Ich würde Punkt drei einfach streichen
> und dafür plädieren, dass man bis zur Unkenntlichkeit
> verzerrte Sprachdateien gar nicht erst in die Datenbank aufnimmt.
das Konzept "nicht in die Datenbank aufnehmen" gibt es in meinem Flow nicht - ich nehme alle Submissions in einem vollautomatischen Prozess in meine DB auf. Also konkret rsynce ich erst die aktuellen Daten von Voxforge und gleiche die dann mit meiner DB ab. Was fehlt, lege ich in der Datenbank an - dabei konvertiere ich FLAC auch gleich nach WAV und mache daraus ein MFCC. Ausserdem bestimme ich jetzt auch die Laenge der Submissions in Samples (aus dem MFCC) und lege sie in der Datenbank ab - das Feld "num_samples" ist jetzt auch bei meinem CSV Export dazugekommen - ich selber verwende es fuer die Statistik.
Fuer mein Modell in Betracht ziehen wuerde ich nur, was Audio Level 0 (good) oder 1 (low) hat - 2 (very low) lasse ich genauso weg wie 3 (distorted) - was eigentlich eh nichts anderes bedeutet als "auf die eine oder andere Weise schlicht kaputt"
> Zu "pronunciation": Über die Abgrenzung von Hochdeutsch zu Akzent kann man sich wunderbar streiten.
Ja, das ist mir beim reviewen auch schon aufgefallen, dass da manches grenzwertig ist - insbesondere kann es passieren, dass der Akzent des Sprechers nur bei manchen Submissions ueberhaupt zu Tage tritt.
Spielt fuer mich im Moment allerdings eh keine Rolle, ich nehme beides in mein Modell mit auf - nur Dialekt und (neu) "Error" (fuer Lesefehler - manche Submissions enthalten tatsaechlich aehms und ehs oder die Leute fangen mittendrin nochmal ein Wort von vorne an) fliegt raus.
Ich wuerde vorlaeufig an meinem Datenmodell nichts mehr aendern wollen, sondern erstmal weiter reviewen und Erfahrungen sammeln - insbesondere, wie gut oder schlecht sich darauf aufbauend dann Audiomodelle rechnen lassen.
Gefällt mir soweit ganz gut. Was genau bezeichnet audio level jetzt? Qualität, Lautstärke?
Sehe ich das richtig: die Unterschiede von deinem letzten Modell zu deinem geplanten Modell wären
1. korrigierte Transkriptionen und
2. mangelhafte Quellen aussortiert?
Und am wichtigsten: ist es dir lieber, wenn dir jemand hilft, oder sollen wir dich erstmal in Ruhe werkeln lassen?
> I'm actually working on something similar in English.
hey! now this is really good news :) I have been thinking that there is absolutely nothing german-specific about the tools I am building - it would be cool to have this infrastructure setup for other models as well.
I have decided to push my code as-is on github so anybody interested can have a look:
https://github.com/gooofy/voxforge
this is just a snapshot - many things work, others are broken. in particular the audio model generation script is not updated to the latest DB model yet (I hope to be able to do that on the weekend).
I will also create database dumps and other kinds of data exports and make them available on the web somewhere - just need to find the time to do it.
BTW: I just realized I have not decided on the license of my code yet - is there anything that is particularly suitable for voxforge? personally I don't really care as long as it qualifies as free software, so GPL, LGPL, BSD, MIT ... all works for me - just want to create as little friction as possible here.
> I didn't plan on classifying the dialect or accent of each region as
> American's have many accents as I'm sure German's do as well.
me neither :o) - not sure why this issues pops up over and over again. all I have is a simple numeric field which says "pronounciation" and this field in my current interpretation is more or less boolean, meaning
0: clean, 1: accent
is "OK", while
2: dialect, 3: error
is "broken".
> Question for you, are you going to make a webform to do the approvals?
actually I already have that running - see audio-transcribe.py for the server part and web/html/* for the client part (jquery/javascript).
this is what it looks like (roughly - screenshot is from an earlier prototype):
https://twitter.com/_Gooofy_/status/421594790220685312/photo/1
> If so how are you going to show the wavform images for each .wav file?
right now: not at all. why would you want to display waveform images? i have been considering it but the only use I could see was determining the audio level - but that I can also decide by simply listening to the submission.
anyway, it would definitely look cool :o) - maybe such a thing could be rendered (and cached) on the server using GD and transferred to the client as a simple image?
https://github.com/Solomoriah/gdmodule
http://stackoverflow.com/questions/3059089/how-to-get-wav-samples-from-a-wav-file
> For assurance I also thought about having multiple people review the
> submissions, and the database can keep record of it. The reason would be so
> we can see if 1 person disagrees with another what do you do? What if 1
> reviewer thought it was ok, and another one didn't?
I have been thinking along these lines as well :)
I am pretty scared of running a public multi-user web application (and probably we'd have to implement mobile frontends/apps as well if we want this effort to appeal to many people nowadays) - a lot of work, a lot of responsibility.
I think the obvious way to address this is to have a central database which can store multiple reviews for each submission, just like you said. we could then weight those submissions - e.g. an anonymous user has weight "1", an authenticated user has weight 2-10 depending on how old the account is (freshmen have weight 2, long-term users weight 10), maybe multiplied by a "karma" value for each account which could take into consideration how active the user is and how well past reviews have matched what other users think.
anyway, it would require considerable effort implementing all this and setting up (and maintaining) the infrastructure for that.
right now, while I am just tinkering on my own, I am going for a different approach - I am just running my own, local database, publish my code and publish the data I have - so anybody who is interested can set up his or her own database, import my data and start reviewing and publish their results. we could then have merge scripts which import those results - effectively running a git-style distributed db repo. also contributors are not forced to agree with my DB schema - they can use whatever tools they want to review submissions - one user has sent me an OpenDocument file that contained plain text comments on submissions - which I could add to my DB (in a manual process, of course) without any problems.
actually .... I wonder if we could use git to collect and merge such DB dumps in sensible way??
anyway, I am not opposed to doing this properly, not at all. but before we dive into such a huge effort we need to be sure we have enough people and resources to see this through.
Lautstaerke
ganz genau - und natuerlich: das modell ist erstmal viel viel kleiner,
weil ja momentan nur ein kleiner teil der submissions reviewed ist,
konkret:
STATS: reviewed 1330 files, reviewed length: 84.56min
STATS: good 1086 files, good length: 65.97min
4,4% der files aktuell
ich habe jetzt endlich meine daten alle exportiert und auf einen
webserver gepackt:
http://goofy.zamia.org/voxforge/de/
modelle, logs, exports, dumps - alles da.
bin sehr froh um jeden beitrag, jeden hinweis, jeden datensatz - und
natuerlich umgekehrt gerne bereit, meine daten zur verfuegung zu
stellen.
ich hoffe, dass ich nun alles vollstaendig hochgeladen habe - code
ist, wie gesagt, auf github:
https://github.com/gooofy/voxforge
aktuell wuerde mich - natuerlich neben reviews und transcripts in
jeder form - auch kommentare und hinweise zu meinem modell und der
art, wie ich es erzeuge und evaluiere interessieren.
ist alles noch sehr sehr frisch - aktuell komme ich auf eine
wortfehlerrate von 62% was mir sehr viel erscheint - vielleicht mache
ich grundsaetzlich etwas falsch? sollte parameter anders setzen? oder
ist das mit so wenig material einfach das, was man erwarten sollte? :)
bin mir auch nicht sicher, welche form der evaluierung an diesem punkt
ueberhaupt sinnvoll waere - ich berechne im moment ein statistisches
sprachmodell einfach ueber die prompts, die im modell drin sind -
vielleicht ist das einfach im moment an der stelle noch viel zu wenig
material? sollte ich eher julian nehmen mit einer kleinen grammatik
ueber die prompts und damit evaluieren?
ein anderer spannender ansatz waere, mal alternativ mit sphinxtrain
ein modell zu erzeugen und mit sphinx/pocketsphinx zu testen, was
damit zum vergleich rauskommt.
Das mit der Fehlerrate hängt stark davon ab, was du evaluierst. Beispiel: Unsere Standardtestbatterie arbeitet mit Interviews auf Messegelände, also sehr schlechte Umgebung. Und wir haben im Schnitt Erkennungsraten von 25% selbst mit unserer optimierten PocketSphinx-Variante.
Ich mache mal ein paar Vorschläge, basierend darauf, wie wir das hier machen:
1. Nimm ein vorhandenes Standardmodell und schaue, ob sich die Ergebnisse bei der Hinzunahme deines Materials eher verbessern oder verschlechtern. Dann brauchst du aber ein separates akustisches und Sprachmodell.
2. Wir könnten dein Material ergänzend durch unsere Testbatterie jagen. Das können wir aber erstens nicht ständig machen und zweitens benötigen wir dazu ein alternatives akustisches Modell. Bestenfalls also in einigen Wochen, schlimmstenfalls gar nicht.
Wir könnten folgendes Material für PocketSphinx zur Verfügung stellen:
- Sprachmodell: wir haben eine für Pocketsphinx formatierte Version des German Parole Corpus (siehe http://ota.ahds.ac.uk/desc/2467 ).
- Konfigurationsdatei: wir können dir sagen, welche Parameter wir bei uns verwenden. Vielleicht hilft das ja auch bei dir.
Erstmal: sorry fuer meine spaete Antwort - die Hinweise waren sehr nuetzlich, ich wollte sie aber erst umsetzen/ausprobieren, ehe ich mich aeussere.
Der Hinweis mit dem Parole-Corpus war Gold wert, kannte ich bisher gar nicht - dieser Corpus ist auf jeden Fall sehr viel ausgewogener als der europarl-Corpus, mit dem ich bisher experimentiert habe. Ich habe mir jetzt ein Skript basierend auf nltk zusammengehacked, welches daraus Saetze (oder was nltk dafuer haelt ;) ) extrahiert
https://github.com/gooofy/voxforge/blob/master/lm-parole.py
das kombiniere ich nun mit den Saetzen aus den Prompts und generiere mir damit ein language Model mit srilm:
rm -f gt*.params
ngram-count -order 2 -text all.sent -unk -gt1 gt1.params -gt2 gt2.params
ngram-count -order 2 -text all.sent -unk -gt1 gt1.params -gt2 gt2.params -lm german.arpa -vocab wlist.txt
rm -f gt*.params
ngram-count -order 4 -text all.rev -unk -gt1 gt1.params -gt2 gt2.params -gt3 gt3.params -gt4 gt4.params
ngram-count -order 4 -text all.rev -unk -gt1 gt1.params -gt2 gt2.params -gt3 gt3.params -gt4 gt4.params -lm german-rev.arpa -vocab wlist.txt
mkbingram -nlr german.arpa -nrl german-rev.arpa german.bingram
Daneben generiere ich nun auch ein DFA/Grammatikbasiertes Modell, in dem ich einfach die haeufigsten 100 Prompts zu einer "Grammatik" verbinde
http://goofy.zamia.org/voxforge/de/grammar/eval.grammar
wenig realistisch, aber eben mal ein Versuch zu evaluieren, wie gut das Modell fuer command+control Anwendungen taugen wuerde.
Zur Evaluation jage ich momentan einfach alle relevanten, guten Submissions durch Julius und vergleiche, was erkannt wuerde mit dem, was der Prompt war und berechne die Edit-Distance, die ich dann als Wortfehlerrate ausgebe.
Zum aktuellen Stand: Ich habe 8016 Submissions reviewed (28% des voxforge Materials), das sind 544.56min, davon habe ich 470.30min fuer verwandbar gefunden. Das Lexikon fuer das Modell umfasst aktuell 6206 verschiedene Woerter (ich nehme aktuell nur die Woerter, die mindestens einmal in den verwendeten Submissions vorkommen).
Das Audiomodell daraus liefert mit dem statistischen Sprachmodell aktuell eine Wortfehlerrate von 72,8 % (ich vermute, mehr kann man aktuell einfach nicht erwarten angesichts der vielen verschiedenen Sprecher und demgegenueber, wie wenig Material im Modell eingerechnet ist) - mit dem Grammatikbasierten Modell hingegen liegt die Wortfehlerrate bei 27,4%.
Details siehe:
http://goofy.zamia.org/voxforge/de/audio-stats.txt
PS: Ich habe saemtliche Zahlen nun durch ihre Umschreibungen ersetzt in den Prompts - als "VIER" statt "4" und "NEUNZEHNHUNDERTNEUNZIG" satt "1990" - vielen Dank an binh fuer die Anregung, das ist wirklich eine sehr sinnvolle Massnahme! :)
