En otras palabras, el usuario que trata de hacer login con su DNI o username graba una frase para que el sistema determine si esa voz se corresponde con ese usuario. Debemos llegar a un valor numérico que represente el parecido de esa voz grabada con las voces que tenemos guardadas en nuestra base de datos. Si el parecido es alto, se permite el acceso al usuario, y en caso contrario no.
Pero, ¿cómo llegamos desde una grabación de voz hasta un número? El reconocimiento por voz es un campo que está en pleno desarrollo, produciéndose avances con técnicas y algoritmos más fiables cada poco tiempo. Nosotros no vamos a usar las mejores herramientas que existen hoy en día, ya que su complicación supera el nivel de la práctica.
Nuestra prioridad es obtener resultados, sin importar por ahora tener excelente fiabilidad. Las técnicas empleadas pueden modificarse y refinarse en el futuro, que será lo que haremos si tenemos tiempo para perfeccionar la práctica.
En este post vamos a describir cada una de las fases principales que toman parte en el entrenamiento y autentificación en nuestro sistema. El diagrama es el siguiente, y previsiblemente se irá completando con más información a medida que entremos en detalle.
 |
| https://bubbl.us/ |
Verificación vs identificación
Antes de continuar, hay que aclarar el uso del reconocimiento. El usuario escribirá un DNI o username propio y además hará la grabación. Esto significa que su voz será contrastada con las que le correspondan en la base de datos.
Por eso, estrictamente hablando, nuestra práctica realiza una verificación biométrica. Frente a este caso está en el que tienes que decidir qué usuario es a partir de una muestra de voz, sin contar con otro dato como el DNI. Esto sería identificación.
Dicho esto, ya podemos pasar a materia.
Adaptación
Hay un pequeño detalle a tener en cuenta, que es el cómo ha sido grabada la pista de voz. Sobre esto mismo era la pregunta que nos hizo el profesor Roberto Barra en la presentación.
Tal y como dijimos ya, WAMI graba a 22050 Hz. Gracias a SoX, the Swiss Army knife of sound processing programs, podemos adaptar la señal grabada a 16 u 8kHz. También aprovechamos para cambiar el formato a RAW.La opción de modificar el archivo de Flash que maneja el micrófono partiendo de los archivos .as y compilándolo con Flex fue estudiada e intentada. Sin embargo, al no conseguir resultados, nos decantamos por SoX.
 |
| Arriba tenemos un fragmento de voz grabado por el plugin de captura y abajo tenemos el mismo framento después de haberlo tratado con SoX. Ampliando, se puede observar un menor número de muestras en el segundo. |
Parametrizado
Como alguno ya sabrá o supondrá, lo que el sistema almacena es información sobre voz. No se guardan los ficheros de audio. Por tanto, para realizar cualquier análisis de una grabación, lo primero es extraer datos de ella. Esta operación la hacemos con SPro (MIT License).
La grabación se divide en fragmentos del orden de 20-30 ms, solapando cada uno con los contiguos unos 10-15 ms. A continuación se calcula la FFT con 256 puntos. Luego se pasa por un banco de filtros. Típicamente son unos 24 filtros MFCCs y luego al hacer la DCT es que se obtiene un vector de 12 dimensiones.
 |
| Imagen de la documentación de SPro 5.0 |
Adicionalmente se añade una dimensión más (la nº 13) que contabiliza la energía total de la señal en la trama. Es especialmente útil a la hora de eliminar silencios, que tienen muy poca energía. También es conveniente añadir otras 13 dimensiones que sean la derivada de las anteriores (velocidad de cambio) y 13 más que sean la segunda derivada (aceleración). Las primeras se llaman Δ (delta) y las segundas ΔΔ (delta-delta).
 |
| Estructura de un vector con información de una trama. Imagen de la documentación de SPro 5.0 |
Obviamente, el proceso real es más complicado que el descrito aquí, ya que también se pasa por un pre-énfasis y por una normalización. Toda la información está en la documentación de SPro.
Una vez se ha extraído la información de la señal, el fichero de audio no volverá a ser necesario y en su lugar se usarán los coeficientes obtenidos.
ALIZE
Ahora pasamos a usar ALIZE, una plataforma para autentificación biométrica bajo LGPL (es decir, que se puede usar tanto para desarrollar software libre como propietario).
ALIZE está compuesto de dos partes:
- Librería de bajo nivel ALIZE
- Toolkit de alto nivel LIA_RAL
 |
