Belegarbeit (.pdf - 2.3 MB) - Technische Universität Dresden

TECHNISCHE UNIVERSITÄT DRESDEN 

FAKULTÄT INFORMATIK 

INSTITUT FÜR SOFTWARE- UND MULTIMEDIATECHNIK 

PROFESSUR FÜR COMPUTERGRAPHIK UND VISUALISIERUNG 

PROF. DR. STEFAN GUMHOLD 

Großer Beleg 

Spracheingabe für VR Anwendungen 

Jan Richter 

(Mat.-Nr.: 2928921) 

Betreuer: Prof. Dr. Stefan Gumhold 

Dresden, 28. Juli 2008

Aufgabenstellung 

In gängigen VR Umgebungen interagiert der Benutzer mit Eingabegeräten, die für die Eingabe von dreidimensionalen 

Parametern wie Position und Orientierung geeignet sind. Für die Navigation in graphischen 

Benutzungsschnittstellen sind diese Eingabegeräte jedoch nicht optimal geeignet. Eine mögliche 

Problemlösung ist der Einsatz von Spracheingabe für die Bedienung graphischer Benutzungsschnittstellen 

in VR-Umgebungen. Ziel der Belegarbeit ist es, den Stand der Technik von Spracherkennungssystemen 

zu ermitteln und frei verfügbare Lösungen für den Einsatz in VR Umgebungen zu evaluieren. Im 

speziellen sind die folgenden Punkte zu erarbeiten: 

• Vergleichende Zusammenstellung existierender Spracherkennungs- und Spracheingabesysteme 

• Evaluation und Vergleich von frei verfügbaren Lösungen in Bezug auf: 

– Einbindung in eine Echtzeitumgebung, d.h. wie ist die Aufnahme von Audiodaten in Echtzeit 

gelöst 

– Latenzzeiten bei der Erkennung 

– Art und Flexibilität der Programmierschnittstelle 

• Abstraktion der Schnittstelle zur Integration von Spracherkennungssystemen in C++ 

• Implementierung der Schnittstelle für ein ausgesuchtes Spracherkennungssystem 

• Optional sollen die Bibliotheken zum Steuern der graphischen Schnittstellen im C++-Framework 

des Lehrstuhls für Computergraphik und Visualisierung integriert werden und an einer Beispielanwendung 

getestet werden.

1 

Inhaltsverzeichnis 

1 Einleitung 6 

2 Allgemeine Angaben zu Spracheingabesystemen 7 

2.1 Systemarten und Anwendungsgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.1.1 Einzelworterkenner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.1.2 Spracherkenner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.1.3 Sprechererkenner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2.1 Wortschatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2.2 Realisierung der Spracheingabe . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.2.2.1 diskrete Sprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.2.2.2 kontinuierliche Sprache . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.2.3 Erkennen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.2.3.1 sprecherabhängiges Erkennen . . . . . . . . . . . . . . . . . . . . . . 11 

2.2.3.2 sprecherunabhängiges Erkennen . . . . . . . . . . . . . . . . . . . . 11 

2.3 Realisierung der Spracheingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.3.1 Spracheingaben erkennen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.3.1.1 Push to Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.3.1.2 Sprachsignal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.3.2 Mikrofon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.3.2.1 stationäre Mikrofone . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.3.2.2 mobile Mikrofone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

3 Allgemeiner Aufbau eines Spracherkenners 14 

3.1 Signalaufbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.1.1 Formale Vorverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.1.2 Spezielle Vorverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

3.2 Analyse und Merkmalsableitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2 

3.2.1 Analyseverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

3.2.2 Merkmalableitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

3.3 Klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

3.3.1 Lineare Streckung/Stauchung . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

3.3.2 Dynamic Time Warping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

3.3.3 Hidden Markov Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

3.4 Interpretation und Reaktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

4 Erhältliche Programme 23 

4.1 freie Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

4.1.1 Microsoft Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

4.1.2 CVoiceControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

4.1.3 XVoice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

4.2 kommerzielle Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

4.2.1 Dragon Naturally Speaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

4.2.2 iListen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

4.2.3 ViaVoice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

4.2.4 VoiceIt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

5 Frei verfügbare Spracherkenner 28 

5.1 Sphinx-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

5.1.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

5.1.2 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

5.1.3 Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

5.1.3.1 Front End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

5.1.3.2 Liguist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

5.1.3.3 Decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

5.2 Microsoft Speech API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

5.2.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

5.2.2 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

5.2.3 Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

5.3 jlab Speech Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

5.3.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

5.3.2 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

5.3.3 Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 

5.3.4 Vokabular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

5.3.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

6 Tests 41 

6.1 Worterkennungsrate für Sprachsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . 41 

6.1.1 Sphinx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 

6.1.2 JLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

6.1.3 SAPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

6.1.4 Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

6.2 Worterkennungsrate für Diktieranwendungen . . . . . . . . . . . . . . . . . . . . . . . 46 

7 Auswahl eines Spracherkenners 47 

8 Entwicklung einer Schnittstelle auf Basis der Microsoft Speech API 50 

8.1 Anforderungen an die Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

8.2 Begriffserklärungen im Zusammenhang mit der Schnittstelle . . . . . . . . . . . . . . . 51 

8.2.1 Die Grammatik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

8.2.2 Regeln und Menüs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

8.2.3 Der Befehl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 

8.2.4 Das Vokabular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

8.3 Eine Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 

8.3.1 Vokabular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 

8.3.2 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 

8.3.3 Programmieren der Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . 55 

8.3.3.1 main() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 

8.3.3.2 ExecuteCommand() . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

8.3.3.3 exit() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

8.4 Test der Schnittstelle mit Hilfe der Beispielanwendung . . . . . . . . . . . . . . . . . . 59 

9 Abschließende Betrachtungen 63 

9.1 Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

9.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

10 Glossar 67 

Literaturverzeichnis 72

4 

Abbildungsverzeichnis 75 

Tabellenverzeichnis 76

5 

Selbstständigkeitserklärung 

Hiermit erkläre ich, dass ich diese Arbeit selbstständig erstellt und keine anderen als die angegebenen 

Hilfsmittel und Quellen verwendet habe. 

Jan Richter

1. EINLEITUNG 6 

1 Einleitung 

’Ich konnte Sie leider nicht verstehen! Bitte wiederholen Sie Ihre Aussage.’ So oder so ähnlich klingt es 

wenn die freundliche Computerstimme am anderen Ende des Telefons, mich zum wiederholten mal nicht 

verstanden hat, obwohl ich doch extra deutlich gesprochen habe. Ein bekanntes Szenario und sicher auch 

einer der Gründe warum Dialogsysteme und Spracheingabesysteme im Allgemeinen in der Vergangenheit 

nicht ernst genommen wurden. 

Heutige Spracheingabesysteme arbeiten genauer, schneller und haben immer seltener mit derartigen Probleme 

zu kämpfen. Ihr Anwendungsgebiet ist weitläufig und beinhaltet unter anderem die Sprachsteuerung, 

das Lernen von Fremdsprachen, das Diktieren von Texten oder sogar Nutzerverifikation. Auch 

wenn Herstellerangaben wie 99Prozent Worterkennungsrate mit Vorsicht zu genießen sind, da sie häufig 

nur unter optimalen Testbedingungen erreicht werden, können Spracheingabesysteme eine große Arbeitserleichterung 

darstellen. 

In dieser Arbeit wird zunächst vorgestellt welche Arten von Spracherkennern existieren, welche Anforderungen 

bestehen und wie die Eingabe am besten zu realisieren ist. Danach wird der allgemeine Aufbau 

eines Spracherkenners beschrieben und seine einzelnen Elemente näher betrachtet. Später werden kurz 

einige kommerzielle und frei verfügbare Programme und ihre Anwendungsbereiche vorgestellt. Im Anschluss 

daran wird näher auf drei frei verfügbare Spracherkennungssysteme eingegangen, mit deren Hilfe 

man eigene Spracherkennungssoftware erstellen kann. Im drauf folgenden Kapitel werden diese Systeme 

hinsichtlich ihrer Erkennungsqualitäten getestet und eines davon für eine Schnittstelle ausgewählt. Im 

letzten Kapitel wird die Implementation diese Schnittstelle dokumentiert und eine Beispielanwendung 

beschrieben. Darauf folgt ein Test der Schnittstelle und es werde Vergleiche zu den früheren Testergebnissen 

gezogen.

2. ALLGEMEINE ANGABEN ZU SPRACHEINGABESYSTEMEN 7 

2 Allgemeine Angaben zu Spracheingabesystemen 

In diesem Kapitel wird zunächst ein Überblick über die verschiedenen Anwendungsgebiete für Spracheingabesysteme 

gegeben. Im zweiten Teil werden die verschiedenen Anforderungen an solche Systeme noch 

einmal näher betrachtet. 

2.1 Systemarten und Anwendungsgebiete 

2.1.1 Einzelworterkenner 

Einzelworterkenner gehören zu den einfacheren Spracherkennern. Sie realisieren nur ein sehr kleines 

Vokabular und die Spracheingabe erfolgt dabei diskret und meist sprecherunabhängig. Sie finden Anwendung 

bei Notschaltern, Ein- oder Ausschalter oder in einfachen Menüsteuerung. 

2.1.2 Spracherkenner 

Spracherkenner bilden das Hauptfeld der Spracheingabesysteme. Zu ihnen gehören Dialogsysteme, Diktiersysteme 

und Übersetzer, Sprachtrainer aber auch komplexe Steuerungssysteme. 

Dialogsysteme finden häufig im Dienstleistungssektor Anwendung. In Telefondiensten verschiedenster 

Firmen werden sie zum Beispiel genutzt, um etwas über das Anliegen des Anrufers herauszufinden, 

bevor man ihn zur entsprechenden Abteilung durch stellt. Da diese Systeme mit einer Vielzahl unterschiedlichster 

Personen und damit mit zum Teil sehr unterschiedlichen Aussprachen zurecht kommen 

müssen, sind sie sprecherunabhängig realisiert. Durch den Dialog werden die Antwortmöglichkeiten des 

Kunden und somit das mögliche Vokabular so gering wie möglich gehalten. Der Nutzer kann intuitiv mit 

dem System interagieren, wodurch sehr viele Antwortmöglichkeiten zustande kommen. Der Erkenner 

selbst sucht innerhalb der Aussage des Kunden jedoch nur nach einigen wenigen Signalwörtern, die er 

zu interpretieren weiß. Aus diesem Grund sind Dialogsysteme nicht fest, entweder bei diskreten oder 

den kontinuierlichen Erkennern, einzuordnen.


Diktiersysteme arbeiten generell mit kontinuierlicher Spracheingabe und zeichnen sich durch einen sehr 

großen Wortschatz aus. Dadurch soll jede Art von Diktat realisierbar sein ohne das der Nutzer das Gefühl 

hat er wird durch die Spracheingabe behindert. Damit die Worterkennungsrate möglichst hoch ist, werden 

derartige Systeme meist sprecherabhängig trainiert. In der Vergangenheit waren dazu zum Teil recht 

lange Trainingssitzungen nötig, bevor man mit der Arbeit beginnen konnte. Die modernsten Diktiersysteme 

kommen heute allerdings schon völlig ohne vorheriges Training aus, passen sich aber trotzdem noch 

während der Arbeit an und bleiben damit weiterhin sprecherabhängige Systeme. Neben den allgemeinen 

Diktiersysteme gibt es von einigen Anbietern auch spezielle Erkenner für einzelne Fachgebiete wie zum 

Beispiel Medizin oder Jura. Auch Übersetzer gehören in diese Kategorie, da sie das Diktat nur noch um 

eine Stufe erweitern. 

Sprachlernsysteme beziehen sich in diesem Zusammenhang nicht nur auf Fremdsprachen sondern bieten 

auch tauben oder gehörgeschädigten 1 Menschen die Möglichkeit ihre Aussprache zu trainieren. Dabei 

wird die Eingabe des Nutzers analysiert und ihm daraufhin Hinweise zur richtigen Betonung gegeben. 

Dies lässt sich auch mit diskreter Spracheingabe realisieren, um einzelne Wörter zu trainieren. Kontinuierliche 

Spracheingabe ist aber dennoch von Vorteil, da sich die richtige Betonung im Zusammenspiel 

mit anderen Wörtern oftmals ändert. Sprachlernsysteme kommen jedoch ohne Lernphase aus, da sich in 

diesem Fall der Nutzer anpassen soll und nicht das System. 

Komplexe Steuerungssysteme sind für Anwendungen gedacht, in denen ein Einzelworterkenner nicht 

mehr ausreicht. Dies geschieht zum Beispiel wenn man einen natürlichen Umgang der Nutzer mit dem 

System erreichen will. Dementsprechend wird die Spracheingabe hier kontinuierlich erfolgen und das 

System reagiert auf enthaltene Befehlswörter oder deren Kombination. Außerdem wird es nicht nur einen 

einzigen möglichen, sondern mehrere Sprachbefehle für eine Aktion geben, damit der Nutzer möglichst 

intuitiv mit dem System umgehen kann. Wenn es das Einsatzgebiet erfordert kann der Spracherkenner 

zusätzlich noch sprecherunabhängig realisiert werden. 

1 Altersschwerhörigkeit zum Beispiel, schränkt den Hörbereich von oben her ein. Das heißt höherfrequente Töne sind zuerst 

betroffen. Heute Hörgeräte versuchen das natürlich wieder auszugleichen. Wenn die Einschränkung des Hörbereichs sogar 

den Teil der menschlichen Sprache erreichte, war es früher jedoch häufig so, das bei älteren Menschen die Zischlaute mit 

der Zeit immer dumpfer klangen, einfach weil sie selbst ihre Aussprache nicht mehr richtig wahrnehmen konnten.


2.1.3 Sprechererkenner 

Sprechererkennung soll in verschiedensten Anwendungen die Sicherheit erhöhen indem sie normale 

Logins und Passwörter erweitern oder ersetzen. Die Stimme dient dabei als ein einzigartiges Erkennungsmerkmal. 

Bei der Sprecherverifikation muss der Nutzer einen Login verwenden und das System 

überprüft nur ob die Spracheingabe zum Login passt. Bei der Sprecheridentifikation weiß das System 

nicht, wer sich gerade anmelden will und muss aus einer großen Menge von möglichen Nutzern den 

richtigen herausfinden. In beiden Fällen muss dem System vorher jedoch eine Sprachprobe des Nutzers 

nehmen. Für Sprechererkennung reicht diskrete Spracheingabe aus. Der Wortschatz sollte in diesem Fall 

recht groß gewählt werden 2 . 

2.2 Anforderungen 

2.2.1 Wortschatz 

Der Wortschatz spiegelt die Gesamtmenge aller Wörterbucheinträge wieder und verdeutlicht damit, wie 

viele Wörter das Programm versteht. In Tabelle 2.1 wird, mittels einer kleinen Beispielrechnung verdeutlicht, 

wie viele Einträge für einen halbwegs ausreichenden Wortschatz in deutsch und englisch mindestens 

nötig sind. In Tabelle 2.2 werden die benötigten Wortschätze für verschiedene Anwendungen 

gegenüber gestellt. 3 Sprache Basiswortschatz Wortformen Gesamtwortschatz 

deutsch 4.000 10 40.000 

englisch 800 4 3.200 

Tabelle 2.1: Mindestwortschatz einer Diktieranwendung in deutsch und englisch nach [1] 

Große Wortschätze sind sehr gut geeignet um beinahe jede Art von Spracheingabe zu realisieren. Umso 

größer der Wortschatz jedoch wird, desto schwerer wird es für den Erkenner die Eingabe zu analysieren. 

2 Ein besonders ausgereiftes System könnte sicher aus einem einzigen Wort, das jeder Nutzer aussprechen muss, genau bestimmen 

um welchen Nutzer es sich handelt. Aus Sicherheitsgründen ist dies jedoch nicht sehr ratsam. Eine böswillige 

Person könnte sich sonst mit Hilfe einer Sprachaufzeichnung als jemand anderes ausgeben. Daher ist es besser einen sehr 

großen Wortschatz zu verwenden und den Nutzer dazu auffordern ein zufällig gewähltes Wort auszusprechen. 

3 Diese Angaben erscheinen sehr gering, wenn man bedenkt, dass der vollständige Wortschatz im Deutschen, je nach Quelle, 

300.000-500.000 und im Englischen reichlich 300.000 Wörter enthält. Diese Wortfülle wird jedoch meist nicht einmal 

annähernd ausgeschöpft. So beinhaltet der deutsche Basiswortschatz im alltäglichen Gebrauch nur etwa 400-800 Wörter 

und erst versierte Redner nutzen einen Basiswortschatz von 4.000 bis 10.000 Wörtern. Weiter Informationen dazu finden 

sich auch unter http://de.wikipedia.org/wiki/Wortschatz


Anwendung 

benötigter Wortschatz 

Notstop-Schalter 1 

Ja/Nein 2 

Ziffernfolge 10 

Menü- oder Gerätesteuerung 20-300 

einfacher Auskunftsdialog 500-2.000 

Alltagssprache 8.000-20.000 

Diktiergerät 20.000-50.000 

Deutsch ohne Fremdwörter ca. 300.000 

Tabelle 2.2: Wortschatz für verschiedene Anwendungen nach [18] 

Die Antwortzeit steigt und Verwechslungsfehler treten häufiger auf. Ein großes Problem dabei sind Homophone, 

dass heißt Wörter mit unterschiedlichen Bedeutungen aber gleichem Klang. Ein Beispiel dafür 

sind ’mehr’ und ’Meer’. Ohne zusätzliche Analysemechanismen sind Homophone für den Computer nur 

sehr schwer zu unterscheiden. Aus diesem Grund ist es für die Sprachsteuerung nötig eine gute Balance 

zwischen einem möglichst kleinen aber dennoch umfassenden Befehlswortschatz zu finden. [1] 

2.2.2 Realisierung der Spracheingabe 

2.2.2.1 diskrete Sprache 

Bei diskreter Spracheingabe muss der Nutzer zwischen den Eingaben künstliche Pausen einfügen. Wenn 

es darum geht, einzelne Befehlsworte oder Wortgruppen zur Steuerung des Computers zu verwenden, ist 

diskrete Spracheingabe durchaus praktikabel. Leider wird dem Nutzer mitunter der Eindruck vermittelt, 

dass er durch die Spracheingabe ausgebremst wird. [1] 

2.2.2.2 kontinuierliche Sprache 

Bei kontinuierliche Spracheingabe hingegen kann der Nutzer viel natürlicher Sprechen und muss sein 

