Universitatea POLITEHNICA București

Facultatea Automatică şi Calculatoare

Departamentul Automatică şi Informatică Industrială

LUCRARE DE DISERTAŢIE

Transformarea de voce in text cu Voice

Recognition (Recunoașterea vocală)

Coordonator ştiinţific:
Prof. Dr. Ing. Dan POPESCU

Masterand:
Ing. CAMACHI Balduino Estison Mugilila

Bucureşti – 2016
 Cuprins
1. Introducere ..................................................................................................................... 4
1.1. Beneficii ale sistemele de RV ................................................................................. 6
1.2. Aplicații potențiale pentru viitor ............................................................................. 6
1.3. Cum funcționează Recunoaștere vocală? ............................................................... 7
1.4. Cum este facut? ....................................................................................................... 7
1.4.1. Pasul 1: Extragerea fonemelor ......................................................................... 7
1.4.2. Pasul 2: Modele Markov ................................................................................. 9
2. Scopul proiectului ........................................................................................................ 10
3. Scurta istorie ................................................................................................................ 12
3.1. Secolul 21 ............................................................................................................. 14
4. Modelul acustic construit pe HMM ............................................................................. 15
4.1. Definiția HMM ..................................................................................................... 15
4.2. HMM şi recunoaşterea limbajului vorbit .............................................................. 16
4.3. Problema evaluării unui HMM ............................................................................. 17
4.4. Problema decodării unui HMM ............................................................................ 18
5. Recunoasterea vorbirii ................................................................................................. 19
5.1. Gramatici Context-free (bazate pe reguli) ............................................................ 20
5.2. Gramatici de Dictare ............................................................................................. 21
5.3. Limitari in recunoasterea de vorbire ..................................................................... 21
5.4. Modul de abordare a aplicatiilor de vorbire .......................................................... 23
5.5. Tehnologia de recunoaștere a vocală .................................................................... 23
5.6. Limitări și potențialele ale recunoașterea a vocală ............................................... 25
5.7. Viitorul ale Recunoașterea Vocală ....................................................................... 26
5.8. Aplicații ale Recunoașterii vocale: ....................................................................... 27
6. Formalismul recunoașterii automate limbii (vorbirii) ................................................ 32
7. Arhitectura unui sistem de recunoaştere automată a vorbirii ...................................... 32
8. Dezvoltarea aplicației .................................................................................................. 35
8.1. API în limbaje de procedură ................................................................................. 35
8.2. API în limbaje orientate pe obiect ........................................................................ 36
8.3. Arhitectura si biblioteci API ................................................................................. 38
8.4. API si protocoale .................................................................................................. 38
8.5. Obiect API de schimb și protocoale ..................................................................... 38
8.6. Obiect API de acces la distanță și protocoale ....................................................... 39
8.7. Partajarea API și reutilizarea prin mașină virtuală ............................................... 39
8.8. API-uri Web .......................................................................................................... 40
8.9. Utilizarea Web pentru a partaja conținut .............................................................. 40
8.10. Implementări ..................................................................................................... 41
8.11. Design API ........................................................................................................ 41
8.12. Release policies. ................................................................................................ 42
8.13. Implicații API publice ....................................................................................... 42
8.14. Deprecierea API-ului......................................................................................... 42
8.15. Exemple API ..................................................................................................... 43
8.16. Ce este JSAPI sau MSAPI? ............................................................................... 43
8.17. Scopurile a interfetei Speech API ..................................................................... 43
9. Dezvoltare versiunii Alpha/Beta ................................................................................. 43
9.1. Versiunea Alpha ................................................................................................... 43
9.2. Dezvoltare versiunii Beta ...................................................................................... 44
9.3. Rezultatele obținute in urma testelor .................................................................... 46

2
 9.3.1. Limba Portugheză .......................................................................................... 46
9.3.2. Limba română ................................................................................................ 48
9.3.3. Limba engleză................................................................................................ 49
10. Concluzii................................................................................................................... 51
11. Bibliografie ............................................................................................................... 52
12. Anexe ........................................................................................................................ 53

3
 1. Introducere
Recunoașterea vocală este procesul de convertire a cuvintelor vorbite în format
digital care poate fi utilizat ulterior pentru tipărire, arhivare, căutare. Termenul de
recunoaștere vocală poate însemna și recunoașterea vorbitorului. Domeniile de
aplicabilitate sunt: Medicină (transcriere medicala), Armată (comenzi vocale pentru
aparate de zbor), antrenarea controlorilor de zbor și pentru persoanele cu handicap.

Procesul recunoaşterii automate a vorbirii (RAV) vizează transformarea unui

semnal audio ce conţine vorbire într-o succesiune de cuvinte. Înţelegerea automată a
vorbirii extinde scopul RAV (generarea unei secvenţe de cuvinte) încercând să producă
informaţii de natură semantică privind înţelesul propoziţiei generate de sistemul de RAV.
În cazul în care semnalul acustic de intrare conţine vorbire provenind de la mai mulţi
vorbitori, procesul de RAV poate fi privit ca având două etape: diarizare (etapă ce încearcă
să răspundă la întrebarea: “cine şi când a vorbit?”) şi transcriere (etapă ce încearcă să
răspundă la întrebarea: “ce a spus?”).

Recunoașterea automată a vorbirii are o gamă largă de aplicabilitate. Domeniul cel

mai important pare a fi acela al interfeţelor hands-free și eyes-free. Există multe aplicaţii în
care utilizatorii au nevoie să-şi foloseasă mâinile și ochii pentru altceva, iar vorbirea
rămâne singura lor alternativă de a fi eficient în dialogul cu calculatorul. Mai mult decât
atât, vorbirea este cel mai natural mijloc de comunicare pentru fiinţele umane.

Alte domenii importante în care RAV se aplică cu succes sunt sistemele de dialog
pentru call-centere şi sistemele de traducere speech-to-speech. Traducerea speech-to-
speech este în acest moment un subiect foarte „la modă” în mai multe centre de cercetare
academice și industriale.

Nu în ultimul rând, RAV se poate utiliza şi pentru dictare: transcrierea unui

monolog al unui vorbitor anume. Transcrierea unui astfel de monolog este utilă în diverse
domenii, de la cea mai simpla utilizare pentru editarea documentelor de către jurnalişti,
scriitori, etc., până la utilizarea pentru transcrierea discuţiilor din timpul proceselor de
judecată.

Fiecare dintre aceste aplicaţii este de obicei mult mai restrictivă decât problema
generală care impune transcrierea automată a vorbirii naturale, continue, provenind de la
un vorbitor necunoscut, în orice mediu (zgomotos sau nu). Diferitele surse de variabilitate
în vorbire, care vor fi discutate în continuare, fac sarcina generală de RAV una foarte
dificilă. Cu toate acestea, în multe situaţii practice, variabilitatea este restricţionată.

De exemplu, vorbitorul ar putea fi cunoscut (în loc un număr oarecare de vorbitori

necunoscuţi sistemului) sau vorbirea ar putea fi dictată (în loc de vorbire spontană) sau
mediul de înregistrare ar putea ne-zgomotos și ne-reverberant. În recunoaşterea automată a
vorbirii se face o distincţie între modulul care abordează variabilitatea acustică (modelul
acustică) și modulul care tratează incertitudinea lingvistică (modelul de limbă).

Ce este de fapt recunoașterea vocală?

Recunoașterea vocală (RV) este o tehnologie în curs de dezvoltare, care va avea un
impact prin actualizarea asupra industriilor de telefonie, televiziune si a calculatoarelor,

4
tehnologia RV inca este folosita si in ziua de azi. Limita de dezvoltare ale aplicatiilor si a
resurselor de calcul, au fost costurile ridicate impreuna cu absenta standardelor comune de
a integra tehnonlogia de RV, ce implica aplicatii software.
Mediul afacerilor nu a acceptat inca RV, astfel de tehnologii au rezultat din
totalitatea veniturilor ale SUA, in valoare de 48 milioane de dolari, ce au avut loc in anul
1996. Conform spuselor lui William Meisel, din cadrul discursului numit „Actualizarea
Recunoașterii Vocală” afacerea nu a fost inca transferata la tehnologia RV, conform
calitatii prin capacitatea de a intelege cuvintele transmise, capactitatea de a diferentia
cuvintele precum: hair, here, hear, impreuna cu costurilor ridicate si a resurselor de calcul,
si lipsa standardelor comune de a integra tehnologia de RV, ce implica aplicatii software.

Recunoașterea vocală este o tehnologia capabila sa schimbe in mod radical interfata

(relatia) dintre utilizatori si calculatoare (si alte dispozitive care au capacitatii de calcul)
este desfasurata prin intermediul tastaturii si a mouse-ului. In orice caz, RV este un
ansamblu al provocarii tehnologice. Pentru a folosi RV, calculatorul trebuie sa
indeplineasca urmatorele conditii:
 Recunoasterea propozitii care a fost vorbita;
 Transcrierea propozitii in cuvinte separate;
 Interpretarea semnificatiei cuvintelor;
 Actiunea bazata pe interpretare printr-o maniera adecvata (ex: rezultatul
informatiilor analizate).
RV necesita o aplicație software „motor” cu logica construita pentru a descifra si sa
actioneze pe cuvantul vorbit. Exista trei puncte slabe principale, ce tin de dezvoltare, cu
cele mai multe „motoare” de RV disponibile:

 Imposibilitate de a decodifica recunoasterea vocală. Majoritatea motoarelor sunt

capabile sa interpreteze cuvintele care sunt vorbite clar cu o anumita cadenta intr-
un mediu lipsit de zgomot/interferente. Utilizatorul trebuie să invete limba specifica
a motorului de RV. Recunoasterea Vocală Conversationale (RVC) a fost dezvoltata
de Universitatea Stanford. Astfel, metoda conversationala semnifica faptul ca
motorul este pregatit sa adreseze intrebari, pentru a se asigura daca o comanda este
bine executata. In concluzie, RVC se familiarizeaza cu utlilizator spre deosebire de
a face utilizator sa se familiarizeze cu el.
 Lipsa standardelor pentru dezvoltarea rapida si aplicare economica. Comisia de
interfata de programare a RV (The Speech Recognition Programming Interface
Committee – RVAPI) lucreaza cu un consortiu de firme de tehnologie, pentru a
dezvolta standarde care vor aduce capacitati de RV in acceptare si utilizare in masa.
 Abilitatea de a interpreta contextul difuzorului este o limitare critica a tehnologiei
in ziua de azi. Este greu de programat un motor care recunoaste si interpreteaza
contextul difuzorului. Victor Zue e la MIT lucreaza pentru a imbunatati aceasta
situatie prin dezvoltarea unor motoare care pot opera in contextul domeniilor de
continut specificate.

Implicarea acestei tehnologii va varia, o data ce costul resurselor de calcul

devin mai rezonabile, standarde sunt dezvoltate, si motoare de RV sunt competente.
Majoritatea partilor mentionate sunt deja indeplinite. Costurile au inceput sa
reduca, produsele de RV pot rula la Calculatoare de nivel cu procesoare existente.

5
 Standarde au fost dezvoltate, dar inca trebuie sa fie imbunatatite. Numeroase
motoare au fost dezvoltate cu o gamă largă de capacități. Aceste progrese au avut
ca rezultat produse cum ar fi: Interactive Voice Response systems (IVRs), inclusiv
activități de call center și sisteme de mesagerie vocală. Cyber Voice Incorporated
este una dintre multele firme care foloseste tehnologia RV pentru a îmbunătăți
operațiunile de call center pentru clienți. Voice-to-text (VTT), aplicațiile care iau
dictare de cuvinte și cifre și în mod automat le introduce în cuvânt de procesoare /
foi de calcul și sunt utilizate pentru a efectua comenzi de calcul obișnuite. IBM si
alti firme de software oferă aplicații cu caracteristici similare. O listă cu alte
aplicații RV disponibile în comerț arată potențialul tehnologiei RV.

1.1. Beneficii ale sistemele de RV

 VTT crește eficiența lucrătorilor care desfășoară activități extinse de tastare sau de
date de intrare (numere și cuvinte pot fi dictate). Acest lucru ar putea fi deosebit de
benefic în mediile juridice, medicale și de asigurare în cazul în care se produc
cantități mari de dictare și transcriere.
 VTT RV aplicații au capacitatea de a preveni tulburările repetitive tulpina cauzate
de tastaturi. Se elimină necesitatea de a introduce sau de a folosi un mouse. Cu
toate acestea, incidente anecdotice de tulburări de voce cauzate de utilizarea de RV
sunt deja la suprafață în mass-media.
 VTT pot fi folosite pentru a ajuta persoanele cu dizabilități.
 Sistemele interactive de răspuns vocal au multe beneficii în gestionarea centrelor de
apel, prin reducerea costurilor de personal și prin selectarea apeluri telefonice și
apelurile către repartizarea furnizorul corect / corespunzătoare serviciului
(calculator sau utilizator).

1.2. Aplicații potențiale pentru viitor

 Discursul condus browsere web: Modificările de interfață de utilizator de la

tastatură / mouse-ul de vorbire. Acest lucru permite un acces mai mare la net,
deoarece un telefon poate servi ca interfață. Utilizatorii pot obține, teoretic, poștă
vocală și de e-mail utilizând această opțiune. E-mail ar putea fi citit pentru prin
intermediul software-sinteză vocală (text-to-voice sau TTV), care este deja viabile
din punct de vedere comercial.
 Servere RV de pe internet: Un client poate accesa internet și a vedea un anunț care
il interesează. Un simplu click pe un buton îi oferă o conexiune la internet pentru o
aplicație RV pe serverul companiei.
 Discursul condus de telefonie desktop: utilizator de telefon spune pur și simplu
"acasă apel", "conferință în Jeff" și dispozitivul de calculator-telefon integrat
execută comanda.
 Personal Digital Assistants (PDA) cu RV Capacitate: Dispozitivele nu ar avea
capacitatea de RV la nivel local (din cauza puterii de calcul), dar ar putea fi folosit
ca o interfață (prin intermediul serviciului de telefonie fără fir), între utilizator și un
server de la distanță cu capacitate de RV.

6
  Tehnica RV: Un utilizator mașină de spălat ar spune pur și simplu aparatul "începe
un ciclu rece". Puterea de calcul RV ar depinde de un PC central (acasă), sau pe
internet, care este conectat la aparat și execută comanda pentru el si alte
electrocasnice. PC-ul central sau internet, resurse este necesară deoarece costul
instalării puterii de calcul și a software-ului pe fiecare aparat în parte ar fi
neeconomică.

1.3. Cum funcționează Recunoaștere vocală?

Cum face un calculator conversie discurs vorbit în date pe care le poate apoi să
manipuleze sau să execute? Ei bine, dintr-o perspectivă generală, ceea ce trebuie
făcut? Inițial, atunci când vorbim, un microfon convertește semnalul analogic al
vocii noastre în bucăți digitale de date pe care computerul trebuie să analizeze. Este
de la aceste date că computerul trebuie să extragă informații suficiente pentru a
considera cu încredere cuvântul vorbit. Aceasta nu este o sarcină mică! De fapt, la
începutul anilor 1990, cele mai bune recognizers obținândiniau o rată de eroare de
15%. Acum, însă, că procentul de eroare a scăzut la la nivelul de 1-2%, deși acest
lucru poate varia de la om la om, depinde foarte mult accentul, si cat de clar o
persoana vorbeste.

1.4. Cum este facut?

1.4.1. Pasul 1: Extragerea fonemelor
Foneme sunt mai bine descrise ca unități lingvistice. Ele sunt sunetele pe care
impreuna formeaza cuvintele, modul în care un fonem se transformă într-un sunet depinde
de mai mulți factori, inclusiv fonemele din jur, difuzor de accent și de vârstă.
Exemple de foneme:
Fonemele cele mai evidente sînt chiar sunetele limbii respective, așa cum sînt ele
percepute de vorbitori. De exemplu, limba română standard folosește 7 foneme vocalice,
20 consonantice și 4semivocalice. Acest set situează limba română printre limbile cu un
număr mediu de foneme. Extremele se consideră a fi limba vorbită de
populația Pirahã din Brazilia cu doar 10 foneme în total, și
limba !Xóõ din Botswana și Namibia care dispune de 141 de foneme.
În categoria fonemelor intră și alte aspecte ale articulării cuvintelor, nu doar
sunetele propriu-zise. Există cîteva categorii de foneme numite "suprasegmentale," care țin
printre altele de accentul, tonurile, și lungimea fonemelor, silabelor sau cuvintelor unei
limbi.

[a] amar
[e] elev
[i] iris
[o] ocol
[u] uluc
[ ə] fără
[ ɨ] vîrî

7
 1.4.1.1. Accentul
În limba română fiecare cuvînt polisilabic are o anumită silabă pronunțată mai
puternic decît celelalte. În cele mai multe cazuri poziția schimbată accentului nu poate
modifica sensul unui cuvînt, putînd doar să dea acelui cuvînt un "accent" nenatural. Există
totuși situații cînd poziția accentului determină sensul cuvîntului, iar existența acestui
fenomen demonstrează că în limba română accentul este "fonemic." De exemplu, în
propozițiile silaba accentuată din lumina determină categoria gramaticală a cuvîntului
(substantiv, respectiv verb) și deci sensul acestuia. Prin comparație, în
limbile franceză, maghiară accentul este fix și deci nu poate modifica sensul cuvintelor.
Mergeam la lumina lanternei.
și
Lanterna nu lumina îndeajuns.

1.4.1.2. Cronemul

În multe limbi lungimea sunetelor poate fi un element cu rol important în

distingerea cuvintelor. Acest fonem se numește "cronem" (din grecește χρονος chronos:
timp) și se poate referi atît la durata vocalelor cât și la a consoanelor. Limba română are
foarte puține astfel de situații în care lungimea unui sunet este importantă, ca în cazul
consoanei n din cuvintele înot și înnod; pentru alte limbi însă diferențele de acest tip pot fi
numeroase și esențiale. De exemplu cuvintele englezești slip (a aluneca) și sleep (a dormi)
diferă în primul rînd prin lungimea vocalei (care antrenează și o schimbare în calitatea
acesteia). Similar, lungimea consoanelor (timpul de emitere sau de așteptare pînă la
emiterea consoanei) este importantă în unele limbi precum italiana sau japoneza. Mai mult,
unele limbi diferențiază chiar trei niveluri în lungimea vocalelor sau consoanelor;
astfel estona distinge vocale scurte, semi-lungi și superlungi și de asemenea are consoane
cu trei lungimi posibile în funcție de care se modifică sensul cuvintelor.

1.4.1.3. Tonuri

Unele limbi, ca de exemplu limbile cunoscute sub numele colectiv limba chineză,
dispun de foneme exprimate prin intonația dată individual fiecărei silabe. Toate limbile
folosesc un sistem sau altul de intonație (în limba română de exemplu intonația este
esențială pentru diferențierea enunțurilor de întrebări), dar numai în limbile tonale sensul
unui cuvînt separat se poate schimba o dată cu modificarea tonului. Exemplul clasic în
acest sens este cuvîntul "ma" din limba chineză, care în funcție de ton poate să aibă sensuri
complet diferite.

Foneme sunt adesea extrase prin rularea de undă printr-o transformare Fourier.
Aceasta permite forma de undă să fie analizată în domeniul de frecvență. Este, probabil,
mai ușor de înțeles acest principiu prin uita la un spectrograf. Un spectrograf este un grafic
3D a unei forme de undă de frecvență și amplitudine în funcție de timp. În multe cazuri
însă, amplitudinea frecvenței este exprimată ca o culoare (nuanțe de gri, fie, sau o culoare
gradient).

