viernes, 25 de marzo de 2011

Probando el reconocimiento de voz de Chromium/Chrome

Para muchos fue una sorpresa el encontrar, poco después de la salida de Firefox 4, la noticia de que Google había lanzado su navegador con reconocimiento de voz para los elementos HTML aún sabiendo que el estándar no se ha aprobado. En este post aclaro algunos puntos sobre esta nueva funcionalidad.


No hay que sorprenderse. Aunque soy un fiel fan de Mozilla y su navegador Firefox, no puedo evitar sorprenderme y emocionarme con los grandes pasos en cuanto a innovación que da el equipo de Chromium, de lo cual se beneficia enormemente Google Chrome. Y es que Chromium y Chrome son casi lo mismo, uno con más imagen corporativa que el otro. Esto me da la posibilidad de probar en Debian lo que los usuarios de Chrome reciben en cada nueva versión o acutalización de su navegador.

En esta ocasión lo que más me llamó la atención no fue el soporte a transformaciones CSS con aceleración por hardware, ni por el cambio de logo (aunque les quedó muy bien, ¡felicidades!). Fue por el soporte parcial a la API de entrada de audio hablado para los campos de texto; el borrador ni siquiera está completo y ya están implementando funcionalidades ¡con muy buenos resultados experimentales!

Para verlo funcionando basta con navegar (en Chromium/Chrome, obviamente) a una página que tenga cajas de texto con el atributo x-webkit-speech en los que el navegador mostrará un pequeño micrófono dentro del texto. Al hacerle click se activa el reconocimiento de voz y aparece un cuadro con un medidor de sonido y un botón para Cancelar. En ese momento podemos hablarle al navegador usando un micrófono conectado a la entrada de audio del PC y, una vez que dejamos de hablar, el contenido del campo de texto se reemplaza por la transcripción de lo que hayamos dicho.

Puede que al principio el reconocimiento no sea muy bueno, ya que a veces aparecerán palabras que no son correctas, es natural. El reconocimiento de voz depende de muchos factores, como el ruido ambiental, la calidad del micrófono, o la vocalización. Incluso teniendo estos factores a favor, es posible que el resultado no sea el esperado, y esto puede deberse a que para ello el programa está haciendo uso de la misma tecnología que se utiliza en Youtube para transcribir el audio de los videos. Esta tecnología no es perfecta, pero hace un trabajo más que descente y suficiente para que las personas capten la idea del mensaje.

Averiguando por la red encontré que alguien había ya hecho mi tarea: la de investigar si el audio era procesado en la máquina o se enviaba a los servidores de Google, donde el poder de procesamiento supera en varios órdenes de magnitud lo que mi modesta máquina puede ofrecer. Según Mike Pultz, del blog Don't Panic, es el segundo caso, y en su post hace un buen trabajo experimental con esta funcionalidad directamente con los servidores de Google. Por lo visto éstos no sólo devuelven el primer resultado de la transcripción, sino varios posibles resultados con sus niveles de confianza, lo que permitiría, por ejemplo, ofrecer varias correcciones alternativas a lo que se habla cuando el usuario no quede satisfecho (¿Usted dijo: "Hakuna Patata"? Otros: "Hakuna Matata", "Hakuna Rattata").

Conociendo esto me pude a jugar con el lenguaje. Ya que mi sistema está en español, las páginas de prueba de esta funcionalidad no me reconocían al hablarles en inglés. Específicamente en este demo tenía que pronunciar los nombres de los colores en inglés pero con pronunciación y acento español (latino). Mirando la página del W3C con el Editor's Draft de Google sobre la API de voz encontré que los elementos deben tener un lenguaje de entrada en forma de atributo para ayudar al sistema de reconocimiento de voz en su tarea. Chromium entonces utiliza esa información y la envía junto con el archivo de audio a los servidores que lo procesan de acuerdo al lenguaje especificado, como apuntó Mike Pultz en su post. En cualquier caso se utiliza el atributo lang, ya sea en el XML del documento, en un elemento padre del input, o en el mismo input, siguiendo las reglas BCP47 para nombrado de los lenguajes estandarizados por la norma ISO 639.

Poniéndolo de manera simple:

<form>
<table>
<tr>
<th>Espa&ntilde;ol</th>
<th>Ingl&eacute;s:</th>
</tr>
<tr>
<td><input type="text" x-webkit-speech lang="es" placeholder="Mary ten&iacute;a un corderito"/></td>
<td><input type="text" x-webkit-speech lang="en" placeholder="Mary had a little lamb"/><td>
</tr>
<tr>
<td colspan="2" > Pruebe primero a dictar los textos sugeridos. <br/>Luego pruebe a dictar el texto en espa&ntilde;ol<br/> en el campo en ingl&eacute;s y viceversa.</td>
</tr>
</table>
</form>

Que da lo siguiente:










Español Inglés:

Pruebe primero a dictar los textos sugeridos.
Luego pruebe a dictar el texto en español
en el campo en inglés y viceversa.
Habiendo hecho este experimento, ¿qué opinan del nuevo Chromium/Chrome? Personalmente creo que el cuadro que indica que se está esperando a que la persona hable debería tener una bandera u otro indicador que indicara el idioma de entrada.

1 comentario:

Leon S. Kennedy dijo...

Por lo visto, el traductor es lo que me llama la atencion, que Google, nos siga impresionando más, ese Pobre Transleitor es una "basura" total.

Buscar entradas