Sprechtempo nicht an die Maschine anpassen. Dies ist besonders für Diktierfunktionen vorteilhaft. [1] 

2.2.3 Erkennen


2.2.3.1 sprecherabhängiges Erkennen 

Sprecherabhängiges Erkennen hilft dem Computer dabei die verschiedenen Worte besser auseinander 

zu halten. Das ist besonders bei großen Wortschätzen von Vorteil. Der Nachteil besteht allerdings darin, 

dass jeder neue Nutzer bevor er mit dem Spracheingabesystem arbeiten kann, erst eine oder mehrere Trainingsphasen 

durchlaufen muss. Dabei wird für jeden Nutzer ein neues Sprecherprofil angelegt. Dieses 

Vorgehen ist besonders bei häufig wechselnden Nutzern ungeeignet. Bei einer etwas schnellere Variante 

des sprecherabhängigen Erkennens muss vor der Arbeit nur kurz das Geschlecht und die Altersgruppe 

des Nutzers ausgewählt werden. Das ist zwar nicht so effektiv wie eine ganze Trainingsphase, dafür aber 

bedeutend schneller und erhöht die Worterkennungsrate schon deutlich. [1] Die neusten Systeme kommen 

sogar völlig ohne vorheriges Training aus, legen aber dennoch ein Nutzerprofil an und verfeinert es 

während der Arbeit. 

2.2.3.2 sprecherunabhängiges Erkennen 

Sprecherunabhängiges Erkennen ist nur bei einem begrenzten Wortschatz einsetzbar. Da der Spracherkenner 

nicht auf einen bestimmten Sprecher geprägt wird, steigt die Verwechslungswahrscheinlichkeit 

mit jedem zusätzliche Wort stark an. [1] Durch immer besser werdende Erkenner wird diese Einschränkung 

aber mehr und mehr aufgehoben. 

2.3 Realisierung der Spracheingabe 

2.3.1 Spracheingaben erkennen 

Bei einer Spracheingabe fällt es dem Computer schwer, zwischen einem normalen Gespräch und einem 

Sprachbefehl zu unterscheiden. Am einfachsten ist es natürlich, den Spracherkenner immer nur dann 

einzuschalten, wenn man einen Sprachbefehl geben will. Dies ist aber recht umständlich und teilweise 

auch nicht möglich, da man zum Beispiel die Hände nicht frei hat, zu weit vom Computer entfernt ist 

oder aber das Starten des Spracherkenners einfach zu lange dauert. Um dies zu vereinfachen gibt die 

Möglichkeit den Computer darauf hinzuweisen, das in kürze eine Eingabe erfolgt. 

2.3.1.1 Push to Talk 

Dabei handelt sich um eine sehr bekannte und praktikable Variante. Der Nutzer betätigt eine Taste um 

die Eingabe zu signalisieren. Damit das ganze für den Nutzer komfortabler abläuft, kann das ’Betätigen


der Taste’ in eine natürlichere Handlung eingebettet werden. Zum Beispiel in das Einschalten eines 

Laserpointers. [1] 

2.3.1.2 Sprachsignal 

Auch Spracheingaben kann man wiederum durch Sprachsignale ankündigen. Die einfachste Variante ist 

ein exotisches Befehlswort, von dem man annehmen kann, dass es im allgemeinen sehr selten verwendet 

wird. Der Computer hört sozusagen die ganze Zeit mit, wird aber erst aktiv wenn er das exotische 

Befehlswort erkennt. [1] Das Ganze lässt sich noch dadurch erweitern, dass der Computer nur bei einer 

bestimmten Betonung des Signalwortes aktiv wird. Man hat sogar herausgefunden, dass allein aufgrund 

der Betonung schon eine 80 prozentige Erkennungsrate erreicht wird. Dadurch ist es nicht einmal mehr 

nötig ein besonders exotisches Signalwort zu wählen. Unter diesen Bedingungen wird der Satz: ’Ich werde 

gleich nach dem Speichern den Computer ausschalten’ nicht dazu führen, dass die gesamte Tagesarbeit 

verloren geht. Wohingegen das besonders betonte ’COMPUTER ausschalten’ umgehend ausgeführt 

wird. 

2.3.2 Mikrofon 

Bei der Spracheingabe ist die wichtigste Schnittstelle zwischen Mensch und Maschine das Mikrofon. 

Billige Modelle fügen dem Sprachsignal mitunter einen beachtlichen Rauschanteil hinzu oder helfen 

nicht dabei Störgeräusche zu vermindern. Beides ist jedoch sehr wichtig um dem Spracherkenner bestmögliche 

Eingangssignale zu liefern und damit die Worterkennungsrate zu verbessern. Aus diesen Grund 

ist es besonders wichtig qualitativ hochwertige Mikrofone zu verwenden. Im Folgenden wird noch kurz 

auf die Mikrofonposition eingegangen. 

2.3.2.1 stationäre Mikrofone 

Ein, an einer festen Position installiertes Mikrofon bietet dem Benutzer vollständige Bewegungsfreiheit 

und Komfort. Leider steigt dadurch der störende Einfluss von Umgebungsgeräuschen sehr stark an. Dies 

wiederum erhöht den Anspruch, der an das Spracherkennungssystem gestellt wird. Es wird eine bessere 

Vorverarbeitung und Analyse des Eingangssignals benötigt und damit eine um ein vielfaches höhere 

Rechenleistung beansprucht. [1]


2.3.2.2 mobile Mikrofone 

Ein mobiles Mikrofon, wie zum Beispiel in einem Headset verringert durch seine extrem kurze Distanz 

zum Sprecher den Einfluss von Störgeräuschen enorm. Dadurch wird die Spracherkennung im Vergleich 

zu stationären Mikrofonen deutlich verbessert. Der einzige Vorteil stationärer Mikrofone, nämlich die 

Bewegungsfreiheit, wird durch heutige wireless Technologie vollständig aufgehoben. Damit sind mobile 

Mikrofone den stationären im Allgemeinen überlegen. [1]

3. ALLGEMEINER AUFBAU EINES SPRACHERKENNERS 14 

3 Allgemeiner Aufbau eines Spracherkenners 

Dieses Kapitel beschäftigt sich mit dem allgemeinen Aufbau eines Spracherkenners. Abbildung 3.1 zeigt 

das Grundmodell eines solchen Systems 1 . 

Abbildung 3.1: Allgemeiner Aufbau eines Spracherkenners 

In den Teilkapiteln werden die einzelnen Bestandteile näher betrachtet. 

Außerdem sei noch zu erwähnen, dass zwei grundlegende Ansätze existieren nach denen Erkenner funktionieren. 

Beim Mustererkennungsansatz (Abbildung 3.2) wird ein einzelnes Muster aus dem Signal 

gewonnen, dieses mit allen Referenzmustern verglichen und letztendlich das passendste Muster ausgewählt 

oder das Muster des Signals zurückgewiesen. Dem gegenüber steht der Akustisch-phonetische 

Ansatz (Abbildung 3.3). Hier wird aus dem Signal eine Menge von Merkmalen extrahiert, verknüpft und 

danach mit Hilfe des Hypothesentesters mit dem Vokabular verglichen.[9] 

1 Mit Signal ist hier bereits das digitalisierte Sprachsignal gemeint. Damit beim digitalisieren keine Informationen verloren 

gehen, muss die Abtastrate dabei mindestens das Doppelte der größten Frequenz des Sprachsignals entsprechen. Im Fall der 

menschliche Sprache sind das 8kHz, was zu einer minimalen Abtastrate von 16kHz führt. Es gibt natürlich Ausnahmefälle. 

Bei Telefonsignalen wird zum Beispiel nur noch ein Bereich von 0,3-3,4kHz übertragen, also wäre hier eine Abtastrate von 

nur 8kHz vollkommen ausreichend.[8]


Abbildung 3.2: Mustererkennungsansatz 

Abbildung 3.3: Akustisch-phonetischer Ansatz 

3.1 Signalaufbereitung 

Die Signalaufbereitung ist eng mit der Analyse verbunden. Ihr Ziel besteht darin, die Schwankungen 

und Störungen im Signal zu reduzieren und dadurch den späteren Analyseaufwand zu minimieren. Umso 

besser die Aufbereitung also ist, desto besser können später die Merkmale aus dem Signal abgeleitet 

werden. Es existieren verschiedene Schritte der Signalaufbereitung, die sich noch einmal in die formale 

und die spezielle Vorverarbeitung unterteilen lassen. Abbildung 3.4 zeigt den möglichen Aufbau einer 

Signalaufbereitungskomponente. 

Abbildung 3.4: Aufbau der Signalaufbereitung 

3.1.1 Formale Vorverarbeitung 

Vorfilterung: 

Die Vorfilterung unterdrückt, mit Hilfe von Bandsperren und verschiedenen Filtern, Störsignale. Da die


menschliche Sprache einen Frequenzbereich von 50Hz bis 8kHz umfasst, ist es zum Beispiel sinnvoll 

alle darunter und darüber liegenden Frequenzanteile des Signals zu entfernen. 

Grenzdetektion: 

Bei einem eintreffenden Signal muss es sich allerdings nicht zwangsläufig ein Sprache handeln. Mit 

Hilfe der Grenzdetektion soll nun herausgefunden werden wo der Sprachteil beginnt beziehungsweise 

endet. Dazu existieren zwei Verfahren. Das Erste arbeitet im Zeitbereich. Es wertet die Energiesumme 

des Signals über einen bestimmten Zeitraum aus um eine Grenzdetektion vornehmen zu können. Wird 

ein Schwellwert überschritten muss es sich um ein Sprachsignal handeln. Beim analytischen Verfahren 

hingegen werden bestimmte Merkmale aus dem Eingangssignal extrahiert und mit Hilfe verschiedener 

Entscheidungsregeln wird überprüft, ob die Merkmale des Eingangssignals mit den Merkmalen eines 

Sprachsignals übereinstimmen.[2] 

Normierung, Pegelanpassung: 

Damit die spätere Mustererkennung erheblich einfacher ablaufen kann wird das Signal zusätzlich angepasst, 

sprich normiert. Der größte Pegel des Signals wird dabei auf einen vordefiniert Maximalwert 

gesetzt und alle anderen Pegel im Verhältnis zu dieser Änderung angepasst.[3] 

3.1.2 Spezielle Vorverarbeitung 

Quellenlokalisation und -verfolgung: 

Dieses Verfahren dient wie die Vorfilterung dazu Umgebungslärm auszufiltern. Dabei wird versucht den 

sogenannten Cocktailparty-Effekt 2 nachzubilden. Anstelle eines einzelnen Mikrofons und eines sehr 

komplexen Lärmfiltersystems werden bei diesem Verfahren mehrere Mikrofone verwendet. Dadurch entstehen 

unterschiedliche Aufnahmen des Signals, mit deren Hilfe man verschiedene Schallquellen voneinander 

unterscheiden, Echos kompensieren und Störungen unterdrücken kann.[9] 

Segmentierung: 

Die Segmentierung ist der letzte Schritt der Vorverarbeitung. Das gefilterte und normierte Sprachsignal 

wird hierbei in Segmente gleicher Länge aufgeteilt. Sie haben eine Dauer von 10ms bis 25ms, werden 

mit Hilfe einer Fensterfunktion, wie zum Beispiel dem Hamming-Fenster, gewonnen und können einan- 

2 Cocktailparty-Effekt bezeichnet die Fähigkeit des menschlichen Gehörs, sich bei vielen Signalquellen auf ein einzelnes 

Signal zu konzentrieren und alle anderen auszublenden.


der überlappen.[2] 

3.2 Analyse und Merkmalsableitung 

3.2.1 Analyseverfahren 

Linear Predictive Coding 

Beim Linear Predictive Coding wird die menschliche Sprache vereinfacht als ein Anregungs-/ Bewertungsmodell 

dargestellt. Die Öffnung zwischen den Stimmbändern liefern die Anregungimpulse, die 

dann durch den Rachenraum und Mund bewertet werden. Dies wird in Abbildung 3.5 für einen Vokal 

dargestellt. Die Häufigkeit der Anregung F 0 (Bild (a)) ist dabei 1/T 3 0 (Bild (b)). In Bild (c) der Abbil- 

Abbildung 3.5: Anregung und Bewertung für einen Vokal[17] 

dung 3.5 ist die zugehörige Bewertungsfunktion zu sehen. Sie zeigt die vorhandene Signalenergien für 

die einzelnen Frequenzen an. Frequenzanteile, die im Verhältnis zu ihrer Umgebung relativ viel Energie 

3 T 0 bezeichnet die Zeitdauer zwischen zwei Anregungen.


besitzen nennt man Formanten. Diese ermöglichen es, das Signal zu identifizieren und sind als F1 bis F4 

eingetragen. Diese Merkmale jedoch im Echtzeitbetrieb aus einem Signal zu extrahieren dauert zu lange. 

Beim Linear Predictive Coding werden diese Merkmale deshalb nur beim Erstellen eines Eintrags, 

für das Referenzmusterspeicher, extrahiert. Dies verringert zunächst nur den Speicheraufwand für das 

Vokabular. Während des tatsächlichen Betriebs des Erkenners werden diese Merkmale dazu genutzt das 

ursprüngliche Signal eines Vokabulareintrags wieder herzustellen, was wesentlich schneller funktioniert. 

Das ursprüngliche Signal wird dann mit Hilfe der Kreuzkorrelationsfunktion mit dem eingehenden Signal 

verglichen. Das Ergebnis gibt an, wie ähnlich sich die zwei Signale sind. [17] 

cepstrale Glättung 

Auch hier wird ein Anregungs-/Bewertungsmodell als Grundlage verwendet. Das Cepstrum (c (n)) ist 

die inverse Fourier-Transormation (IDFT) des Logarithmus des Spektrums (X (k)) eines Sprachsignals 

(x (n)). 

c (n) = IDF T {log|X (k) |} 

Nach dieser Transformation sind der Anregungs- und der Bewertungsteil zeitlich getrennt. Der unerwünschte 

Anregungsteil kann nun einfach subtrahiert werden. Danach wird das ganze wieder Fouriertransformiert 

und entlogarithmiert um letztendlich das Spektrum (Bild (d) der Abbildung 3.5) des Bewertungsteils 

zu erhalten. [17] 

Frequenz-Zeit-Transformation 

Das Eingangssignal wurde während der Vorbereitung in Segmente unterteilt. Die Segmente werden so 

kurz gewählt, das man davon ausgehen kann, dass das Signal in einem Segment gleich bleibt. Jedes 

Segment wird mit Hilfe der Fouriertransformation vom Zeit- in den Frequenzbereich überführt. So erhält 

man zu jedem Segment das zugehörige Spektrum. Wenn man diese Spektren zeitlich verknüpft folgt 

daraus das Gesamtspektrum des Eingangssignals. 

3.2.2 Merkmalableitung 

Differentiation 

Die Differenziation erfasst Unterschiede erster und zweiter Ordnung, zwischen Teilobjekten die einander 

folgen. 

1. Ordnung: x ′ i = x i+1 − x i 

2. Ordnung: x ′′ 

i = x′ i+1 − x′ i


Merkmalselektion 

Um die Gesamtanzahl der zu speichernden Information zu reduzieren, werden redundate Merkmale beseitigt. 

Vektorquantisierung 

Um die Anzahl der Merkmalsvektoren zu reduzieren werden ähnliche Vektoren zu einem einzelnen Vektor 

zusammengefasst. 

Psychisch motivierte Verfahren 

Bei psychisch motivierten Verfahren werden für den Menschen tatsächlich wahrnehmbare Größen als 

Merkmale genutzt. In der Akustik handelt es sich dabei um die Phoneme. Die kleinsten bedeutungstragenden 

Einheiten der Sprache. Eintreffende Sprachsignale werden in ihre Phonemfolge zerlegt. 

Heuristische Verfahren 

Aus verschiedenen Signalen werden aussagekräftige Merkmale aufgrund von Expertenwissen extrahiert. 

Diese Merkmale können später genutzt werden, um bereits untersuchte Signale wieder zu erkennen. 

3.3 Klassifikation 

In diesem Schritt werden die abgeleiteten Merkmale mit den Daten aus einem oder mehreren Referenzmusterspeichern 

verglichen. Danach wird das ähnlichste Muster als erkanntes Ergebnis weiter gegeben. 

Natürlich kann es sein, dass tatsächlich garkeine Eingabe erfolgte. Aus diesem Grund darf der Unterschied 

zwischen Eingabesignal und zugeordnetem Referenzmuster einen voreingestellte Rückweisungsschwelle 

nicht überschreiten. Um die Klassifikation durchzuführen gibt es verschiedene Verfahren. 

3.3.1 Lineare Streckung/Stauchung 

Da man das selbe Wort nur sehr selten exakt gleich schnell ausspricht muss das Eingangsmuster zeitlich 

an das Referenzmuster angepasst werden. Ein einfaches Verfahren dazu passt die Gesamtdauer des 

Eingangssignals durch linear Streckung oder Stauchung an das Referenzmuster an. Danach wird ein direkter 

Vergleich zwischen dem Muster des Eingangssignals und dem entsprechenden Referenzmuster 

durchgeführt. Dies wird für alle Referenzmuster wiederholt und das passendste ausgewählt.


3.3.2 Dynamic Time Warping 

Hierbei handelt es sich um verbessertes Verfahren zur zeitlichen Anpassung. Es wird nicht nur auf die 

Gesamtdauer des Eingabemusters eingegangen, sondern auch Geschwindigkeitsschwankungen innerhalb 

eines Musters beachtet. Die Werte des Eingabemusters werden, wie in Abbildung 3.6 zu sehen, den 

Werten des Referenzmusters zugeordnet, denen sie am ehesten entsprechen. Dabei sind allerdings einige 

Randbedingungen einzuhalten. Die beiden Anfangs und Endpunkte der Signale müssen jeweils einander 

zugeordnet sein. Die zeitliche Abfolge muss beibehalten werden und man darf keine Werte auslassen. 

Abbildung 3.6: Dynamic Time Warping 

Da bei diesem Verfahren mehrere Ergebnisse möglich sind, wird mit Hilfe einer rekursiven Gleichung 

der optimale Weg durch die aufgespannte Ebene gesucht. Auch dieses Verfahren wird wieder für alle


Referenzmuster durchgeführt und das am besten passende gesucht. [7] 

3.3.3 Hidden Markov Modell 

Das Hidden Markov Modell (HMM) versucht Sprachsignale durch ihre statistischen Eigenschaften zu 

beschreiben. Zu jedem Eintrag im Vokabular wird ein statistisches Modell erstellt. Dabei wird jeder 

