Esta práctica se distribuye a través del repositorio GitHub Práctica 2, y una parte de su gestión se realizará mediante esta web de trabajo colaborativo. Al contrario que Git, GitHub se gestiona completamente desde un entorno gráfico bastante intuitivo. Además, está razonablemente documentado, tanto internamente, mediante sus Guías de GitHub, como externamente, mediante infinidad de tutoriales, guías y vídeos disponibles gratuitamente en internet.

Para cargar los ficheros en su ordenador personal debe seguir los pasos siguientes:

• Abra una cuenta GitHub para gestionar esta y el resto de prácticas del curso.

• Cree un repositorio GitHub con el contenido inicial de la práctica (sólo debe hacerlo uno de los integrantes del grupo de laboratorio, cuya página GitHub actuará de repositorio central del grupo):

  • Acceda la página de la Práctica 2.
  • En la parte superior derecha encontrará el botón Fork. Apriételo y, después de unos segundos, se creará en su cuenta GitHub un proyecto con el mismo nombre (P2). Si ya tuviera uno con ese nombre, se utilizará el nombre P2-1, y así sucesivamente.

• Habilite al resto de miembros del grupo como colaboradores del proyecto; de este modo, podrán subir sus modificaciones al repositorio central:

  • En la página principal del repositorio, en la pestaña ⚙️Settings, escoja la opción Collaborators y añada a su compañero de prácticas.
  • Éste recibirá un email solicitándole confirmación. Una vez confirmado, tanto él como el propietario podrán gestionar el repositorio, por ejemplo: crear ramas en él o subir las modificaciones de su directorio local de trabajo al repositorio GitHub.

• En la página principal del repositorio, localice el botón Branch: master y úselo para crear una rama nueva con los primeros apellidos de los integrantes del equipo de prácticas separados por guion (fulano-mengano).

• Todos los miembros del grupo deben realizar su copia local en su ordenador personal.

  • Copie la dirección de su copia del repositorio apretando en el botón Clone or download. Asegúrese de usar Clone with HTTPS.

  • Abra una sesión de Bash en su ordenador personal y vaya al directorio PAV. Desde ahí, ejecute:

    git clone dirección-del-fork-de-la-práctica

  • Vaya al directorio de la práctica cd P2.

  • Añada la etiqueta origin a su copia del repositorio. Esto es útil para facilitar los push y pull al repositorio original:

    git remote add origin dirección-del-fork-de-la-práctica

  • Cambie a la rama fulano-mengano con la orden:

    git checkout fulano-mengano

• A partir de este momento, todos los miembros del grupo de prácticas pueden trabajar en su directorio local del modo habitual.

  • También puede utilizar el repositorio remoto como repositorio central para el trabajo colaborativo de los distintos miembros del grupo de prácticas; o puede serle útil usarlo como copia de seguridad.

  • Cada vez que quiera subir sus cambios locales al repositorio GitHub deberá confirmar los cambios en su directorio local:

    git add .
    git commit -m "Mensaje del commit"

    y, a continuación, subirlos con la orden:

    git push -u origin fulano-mengano

• Al final de la práctica, la rama fulano-mengano del repositorio GitHub servirá para remitir la práctica para su evaluación utilizando el mecanismo pull request.

  • Vaya a la página principal de la copia del repositorio y asegúrese de estar en la rama fulano-mengano.
  • Pulse en el botón New pull request, y siga las instrucciones de GitHub.

Responda, en este mismo documento (README.md), los ejercicios indicados a continuación. Este documento es un fichero de texto escrito con un formato denominado markdown. La principal característica de este formato es que, manteniendo la legibilidad cuando se visualiza con herramientas en modo texto (more, less, editores varios, ...), permite amplias posibilidades de visualización con formato en una amplia gama de aplicaciones; muy notablemente, GitHub, Doxygen y Facebook (ciertamente, 👀).

En GitHub. cuando existe un fichero denominado README.md en el directorio raíz de un repositorio, se interpreta y muestra al entrar en el repositorio.

Debe redactar las respuestas a los ejercicios usando Markdown. Puede encontrar información acerca de su sintáxis en la página web Sintaxis de Markdown. También puede consultar el documento adjunto MARKDOWN.md, en el que se enumeran los elementos más relevantes para completar la redacción de esta práctica.

Recuerde realizar el pull request una vez completada la práctica.

• Etiquete manualmente los segmentos de voz y silencio del fichero grabado al efecto. Inserte, a continuación, una captura de wavesurfer en la que se vea con claridad la señal temporal, el contorno de potencia y la tasa de cruces por cero, junto con el etiquetado manual de los segmentos.