8
 1.4.2. Pasul 2: Modele Markov

Acum, că computerul generează o listă de foneme, urmatorul pas este evident că

aceste foneme trebuie să fie convertite în cuvinte și poate chiar cuvintele în propoziții.
Cum acest lucru se întâmplă poate fi foarte complicat, într-adevăr, în special pentru
sistemele proiectate pentru difuzoare independente dictare, continuă.
Cu toate acestea, cea mai des întâlnită metodă este de a folosi un model Markov
ascunse (HMM). Teoria din spatele HMMs este complicată, dar o scurtă privire la simplu
Modele Markov va ajuta să câștige o înțelegere a modului în care acestea funcționează.
In principiu, cred că un model Markov (într-un context de recunoaștere a vocii) sub
forma unui lanț de foneme care reprezintă un cuvânt. Lanțul de ramură poate, iar în cazul
în care o face, este echilibrat statistic. De exemplu:

De luat in considerare că acest model Markov reprezintă atât în limba engleză

americană și metodele (reale) din engleză a spune cuvântul "tomato". În acest caz, modelul
este ușor înclinată spre pronuntare de limba engleză. Această idee poate fi extinsă până la
nivelul pedepselor, și poate îmbunătăți foarte mult de recunoaștere.

9
 2. Scopul proiectului
Scopul proiectului consta in realizarea unei aplicații informatice capabila sa
recunoască limba in care este scris un text prin intermediul vocii. Particularitatea acestei
aplicații, fata de alte rezultate similare, consta in faptul ca limba e recunoscuta in mod
dinamic, deoarece textul nu este introdus static, ci este primit de aplicație in mod continuu,
sub forma de flux. De asemenea, textul poate fi scris in mai multe limbi, iar fragmentele de
text scrise in limbi diferite pot fi chiar si de numai câteva cuvinte.

Problemele care propuse vor fi tratate.

 Etapa 1:
Scopul acestei etape este de a realiza o analiza informatica a sistemului de
conversie de text in voce cu recunoașterea automata a limbii, precum si de a defini
specificațiile sistemului care urmează sa fie realizat. Prezentul studiu trece prin a studia
metodele deja existente pe piața.
 Etapa 2:
In etapa al doilea sunt prezentate principalele metode. Prima metoda prezentata se
refera la analiza unui text care conține fragmente scrise in limbi diferite (text multilingv);
este prezentata identificarea limbii si transcrierea dependenta de aceasta, precum si analiza
dependenta de limba a structurii sintactice a textului analizat.

Identificarea limbii prin metoda statistică a analizei n-gramelor este probabil ce mai
folosită metodă; în acest studiu se prezintă elementele teoretice ale metodologiei pe baza
căreia urmează să fie elaborat algoritmul aplicaţiei, ţinând cont de specificaţiile care vor fi
definite ulterior. Etapa 2 se încheie cu prezentarea altor abordări utilizate la identificarea
limbii.

Analiza aplicațiilor de recunoaștere a limbii existente la ora actuala, este importanta

deoarece permite identificarea know-how-ului care poate fi folosit in proiectul meu,
precum si problemele care ramân de rezolvat in contextul particular al implementărilor
avute in vedere.

Diversele limbi vorbite prezintă provocări diferite pentru un sistem de recunoaştere

a vorbirii. Pentru un număr covârşitor de mare de limbi nu există suficiente resurse
acustice (baze de date de vorbire) şi lingvistice (corpusuri de text). Aceste aşa-numite limbi
slab dotate sunt vorbite de un număr mare de oameni, însă până acum s-au achiziţionat
prea puţine resurse acustice şi lingvistice pentru a putea dezvolta un sistem de RAV. În
consecinţă, proiectarea şi crearea unui sistem de RAV trebuie să prevadă şi colectarea
acestor resurse. 2 Alte limbi “suferă” de o morfologie foarte complexă. De exemplu
limbile cu morfologie complexă, cum ar fi Franceza, Romană sau Portugheza, au
vocabulare de dimensiuni mai mari decât limbile cu morfologie simplă, cum ar fi Engleză.
Timpul prezent al verbului ir care înseamnă a merge are şase forme diferite în limba
Portugheza: vou, vais, vai, vamos, ides, vão; cinci forme diferite în limba Română: merg,
mergi, merge, mergem şi mergeţi, şi şase forme diferite în Franceză: vais, vas, va, allons,
allez, vont.

În Engleză, acelaşi verb, la acelaşi timp, are doar două forme morfologice diferite:
go şi goes. Limbile Germană şi Turcă sunt două dintre aşa-numitele limbi aglutinative. În
aceste limbi se pot forma cuvinte noi prin concatenarea altor cuvinte sau morfeme. Astfel

10
dimensiunea vocabularului de cuvinte pentru o limbă aglutinativă este mult mai mare,
acest lucru complicând sarcina de recunoaştere automată a vorbirii.

Dimensiunea vocabularului este de asemenea un factor important care influenţează

dificultatea sarcinii de RAV. Este evident faptul că o sarcină de recunoaştere de cifre (cu
un vocabular de 10 cuvinte) este mult mai simplă decât, de exemplu, recunoaşterea vorbirii
spontane (cu un vocabular de 64.000 de cuvinte). Cu toate acestea, dimensiunea mare a
vocabularului nu înseamnă neapărat că sarcina de recunoaştere va fi mai dificilă.
Incertitudinea lingvistică a potenţialelor discursuri ce trebuie recunoscute constituie de
asemenea un factor important. De exemplu, o sarcină de RAV specifice turismului (cu un
vocabular de 64 de mii de cuvinte conţinând în general nume de locuri, hoteluri,
restaurante, etc.) nu este atât de dificilă ca o sarcină de recunoaştere a vorbirii spontane (cu
un vocabular de de aceeaşi dimensiune). Incertitudinea lingvistică (perplexitatea) scăzută a
primeia o face mult mai simplă.

Procentul de cuvinte incorecte obţinut pentru diverse sarcini de recunoaştere este

prezentat în Tabelul 1. Datele se referă la sisteme state-of-the-art de RAV pentru limba
Engleză [Jurafsky, 2009]. Rata de cuvinte eronate (word error rate - WER) este criteriul de
performanţă standard utilizat în evaluarea sistemelor de RAV. Pentru mai multe informaţii
despre acest criteriu de performanţă consultaţi platforma „Evaluarea unui sistem de
recunoaștere a vorbirii continue”.
Tabelul 1. Rezultate WER raportate in anul 2005 pentru diverse sarcini de RAV [Jurafsky,
2009]

Sarcina de RAV Dimensiunea vocabularului WER[%]

TI Digits 11 cuvinte 0.55
Wall Street Journal read speech 5000 cuvinte 3.0
Wall Street Journal read speech 20000 cuvinte <6.6
Broadcast News 64000+ cuvinte 9.9
Conversational Telephone speech 64000+ cuvinte 20.7

Un alt factor important care influenţează dificultatea procesului de RAV este stilul
vorbirii. Stilul vorbirii se referă la cât de fluentă, naturală sau conversaţională este vorbirea
ce trebuie recunoscută. În mod evident, recunoașterea de cuvinte izolate, unde cuvintele
sunt separate de pauze de linişte, este mult mai simplă decât recunoașterea vorbirii
continue, unde cuvintele sunt pronunţate legat şi vorbirea trebuie segmentată înainte de
recunoaştere. De fapt, primele sisteme de recunoaștere automată a vorbirii puteau rezolva
problema localizării graniţelor între cuvinte numai dacă vorbitorul făcea pauze generoase
în pronunţarea lor: Dragon Dictation [Baker, 1989] este un bun exemplu de un sistem de
recunoaştere de cuvinte izolate cu vocabular extins.
Sarcinile de recunoaştere a vorbirii continue pot fi mai departe clasificate în funcţie
dificultatea lor. De exemplu, sarcina de recunoaștere a vorbirii citite este mult mai simplă
decât sarcina de recunoaștere a vorbirii conversaţionale sau spontane. Variabilitatea
acustică mai mare face ca sarcina urmă să fie mai dificilă. Această diferenţă în dificultate
între sarcinile de vorbire continue este reflectată în ratele crescute de eroare pentru
recunoașterea vorbirii spontane, comparativ cu recunoașterea vorbirii citite (a se vedea
Tabelul 1).

11
 3. Scurta istorie
Încă din anul 1932, cercetători de la Bell Labs ca Harvey Fletcher investigau știința
percepției vorbirii. În 1952 trei cercetători de la Bell Labs au construit un sistem de
recunoaștere de cifre cu un singur difuzor. Sistemul lor a lucrat prin localizarea formanților
în spectrul de putere al fiecărui enunț. Tehnologia anilor 1950, era limitata la sisteme cu un
singur vorbitor cu vocabulare de aproximativ zece cuvinte.

Din păcate, finanțarea de la Bell Labs s-a anulat timp de mai mulți ani, când, în
1969, John Pierce, un om cu influența a scris o scrisoare deschisă, care a fost critic legat de
cercetare de recunoaștere a vorbirii. Scrisoare lui a comparat Pierce recunoaștere a vorbirii
cu "scheme pentru transformarea apei în benzină, extragerea aurului de la mare, in tratarea
cancerului, sau de a merge la luna." Pierce a oprit fluxul de fonduri către cercetare de
recunoaștere a vorbirii la Bell Labs.

Raj Reddy a fost prima persoană care a contiunuat recunoașterea vorbirii ca student
absolvent de la Universitatea Stanford, la sfarsitul anilor 1960. Sistemele anterioare
impuneau utilizatorii să facă o pauză după fiecare cuvânt. Sistemul lui Reddy a fost
conceput pentru a emite comenzi pentru jocul vocale de șah. De asemenea, în jurul aniilor
60 cercetătorii sovietici au inventat timp dinamic colmatare algoritm si au folosit pentru a
crea un ”recognizer” capabil să funcționeze pe un vocabular de 200 de cuvinte. Obținerea
independenței difuzorului a fost un obiectiv major al cercetătorilor nerezolvat pe parcursul
acestei perioade de timp.

În 1971, DARPA a finanțat cinci ani de cercetare de recunoaștere a vocii, prin

programul său de cercetare de vorbire înțelegere cu obiective finale ambițioase, inclusiv o
dimensiune minimă de vocabular de 1000 de cuvinte. Bolt, Beranek and Newman
Technologies (BBN Technologies) , International Business Machines Corporation (IBM),
Carnegie Mellon University (CMU) și Stanford Research Inistitute (SRI), toate au
participat la acest program. Finanțare de la guvern pentru cercetarea de recunoaștere a
vorbirii care a fost abandonat în mare parte, în Statele Unite, după scrisoarea lui John
Pierce. În ciuda faptului că sistemul lui Harpy de la CMU a îndeplinit obiectivele stabilite
la începutul programului, multe dintre predicțiile s-au dovedit a fi nimic mai mult decât
publicitate intensivă, dezamăgind administratorii de la DARPA. Acest lucru a dus la
dezamăgire DARPA sa nu continue cu finanțarea. Mai multe tipuri de inovații întâmplat în
acest timp, cum ar fi inventarea căutare fasciculului pentru utilizare în sistemul lui Harpy
de la CMU.
De asemenea, domeniul a beneficiat de descoperirea mai multor algoritmi în alte domenii,
cum ar fi codificarea predictivă lineară și analiza Cepstrala.

În timpul anilor 1960 Leonard Baum a dezvoltat matematica lanț Markov la

Institutul pentru Analiza Apărării. La CMU, studenții lui Raj Reddy, James Baker si Janet
Baker au inceput sa foloseasca Modelul Markov cu stari invizibile (Hidden Markov
Models - HMM) pentru recunoașterea vorbirii. James Baker a aflat despre HMM de la un
loc de muncă de vară la Institutul de Analiza Apărării în timpul educației sale universitare.
Utilizarea HMM a permis cercetatorilor sa combine diferite surse de cunoaștere, cum ar fi
o acustică, limba și sintaxă, într-un model probabilistic unificat.

Sub conducerea lui Fred Jelinek, IBM a creat o mașină voice activated de scris
numita ”Tangora”, care ar putea să se ocupe de un vocabular de 20.000 cuvânt de la
12
mijlocul anilor 1980. Abordarea statistică Jelinek a pus un accent mai puțin pe emularea
modul în care procesele de creier uman și înțelege vorbirea în favoarea utilizării tehnicilor
de modelare statistice cum ar fi HMM. (Grupul Jelinek descoperit în mod independent,
aplicarea HMM în vorbire.) Acest lucru a fost controversat cu lingviști, deoarece HMM
sunt prea simplist pentru a explica multe caracteristici comune ale limbilor umane. Cu
toate acestea, HMM s-au dovedit a fi o modalitate extrem de utilă pentru modelarea
vorbirii și a înlocuit timp dinamic urzirea pentru a deveni dominatul algoritmului de
recunoaștere a vorbirii în 1980. IBM a avut câțiva concurenți, inclusiv Dragon Systems
fondat de James si Janet Baker în 1982. 1980 a văzut, de asemenea, introducerea modelului
limbajului n-gram. Katz a introdus modelul de back-off în 1987, care a permis modele
lingvistice să utilizeze mai multe lungime n-grame. În același timp, de asemenea, a fost
CSELT (Centro Studi e Laboratori Telecomunicazioni) a folosit HMM (în special, a
diphonies) să recunoască cum ar fi limba italiană. În același timp, CSELT a condus o serie
de proiecte europene (Esprit I, II), și a rezumat state-of-the-art într-o carte, mai târziu
(2013), republicat.

O mare parte a progresului în domeniu se datorează capacitățile în creștere rapidă a

calculatoarelor. La sfârșitul programului DARPA în 1976, cel mai bun calculator la
dispozitia cercetatorilor a fost PDP-10 cu 4 MB RAM. Cu ajutorul acestor calculatoare ar
putea dura până la 100 de minute pentru a decoda doar 30 de secunde de vorbire. Cateva
decenii mai tarziu, cercetatorii au avut acces la zeci de mii de ori ca putere de calcul mult.
Pe măsură ce tehnologia avanseaza și calculatoarele mai repede au ajuns, cercetatorii au
inceput abordarea problemelor mai dificile, cum ar fi vocabulare mai mari, independența
difuzorului, medii zgomotoase și vorbire de conversație. În special, această schimbare a
sarcinilor mai dificile și-a caracterizat prin fonduri de la DARPA de recunoaștere a vorbirii
începând cu anii 1980.

De exemplu, s-au înregistrat progrese cu privire la independența difuzorului în

primul rând prin formarea pe o varietate mai mare de vorbitori și apoi mai târziu de a face
adaptarea difuzorului explicit în timpul decodificare. Reduceri suplimentare ale ratei de
eroare de cuvânt a venit cand cercetatorii au mutat modele acustice pentru a fi
discriminativ în locul utilizării modelelor de probabilitate.

Încă unul dintre foștii studenți lui Raj Reddy, Xuedong Huang, a dezvoltat sistemul
Sfinx-II la CMU. Sistemul Sphinx-II a fost primul care a făcut-difuzor independent,
vocabular mare, recunoaștere continuă vorbire și a avut cea mai bună performanță în
evaluarea DARPA 1992. Huang a continuat cu recunoaștere a vorbirii la Microsoft în
1993.
In 1990 s-a văzut prima introducere a tehnologiilor de recunoaștere a vorbirii de
succes comercial. Până la acest punct, vocabularul sistemului de recunoaștere a vorbirii
tipic comercial a fost mai mare decât vocabularul uman mediu. In anul 2000, Lernout &
Hauspie a achizitionat Dragon Systems si a fost un lider in industrie pana cand un scandal
contabil a pus capăt companiei în 2001. Tehnologia L & discurs H a fost cumpărata de
ScanSoftTM, care a devenit Nuance în 2005. În 2011 Nuance a achiziționat Loquendo,
compania de spin-off din fostul grup de tehnologie CSELT în 2001. Apple si-a inițial
software-ul de la Nuance pentru a oferi capacitatea de recunoaștere a vorbirii a asistentului
său digitală ”Siri”.

13
 3.1. Secolul 21

In 2000 DARPA a sponsorizat două programe de recunoaștere a vorbirii: Effective

Affordable Reusable Speech-to-text în 2002 (EARS) și Global Autonomous Language
Exploitation (GALE). Patru echipe au participat la programul EARS: IBM, o echipa
condusa de BBN cu Laboratoire d’informatique pour la mécanique et les sciences de
l’ingénieur (LIMSI) și Universitate din Pittsburgh, Universitatea Cambridge, si o echipa
compusa din International Computer Science Institute (ISCI), SRI si Universitate din
Washington. Programul GALE s-a axat pe arabă și mandarină deseminat pentru știri.
Primul efort de la Google legat de recunoaștere vocală a venit în 2007, după angajarea unor
cercetători de la Nuance. Primul produs a fost GOOG-411, un serviciu director telefonic.
Înregistrările din GOOG-411 au produs date valoroase care au ajutat Google să
îmbunătățească sistemele lor de recunoaștere. Google voice search este acum acceptată în
peste 30 de limbi.

In Statele Unite, Agenția Națională de Securitate (National Security Agency –

NSA) a folosit un tip de recunoaștere a vocii pentru formarea petelor de cuvinte cheie, cel
puțin din 2006. Această tehnologie permite analiștilor să caute prin volume mari de
conversații înregistrate și să izoleze menționarea de cuvinte cheie. Înregistrările pot fi
indexate și analiștii pot rula interogări asupra bazei de date pentru a găsi conversații de
interes. Unele programe de cercetare guvernamentale s-au concentrat asupra cererilor de
informații de recunoaștere a vorbirii, de exemplu Programul EARS de la DARPA și
programul Babel de la IARPA.

La începutul anilor 2000, recunoaștere a vorbirii era încă dominată de abordările

tradiționale, cum ar fi Modelul lant Markov combinate cu rețele neuronale artificiale
feedforward. Astăzi, cu toate acestea, multe aspecte ale recunoașterii vorbirii au fost
preluate printr-o metodă de învățare profundă numit memoria lunda pe termen scurt (Long
short-term memory - LSTM), o neuronale recurente de retea (Recurrent Neural Network –
RNN) publicat de Sepp Hochreiter & Jürgen Schmidhuber în 1997. RNNs LSTM evita
problema cu gradient de dispariție și pot învăța sarcini "Foarte adânc Learning", care
necesită amintiri ale unor evenimente care au avut loc mii de etape de timp discrete în
urmă, ceea ce este important pentru vorbire. În jurul anului 2007, LSTM antrenat de
conexioniste Clasificarea Temporal (CTC) a început să depășească recunoașterea
tradițională vorbirii în anumite aplicații. În 2015, recunoaștere vocală de la Google, a
cunoscut un salt de performanță dramatică de 49%, prin CTC-instruit de LSTM, care este
acum disponibil prin intermediul Google Voice pentru toți utilizatorii de smartphone-uri.

Utilizarea de feedforward profunde a rețelelor (non-recurente) pentru modelarea

acustică a fost introdusă în timpul ultimei părți a anului 2009 de către Geoffrey Hinton și
studenții săi de la Universitatea din Toronto si de Li Deng si colegii sai de la Microsoft
Research, inițial în activitatea de colaborare între Microsoft și Universitatea din Toronto,
care a fost ulterior extins pentru a include IBM și Google. Un director de cercetare
Microsoft a numit această inovație "schimbarea cea mai dramatică acuratețe din 1979."
Spre deosebire de îmbunătățiri progresive de echilibru ale ultimelor decenii, aplicarea
învățare profundă a scăzut rata de eroare cuvânt cu 30%. Această inovație a fost adoptată
rapid peste câmp. Cercetătorii au început să folosească tehnici de învățare profundă pentru
modelarea limbajului, de asemenea.