Eintrag in seine Phoneme zerlegt und die entsprechenden Wahscheinlichkeiten ermittelt. Abbildung 3.7 

stellt dieses Modell für das Wort ’haben’ dar. Im oberen Teil sind die Übergangswahrscheinlichkeiten für 

die einzelnen Zustände zu sehen. Im unteren Teil werden die Wahrscheinlichkeiten dafür gegeben, im 

entsprechenden Zustand die angegebene Beobachtung gemacht zu haben. Die zeitlichen Unterschiede 

zwischen Eingabe und Referenz werden dadurch beglichen, das auch die Wahrscheinlichkeiten dafür 

gegeben sind ob ein Zustand weiterhin anhält oder ob ein Übergang stattfindet. 

Abbildung 3.7: Hidden Markov Modell für das Wort ’haben’ nach [7] 

Später wird die Wahrscheinlichkeit, dass die Beobachtete Phonemfolge tatsächlich zu einer Referenz 

gehört, durch folgende Formel berechnet: 

P (Y ) = ∑ X 

P (Y |X) P (X) 

Wobei Y die beobachtete Phonemfolge ist und X der Phonemfolge einer Referenz entspricht. Auch hier 

wird zum Schluß die wahrscheinlichste Referenz als Ergebnis zurückgegeben oder die gesamte Eingabe 

als ’nicht erkannt’ verworfen. [7]


3.4 Interpretation und Reaktion 

Nachdem das Eingangssignal nun einem Eintrag des Vokabulars zugeordnet wurde kann es interpretiert 

werden. Bei einer Diktieranwendung erfolgt nun eine Textausgabe des Ergebnisses, bei einem Steuerungssystem 

würde der entsprechende Menüpunkt aufgerufen oder eine Aktion ausgeführt. Bei einer 

weitaus komplexeren Interaktion könnte auch die gesamte Eingabe analysiert und nach Signalwörtern 

und ihren Zusammenhängen durchsucht werden um darauf basierend zu reagieren. Im konkreten Fall 

könnte dies bedeuten, dass die Aussage: ’Den roten Ball zu der Kiste legen!’ in einer komplexen Szene 

dazu führt, dass ein rotes kugelförmiges Objekt gesucht wird und in die Nähe eines Quaders plaziert 

wird oder aber dass in einer Rückmeldung nachgefragt wird, welches der roten kugelförmigen Objekte 

gemeint ist.

4. ERHÄLTLICHE PROGRAMME 23 

4 Erhältliche Programme 

Zur Spracheingabe und Spracherkennung sind einige Programme erhältlich. In Tabelle 4.1 werden frei 

verfügbaren Programme aufgelistet, Tabelle 4.2 gibt einen kurzen Überblick über kommerziell erhältliche 

Software. 

Software Hersteller Grundlage Betriebssystem Plattform 

Microsoft Agent Microsoft Microsoft Speech API Windows PC 

CVoiceControl Daniel Kiecza - Linux PC 

XVoice David Z. Creemer IBMViaVoice Linux PC 

Tom Doris 

Brian Craft 

Tabelle 4.1: Frei verfügbare Spracheingabesoftware 

Software Hersteller Betriebssystem Plattform 

Dragon Naturally Speaking Nuance Win PC 

iListen MacSpeech Inc OS X Mac 

Via Voice IBM Win PC 

Voice*It VoiceIt Technologies - PC, PDAMobil 

Tabelle 4.2: Kommerzielle Spracheingabesoftware 

An dieser Stelle wird kurz auf die verschiedenen Produkte eingegangen. Was die jeweilige Software kann 

entspricht dabei den Herstellerangaben. 

4.1 freie Anwendungen 

4.1.1 Microsoft Agent 

Der Microsoft Agent ist eine Software Technologie, die es Entwicklern ermöglicht Spracheingabe, Sprachsteuerung 

und Text to Speech (TTS) in Form verschiedener animierter Charaktere, in ihre Anwendungen


zu integrieren. Microsoft bietet vier Standardcharaktere an. Man hat allerdings zusätzlich die Möglichkeit, 

eigene zu erstellen oder weitere Charaktere von Fremdanbietern zu erhalten. Die Basis für den 

Microsoft Agent ist die Microsoft Speech API 4.0. Sie muss in jedem Fall installiert werden um, mit 

dem Agent zu arbeiten. Wird der Agent in einem Programm aktiv, führt die vom Entwickler definierten 

Aktionen aus. Zum Beispiel kann er dem Anwender mit Hilfe der verschiedenen TTS Engines Hinweisen 

geben oder auf Spracheingaben reagieren. Für TTS werden unter anderen Engines für U.S. Englisch, 

britisches Englisch, Französisch, Deutsch und Italienisch geboten. Die Spracheingabe wird jedoch nur 

für U.S. Englisch unterstützt. Alle Downloads finden sich unter [13], zusätzliche TTS Fremdanbieter 

unter [12]. Weiter Informationen zur genaueren Funktionsweise der SAPI sind in Kapitel 5.2 zu finden. 

4.1.2 CVoiceControl 

CVoiceControl ist ein Spracherkennungssystem von Daniel Kiecza. Es ermöglicht dem Linuxanwender 

Sprachbefehle mit Unix Kommandos zu verknüpfen. Es erkennt automatisch Spracheingaben mittels 

Mikrofon. Falls diese Eingaben korrekt erkannt werden, führt CVoiceControl die zugehörigen Kommandos 

aus. Damit die Eingabe erkannt werden kann muss mindestens ein Sprechermodell angelegt werden. 

Einen entsprechenden Editor gehört schon zu CVoiceControl. In einem Sprechermodell befindet sich 

je Sprachkommando eine Beschreibung dessen, was gesagt wird, das auszuführende Kommando selbst 

und Vergleichswerte für den Erkenner. Bei den Vergleichswerten handelt es sich um Sprachaufnahmen 

des Kommandos, die man selbst anfertigen muss. Da direkt die Ähnlichkeit zwischen dem eintreffenden 

Sprachsignal und den Vergleichswerten berechnet wird ist es vorteilhaft mehrere Vergleichswerte pro 

Kommando aufzunehmen. Die vorgegebene Mindestzahl beträgt dabei vier. Da der Erkenner die Amplitude 

des eintreffenden Sprachsignals nicht anpasst, muss man bei der Spracheingabe darauf achten, dass 

die Entfernung zwischen Mund und Mikrofon sowie die Aussprachelautstärke konstant bleiben. Indem 

man Vergleichswerte nicht nur in verschiedenen Betonungen sondern auch in verschiedenen Lautstärken 

aufnimmt, kann hier möglicherweise Abhilfe geschaffen werden. Leider ist dazu nichts im Online 

Handbuch zu finden. [10] CVoiceControl bietet damit einen sprecherabhängigen Spracherkenner. Das 

Training des Erkenners wird hier durch das anlegen der Vergleichswerte erledigt. Es ist nur diskrete 

Spracheingabe möglich. Dies ist für die Eingabe einzelner Befehlswörter oder Befehlswortgruppen aber 

vollkommen ausreichend. Wie in Kapitel 2.2.1 gesagt, sollte das Vokabular des Erkenners so klein wie 

möglich gehalten werden, um die Rechenzeit zu sparen und Verwechslungsfehler auszuschließen. Dies 

ist in CVoiceControl gegeben, indem man mehrere Sprechermodelle für verschiedene Anwendungen 

anlegt und immer nur das benötige Modell lädt.


4.1.3 XVoice 

XVoice ermöglicht durchgängige Spracheingabe und Sprachsteuerung unter Linux. Um die Spracheingaben 

in Text umzuwandeln wird IBMs ViaVoice benötigt. ViaVoice ist allerdings weder gemeinsam 

mit XVoice erhältlich, noch kostenlos. [5] Des weiteren wird ViaVoice nicht mehr von IBM betreut oder 

angeboten. Weitere Informationen zu ViaVoice sind im Abschnitt 4.2.3 zu finden. In XVoice kann der 

Nutzer verschiedene Sprachkommandos mit Aktionen verbinden. Dazu muss er diese Kommandos in Vokabularen 

zusammenfassen. Diese wiederum können dann mit unterschiedlich Anwendungen oder Modi 

verknüpft angewandt oder aber dauerhaft verwendet werden. In einem Übersichtsfenster zeigt XVoice 

die aktiven Vokabulare und die letzten Spracheingaben an. Falls eine Spracheingabe einem Kommando 

sehr ähnelte, aber XVoice sich nicht sicher genug ist, wird dies im Übersichtsfenster grau unterlegt angezeigt. 

Eine Aktion wird aber nicht ausgeführt. Innerhalb einer Anwendung ist XVoice in einem von vier 

Zuständen. Im Kommandomodus wird nur auf Befehle aus dem Vokabular reagiert. Im Diktiermodus 

werden nur generelle Kommandos beachtet, ansonsten wird jede Spracheingabe einfach aufgeschrieben. 

Im Untätig-Modus werden nur generelle Befehle ausgeführt. Im vierten, dem Diktier- und Kommandomodus 

werden beide Modi kombiniert. Um in diesem Modus Kommandos zu erkennen muss vor und 

nach jedem Kommando eine Pause gelassen werden.[21] Zusammenfassend kann man sagen, das XVoice 

durch die verschiedenen Modi sowohl kontinuierliche wie auch diskrete Spracheingabe unterstützt. 

Gleichzeitig kann, durch die Modi einerseits ein möglichst kleines, auf die jeweilige Anwendung abgestimmtes 

Vokabular verwendet werden und andererseits mit Hilfe des umfangreiches Vokabulars die 

Texteingabe realisiert werden. Die Spracherkennung erfolgt dabei sprecherabhängig. Um bestmögliche 

Ergebnisse zu erzielen sollte ViaVoice, auf dem XVoice basiert, vor der Arbeit trainiert werden. 

4.2 kommerzielle Anwendungen 

4.2.1 Dragon Naturally Speaking 

Dragon Naturally Speaking wird von Nuance entwickelt. Es bietet Spracheingabe, Sprachsteuerung 

und fließende Sprachausgabe von Texten in einem. Die Spracheingabe bietet die Möglichkeit Texte 

auf Deutsch oder Englisch zu diktieren. Dies soll laut Hersteller dreimal schneller als mit der Tastatur 

funktionieren. Dabei kann eine Erkennungsrate von bis zu 99Prozent erreicht werden. Der Spracherkenner 

muss vor Beginn der Arbeit nicht trainiert werden. Während der Arbeit legt das Programm 

allerdings automatisch ein Nutzerprofil an und verfeinert es fortlaufend, um die Fehlerrate zu senken. 

Zusätzlich zur Diktierfunktion sollen mit Dragon Naturally Speaking auch die meisten Windows XP 

und 2000 Anwendungen und die Maus per Spracheingabe steuerbar sein. Außerdem kann der Nutzer


weitere Sprachbefehle selbst erstellen.[14] Die Unterscheidung zwischen Befehl und Diktat soll dabei 

automatisch erfolgen.[16] Damit liefert Dragon Naturally Speaking sowohl kontinuierliche Spracheingabe, 

mit einem umfassenden Vokabular, für längere Texte, als auch diskrete Spracheingabe für Befehle. 

Da während der Arbeit ein Nutzerprofil angelegt wird ist nur sprecherabhängiges Erkennen möglich. 

4.2.2 iListen 

Hierbei handelt es sich um ein Produkt von MacSpeech. Die aktuelle Version ist 1.8 für Mac OS X. 

Zu Beginn der Arbeit mit iListen ist eine kurze Trainingsphase von maximal fünf Minuten nötig. Bei 

der Arbeit mit iListen hat der Nutzer schon während des Diktats die Möglichkeit, den Text zu formatieren. 

Auch Korrekturen sind per Spracheingabe realisierbar. iListen soll in allen Anwendungen nutzbar 

sein. Während der Arbeit passt sich iListen schnell an die Sprechweise des Nutzers an. Dadurch, dass 

mehrere Benutzerprofile angelegt werden können, ist iListen von mehreren Personen nutzbar. Man hat 

die Möglichkeit Anwendungen wie zum Beispiel den Browser oder den Desktop per Spracheingabe 

zu steuern. Außerdem können auch eigene Steuerbefehle erstellt werden. Zusätzlich zu iListen werden 

noch Sprachpakete benötigt. Sie werden in Deutsch, Italienisch, Spanisch und Englisch angeboten. Die 

Sprachsteuerung soll für nahezu alle Anwendungen möglich sein. Wie bei anderen Programmen, muss 

man dafür jedoch viele eigene Sprachbefehle definieren. Allerdings werden von MacSpeech so genannte 

ScriptPak’s angeboten, um die grundlegenden Befehle für verschiedenste Anwendungen zu liefern. Solche 

Pak’s stehen in Englisch und Italienisch zur Verfügung. Ein großer Nachteil ist, dass alle Teile und 

Updates zusätzlich gekauft werden müssen. [11] iListen bietet ein umfangreiches Vokabular für Diktate, 

eine kontinuierliche Spracheingabe und verwendet dazu sprecherabhängiges Erkennen. 

4.2.3 ViaVoice 

ViaVoice wurde 1997 von IBM veröffentlicht. [6] Im laufe der Jahre wurde es immer mehr verbessert. 

2003 hat IBM die Vertriebsrechte für ViaVoice an ScanSoft abgegeben. Im Jahr 2005 wurde ScanSoft von 

Nuance übernommen. Seit dem besitzt Nuance auch die Vertriebsrechte an IBM ViaVoice. Die aktuelle 

Version ist IBM ViaVoice 10.5. [23] Via Voice bietet wie iListen eine Diktiersoftware für kontinuierliche 

Spracheingabe, mit einem umfangreichen Vokabular und die Möglichkeit, das Diktierte per Sprachsteuerung 

zu überarbeiten und formatieren. Mit der Pro USB Edition können zusätzlich noch verschiedene 

andere Anwendungen gesteuert werden. Auch ViaVoice arbeitet sprecherabhängig. Vor Beginn der Arbeit 

ist wieder eine kurze Trainingsphase nötig. Das daraus resultierende Nutzerprofil wird während der 

Arbeit weiter angepasst.[15]


4.2.4 VoiceIt 

Von VoiceIt Technologies kommen verschiedene Programme um Anwendungen per Stimme zu steuern. 

In Tabelle 4.3 ist dargestellt auf welchen Betriebssysteme die verschiedenen Produkte von VoiceIt laufen. 

Für die mit * gekennzeichnet Betriebssysteme soll die entsprechende Software bald verfügbar sein. 

Software 

Betriebssystem 

VoiceNavIt Windows* Windows Mobile Palm OS Symbian* 

VoiceSecureIt Windows* Windows Mobile Palm OS Symbian* 

VoicePlayIt 

Palm OS 

VoiceDailIt Palm OS Symbian* 

Tabelle 4.3: Übersicht über VoiceIt Sofware und die unterstützten Betriebssysteme nach [25] 

Da alle Programme zur Steuerung oder Sicherung gedacht sind, besitzen sie eingeschränkte Vokabulare. 

Die diskreten Spracheingaben werden nur sprecherabhängig erkannt. In einer einleitenden Trainingssitzung 

müssen alle Sprachbefehle also zunächst vorgesprochen werden. Bei VoicePlayIt handelt es sich 

dabei um vordefinierte Befehle, bei allen anderen können die Spracheingaben sowie die daraus folgenden 

Aktionen individuell festgelegt werden. [25]

5. FREI VERFÜGBARE SPRACHERKENNER 28 

5 Frei verfügbare Spracherkenner 

Im vorherigen Kapitel wurde ein Überblick über schon vorhandene Sprachsteuerungssoftware gegeben. 

In diesem Kapitel hingegen werden drei Systeme vorgestellt, die dem Programmierer die Möglichkeit 

geben Sprachsteuerung in eigene Anwendungen zu integrieren. Es wird gezeigt, dass diese Systeme sehr 

unterschiedliche Eigenschaften besitzen. Eines der Systeme erkennt die deutsche Sprache, wohingegen 

die anderen für die englische Sprache entwickelt wurden. Außerdem erkennt eines der Systeme nur 

sprecherabhängig, was wiederum mit sprecherunabhängigem Erkennen nur schwer zu vergleichen ist. 

5.1 Sphinx-4 

5.1.1 Allgemeines 

Sphinx-4 wurde von der Sphinx Gruppe an der Carnegie Mellon Universität, Mitsubishi Electric Research 

Labs, Sun Microsystems Laboratorien und Hewlett Packard entwickelt. Dabei wurden sie von der 

Universität von Kalifornien in Santa Cruz und dem Massachusetts Institut of Technologie unterstützt. 

Bei Sphinx-4 handelt es sich um ein Spracherkennungssystem, das komplett in Java geschrieben wurde. 

[4] 

5.1.2 Aufbau 

Die Abbildung 5.1 zeigt den Aufbau der Architektur von Sphinx-4. Sphinx-4 wurde sehr flexibel und 

modular entworfen. Jeder der beschriebenen Teile kann einfach ausgetauscht werden ohne das dafür an 

den anderen Systemteilen Veränderungen vorgenommen werden müssen. 

Es existieren die drei Hauptmodule Front End, Decoder und Liguist. Das Front End nimmt ein oder 

mehrere Eingangssignale und zerlegt diese in eine Folge von Features (Merkmalsvektoren). Der Liguist 

erstellt aus dem Language Model, den Ausspracheinformationen aus dem Dictionary und den strukturellen 

Informationen aus einem oder mehreren Acoustic Models einen Search Graph. Der Search Manager 

arbeitet innerhalb des Decoders. Er nutzt den Search Graph um aus den Features, die er vom Front End 

erhält, die Eingabe zu entschlüsseln und das Ergebnis zu generieren. Dabei kann die Anwendung jeder-


Abbildung 5.1: Aufbau von Sphinx-4 nach [26] 

zeit Kontrollanweisungen an die verschiedenen Module senden und somit auf den Erkennungsprozess 

Einfluss nehmen. Sphinx-4 besteht aus vielen einstellbaren Teilen. Um diese Einstellungen vor zu nehmen 

wird der Configuration Manager genutzt. Außerdem können mit seiner Hilfe, Module dynamisch 

während der Laufzeit geladen oder verändert werden. Zusätzlich werden dem Nutzer viele Werkzeuge 

geboten. Mit ihrer Unterstützung können verschiedenste Statistiken, wie zum Beispiel über die Wortfehlerrate 

oder die Speichernutzung erstellt werden. 

5.1.3 Funktion 

Sobald der Erkenner gestartet wird, richtet er das Front End, den Decoder und den Linguist ein. Dabei 

