Google integreert Web Speech-api in nieuwe Chrome-bèta

Google heeft een nieuwe bètaversie van zijn Chrome-browser uitgebracht waarin ondersteuning is toegevoegd voor de Web Speech-api. Hierdoor kunnen ontwikkelaars van websites en webapps ondersteuning voor stembesturing aan invoervelden toevoegen.

De Web Speech-api is gebaseerd op de public speech-api die momenteel in ontwikkeling is bij W3C en werkt op basis van JavaScript. Hoewel Google het niet expliciet vermeldt wordt de ingesproken tekst hoogstwaarschijnlijk eerst naar servers van Google verzonden waar de omzetting van spraak naar tekst plaatsvindt. Daarna wordt de tekstuele weergave van de ingesproken tekst teruggestuurd naar de browser. Een demo van Google toont een aangepast invoerveld met in de bovenhoek een icoontje van een microfoon. Als deze aangeklikt wordt kan begonnen worden met tekstinvoer via spraak.

De nieuwste bèta van Chrome brengt ook verbeteringen met zich mee rondom het installeren van extensies. Via een register-methode was het tot nu toe mogelijk om stilletjes extensies toe te voegen aan Chrome op Windows-machines. Die mogelijkheid was er om gebruikers een opt-in te bieden als ze software installeerden die additionele Chrome-extensies wilde toevoegen. De bèta van Chrome 25 maakt dit onmogelijk en deactiveert extensies die op deze wijze geinstalleerd zijn automatisch, waarbij de gebruiker de keuze krijgt deze handmatig weer te activeren.

Reacties (34)

[TheWickedD]

Volgens mij begrijp ik iets niet; waarom hoort dit in de browser thuis? En zit dat soort software niet al ingebakken in het OS (e.g. Android), danwel kan geinstalleerd worden? Dat soort software kan dan toch ook textvelden invullen, net zoals je er emails mee kunt inspreken? Waarom moet hier dan een hele browser API voor gebakken worden?

Goed dit zijn alleen maar vragen, ik hoop dat ik geen steekjes heb laten vallen. Trouwens, is het niet zo dat goede resultaten met speech-to-text voornamelijk behaald worden na training op de stem van de gebruiker?

[Reactie gewijzigd door TheWickedD op 25 juli 2024 10:14]

[Dreamvoid]

Google's filosofie is dat *alles* de browser in gaat.

[ATS]

En dat die browser dus groter, lomper, trager en onveiliger wordt. Nee, dank je. Dit zie ik liever als een plug-in o.i.d.

[Verwijderd]

Nee, je wilt geen plug-ins. Dan is er weer actie nodig van een eindgebruiker om bepaalde functionaliteit te willen gebruiken. Het hele idee van "alles in de browser" is juist dat je alles altijd en overal (ongeacht het device) werkt zonder dat je daar apps of wat dan ook voor moet installeren.

WebRTC bijvoorbeeld schept bijvoorbeeld de mogelijkheid om voice en video calls op te zetten zonder specifieke apps (zoals bijv. Skype).

[imp4ct]

't Is eigenlijk erg, maar met het ten onder gaan van L&H (Lernout & Hauspie) is er veel goeie technologie ook verloren gegaan op vlak van spraak herkenning en besturing. Maar ik vind het geweldig dat we over enkele jaren gewoon e-mails kunnen dicteren aan de tablet of PC.

Dit zal voor veel mensen weer een nieuwe wereld openen, zoals bv. oudere mensen die niet zo handig zijn met een toetsenbord (of zeer traag), die kunnen dan alles gewoon dicteren en toch makkelijk e-mails versturen. Super!

[pretorian]

met het ten onder gaan van L&H (Lernout & Hauspie) is er veel goeie technologie ook verloren gegaan op vlak van spraak herkenning en besturing

Kun je een voorbeeld noemen? Ik lees namelijk dat de spraakafdeling gewoon overgenomen is door Scansoft.

[boss2022003]

Dit maakt de mogelijkheden als ontwikkelaar nog heel wat breder. Ik ben benieuwd hoe die API eruit ziet. Ik ben altijd een grote fan van de documentatie van Google. Helder, duidelijk en 'straight2thepoint'.

[maarud]

http://9292.nl/ heeft dit ook al een tijdje. Dit werkt ook zonder de api