14
 În lunga istorie a recunoașterii vorbirii, atât sub formă superficială și forma
profundă (de exemplu, plasele recurente) ale rețelelor neuronale artificiale au fost explorate
de mai mulți ani, pe parcursul anilor 80, 90, și de câțiva ani, în 2000. Dar aceste metode nu
a câștigat niciodată pe non-uniform intern-gaussian model de model de împletesc amestec /
Markov ascunse (MMG-HMM), tehnologia bazată pe modele generative de vorbire
discriminativele de vorbire. O serie de dificultăți-cheie au fost bine analizate în anii 1990,
inclusiv diminuarea gradientului și structură slabă de corelare temporală în modelele
predictive neuronale. Toate aceste dificultăți au fost un plus pentru rezolvarea problemelor
de ziua de azi, din cauza puterii mare de calcul. Cei mai mulți cercetători de recunoaștere a
vorbirii care au înțeles aceste bariere, prin urmare, au schimbat plase neuronale pentru a
urmari modelarea generativă care se apropie până la recenta reapariția învățării profunde în
jurul începând cu 2009-2010, si au reusit sa depășeasca toate aceste dificultăți.

4. Modelul acustic construit pe HMM

4.1. Definiția HMM

Modelele Markov Ascunse (HMM) sunt folosite în mod eficient în recunoașterea

de forme. Privind recunoaşterea vorbirii ca un caz particular, această metodă statistică
poate fi folosită cu succes datorită avantajelor pe care le oferă. Faţă de modelele Markov
simple, în cazul HMM-urilor nu există o bijecţie între stare şi ieşire. Acesta oferă
flexibilitate mai mare şi se potrivește foarte bine semnalului vocal, în care același fonem
poate avea durate diferite după caz. Un exemplu de HMM este prezentat în Figura
urmatoarea:

Un exemplu de HMM cu 5 stări din care prima și ultima nu sunt emisive

Prima şi ultima stare nu sunt emisive. În rest, fiecare stare emite o valoare după o
anumită funcție de distribuție de probabilitate. În această lucrare nu sunt permise decât
tranzițiile din starea i în stările i, i+1 și i+2.
Probabilitățile de tranziție constituie matricea de tranziție A. Tranzițiilor nepermise
le corespunde o probabilitate de tranziție egală cu 0.
Un HMM este complet definit prin:
 O= {o1, o2,…. oM} - Un alfabet pentru observaţiile de la ieşire, pentru cazul în care
această mulțime este discretă.

 Ω= {1,2,…,N} – Spatiul de stari.

15
  A={aij} – Matricea cu probabilităţiile de tranziţie, unde aij este probabilitatea de a
trece din starea i în starea j.
 B={bi(k)} – Matricea de ieşire, unde bi(k) este probabilitatea să se emită simbolul
ok la starea i. Pentru cazul în care ieșirea unui HMM ia valori continue, atunci bi(k)
este o funcție de densitate de probabilitate (în particular, la această lucrare ieșirea
unei stări este modelată printr-o mixtură gaussiană).
 Π = {πi} – Probabilitatea ca starea iniţială să fie starea i. Pentru ca un HMM să fie
complet, este nevoie să se specifice numărul de stări N, dimensiunea M a
alfabetului de observaţii O (dacă este cazul), şi matricile de probabilităţi A, B, Π.
Aşadar un model îl putem nota cu:
Ф=(A, B, Π)

Ca să putem aplica acest model în lumea reală trebuie rezolvate următoarele probleme:
A. Problema evaluării – Dat fiind un model Φ şi o secvenţă de observaţii
O=(O1,O2,...,OT), care este probabilitatea P(O|Φ) ca această secvenţă O să fi fost
generată de modelul Φ?

B. Problema decodării – Dat fiind un model Φ şi o secvenţă de observaţii

O=(O1,O2,...,OT), care este cea mai probabilă secvenţă de stări S=(s0,s1,...,sT) ale
modelului care a generat aceste observaţii?

C. Problema antrenării – Dat fiind un model Φ şi un set de observaţii, cum putem

ajusta parametrii modelului Φ astfel încât să maximizăm probabilitatea
ΠP(O| Φ)?
o

În esență, recunoașterea formelor sau a vorbirii constă în a decide care model (sau
succesiune de modele) se potrivește cel mai bine cu un set de observaţii date pe baza
probabilităţii P(O|Φ). Ceea ce înseamnă că problema recunoașterii în sine este rezolvată
dacă avem modele antrenate. Decodarea este importantă la antrenarea HMM-urilor în cazul
recunoaşterii vorbirii continue. Cea mai dificilă este problema antrenării sau a estimării.
Dintr-un set de date de antrenare trebuie estimați parametrii HMM-ului astfel încât ei să
caracterizeze cât mai bine unitatea de voce aleasă.

4.2. HMM şi recunoaşterea limbajului vorbit

Semnalul vocal se imparte în entităţi elementare, de exemplu: cuvinte, foneme,

difoneme, trifoneme, alofone. Fiecărei entităţi i se asociază un HMM, iar stării unui HMM
i se poate asocia o fereastră de timp aleasă cu parametrii de voce calculaţi pentru această
fereastră. Dimensiunea ferestrei se alege astfel încât parametrii semnalului vocal să fie
constanţi pe acea durată (valori uzuale sunt 10, 20, 30ms). Se poate imagina că în timpul
vorbirii, tractul vocal trece printr-o serie de stări (care sunt modelate cu stările HMM) şi în
fiecare stare se emite un segment din semnalul vocal cu un vector de parametrii care vor
constitui ieşirea stării HMM-ului. Parametrii de voce care se folosesc la recunoaştere sunt
MFCC, PLP, LPC, etc.

Cum parametrii de voce iau valori intr-un spaţiu continuu trebuie ca şi vectorul de
ieşire al HMM-ului sa aibă valori continue. Din acest motiv se folosesc mixturile gaussiene
pentru modelarea ieșirii stărilor HMM-ului. Fiecare parametru al vectorului de ieşire poate
fi modelat printr-o sumă ponderată de funcţii de distribuţie normală:

16
unde:

unde O=[o1,o2,..,on]’ este vectorul de observaţie n-dimensional, n este numărul de

parametrii de voce pe care ii extragem din observaţii, |Σ| este determinantul matricii
diagonale de covarianţă, G este numărul de componente ale mixturi şi wjg este ponderea
componentei g ale stării j.

4.3. Problema evaluării unui HMM

Problema evaluării unui HMM constă în calcularea probabilității P(O|Φ), adică

probabilitatea ca observația O să fie generată de modelul Φ. Această problemă este
rezolvată prin algoritmul progresiv. Probabilitatea progresivă este definită ca fiind:
α j (t) = P(o1 ,...,ot , x(t) = j | M)

Adică, α este probabilitatea ca modelul M să fi generat primele t observații, dacă la

momentul t se află în starea j. Această probabilitate se calculează recursiv:

Trebuie observat că se sumează toate probabilitățile obținute din toate stările care în
momentul t tranzitează în starea j. Cum prima și ultima stare a HMM sunt non-emisive,
rezultă următoarele condiții inițiale și finale:

Din definiția probabilitații progresive rezultă că:

P(O | M) = α N (T)

Trebuie observat că algoritmul progresiv calculează probabilitatea ca modelul M să

fi generat secvența de observații O, luând în considerare toate drumurile care pot fi
parcurse prin stările modelului. Există o discrepanță între modul în care se calculează
această probabilitate la antrenare și la recunoaștere. La recunoaștere, se ia în considerare
doar drumul (succesiunea de stări) care are cea mai mare probabilitate. Această
simplificare se face pentru reducerea complexității algoritmului de decodare.

17
 Mai trebuie observat că probabilitatea bj(ot), fiind valoarea unei funcții de densitate
de probabilitate într-un punct, este un scor (likelihood în limba engleză) obținut de fiecare
stare pentru un vector de observație dat. De aceea, în această lucrare se va folosi, în
continuare,noțiunea de scor.

4.4. Problema decodării unui HMM

Problema decodării coincide cu problema recunoașterii. Deși la recunoaștere ne

interesează doar modelul cel mai probabil, există cazuri, de exemplu în cazul vorbiri
continue, unde explicitarea (decodarea) secvenței de stări devine necesară. Prin vorbire
continuă, aici se înțelege cazul în care dintr-o secvență de observații trebuie gasită cea mai
probabilă secvență de modele și nu se știu a priori granițele între cuvinte. Așadar, în acest
caz pentru evaluarea HMM-ului se poate folosi o formulă similară ca cea folosită în
algoritmul progresiv înlocuind funcția de însumare cu funcția de maxim. Astfel, se
definește probabilitatea maximă de a genera secvența de observații de la momentul 1 la
momentul t:

Pentru a nu lucra cu numere mici, se folosește probabilitatea logarítmica devine:

Această formulă stă la baza algoritmului Viterbi de decodare [124]. În fond,

algoritmul Viterbi găsește drumul optim într-o rețea de noduri, în care cele două
dimensiuni sunt ferestrele de timp și stările modelelor Markov. Termenul log(bj(ot))
reprezintă scorul nodului iar termenul log(aij) reprezintă scorul tranziției.
Algoritmul Viterbi poate fi sumarizat cum este arătat mai jos:

18
 Algoritmul de decodare Viterbi

5. Recunoasterea vorbirii
Recunoasterea vocii este un process de convertire a limbii vorbite intr-un text scris
sau o forma similara. Caracteristicile de baza a unui recunoscator de voce care are ca
suport Java Speech API sunt:
 Suporta o singura limba specificata;
 Proceseaza un singur stream audio de intrare;
 Se poate optional sa adapteze vocea pentru toti useri ;
 Gramatica poate fi updatata dynamic;
 Are un mic set definit de propietati a unor aplicatii controlabile.

Pasi principali a unui recunoscator de voce tipic sunt:

 Designul gramaticii: in gramatica sunt definite cuvinte care ar putea fi rostite de

un utilizator si conditiile in care pot fi rostite.O gramatica trebuie sa fie creata si
activata de un recunoscator pentru a stii ce sa asculte pentru streamul
audio.Gramatica este descrisa mai jos in detaliu.
 Procesarea semnalului: analizarea caracteristicile spectrum-ului(frecventelor) a
urmatorului semnal audio.

 Recunoasterea fonetici(“phoneme”): compara modelul spectrului cu modelul

fonetici a limbi care trebuie recunoscuta (o scurta descriere a fonetici este data in
sectiunea “Sintetizarea vorbirii” in discutia conversia text-in-fonetica ).

 Recunoasterea cuvintului: compara secventa de fonetici cu cuvinte si modele de

cuvinte specificate de gramatica activa.

19
  Generarea rezultatului : ofera aplicatiei cu informatii despre cuvinte care au fost
detectate de recunoscator in streamul audio urmator. Rezultatul informatiei este
intotdeauna dat dupa ce recunosterea propozitiei este completa, dar poate fi data si
in timpul procesului de recunoastere. Rezultatul intotdeaunea indica cea mai buna
“ghicire” a motorului de vorbire a ceea ce a spus utilizatorul, dar poate indica si o
“ghicire” alternative.

Cele mai multe procese a unui motorului de vorbire sunt automate sin u sunt
controlate de creatorul aplicatiei. De exemplu, plasarea microfonului, zgomotul de fond,
calitatea placii de sunet, performantele sistemului, puterea procesorului si sistemul de sunet
folosit , toate afecteaza performanta recunoscatorului de vorbire care este peste controlul
aplicatiei.
Modul principal cum o aplicație controleaza acivitatea motorului de vorbirei este prin
controlare gramaticii.

O gramatica este un obiect in Speech API care indica ce cuvinte un utilizator se

asteapta sa zica si in ce modele acele cuvinte ar putea aparea.Gramaticile sunt importante
pentru motorulde vorbire pentru ca controleaza procesele de recunostere. Aceste controale
fac ca recunosterea sa fie mai rapida si cu o acuratețe crescuta , pentru ca motorul de
vorbire nu trebuie sa verifice propoziti bizare, cum ar fi “umfla te risul”.
Speech API suporta doua tipuri de gramatici: rule grammars si dictation grammars.
Aceste tipuri de gramatici difera in sensul in care aplicatiile seteaza gramaticiile, tipurile de
fraze premise; in sensul in care rezultatele sunt date, cantitatea de resurse calculate
necesare, si in sensul in care aceste sunt folosite efectiv in designul aplicatiei. Tipurile de
gramaticii sunt descrise in detaliu mai jos.

Alte controale de recunoastere de vorbire sunt disponibile intr-o aplicatie, care

include “pauza” si “reîntoarcerea” in procesul de recunoastere, directia a evenimentelor
rezultate si alte evenimente legate de procesele de recunoastere, si controlul vocabularului
motorului de vorbire.

5.1. Gramatici Context-free (bazate pe reguli)

Intr-un sistem de recunoastere a vorbiriii bazat pe reguli, o aplicatie ofera motorului

de vorbire reguli care defineste cea ce este asteptat sa spuna utilizatorul. Aceste
reguli limiteaza procesele de recunoastere. Un design precaut a regulilor, combinat cu un
design precaut a interfetei utilizatorului, va produce reguli care permite utilizatorului o
libertate de expresie rezonabila si in acelasi timp limitand o gama de cuvinte care pot fi
spuse, pentru ca procesele de recunoastere sa fie cat se poate de rapide.
Orice recunoscator de voce care suporta un Speech API trebuie sa aiba ca support
reguli de gramatica.
Urmatorul exemplu este o simpla regula de gramatica. Poate fi reprezentat in Java
Speech Grammar Format Specification.
Gramatica permite unui utilizator sa spuna comenzi cum ar fi “Open the window”
si “Please close the window and the file”.
Java Speech Grammar Format Specification defineste comportarea a regulilor de
gramatica si discuta cat de complexa o gramatica poate fi construita prin combinarea a
gramaticiilor mai mici. Cu aplicatii JSGF eu pot sa refolosesc gramatici, ne poate da stiluri
de documentatii Javadoc si pot sa folosesc facilitatile ce activeaza sisteme avansate de
vorbire.
20
 5.2. Gramatici de Dictare

Gramaticile de dictatre impune cateva restrictii a cea ce se poate spune, facand mai
acesibil intrari de voce. Costul a unei libertati mai mari este aceea de a necesita un sistem
mai performant cu calitea de placi audio mai ridicata si tinde spre mai multe erori.

O gramatica de dictare este de obicei mai mare si mai complexa decat o gramatica
bazata pe reguli. Acesata gramatica este realizata pe o statistica care cuprinde o colectie de
text scris. Din fericire , creatori de aplicatii nu trebuie sa stie despre aceasta pentru ca un
motor de vorbire care suporta o gramatica de dictare prin Java Speech API are o gramatica
de dictare build-in. O aplicatie care are nevoie sa foloseasca o gramatica de dictare trebuie
simplu sa ceara o referenta la ea si se aciveaza cand un utilizator ar putea spune ceva
asemanator cu ce este in gramtica de dictare.

Gramaticiile de dictare pot fi optimizate pentru tipuri de text particulare. Deobicei

un recunoscator dicatare poate fi disponibil cu gramatici de dicatare pentru text propus in
general, sau pentru tipuri variate de rapoarte medicale. In aceste domeni diferite, diferite
cuvinte sunt folosite, si modelele de cuvinte pot sa difere.

5.3. Limitari in recunoasterea de vorbire

Principalele doua restrictii a unei tehnologii de recunoastere a vocii sunt ca nu

trebuie inca transcris intrarea de voce cu forma libera, si ca se fac greseli. In sectiunile de
mai sus sa discutat despre cum motorele de vorbire sunt constranse de gramatici. Acesta
sectiune se discuta despre erorile de recunoastere.

Motorele de vorbire fac greseli. Intelegand de ce motorele de vorbire fac greseli, si

cum sa invatam utilizatori a recunosteri de voce sa minimizeze erorile este foarte
important.

Stabilitatea unui motor de vorbire este de cele mai multe ori definit ca si
“acuratetea recunoasterii”. Acuratetea este deobicei dat de un procentaj si de multe ori de
procentajul corectitudinii recunoasterii cuvintelor. Pentru ca procentajul este masurat
diferit si depinde in mare masura de task si de conditiile de testare nu este in totdeauna
posibil sa comparam motorele de vorbire doar prin procentajul lor de acuratete a
recunoasterii. Un programator trebuie in acelasi timp sa considere cat de serioasa este
eroarea de recunoastere: nerecunoasterea a unei comenzi cum ar fi “delete all files” poate
avea consecinte grave.

Factori majori care influenteaza acuratetea recunosateri:

 Acuratetea recunosaterii este de obicei mare intr-un mediu silentios;

 Microfoanele si placile de sunet de calitate buna poate sa imbunatateasca

acuratetea;

 Utilizatorii care vorbesc clar (dar natural);

 Utilizatorii care au accente sau voci atipice pot duce la o acuratete mai mica;

21
  Aplicatiile cu garmaticii mai simple au o mai buna acuratete;

 Aplicatii cu gramatici mai putin cunfuze au o mai buna acuratete( suntele

cuvintelor similare sunt greu de deosebit ).

Cati timp acesti factori pot fi foarte importanti, impactul lor poate varia intre
motorele de vorbire pentru ca fiecare recunostere a vorbirii optimizeaza performata lor prin
negocierea a unei criteri. De exemplu, sunt motorele de vorbire care sunt facute sa lucreze
stabil in medii cu zgomot ridicat (fabrici sau mine), dar sunt restrictionate la gramatici
foarte simple. Sitemele de dictare au gramatici foarte complexe, dar au microfoane
performante, medii silentioase, utilizatorii vorbesc clar si sisteme de calcul puternice. Sunt
recunoscatoare de voce care isi adapteaza procesele de recunoastere la o voce
particularizata pentru a inbunatatii acuratetea, dar ar fi necesar invatarea utilizatorului.
Deci, utilizatorii si aplicatia developers de multe ori beneficiaza de selesctarea unui
recunoscator de voce potrivnic pentru un task specific si mediu.

Numai cativa din acesti factori pot fi controlati prin programare. Principalul factor
de control al aplicatiei care influenteaza acuratetea recunosaterii este complexitatea
gramaticii. Performanta recunoscatorului de voce poate scadea cu cat gramatica devine din
ce in ce mai complexa, si mai poate scadea cu cat sunt mai multe gramaticii active
simultan. Dar, facand o interfata mai naturala este necesara o gramatica mai complexa si
mai flexibila.

Cele mai multe erori se impart in urmatoarele categorii:

 Rejection : utilizatorul vorbeste, dar motorul de vorbire nu poate intelege ce

spune. In Java Speech API, aplicatiile recepteaza un eveniment care indica
refuzarea a unui rezultat.

 Misrecognition : motorul de vorbire returneaza un rezultat cu cuvinte care sunt

diferite de ceea ce utilizatorul a spus. Aceasta este cea mai intalnita eroare de
recunoastere.

 Misfire: utilizatorul nu vorbeste dar motorul de vorbire returneaza un rezultat.

In Tabelul de mai jos sunt cateva din cele mai intalnite cause a erorilor mentionate.

Erori de recunoastere a vorbirii si posibile cauze