werden die Spezifikationen des Nutzers beachtet. Diese Komponenten wiederum legen ihre eigenen 

Unterkomponenten an. Der Liguist lädt das Acoustic Model, das Dictionary und das Language Model. 

Aus diesen Teilen wird danach ein passender Search Graph konstruiert. Der Decoder erstellt den Search 

Manager, der wiederum den Scorer, den Pruner und die Active List anlegt. 

Die meisten dieser Komponenten sind Java Interfaces. Für sie existieren verschiedene Implementationen. 

Welche Implementation tatsächlich genutzt wird legt der Nutzer in einer Konfigurationsdatei fest. Sie 

basiert auf XML und wird vom Configuration Manager geladen. In ihr können auch Eigenschaften wie 

zum Beispiel die Sample Rate der eintreffenden Sprachdaten festgelegt werden. 

Um ein Eingabesignal richtig zu erkennen wird der Search Graph genutzt. Innerhalb des Graphen gibt


es verschiedene Wege um zum richtigen Ergebnis zu gelangen. In Sphinx-4 wird ein Token-Algorithmus 

implementiert. Jedes mal wenn ein neuer Zustand im Search Graph erreicht wird, wird ein neuer Token 

erstellt. Er zeigt auf den vorherigen Token und den nächsten Zustand im Graph. In der Active List werden 

alle Pfade durch den Search Graph verfolgt, die im Moment aktiv sind. Dazu wird der letzte Token jedes 

Pfads gespeichert. 

Die Anwendung möchte nun, dass der Recognizer eine Erkennung durchführt. Dazu fordert der Search 

Manager den Scorer auf, jeden Token der Active List mit dem nächsten Feature (Merkmalsvektor), der 

vom Front End kommt, auszuwerten. Dabei entsteht eine Auswertung für jeden aktiven Pfad. Mit Hilfe 

dieser Bewertung und bestimmten heuristischen Methoden wird der Pruner verschiedene Token verwerfen. 

Jeder übrige Pfad wird um den nächsten Zustand erweitert. Für jeden Zustand wird ein neuer Token 

erstellt. Dieser Vorgang wird wiederholt, bis keine weiteren Merkmalsvektoren mehr vom Front End eingehen. 

Das bedeutet im Normalfall, dass keine weitere Spracheingabe erfolgte. An dieser Stelle werden 

alle Pfade, die den Endzustand erreicht haben, verglichen. Der Pfad mit der höchsten Bewertung wird als 

Ergebnis an die Anwendung zurück geschickt.[4] 

5.1.3.1 Front End 

Die Aufgabe des Front End ist es, Eingangssignale in eine Folge von Merkmalen zu zerlegen. Wie in 

Abbildung 5.2: Das Sphinx-4 Front End nach [26] 

Abbildung 5.2 dargestellt, umfasst das Front End eine oder mehrere parallele Ketten von signalverarbeitenden 

Modulen. Den so genannten Data Processors. Dadurch, dass mehrere Ketten unterstützt werden, 

können gleichzeitig verschieden Merkmale für ein einzelnes oder verschiedene Eingangssignale berechnet 

werden. Jede Ausgabe eines Data Processors kann einem anderen Data Processor wieder als Eingabe 

dienen. Dadurch werden beliebig lange Ketten ermöglicht. Der letzte Data Processor jeder Kette ist dafür 

verantwortlich, dass aus den verschiedenen Signalparametern ein Datenobjekt, der Merkmalsvektor, 

erstellt wird. Dieser kann dann vom Decoder weiter verarbeitet werden. [26]


5.1.3.2 Liguist 

Der Liguist erstellt den Search Graph. Dieser wird während der Suche vom Decoder genutzt. Natürlich 

ist auch der Linguist austauschbar und lässt sich dynamisch konfigurieren. Um den Search Graph 

zu erstellen nutzt der Linguist typischerweise die Sprachstruktur, die im Language Model angegeben 

wird und die topologische Struktur des Acoustic Model. Zusätzlich wird noch ein Dictionary oder Aussprachelexikon 

genutzt. Es bildet Worte aus dem Language Model auf Sequenzen von Elementen des 

Acoustic Model ab. Im Folgenden werden die drei Unterkomponenten des Liguist noch einmal näher 

beschrieben.[26] 

Language Model 

Das Language Model des Linguist bietet eine ’word-level’ Sprachstruktur. Das heißt, es arbeitet auf der 

Basis von ganzen Wörtern. Diese kann von einer Vielzahl auswechselbarer Implementationen dargestellt 

werden. Die Implementationen fallen in eine von zwei Kategorien, eine graphgesteuerte Grammatik 

oder ein stochastisches N-Gram Modell. Die Graphgesteuerte Grammatik repräsentiert einen gerichteten 

’Wort-Graphen’. Dabei steht jeder Knoten für ein Wort und jede Kante für die Wahrscheinlichkeit, dass 

dieser Übergang statt findet. Das stochastische N-Gram Model gibt an, wie wahrscheinlich ein Wort 

folgt, wenn die vorherigen n-1 Wörter beobachtet wurden. [26] 

Dictionary 

Das Dictionary liefert die Aussprache für Wörter die im Language Model vertreten sind. Die Aussprache 

teilt Wörter in Folgen kleinerer ’unter Worteinheiten’ auf, die im Acoustic Model aufgeführt sind. 

Das Dictionary ermöglicht es auch, die einzelnen Wörter zu klassifizieren. Dabei ist es Wörtern erlaubt 

zu mehrere Klassen zu gehören. Je nach Bedarf kann das Dictionary unterschiedlich optimiert und implementiert 

werden. Eine Möglichkeit währe zum Beispiel, das gesamte Vokabular zu laden, sobald das 

System initialisiert wird. Eine andere Möglichkeit besteht darin die Aussprachen immer erst bei Bedarf 

zu liefern. [26] 

Acoustic Model 

Das Acoustic Model liefert die Abbildung einer Spracheinheit auf ein Hidden Markov Modell (HMM). 

Dieses HMM kann mit Merkmalsvektoren verglichen werden, die vom Front End kommen. Dabei werden 

auch Kontextinformationen wie die Wortposition einbezogen. Im Fall von sogenannten Triphonen 

bedeutet Kontext, die einzelnen Phoneme links und rechts von einem betrachteten Phonem. Die Wortposition 

würde dann aussagen, ob das Triphon am Anfang, in der Mitte oder am Ende eines Wortes 

steht oder selbst ein Wort ist. Welche Kontextinformationen genau in Betracht gezogen werden, wird 

von Sphinx-4 nicht vorgegeben. Normalerweise teilt der Linguist jedes Wort des aktiven Vokabulars in 

Folgen kontextabhängiger Untereinheiten. Diese Einheiten und ihr Kontext werden dann an das Acou-


stic Model weiter gegeben. Daraus entstehen die HMM-Graphen der jeweiligen Einheiten. Danach wird 

aus diesen HMM-Graph, in Verbindung mit dem Language Model, der Search Graph konstruiert. Der 

Sphinx-4 HMM-Graph ist einfach ein gerichteter Objektgraph ohne feste Strukturen. Jeder Knoten korrespondiert 

mit einem HMM-Zustand und jede Kante gibt die Übergangswahrscheinlichkeit an. Dadurch 

können ganz einfach verschiedenste HMM’s mit unterschiedlichen Topologien geliefert werden. Es gibt 

keine Einschränkung bei der Anzahl der Zustände, der Anzahl der Übergänge oder ihrer Richtung. Ein 

HMM-Zustand kann die Bewertung für ein beobachtetes Feature erstellen. Was dabei genau berechnet 

wird, steht im HMM-Zustand selbst und wird vor dem System versteckt. Wie alles andere, kann auch 

das Acoustic Model an die Bedürfnisse des Nutzers angepasst werden. [26] 

Search Graph 

Der Linguist kann auf viele verschiedene Arten implementiert werden und die Topologien des von ihm 

generierten Suchraums variieren sehr. Trotzdem wird der Suchraum immer als Search Graph dargestellt. 

Der in Abbildung 5.3 gezeigte Search Graph stellt die primäre Datenstruktur dar, die für den Erkennungsprozess 

genutzt wird. In diesem gerichteten Graph steht jeder Knoten für einen festen oder fließenden 

Abbildung 5.3: Der Sphinx-4 Search Graph für ’one’ und ’two’ nach [26] 

Zustand. Fließende Zustände werden mit eintreffenden Features verglichen. Feste Zustände repräsentieren 

sprachliche Konstrukte auf einer höheren Ebene, wie Wörter und Phoneme. Diese werden nicht direkt 

mit eintreffenden Features verglichen. Die Kanten repräsentieren die möglichen Zustandsübergänge und 

ihre Wahrscheinlichkeit. Der Search Graph kann auf verschiedene Arten implementiert werden. Je nachdem 

wie er implementiert wurde, beeinflusst dies die Erkennungsgenauigkeit, die Geschwindigkeit und 

den Speicherbedarf. [26]


Implementation 

Es gibt verschiedene Implementationen für den Linguist. 

• Der Flat Liguist passt besonders bei Erkennungsaufgaben mit kontextfreien Grammatiken, finitestate 

Grammatiken, finite-state Wandlern und kleinen N-Gram Sprachmodellen. Alle diese externen 

Sprachmodelle werden in interne Grammatikstrukturen umgewandelt. Dabei entsteht ein 

gerichteter Wortgraph. Jeder Konten steht für ein Wort, jede Kante für die Übergangswahrscheinlichkeit. 

Aus der internen Grammatikstruktur wird direkt der Search Graph erzeugt und vollständig 

in den Speicher geladen. Dadurch ist der Flat Linguist zwar sehr schnell, hat aber Probleme bei 

Grammatiken mit hohem Verzweigungsgrad.[26] 

• Der Dynamic Flat Linguist ist dem Flat Linguist sehr ähnlich und damit auch für ähnliche Aufgaben 

geeignet. Der Hauptunterschied ist dabei, dass der Search Graph, je nach Bedarf, dynamisch 

konstruiert wird. Dadurch ist es zwar möglich mit weit komplexeren Grammatiken umzugehen, 

gleichzeitig wird aber die Erkennungsgeschwindigkeit reduziert.[26] 

• Der Lex Tree Linguist ist passend für alle Erkennungsaufgaben die große Vokabulare und N-Gram 

Sprachmodelle nutzen. Die Wörter werden in sogenannten Lex Trees organisiert. Dabei handelt 

es sich um eine kompakte Methode große Vokabulare darzustellen. Aus diesen Lex Trees werden 

dynamische ’Suchzustände’ generiert. So können sehr große Vokabulare bei nur mäßigem Speicheraufwand 

genutzt werden.[26] 

5.1.3.3 Decoder 

Die Hauptaufgabe des Decoders besteht darin, die Features, die vom Front End kommen, mit dem Search 

Graph des Linguist zu verknüpfen. Daraus generiert er dann Annahmen über das Ergebnis. Der Decoder 

umfasst einen austauschbaren Search Manager und anderen Code, der dabei hilft die Arbeit für die Anwendung 

zu vereinfachen. Der interessanteste Teil des Decoders ist der Search Manager. Der Decoder 

sendet ihm einfach die Anweisung, eine Anzahl von Features zu erkennen. In jedem Schritt des Erkennungsprozesses 

generiert der Search Manager ein Ergebnisobjekt. Es beinhaltet alle Pfade die einen 

finalen Zustand erreicht haben. Um das Ergebnis zu verarbeiten bietet Sphinx-4 Utilities. Mit ihrer Hilfe 

können Konfidenzmaße für die einzelnen Ergebnisse berechnet werden. Dabei wird der Anwendung die 

Möglichkeit gegeben, am Erkennungsprozess teil zu haben. 

Der Search Manager wird nicht auf eine bestimmte Implementation beschränkt. Jeder Search Manager 

nutzt einen Token-Algorithmus. Ein Sphinx-4 Token ist ein Objekt das mit einen Zustand innerhalb des 

Erkennungsprozesses in Zusammenhang steht. Es beinhaltet die gesamte akustische und sprachliche Be-


wertung eines Pfades an einem bestimmten Punkt innerhalb des Search Graph, eine Referenz auf den 

aktuellen Zustand, eine Referenz auf das eingegebene Merkmal und andere nützliche Informationen. 

Durch den Zustand kann der Search Manager einen Token mit seinem dazugehörigen Zustandsverlauf, 

den kontextabhängigen phonetischen Einheiten, Aussprachen, Wörtern und Grammatikzuständen in Verbindung 

bringen. Jede Teilannahme endet an einem aktiven Token. 

Sphinx-4 bietet ein sub-framework das Search Manager unterstützt die aus Active List, Pruner und Scorer 

bestehen. Die Active List wird aus allen, im Moment aktiven Token generiert. Dabei wird die Anzahl 

der aktiven Token reduziert, indem der Pruner Token löscht, die sich in einem Endzustand befinden, 

obwohl noch weitere Merkmalsvektoren eintreffen. Der Search Manager kommuniziert auch mit dem 

Scorer. Wenn eine Bewertung vom Scorer angefordert wird, bekommt dieser Zugriff auf den aktuellen 

Merkmalsvektor und führt darauf Berechnungen aus. [26] 

5.2 Microsoft Speech API 


Die Speech API wurde von Microsoft entwickelt um Spracherkennung und Sprachsynthese in Windows 

Anwendungen nutzbar zu machen. Alle Versionen wurden so entworfen, dass Software Entwickler nach 

belieben Anwendungen dafür schreiben können. Dazu wird ein standardisiertes Interfaces genutzt, auf 

das mit vielen verschiedenen Programmiersprachen zugegriffen werden kann. Außerdem können Fremdfirmen 

ihre eigenen Spracherkenner und TTS Engines erstellen oder existierende anpassen, um mit der 

SAPI zu arbeiten. Solange diese Engines konform zu den von Microsoft unterstützten sind, können sie 

auch an deren Stelle treten. Die Speech API ist frei weitergebbar und kann mit jeder Windows Anwendung 

vergeben werden, die Sprachtechnologien nutzen will. [24] 

Hier ein kurzer Überblick über Anwendungen, die die SAPI nutzen: 

• Microsoft Narrator in Windows 2000 und höher 

• Microsoft Office XP 

• Microsoft Windows XP für Tablet PC 

• Microsoft Agent 

• Microsoft Speech Server 

• Microsoft Voice Command 

• Microsoft Plus! Voice Command für den Windows Media Player


• Bonzi Buddy 

• Dragon Naturally Speaking 

• Adobe Reader 

[24] 

5.2.2 Aufbau 

Die SAPI verfügt über Spracherkennung und Sprachsynthese. Im Rahmen dieser Arbeit soll nur auf die 

Spracherkennung eingegangen werden. Die Abbildung 5.4 zeigt den Aufbau des Spracherkenners der 

Speech API. 

Abbildung 5.4: Aufbau des Speech API Spracherkenners nach [19] 

5.2.3 Funktion 

Die Spracheingabe des Nutzers wird zunächst digitalisiert. Diese Audiodaten werden dann im Frequenzanalysemodul 

in ein passenderes Format umgewandelt. Dies beinhaltet einen Großteil der Signalverarbeitung. 

Die größte Herausforderung besteht darin, die nützlichen Informationen aus dem Audiosignal 

zu extrahieren. Als nächstes werden die umgewandelten Daten durch das Phonemerkennungsmodul in 

Phoneme zerlegt. Dazu durchsucht das Modul eine ’Sound to Phonem’ Datenbank nach einem Phonem, 

das am ehesten dem Eingegebenen entspricht. Jeder Datenbankeintrag beinhaltet ein Template. Es beschreibt 

wie dieses Phonem klingt. Da das Vergleichen vieler Phoneme sehr lange dauern kann, gibt es 

das Phonemvorhersagemodul. Es reduziert die Anzahl der möglichen folgenden Phoneme in Bezug auf


den vorhandenen Kontext. So gibt es zum Beispiel Phoneme die nur sehr selten an Wortanfängen stehen 

oder Phoneme die nie oder nur selten aufeinander folgen. Trotz dieser Verbesserung dauert die Spracherkennung 

noch zu lange. Um die Liste der möglichen Phonemkandidaten weiter zu verkleinern gibt es 

zusätzlich die Wortvorhersagedatenbank. Mit ihrer Hilfe werden Phoneme eliminiert, die keine gültigen 

Wörter ergeben. Indem man das Vokabular zusätzlich noch auf die Wörter beschränkt, die man wirklich 

benötigt, kann man die Erkennungsgeschwindigkeit weiter erhöhen. Sobald Phoneme erkannt sind, 

werden sie in Wörter geparst, in Text Strings umgewandelt und an die Anwendung weiter gegeben.[19] 

5.3 jlab Speech Server 


Der jlab Speech Server wurde im Jahre 2003 am Institut für Akustik und Sprachkommunikation (IAS) 

der TU Dresden entwickelt und seit dem immer weiter verbessert. Obwohl jlab unter frei verfügbare 

Spracherkenner aufgeführt ist, darf er nur mit Genehmigung des IAS genutzt werden und ist nur dort erhältlich. 

Der Erkenner arbeitet ausschließlich auf deutsch. Die Erkennung läuft sprecherunabhängig ab, 

wodurch ein zeitraubendes Eingangstraining für den Nutzer entfällt. Dadurch ist der jlab Speech Server 

ist immer sofort einsetzbar. Um die Erkennungsrate zu verbessern, sollten Wörterbücher mit den Sprachkommandos 

so klein wie möglich gehalten werden, so dass immer nur das minimal nötige Vokabular 

geladen ist. Damit keine Verzögerungen auftreten ermöglicht der jlab Speech Server einen schnellen 

Wechsel zwischen den Wörterbüchern. 

Auf Basis des jlab Speech Servers wurden unter anderem schon die Diplomarbeiten ’Sprachsteuerung 

eines Computerspiels - Untersuchungen zur Leistungsfähigkeit und Ergonomie’ [20] und ’Konzeption, 

Realisierung und Evaluation einer multimodalen Benutzungsoberfläche für PDA-basierte Software’ [22] 

verfasst, sowie eine Web-basierte Lernumgebung entwickelt. [27] 

5.3.2 Aufbau 

Der Grobaufbau des jlab Speech Server wird in Abbildung 5.5 gezeigt. Er kümmert sich um das Sitzungs- 

, Netzwerk- und Sicherheitsmanagement und bietet Dienste zur Sprachsynthese, Sprechererkennung und 

Spracherkennung. Im Folgenden wird es aber nur um die Spracherkennung gehen. Zum Speech Server 

gehört natürlich noch ein Client, der je nach Anwendung erstellt werden muss. Er ist dafür zuständig, 