[Reactie gewijzigd door maarud op 25 juli 2024 10:14]

[Menesis]

Ik heb de update, maar zie nergens een microfoon. Ik meen me zelfs te herinneren dat op google.com eerst wél een microfoontje getoond werd?

[hans_debruin]

Mijn ervaring met spraakherkenning is dat het wel aardig werkt als je van tevoren weet wat je wilt gaan schrijven. Meestal weet ik dat niet precies en vormt een emailtje zich na een tijdje door te schuiven met zinnen, woorden aan te passen e.d.. Daar kan ik best een half uur mee bezig zijn om alles duidelijk in beeld te krijgen.
Met spraakherkenning werkt dat gewoon niet zo handig. Als je met spraak zinnen moet schuiven en aanpassen ben je veel langer bezig.
Simpele korte berichtjes heb je wel voordeel aan, maar goed, dat heb je ook binnen enkele minuten getypt.
Combineer dat met een interface die meestal niet spraakgestuurd is en je zit alsnog aan te toetsenbord en muis om dat emailtje te versturen.

Ik zie heel weinig voordelen hier.

[Peetke]

De grootste aanpassingen/vernieuwingen in Chrome 25 gaan gebeuren in WebRTC: VP9 en Opus audio.

Dit zijn echte next-gen audio en video-codec (royalty vrij en open source).

[Verwijderd]

Opus is een open standaard van de IETF.

VP9 zal weer een proprietary codec zijn die 100% eigendom is van Google.

Dat is een enorm verschil.

[Verwijderd]

Opus heeft een BSD licentie. Een licentie die zoveel vrijheid biedt dat zelfs Microsoft er broncode van leende voor Windows.

VP9 weet ik nog niet van wat de exacte licentie zal zijn, maar aangezien VP8 een copyleft licentie had verwacht ik dat VP9 dat ook zal hebben. Wat is er exact proprietary aan een copyleft licentie?

Kortom, op welk verschil mik je?

[Verwijderd]

Opus heeft een BSD licentie

Je hebt het vast over de source code van één specifieke implementatie van de codec is vastgelegd.
Het Opus standaard formaat valt onder de IETF license policy.

maar aangezien VP8 een copyleft licentie had

Dat was de libvpx API/codeimplementatie. Dat is een google open source implementatie van de VP8 codec.

De VP8/VP9 formaten zijn even open als de oude binaire Office formaten.doc/.xls/.ppt formaten van Microsoft. De specificatie is beschikbaar en er is een technologiebelofte voor implementerende partijen. Beide formaten zijn echter eigendom van een private partij die de volledige controle heeft over het formaat en de aanpassingen daaraan in de toekomst.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 10:14]

[Dreamvoid]

De specificatie is beschikbaar en er is een technologiebelofte voor implementerende partijen.

Precies, de specs zijn open en er hoeven geen royalties betaald te worden. Dat is niet hetzelfde als een patentvrije standaard. Die zijn bijzonder zeldzaam in video-land, bijna alle interessante video compressie technieken zijn ooit gepatenteerd.

[Verwijderd]

Dat is een google open source implementatie

En dat is voldoende. Je kan er vervolgend de wereld bij verzinnen, maar één open source implementatie is voldoende. Die kan je, als daar goede redenen voor zijn forken. De eigenaar *kan* daar geen bezwaar tegen maken.

Van de office formaten bestaat geen 100% werkende open source implementatie en die zal hoogst waarschijnlijk ook nooit bestaan. daarvoor is het formaat een te grote puinhoop.

Dat het format zelf eigendom is van iemand maakt vrij weinig uit. Dat wil je sowieso niet op de schop gooien, tenzij je een volledig nieuwe standaard wil gaan opzetten.

Binnen het huidige formaat blijkt genoeg te winnen, dus een nieuwe standaard lijkt me niet aan de orde.

Maar ik snap nu in elk geval je misleide gedachte dat het niet open zou zijn. Je wil het vrijer maken dan nodig is. Je gaat ook geen volledig nieuw compressie algoritme aan h264 toevoegen omdat bijna niemand dat vervolgens kan decoderen.

Wat dat betreft zijn h264 en VP8 en 9 even proprietary.

Kortom, je speelt met definities om de boel te vertroebelen... Alweer...

[Peetke]

"VP9 is an open and royalty free video compression standard" zie oa. wikipedia of http://www.webmproject.org/