Problema Cauza
Rejection sau Utilizatorul vorbeste unul sau mai multe cuvinte care nu sunt in vocabular.
Misrecognition Propozitia utilizatorului nu se potriveste cu nici o gramatica activa.
Utilizatorul vorbeste inainte ca sistemul sa asculte de la microfon.
Cuvintele din vocabular se pronunta la fel, dar forma scrisa are mai multe
optiuni (ex: ”two”, ”too”).
Utilizatorul face pauze prea mari intre cuvintele din propozitie.
Utilizatorul vorbeste fara fluenta (ex: reincepe propozitia, ”uhmm”, ”ahh”).
Vocea utilizatorului nu este clara.
Utilizatorului are un accent.
Vocea utilizatorului este semnificativ diferita fata de modelele vociilor stocate.
Setarile audio ale sistemului de calcul nu sunt configurate corespunzator.

22
 Microfonul utilizatorului nu este configurat corespunzator.
Misfire Sunet non-vorbire (tusire, rasete).
Sunetul de fond activeaza recunoasterea.
Utilizatorului vorbeste cu alta persona.

5.4. Modul de abordare a aplicatiilor de vorbire

Aplicatiile de vorbire sunt conversatii intre utilizator si computer. Conversatiile

sunt caracterizate prin “turn-taking”, shifturi in initiative, si feedback verbal sau non-verbal
pentru a indica intelegerea.
Un beneficiu major a incorporarii vorbirii in o aplicatie este ca vorbirea este
naturala: oamenii gasesc vorbitul usor.

5.5. Tehnologia de recunoaștere a vocală

Tehnologiile complicate ce sprijină sistemele recunoaștere a vocală variază la fel de

mult ca și vocea în sine. Cu toate acestea, tehnologia de bază RV este, în principiu aceeași
pentru toate aplicațiile majore astăzi. In cel mai simplu sens, vorbirea este introdus în
computer, care este apoi analizat și / sau identificate prin programul Recunoaștere vorbire.
În continuare, procesorul execută o serie de algoritmi pentru a determina ceea ce se crede a
fi fost spus (bazat pe alte tehnologii pentru a fi explorate următor) și răspunde la mesajul
sonor, fie ca o comandă sau de vorbire-text de intrare.
Obiectivul final pentru dezvoltarea tehnologiilor RV este de a crea un sistem prin
care oamenii pot vorbi cu o mașină, în același mod în care s-ar conversa cu o altă ființă
umană. În esență, voi vorbi într-un limbaj natural pentru sistemul informatic umanizat, fără
a ține cont de sintaxă perfectă sau gramatica.

Natural Language Processing (NLP) are două metode de bază pentru

interpretarea de intrare de voce:
1. Keywording: Discursul este înregistrat și computerul generează rezultate
bazate pe cuvinte sau fraze importante. De exemplu, această aplicație
funcționează bine pentru efectuarea sarcinilor pe un sistem de operare: "Open
file", "select all" etc. Keywording este de asemenea utilizat în centrele de apel
(de exemplu, tu spui numele sau extinderea partidului în loc de apăsarea tastelor
de pe numărul pad-ul).

2. Sintactic si Analiza Symantec: Acest proces este mult mai complex decât
Keywording. Pe măsură ce datele sonor intrările difuzoarelor, programul RV
analizează zgomotul și calculează ceea ce se crede (de sistem) pentru a fi ceea
ce intrările de utilizator. Această tehnică necesită un set extins de algoritmi,
reguli și definiții. De exemplu, atunci când cuvântul "doi" se vorbește în sistem,
programul poate prezice că "2" este destinat (în loc de "prea" sau "a").
Computerul poate determina sensul corespunzătoare al acestei omonimă prin
analiza sintaxa, semantica și structura propoziții. Această metodă este aplicată
cel mai bine de procesare de text și de introducere a datelor.

23
 O altă tehnologie importantă asociată cu RV este capacitatea de program pentru a
înțelege vorbirea de fluid față de vorbire nefirești, cu pauze între fiecare cuvânt. Această
capacitate se marchează diferența dintre sistemele de vorbire continuă și sisteme de vorbire
discrete. În timp ce sistemele de vorbire discrete, nu favorizează vorbirea umană naturală,
acestea sunt extrem de precise. Pe de altă parte, după cum era de așteptat, modelul de
vorbire continuu, care este mai aproape de a vorbi naturale unui om are o rată de precizie
mai mică.
O serie de companii s-au dezvoltat și distribuit "motoarele de vorbire." Aceste
"motoare" sunt, în esență, din toate posibile bănci de date cuvinte, fraze, silabe, foneme,
etc., prin care RV programele de căutare pentru a găsi un rezultat rezonabil. Fiecare motor
de vorbire oferit de fiecare dezvoltator diferit funcționează pe un principiu diferit. De
exemplu, motoarele Microsoft Speech Recognition folosi fie un "model de acustic" sau un
"model de limbă dictare." Alte companii au propriile lor caietul de sarcini.

 Aplicații comerciale actuale

Primele aplicații comerciale de recunoaștere a vocii asistate de calculator a venit în

domeniul medical și juridic. Medici si avocati utilizate pentru a dicta note cu privire la un
caz la un serviciu de răspuns și un secretar ar introduce raportul. Pe măsură ce puterea de
hardware și software îmbunătățit, capacitățile de recunoaștere a vocală a calculatorului a
devenit suficient pentru a transcrie aceste dictări. Mai degrabă decât a avea pe cineva
retastați întregul raport, un om a fost pur și simplu trebuia să recitești documentul după ce
calculatorul a construit un proiect de dur. La scurt timp necesitatea unei corectorul umană
va dispărea pe măsură ce tehnologia devine și mai puternic. Necesitatea unei metode
precisă și eficientă de transcriere a furnizat un impuls pentru software-ul de astăzi de
recunoaștere a vocii comerciale.

Există trei jucători importanți în aplicarea comercială a utilizatorului final al

recunoașterii vocală; IBM, Lernaut și Hauspie, și sisteme de Dragon. Aceste trei companii
oferă pachete de software care transformă cuvintele sonore în date digitale, care aplicațiile
informatice pot transforma în date utilizabile. IBM ViaVoice, L & H VoiceXPress lui, și
natural Vorbind sunt produse foarte similare Dragon System, care sunt comparabile în preț,
ușurința în utilizare și caracteristici. Versiunea de lux a acestor programe costă aproximativ
150 $ si are un vocabular de peste 200.000 de cuvinte. Ei vor transforma datele de voce în
date utilizabile pentru aplicatii software cele mai populare și au personalizat interfețe
pentru suita Microsoft de aplicații. Aceste programe sunt programate să recunoască și să
interpreteze corect datele, moneda și numere. Utilizatorul poate controla operațiile
calculatorului (cum ar fi deschiderea și închiderea fișierelor și navigarea pe Web) prin
intermediul comenzilor vocale si macro-uri. Software-ul va citi, de asemenea, textul și
numerele pentru utilizator într-o voce umană. Toate aceste programe de recunoaștere a
vocii necesită o sesiune de antrenament intens (de la 15 minute până la o oră) pentru a afla
modelele specifice ale vocii unui individ. În ceea ce vitezele procesorului computerului s-
au îmbunătățit, astfel încât are precizia și viteza acestor aplicații software de recunoaștere a
vocii.

 Voice XML

Pe 2 martie 1999, douăzeci și discurs de conducere, companiile de Internet și

tehnologia de comunicații a anunțat formarea Forumului EXTENSIVE Limba de marcare
Voice pentru a dezvolta un standard în tehnologia de recunoaștere a vocii. Forumul VXML

24
"își propune să conducă piața de acces la Internet și voce activat de telefon prin
promovarea unei specificații standard pentru VXML, un limbaj de calculator folosit pentru
a folosit pentru a crea conținut și servicii care pot fi accesate prin telefon Web." [1] Odată
ce un standard în comunitatea de calculator este stabilit, va exista o adaptare sporită a
tehnologiei de recunoaștere a vocii de către dezvoltatorii de software terță parte. Chiar și
programe simple vor fi capabili de a încorpora tehnologia de recunoaștere a vocii, fără o
investiție mare în timp de dezvoltare și de calificare.

Natural Language Speech Assistant (NLSA) by Motorola and Unisys

Limbajul natural Speech Assistant (NLSA) este un set de instrumente dezvoltator

pentru dezvoltarea de software care permite clienților să acceseze datele de care au nevoie,
folosind propria lor limbă de zi cu zi (sau limbaj natural), mai degrabă decât restricționarea
răspunsurilor la intrările de la tastatură sau răspunsuri cu un singur cuvânt . Echipează
NLSA dezvoltatorii cu instrumentele necesare pentru scrierea de aplicații de vorbire
activat. Aceasta elimină necesitatea de a învăța detaliile de vorbire de programare de
recunoaștere a programelor. În plus, protejează investițiile de dezvoltare pentru
programatori, în scopul de a migra spre diferite recognizere de vorbire. Mai mult decât
atât, NLSA va spori, sperăm, aplicațiile actuale de recunoaștere vocală la Internet precum
și a dezvolta aplicații noi și mai sofisticate, prin valorificarea tehnologiei de vorbire
disponibile astăzi.

5.6. Limitări și potențialele ale recunoașterea a vocală

In trecut, constrângerea majoră pentru dezvoltarea perfectă sistem de recunoaștere a

vocală a fost puterea de procesare limitată a microprocesorului computerului. Odată ce
acest obstacol a fost depășită cu dezvoltarea microcip, adevăratele limitări ale tehnologiei
RV au devenit vizibile: abilitatea de a dezvolta logaritmi suficient de sofisticate pentru
aproape înțeleg perfect, interpreta și de a răspunde la comenzi vocale. Răspunsurile la
această problemă încă ocolească instituțiile de cercetare cele mai de succes. De exemplu,
unele sisteme pot înțelege de intrare de la o varietate de utilizatori, dar cu o bancă de
vocabular limitat. Pe de altă parte, alte sisteme recunosc peste 200.000 de cuvinte, ci numai
dintr-un număr foarte limitat ale utilizatori. Acolo nu exista un program care poate înțelege
vocabularele extinse din diferite difuzoare.

Programele comerciale disponibile astăzi necesită o "sesiune de formare", cu

fiecare utilizator, care poate dura mai mult de o oră. În acest timp, nu numai că utilizatorul
trebuie să învețe cum să vorbească la mașină, dar, de asemenea, computerul trebuie să se
obișnuiască cu vocea utilizatorului. Acest lucru poate fi o constrângere asupra
productivității din cauza orelor pierdute, dar acest lucru prezintă, de asemenea, o altă
problemă. Această nouă problemă constă în faptul că sistemele vor trebui să învețe să
înțeleagă mai mulți utilizatori într-un timp scurt (sau instantaneu). De exemplu, atunci când
vom merge la McDonald drive-thru ferestre si comanda un burger cu ketchup, ne vom
aștepta ca sistemul informatic să recunoască intrarea noastră verbală imediat. Nu ar fi fast-
food dacă am avut de a instrui programul Recunoașterea vocală pentru o jumătate de oră.

O altă limitare a utilizării instrumentelor RV actuale este faptul că există variabile

aproape nelimitate care cuprind zgomotul vocii. De exemplu, atunci când răspunde la un
apel telefonic la fel cum ne trezim din somn, vocea noastră sună altfel decât după ce ne-am
aplaudat toată noaptea, la un meci de baschet. In plus, zgomotul de fond prezintă factori de

25
limitare cu privire la eficacitatea tehnologiei RV. Este relativ ușor pentru computer pentru
a filtra zgomotul de fond, atunci când vorbim într-un birou liniștit, dar dacă ar fi să spunem
aceeași frază pe o stradă aglomerată RV sisteme vor fi confundate.

Chiar dacă sistemele RV actuale au limitări, s-au înregistrat progrese semnificative

în dezvoltarea unui program de RV perfect fiabil. Odată ce aceste obstacole sunt depășite
frustrant, potențialul pentru tehnologia RV este enormă. Metodele tradiționale de date
introducerecod într-un computer, cum ar fi un mouse și tastatură vor deveni caduce.
Produsele actuale de RV comerciale nu au capacitatea de a fi utilizate pe o bază pe
scară largă. În funcție de aplicarea acestei tehnologii, ea poate sau poate să nu fie un
moment oportun să se adopte aceste sisteme RV. De exemplu, tehnologia RV pot fi puse în
aplicare în mod eficient pentru a reduce costurile în centrele de apel. Cu toate acestea,
tehnologia RV nu este, probabil, la un nivel adecvat pentru a crește productivitatea
sarcinilor de birou. Cu rata de aplicațiile software RV sunt în curs de dezvoltare, acesta va
fi în curând benefic să se folosească tehnologia de recunoaștere a vocală în funcții de zi cu
zi.

5.7. Viitorul ale Recunoașterea Vocală

Deja se poate folosi K.I.T.T. de la faimosul serial din anul 1980 "Knight Rider" in
ziua de azi. Fie că vrem să luam cel mai rapid traseu la birou sau întrebam la care persoana
care este lângă noi, tehnologiile similare cu cele demonstrate în această serie de televiziune
science-fiction va fi în curând caracteristici standard în automobile. De fapt, Clarion a
dezvoltat deja o primă generație AutoPC care poate răspunde la comenzi vocale. Acest
produs utilizează sistemul de operare Windows CE Microsoft pentru a efectua "mâini
libere" funcții, cum ar fi voce activat apelarea prin intermediul unui telefon mobil, asistență
cu instrucțiuni de ghidare și informații suplimentare despre vreme, știri și stocuri.

Pe măsură ce tehnologia Recunoaștere vorbire îmbunătățește în ceea ce privește

acuratețea, vocabular, precum și capacitatea sa de a înțelege limbajul natural, vom vedea
conceptul ale mașini interactive în fiecare arena. De la unelte mecanice linie de asamblare
pentru cuptoare cu microunde inteligente "în scris" un cec, vom avea puterea de a utiliza
vocea noastră pentru a instrui dispozitivele electronice pe care le întâlnim în fiecare zi.

Progresul tehnologiilor de recunoaștere vocală, în viitorul apropiat, poate fi

împiedicată de lipsa unui cod standard eficient și legitim. Eforturile sunt realizate de către
AT & T, Lucent, Motorola și alte șaptesprezece instituții de conducere pentru a dezvolta
standardul Voice (eXtensible Markup Language VXML). Cu toate acestea, Microsoft și
Unisys sunt, de asemenea, colaborează pentru a populariza Standard Application
Programming Interface (SAPI), care nu este compatibil cu standardul VXML. Tehnologii
de vorbire și de recunoaștere a vocii, probabil, nu va înflori până când aceste standarde
sunt aprobate de către World Wide Web Consortium (W3), la fel ca și World Wide Web
nu a crescut, până au fost adoptate standardele Hypertext Markup Language (HTML).

Este evident că oamenii încearcă să creeze un mediu de calcul în care computerul

învață de către utilizator în loc de unul în cazul în care utilizatorul trebuie să învețe cum să
utilizeze calculatorul. Tehnologia de recunoaștere a vocală este următorul pas evident într-
o încercare de a se integra într-un mod de calcul "natural" al vieții. Acest lucru mijloc
eficient de comunicare, chiar și atunci când perfectat, se va prezenta în continuare restricții
privind modul în care oamenii se pot exprima. Gâtuire viitorului va fi constrângerea fizică

26
de a nu putea să vorbească toate gândurile într-o manieră coerentă și rațională. In schimb,
infricosator deoarece poate fi, computerele pot avea sisteme care pot primi și interpreta
datele neurologice.
O aplicatie efectiva este una care simuleaza aspecte ale conversației om-om.

5.8. Aplicații ale Recunoașterii vocale:

 Sisteme auto.

În mod tipic o intrare de comandă manuală, de exemplu, prin intermediul

unui control al degetului pe volanului, permite sistemului de recunoaștere a vorbirii
și acest lucru este semnalat șoferului printr-un prompt audio. Ca urmare a solicitării
audio, sistemul are o "fereastră de ascultare", în timpul căreia se poate accepta o
intrare de vorbire de recunoaștere.

Comenzile vocale simple pot fi folosite pentru a iniția apeluri, a selecta

posturi de radio sau de a reda muzică de pe un smartphone compatibil, MP3 player
sau o unitate flash încărcat cu muzică. capabilități de recunoaștere a vocii variază
între marca mașinii și modelul. Unele dintre cele mai recente modele de automobile
oferă o recunoaștere a vorbirii limbajului natural în locul unui set fix de comenzi,
care permite șoferului să folosească propoziții complete și fraze comune. Cu astfel
de sisteme, nu este nevoie ca utilizatorul să memoreze un set de cuvinte de
comandă fixe.

 Sănătate; Documentație medicală

În sectorul sănătății, recunoașterea vorbirii poate fi implementată în front-end sau

back-end al procesului de documentare medicală. Recunoașterea vorbirii front-end este în
cazul în care furnizorul dictează într-un motor de recunoaștere a vorbirii, sunt afișate
cuvintele recunoscute ca acestea sunt vorbite, iar dictatorul este responsabil pentru editarea
și semnarea pe document. Back-end sau de recunoaștere a vorbirii amânată este în cazul în
care furnizorul dictează într-un sistem de dictare digitale, vocea este dirijata printr-o
mașină de recunoaștere vocală și proiectul de document recunoscut este dirijat, împreună
cu fișierul vocal original la editor, în cazul în care proiectul este editat și un raport finalizat.
Recunoașterea vorbirii este utilizat pe scară largă decalată în industrie prezenta.

Una dintre problemele majore legate de utilizarea recunoașterii vorbirii în domeniul

asistenței medicale este faptul că American Recovery and Reinvestment Act of 2009
(ARRA) prevede beneficii financiare substanțiale pentru medicii care folosesc un EMR
conform standardelor " Meaningful Use". Aceste standarde cer ca o cantitate substanțială
de date să fie menținută de EMR (acum mai denumit în mod obișnuit ca un dosar
electronic de sănătate sau Electronic Health Record - EHR). Utilizarea de recunoaștere a
vorbirii este mai natural potrivit pentru generarea de text narativ, ca parte a unei radiologie
/ interpretare patologie, nota un progres sau un sumar de descărcare de gestiune: câștigurile
ergonomice de utilizare a recunoașterii vorbirii pentru a introduce date discrete structurate
(de exemplu, valori numerice sau coduri dintr-o listă sau un vocabular controlat) sunt
relativ minime pentru persoanele care sunt deficiențe de vedere și care poate opera o
tastatură și mouse-ul.

27
 O problemă mai semnificativ este faptul că majoritatea EHRs nu au fost adaptate în
mod expres pentru a beneficia de capacitățile de recunoaștere vocală. O mare parte a
interacțiunii clinicianului cu EHR implică navigarea prin interfața cu utilizatorul utilizând
meniuri, și fila / clicurile pe butonul, și este puternic dependentă de tastatură și mouse-ul:
navigare pe bază de voce oferă beneficii ergonomice modeste. Prin contrast, multe sisteme
extrem de personalizate pentru radiologie sau patologie dictarea punerea în aplicare de
voce "macro-uri", în cazul în care utilizarea anumitor fraze - de exemplu, "raport normal",
se va completa automat într-un număr mare de valori implicite și / sau de a genera
șabloane, care va variază în funcție de tipul de examen - de exemplu, o radiografie toracică
vs o serie de contrast gastro-intestinale pentru un sistem de radiologie.

Ca o alternativă la această navigație de mână, în cascadă utilizarea de recunoaștere