beim Server eine neue Sitzung zu registrieren und das genutzte Vokabular, sowie alle Spracheingaben an 

den Server zu übermitteln. Außerdem muss er noch auf die Erkennungsergebnisse reagieren. [27]


Abbildung 5.5: Die jlab Speech Server Architektur nach [27] 

5.3.3 Funktion 

Bevor mit der Spracheingabe begonnen werden kann, muss der Client dem Server ein Vokabular übergeben. 

Darin finden sich die zu erkennenden Befehle und verschiedene Rückweisungswerte. Genauere 

Informationen zum Vokabular finden sich in Abschnitt 5.3.4. Aus dem Vokabular erstellt Server nun ein 

Erkennungsnetzwerk. Außerdem steht dem Erkenner das akustische Model der Eingabesprache zur Verfügung. 

Um nun eine Eingabe zu erkennen wird das Sprachsignal in einem ersten Schritt, durch verschiedene 

Filter analysiert. Dadurch entsteht eine Folge von Merkmalsvektoren, die das Signal beschreiben. 

Mit Hilfe des akustischen Models wird aus der Vektorfolge eine Netzwerk aus möglichen Phonemfolgen 

erstellt. Aus diesem Netzwerk wiederum, werden unter Zuhilfenahme des Erkennungsnetzwerks die 

Erkennungsergebnisse generiert. Außerdem werden Vertraulichkeitswerte berechnet, die angeben wie 

sicher sich der Erkenner bei den einzelnen Ergebnissen war. In einem letzten Schritt werden all diese 

Ergebnisse bezüglich ihres Vertraulichkeitswertes und der im Vokabular angegeben Rückweisungswerte 

ausgewertet. Am Ende wurden entweder alle Ergebnisse verworfen oder das endgültige Ergebnis an den 

Client gesandt. [27] 

5.3.4 Vokabular 

Vokabulare in jlab werden in einfachen txt-Dateien angegeben die je nach Bedarf in den Erkenner geladen 

werden. Ein Vokabular besteht dabei aus mehreren Befehlszeilen. Jede Zeile enthält an erster Stelle 

die orthographische Beschreibung des Befehls. Dieser Wert wird, neben verschiedenen statistischen Ergebnissen, 

vom Erkenner zurück geliefert. Er kann sich auch in mehreren Zeilen wiederholen, was als 

verschiedene Aussprachevarianten ein und des selben Befehls interpretiert wird. An zweiter Stelle wird


Abbildung 5.6: Vereinfachtes Ablaufschema nach [27] 

der Befehl oder die Befehlswortgruppe in Phonemschrift angegeben. Die entsprechende Übersetzungstabelle 

ist im Glossar zu finden. Das Übersetzen in Phonemschrift ist für ungeübte Personen jedoch recht 

schwierig und bedarf daher einiger Übung. Danach folgt das Wortgewicht, an dritter Stelle. Es ist optional 

und kann Werte von 0 bis 100 annehmen. Das Wortgewicht wird genutzt, wenn für einen tatsächlich 

eingegebenen Befehl mehrere Erkennungsergebnisse möglich währen. Das Ergebnis mit dem höchsten 

Wortgewicht wird zurückgegeben. Auch die Werte an den Stellen vier und fünf sind optional. Die hier 

angegebenen Wert müssen von einem möglichen Erkennungsergebnis unterboten werten, damit es akzeptiert 

wird. Für gute Ergebnisse sollte der vierte Wert (NAD) maximal 0.05 und der fünfte Wert (NED) 

maximal 0.5 annehmen. Genauere Angaben zu NAD und NED sind im Glossar zu finden. Abbildung 5.7 

zeigt den Aufbau eines solchen Vokabulars für jlab. 

5.3.5 Test 

In Kapitel 6 wird versucht, allen drei Erkenner mit Hilfe eines einheitlichen Tests zu vergleichen, soweit 

das möglich ist. In diesem Abschnitt hingegen wird ein speziell auf jlab zugeschnittener Test durchgeführt. 

Dazu wurde ein Vokabular aus 160 Befehlen zusammengestellt. Dieses Gesamtvokabular besteht 

aus 80 Befehlen die zur Steuerung der Benutzeroberfläche von Windows genutzt werden könnten und jeweils 

40 Befehlen mit denen ein Spiel kontrolliert oder ein Textverarbeitungsprogramm bedient werden 

könnte. Um den Erkenner dauerhaft unter gleichen Bedingungen testen zu können wurde eine Sprachbibliothek 

aufgenommen. Sie beinhaltet alle 160 Befehle jeweils ein mal von einem weiblichen und


Abbildung 5.7: Aufbau eines jlab Vokabulars 

männlichen Sprecher aufgenommen. Getestet wurde die Erkennungsrate und -geschwindigkeit. In den 

Abbildungen 5.8 und 5.9 sind die Ergebnisse für verschiedene akustische Modelle, die jlab unterstützt, 

zu sehen. 

Abbildung 5.8: Worterkennungsrate 

Aus den Ergebnissen geht hervor, dass jlab mit dem akustischen Modell 1_3_19 eine Worterkennungsrate 

von über 98Prozent erreicht. Dies entspricht einem sehr guten Ergebnis. Der zu diesem Wert gehörige 

Echtzeitfaktor von etwa 1,1 ist für kurze Befehlswörter geeignet. Bei längeren Befehlswortgruppen 

könnte es zu erkennbaren Verzögerungen kommen.


Abbildung 5.9: Der Echtzeitfaktor, bezogen auf die Dauer des Eingabesignals

6. TESTS 41 

6 Tests 

Alle drei Systeme in einem umfassenden Test zu vergleichen ist aufgrund ihrer gravierenden Unterschiede 

nicht einfach möglich. Normalerweise müsste man allen drei Erkennern das gleiche Vokabular 

vorgeben und sie mit den gleichen Sprachdaten testen. Ein Problem hierbei ist, dass nicht alle drei die 

selbe Sprache unterstützen. Durch die großen Unterschiede zwischen verschiedenen Sprachen und ihrer 

Repräsentation in den Spracherkennern ist ein einheitliches Vokabular nicht möglich. Auch die Tatsache 

das zwei der Systeme nur einzelne Befehlswörter oder Befehlswortgruppen erkennen und eines 

auch kontinuierliche Sprache unterstützt erschwert einen gerechten Vergleich. Kontinuierliche Sprache 

ist weitaus schwieriger als diskrete Spracheingabe zu erkennen. Zu guter Letzt ist eines der Systeme 

sprecherabhängig, was ihm einen Vorteil gegenüber den anderen Systemen verschafft. Trotz dieser Unterschiede 

werden hier einige Tests vorgenommen. Mit Hilfe der Testergebnisse sollen zunächst einige 

Vorteile und Nachteile der drei Systeme herausgefunden werden. Am Ende sollen, wo dies möglich ist, 

auch Vergleiche zwischen den einzelnen Systemen gezogen werden. 

6.1 Worterkennungsrate für Sprachsteuerung 

Die Worterkennungsrate für jedes System wird mit Hilfe einer der zugehörigen Beispielanwendungen 

getestet. Jede Eingabe wird dazu fünf mal wiederholt um die verschiedenen Aussprachegeschwindigkeiten 

und Betonungen mit in den Test einfließen zu lassen. An dieser Stelle noch der Hinweis, dass es 

sich in diesem Abschnitt eigentlich immer um Befehlswortgruppen und nicht um einzelne Befehlswörter 

handelt. Trotzdem wird weiterhin von Worterkennungsrate gesprochen und jede Befehlswortgruppe als 

ein einzelnes Wort angesehen. 

6.1.1 Sphinx 

Um Sphinx zu testen wird die mitgelieferte Sphinx-4 Dialog Demo genutzt. Es handelt sich hierbei um 

eine Menüsteuerung. Anstelle eines großen Gesamtvokabulars gehört zu jedem Menüpunkt ein einzelnes 

Vokabular. In Tabelle 6.1 ist dargestellt wie viele Einträge zu dem jeweiligen Menüpunkt gehören und

6. TESTS 42 

wie hoch die Worterkennungsrate in den einzelnen Menüs ist. Jeder Befehl wurde dazu fünf mal wiederholt. 

Außerdem wurden nur ein Teil der möglichen Menüpunkte ausgewählt, die geeignet sind, einen 

Überblick zu geben welche Erkennungsraten bei welcher Vokabulargröße zu erwarten sind. Natürlich 

Menüpunkt Anzahl richtig nicht verwechselt Worterkennungsrate 

der Befehle erkannt erkannt in Prozent 

Musik 31 90 24 40 58,06 

Anrufe 24 83 10 27 69,17 

Spiele 18 62 13 15 68,89 

eMail 13 58 3 4 89,23 

Hauptmenü 11 43 4 8 78,18 

Tabelle 6.1: Worterkennungsrate einiger Menüs der Sphinx-4 Dialog Demo 

sind diese Daten mit Vorsicht zu betrachten. Zunächst ist Sphinx für sprecherunabhängiges Erkenner gedacht. 

Darum wäre es von Vorteil gewesen noch die Daten von anderen Sprechern zu haben um objektive 

Werte zu erhalten. Außerdem versteht dieser Erkenner nur die englische Sprache. Ein Muttersprachler 

hätte somit wahrscheinlich noch eine etwas bessere Worterkennungsrate erzielen können. Des weiteren 

schient es, als ob der Erkenner besser damit zurecht kommt, wenn man die Pausen zwischen den 

einzelnen Wörtern einer Befehlswortgruppe etwas verlängert. 

6.1.2 JLab 

Im Kapitel 5.3.5 wurden schon einmal Testdaten von JLab gezeigt. Um einen besseren Vergleich mit 

Sphinx zu erreichen wurden im einige zusätzliche Vokabulare erstellt. Diese orientieren sich stark an den 

Befehlswörterbüchern der Sphinx-4 Dialog Demo. Der Zweck besteht darin, die Befehle in ihrer Länge, 

Anzahl und Ähnlichkeit untereinander, denen des Sphinx Tests anzugleichen. So soll trotz der unterschiedlichen 

Sprache ein möglichst guter Vergleich zustande kommen. In Tabelle 6.2 werden die Testergebnisse 

dargestellt. Auch in diesem Test wurde jeder Befehl fünf mal eingegeben. Der JLab Speech 

Server erreicht in fast allen Menügrößen deutlich bessere Erkennungsraten. Diese Werte sind jedoch 

nicht vollständig vergleichbar. Die eigenhändig erstellten Vokabulare für JLab sind nicht optimiert. Das 

heißt die Rückweisungsschwelle für die einzelnen Befehle ist so gering, das beinahe jede Eingabe am 

Ende auch wirklich als ein Befehl erkannt wird. Aus diesem Grund sind auch nur Verwechslungsfehler 

in der Tabelle zu finden. Das ist kein Problem wenn man den Erkenner nur einschaltet wenn man auch 

wirklich einen Befehl gibt (siehe Abschnitt 2.3.1.1 Push to Talk). Es erschwert aber den Vergleich mit 

Sphinx, da dort versucht wird wirklich nur auf echte Befehle zu reagieren.

6. TESTS 43 

Menüpunkt Anzahl richtig verwechselt Worterkennungsrate 

der Befehle erkannt in Prozent 

Musik 31 127 28 81,94 

Anrufe 24 98 22 81,67 

Spiele 18 80 10 88,89 

eMail 13 56 9 86,15 

Hauptmenü 11 52 3 94,55 

Tabelle 6.2: Worterkennungsrate von JLab 

6.1.3 SAPI 

Um die Microsoft Speech API zu testen wurde die zugehörige Anwendung Dictation Pad genutzt. Sie 

ist ursprünglich für kontinuierliche Spracheingabe gedacht und nutzt ein sehr umfangreiches englisches 

Grundvokabular. Diese Anwendung wurde gewählt, da man dem Vokabular eigene Einträge hinzufügen 

kann. So ist zumindest gewährleistet, dass Testvokabular der Sphinx-4 Dialog Demo eins zu eins 

übernommen werden kann. Im ’erweiterten Vokabular’ des Dictation Pads war zu jeder Zeit nur das 

Vokabular eines der Menüpunkte aktiv um weiter störende Einflüsse zu vermeiden. Natürlich resultieren 

aus dieser Wahl auch Probleme auf die später eingegangen wird. In Tabelle 6.3 werden zunächst 

die Testergebnisse gezeigt. Wieder wurde jeder Befehl fünf mal gegeben. Aus den Testergebnissen ist 



Musik 31 85 70 54,84 

Anrufe 24 107 13 89,17 

Spiele 18 86 4 95,56 

eMail 13 57 8 87,69 

Hauptmenü 11 50 5 90,91 

Tabelle 6.3: Worterkennungsrate des Dictation Pad (trainiert) 

ersichtlich, dass alle Fehler der SAPI auf Verwechslungen zurück zu führen sind. Die Ursache dafür ist 

allerdings nicht, wie bei JLab, eine zu niedrige Rückweisungsschwelle. Das Problem ist hier vielmehr, 

dass neben dem extra erstellten Wörterbucheinträgen, während des Tests auch noch alle anderen Wörter 

aus dem allumfassenden Sprachvokabular aktiv genutzt wurden. Besonders gravierend war dieser 

Einfluss im Untermenü ’Musik’. Durch die besonders langen Befehlswortgruppen kam es hier sehr häu-

6. TESTS 44 

fig zu Verwechslungen. In einer Umgebung in der nur das wirklich benötigte Vokabular genutzt wird, 

kann dem nach eine bedeutend höhere Worterkennungsrate erreicht werden. Ein weiteres Problem für 

den Vergleich besteht darin, dass die SAPI sprecherabhängig arbeitet. In diesem Fall war der Erkenner 

durch eine vorab Trainingszeit von insgesamt etwa 60 Minuten besonders auf meine Stimme trainiert 

und um einen neuen Vokabulareintrag hinzuzufügen musst dieser ebenfalls noch einmal eingesprochen 

werden. Das sollte dem Erkenner normalerweise einen Vorteil verschaffen. Eine interessante Frage besteht 

darin, welchen Einfluss die Sprecherabhängigkeit auf die Erkennungsrate hat. Im Folgenden wird 

der gesamte Test noch einmal mit einem Sprecher wiederholt, auf den Erkenner vorher nicht trainiert 

wurde. Erschwerend kommt hinzu, dass es sich nun um eine Sprecherin handelt, der Erkenner ist jedoch 

weiter auf einen männlichen Sprecher eingestellt. Das Ergebnis dieser Testreihe ist in Tabelle 6.4 zu sehen. 

Dabei hat der Erkenner in allen Bereichen deutlich schlechter abgeschnitten. Auch bei diesem Test 



Musik 31 46 109 29,68 

Anrufe 24 37 83 30,83 

Spiele 18 71 19 78,89 

eMail 13 29 36 44,61 

Hauptmenü 11 33 22 60 

Tabelle 6.4: Worterkennungsrate des Dictation Pad (untrainiert) 

gibt es wieder einen besonders abweichenden Wert. Diesmal ist es die Erkennungsrate für den Menüpunkt 

Spiele, die eine deutlich bessere Erkennungsrate als alle anderen aufweist. Trotzdem wäre sie für 

einen Einsatz in Anwendungen nicht ausreichend. Aus den Ergebnissen kann man klar ablesen, dass die 

Sprecherabhängigkeit einen sehr großen Einfluss auf die Worterkennungsrate hat. Es macht also wenig 

Sinn zu versuchen eine Anwendung, die sprecherunabhängig sein soll, mit einen sprecherabhängigen 

Erkenner zu erstellen. 

6.1.4 Vergleich 

Um die verschiedenen Systeme noch einmal direkt gegenüber zu stellen werden in Tabelle 6.5 die einzelnen 

Worterkennungsraten und ein Durchschnittswert angegeben. Bei der Dialog Demo kann man gut die 

Abhängigkeit von Vokabulargröße und Worterkennungsrate erkennen. Der beste Wert von 89,23Prozent 

ist allerdings immernoch zu niedrig. Wenn man selbst eine Anwendung auf der Basis von Sphinx erstellt 

kann man daran aber noch Verbesserungen vornehmen. Der JLab Speech Server hingegen hält einen

6. TESTS 45 

Menüpunkt Sphinx4 JLAB Microsoft SAPI 

Dialog Demo Speech Server Dictation Pad 

Musik 58,06 81,94 54,84 

Anrufe 69,17 81,67 89,17 

Spiele 68,89 88,19 95,56 

eMail 89,23 86,15 87,69 

Hauptmenü 78,18 94,55 90,91 

Durchschnitt 72,71 86,5 83,63 

Tabelle 6.5: Worterkennungsraten aller drei Anwendungen in Prozent 

relativ konstante Worterkennungsrate über alle Vokabulargrößen. Das zeigt das er auch bei größeren Vokabularen 

noch gut funktioniert. Außerdem liefert er im Durchschnitt das beste Ergebnis ab. Für den Test 

stand leider nur die Version 1.3.5 des JLab Sprachmodells zur Verfügung. Mit der verbesserten Version 

1.3.19 könnte noch einmal eine kleine Verbesserung erreicht werden. Durch eine Optimierung des 

Vokabulars kann auch die Häufigkeit von Verwechslungen reduziert und somit die Worterkennungsrate 

gesteigert werden. Dies stellt das größte Verbesserungspotenzial dar, da am Testvokabular nur Standardwerte 

eingestellt waren. Dictation Pad belegt mit einer durchschnittlichen Worterkennungsrate von 

83,63Prozent in diesem Abschnitt zunächst den zweiten Platz. Wenn man die einzelnen Werte betrachtet 

fällt allerdings sofort die besonders schlechte Wertung im Menüpunkt Musik auf. In Anbetracht der der 

Tatsache, das es bei diesem Menüpunkt um sehr lange Befehlswortgruppen handelte und der Erkenner 

mit einem viel größeren Vokabular umgehen musste, besteht jedoch eine besonders hohe Verwechslungsgefahr. 

Lässt man diesen Ausreißer einmal außer Betracht erreicht Dictation Pad eine durchschnittliche 

Worterkennungsrate von 90,83Prozent. Wenn man eine eigene Anwendung auf Basis des Speech API 

erstellt, kann man auch eigene Vokabulare anlegen. Dadurch können Verwechslungsfehler im Vergleich 

zum Dictation Pad erheblich reduziert werden. 

Die Ergebnisse dieser Tests zeigen, dass man JLAB und SAPI bezüglich der Worterkennungsrate in etwa 

gleich stark einordnen kann und ihre Ergebnisse durch angesprochenen Verbesserungen noch ausbauen 

