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)
Goed nieuws! Misschien moet ik ook maar voor Chrome gaan ontwikkelen!
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.
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 dinsdag 15 januari 2013 08:19]
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
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.
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 dinsdag 15 januari 2013 08:59]
Beter ga je gewoon voor standaarden ontwikkelen.
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.
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.
3gpp was ook een defacto standaard, al bestaande codecs + een al bestaande container.
[Reactie gewijzigd door Dreamvoid op dinsdag 15 januari 2013 11:30]
"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.
Met andere woorden: Google verzint zijn eigen standaarden, alweer.
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'. 
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).
Dit zijn echte next-gen audio en video-codec (royalty vrij en open source).
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.
VP9 zal weer een proprietary codec zijn die 100% eigendom is van Google.
Dat is een enorm verschil.
"VP9 is an open and royalty free video compression standard" zie oa. wikipedia of http://www.webmproject.org/
Je verward hier een open en royalty vrije standaard met een patentvrije standaard.
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?
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?
Je hebt het vast over de source code van één specifieke implementatie van de codec is vastgelegd.Opus heeft een BSD licentie
Het Opus standaard formaat valt onder de IETF license policy.
Dat was de libvpx API/codeimplementatie. Dat is een google open source implementatie van de VP8 codec.maar aangezien VP8 een copyleft licentie had
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 hAl op dinsdag 15 januari 2013 13:58]
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.De specificatie is beschikbaar en er is een technologiebelofte voor implementerende partijen.
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.Dat is een google open source implementatie
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...
http://9292.nl/ heeft dit ook al een tijdje. Dit werkt ook zonder de api 
[Reactie gewijzigd door maarud op dinsdag 15 januari 2013 08:48]
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?
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 dinsdag 15 januari 2013 10:23]
Google's filosofie is dat *alles* de browser in gaat.
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.
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).
WebRTC bijvoorbeeld schept bijvoorbeeld de mogelijkheid om voice en video calls op te zetten zonder specifieke apps (zoals bijv. Skype).
Dit was al mogelijk vanaf minimaal versie 23 geloof ik..?
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)
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?
'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!
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!
Kun je een voorbeeld noemen? Ik lees namelijk dat de spraakafdeling gewoon overgenomen is door Scansoft.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
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