[Dreamvoid]

Je verward hier een open en royalty vrije standaard met een patentvrije standaard.

[Amanush]

Goed nieuws! Misschien moet ik ook maar voor Chrome gaan ontwikkelen!

[David Mulder]

Het is momenteel de grootste browser wereldwijd, dus als je momenteel niet in chrome test dan is dat wel een goed idee ja.

Hoe dan ook, voor de programmeurs hier, dit is niet hetzelfde als de x-webkit-speech flag die je tot nu toe kon toevoegen aan velden, maar dit is een echte API waar je wat meer in controle bent. Persoonlijk heb ik wel een beetje vraag tekens in hoeverre dit in de browser thuishoort, want je kan op zich met de getUserMedia* dit net zo goed zelf bouwen. Het enige voordeel van het in de browser hebben is dat de browser versie ook offline zou kunnen werken, maar dat is tenminste bij Google's implementatie dus niet het geval.

* getUserMedia is de functie die het mogelijk maakt voor web applicaties om de microphone en webcam uit te lezen.

[Reactie gewijzigd door David Mulder op 25 juli 2024 10:14]

[tweakerbwoy]

Of de api zit na een update een keer in chrome gebakken. Het zou kunnen. En als je het zelf moet maken kost dit veel moeite als je het goed werkend wil hebben. Het zou waarschijlijk ook ruimte besparen. Als het ingebakken in Chrome zal zitten zal niet iedere keer spraakbediening in een app moeten zitten en dit scheelt ruimte. Dit zal betekenen dat Chromebooks minder in opslagcapiciteit te hoeven groeien

[FragFrog]

Helaas is goede spraakherkenning nog steeds vrij data-intensief. Er worden goede resultaten gehaald met HMM based speech recognition, maar ook die hebben veel data nodig om enigszins acceptabele resultaten te geven (denk hierbij aan de vaak tegenvallende resultaten van siri). Het is een beetje onzinnig om 100MB aan data mee te leveren bij een browser van 90MB, als het merendeel van je gebruikers het niet eens gebruikt. Bovendien is dat een bak data die je voor elke input-taal weer opnieuw zou moeten downloaden.

Overigens is er ook een W3C VoiceXML standaard die het ook mogelijk maakt om oa. formulieren in te vullen middels spraak; daarbij mist evenwel een grafisch component, m.a.w, daarmee maak je de welbekende bel-menu's. Ben benieuwd hoe spraak-input gaat werken als je het combineert met een normale browser.

[Reactie gewijzigd door FragFrog op 25 juli 2024 10:14]

[Loller1]

"De Web Speech-api is gebaseerd op de public speech-api die momenteel in ontwikkeling is bij W3C en werkt op basis van JavaScript."

Met andere woorden: Google verzint zijn eigen standaarden, alweer.

[Ramon]

Beter ga je gewoon voor standaarden ontwikkelen.

[Dreamvoid]

Standaarden ontwikkelen is niet in een ivoren torentje iets bedenken en via commissies naar voren duwen, het is zelf een techniek bedenken, het uittesten in de markt, en als het goed ontvangen wordt op een gegeven moment standaardiseren. "Embrace-and-extend" is het basisprincipe waarop het WWW gebouwd is.

[Verwijderd]

Dat zijn de facto standaarden die je beschrijft. "Echte" standaarden worden voordat ze worden geimplementeerd beschreven in standardisation bodies, en vervolgens gaan leveranciers dat implementeren. Zie bijv. 3gpp.

[Dreamvoid]

3gpp was ook een defacto standaard, al bestaande codecs + een al bestaande container.

[Reactie gewijzigd door Dreamvoid op 25 juli 2024 10:14]

[WeeJeWel]

Dit was al mogelijk vanaf minimaal versie 23 geloof ik..?

[verleemen]

Mwah, ondanks dat er veelbelovend uitziet mag je nog de helft gaan aanklikken. Daarnaast mag je voor elke punt period gaan zeggen. Ik vraag me af of ik dan niet sneller klaar ben als ik ga typen. Gevaar is natuurlijk dat we er zo aan gewend zijn door in onze smartphones te spreken dat we straks in onze normale real life gesprekken ook de hele tijd period gaan zeggen als we aan t eind van een zin zijn (dubbele punt, haakje sluiten)