kann. Sphinx hingegen erhält eine schlechtere Bewertung. Dabei ist besonders der negative Einfluss der 

Vokabulargröße auf die Worterkennungsrate ein Problem.

6. TESTS 46 

6.2 Worterkennungsrate für Diktieranwendungen 

Für Sphinx und JLab ist an dieser Stelle kein Test möglich, da es sich ausschließlich um diskrete Spracherkenner 

handelt. Trotzdem ist dieser Test interessant um die tatsächliche Leistungsfähigkeit der Microsoft 

Speech API am Beispiel der Dictation Pad Anwendung besser beurteilen zu können. In diesem 

Test werden zwei etwa gleichlange Texte diktiert und die Worterkennungsrate gemessen. Bei dem ersten 

Text handelt es sich um einen der Trainingstexte der SAPI, bei dem zweite Text um fiktive Geschichte. 

Die Ergebnisse sind in Tabelle 6.6 zu sehen. Das für beide Texte etwa die gleiche Rate gemessen wur- 

Text Wortzahl nicht oder Worterkennungsrate 

falsch erkannt in Prozent 

Aesop’s Fabeln 864 260 69,91 

fiktive Geschichte 917 305 66,74 

Tabelle 6.6: Ergebnisse für die Diktieranwendung der SAPI 

de zeigt, das der Erkenner nach genügend Trainingszeit, bekannte wie unbekannte Texte gleichermaßen 

gut erkennt. Leider ist eine Erkennungsrate von maximal siebzig Prozent nicht annähernd ausreichend. 

Sicher könnte auch bei diesem Test ein Muttersprachler noch bessere Werte erzielen, aber selbst eine 

Worterkennungsrate von 90 oder 95 Prozent ist für eine Diktieranwendung noch zu wenig.

7. AUSWAHL EINES SPRACHERKENNERS 47 

7 Auswahl eines Spracherkenners 

In diesem Abschnitt werden noch einmal kurz die Vorteile und Nachteile der einzelnen Erkenner angesprochen. 

Auf dieser Basis wird einer von ihnen für die Implementation einer vereinfachten Schnittstelle 

ausgewählt. 

Bei CMU Sphinx handelt es sich um eine Arte Baukasten für Spracherkenner. Der Entwickler erhält 

so die Möglichkeit, einen eigenen Spracherkenner nach seinen Bedürfnissen zu erstellen. Dadurch ist 

das Ergebnis sehr flexibel in seiner Funktionalität. Man benötigt keine Trainingsphase bevor man beginnen 

kann damit zu arbeiten. So ist ein schneller Wechsel zwischen verschiedenen Nutzern und sogar 

die gleichzeitige Verwendung durch mehrere Nutzer möglich. Leider handelt es sich bei CMU Sphinx 

nicht um einen fertigen Spracherkenner, sondern wie schon erwähnt um eine Art Baukasten. Das heißt, 

man müsste den endgültigen Erkenner erst konzipieren und entwickeln, bevor man ihn in irgendeine andere 

Anwendung integrieren kann. Ein weiterer Nachteil besteht darin, dass auch bei den vorhandenen 

Beispielen die Erkennungsrate nicht besonders gut war. 

Die Microsoft Speech API ist schon ein fertiges System. In einer Vielzahl von Beispielanwendungen 

wird gezeigt, wie exakt der Erkenner arbeiten kann. Er wird sogar in einer Diktieranwendung genutzt, 

die freie Texte erkennt, also mit großen Vokabularen umgehen kann. Natürlich besteht die Möglichkeit in 

der eigenen Anwendung auch ein eigenes, kleineres Vokabular zu definieren, wodurch die Erkennungsrate 

noch verbessert werden kann. Standardmäßig unterstützt die SAPI 5.1 U.S. Englisch. Außerdem 

kann man noch Paket für verschiedene andere Sprachen nachladen. Zusätzlich zu den Beispielanwendungen 

bekommt man noch einige Tutorials geboten. In ihnen wird gezeigt, wie man die SAPI in die 

eigenen Anwendungen integriert. Der Nachteil der SAPI von Microsoft besteht allerdings darin, dass vor 

Beginn der Arbeit eine Trainingsphase für den Erkenner nötig ist. Je nachdem wieviel Zeit man sich dabei 

nimmt und wieviele der möglichen Trainingssitzungen man absolviert, wird die Wahrscheinlichkeit 

erhöht, dass die erkannten Worte auch die gesprochenen sind. Somit ist es nicht möglich sofort mit der 

Arbeit zu beginnen. Dazu kommt noch, dass die SAPI nur für einen Benutzer je Gerät gedacht ist. Es 

wird also ein globales Profil angelegt. Dieses Profil wird für jede Anwendung, die mit der SAPI arbeitet 

geladen. Mehrere Profile sind nicht möglich. Man kann zwar trotzdem mehrere Nutzer an einem System 

arbeiten lassen, aber da sich dabei das Sprecherprofil jedes mal gravierend ändert, ist dann kein optimales


Ergebnis möglich. 

Auch der jlab SpeechServer des IAS bietet einen fertigen Spracherkenner. Dieser arbeitet auf Kommandozeilenebene 

und besitzt schon vordefinierte Schnittstellen. Es gibt eine fertige in JAVA geschriebene 

Anwendung, bestehend aus einem dem Server und einer Client-Webseite, auf der der Server getestet 

werden kann. Dort können unter anderem Vokabulare geladen werden, man kann eigene Spracheingaben 

machen und die eigenen Vokabulare mit Hilfe von Sprachaufnahmen automatisch längeren Tests unterziehen. 

Der Speech Server ist allerdings nur auf die deutsche Sprache trainiert. Die Antwortzeiten sind 

zwar recht lang, je nachdem, wie gut man das Vokabular eingestellt hat, liefert der SpeechServer aber 

gute Erkennungsergebnisse. Darin liegt auch der besondere Vorteil des SpeechServers, da nie eine Trainingsphase 

nötig ist. Der Server kann auf Kommandozeilenebene initialisiert werden. Dort muss man 

lediglich einen Pfad für die Konfigurationsdatei und eine Session ID angeben. Optional sind auch noch 

weitere Einstellungen möglich. Danach kann man mit Hilfe einiger weniger Funktionen neue Vokabulare 

laden, Sprachdaten an den Server senden und bekommt die entsprechenden Erkennungsergebnisse 

zurück. 

Die Ergebnisse werden noch einmal in Tabelle 7.1 dargestellt. 

Erkenner CMU Sphinx Microsoft Speech API jlab SpeechServer 

bereit zur Nutzung nein ja ja 

Sprache englisch versch. Sprachen mögl. deutsch 

Spracheingabe diskret diskret diskret 

kontinuierlich 

Eingangstraining nein ja nein 

Mehrbenutzerbetrieb ja nein ja 

Erkennungsergebnis mittelmäßig gut gut 

(sehr gut mit Training) 

Tabelle 7.1: Übersicht über die Eigenschaften von CMU Sphinx, MS SAPI und jlab 

Da für Sphinx der eigentliche Erkenner erst erstellt werden muss und die Erkennungsergebnisse in den 

Beispielen nicht überragend waren, kommt dieser Erkenner nicht in die engere Wahl für eine Schnittstelle. 

Die Entscheidung zwischen der SAPI und jlab fällt hingegen schon schwerer. Jlab bietet zwar etwas bessere 

Erkennungsergebnisse, dafür ist das Erstellen des Vokabulars in Phonemschrift besonders schwierig 

und die Eingabe auf die deutsch Sprache beschränkt. Durch die höhere Erkennungsgeschwindigkeit und 

bessere Dokumentation fällt die Wahl am Ende auf die SAPI von Microsoft. Im folgenden Kapitel wird


eine vereinfachte Schnittstelle für die SAPI entwickelt, die der Programmsteuerung dienen soll.

8. ENTWICKLUNG EINER SCHNITTSTELLE AUF BASIS DER MICROSOFT SPEECH API 50 

8 Entwicklung einer Schnittstelle auf Basis der 

Microsoft Speech API 

In den vorangegangenen Kapiteln wurden die drei freien Spracherkenner verglichen und mit diesen Ergebnissen 

einer der Erkenner ausgewählt, auf dessen Basis nun eine Schnittstelle erstellt wird. Dieses 

Kapitel beginnt mit den Anforderungen, die an diese Schnittstelle gestellt werden. Danach werden einige 

Begriffe erklärt und der Aufbau eines Vokabulars beschrieben. Zum Abschluss wird mit Hilfe dieser 

Schnittstelle eine Beispielanwendung erstellt und mit ihr einige Tests durchgeführt. um die Schnittstelle 

mit den früheren Ergebnissen vergleichen zu können. 

8.1 Anforderungen an die Schnittstelle 

Um möglichst schnell und ohne großen Einarbeitungsaufwand, Spracherkennung in eine Anwendung 

einzubauen, sollte eine vereinfachte Schnittstelle entwickelt werden. Sie sollte ohne komplexe Datentypen 

auskommen und alle SAPI spezifischen Abhängigkeiten verdecken. Ausgehend von diesen Anforderungen 

sind folgende Funktionalitäten nötig: 

1. Starten und Beenden des Spracherkenners 

2. Einlesen eines vollständigen Vokabulars 

3. Schrittweises Erstellen eines Vokabulars 

4. Steuerung des Spracherkenners 

5. Spracheingaben verarbeiten 

Da die SAPI nicht der einzige frei verfügbare Spracherkenner ist, sollte die Möglichkeit bestehen auch 

andere Spracherkenner anzubinden. Aus diesem Grund wurde zusätzlich die abstrakte Klasse speech_input 

erstellt. Sie bietet die oben genannten Funktionalitäten ohne auf einen konkreten Spracherkenner einzugehen. 

Basierend auf dieser abstrakten Klasse wurde die Klasse microsoft_speech_input erstellt. Sie 

stellt die SAPI spezifische Implementierung dar. Eine vollständige Dokumentation dieser Schnittstelle 

findet sich im Verzeichnis project/src/doc auf der CD zum Beleg.


8.2 Begriffserklärungen im Zusammenhang mit der Schnittstelle 

In diesem Kapitel werden einige Begriffe erklärt, die im Zusammenhang mit der Schnittstelle und ihrer 

Implementierung von Bedeutung sind. 

8.2.1 Die Grammatik 

Die Beschreibung der Befehle und die Zusammenhänge zwischen den Befehlen bilden innerhalb der 

SAPI die Grammatik. Während der gesamten Laufzeit einer Anwendung, die diese Schnittstelle nutzt, 

kann es nur eine einzige Grammatik geben. Sie beinhaltet alle momentan vorhandenen Regeln sowie alle 

ihnen zugeordneten Befehle. Es existieren zwei Wege, eine Grammatik zu erstellen. Bei der ersten Variante 

wird die Grammatik Schritt für Schritt aus Regeln und Befehlen aufgebaut. Die Abschnitte ’Regeln 

und Menüs’ und ’Der Befehl’ beschrieben das jeweilige Vorgehen genauer. Wurde die Grammatik auf 

diese Art geändert, müssen die Änderungen durch Aufrufen der Funktion finalize_grammar festgeschrieben 

werden. Die zweite Möglichkeit besteht darin, eine Grammatik vollständig aus einem Vokabular zu 

laden. Im Abschnitt ’Das Vokabular’ wird darauf näher eingegangen. Im den Inhalt einer Grammatik 

vollständig zu löschen ist die Funktion clear_grammar vorgesehen. 

8.2.2 Regeln und Menüs 

Der Begriff Regel stammt noch aus der SAPI selbst. Eine Regel beschriebt dort alle Kombinationen von 

Spracheingaben, die von der SAPI erkannt werden können. Dabei musste es sich aber nicht zwangsläufig 

auch um konkrete Befehle handeln. Für die vereinfachte Schnittstelle wurden diese Möglichkeiten allerdings 

weggelassen, so dass eine Regel nur noch Befehle enthält. Aufgrund dieser Einschränkung, und 

weil eine Regel im Prinzip ein Menü darstellt, deren Befehle die Menüoptionen sind, wird innerhalb der 

Schnittstellenimplementation der Begriff ’menu’ anstelle von ’regel’ oder ’rule’ genutzt. Im Rest dieses 

Kapitels werden die Begriffe Regel und Menü analog verwendet und beziehen dabei sich immer auf die 

Implementation in der vereinfachten Schnittstelle. 

Um der Grammatik ein neues Menü hinzuzufügen wird die Funktion add_menu genutzt. Ihr werden als 

Parameter der Index, der initale Status, und der Name des Menüs übergeben. Der Index und der Name 

der Regel müssen jeweils eindeutig sein. Sie werden dazu genutzt, einen erkannten Befehl eindeutig zu 

identifizieren. Die Funktionen get_menu_index und get_menu_name können dazu genutzt werden, die 

entsprechenden Werte für den letzten erkannten Befehl zu ermitteln. Der initiale Status eines Menüs wird 

mit true für aktiv und false für inaktiv angegeben. Er sagt aus, ob die Regel direkt nach dem Erstellen 

sowie nach jedem weiteren Aufruf der Funktion finalize_grammar aktiv sein soll.


Nur Befehle die zu Regeln gehören deren Status ’aktiv’ ist können erkannt werden. Um ein Regel zu 

aktivieren können die Funktion activate_menu_index und activate_menu_name verwendet werden. Es 

ist allerdings nicht vorteilhaft immer alle Menüs aktiv zu lassen. Damit man ein Menü also auch wieder 

deaktivieren kann stehen die Funktionen deactivate_menu_index und deactivate_menu_name zur Verfügung. 

Dadurch wird Wahrscheinlichkeit reduziert, dass Spracheingaben verwechselt werden. 

Falls nötig können aus einer Regel auch alle Befehle gelöscht werden indem man erneut die Funktion 

add_menu mit dem entsprechenden Index aufruft. Der Name der Regel hat darauf allerdings keinen 

Einfluss und ändert sich auch dann nicht, wenn man beim Aufruf der Funktion einen neuen Namen 

angibt. 

8.2.3 Der Befehl 

Jede Spracheingabe, die erkannt werden kann, wird als Befehl bezeichnet. Der Begriff umfasst dabei 

sowohl Befehle die nur aus einem einzigen Wort bestehen als auch Befehlswortgruppen. 

Mittels der Funktion add_command wird der Grammatik ein neuer Befehl hinzugefügt. Bei den übergebenen 

Parametern handelt es sich um den Menüindex, die Spracheingabe, den Befehlsindex sowie 

den Name des Befehls. Der Menüindex gibt an zu welchem Menü der neue Befehl hinzugefügt werden 

soll. Der Name und der Index eines Befehls identifizieren ihn innerhalb seines Menüs eindeutig. Die 

Spracheingabe gibt an, was gesagt werden muss um den entsprechenden Befehl auszulösen. Natürlich 

kann es vorkommen das verschiedene Spracheingaben den selben Befehl auslösen sollen. Zum Beispiel 

könnten die Eingaben ’exit program’, ’close program’ und ’end program’ alle die gleiche Wirkung verfolgen. 

Um dies zu realisieren muss für jede Spracheingabe erneut die Funktion add_command, mit dem 

gleichen Menü- und Befehlsindex aufgerufen werden. 

Um heraus zu bekommen welcher Befehl in der letzten Spracheingabe aufgerufen wurde, können die 

Funktionen get_menu_name und get_command_index aufgerufen werden. Falls nur eine Regel existieren 

sollte ist das ausreichend. Wenn mehrere Regeln existieren und gleichzeitig aktiv sind sollten noch 

entweder der Regelname oder der Regelindex abgefragt werden um einen Befehl eindeutig zu identifizieren. 

An dieser Stelle soll noch auf eine Besonderheit eingegangen werden. Wie schon zuvor erwähnt können 

mehrere Spracheingaben den selben Befehl auslösen. Außerdem wurde gesagt, dass dazu wiederholt 

die Funktion add_command mit dem gleichen Menü- und Befehlsindex aufgerufen werden muss. An 

dieser Stelle kommt die Frage auf, ob den nicht auch der Name des Befehls gleich lauten muss, da auch 

er einen Befehl eindeutig identifiziert. Die Antwort ist allerdings nein. Man kann einem Befehl also


durchaus mehrere Spracheingaben mit unterschiedlichen Befehlsnamen zuordnen. Das heißt, dass der 

Befehlsindex einen Befehl innerhalb eines Menüs eindeutig identifiziert und dass der Befehlsname dazu 

genutzt werden kann, verschiedene Spracheingaben eines Befehls auseinander zu halten. Im folgenden 

Beispiel wir gezeigt wie man sich diese Eigenart der SAPI zu nutze machen kann. Man erstellt eine 

Grammatik wie folgt: 

add_menu(1, true, ’exit’); 

add_command(1, ’exit program’, 0, ’ep’); 

add_command(1, ’close window’, 0, ’cw’); 

Die Regel ’exit’ ist während der gesamten Laufzeit der Anwendung aktiv. Die zwei Spracheingaben 

’exit program’ und ’close window’ führen zum selben Befehlsindex (0) aber zu den unterschiedlichen 

Befehlsnamen ’ep’ und ’cw’. In einer fiktiven Anwendung existiert nun ein Hauptfenster und zusätzliche 

Fenster abhängig von der momentanen Aufgabe. Befindet sich die Anwendung nun in einem Fenster 

für eine der zusätzlichen Aufgaben, wird der Name des Befehls abgefragt. Ist er ’ep’ wird die gesamte 

Anwendung geschlossen, wohingegen ’cw’ nur das einzelne Fenster schließt. Sollte sich die Anwendung 

allerdings im Hauptfenster befinden wird der Index des Befehls erfragt. Beide Spracheingaben führen 

dann dazu, dass die Anwendung beendet wird. 

8.2.4 Das Vokabular 

Abgesehen von den Funktionen clear_grammar, add_menu, add_rule und finalize_grammar gibt es auch 

die Möglichkeit, die gesamte Grammatik in einem Schritt zu erstellen. Dazu kann sie aus einem vorgegebenen 

Vokabular eingelesen werden. 

Es bestehen zwei Möglichkeiten, wie ein Vokabular angegeben werden kann. Zunächst ist da das anwendungsinterne 

Vokabular. Es ist in einer Zeichenkette fest in die Anwendung integriert und wird 

mittels read_grammar_string eingelesen. Bei dieser Variante kann das Vokabular nicht von außen manipuliert 

werden. Der Funktionsaufruf kann bei größeren Vokabularen allerdings schnell unübersichtlich 

werden. Das externe Vokabular wird in einer txt-Datei gespeichert. Auf sie wird durch die Funktion 