• A la vista de la gráfica, indique qué valores considera adecuados para las magnitudes siguientes:

• Incremento del nivel potencia en dB, respecto al nivel correspondiente al silencio inicial, para estar seguros de que un segmento de señal se corresponde con voz.

Para estar seguros de que un segmento de la señal corresponde a voz y no silencio, el incremento de nivel de potencia debería ser aproximadamente de unos 40dB.

• Duración mínima razonable de los segmentos de voz y silencio.

El valor mínimo razonable nos parece que debería ser de t = 0,5s aproximadamente.

• ¿Es capaz de sacar alguna conclusión a partir de la evolución de la tasa de cruces por cero?

No hemos sido capaces de generar la gráfica de la tasa de cruces por cero(zcr) despues de muchos intentos.

• Complete el código de los ficheros de la práctica para implementar un detector de actividad vocal tan exacto como sea posible. Tome como objetivo la maximización de la puntuación-F TOTAL.

Hemos empezado creando 2 nuevos estados de la máquina para mejorar el rendimiento del programa. Primero, tenemos el estado "ST_MAYBE_VOICE" que representa a los
frames que podrían ser voz después de estar en silencio. Segundo, tenemos el estado "ST_MAYBE_SILENCE" que representa todo lo contrario, los frames que podrían ser silencio después de estar en voz.

Para estos cambios hemos definido las variables k0, k1 y k2, que representan umbrales de potencia. Si estás en ST_SILENCE y superas k1, entras en el estado ST_MAYBE_VOICE y, desde aquí, si superas k2 pasas al estado ST_VOICE. En cambio, si lo reduces por debajo de k1, vuelves al estado ST_SILENCE. Si estás en el estado ST_VOICE y reduces por debajo de k2, pasas al estado ST_MAYBE_SILENCE y, desde aquí, si reduces todavía más por debajo de k1, pasas al estado ST_SILENCE pero, si superas el estado k2, vuelves al estado ST_VOICE. También hemos tenido en cuenta la tasa de cruces por cero para confirmar que realmente estemos tratando de voz o silencio, por ejemplo, para las consonantes fricativas.

En el estado ST_INIT, hemos creado 6 constantes y hemos variado sus valores hasta obtener el resultado más óptimo. Tenemos alfa1 y alfa2, que sirven para calcular los umbrales de k1 y k2. También tenemos min_voice y min_silence, que marcan el mínimo de frames que hay que estar en los estados MAYBE para cambiar de estado y que no se considere un silencio esporádico en el habla, por ejemplo. Por último, hemos tomado los 10 primeros frames de silencio para hacer una media y calcular un valor de k0 más aproximado a la realidad.

• Inserte una gráfica en la que se vea con claridad la señal temporal, el etiquetado manual y la detección automática conseguida para el fichero grabado al efecto.

• Explique, si existen. las discrepancias entre el etiquetado manual y la detección automática.

Existen claras claras discrepancias entre el etiquetado manual y el automático. Podemos observar a través de wavesurfer que estas se deben a unos niveles bastante altos de potencia que aparecen al inicio o al final de algunos segmentos de voz. Podríamos concluir que, al menos para este caso, el umbral de decisión entre voz y ruido no es lo suficientemente alto para conseguir eliminar cualquier discrepancia perceptible.

• Evalúe los resultados sobre la base de datos db.v4 con el script vad_evaluation.pl e inserte a continuación las tasas de sensibilidad (recall) y precisión para el conjunto de la base de datos (sólo el resumen).

• Si ha desarrollado el algoritmo para la cancelación de los segmentos de silencio, inserte una gráfica en la que se vea con claridad la señal antes y después de la cancelación (puede que wavesurfer no sea la mejor opción para esto, ya que no es capaz de visualizar varias señales al mismo tiempo).

• Si ha usado docopt_c para realizar la gestión de las opciones y argumentos del programa vad, inserte una captura de pantalla en la que se vea el mensaje de ayuda del programa.

• Indique a continuación si ha realizado algún tipo de aportación suplementaria (algoritmos de detección o parámetros alternativos, etc.).

• Si lo desea, puede realizar también algún comentario acerca de la realización de la práctica que considere de interés de cara a su evaluación.

Recuerde comprobar que el repositorio cuenta con los códigos correctos y en condiciones de ser correctamente compilados con la orden meson bin; ninja -C bin. El programa generado (bin/vad) será el usado, sin más opciones, para realizar la evaluación ciega del sistema.