a vorbirii și de extragere a informației a fost studiată, ca o modalitate de a completa un
formular de transfer pentru verificare clinică și să semneze-off. Rezultatele sunt
încurajatoare, iar hârtia se deschide, de asemenea, date, împreună cu obiectivele de
referință de performanță aferente și unele software-ul de procesare, pentru comunitatea de
cercetare și dezvoltare pentru studierea documentației clinice și de procesare a limbajului.

 Utilizare terapêutica

Utilizarea prelungită a software-ului de recunoaștere a vorbirii în combinație cu

procesoare de text a demonstrat beneficii pentru un termen scurt de memorie
restrengthening in creierul pacientilor AVM care au fost tratați cu rezecție. cercetări
suplimentare trebuie să fie efectuate pentru a determina beneficiile cognitive pentru
persoanele ale caror AVMS au fost tratate folosind tehnici radiologice.

 Armata: Avioane de luptă de înaltă performanță

Eforturi substanțiale au fost dedicate în ultimul deceniu, pentru testare și evaluare a

recunoașterii vorbirii în avioane de luptă. De notat este special programul SUA în
recunoaștere a vorbirii pentru Advanced Fighter Technology Integration (AFTI) /
aeronavei F-16 (F-16 VISTA), precum și un program în Franța, instalarea de sisteme de
recunoaștere vocală pe aeronave Mirage, precum si programe in Marea Britanie care se
ocupă cu o varietate de platforme de aeronave. În aceste programe, recognizere de vorbire
au fost operate cu succes în avioane de luptă, cu aplicații, inclusiv: setarea frecvențelor
radio, comandarea unui sistem de pilot automat, stabilirea coordonatelor de direcție puncte
și parametri de eliberare a armelor, precum și controlul zborului de afișare.

Lucrand cu piloți suedezi care zboară în JAS-39 Gripen carlingă, Englund (2004) a
constatat recunoașterea sa deteriorat odată cu creșterea G-sarcini. De asemenea, sa
concluzionat că adaptarea îmbunătățit foarte mult rezultatele în toate cazurile și modele de
introducere pentru respirație a fost demonstrat de a imbunatati in mod semnificativ
scorurile de recunoaștere. Contrar a ceea ce s-ar putea fi de așteptat, s-au găsit nici un efect
de rupt în limba engleză a difuzoarelor. Era evident că vorbirea spontană a cauzat
probleme pentru recognizer, cum ar fi de așteptat. Un vocabular restrâns, și mai presus de
toate, o sintaxă adecvată, astfel, ar putea fi de așteptat să îmbunătățească în mod substanțial
acuratețea recunoașterii.

Eurofighter Typhoon prezent au în funcțiune RAF din Marea Britanie care

folosește un sistem dependent de difuzor, adică necesită fiecare pilot pentru a crea un

28
șablon. Sistemul nu este utilizat pentru sarcini critice critice sau arme de siguranță, cum ar
fi eliberarea armă sau coborârea șasiului, dar este folosit pentru o gamă largă de alte funcții
din cabină. Comenzile vocale sunt confirmate prin feedback vizual și / sau fonetica.
Sistemul este văzută ca element de design major în reducerea volumului de muncă pilot, și
chiar și permite pilotului să atribuie ținte pentru el însuși, cu două comenzi vocale simple,
sau la oricare dintre wingmen sale cu doar cinci comenzi.

Sistemele de difuzoare independente sunt, de asemenea, dezvoltate și sunt în

testarea pentru F35 Lightning II (JSF) și M-346 master-plumb în trainer luptător Alenia
Aermacchi. Aceste sisteme au produs o precizie cuvânt în exces de 98%.

 Elicoptere

Problemele cea mare de realizare precizii de recunoaștere în condiții de stres și de

zgomot puternic se referă la mediul de elicopter precum și pentru mediu cu jet de luptator.
Problema zgomotului acustic este de fapt mai severă în mediul de elicopter, nu numai din
cauza nivelului ridicat de zgomot, dar și pentru că pilotul elicopterului, în general, nu purta
un facemask, ceea ce ar reduce zgomotul acustic în microfon. Programele de evaluare și
testare substanțiale au fost efectuate în ultimii zece ani în aplicații de sisteme de
recunoaștere a vorbirii în elicoptere, în special de către US Army Avionics Cercetare și
dezvoltare (AVRADA) și de către Royal Aerospace Establishment (RAE) in Marea
Britanie. Lucrări în Franța a inclus recunoașterea vorbirii în elicopter Puma. De asemenea,
a existat multă muncă utilă în Canada. Rezultatele au fost încurajatoare, iar aplicațiile de
voce au inclus: controlul radio de comunicare, stabilirea sistemelor de navigație, precum și
controlul unui sistem automat de transfer țintă.

Ca și în aplicațiile de luptă, problema primordială pentru voce în elicoptere este

impactul asupra eficacității pilot. Rezultatele încurajatoare sunt raportate pentru testele
AVRADA, cu toate că acestea reprezintă doar o demonstrație de fezabilitate într-un mediu
de testare. Rămân multe de făcut, atât în recunoașterea vorbirii și în tehnologia generală de
vorbire, în scopul de a realiza în mod constant îmbunătățiri de performanță în setările
operaționale.

 Instruirea controlorilor de trafic aerian

Formare profesională pentru controlorii de trafic aerian (ATC) reprezintă o

aplicație excelentă pentru sistemele de recunoaștere a vorbirii. Multe sisteme de formare
ATC necesită în prezent o persoană să acționeze ca un "pseudo-pilot", angajarea într-un
dialog vocal cu controller stagiar, care simulează dialogul pe care controlorul ar trebui să
efectueze cu piloți într-o situație reală ATC. Tehnici de recunoaștere vocală și sinteză oferă
posibilitatea de a elimina necesitatea unei persoane de a acționa ca pseudo-pilot, reducând
astfel personalul de formare și susținere. În teorie, sarcinile de controlor de aer sunt de
asemenea caracterizate prin vorbire foarte structurat ca producția primară a controlerului,
reducând astfel dificultatea sarcinii de recunoaștere a vorbirii ar trebui să fie posibilă. În
practică, acest lucru este rareori cazul. Documentul FAA 7110.65 detaliază expresiile care
ar trebui să fie utilizate de către controlorii de trafic aerian. În timp ce acest document
oferă mai puțin de 150 de exemple de astfel de fraze, numărul de fraze susținute de către
unul dintre furnizorii de simulare sistemele de recunoaștere a vorbirii este mai mare de
500.000.

29
 USAF, USMC, US Army, US Navy, și FAA precum și o serie de organizații
internaționale de formare ATC, cum ar fi Australian Royal Air Force și autoritățile aviației
civile din Italia, Brazilia și Canada sunt în prezent, folosind simulatoare ATC cu
recunoaștere a vorbirii de la un număr de furnizori diferiți.

 Telefonie si alte domenii

ASR în domeniul telefoniei este acum un lucru obișnuit și în domeniul jocurilor pe

calculator și simularea devine din ce mai răspândită. În ciuda nivelului ridicat de integrare
cu procesare de text în calcul personal general. Cu toate acestea, ASR în domeniul
producției de documente care nu a văzut creșterile în timpul utilizării.
Îmbunătățirea vitezei procesoarelor mobile a făcut fezabilă vorbire-a permis
Symbian și Windows Mobile smartphone-uri. Discursul este folosit mai ales ca o parte
dintr-o interfață de utilizator, pentru a crea comenzi predefinite sau personalizate de
vorbire. Importanți furnizori de software din acest domeniu sunt: Google, Microsoft
Corporation (Microsoft Voice Command), Syphon digital (Sonic Extractor), LumenVox,
Nuance Communications (Nuance Voice Control), VoiceBox Tehnologie, Speech
Technology Center, Vito Technologies (VITO Voice2Go), Speereo Software-ul (Speereo
Voice Translator), Verbyx VRX și SVOX.

 Utilizarea în educație și viața de zi cu zi

Pentru învățarea limbilor străine, de recunoaștere a vorbirii poate fi utilă pentru

învățarea unei a doua limbi. Ea poate învăța pronunția corectă, în plus față de a ajuta o
persoană să dezvolte fluența cu abilitățile lor de vorbire.
Studenții care sunt orbi (a se vedea orbire și educație) sau au vizibilitate foarte
scăzută pot beneficia de pe urma folosind tehnologia pentru a transmite cuvinte și apoi auzi
computerul le recita, precum și utilizarea unui calculator prin comandarea cu vocea lor, în
loc să se uite la ecranul și tastatura.

Studenții care sunt cu handicap fizic sau suferă de un prejudiciu Efort / alte leziuni
la nivelul extremitatilor superioare pot fi eliberate din a fi nevoie să vă faceți griji cu
privire la scrierii de mână, dactilografiere, sau care lucrează cu scrib la misiuni școlare prin
utilizarea unor programe de vorbire în text. Ele pot utiliza, de asemenea, tehnologia de
recunoaștere a vorbirii pentru a se bucura în mod liber căutarea pe Internet sau utilizând un
computer la domiciliu, fără a fi nevoie să opereze fizic un mouse și tastatură.

Recunoașterea vorbirii poate permite elevilor cu dizabilități de învățare să devină

scriitori mai buni. Prin a spune cuvinte cu voce tare, ei pot crește fluiditatea scrierii lor și
să fie atenuate de preocupările legate de ortografie, punctuație, precum și a altor mecanici
de scriere.
Utilizarea funcției de recunoaștere a vocii, a coroborat cu un înregistrator digital
audio, un calculator personal și Microsoft Word sa dovedit a fi pozitiv pentru restabilirea
capacității pe termen scurt-memorie deteriorat, accident vascular cerebral si indivizii
craniotomy.

30
  Persoane cu dizabilități

Persoanele cu dizabilități pot beneficia de programe de recunoaștere vocală. Pentru

persoanele care sunt surzi sau tare de auz, software-ul de recunoaștere a vorbirii este
utilizat pentru a genera automat un tip închis de conversații, cum ar subtitrări ca discuții în
săli de conferințe, prelegeri clasă și / sau servicii religioase.
Recunoașterea vorbirii este, de asemenea, foarte util pentru persoanele care au
dificultăți în utilizarea mâinile lor, variind de la leziuni ușoare repetitive de stres pentru a
implica handicap, care împiedică utilizarea dispozitivelor de intrare de calculator
convenționale. De fapt, oamenii care au folosit tastatura o mulțime și dezvoltat RSI a
devenit o piață de urgență timpurie pentru recunoașterea vorbirii.

Recunoașterea vorbirii este utilizat în telefonia surd, cum ar fi mesagerie vocală la

text, servicii de retransmisie și telefonice din titlu. Persoanele cu dizabilități de învățare
care au probleme cu comunicarea gândurilor la hârtie (în esență, ei se gândesc la o idee,
dar este incorect prelucrata determinându-l să se încheie în mod diferit pe suport de hârtie),
pot beneficia, eventual, de software-ul, dar tehnologia nu este bug dovada. De asemenea,
toată ideea de a vorbi în text poate fi greu pentru persoane cu dizabilități intelectuale,
datorită faptului că este rar ca cineva încearcă să învețe tehnologia pentru a preda persoana
cu handicapul.

Acest tip de tehnologie poate ajuta pe cei cu dislexie, dar alte dizabilități sunt încă
în discuție. Eficacitatea produsului este problema care împiedică a fi eficient. Cu toate că
un copil poate fi capabil să spună un cuvânt, în funcție de cât de clar au spun ca tehnologia
ar putea crede că spun un alt cuvânt și introduceți greșit. Oferindu-le mai mult de lucru
pentru a stabili, făcându-le să trebuie să ia mai mult timp cu fixare cuvântul greșit.

Alte aplicații:

 Industria aerospațială (de exemplu, explorarea spațială, nave spațiale, etc.);

 subtitrării automată cu recunoaștere a vorbirii;
 traducere automată;
 raportare instanță (Realtime vorbire de scriere);
 calcul hands-free: Recunoașterea vorbirii interfața cu utilizatorul calculatorului;
 acasă de automatizare;
 răspuns vocal interactiv;
 telefonia mobilă, inclusiv e-mail mobil;
 interacțiune multimodală;
 Evaluarea în aplicații de învățare pronunție limbă asistată de calculator;
 robotica;
 Vorbire-text reporter (transcriere de vorbire în text, video de subtitrare, raportarea
Curții);
 Sisteme de navigatie inteligente (de exemplu, vehicul sisteme de navigație);
 Transcriere (digital de vorbire-text);
 jocuri video, cu EndWar Tom Clancy și Lifeline ca exemple de lucru.

31
 6. Formalismul recunoașterii automate limbii (vorbirii)
Procesul recunoaşterii automate a vorbirii (RAV) vizează transformarea unui
semnal audio ce conţine vorbire într-o succesiune de cuvinte. Recunoaşterea automată a
vorbirii este unul dintre primele domenii în care tehnicile de modelare statistică (în care
modelele se creează pe baza unor catintăţi mari de date) s-au impus ca şi standard.
Platforma statistică pentru recunoaşterea automată a vorbirii a fost creată şi dezvoltată de-a
lungul a două decenii de către Baker [Baker, 1975], o echipă de cercetători de la compania
IBM [Jelinek, 1976; Bahl, 1983] şi o echipă de cercetare-dezvoltare de la compania AT&T
[Levinson, 1983; Rabiner, 1989]. Procesul de transformare a vorbirii în text poate fi
formulat într-o manieră statistică astfel: Care este cea mai probabilă secvenţă de cuvinte
W* în limba L, dat fiind mesajul vorbit X? Reprezentarea formală utilizează funcţia
argmax, care selectează argumentul ce maximizează probabilitatea secvenţei de cuvinte:

1.1

Dezvoltarea din Ecuaţia 1.1 are la bază regula Bayes şi s-a făcut ţinând cont de
faptul că probabilitatea mesajului vorbit p(X) este independentă de secvenţa de cuvinte W.
Ultimul rezultat evidenţiază doi factori care pot fi estimaţi direct. Problema iniţială (găsirea
secvenţei de cuvinte pe baza mesajului vorbit) a fost împărţită în două sub-probleme mai
simple: a) estimarea probabilităţii apriori a secvenţei de cuvinte p(W) şi b) estimarea
probabilităţii mesajului vorbit dată fiind secvenţa de cuvinte pronunţată p(X|W). Primul
factor poate fi estimat utilizând exclusiv un model de limbă, iar cel de-al doilea poate fi
estimat cu ajutorul unui model acustic.
Cele două modele pot fi construite independent aşa cum se va vedea în secţiunea
următoare, dar vor fi folosite împreună pentru a decoda un mesaj vorbit, aşa cum arată
Ecuaţia 1.1.

7. Arhitectura unui sistem de recunoaştere automată a

vorbirii
Arhitectura generală a unui sistem de recunoaştere automată a vorbirii (RAV) este
prezentată în Figura 1. Din figură reies două lucruri esenţiale în ceea ce priveşte procesul
de recunoaştere a vorbirii: a) recunoaşterea se face utilizând o serie de parametri vocali
extraşi din semnalul vocal (nu direct, utilizând mesajul vorbit) şi b) recunoaşterea se face
pe baza unor modele (acustic, fonetic şi lingvistic) dezvoltate în prealabil.

32
 Figura 1. Arhitectura generală a unui sistem de recunoaştere a vorbirii

Modelul acustic are rolul de a estima probabilitatea unui mesaj vorbit, dată fiind o
succesiune de cuvinte. În sistemele de RVC actuale modelul acustic nu foloseşte cuvinte ca
unităţi acustice de bază pentru că: a) fiecare sarcină de RAV are un vocabular de cuvinte
diferit pentru care nu există modele deja antrenate şi nici date de antrenare disponibile şi b)
numărul de cuvinte diferite dintr-o limbă este prea mare. În locul cuvintelor, se utilizează
unităţi acustice de bază sub-lexicale, de exemplu foneme, sau, mai recent, chiar unităţi sub-
fonemice numite senone. Prin urmare, modelul acustic este format dintr-un set de modele
pentru foneme (sau senone) care se conectează în timpul procesului de decodare pentru a
forma modele pentru cuvinte şi apoi modele pentru succesiuni de cuvinte. Acestea sunt
utilizate în final pentru a estima probabilitatea ca mesajul rostit de vorbitor să fie format
dintr-o succesiune sau alta de cuvinte. Experienţa a arătat că această abordare generativă
pentru modelele acustice poate fi foarte bine implementată utilizând modele Markov
ascunse (hidden Markov models - HMM). Pentru mai multe informaţii despre modul cum
funcţionează modelele acustice consultaţi platforma „Principiile de bază ale modelării
acustice”.

Modelul de limbă este utilizat în timpul decodării pentru a estima probabilităţile

tuturor secvenţelor de cuvinte din spaţiul de căutare. În general, rolul unui model de limbă
este de a estima probabilitatea ca o secvenţă de cuvinte W = w1, w2, …, wn, să fie o
propoziţie validă a limbii. Probabilitatea acestor secvenţe de cuvinte ajută foarte mult
modelul acustic în procesul de decizie. De exemplu, aceste două fraze: ceapa roşie este
sănătoasă şi ce apar oşti ie este sănătoasă sunt similare din punct de vedere acustic, însă
cea de-a doua nu are niciun sens. Rolul modelului de limbă este acela de a asigna o
probabilitate mult mai mare primei secvenţe de cuvinte şi, prin urmare, de a ajuta sistemul
de RAV să decidă în favoarea acesteia.

Modelul fonetic are rolul de a conecta modelul acustic (care estimează

probabilităţile acustice ale fonemelor) cu modelul de limbă (care estimează probabilităţile
secvenţelor de cuvinte). De cele mai multe ori modelul fonetic este un dicţionar de
pronunţie care asociază fiecărui cuvânt din vocabular una sau mai multe secvenţe de
foneme adecvate, reprezentând modul în care se poate pronunţa respectivul cuvânt.

Figura 1. ilustrează, de asemenea, procesele implicate în dezvoltarea unui sistem de

RAV, dar şi resursele necesare creării modelelor acustice, lingvistice şi fonetice. Modelul

33
acustic se construieşte strict pe baza unui set de clipuri audio înregistrate asociate cu
transcrierea textuală a mesajelor vorbite şi a unui dicţionar fonetic ce cuprinde toate
cuvintele din respectiva transcriere textuală. În cazul sistemelor de RVC cu vocabular
extins se folosesc modele de limbă statistice, care se construiesc utilizând corpusuri de text
de dimensiuni cât mai mari şi cât mai adaptate domeniului din care fac parte mesajele
vorbite ce trebuie decodate. În sistemele de RVC cu vocabular redus se folosesc
preponderent modele de limbă de tip gramatică cu reguli, iar pentru construcţia acestora nu
este nevoie de resurse textuale.

34
 8. Dezvoltarea aplicației
Application Programming interface – API (Interfața de programare a aplicației)

În programarea calculatoarelor, o interfață de programare a aplicațiilor (API) este

un set de definiții de rutină, protocoale și instrumente pentru construirea de software și
aplicații.
Un API exprimă o componentă software în ceea ce privește operațiunile, intrările,
ieșirile, și tipurile sale subiacente, definind funcționalități care sunt independente de
implementări lor respective, ceea ce permite definiții și implementări să varieze, fără a
compromite interfața. Un API face sa fie mai ușoara dezvoltarea unui program prin
furnizarea tuturor blocurilor de construcție, care sunt apoi puse împreună de către
programator.
API poate fi pentru un sistem bazat pe web, sistem de operare, sau un sistem de
baze de date, și oferă facilități pentru a dezvolta aplicații pentru sistemul respectiv folosind
un anumit limbaj de programare. Ca un exemplu, un programator care dezvoltă aplicații
pentru Android poate utiliza un API Android pentru a interacționa cu hardware-ul, cum ar
fi camera frontală a unui dispozitiv bazat pe Android.