read_grammar_file zugegriffen. Eine externes Vokabular hat den Vorteil, dass der geübte Nutzer das 

Vokabular bei Bedarf auch an seine eigenen Vorlieben anpassen kann. 

Das gesamte Vokabular besteht aus abwechselnd Menü-Zeilen und Befehls-Zeilen. Diese Vorgabe macht 

es notwendig, dass auch in einem String alle Zeilenumbrüche angezeigt werden. 

Menü-Zeilen: 

Das Schlüsselwort ’Menu’ leitet eine neue Menü-Zeile ein. Ihm folgen der Name des Menüs und optional 

der Startzustand. Er kann ’active’ oder ’inactive’ sein. Wird kein Startzustand angegeben, wird er


automatisch auf ’inactive’ gesetzt. Gültige Zeilen sind somit: 

Menu namexyz active 

Menu nameabc inactive 

oder 

Menu namexyz 

Jede Menu-Zeile sollte mindestens eine ihr zugehörige Kommandozeilen folgen. 

Kommando-Zeile: 

Mit dem Schlüsselwort ’Command’ beginnt eine Kommando-Zeile. Danach folgen der Name des Kommandos 

und ihm alle gültigen Spracheingaben, die dieses Kommando auslösen. Besteht eine Spracheingabe 

aus mehreren Wörtern wird die gesamte Wortgruppe zwischen zwei ’ gesetzt. In folgendem Beispiel 

wird das Kommando exit gezeigt, welches durch die Spracheingaben ’exit the program’, ’close the program’ 

oder einfach nur ’end’ ausgelöst werden kann: 

Command exit ’exit the program’ ’close the program’ end 

Der Übersicht halber können auch Leerzeilen oder Beschreibungen der einzelnen Teile des Vokabulars 

eingefügt werden. Diese dürfen allerdings nicht mit ’Rule’ oder ’Command’ beginnen und nicht auf der 

selben Zeile wie ein Kommando oder eine Regel stehen. 

Das Aufrufen der Funktionen read_grammar_file und read_grammar_string führt immer dazu, dass 

Abbildung 8.1: Beispielhafter Inhalt einer txt-Vokabulars für eine gültige Grammatik mit zwei Regeln. 

Abbildung 8.2: Beispielhafte Zeichenkette, die die selbe Grammatik wie das txt-Vokabular erzeugen 

würde. 

die zuvor genutzte Grammatik überschrieben wird. Eine Grammatik, die durch eine dieser Funktionen 

erstellt wurde kann aber immer noch durch clear_grammar, add_menu, add_command und finalize_grammar 

manipuliert werden. Allerdings muss man in diesem Fall besonders auf ID’s den einzelnen


Menüs und Kommandos achten. Diese werden bei Erstellen der Grammatik nämlich automatisch, von 

Null beginnend vergeben. 

8.3 Eine Beispielanwendung 

Die Beispielanwendung wird auf der Konsole ausgeführt und besteht aus einem Hauptmenü, zu dem elf 

Menüpunkte gehören, von denen wiederum Vier, eigene Untermenüs öffnen. Der Quellcode der Anwendung 

ist gemeinsam mit dem der Schnittstelle, auf der Beleg CD im Verzeichnis project/src abgelegt. 

8.3.1 Vokabular 

Das vollständige Vokabular, so wie es in ’vocabulary.txt’ zu finden ist, wird in Abbildung 8.3 dargestellt. 

Es orientiert sich an den Befehlen, die schon in Kapitel 6.1 für die verschiedenen Tests genutzt wurden. 

Genauere Informationen zum Aufbau eines Vokabulars sind in diesem Kapitel im Unterpunkt 8.2.4 ’Das 

Vokabular’ zu finden. 

8.3.2 Navigation 

Abbildung 8.4 gibt einen Überblick über die Navigation innerhalb der Anwendung. Alle Befehle die dort 

nicht auf ein anderes Menü verweisen, werden nur durch eine kurze Textmeldung bestätigt. 

8.3.3 Programmieren der Beispielanwendung 

Um eine funktionsfähige Anwendung zu erstellen müssen folgende Quelldateien dem Projekt hinzugefügt 

werden: 

• cgv/media/text/advanced_scan.cxx 

• cgv/media/text/scan.cxx 

• cgv/input/microsoft_speech_input.cxx 

• cgv/utils/file.cxx 

Natürlich müssen auch die nötigen Includeverzeichnisse angegeben werden. Außerdem muss mittels 

cgv::input::speech_input* si = new cgv::input::microsoft_speech_input(); ein neuer speech_input angelegt 

werden. Über ihn erhält man Zugriff auf alle nötigen Funktionen der Schnittstelle.


Abbildung 8.3: Vokabular der Beispielanwendung 

Abgesehen davon gibt es in der Beispielanwendung drei wichtige Funktionen: 

• main() 

• ExecuteCommand() 

• exit() 

Alle anderen Funktionen werden nur dazu genutzt um die verschiedenen Menüs anzuzeigen. 

8.3.3.1 main() 

Der Einstiegspunkt der Anwendung ist in Abbildung 8.5 zu sehen. Zunächst wird durch aufrufen der 

Funktion init() der Spracherkenner initialisiert. Sollte dies erfolgreich geschehen sein, lädt 

read_grammar_file(’vocabulary.txt’) das standard Vokabular als Grammatik in den Erkenner und das


Abbildung 8.4: Navigation in der Beispielanwendung 

Hauptmenü wird angezeigt. Falls dabei ein Fehler passieren sollte, wird eine Fehlermeldung angezeigt, 

das Notfallvokabular aus einem String geladen und das Notfallmenü angezeigt. Falls auch das fehlschlagen 

sollte, wird die Anwendung beendet. Nachdem der Spracherkenner vollständig initialisiert wurde, 

wird die Erkennungsschleife gestartet. Durch die Funktion is_recognizer_active() wird abgefragt ob der 

Erkenner noch arbeitet. Solange das der Fall ist, wird zunächst darauf gewartet, dass ein neuer Befehl erkannt 

wird. Diese Arbeit übernimmt die Funktion wait_for_event() und sorgt gleichzeitig dafür, dass im 

Falle einer Spracheingabe die Werte Menüindex, Menüname, Befehlsindex und Befehlsname abgefragt 

werden. Ist das geschehen, führt ExecuteCommand() den erkannten Befehl aus. Sollte das Initialisieren 

fehlgeschlagen sein, oder zuletzt der Befehl zum Beenden gegeben wurden sein, liefert die Funktion 

is_recognizer_active() den Wert false zurück und die Anwendung wird beendet.


void main() 