| Página web de ALIZE |
Por tanto, trabajaremos sobre LIA_RAL, que se apoya sobre ALIZE, la librería de bajo nivel. Partimos de una serie de ejecutables para realizar todas las operaciones siguientes, pero cuya configuración debe especificarse y marca la diferencia entre un buen o un mal sistema.
Detección de silencios
El primer paso es normalizar los vectores de coeficientes generados por SPro. A continuación, se procede a analizar la dimensión 13 de dichos vectores, que recordemos que corresponde al nivel total de energía de la señal en cada trama.
Se establece un umbral de este campo bajo el cual se considera que en la trama no hay voz. Este umbral es necesario porque la señal nunca será nula debido al ruido ambiente y del micrófono. Las tramas consideradas silencio se descartan de los análisis posteriores ya que si no tienen voz, no contienen información útil.
Lo interesante es que este umbral no es un valor fijo, sino que se genera un modelo dependiendo de la entrada compuesto de gaussianas. Lo habitual es usar dos gaussianas, y a partir de ellas se establece un umbral. Parámetros con los que controlar el comportamiento de esta parte son, por ejemplo, los relacionados con la varianza.
Tras este proceso se efectúa una nueva normalización en la que las tramas "silenciosas" ya se han descartado.
 | |||
| El resultado final es un fichero con los intervalos de tiempo en los que hay voz. Este primer análisis no es suficientemente preciso, pero modificando los parámetros de configuración se podrán conseguir mejores resultados |
Entrenamiento
Si hemos realizado el proceso anterior con un número considerable de grabaciones de voz de una persona, lo que podemos hacer es combinar la información de todas ellas para generar un modelo que la represente.
 | |||||
| La mezcla de estas gaussianas aproxima el comportamiento de la función. |
De este modo, cada dimensión queda modelada por una mezcla de gaussianas, de las que se guarda su media y varianza en un vector. Este proceso se repetirá para cada una de las demás dimensiones.
Para el entrenamiento de un modelo de una persona hacen falta múltiples grabaciones, cuantas más, más fiable. Hablamos de muchas grabaciones, muchas más de las que cualquier usuario esté dispuesto a hacer, por lo que existen técnicas para reducirlo.
Para poder realizar la autentificación sin que sea necesario que cada usuario grabe su voz muchísimas veces, usaremos un Universal Background Model (UBM), que es un modelo genérico muy bien entrenado con grabaciones de muchas personas.
Verificación
El modelo general UBM se ha hecho componiendo varias pistas de audio de muchas personas. Ahora llega el momento de la verdad, comprobar si el sistema es capaz de verificar la identidad de una persona con una nueva grabación.
¿Cómo conseguir esto a partir de un modelo UBM en el que hay datos de muchas personas diferentes? Lo que se hará es adaptar el UBM a esa persona a partir de sus grabaciones de entrenamiento y la estimación MAP (máximo a posteriori). Así se consigue que el usuario tenga que hacer solamente unas cuantas grabaciones para entrenar al sistema.
La nueva grabación debe pasar todos los procesos previamente descritos hasta que se genere un modelo de gaussianas de ella. Este modelo será comparado con el UBM adaptado, obteniéndose así un índice numérico de lo parecidos que son el vector que modela la voz grabada para entrar al sistema y el modelo adaptado a esa persona a partir del UBM.
Este es el resultado buscado y que determina si la grabación de voz produce un acierto o un fallo. Según este valor, dejaremos o no pasar al usuario dentro de nuestra página web.
 |
| Imagen del ordenador |
La autentificación biométrica por voz es mucho más compleja que lo descrito aquí. Existen más técnicas, por ejemplo el normalizado de la solución, que describiremos según las vayamos implementando.
El próximo post del tema mostrará los primeros resultados que hemos obtenido, en los que el modelo construido no es nada fiable pero algo es capaz de diferenciar.