În plus față de accesarea bazelor de date sau hardware de calculator cum ar fi

unitățile de hard-disc sau plăci de video, un API poate ușura activitatea componentelor
GUI de programare. De exemplu, un API poate facilita integrarea de noi caracteristici în
aplicații existente (așa-numita "plug-in API"). Un API poate ajuta, de asemenea, aplicații
de altfel distincte cu schimbul de date, care pot contribui la integrarea și consolidarea
funcționalitățile aplicațiilor.
API-uri de multe ori vin sub forma unei biblioteci, care include specificații pentru
rutine, structuri de date, clase de obiecte și variabile. În alte cazuri, în special servicii
SOAP și REST, un API este pur și simplu o specificație a apelurilor de la distanță expuse
la consumatori API.
O specificație API poate lua mai multe forme, inclusiv un standard internațional,
cum ar fi POSIX, documentația de furnizor, cum ar fi API Microsoft Windows sau
bibliotecile unui limbaj de programare, de exemplu Template Library Standard în C ++ sau
API-uri Java.

Un API diferă de la o aplicație de interfață binară (ABI), prin aceea că un API este
pe bază de cod sursă în timp ce un ABI este o interfață binar. De exemplu, POSIX este un
API, în timp ce Standard Baza de Linux oferă un ABI.
API-uri sunt una dintre cele mai comune modalități de companii de tehnologie
integrează unele cu altele. Cele care furnizează și să utilizeze API-uri sunt considerate ca
fiind membri ai unui ecosistem de afaceri.

8.1. API în limbaje de procedură

În cele mai multe limbaje de procedură, un API specifică un set de funcții sau
rutine care realizează o anumită sarcină, sau li se permite să interacționeze cu o
componentă software specific. Această specificație este prezentată într-un format care
poate fi citit uman în cărți de hârtie sau în format electronic, cum ar fi cărți electronice sau
ca pagini de om. De exemplu, API matematica pe sistemele Unix este o specificație cu
privire la modul de utilizare a funcțiilor matematice incluse în biblioteca matematică.

35
Printre aceste funcții există o funcție numită sqrt (), care poate fi folosit pentru a calcula
rădăcina pătrată a unui număr dat.
Comanda Unix man 3 sqrt prezintă semnătura funcției sqrt în forma:
SYNOPSIS
#include <math.h>
double sqrt (double X);
float sqrtf (float X);
DESCRIPTION
sqrt calculează rădăcina pătrată pozitivă a argumentului. ...
RETURNS
În caz de succes, rădăcina pătrată este returnata. În cazul în care X este real și
pozitiv…

Această descriere înseamnă că funcția sqrt () întoarce rădăcina pătrată a unui număr
în virgulă flotantă pozitiv (de precizie simplă sau dublă), ca un alt număr în virgulă mobilă.
Pagina principală, de asemenea, prevede că programul apelant trebuie să includă fișierul
antet math.h pentru a fi capabil de a face referire la funcțiile prezente în biblioteca
matematică.
In acest caz API, poate fi interpretată ca și colecția de fișiere include utilizate de un
program, scrise în limbajul C, pentru a face referire această funcție de bibliotecă și uman
descriere care poate fi citit furnizată de către paginile man.
În mod similar, alte limbi au biblioteci procedurale; de exemplu, Perl are API-uri
dedicate pentru aceeași sarcină matematică cu documentație încorporată disponibilă, care
poate fi accesat folosind utilitarul perldoc:

$ perldoc -f sqrt
sqrt EXPR
sqrt #Return the square root of EXPR. If EXPR is omitted, returns
#square root of $_. Only works on non-negative operands, unless
#you've loaded the standard Math::Complex module.

8.2. API în limbaje orientate pe obiect

În forma sa cea mai simplă, un API obiect este o descriere a modului în care
obiectele funcționează într-un anumit limbaj orientat pe obiect - de obicei, este exprimat ca
un set de clase cu o listă asociată de metode de clasă.

De exemplu, în Java, dacă scanerul de clasă este de a fi utilizat (o clasă care citește
de intrare de la utilizator la programe bazate pe text), este necesar să se importe biblioteca
java.util.Scanner. Apoi obiecte de tip scaner pot fi folosite prin invocarea unor metode din
clasa ":

import java.util.Scanner;
public class Test {
public static void main(String[ ] args) {
System.out.println("Enter your name:");
Scanner inputScanner = new Scanner(System.in);
String name = inputScanner.nextLine();
System.out.println("Your name is " + name + ".");
inputScanner.close();

36
 }
}

În exemplul de mai sus, metodele nextLine () și close () fac parte din API pentru
Scanner class, și, prin urmare, sunt descrise în documentația pentru API, de ex .:

public String nextLine()

Advances this scanner past the current line and returns the skipped input...
Returns:
the line that was skipped
Throws:
NoSuchElementException - if no line found
IllegalStateException - if this scanner is closed

Mai mult, în general, în limbaje orientate obiect, un API includ de obicei, o

descriere a unui set de definiții de clasă, cu un set de comportamente asociate cu aceste
clase. Acest concept abstract este asociat cu funcționalitatea reală expusă, sau puse la
dispoziție, prin clasele care sunt puse în aplicare în ceea ce privește metodele de clasă (sau,
mai general, de către toate componentele sale publice, prin urmare, toate metodele publice,
dar, de asemenea, posibil, inclusiv orice entitate internă făcută publică cum ar fi : câmpuri,
constante, obiecte imbricate, enums, etc.).
API în acest caz, poate fi concepută ca totalitatea tuturor metodelor expuse în mod
public de către clasele (de obicei, numită interfața de clasă). Acest lucru înseamnă că API
prevede metodele prin care una interacționează / manipulează obiectele derivate din
definițiile de clasă.

Mai general, se poate vedea API ca și colectarea tuturor tipurilor de obiecte se pot
deriva din definițiile de clasă și comportamentele asociate lor posibile. Din nou: utilizarea
lor este mediată prin metodele publice, dar în această interpretare, metodele sunt văzute ca
un detaliu tehnic modului în care este implementat comportamentul.
De exemplu: o clasă care reprezintă o stivă poate expune pur și simplu, în mod
public două metode de a împinge () (pentru a adăuga un nou element în stivă) și pop ()
(pentru a extrage ultimul element, ideal plasat pe partea de sus a stivei).
În acest caz, API-ul poate fi interpretat ca pop două metode () și împinge (), sau,
mai general, ca și ideea că se poate utiliza un element de tip stivă care implementează
comportamentul unui stivă: un morman expune partea superioară a acesteia pentru a
adăuga / elimina elemente. Cea de a doua interpretare pare mai adecvată în spiritul
orientării obiectului.

Acest concept poate fi realizată la punctul în care o interfață de clasă într-un API nu
are metode deloc, ci numai comportamente asociate cu ea. De exemplu, API-urile de limbă
Lisp Java și includ interfața numită Serializable, care este o interfață marker care necesită
fiecare clasă de punere în aplicare să se comporte într-un mod serializate. Acest lucru nu
necesită punerea în aplicare a unei metode publice, ci necesită mai degrabă orice clasă care
implementează această interfață să se bazeze pe o reprezentare care poate fi salvat
(serializate) în orice moment.
În mod similar, comportamentul unui obiect într-un mediu concurent (multi-thread)
nu este determinată în mod necesar prin metode specifice, care fac parte din interfața pusă
în aplicare, dar încă mai face parte API pentru această clasă de obiecte, și ar trebui să fie
descrise în documentație.

37
 În acest sens, în limbaje orientate obiect, API definește un set de comportamente
obiect, eventual mediate de un set de metode de clasă.
În astfel de limbi, API-ul este încă distribuit ca o bibliotecă. De exemplu,
bibliotecile de limbă Java includ un set de API-uri care sunt furnizate sub formă de JDK
utilizat de către dezvoltatorii pentru a construi noi programe Java. JDK includ
documentația API în notație JavaDoc.
Calitatea documentației asociată cu un API este de multe ori un factor determinant
pentru succesul său în ceea ce privește ușurința de utilizare.

8.3. Arhitectura si biblioteci API

Un API este de obicei legată de o bibliotecă de software: API descrie și prescrie

comportamentul dorit, în timp ce biblioteca este o punere în aplicare efectivă a acestui set
de reguli. Un singur API poate avea punerea în aplicare multiplă (sau nici unul, fiind
abstract), sub forma unor biblioteci diferite care împart aceeași interfață de programare.
Un API poate fi legată de o arhitectura software: o arhitectură se poate baza pe mai
multe biblioteci de implementare mai multe API-uri, dar spre deosebire de utilizarea
normală a unui API, accesul la comportamentul construit în arhitectura este mediată prin
extinderea conținutului său cu noi clase conectat la arhitectura în sine. Mai mult decât atât,
fluxul global al programului de control poate fi în afara controlului apelantului, și în
mâinile arhitecturii prin inversare de control sau un mecanism similar.

8.4. API si protocoale

API poate fi, de asemenea, o implementării a unui protocol. Atunci când un API
implementează un protocol poate fi bazată pe metode de Proxy pentru invocări la distanță,
care se bazează pe sub protocolul de comunicare. Rolul API poate fi exact pentru a
ascunde detaliile a protocolului de transport. Ex .: RMI este un API care pune în aplicare
protocolul JRMP sau IIOP ca RMI-IIOP.
Protocoalele sunt de obicei împărțite între diferite tehnologii (sisteme bazate pe
limbaje de programare, într-un anumit sistem de operare) și, de obicei permit diferite
tehnologii pentru a face schimb de informații, acționând ca un nivel de abstractizare /
mediere între cele două medii diferite. Protocolul prin urmare, poate fi considerat API la
distanță, API-uri locale în schimb sunt de obicei specifice unei anumite tehnologii: prin
urmare, un API pentru o anumită limbă nu poate fi utilizată în alte limbi, cu excepția
cazului când apeluri de funcții sunt împachetate cu bibliotecile de adaptare specifice.
Pentru a permite schimbul de informații între sisteme care folosesc tehnologii
diferite, atunci când un API implementează un protocol, acesta poate prescrie un format de
mesaj-limbaj neutru: de ex SOAP folosește XML ca un container general pentru mesajele
care urmează să fie schimbate, REST API în mod similar poate utiliza atât XML și JSON.

8.5. Obiect API de schimb și protocoale

Un obiect API poate prescrie un anumit format de schimb obiect pe care un

program poate utiliza local într-o aplicație, în timp ce un protocol de schimb obiect poate
defini un mod de a transfera același tip de informații într-un mesaj trimis la un sistem la
distanță.
Atunci când un mesaj este schimbat prin intermediul unui protocol între două
platforme diferite, folosind obiecte de pe ambele părți, obiectul într-un limbaj de

38
programare poate fi transformat într-un obiect la distanță și diferite limbaje de programare:
astfel încât, de exemplu, un program scris în Java invocă un serviciu prin intermediul
SOAP sau IIOP scrise în C # ambele programe folosesc API-uri pentru invocarea de la
distanță pentru a face schimb de informații (de la distanță), care ambele convertesc de la /
pentru un obiect în memoria locală.
In schimb, atunci când un obiect similar este schimbat printr-un API local de la o
singură mașină obiectul este schimbat în mod efectiv în memorie: de ex prin intermediul
memoriei alocate printr-un singur proces, sau între mai multe procese care utilizează
memoria partajată, un server de aplicații, sau alte tehnologii de partajare, cum ar fi spații
tuple.

8.6. Obiect API de acces la distanță și protocoale

Un obiect API de acces la distanță se bazează in protocoale cu acces la distanță,

cum ar fi CORBA, care permite invocarea prin metoda acces la distanță. Un apel de
metodă, executată la nivel local pe un obiect proxy, invocă metoda corespunzătoare de pe
obiect la distanță, utilizând protocolul de acces la distanță, și dobândește, rezultatul să fie
folosit local ca valoare de retur.
Când de accesul la distanță este implementat, o modificare a obiectului Proxy
corespunde unei modificări asupra obiectului la distanță. Atunci când este implementat
numai un transfer de obiect, modificarea la copia locală a obiectului nu este reflectat în
obiectul original, cu excepția cazului în care obiectul este trimis înapoi la sistemul de
trimitere.

8.7. Partajarea API și reutilizarea prin mașină virtuală

Anumite limbaje, cum ar fi cele care rulează într-o mașină virtuală pot partaja un
API. În acest caz, o mașină virtuală permite interoperabilitatea limbajului, prin
abstractizarea unui limbaj de programare, folosind un cod de octet intermediar și legături
lingvistice. În aceste limbaje, compilator efectuează doar în compilare timp sau înainte de
timp de compilare transformă codul sursă, eventual scris în mai multe limbaje, în
reprezentarea sa de cod octet independent de limbaj.
De exemplu, prin reprezentarea de cod octet, un program scris în limba Groovy sau
Scala poate folosi orice clasă Java standard, și, prin urmare, orice Java API. Acest lucru
este posibil datorită faptului atât Groovy și Scala au un model de obiect care este un super
set a limbajului Java; în acest fel, orice API expus prin intermediul unui obiect Java este
accesibil prin Groovy sau Scala printr-o invocare obiect echivalent tradus în cod de octet.
Pe de altă parte, Groovy și Scala introduc entități de primă clasă, care nu sunt
prezente în Java, cum ar fi dispozitive de închidere. Aceste entități nu pot fi reprezentate în
limbajul Java nativ (Java 8 a introdus conceptul de expresie lambda); astfel, pentru a
permite funcționarea alia, o închidere este încapsulat într-un obiect standard de Java. În
acest caz, invocarea de închidere este mediată printr-un apel numit “call ()”, care este
întotdeauna prezentă într-un obiect de închidere așa cum se vede in Java, iar în Java
închiderea nu reprezintă o entitate de primă clasă.

39
 8.8. API-uri Web

API-urile web sunt interfețe definite prin interacțiuni care au loc între o
întreprindere și aplicațiile care utilizează activele sale. O abordare API este o abordare
arhitecturală care se învârte în jurul furnizând interfețele programabile la un set de servicii
pentru diferite aplicații care deservesc diferite tipuri de consumatori.
Atunci când este utilizat în contextul de dezvoltare web, un API este definit în mod
obișnuit ca un set de Hypertext Transfer Protocol (HTTP) mesaje de solicitare, împreună
cu o definiție a structurii mesajelor de răspuns, care este de obicei într-un Extensible
Markup Language (XML) sau JavaScript Object Notation format (JSON). În timp ce "API-
ul web", a lungul historiei a fost practic sinonim pentru serviciul web, tendința recentă
(așa-numitul Web 2.0) a fost trecerea de la Simple Object Access Protocol (SOAP) servicii
bazate pe web si arhitectura orientata pe servicii (SOA) către mai directă prin transfer de
stat (REST) resurse web reprezentaționale stil și arhitectură orientată spre resurse (ROA).
O parte din această tendință este legată de Semantic Web Movement spre Resource
Description Framework (RDF), un concept pentru a promova tehnologiile de inginerie de
ontologie bazate pe web. API-uri web permit combinarea de mai multe API-uri în noi
aplicații cunoscut sub numele de mashup.

8.9. Utilizarea Web pentru a partaja conținut

Practica de publicare API-uri a permis comunităților web pentru a crea o arhitectură

deschisă pentru schimbul de conținut și de date între comunități și aplicații. În acest fel,
conținutul care este creat într-un singur loc pot fi postate și actualizate în mai multe locații
de pe web dinamic:
 Fotografiile pot fi partajate de pe site-uri precum Flickr și Photobucket la site-
uri de rețele sociale precum Facebook si Instagram.
 Conținutul poate fi încorporat, de exemplu, încorporarea unei prezentări de la
SlideShare pe un profil LinkedIn.
 Conținutul poate fi postate în mod dinamic. Partajarea de comentarii în direct
făcute pe Twitter cu un cont de Facebook, de exemplu, este activat prin API-
urile lor.
 Conținut video poate fi încorporat pe site-urile deservite de o alt host (gazda).
 Informații utilizator pot fi partajate între comunități web la aplicațiile externe,