{ 

if(si->init()) 

{ 

if(si->read_grammar_file("vocabulary.txt")) 

{ 

menu(); 

vocnumber = 1; 

} 

else 

{ 

cout is_recognizer_active()) 

{ 

si->wait_for_event(); 

ExecuteCommand(); 

} 

} 

Abbildung 8.5: Der Einstiegspunkt der Beispielanwendung.


8.3.3.2 ExecuteCommand() 

Die Abbildung 8.6 stellt die Funktion ExecuteCommand() dar. Um die Funktionsweise besser zu zeigen, 

ist nur die Behandlung aller Befehle des Hauptmenüs abgebildet. Die Behandlung von Befehlen 

in den anderen Menüs läuft analog dazu ab. Sobald die Funktion aufgerufen wurde, werden zu dem soeben 

erkannt Befehl, der Name sowie die ID des Befehls selbst sowie der zugehörigen Regel abgefragt. 

Dies geschieht über die Funktionen get_menu_index(), get_command_index(), get_menu_name() und 

get_command_name(). Einige davon werden allerdings nicht für die Navigation im Hauptmenü genutzt. 

Die darauf folgende Abfrage der ’vocnumber’ dient nur dazu, zu unterscheiden ob das richtige Vokabular 

geladen ist oder ob sich die Anwendung im Fehlermenü befindet. Wenn nun das original Vokabular geladen 

wurde und sich die Anwendung im Hauptmenü befindet, nimmt die Variable ’rule_name’ den Wert 

’main’ an. Auf Grund dessen wird die Regel für das Hauptmenü ausgeführt und nun überprüft, welcher 

der Befehle des Hauptmenüs soeben eingegeben wurde. Dies geschieht entweder über den Namen des 

Befehls oder seine ID. Danach werden die entsprechenden Anweisungen für diesen Befehl ausgeführt. 

Im Fall der Beispielanwendung erfolgt entweder eine einfache Bildschirmausgabe, eine weitere Funktion 

wird ausgeführt oder ein Untermenü wird geöffnet, das entsprechende Menü in der Grammatik wird 

aktiviert und das momentane Menü deaktiviert. 

8.3.3.3 exit() 

Die Funktion exit() wird in Abbildung 8.7 gezeigt. Sie ist nur dafür zuständig die Ressourcen des Spracherkenners 

wieder frei zu geben. Dazu wird die Funktion close() der Schnittstelle aufgerufen. Auf das 

Beenden der Anwendung hat sie insofern Einfluss, als dass beim nächsten Aufruf der Erkennungsschleife 

die Funktion is_recognizer_active() den Wert ’false’ zurück gibt. Dies hat den Ausstieg aus der Schleife 

und damit das Ende der Anwendung zur Folge. 

8.4 Test der Schnittstelle mit Hilfe der Beispielanwendung 

Um die Schnittstelle auch mit den früheren Testergebnissen vergleichen zu können, wurde die Beispielanwendung 

entsprechend der Sphinx-4 Dialog Demo erstellt. Somit enthält die Testanwendung 

insgesamt fünf Menüs. Diese wiederum beinhalten zwischen elf und 31 Kommandos. Wie in den vorangegangenen 

Tests wurde auch hier jedes Kommando fünf mal wiederholt. Das Gesamtergebnis der 

Testanwendung wird in Tabelle 8.1 dargestellt. In der darauf folgenden Tabelle 8.2 werden diese neuen 

Ergebnisse den früheren Testergebnissen von SAPI, jlab und Sphinx gegenüber gestellt.


void ExecuteCommand(){ 

int rule = si->get_menu_index(); 

int value = si->get_command_index(); 

std::string rule_name = si->get_menu_name(); 

std::string command_name = si->get_command_name(); 

if (vocnumber==1){ 

if( rule_name=="main" ){ 

if(command_name=="exit"){exit();} 

else if(command_name=="help"){help();} 

else if(command_name=="music"){ 

music(); 

si->activate_menu_name("music"); 

si->deactivate_menu_name("main"); 

} 

else if(command_name=="phone"){ 

phone(); 

si->activate_menu_name("phone"); 


} 

else if(command_name=="game"){ 

games(); 

si->activate_menu_name("game"); 


} 

else if(command_name=="mail"){ 

mail(); 

si->activate_menu_name("mail"); 


} 

else{ 

switch( value ){ 

case 5:{cout


void exit() 

{ 

si->close(); 

} 

Abbildung 8.7: Die Funktion exit(). 

Menüpunkt Anzahl richtig nicht verwechselt Worterkennungsrate 

der Befehle erkannt erkannt in Prozent 

Musik 31 150 5 0 96,80 

Anrufe 24 115 1 4 92,00 

Spiele 18 90 0 0 100 

eMail 13 65 0 0 100 

Hauptmenü 11 51 4 0 92,70 

Tabelle 8.1: Worterkennungsrate der SAPI Schnittstelle in den einzelnen Menüs 

Schon in den erst Tests wurde deutlich, dass die SAPI in vielen der Menüs besser als die anderen Erkenner 

arbeitete. Der extreme Einbruch der Erkennungsrate im Musik-Menü wurde damit begründet, dass in 

diesen Tests mit dem Dictation Pad, einer Diktieranwendung mit allumfassendem Sprachvokabular, gearbeitet 

wurde. Die neuen Ergebnisse zeigen zum Einen, dass diese Annahme richtig war. Zum Anderen 

zeigen sie auch, dass die SAPI im Bereich Befehlserkennung mit 97,1% Erkennungsrate deutlich exakter 

als jlab und Sphinx arbeitet. Die 2,9% Fehlerrate setzten sich dabei aus 2,1% nicht erkannten und 0,8% 

falsch verstandenen Befehlen zusammen.


Menüpunkt Sphinx4 JLAB Microsoft SAPI SAPI Interface 

Dialog Demo Speech Server Dictation Pad Testanwendung 

Musik 58,06 81,94 54,84 96,80 

Anrufe 69,17 81,67 89,17 92,00 

Spiele 68,89 88,19 95,56 100 

eMail 89,23 86,15 87,69 100 

Hauptmenü 78,18 94,55 90,91 92,70 

Durchschnitt 72,71 86,5 83,63 97,10 

Tabelle 8.2: Vergleich der Ergebnisse aus Kapitel 6 mit den Ergebnissen der Testanwendung (Angaben 

in Prozent)

9. ABSCHLIESSENDE BETRACHTUNGEN 63 

9 Abschließende Betrachtungen 

9.1 Resümee 

Zu Beginn dieser Arbeit wurden zunächst einige grundlegende Informationen über Spracheingabe und 

den Aufbau von Spracherkennern gegeben. Danach wurden einige momentan verfügbare Spracherkenner 

vorgestellt. 

Im Hauptteil dieser Arbeit wurden drei freie Erkenner vorgestellt und verglichen. Dabei handelte es sich 

zum einen um Sphinx von, unter Anderen, der Carnegie Mellon Universität. Dieser Erkenner bietet eine 

knappe Dokumentation und einige Beispielanwendungen. Der Nachteil ist, dass Sphinx eine Art Baukasten 

für Spracherkenner ist. Man hätte also zunächst seinen eigenen Erkenner aufbauen müssen, bevor 

man ihn in einer Anwendung nutzen kann. Sphinx ist in Java implementiert. 

Jlab vom Institut für Akustik und Sprachkommunikation der TU Dresden bietet einen fertigen Erkenner 

der für Befehlseingabe konzipiert ist und mit der deutschen Sprache arbeitet. Nachteilig wirkt sich bei 

Jlab das Vokabular aus. Durch das Angeben der Befehle in Phonemschrift ist es für Laien sehr schwer 

ein korrektes Vokabular zu erstellen. Außerdem kann sehr viel Feinarbeit nötig sein, um die Rückweisungsschwellen 

korrekt anzugeben, damit Verwechslungen durch den Erkenner ausgeschlossen werden. 

Der dritte Erkenner war die Microsoft Speech API. Sie bietet eine gute Dokumentation und eine Vielzahl 

von guten Beispielen zur Einarbeitung. Der Erkenner ist für Diktieranwendungen, sowie Befehlseingabe 

gedacht. Er arbeitet mit der englischen Sprache, es existieren aber Pakete für andere Sprachen. Außerdem 

handelt es sich bei der SAPI um den einzigen der drei Erkenner, der in C++ geschrieben ist. 

Im Anschluss daran wurden mit den Erkennern einige Tests durchgeführt. Bei der Befehlseingabe lag jlab 

mit 86,5Prozent Worterkennungsrate vor der SAPI mit 83,63Prozent. Am schlechtesten schnitt Sphinx, 

mit einer Rate von 72,71Prozent, ab. Letztendlich muss man sagen, dass dabei keiner der Erkenner 

wirklich überzeugende Ergebnisse geliefert hat. Anschließend wurde auch die Worterkennungsrate für 

die Diktieranwendung der SAPI getestet. Das mittlere Ergebnis dieses Tests lag bei 68,3Prozent. Danach 

wurden noch einmal alle drei Erkenner miteinander verglichen. 

Im letzten Kapitel dieses Belegs wurde eine Schnittstelle auf Basis der SAPI beschrieben. Die Schnittstelle 

versucht die SAPI spezifischen Merkmale zu verdecken um so eine einfachere Möglichkeit zu


bieten um die Integration von Spracheingabe in die eigenen Anwendungen zu erleichtern. Um die Fähigkeiten 

dieser Schnittstelle zu zeigen wurde eine Beispielanwendung implementiert. Tests, die mit dieser 

Anwendung durchgeführt wurden, zeigten, das die SAPI weit bessere Ergebnisse liefern kann als aus 

den früheren Kapiteln hervor geht. Die ermittelte durchschnittliche Worterkennungsrate stieg in der Beispielanwendung 

auf 97,1Prozent und übertrifft die zwei anderen Erkenner nun bei Weitem. Mit diesem 

Wert bietet die SAPI eine gute Möglichkeit, Spracherkennung in eigene Anwendungen zu integrieren 

ohne dabei kommerzielle Systeme nutzen zu müssen. 

9.2 Ausblick 

In dieser Arbeit wurde die vereinfachte Schnittstelle für die Microsoft Speech API implementiert. Für die 

Zukunft wäre es natürlich wünschenswert, wenn die Schnittstelle auch für andere Erkenner implementiert 

würde. Im folgenden sollen allerdings ihre Anwendungsmöglichkeiten näher betrachtet werden. 

In Kapitel 7 wurde eine kleine Beispielanwendung zur Menüsteuerung vorgestellt. Heutige Anwendungen 

sind allerdings weitaus komplexer und besitzen einer sehr großen Anzahl an Menüs und eine dem 

entsprechende Masse an Befehlen. Aus diesem Grund werden einzelne Vokabulardateien schnell unübersichtlich. 

Wenn immer möglich, sollte man daher versuchen, immer nur das gerade benötigte Vokabular 

zu laden. Sollte zu einem Zeitpunkt zum Beispiel immer nur ein einzelnes Menü aktiv benötigt werden, 

bietet es sich an, für jedes Menü eine Vokabulardatei anzulegen. Diese wird dann immer, wenn es nötig 

ist, in die Grammatik geladen. Auf diese Weise hat man stets übersichtliche Vokabulardateien. Natürlich 

ist es nicht immer möglich ein riesiges Vokabular so aufzuteilen. Eine zweite Möglichkeit besteht darin, 

alle Befehle, die von jedem Programmpunkt aus zugänglich sind, in ein eigenes Menü zu packen und 

dieses dauerhaft aktiv zu lassen. So spart man sich zumindest, sich ständig wiederholende Befehle über 

alle Menüs hinweg. Um das Erstellen von Vokabularen einfacher zu gestalten wäre auch ein kleines Tool 

schön, mit dessen Hilfe die Vokabulardateien übersichtlicher dargestellt werden. Im Moment werden nur 

Vokabularzeilen ausgewertet, die mit den Worten ’Menu’ oder ’Command’ beginnen. Andere Schlüsselwörter 

könnte für vollkommen andere Auswertungsvarianten genutzt werden. Mit den entsprechenden 

Anpassungen könnte ein Tool somit eine grafische Nutzeroberfläche bieten, auf der man sehr einfach 

und übersichtlich neue Vokabulare erstellen kann. Die zusätzlichen Informationen könnten dann dazu 

genutzt werden, die Navigation innerhalb der Anwendung zu visualisieren und sie dem Nutzer dadurch 

einfacher verständlich darzustellen. 

Die Anwendung der vereinfachten Schnittstelle bezieht sich aber nicht nur auf Menüsteuerungen jeder 

Art. Auch die Steuerung von virtuellen Umgebungen oder Modellierungsanwendung wird möglich. In


Zukunft müsste also untersucht werden, wie die Steuerung oder Bearbeitung von Objekten via Spracheingabe 

realisiert werden kann. Zunächst müsste man natürlich für jedes Objekt die entsprechenden Befehle 

in die Grammatik laden. Es ist aber klar, dass der Benutzer das nicht bei jedem neu angelegten Objekt 

von Hand erledigen will. Also wird eine Aufgabe darin bestehen, herauszufinden, wie man diese Abläufe 

automatisieren kann. Im folgenden werden dazu ein paar Anregungen gegeben. 

Als erstes muss man sich überlegen ob man ein Vokabular anlegt in dem alle Befehle zu den vorhandenen 

Objekten stehen. Dieses Vokabular muss dann jedes mal umgeschrieben werden wenn man ein 

Objekt hinzufügt oder entfernt und im Anschluss daran neu geladen werden. Sollten alle Befehle, die zur 

Anwendungssteuerung genutzt werden auch in einem Vokabular stehen, gibt es das Problem, dass keine 

zwei Vokabulare gleichzeitig geladen sein können. Dies lässt sich aber umgehen, indem man ein beim 

Erstellen eines neuen Projekts, ein neues Vokabular mit alle Menübefehlen erstellt und dieses dann um 

die Objektbefehle erweitert. Wenn man kein Vokabular anlegen will, kann man die einzelnen Befehle für 

die Objekte auch direkt in die Grammatik laden. Wenn ein Objekt gelöscht wird, wird einfach die alte 

Grammatik gelöscht und die Befehle für alle verbleibenden Objekte erneut geladen. 

Nach dem man diese Frage für sich geklärt hat, muss man überlegen, wie man die Befehle zur Steuerung 

der Objekte zu seinem Vokabular oder direkt zur Grammatik hinzufügen kann. Zunächst ist es vorteilhaft 

für jedes Objekt ein Menü anzulegen. Darin werden danach automatisch alle möglichen Sprachbefehle 

aufgeführt. Da sich diese Befehle bei mehreren Objekten wiederholen können steht dabei die Frage im 

Raum, wie man einen Befehl einem bestimmten Objekt zuordnet. Eine Möglichkeit jederzeit alle ’Objektmenüs’ 

aktiviert zu lassen. Die Befehle in den Menüs müssten sich dann aus dem Objektnamen und 

der auszuführende Aktion zusammensetzen, um eindeutig zu sein. So entstehen Befehle wie ’move Red 

Cube to the right’, ’move Red Cube to the left’ und so weiter. Eine andere Möglichkeit ist, zum Beispiel 

im Hauptmenü, zu jedem Objekt einen Befehl wie ’take +Objektname’ anzulegen. Wird dieser Befehl für 

ein Objekt aufgerufen werden alle folgenden Befehle auf dieses Objekt bezogen, bis ein anderes Objekt 

aufgerufen wird. Die Objektnamen müssen in beiden Fällen eindeutig sein. 

Zum Ende sollen noch kurz zwei mögliche Erweiterungen der Schnittstelle genannt werden. Einerseits 

wäre da die Unterstützung von Callbacks. Im Moment ist der Aufruf der Schnittstellenfunktion 

wait_for_event() in einer Schleife in der Hauptanwendung vorgesehen. Für die Zukunft wäre es wünschenswert 

wenn diese Funktion in einem extra Thread angesiedelt werden könnte. Dazu kann die 

signal-Klasse aus cgv/utils genutzt werden. Man müsste der abstrakten Klasse speech_input ein Signal 

als Member hinzufügen. Die Funktion wait_for_event() kann dadurch in einer Schleife, in einem 

extra Thread laufen. Wenn eine Spracheingabe erfolgt, wird dann ein Signal an die Hauptanwendung 

geschickt, wodurch der Sprachbefehl verarbeitet wird. 

Eine weitere Erweiterung wurde dieser Arbeit im Kapitel 6 schon einmal kurz erwähnt. Es handelt sich


um die Möglichkeit Texte zu diktieren. Nachdem man eine Anwendung schon per Sprachbefehl steuern 

kann, fehlt nur noch diese Erweiterung um Anwendungen unabhängig von Tastatur oder Maus nutzen 

zu können. Wie schon erwähnt bot die SAPI als einziger Erkenner diese Möglichkeit. Trotzdem wäre es 

eine sehr schöne Erweiterung um die Schnittstelle abzurunden.

10. GLOSSAR 67 

10 Glossar 

Erkennungsgeschwindigkeit 

Die Erkennungsgeschwindigkeit oder Echtzeitfaktor gibt an, wieviel schneller der Erkenner gegenüber 

der Dauer der gesprochenen Eingabe ist. 

Erkennungsraten 

Die Worterkennungsrate eines Spracherkenners bezeichnet wieviele Worte korrekt erkannt wurden. Ihr 

entgegen steht die Wortfehlerrate. 

Formanten 

Formanten sind die Frequenzanteile eines Signals, bei denen besonders viel Energie vorhanden ist. In 

Abbildung 10.1 ist das Spektrogramm eines Phonems zu sehen. Umso dunkler die Farbe desto höher ist 

der Energieanteil der entsprechenden Frequenz. 

NAD 

Die NAD (normalized acoustic distance) gibt an wie sicher sich der Erkenner bei einem bestimmten Ergebnis 

ist. Ihr zugrunde liegt eine Folge von Merkmalsvektoren für die die NAD berechnet wird. Dazu 

werden zunächst zwei zusätzliche Werte ermittelt. Der erste Wert (NLLd) gibt die Wahrscheinlichkeit der 

erkannte Vektorfolge an, mit der Beschränkung das nur die im Vokabular angegebenen Befehle möglich 

sind. Für den zweiten Wert (NLLr) gibt es keine Einschränkung. Es kann also jede Vektorfolge erkannt 

werden. Dadurch das es für NLLr keine Einschränkungen gibt, ist dieser Wert immer kleiner als NLLd. 

Umso geringer nun die Differenz von NLLd und NLLr ist, desto sicherer ist es, dass das Ergebnis korrekt 

ist. Die NAD wird dabei wie folgt berechnet: 

NAD = (NLLd-NLLr)/NLLd 

Ein NAD von unter 0.05 steht für einen mit hoher Sicherheit richtig erkannten Befehl. 

NED


Abbildung 10.1: Spektrogramm des englischen Phonems ’ee’[17] 

Die NED (normalized edit distance) gibt genauso wie die NAD an wie sicher sich der Erkenner bei 

einem bestimmten Ergebnis ist. Für die Berechnung des NED wird allerdings die erkannte Phonemfolge 

genutzt. Auch hier werden wieder zwei unterschiedliche Werte Verglichen. Der erste Wert (Ad) 

beinhaltet die erkannte Phonemfolge unter der Bedingung, dass nur Phonemfolgen, die im Vokabular angegeben 

sind auftreten können. Der zweite Wert (Ar) enthält die erkannte Phonemfolge, wenn es keine 

Einschränkenden Bedingungen gibt. Da Pausen und Müll-Zeichen keine Informationen über den eingegebenen 

Befehl beinhalten, werden sie aus Ad sowie aus Ar entfernt. Danach werden die Phonemfolgen 

Phonem für Phonem wie folgt verglichen: 

∑ 

NED = ( N c_i) / N 

mit: 

i=0 

N = maximale Anzahl der Phoneme, und 

c_i={Ad_i = Ar_i : 1; sonst : 0} 

Ein akzeptabler NED Wert sollte unter 0.5 liegen. 

Phoneme 

Phoneme bilden die Menge der kleinsten bedeutungstragenden Bestandteile einer Sprache und sind von


Sprache zu Sprache unterschiedlich. Im deutschen wie im englischen unterscheidet man etwa 40 Phoneme. 

Tabelle 10.1 das Phonemset des JLAB Speech Servers. 

Phonemzeichen Beispiel Phonemzeichen Beispiel Phonemzeichen Beispiel 

a kann N Junge S Tasche 

a: Kahn h Hast t Torte 

aU Baum I ritt u: Mus 

b bei i: riet U muss 

C dich j ja v Vase 

x Dach k Kahn OY neu 

d du l Licht E: Käse 

e: Beet m Mann 2 Höhle 

@ lesen n neun 9 Hölle 

E Bett o: bog Y Hütte 

6 Leser O Bock y: Hüte 

aI zwei p Platz Spezialzeichen: 

f f ahren r Rauch Q (Glottalisierung) beenden 

Z Loge s las . Pause 

g Gast z lesen ♯ Müll 

Tabelle 10.1: Phonemset der deutschen Sprache wie es in jlab genutzt wird 

Rückweisungsschwelle oder Rückweisungswert 

Dieser Wert gibt an wie sicher sich der Erkenner sein muss, dass sein Ergebnis mit der Eingabe übereinstimmt, 

damit es akzeptiert wird. Wird dieser Wert falsch gewählt, kann es passieren das zu häufig 

Ergebnisse zurückgewiesen werden obwohl sie richtig waren oder aber es kommt zu häufig vor, dass der 

Erkenner auch Ergebnisse zulässt obwohl keine entsprechende Eingabe erfolgte. Siehe auch NAD und 

NED. 

Wortfehlerrate 

Sie bezeichnet wie häufig Erkennungsfehler auftreten und setzt sich aus verschiedenen Fehlerarten zusammen: 

• erkannte Eingabe ohne das eine Eingabe erfolgte 

• erkannte Eingabe obwohl eine völlig andere Eingabe erfolgte


• nicht erkannte Eingabe obwohl ein korrekte Eingabe erfolgte


[]

Literaturverzeichnis 72 

Literaturverzeichnis 

[1] BOWMAN ; KRUIJFF ; LAVIOLA ; POUPYREV: 3D User Interfaces: Theory and Practice. Addison- 

Wesley, 2004, S. 119,268,269,304–306. – ISBN 0–201–75867–9 

[2] BREMPEL, Michael: LipSync in Echtzeit-3D-Anwendungen, Fachhochschule Furtwangen, Diplomarbeit, 

2005 

[3] BUDDE, Mark: Kompakte Spracherkenner. In: Funkschau (13/1999) 

[4] CMU. Sphinx4 Overview. Dokumentation der Sphinx4-Version 1.0beta erhätlich unter 

http://sourceforge.net/project/showfiles.php?group_id= 

1904&package_id=117949. 1999-2004 

[5] CREEMER, David Z. ; DORIS, Tom ; CRAFT, Brian. XVoice. 

http://xvoice.sourceforge.net/. 1999 

[6] IBM. Offizielle Website, IBM speech recognition research history. 

http://www.research.ibm.com/hlt/html/body_history.html 

[7] JOHAN, Anhofer: Das elektronische Tagebuch der Sinne, Technische Universität Graz, Diplomarbeit, 

2003 

[8] KASPER, Klaus: Spracherkennung mit rekurrenten neuronalen Netzen. Shaker, 2000, S. 67–77. – 

ISBN 3–8265–7644–6 

[9] KELLER, Eric: Fundamentals of Speech Synthesis and Speech Recognition. Wiley, 1995, S. 129– 

146,297–310. – ISBN 0–471–94449–1 

[10] KIECZA, Daniel. VoiceControle - command and control for Linux! 

http://www.kiecza.net/daniel/linux/. 11.11.2002 

[11] MACSPEECH. Speech Recognition for MAC OS X. 

http://www.macspeech.com/ 

[12] MICROSOFT. Offizielle Website, Other speech engine support. 

http://www.microsoft.com/msagent/downloads/otherspeech.aspx. 

02.04.2003


[13] MICROSOFT. Offizielle Website, Microsoft Agent download page for end-users. 

http://www.microsoft.com/msagent/downloads/user.aspx. 15.05.2003 

[14] NUANCE. Datenblatt Dragon Naturally Speaking. 

ftp://ftp.scansoft.com/nuance/datasheets/ds_dns9_professional_de. 

pdf. 2005 

[15] NUANCE. IBM ViaVoice. 

http://www.nuance.com/viavoice/matrix/. 2005 

[16] NUANCE. Offizielle Website, Datenblatt Dragon Naturally Speaking. 

http://www.nuance.de/naturallyspeaking/matrix/. 2008 

[17] PARK, Sung won. Chapter 7 Linear Predictive Speech Processing. 

http://www.engineer.tamuk.edu/SPark/chap7.pdf. 2003 

[18] PFISTER, Beat ; UEBERSAX, Hans-Peter: Erweiterungen von trueAct zum Sprachdialogsystem. In: 

PIDAS Kundenzeitschrift (2/2002) 

[19] ROZAK, Mike: Talk to Your Computer and Have It Answer Back with the Microsoft Speech API. 

In: Microsoft Systems Journal (Januar 1996) 

[20] SOBE, Daniel: Sprachsteuerung eines Computerspiels - Untersuchungen zur Leistungsfähigkeit 

und Ergonomie, Technische Universität Dresden, Diplomarbeit, 2004 

[21] SPEARMAN, Rob: ViaVoice and XVoice: Providing Voice Recognition. In: Linux Journal 

(17.10.2002) 

[22] STACHE, Oliver: Konzeption, Realisierung und Evaluation einer multimodalen Benutzungsoberfläche 

für PDA-basierte Software, Technische Universität Dresden, Diplomarbeit, 2006 

[23] VERSCHIEDENE. IBM ViaVoice. 

http://en.wikipedia.org/wiki/IBM_ViaVoice. 06.06.2008 

[24] VERSCHIEDENE. Speech Application Programming Interface. 

http://en.wikipedia.org/wiki/Speech_Application_Programming_ 

Interface. 21.07.2008 

[25] VOICEIT. VoiceIt Produkte. 

http://www.groverind.com/index.php. 2006 

[26] WALKER ; LAMERE ; KWOK ; RAJ ; SINGH ; GOUVEA ; WOLF ; WOELFEL. Sphinx-4: A Flexible 

Open Source Framework for Speech Recognition. 

http://cmusphinx.sourceforge.net/sphinx4/doc/Sphinx4Whitepaper.


pdf. 2004 

[27] WERNER, Steffen ; WOLFF, Matthias ; EICHNER, Matthias ; HOFFMANN, Rüdiger. Integrating 

Speech enabled Services in a Web-based e-Learning Environment. 2004

Abbildungsverzeichnis 75 

Abbildungsverzeichnis 

3.1 Allgemeiner Aufbau eines Spracherkenners . . . . . . . . . . . . . . . . . . . . . . . . 14 

3.2 Mustererkennungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.3 Akustisch-phonetischer Ansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.4 Aufbau der Signalaufbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.5 Anregung und Bewertung für einen Vokal[17] . . . . . . . . . . . . . . . . . . . . . . . 17 

3.6 Dynamic Time Warping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

3.7 Hidden Markov Modell für das Wort ’haben’ nach [7] . . . . . . . . . . . . . . . . . . . 21 

5.1 Aufbau von Sphinx-4 nach [26] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

5.2 Das Sphinx-4 Front End nach [26] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

5.3 Der Sphinx-4 Search Graph für ’one’ und ’two’ nach [26] . . . . . . . . . . . . . . . . . 32 

5.4 Aufbau des Speech API Spracherkenners nach [19] . . . . . . . . . . . . . . . . . . . . 35 

5.5 Die jlab Speech Server Architektur nach [27] . . . . . . . . . . . . . . . . . . . . . . . 37 

5.6 Vereinfachtes Ablaufschema nach [27] . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

5.7 Aufbau eines jlab Vokabulars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

5.8 Worterkennungsrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

5.9 Der Echtzeitfaktor, bezogen auf die Dauer des Eingabesignals . . . . . . . . . . . . . . 40 

8.1 Beispielhafter Inhalt einer txt-Vokabulars für eine gültige Grammatik mit zwei Regeln. . 54 

8.2 Beispielhafte Zeichenkette, die die selbe Grammatik wie das txt-Vokabular erzeugen 

würde. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

8.3 Vokabular der Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 

8.4 Navigation in der Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

8.5 Der Einstiegspunkt der Beispielanwendung. . . . . . . . . . . . . . . . . . . . . . . . . 58 

8.6 Die Funktion ExecuteCommand(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

8.7 Die Funktion exit(). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

10.1 Spektrogramm des englischen Phonems ’ee’[17] . . . . . . . . . . . . . . . . . . . . . . 68

Tabellenverzeichnis 76 

Tabellenverzeichnis 

2.1 Mindestwortschatz einer Diktieranwendung in deutsch und englisch nach [1] . . . . . . 9 

2.2 Wortschatz für verschiedene Anwendungen nach [18] . . . . . . . . . . . . . . . . . . . 10 

4.1 Frei verfügbare Spracheingabesoftware . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

4.2 Kommerzielle Spracheingabesoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

4.3 Übersicht über VoiceIt Sofware und die unterstützten Betriebssysteme nach [25] . . . . . 27 

6.1 Worterkennungsrate einiger Menüs der Sphinx-4 Dialog Demo . . . . . . . . . . . . . . 42 

6.2 Worterkennungsrate von JLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

6.3 Worterkennungsrate des Dictation Pad (trainiert) . . . . . . . . . . . . . . . . . . . . . . 43 

6.4 Worterkennungsrate des Dictation Pad (untrainiert) . . . . . . . . . . . . . . . . . . . . 44 

6.5 Worterkennungsraten aller drei Anwendungen in Prozent . . . . . . . . . . . . . . . . . 45 

6.6 Ergebnisse für die Diktieranwendung der SAPI . . . . . . . . . . . . . . . . . . . . . . 46 

7.1 Übersicht über die Eigenschaften von CMU Sphinx, MS SAPI und jlab . . . . . . . . . 48 

8.1 Worterkennungsrate der SAPI Schnittstelle in den einzelnen Menüs . . . . . . . . . . . 61 

8.2 Vergleich der Ergebnisse aus Kapitel 6 mit den Ergebnissen der Testanwendung (Angaben 

in Prozent) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

10.1 Phonemset der deutschen Sprache wie es in jlab genutzt wird . . . . . . . . . . . . . . . 69

Belegarbeit (.pdf - 2.3 MB) - Technische Universität Dresden

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?