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

Weitere Magazine

Empfehlungen

Info

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. ENTWICKLUNG EINER SCHNITTSTELLE AUF BASIS DER MICROSOFT SPEECH API 51 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.
Seite 1 und 2: TECHNISCHE UNIVERSITÄT DRESDEN FAK
Seite 3 und 4: 1 Inhaltsverzeichnis 1 Einleitung 6
Seite 5 und 6: 3 5.3.4 Vokabular . . . . . . . . .
Seite 7 und 8: 5 Selbstständigkeitserklärung Hie
Seite 9 und 10: 2. ALLGEMEINE ANGABEN ZU SPRACHEING
Seite 17 und 18: 3. ALLGEMEINER AUFBAU EINES SPRACHE
Seite 25 und 26: 4. ERHÄLTLICHE PROGRAMME 23 4 Erh
Seite 27 und 28: 4. ERHÄLTLICHE PROGRAMME 25 4.1.3
Seite 29 und 30: 4. ERHÄLTLICHE PROGRAMME 27 4.2.4
Seite 31 und 32: 5. FREI VERFÜGBARE SPRACHERKENNER
Seite 43 und 44: 6. TESTS 41 6 Tests Alle drei Syste
Seite 45 und 46: 6. TESTS 43 Menüpunkt Anzahl richt
Seite 47 und 48: 6. TESTS 45 Menüpunkt Sphinx4 JLAB
Seite 49 und 50: 7. AUSWAHL EINES SPRACHERKENNERS 47
Seite 51: 7. AUSWAHL EINES SPRACHERKENNERS 49
Seite 55 und 56: 8. ENTWICKLUNG EINER SCHNITTSTELLE
Seite 65 und 66: 9. ABSCHLIESSENDE BETRACHTUNGEN 63
Seite 67 und 68: 9. ABSCHLIESSENDE BETRACHTUNGEN 65
Seite 69 und 70: 10. GLOSSAR 67 10 Glossar Erkennung
Seite 71 und 72: 10. GLOSSAR 69 Sprache zu Sprache u
Seite 73 und 74: 10. GLOSSAR 71 []
Seite 75 und 76: Literaturverzeichnis 73 [13] MICROS
Seite 77 und 78: Abbildungsverzeichnis 75 Abbildungs

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

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?