oferind noi funcționalități pentru comunitatea web care împărtășește datele sale
de utilizator prin intermediul unui API deschis. Unul dintre cele mai bune
exemple în acest sens este platforma Facebook. Un alt aspect este platforma
socială deschisă.
 În cazul în care conținutul este o reprezentare directă a lumii fizice (de
exemplu, temperatura într-o locație geospațială pe pământ), atunci un API poate
fi considerată o interfață de programare de mediu ("Environmental
Programming Interface" - EPI). EPI-uri sunt caracterizate prin capacitatea lor
de a oferi un mijloc pentru evenimente universale suficiente pentru a utiliza
date reale pentru luarea deciziilor.

40
 8.10. Implementări

Standardul POSIX definește un API care permite scrierea unei game largi de funcții
de calcul comune într-un mod, astfel încât acestea să poată funcționa pe mai multe sisteme
diferite (Mac OS X, și diverse Berkeley Software Distributions (BSDS) implementa
această interfață) .Cu toate, folosind aceasta interfața necesită o re-compilare pentru fiecare
platformă. Un API compatibil, pe de altă parte, permite cod obiect compilate să
funcționeze fără modificării ale sistemului care implementează acest API. Acest lucru este
benefic pentru ambele furnizori de software (în cazul în care acestea pot distribui software-
ul existent pe noi sisteme, fără a produce și / distribuirea de upgrade-uri) și de utilizatori
(în cazul în care acestea se pot instala software mai vechi pe noi sisteme lor fără a cumpăra
upgrade-uri), cu toate că acest lucru necesită, în general, că diferite biblioteci software
implementarea API-urile necesare, de asemenea.
Microsoft a demonstrat un angajament puternic față de un API compatibil înapoi, în
special în biblioteca lor Windows API (Win32), astfel încât aplicațiile mai vechi pot rula
pe versiunile mai noi de Windows, utilizând o setare executabil-specific numit "modul de
compatibilitate". Printre sistemele de operare Unix, există mai multe sisteme de operare,
dar incompatibile când este vorba de rularea la o platformă hardware comună (în special
Intel sisteme 80386 compatibile).
Au existat mai multe încercări de a standardiza API astfel încât furnizorii de
software ar putea distribui o aplicație binară pentru toate aceste sisteme; Cu toate acestea,
până în prezent, nici una dintre acestea nu a întâlnit. Standard Base Linux încearcă să facă
acest lucru pentru platforma Linux, în timp ce multe dintre BSD Unix-uri, cum ar fi
FreeBSD, NetBSD și OpenBSD, implementează diferite niveluri de compatibilitate API
pentru ambele compatibilitate (permițând programe scrise pentru versiuni mai vechi pentru
a rula pe distribuții mai noi ale sistemului) și compatibilitate cross-platform (care permite
executarea de cod externe fără recompilare).

8.11. Design API

Mai multe principii sunt frecvent utilizate pentru a reglementa procesul de

elaborare a API-uri. Parnas a propus conceptul de ascunderea informației în 1972.
Principiul de ascundere a informațiilor este acela că se poate împărți software-ul în
module, fiecare dintre acestea are o interfață specificată. Interfețele ascund detaliile de
implementare a modulelor, astfel încât utilizatorii de module nu trebuie să înțeleagă
complexitatea din interiorul modulelor. Aceste interfețe sunt API-uri, și, ca rezultat, API-
uri ar trebui să expună numai acele detalii ale modulului pe care clienții trebuie să știe să
utilizeze module în mod eficient. Arhitectura Software-ul este dedicat creării și menținerii
unor structuri de software la nivel înalt, include de obicei module. Astfel, o arhitectură de
sistem este indisolubil legată de API-uri care exprimă această arhitectură. Cu toate acestea,
multe decizii implicate în crearea de API-uri nu sunt arhitecturale, cum ar fi convențiile de
denumire și mai multe detalii cu privire la modul în care sunt structurate interfețe.
Aceste detalii cu privire la modul în care sunt structurate interfețe, precum și
arhitectura software, au un impact semnificativ asupra calitatea softwarului. De exemplu,
Cataldo et al. a constatat că bug-uri este corelat cu dependențe logice de date și în software.
Acest lucru implică faptul că, pentru a reduce ratele de bug-uri, dezvoltatorii de software ar
trebui să ia în considerare cu atenție dependențe a API-ului.
Legea lui Conway afirmă că structura unui sistem reflectă în mod inevitabil
structura organizației pe care a creat-o. Acest lucru sugerează că pentru a înțelege modul în
care API-uri sunt proiectate în lumea reală, trebuie să înțelegem, de asemenea, structurile

41
organizațiilor de inginerie software. De asemenea, un grup de API ar trebui să se
structureze în funcție de ceea ce are nevoie API. Într-un studiu de 775 de ingineri software
Microsoft, Begel et al. a constatat că, în plus față de coordonare în ceea ce privește
proiectarea API, inginerii de software coordonează și in mod obișnuit în ceea ce privește
orarele și funcții. Acest lucru întărește opinia că organizațiile de software colaborează pe
scară largă și că structura organizatorică este importantă.
Mai mulți autori au creat recomandări pentru modul de a proiecta API-uri, cum ar fi
Joshua Bloch, Kin Lane, și Michi Henning. Deoarece unul dintre principiile de proiectare
API este că un API ar trebui să fie în concordanță cu alte API-uri aflate deja în uz în
sistem, detaliile de proiectare API sunt oarecum limbajul și dependente de sistem.

8.12. Release policies.

The main policies for releasing an API are:

 Protejarea informațiilor despre API-uri față de public. De exemplu, Sony folosit
pentru a face PlayStation 2 API disponibile numai pentru dezvoltatorii
PlayStation licențiate. Acest lucru a permis Sony pentru a controla cine a lansat
jocuri de PlayStation 2. Acest lucru oferă privilegii de control de calitate al
companiilor și le poate oferi fluxuri de venituri potențiale de licențiere.
 Ceea ce face API-uri disponibile în mod liber. De exemplu, Microsoft face
public API-ul Microsoft Windows.

8.13. Implicații API publice

Un API poate fi dezvoltat pentru un grup restricționat de utilizatori, sau poate fi pus
la dispoziția publicului. Un factor important atunci când un API devine public este
stabilitatea acesteia interfață. de exemplu, prin adăugarea parametri boi la apelarea
funcției: ar putea rupe compatibilitatea cu clienții care depind de acel API.
Atunci când părțile componente ale unui API prezentat public sunt supuse
schimbării și, prin urmare, nu este stabilă, astfel de părți ale unui anumit API ar trebui să
fie documentată în mod explicit ca instabil. De exemplu, în biblioteca Google Guava
componentele care sunt considerate instabile, și care ar putea schimba într-un viitor
apropiat, sunt marcate cu adnotare Java @Beta.

8.14. Deprecierea API-ului

Un API public poate declara, uneori, părți în sine ca depreciate. Acest lucru
înseamnă, de obicei, că o astfel de parte a unui API ar trebui să fie considerați candidați
pentru a fi eliminate, sau modificate într-un mod incompatibil înapoi.
Atunci când adoptă un API public, o terță parte de dezvoltatorii ar trebui să ia în
considerare politica de dezaprobare utilizată de către producătorul acelui API; în cazul în
care un dezvoltator eliberează în mod public o soluție bazată pe un API care devine
depreciat, el / ea ar putea fi în imposibilitatea de a garanta serviciul furnizat.

42
 8.15. Exemple API

 Cocoa si carbon pentru Macintosh;

 DirectX pentru Microsoft Windows;
 JSAPI pentru vorbire computaționala;
 ODBC pentru Microsoft Windows;
 OpenGL pentru programarea componentelor grafice;
 OpenMP;
 SAPI;
 SDL;
 ASPI;

8.16. Ce este JSAPI sau MSAPI?

Java Speech API sau Microsoft Speech API definește o interfața pentru tehnologia
de vorbire computaționala. Exista doua sub-tehnologii de vorbire care sunt disponibile prin
SAPI: recunoasterea vorbirii si sintetizarea vorbirii. Recunoasterea vorbirii ofera
calculatoarelor abilitatea sa asculte o limba vorbita si sa deternine ceea ce a fost spus. cu
alte cuvinte, proceseaza intrarea audio continand vorbire covertind-o in text. Sintetizarea
vorbirii ofera posibilitatea calculatoarelor sa produca vorbire sintetica dintr-un text generat
de o aplicatie, care se mai numeste si tehnologia text-to-speech.

Unde se pot folosi astfel de aplicatii? De exemplu, in telecomunicatii sitemele

interactive de raspuns prin voce sunt mult mai atractive decat cele traditionale prin
apasarea unuei combinatii de taste; sisteme de dictare pot fi considerate mai rapide decat
tastarea pentru multi utilizatori; tehnologia de vorbire imbunatateste accesabilitatea la
calculatoare pentru oamenii cu handicap.

8.17. Scopurile a interfetei Speech API

 Sa ofere suport pentru sintetizarea vorbirii si pentru recunoasterea vorbirii, fie

pentru sistemele de dictare fie pentru emulatorele de comenzii.
 Ofera o interfata robusta pentru sintetizarea vorbirii si pentru recunoasterea
vorbirii.
 Integrarea acestei interfete in alte capabilitatii a unei aplicatii.

9. Dezvoltare versiunii Alpha/Beta

9.1. Versiunea Alpha

Versiunea Alpha a aplicației are ca scop testarea funcției de transformarea de voce

in text in limba portugheza. Aplicația are doua funcții principale: identificarea
microfonului calculatorului, si scrierea in limba portugheza, sau limba la alegere; in cazul
meu deocamdată am următoarele limbii la dispoziție: Portugheza, engleza, franceza,
spaniola si Italiana. In perioada testării 4 din 5 cuvinte au fost identificatei in cazul
propozițiilor scurte (de trei cuvinte).

43
 9.2. Dezvoltare versiunii Beta

La testarea versiunii Beta, am reușit sa introduc mai multe limbii cum se poate
vedea si in aplicația, sunt convins este un rezultat diferit fata de testarea versiunii Alpha.
In cazul versiunii Alpha, transformarea de voce in text in limba portugheza se face la
nivelul întregului cuvânt . In cazul versiunii Beta se face o analiza mai fina a testului
recunoscut, la nivel de cuvânt.

Testarea versiunii Beta este efectuata in trei etape:

 Prima etapa are un rol preliminar, cu scopul de a analiza influenta pe care o are
mărimea corpusului. Cu aceasta ocazie, este analizata si influenta unor
particularitati ale textului la testare (nume proprii, cuvinte de început si sfârșit intr-
o propoziție.
 A doua etapa este făcuta utilizând la antrenare un text de dimensiuni mai mari si la
testare același text din care elimina majoritatea numelor proprii.
 A treia etapa are ca scop de identifica valori optime ale parametrilor pentru care se
păstrează precizia si confirmarea rezultatelor pe un text din lumea reala.

La testarea Beta un factor care influențează este calitatea rezultatului si in același

timp, numărul de limbi activate în fereastra principală a aplicaţiei.
Pentru viitor o sa fie testate după terminarea proiectului si in sisteme mobile, si
aștept ca intervalul de codificare sa fie mai corecte in proporție de 100%. Acest lucru e de
așteptat având in vedere ca sursele de eroare sunt exterioare algoritmului folosit. In cazul
discriminării limbilor cu același tip de codificare Unicode, rezultatele vor fi similare cu
versiunea Alpha, ceea ce înseamnă ca atât algoritmul este robust, cat si ca implementarea
este fara erori.
Interfața aplicației:

Instructiuni de utilizare:

44
 In partea superioara dreapta se afla o optiune de alegere o interfata a limbii,
reprezentata prin urmatoarea imagine:

In urmatorul meniu se arata posibilitatea de a alege limba dorita dupa dictare.

45
 9.3. Rezultatele obținute in urma testelor
9.3.1. Limba Portugheză

Simbolurile din partea dreapta a imaginii semnifica:

 Primul icon – posibilitatea de a alege variantele textului;
 Al doilea icon – demonstrează ca difuzorul este pornit;
 Al treilea icon – activarea microfonului;
 Al patrulea icon – acceptarea textului dorit;
 Al cincilea icon – copierea textului;
 Al șaselea icon – semne de punctuație si simboluri monetare;
 Al șaptelea icon – printare;
 Al optulea icon – ștergerea textului;
 Al nouălea icon – trimitere mail;
 Al zecelea icon – partajarea textului in rețele sociale (Twitter);
 Al unsprezecelea icon – traducerea textului acceptat prin intermediul
Google translator.

46
Se poate observa ca butoanele din partea dreapta a imaginii se activează odată ce textul
este acceptat.

47
9.3.2. Limba română

48
9.3.3. Limba engleză

49
50
 10. Concluzii

Modificarea unor algoritmi existenți, după cum s-a arătat, trebuie însoțită de analiza
performanțelor în diverse condiții, cum sunt de exemplu texte scurte dar care conțin totuşi
cuvinte din limbi diferite.
Unul dintre cei mai importanţi factori de care depinde dificultatea procesului de
transcriere este sarcina de recunoaștere. Aceasta include specificitatea limbii, numărul de
cuvinte ce pot fi pronunţate şi incertitudinea lingvistică a sarcinii de recunoaştere.
Acest proiect, mi-a dat o imagine decenta de asamblu a modului in care care
functioneaza recunoasterea vocala (vorbirii).
O aplicatie efectiva de vorbire este aceea care foloseste vorbirea pentru a sporii
performanta utilizatorului sau pentru a adauga o activitate care nu se poate face altfel. Un
studiu asupra dialogului natural asigura ca avertizarile si feedback-ul urmareste conventile
de conversatie pe care utilizatorii asteapta intr-o interactiune.

51
 11. Bibliografie

 Baldwin, T. and Lui M. (2010) Language Identification: The Long and the Short of
the Matter. Human Language Technologies: The 2010 Annual Conference of the
North American Chapter of the ACL, pages 229–237, Los Angeles, California
 Cavnar, W., and Trenkle, J. (1994). N-gram-based text categorization. Proc. 3rd
Symp. On Document Analysis and Information Retrieval (SDAIR-94)
 Churcher, G. (1994) Distinctive character sequences. Personal Communication by
Ted Dunning
 Churcher, G., Hayes, J., Johnson, S. and Souter, C (1994) Bigraph and trigraph
models for language identification and character recognition. in Proceedings of
1994 AISB Workshop on Computational Linguistics for Speech and Handwriting
Recognition, University of Leeds
 Devadoss, J.M. (2010) Advanced Natural Language Translation System, Global
Journal of Computer Science and Technology, Vol 9, No 5
 Dunning, T. (1994) Statistical Identification of Language. Technical Report MCCS
94-273, New Mexico State University
 Fogarassy-Neszly, P. (2011) Aplicaţii informatice şi dispozitive cu interfaţă vocală.
Revista Română de Interacţiune Om-calculator 4 (Numar special RoCHI 2011), 53-
58.

52
 12. Anexe
Codul sursa a aplicatiei

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html lang="en-US">
<head>
<title>Voice Recognition by Balduino - Speech Recognition in a Browser</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="description" content="An easy to use web app which allows free speech
to text dictation in a browser." />
<meta name="keywords" content="speech-to-
text,speech,text,dictation,voice,recognition" />
<meta property="og:image"
content="https://balduinovoice.esy.es/common/images/voiceRecognitionLogoBox.png"/>
<meta property="og:title" content="Voice Recognition by Balduino - Speech
Recognition in a Browser" />
<meta property="og:type" content="website" />
<meta property="og:site_name" content="Voice Recognition by Balduino Camachi" />
<meta property="og:description" content="An easy to use web app that gives you
speech to text dictation in a browser." />
<meta property="og:url" content="https://balduinovoice.esy.es/index.html" />
<script src="../../../common/js/jquery-1.5.1.min.js" type="text/javascript"></script>
<script src="../../../common/js/jquery.cookie.js" type="text/javascript"></script>
<script src='../../../common/js/jquery.simplemodal.1.4.1.min.js'
type='text/javascript'></script>
<script src='../../../common/js/vs.js-v=9.htm' type='text/javascript'></script>
<link rel="stylesheet" type="text/css" href="../../../common/css/speech.css-v=9-1.htm" />
<script src="../../../../platform.twitter.com/anywhere.js-id=vNgGuvn7vA7Q6PntwT73g-
amp-v=1.htm" type="text/javascript"></script>
<link rel="canonical" href="../../../index.html">
<script type="text/javascript" src="../../../common/js/jquery.zclip.min.js"></script>
<script language="javascript" type="text/JavaScript">
<!--
var vscs = "Copy text to clipboard";
var vstc = "Text copied";
var vsgp = "Give permission to use the microphone.";
var vsbd = "Begin dictating";
var cl = "";
var clo = "Close";
var vsk = "../js";
var lang = 'en-US';
var bcpLang = 'en-US';
var ttl = 'AutoSave - Text too long';
var dat = "Dictated at balduinovoice.esy.es";
var tex = "Text too long for tweet";
var ttex = "Text too long";
var vser = "Error";
var sf = 1;

53
var ttlt = 0;
var gtb = {
'af':"https://translate.google.co.za/?hl=af&tab=wT",
'ar':"https://translate.google.com/?hl=ar&tab=wT",
'bg':"https://translate.google.bg/?hl=bg&tab=wT",
'ca':"https://translate.google.cat/?hl=ca&tab=wT",
'zh-Hans':"https://translate.google.com/?hl=zh-CN&tab=wT",
'zh-Hant':"https://translate.google.com/?hl=zh-TW&tab=wT",
'cs':"https://translate.google.com/?hl=cs&tab=wT",
'da':"https://translate.google.dk/?hl=da&tab=wT",
'nl':"https://translate.google.nl/?hl=nl&tab=wT",
'en-US':"https://translate.google.com/?hl=en&tab=wT",
'en-GB':"https://translate.google.co.uk/?hl=en&tab=wT",
'fi':"https://translate.google.fi/?hl=fi&tab=wT",
'fr':"https://translate.google.fr/?hl=fr&tab=wT",
'gl':"https://translate.google.es/?hl=gl&tab=wT",
'de':"https://translate.google.de/?hl=de&tab=wT",
'el':"https://translate.google.gr/?hl=el&tab=wT",
'he':"https://translate.google.co.il/?",
'hu':"https://translate.google.hu/?hl=hu&tab=wT",
'is':"https://translate.google.is/?hl=is&tab=wT",
'id':"https://translate.google.co.id/?hl=id&tab=wT",
'it':"https://translate.google.it/?hl=it&tab=wT",
'ja':"https://translate.google.co.jp/?hl=ja&tab=wT",
'ko':"https://translate.google.com/?hl=ko&tab=wT",
'la':"https://translate.google.com/?hl=la&tab=wT",
'ms':"https://translate.google.com.my/?hl=ms&tab=wT",
'no':"https://translate.google.no/?hl=no&tab=wT",
'pl':"https://translate.google.com/?hl=pl&tab=wT",
'pt':"https://translate.google.com/?hl=pt&tab=wT",
'ro':"https://translate.google.ro/?hl=ro&tab=wT",
'ru':"https://translate.google.com/?hl=ru&tab=wT",
'sr':"https://translate.google.rs/?hl=sr&tab=wT",
'sk':"https://translate.google.sk/?hl=sk&tab=wT",
'es':"https://translate.google.es/?hl=es&tab=wT",
'sv':"https://translate.google.se/?hl=sv&tab=wT",
'tr':"https://translate.google.com/?hl=tr&tab=wT",
'zh-yue':"https://translate.google.com.hk/?hl=zh-TW&tab=wT",
'zu':"https://translate.google.com/?hl=zu&tab=wT",
};
var glc = {
'af':0,
'ar':2,
'bg':1,
'ca':0,
'zh-Hans':1,
'zh-Hant':1,
'cs':0,
'da':0,
'nl':0,

54
'en-US':0,
'en-GB':0,
'fi':0,
'fr':0,
'gl':0,
'de':0,
'el':0,
'he':2,
'hu':0,
'is':0,
'id':0,
'it':0,
'ja':1,
'ko':1,
'la':0,
'ms':0,
'no':0,
'pl':0,
'pt':0,
'ro':0,
'ru':1,
'sr':1,
'sk':0,
'es':0,
'sv':0,
'tr':0,
'zh-yue':1,
'zu':0,
};
var bcp = {
'af':'af-ZA',
'ar':'ar-EG',
'bg':'bg',
'ca':'ca',
'zh-Hans':'cmn-Hans-CN',
'zh-Hant':'cmn-Hant-TW',
'cs':'cs-CZ',
'da':'da',
'nl':'nl-NL',
'en-US':'en-US',
'en-GB':'en-GB',
'fi':'fi',
'fr':'fr-FR',
'gl':'gl',
'de':'de-DE',
'el':'el',
'he':'he-IL',
'hu':'hu',
'is':'is',
'id':'id-ID',

55
'it':'it-IT',
'ja':'ja-JP',
'ko':'ko-KR',
'la':'la',
'ms':'ms-MY',
'no':'no',
'pl':'pl-PL',
'pt':'pt-BR',
'ro':'ro',
'ru':'ru-RU',
'sr':'sr',
'sk':'sk',
'es':'es-ES',
'sv':'sv-SE',
'tr':'tr-TR',
'zh-yue':'zh-yue',
'zu':'zu',
};
(function() {
var po = document.createElement('script'); po.type = '../../../text/javascript/index.htm';
po.async = true;
po.src = 'https://apis.google.com/js/plusone.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s);
})();
//-->
</script>
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-31342981-1']);
_gaq.push(['_trackPageview']);

(function() {
var ga = document.createElement('script'); ga.type = '../../../text/javascript/index.htm';
ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-
analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
</head>
<body>
<https://www.facebook.com/estison.balduino>
<div id="page">
<div id="content">
<div id="topban">
<div id="stripe1">
<div id="tb-left">
&nbsp;
</div><!--tb-left -->
<div id="logodiv">

56
<a href="../../../index.htm"><img src="../../../common/images/voiceRecognitionLogo.png"
width="300" alt="Voice Recognition Logo" /></a><br />
<p id="slogan">Voice Recognition Application for Browser by Balduino</p>
</div><!-- logodiv -->
<div id="tb-right"><div id="globeButton"><a href="../../../international.html"><img
id="globeButtonImg" src="../../../common/images/globe_of_flags.png" title="Voice
Recognition in other languages" alt="Globe Icon" /></a><br />
<select id="pageSwap" title="Voice Recognition in other languages">
<option value="https://balduinovoice.esy.es/ar/index.html" >‫<ل عرب ية‬/option>
<option value="https://balduinovoice.esy.es/zh-hans/index.html" >中文 (简体)</option>
<option value="https://balduinovoice.esy.es/zh-hant/index.html" >中文 (繁體)</option>
<option value="https://balduinovoice.esy.es/index.html" selected="selected">English
(US)</option>
<option value="https://balduinovoice.esy.es/en-gb/index.html" >English (GB)</option>
<option value="https://balduinovoice.esy.es/fr/index.html" >Français</option>
<option value="https://balduinovoice.esy.es/de/index.html" >Deutsch</option>
<option value="https://balduinovoice.esy.es/it/index.html" >Italiano</option>
<option value="https://balduinovoice.esy.es.com/ja/index.html" >日本語</option>
<option value="https://balduinovoice.esy.es.com/pt/index.html" >Português</option>
<option value="https://balduinovoice.esy.es.com/ru/index.html" >Pyccĸий</option>
<option value="https://balduinovoice.esy.es.com/es/index.html" >Español</option>
</select>
</div>
<div id="ttiyl">Type in your language</div></div>
</div><!-- stripe1 -->
</div><!-- topban -->
<div id="aspace">
<div id="banad">
<script type="text/javascript"><!--
google_ad_client = "ca-pub-5042118140766962";
/* banner-top */
google_ad_slot = "3110467859";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="../../../../pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</div></div><!-- aspace -->
<div id="sidebar-left">
<div id="social">
<div id="sbx">
<div class="fl" >
<div class="sb">
<iframe
src="javascript:if(confirm('https://www.facebook.com/plugins/like.php?href=https%3A%2
F%2Fbalduinovoice.esy.es./index.html&amp;layout=box_count&amp;show_faces=false&
amp;width=70&amp;action=like&amp;colorscheme=light&amp;height=65\n\nThis file

57
was not retrieved because it was filtered out by your project settings.\n\nWould you like to
open it from the
server?'))window.location='https://www.facebook.com/plugins/like.php?href=https%3A%
2F%2Fbalduinovoice.esy.es/index.html&amp;layout=box_count&amp;show_faces=false&
amp;width=70&amp;action=like&amp;colorscheme=light&amp;height=65'"
scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:70px;
height:65px;" allowTransparency="true"></iframe>
</div>
<div class="sb"><a href="javascript:if(confirm('https://twitter.com/share\n\nThis file
was not retrieved because it was filtered out by your project settings.\n\nWould you like to
open it from the server?'))window.location='https://twitter.com/share'" class="twitter-
share-button" data-count="vertical">Tweet</a><script type="text/javascript"
src="../../../../platform.twitter.com/widgets.js"></script>
</div>
</div>
<div class="flrt" >
<div class="sb"><br style="margin-bottom:15px;" />
<a
href="javascript:if(confirm('https://pinterest.com/pin/create/button/?url=https%3A%2F%2
Fbalduinovoice.esy.es%2Findex.html&media=https%3A%2F%2Fbalduinovoice.esy.es%2
Fcommon%2Fimages%2FvoiceRecognitionLogoBox.png&description=An%20easy%20to
%20use%20web%20app%20providing%20free%20speech%20to%20text%20dictation%2
0in%20a%20browser.\n\nThis file was not retrieved because it was filtered out by your
project settings.\n\nWould you like to open it from the
server?'))window.location='https://pinterest.com/pin/create/button/?url=https%3A%2F%2F
balduinovoice.esy.es%2Findex.html&media=https%3A%2F%2Fbalduinovoice.esy.es%2F
common%2Fimages%2FvoiceRecognitionLogoBox.png&description=An%20easy%20to
%20use%20web%20app%20providing%20free%20speech%20to%20text%20dictation%2
0in%20a%20browser.'" class="pin-it-button" count-layout="vertical" always-show-
count="true"><img border="0" src="../../../../assets.pinterest.com/images/PinExt.png"
title="Pin It" /></a>
</div>
<div class="sb">
<!-- Place this tag where you want the +1 button to render -->
<g:plusone size="tall"></g:plusone>
</div>
</div>
</div>
</div>
<div id="unfortunately" style="display:none;">
<p><span class="intro-title">Unfortunately...</span> &nbsp; Your browser does not
support speech input. Fortunately, that problem is easy to solve. Just <a
href="javascript:if(confirm('https://support.google.com/chrome/bin/answer.py?hl=en-
US&answer=95346\n\nThis file was not retrieved because it was filtered out by your
project settings.\n\nWould you like to open it from the
server?'))window.location='https://support.google.com/chrome/bin/answer.py?hl=en-
US&answer=95346'">download Google Chrome</a> and then come back! For other
possibilities, please visit <a href="../../../alternatives.html"> our page on speech to text
options</a>.</p>
</div>

58
</div><!-- sidebar-left -->
<div id="sidebar-right">
<script type="text/javascript"><!--
google_ad_client = "ca-pub-5042118140766962";
/* SideScraper160x600 */
google_ad_slot = "5705054648";
google_ad_width = 160;
google_ad_height = 600;
//-->
</script>
<script type="text/javascript"
src="../../../../pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
</div><!-- sidebar-right -->
<div id="container">
<div id="getspeech">
<div id="ctrlBar">
<img id="prefsButton" src="../../../common/images/settings.png" title="Edit
settings" alt="Settings" />
<select id="setLang" title="Dictate in another language">
<option value="af">Afrikaans</option>
<option value="ar">‫<ل عرب ية‬/option>
<option value="bg">български</option>
<option value="ca">català</option>
<option value="zh-Hans">中文 (简体)</option>
<option value="zh-Hant">中文 (繁體)</option>
<option value="cs">Česky</option>
<option value="da">Dansk</option>
<option value="nl">Nederlands</option>
<option value="en-US" selected="selected">English (US)</option>
<option value="en-GB">English (GB)</option>
<option value="fi">Suomi</option>
<option value="fr">Français</option>
<option value="gl">galego</option>
<option value="de">Deutsch</option>
<option value="el">ελληνικά</option>
<option value="he">‫<עברית‬/option>
<option value="hu">Magyar</option>
<option value="is">íslenska</option>
<option value="id">Indonesia</option>
<option value="it">Italiano</option>
<option value="ja">日本語</option>
<option value="ko">한국어</option>
<option value="la">Latin</option>
<option value="ms">Melayu</option>
<option value="no">Norsk</option>
<option value="pl">Polski</option>
<option value="pt">Português</option>
<option value="ro">Română</option>

59
<option value="ru">Pyccĸий</option>
<option value="sr">српски</option>
<option value="sk">Slovenčina</option>
<option value="es">Español</option>
<option value="sv">svenska</option>
<option value="tr">Tϋrkçe</option>
<option value="zh-yue">粵語</option>
<option value="zu">Zulu</option>
</select>
</div><!-- ctrlBar -->
<div id="ncd"><p>Speech input is not enabled in your browser.<br />
This page should work with Google Chrome 25 or greater.<br />
Please <a
href="javascript:if(confirm('https://support.google.com/chrome/bin/answer.py?hl=en-
US&answer=95346\n\nThis file was not retrieved because it was filtered out by your
project settings.\n\nWould you like to open it from the
server?'))window.location='https://support.google.com/chrome/bin/answer.py?hl=en-
US&answer=95346'">download Google Chrome</a> and then come back!<br
/></p></div><!-- ncd -->
<div id="speechArea">
<div id="w">Click the microphone and begin dictating!</div>
<div id="tc">Text copied</div>
<textarea id="speechBuf" type="text"></textarea>
<div id="speechBtnPanel">
<div id="optionsButton" class="vBtn" ><img id="optionsButtonImg"
src="../../../common/images/options-inactive.png" title="Choose from alternatives"
alt="Other options" /></div>
<div id="listenButton" class="vBtn" ><img id="listenButtonImg"
src="../../../common/images/spkr-inactive.png" title="Listen to the text" alt="Listen"
/></div>
<div id="micButton" class="vBtn" ><img id="micButtonImg"
src="../../../common/images/mic-active.png" title="Dictate" alt="Dictate" /></div>
</div>
</div><!-- speechArea -->
<div id="btnpanel">
<div id="btnsLeft">&nbsp;
</div><!-- btnsLeft -->
<div id="btnsMiddle">
<div id="mbbh">&nbsp;</div><!-- mbbh -->
<div id="mbb">
</div><!-- mbb -->
</div><!-- btnsMiddle -->
<div id="btnsRight">
<div id="acceptBtnFrame" class="acceptInactive">
<div id="acceptButton" class="vBtn" ><img id="acceptButtonImg"
src="../../../common/images/accept-inactive.png" title="Accept dictated text" alt="Accept
text button" /></div>
</div>
</div><!-- btnsRight -->
</div><!-- btnPanel -->
60
<br /><div id="ct"><textarea id="collectedText">Click the microphone and speak. Your
dictated text will appear above. Edit if necessary, then click the arrow button to move the
text down here.</textarea>
<div id="textBtnPanel">
<div id="puncPanel">
<div id="addDot" class="pb">.</div>
<div id="addComma" class="pb">,</div>
<div id="addEx" class="pb">!</div>
<div id="addQ" class="pb">?</div>
<div id="addD" class="pb">-</div>
<div id="addU" class="pb">_</div>
<div id="addAt" class="pb">@</div>
<div id="addSq" class="pb">&#8217;</div>
<div id="addQt" class="pb">&quot;</div>
<div id="addAnd" class="pb">&amp;</div>
<div id="addOp" class="pb">(</div>
<div id="addCp" class="pb">)</div>
<div id="addCopy" class="pb">&#169;</div>
<div id="addDol" class="pb">$</div>
<div id="addD" class="pb">&#163;</div>
<div id="addU" class="pb">&#165;</div>
<div id="addEur" class="pb">&#8364;</div>
<div id="addUex" class="pb">&#161;</div>
<div id="addUq" class="pb">&#191;</div>
<div id="addLaq" class="pb">&#171;</div>
<div id="addRaq" class="pb">&#187;</div>
</div>
<div id="copyButton" class="vBtn" ><img id="copyButtonImg"
src="../../../common/images/copy-active.png" title="Copy text to clipboard" alt="Copy
button" /></div>
<div id="puncButton" class="vBtn" ><img id="puncButtonImg"
src="../../../common/images/punc-active.png" title="Add punctuation" alt="Add
punctuation button" /></div>
<div id="printButton" class="vBtn" ><img id="printButtonImg"
src="../../../common/images/print-inactive.png" title="Print" alt="Print button" /></div>
<div id="clearButton" class="vBtn" ><img id="clearButtonImg"
src="../../../common/images/clear-inactive.png" title="Clear text" alt="Clear button"
/></div>
<div id="mailButton" class="vBtn" ><img id="mailButtonImg"
src="../../../common/images/mail-inactive.png" title="Send an Email" alt="Email button"
/></div>
<div id="tweetButton" class="vBtn" ><img id="tweetButtonImg"
src="../../../common/images/tweet-inactive.png" title="Tweet this text" alt="Tweet button"
/></div>
<div id="transButton" class="vBtn" ><img id="transButtonImg"
src="../../../common/images/translate-inactive.png" title="Translate" alt="Translate"
/></div>
</div><!-- textBtnPanel -->
</div><!-- ct -->
</div> <!-- getSpeech -->

61
<iframe id="talkItOut" name="talkItOut"></iframe>
</div><!-- end of container -->
<div id="alternatives">
<h2>Alternatives</h2>
<div id="popOptions">
&nbsp;
</div>
</div>
<div id="preferences">
<h2>Settings</h2>
<div id="prefPane">
<p><input type='checkbox' id="safeModePref"/>&nbsp;<label for="safeModePref">Safe
Mode:</label>&nbsp;<span id="fp"> (filter profanity from results)</span>
</p>
<p>
<input type='checkbox' id="grammarPref"/>&nbsp;<label for="grammarPref">Simple
Grammar</label>&nbsp;<span id="fg"> (Fix <em>gonna</em>, <em>wanna</em>,
etc.)</span>
</p>
<p>
<input type='checkbox' id="autosavePref"/>&nbsp;<label
for="autosavePref"><strong>AutoSave:</strong></label>&nbsp;<span id="as"> (Save
dictated text automatically)</span>
</p>
<p><label for="playbackPref">Text Playback:</label>&nbsp;
<select id="playbackPref">
<option value='nospeech'>None</option>
<option value='speechutil' >SpeechUtil (English)</option>
<option value='google' selected="selected">Google (*experimental*)</option>
</select>
</p>
<p><label for="fontPref">Font:</label>&nbsp;
<select id="fontPref">
<option value='serif' >Serif</option>
<option value='sans-serif' selected="selected">Sans-Serif</option>
<option value='monospace'>Monospace</option>
<option value='cursive'>Cartoon</option>
<option value='fantasy'>Other</option>
</select>
</p>
<p><label for="fontSizePref">Font Size:</label>&nbsp;
<select id="fontSizePref">
<option value='10'>10</option>
<option value='12'>12</option>
<option value='14'>14</option>
<option value='16'>16</option>
<option value='18' selected="selected">18</option>
<option value='20'>20</option>
<option value='22'>22</option>
<option value='24'>24</option>

62
<option value='26'>26</option>
<option value='28'>28</option>
<option value='30'>30</option>
<option value='32'>32</option>
<option value='34'>34</option>
<option value='36'>36</option>
<option value='38'>38</option>
<option value='40'>40</option>
</select>
</p>
</div><!-- prefPane -->
</div><!-- preferences -->
<div id="fullInstructions">
<div id="instructions" class="popped">
<p><span class="intro-title">Instructions:</span> &nbsp; Click the microphone icon
<img src="../../../common/images/mic-20.png" alt="Dictate Button" title="Dictate Button"
width="20"/> and begin speaking. Dictate about one sentence at a time. When the speech
is recognized, it will appear in red.</p>
<p>If it's not right, click the "Alternatives" button <img src="../../../common/images/opts-
20.png" alt="Other options button" title="Other options button" width="20"/> to view
other 'recognitions', edit the text, or just try dictating again. When the text is right, click the
button with the arrow pointing down <img src="../../../common/images/accept-30.png"
alt="Accept text button" title="Accept text button" width="30"/>, and your text will be
added to the box at the bottom.</p><p>Repeat this process until you're finished. When
you're all done, click the "Copy" button <img src="../../../common/images/copy-
active.png" alt="Copy button" title="Copy button" width="20"/> and then paste the text
into your document, email, blog, or tweet! (If the copy button doesn't work for you,
remember that the shortcut for copying is <span id="shortcut">Ctrl-C</span>.)</p>
<p>Note that you can also dictate basic punctuation by saying things like "period",
"question mark", "new paragraph", etc.</p>
</div><!-- instructions -->
</div><!-- fullInstructions -->
<div id="print">
<h2>Print</h2>
<div id="printPane">
<p>
<label for="prtT">Title:</label><input type='checkbox' id="prtT"/>&nbsp;&nbsp;<input
type="text" id="ptt"/>
</p>
<p><label for="prtSt">Subtitle:</label><input type='checkbox'
id="prtSt"/>&nbsp;&nbsp;<input type="text" id="ptst"/>
</p>
<p><label for="prtF">Footer:</label><input type='checkbox'
id="prtF"/>&nbsp;&nbsp;<span id="fttxt">balduinovoice.esy.es</span>
</p>
<p class="btnDiv"><button id="rpb" >Print</button></p>
</div><!-- printPane -->
</div><!-- print -->
<div id="mail">
<h2>E-mail</h2>

63
<div id="mailPane">
<p>
<label for="mailSub">Subject:</label> <input id="mailSub" type="text" lang="en-US" />
</p>
<p><textarea id="mailText"/></textarea>
</p>
<p><label for="mlF">Footer:</label><input type='checkbox'
id="mlF"/>&nbsp;&nbsp;<span id="mlfttxt">balduinovoice.esy.es</span>
</p>
<p class="btnDiv"><a id="eml" href="../../../index.htm">E-mail</a>
<select id="ems">
<option value='email' >E-mail</option>
<option value='gmail' selected="selected">Gmail</option>
<option value='fastmail' >FastMail</option>
</select>&nbsp;&nbsp;&nbsp;<button id="rmb" >Send</button></p>
</div><!-- mailPane -->
</div><!-- mail -->
<div id="tweet">
<a id="twt" href="../../../index.htm">Tweet</a>
</div><!-- tweet -->
<div id="trans">
<h2>Translate</h2>
<div id="transPane">
<p>
<label for="transLang">To:</label>
<select id="transLang" title="Translate To ...">
<option value="af">Afrikaans</option>
<option value="ar">‫<ل عرب ية‬/option>
<option value="bg">български</option>
<option value="ca">català</option>
<option value="zh-Hans">中文 (简体)</option>
<option value="zh-Hant">中文 (繁體)</option>
<option value="cs">Česky</option>
<option value="da">Dansk</option>
<option value="nl">Nederlands</option>
<option value="en-US" selected="selected">English (US)</option>
<option value="en-GB">English (GB)</option>
<option value="fi">Suomi</option>
<option value="fr">Français</option>
<option value="gl">galego</option>
<option value="de">Deutsch</option>
<option value="el">ελληνικά</option>
<option value="he">‫<עברית‬/option>
<option value="hu">Magyar</option>
<option value="is">íslenska</option>
<option value="id">Indonesia</option>
<option value="it">Italiano</option>
<option value="ja">日本語</option>
<option value="ko">한국어</option>

64
<option value="la">Latin</option>
<option value="ms">Melayu</option>
<option value="no">Norsk</option>
<option value="pl">Polski</option>
<option value="pt">Português</option>
<option value="ro">Română</option>
<option value="ru">Pyccĸий</option>
<option value="sr">српски</option>
<option value="sk">Slovenčina</option>
<option value="es">Español</option>
<option value="sv">svenska</option>
<option value="tr">Tϋrkçe</option>
<option value="zh-yue">粵語</option>
<option value="zu">Zulu</option>
</select>
</p>
<p class="btnDiv"><a id="trns" href="../../../index.htm">Translate</a>
<button id="rtb" >Translate</button></p>
</div><!-- transPane -->
</div><!-- trans -->
<!-- modal content -->
<div id='confirm'>
<div class='header'><span>Confirm</span></div>
<div class='message'></div>
<div class='buttons'>
<div class='no simplemodal-close'>No</div><div class='yes'>Yes</div>
</div>
</div>
<!-- preload the images -->
<div style='display:none'>
<img src='../../../common/js/images/confirm/header.gif' alt='' />
<img src='../../../common/js/images/confirm/button.gif' alt='' />
</div>
</div><!-- content -->
<div id="overlay"></div>
<div id='footer'>
<div><hr /></div>
<p><a href="../../../index.html">Home</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a
href="../../../about.html">About</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a
href="../../../alternatives.html">Alternatives</a> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a
href="../../../privacy.html">Privacy</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a
href="../../../credits.html">Credits</a></p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../../ar/index.html">‫<ل عرب ية‬/a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../../zh-hans/index.html">中文 (简体)</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../../zh-hant/index.html">中文 (繁體)</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../../index.html">English (US)</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../index.html">English (GB)</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../../fr/index.html">Français</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

65
<a href="../../../de/index.html">Deutsch</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../../it/index.html">Italiano</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../../ja/index.html">日本語</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../../pt/index.html">Português</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../../ru/index.html">Pyccĸий</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="../../../es/index.html">Español</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</p>
<p>Copyright &copy;2016 Voice Recognition by Balduino Camachi</p>
</div>
</div><!-- page -->
<script type="text/javascript" src="../../../../assets.pinterest.com/js/pinit.js"></script>
</body>
</html>

66