GRADO DE INGENIERÍA DE TECNOLOGÍAS Y …lorien.die.upm.es/juancho/pfcs/BER/TFG_Borja.pdf ·...
55
GRADO DE INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE TELECOMUNICACIÓN TRABAJO FIN DE GRADO DESARROLLO DE UN SISTEMA DE APRENDIZAJE AUTOMÁTICO PARA LA SÍNTESIS DE TEXTOS CON VOCES EMOCIONALES BORJA ESCANILLA RODRÍGUEZ 2016
Transcript of GRADO DE INGENIERÍA DE TECNOLOGÍAS Y …lorien.die.upm.es/juancho/pfcs/BER/TFG_Borja.pdf ·...
GRADO DE INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE
TELECOMUNICACIÓN
TRABAJO FIN DE GRADO
DESARROLLO DE UN SISTEMA DE APRENDIZAJE AUTOMÁTICO PARA LA
SÍNTESIS DE TEXTOS CON VOCES EMOCIONALES
BORJA ESCANILLA RODRÍGUEZ
2016
GRADO EN INGENIERÍA DE TECNOLOGÍAS Y
SERVICIOS DE TELECOMUNICACIÓN
TRABAJO FIN DE GRADO
Título: Desarrollo de un sistema de aprendizaje automático para la síntesis de
textos con voces emocionales
Autor: D. Borja Escanilla Rodríguez
Tutor: D. Roberto Barra Chicote
Departamento: Ingeniería Electrónica (IEL)
MIEMBROS DEL TRIBUNAL
Presidente: D. Rubén San Segundo Hernández
Vocal: D. Juan Manuel Montero Martínez
Secretario: D. Pedro José Malagón Marzo
Suplente: D. José Manuel Pardo Muñoz
Los miembros del tribunal arriba nombrados acuerdan otorgar la calificación de:
………
Madrid, a de Julio de 2016
UNIVERSIDAD POLITÉCNICA DE MADRID
ESCUELA TÉCNICA SUPERIOR DE INGENIEROS DE TELECOMUNICACIÓN
GRADO DE INGENIERÍA DE TECNOLOGÍAS Y SERVICIOS DE TELECOMUNICACIÓN
TRABAJO FIN DE GRADO
DESARROLLO DE UN SISTEMA DE APRENDIZAJE AUTOMÁTICO PARA LA
SÍNTESIS DE TEXTOS CON VOCES EMOCIONALES
BORJA ESCANILLA RODRÍGUEZ
2016
RESUMEN
En el presente Trabajo de Fin de Grado se pretende desarrollar un sistema en el lenguaje de
scripting Python que partiendo de la polaridad emocional obtenida mediante peticiones HTTP
a la API WEB de la empresa Textalytics pueda aprender de los gustos del usuario analizando
el uso que se le da al mismo de forma que la emoción sintetizada mediante la interpolación de
varios modelos vocálicos mejore con respecto a la proporcionada por la API y sea cada vez
más acorde a los gustos del usuario. Se analizará tanto su uso para textos comunes como para
el caso particular de la red social de "microblogging" Twitter. En el primero de los casos se
utilizará tanto un filtro sigmoide para añadir cohesión emocional entre las distintas frases del
mismo como un regresor lineal para relacionar la polaridad obtenida mediante las consultas a
la API de Textalytics con el score de síntesis proporcionado por el usuario. En el caso de la red
social únicamente se usará el regresor lineal debido a la poca longitud de los textos a tratar.
Para demostrar la validez o no de los algoritmos utilizados en el sistema, se realizará una
evaluación ciega con un determinado número de personas ajenas al desarrollo y se analizará la
realimentación que proporcione este uso.
SUMMARY
In the present end-of- deegree project, an attemp is made to develop a system in scripting
language Python which, on the basis of the emotional polarity obtained by HTTP requests to
the API WEB of the company Textalytics, is able to learn from user tastes by analizing how
it is used. So that, the emotion synthetized by the interpolation of several vocalics models is
expected to improve compared to the one proportionated by the API, being increasingly more
adjusted to user tastes. Its use will be analyzed both for common textes and for the particular
case of the “microblogging” social net Twitter. In the first case, it will be used both a sigmoid
filter, to add emotional cohesion between the different sentences of the text, and a linear
regressor, to relate the polarity obtained by requests to Textalystics’ API with the synthesis
score proporcionated by the user. In the case of the social net, it will just used the linear
regressor due of the less length of the textes that will be processed.
In order to show if the algorithms used in the system are valid or not, a blind evaluation with
some people unconnected with the development will be carried out, analyzing the feedback
proportionated by this use.
PALABRAS CLAVE
Síntesis de habla, Aprendizaje Automático, Regresor Lineal, Python, Interpolación. Voz
Emocional.
KEYWORDS
Speech-Technology, Automatic Learning, Linear Regresor, Python, Interpolation,
Emotional Voice.
ÍNDICE DEL CONTENIDO
1. INTRODUCCIÓN Y OBJETIVOS .................................................. 1
1.1. Introducción ........................................................................................................... 1
1.2. Objetivos ................................................................................................................ 1
2. DESARROLLO ............................................................................ 3
2.1. Estado del arte ....................................................................................................... 3
2.1.1. Síntesis Concatenativa .................................................................................... 4
2.1.2. Síntesis articulatoria ....................................................................................... 5
2.1.3. Síntesis por formantes .................................................................................... 6
2.1.4. Síntesis mediante modelos ocultos de markov .............................................. 6
2.1.5. Síntesis de voz emocional .............................................................................. 7
2.2. Elementos utilizados para la realización del proyecto .......................................... 8
2.3. Obtención de datos de la api rest ......................................................................... 10
2.4. Síntesis de voz mediante la interpolación de dos modelos ................................. 12
2.5. Desarrollo del programa de proposito general .................................................... 14
2.5.1. Manual de la aplicación ................................................................................ 15
2.5.2. Regresor Lineal ............................................................................................ 16
2.5.3. Filtro Sigmoidal ............................................................................................ 18
2.6. Desarrollo del programa específico para la red social twitter ............................ 22
3. RESULTADOS ........................................................................... 30
3.1.1. Comentarios de los usuarios ......................................................................... 38
4. CONCLUSIONES Y LÍNEAS FUTURAS ....................................... 39
4.1. Conclusiones ........................................................................................................ 39
4.2. Líneas futuras ...................................................................................................... 39
5. ANEXO DE TÉRMINOS ............................................................. 41
6. BIBLIOGRAFÍA ......................................................................... 45
1
1. INTRODUCCIÓN Y OBJETIVOS
1.1. INTRODUCCIÓN
Debido a que las redes sociales actualmente están pasando por un auge sin precedentes
en el que una gran parte del tiempo que un usuario medio pasa en internet es
consultándolas, se hace necesario hacerlas más accesibles mediante el diseño de sistemas
que permita a las personas con requerimientos especiales que no puedan usar un
dispositivo de presentación de datos de forma visual participar de ellas de forma activa
mediante la síntesis de los textos que el resto de usuarios ha compartido.
En este trabajo fin de grado intentaremos dar un paso más haciendo esta presentación de
datos acústica un poco más humana detectando la emoción adecuada del texto a sintetizar
y permitiendo al usuario del sistema proporcionar la realimentación necesaria para que
este aprenda de sus gustos y sea cada vez más fiel a estos, en lo que esperamos que sea
una mejora considerable en su experiencia de uso.
Usaremos la red social de microblogging Twitter por dos razones. La primera es porque
es una red social orientada principalmente a la publicación de textos. La segunda es que
debido al tamaño reducido de estos textos (llamados tweets y limitados a 140 caracteres
cada uno), la emoción será más fácil de analizar y por tanto de entrenar un regresor que
sea capaz de mejorar esa predicción.
Este proyecto fin de grado es una colaboración con el proyecto europeo Simple4All.
1.2. OBJETIVOS
El principal objetivo de este trabajo es que el sistema desarrollado pueda detectar la
emoción del texto y lo categorice en términos de bueno o malo de forma ponderada. Una
vez conseguido este score emocional, lo sintetizáremos mediante la interpolación de
varios modelos vocálicos del mismo actor de forma que el usuario pueda escucharlo y
valorarlo y nos otorgue la realimentación necesaria para ajustarnos a sus preferencias.
Para ponderar la emoción, partiremos de la información que nos proporciona la API
REST de la empresa MeaningCloud (anteriormente llamada Textalytics) e intentaremos
mejorarla mediante la aplicación de un filtro sigmoidal que relacione las ponderaciones
de las frases del mismo texto para darle más “coherencia emocional”. A su vez, usando
la realimentación que el usuario nos dé, le aplicaremos un regresor lineal de forma que
cada vez que se ejecute podamos sintetizar textos de forma más acorde a los gustos de
cada usuario.
2
Nuestro objetivo final será la realización de cierto número de experimentos con el sistema
desarrollado que nos permita verificar o refutar la hipótesis de que este tipo de algoritmos
es capaz de mejorar la predicción obtenida de forma significativa, suponiendo un primer
paso para la inclusión de sistemas de síntesis de voz emocional en los principales
programas y portales web.
Esperamos poder mejorar la interacción en Internet de aquellas personas con diversidad
funcional de forma que cada vez puedan participar más y mejor de los gestores de
noticias, los foros y las redes sociales, así como de aquellas personas que prefieran
participar de ellas de esta forma.
3
2. DESARROLLO
2.1. ESTADO DEL ARTE
Un sintetizador de voz o sintetizador de habla es un sistema software o hardware que
mediante la aplicación de determinados algoritmos es capaz de convertir un texto escrito
en un mensaje oral. Su principal objetivo es facilitar a las personas con una reducción
atípica de su capacidad visual su interacción con determinados sistemas informáticos o
electrónicos.
Para analizar la calidad de un sintetizador de voz debemos analizar tres parámetros:
1. El rango de mensajes que puedan generar: Consideraremos que es mejor un
sintetizador que debido a la base de datos que posea o a los algoritmos de
generación utilizados sea capaz de convertir de texto a voz un mayor número de
textos.
2. Parecido a la voz humana: Debemos procurar que el resultado lo más parecido
posible a una voz real. En caso contrario, los audios generados con ese sintetizador
sonarán más metálicos que humanos.
3. Inteligibilidad: En un buen sintetizador, la persona que escuche los audios no debe
realizar un esfuerzo adicional por entender el mensaje pronunciado.
La creación de un audio sintético pasa por dos procesos: el primero es la preparación del
texto para su interpretación y el segundo es la síntesis propiamente dicha.
El primer proceso es conocido como proceso de etiquetado, de generación de etiquetas o
de “labeling”. Consistirá entre otras cosas en convertir los caracteres no pronunciables
en su representación correspondiente cuando fuera necesario. Por ejemplo, si
estuviéramos leyendo la dirección de correo electrónico “[email protected]”;
cambiar el símbolo “@” por la palabra “arroba”, el número “1” por la palabra “uno” y
leer “dominio punto com” en vez de usar el punto como separador de frases.
El proceso de generación de etiquetas, por último, deberá hacer corresponder cada palabra
con su representación en el espacio de unidades vocálicas del sintetizador. Por ejemplo,
convertir todo el texto a fonemas.
4
Figura 2.1 Label para [email protected]
En la imagen 2.1 podemos ver la salida del preprocesador del sintetizador utilizado para
la dirección de correo electrónico “[email protected]”. Este nos ha entregado a su
salida un fichero que contiene todos los datos para que el proceso de síntesis pueda
continuar. Cabe observar como, efectivamente, ha realizado la conversión de los números
y los caracteres “@” y “.” a su transcripción fonética. Además, podemos fijarnos en que
puede diferenciar vocales con acento o sin él, etiquetando a las primeras además con un
“1” al final.
Actualmente, como principales tecnologías para la realización de sintetizadores de voz
podemos destacar las que se detallan a continuación.
2.1.1. SÍNTESIS CONCATENATIVA
Los sintetizadores que usan esta tecnología realizan concatenaciones de ficheros que
contienen audios que han sido grabados con anterioridad con el fragmento de texto
requerido. Un buen sintetizador debería poseer tantos audios como sean necesarios para
poder cubrir con ellos todas las opciones posibles para realizar la síntesis de cualquier
texto. Si estos audios se corresponden con todos los fonemas del lenguaje a utilizar, o con
todas las combinaciones posibles de estos, el sintetizador será capaz procesar cualquier
texto en ese lenguaje, pero a costa de otorgar un resultado más artificial.
La unidad seleccionada como base del sintetizador es un parámetro muy importante.
Cuanto mayores sean las unidades, menores concatenaciones tendrá que efectuar el
sintetizador y mejor calidad obtendrá. No obstante, si escogemos las palabras como
unidad fundamental del sintetizador no podemos controlar la acentuación de frase y
quedará “poco humana”. Además de que en este caso habría que grabar todas las palabras
existentes en el diccionario aumentando mucho el tamaño
5
El tamaño de la unidad básica más extendido actualmente es el difono, el cual empieza
en el valor medio de un fonema y acaba en el valor medio del siguiente. De esta forma,
se reducen mucho los audios a grabar dado el bajo número de difonos que presenta un
idioma. Además, puede mejorarse el proceso de creación de una voz analizando las
cadenas de fonemas que no sean posibles en ese idioma y evitando su grabación.
SÍNTESIS DE SELECCIÓN DE UNIDADES
Este método consiste en la segmentación del texto a generar en frases, palabras, sílabas,
fonemas, difonos y fonos para posteriormente concatenar los elementos correspondientes
para formar el texto entero. La principal ventaja de este sistema es su naturalidad, pero
se crea a costa de una mayor base de datos de audios pregrabados, por lo que tiene un alto
coste de espacio en disco.
SÍNTESIS DE DIFONOS
Un difono es una transición entre dos fonemas consecutivos, considerándose que duran
desde la mitad del primero hasta la mitad del segundo. Para poder usar esta tecnología se
deben tener grabados tantos difonos como combinaciones de fonemas tenga el idioma. El
resultado es un modelo de voz que ocupa poco espacio con respecto a la selección de
unidades, pero a costa de empeorar su calidad y generar una voz más metálica.
SÍNTESIS DE DOMINIO ESPECÍFICO
Es un caso particular en el que no estamos desarrollando un sintetizador para propósito
general, sino para una aplicación específica como, por ejemplo, un contestador
automático. Debido a esto los audios de la base de datos suelen ser más largos, lo que
aumenta la calidad del sistema total. Como contraparte, no será capaz de sintetizar un
texto arbitrario sino únicamente unas pocas combinaciones de frases o palabras. Sin
embargo, este tipo de sintetizadores ocupa muy poco espacio en disco y son muy sencillos
de implementar.
2.1.2. SÍNTESIS ARTICULATORIA
Este método para síntesis de habla intenta simular el canal oral humano y los movimientos
de este. Por tanto, para su desarrollo no se usan audios pregrabados. Proporcionan una
calidad altísima, pero son muy difíciles de diseñar y de controlar sus parámetros.
6
2.1.3. SÍNTESIS POR FORMANTES
Parten de un audio que simula las vibraciones de las cuerdas vocales al que hacen pasar
por filtros que modelan el tracto vocal.
Usan como fuente primaria de generación tonos y ruido. Los tonos pretenden imitar la
vibración de las cuerdas vocales, mientras que el ruido pretende imitar el proceso de
apertura del canal vocal humano. Los modelos actuales de este sistema hasta permiten
variar parámetros como la frecuencia fundamental del habla o la amplitud.
Para simular el tracto vocal usan un filtro lineal que evoca los efectos de la faringe, la
boca y los labios. Este filtro se caracteriza por sus polos. Cada par de polos complejos
conjugados crea un pico en la representación espectral del filtro, al cual se le denomina
formante. Los ceros del filtro obedecen a los elementos del tracto humano que absorben
el sonido los cuales son importantes, por ejemplo, en las vocales nasales.
Por norma general, un modelo de voz creado mediante síntesis por formantes tendrá más
margen de maniobra que uno creado mediante el método de concatenación, ofreciendo
más parámetros variables que permiten ajustar sus características a nuestra finalidad.
Como contrapunto, su calidad suele ser menor que la de las síntesis por concatenación.
2.1.4. SÍNTESIS MEDIANTE MODELOS OCULTOS DE MARKOV
Este método para la síntesis de voz se basa en cadenas de Markov. Se conoce como
cadena de Markov a los procesos estocásticos discretos en los que, conociendo el estado
actual y los estados anteriores, la probabilidad del siguiente estado sólo dependa de los N
estados anteriores. En este caso, se dice que la cadena de Markov tiene orden N.
En un modelo oculto de Markov los estados no son conocidos, pero si son observables
aquellas variables que dependen del estado. No obstante, podemos obtener más de una
salida diferente para cada estado de la cadena, estando estas definidas por una función de
probabilidad para cada estado. Por tanto, el modelo oculto de Markov quedaría definido
por:
Las probabilidades de transición entre estados.
Distribución de probabilidades para el estado inicial.
Matríz de densidad de probabilidad de salidas para cada estado.
Este modelo se usará para modelar por separado la frecuencia fundamental del sonido, la
duración y la distribución espectral de este. Para poder utilizar estos modelos se partirá
de una base de datos de audios pregrabados (mucho menor que las bases de datos de otros
métodos de síntesis) con sus correspondientes etiquetas. En ellas, se expresará de la forma
más fidedigna posible el contenido del audio de forma que en el entrenamiento del
7
sistema se puedan obtener los diferentes modelos para cada uno de los parámetros de la
voz. Cada parámetro contará con su propio modelo obtenido mediante la aplicación de
ciertos algoritmos y mediante la aplicación de árboles de decisión.
Para realizar la generación del audio, el sistema habrá dividido el texto convirtiéndolo en
unidades prosódicas y escoge los modelos del entrenamiento que mejor caractericen esa
unidad en su contexto (en qué sílaba se encuentra, en qué palabra, si está en una
interrogación, si esta al final de la frase…).
De las principales ventajas de este sistema con respecto al sistema de selección de
unidades se encuentra la posibilidad de efectuar transformaciones en este pudiendo llegar
a modificar ciertas características como la emoción o el estilo del discurso.
Además, al basar la voz en sus parámetros y no en sus audios estos son interpolables
pudiendo realizar mezclas de voces y de estilos. Es por ello que este es el sistema que se
utiliza en este proyecto.
2.1.5. SÍNTESIS DE VOZ EMOCIONAL
Uno de los principales problemas con los que se encuentran los sintetizadores de voz
actuales es que, independientemente de la emoción del mensaje, este es interpretado con
una emoción neutra, ya sea este un mensaje completamente eufórico como un mensaje
de enfado. Por mucho que mejoremos su inteligibilidad, si el sintetizador no es capaz de
expresar emociones, el resultado siempre será artificial.
Recurriendo al Diccionario de la Real Academia Española, se define la emoción como
“una alteración del ánimo intensa y pasajera, agradable o penosa, que va acompañada de
cierta conmoción somática”. Por tanto, el principal desafío de la generación de voz
emocional es estudiar esas alteraciones y su implicación en la variación del habla humana,
de forma que puedan ser modeladas por parámetros variables en el sintetizador a
desarrollar. Se ha identificado una cantidad considerable de parámetros, pero los tres más
importantes son la frecuencia fundamental, la velocidad de habla y la calidad de voz.
La frecuencia fundamental (o pitch) es la frecuencia a la que vibran las cuerdas vocales.
Empíricamente se ha observado que una elevación en la magnitud de la frecuencia
fundamental obedece a una excitación emocional. También debe analizarse la relación
entre el valor mínimo y el máximo de la frecuencia. A mayor distancia entre estos dos
valores mayor será la carga emocional del mensaje. De la misma manera, una variación
discontinua de este parámetro obedece a una emoción negativa mientras que una positiva
tendrá variaciones continuas y suaves.
8
En relación a la velocidad, cuanto más positiva sea la emoción expresada, mayor será la
velocidad del habla y menores las pausas entre oraciones. De forma contraria, las
emociones tristes se caracterizan por ser más pausadas y de un ritmo más lento.
En la calidad de la voz podemos incluir parámetros como la intensidad de la onda acústica
o la distribución espectral de la energía.
En la realización de este trabajo fin de grado, únicamente distinguiremos dos emociones
(sin tener en cuenta la emoción neutra) que, aunque identifiquemos como alegría y
tristeza, serían mejor catalogadas como “la emoción positiva” y la “emoción negativa”
pues un mensaje con una emoción de angustia sería catalogado como “emoción negativa”
sin ser necesariamente tristeza.
2.2. ELEMENTOS UTILIZADOS PARA LA REALIZACIÓN
DEL PROYECTO
A continuación, se detalla todo aquel programa que se ha utilizado para poder realizar el
proyecto y se introduce ligeramente el papel que ha tenido en este.
VirtualBox: Es un programa que actualmente desarrolla la empresa Oracle. Su
utilidad es la de poder virtualizar sistemas operativos de forma que puedan usarse
como un programa más de la máquina anfitrión. Cuenta con dos versiones en
función de la licencia que usen. La primera se denomina VirtualBox OSE y es de
código abierto. La segunda es Oracle VM VirtualBox, que es de código cerrado
pero gratuita para uso no empresarial. Esta es la que hemos utilizado, en su versión
5.0.10.
Debian: Debian es una distribución GNU/Linux creada por Ian Murdock, el cual
a su vez escribió el manifiesto Debian, en el que postulaba que la distribución sería
siempre de código abierto y seguiría el espíritu del proyecto GNU/Linux. Se ha
recurrido a ella por necesitar una distribución GNU/Linux para ejecutar, entre
otros, los binarios de festival. La versión utilizada es la 7.10.
Gnome Classic: Es el entorno de escritorio por defecto en Debian. Se ha escogido
además para asegurar su total compatibilidad con GTK+, la librería utilizada para
la interfaz gráfica.
Python: Es un lenguaje de scripting multiparadigma que soporta orientación a
objetos, herencia múltiple, tipado dinámico… Fue creado en Guido Van Rossum
que liberó su primera versión en 1991. Su filosofía lo convierte en un lenguaje
sencillo de escribir y entender. Es un lenguaje interpretado, lo que lo hace más
lento que los compilados como C, pero se ha priorizado su facilidad de uso sobre
su velocidad para la realización del proyecto. La versión utilizada es la 2.7 siendo
esta la que actualmente está más extendida debido a que es una versión de
transición entre Python 2 y Python 3 compatible con ambas versiones. Mediante
este lenguaje hemos manejado el flujo principal del sistema así como la creación
de la GUI (Interfaz Gráfica de Usuario).
NINJA-IDE: Es el IDE (Integrated Development Environment) utilizado.
Permite tanto la modificación del código como la visualización de la salida
estándar de este. Se ha utilizado la versión 2.3.
9
GTK+: Es un conjunto de librerías que permiten crear una Interfaz Gráfica de
Usuario en los lenguajes de programación más importantes como C/C++, Java y
Python. Actualmente goza de una gran popularidad, ya que es en el que están
desarrollados los entornos de escritorio más utilizados de GNU/Linux como
Gnome Shell, Gnome classic o KDE.
Glade: Es un programa para la creación de interfaces gráficas haciendo uso de
GTK+ de forma declarativa. Esto es, generando un fichero xml de donde el script
de Python leerá las propiedades y ubicación de cada elemento de la interfaz
gráfica, así como “listener event” de los elementos que lo requieran. Se ha
utilizado la versión 3.12.1.
Tweepy: Es una librería para el acceso a la red social Twitter, la cual va a ser la
red social de ejemplo en este proyecto. Está escrita en Python y participa de su
filosofía de facilidad de uso, por lo que es perfecta para el objetivo que nos hemos
marcado.
GCC/G++: Suite de herramientas para la compilación de programas en C/C++.
Se ha tenido que usar la versión 4.4.7 debido a que es la última compatible con la
versión de festival modificada.
TCSH: Es un Shell de Unix basado a su vez en csh. Se ha utilizado para la
ejecución de los scripts de interpolación.
SOX: Es un conjunto de utilidades que permiten convertir ficheros de audio de
unos formatos a otros utilizado para reformatear los audios de salida del
sintetizador de voz
AWK: Lenguaje de programación cuya finalidad es manejar datos representados
en texto. En este proyecto ha sido utilizado para introducir alguna variación a los
ficheros con extensión lab antes de acabar el proceso de síntesis.
PyAudio: Librería de tratamiento de audio de Python. Ha permitido añadir a la
interfaz gráfica la posibilidad de reproducir los textos sintetizados.
Octave: Programa de código abierto que interpreta scripts en lenguaje M. Se ha
utilizado para la creación de las gráficas que nos han permitido interpretar los
datos de retroalimentación de los usuarios.
LibreOffice: Suite ofimática de código abierto. Se ha utilizado el programa Calc
para la conversión de los datos en formato CSV a formato de Hoja de Cálculo de
forma que sea más entendible por un humano.
Matplotlib: Librería de Python dedicada a la creación de gráficas. Se ha utilizado
para generar de forma automática las gráficas de evolución del error para cada
experimento.
El sintetizador que se ha utilizado durante el desarrollo de este proyecto es Festival. Este
es un programa de código abierto que fue desarrollado por la universidad de Edimburgo
en su Centro de Investigación de Tecnologías del Lenguaje y que ha adquirido bastante
importancia, llegando a ser incluido en los repositorios de paquetes de propósito general
de las distribuciones GNU/Linux más comunes, debido a la gran cantidad de programas
que hacen uso de él. Se desarrolló en C++ e incluye los idiomas inglés y castellano de
forma oficial, aunque existen versiones que permiten usarlo para otros idiomas. Se basa
en la interpretación de comandos para su funcionamiento. Si quisiéramos que leyera un
texto una vez iniciado el programa deberíamos usar el siguiente comando:
festival> (SayText "Hello World!")
10
No obstante, para el sistema desarrollado en este trabajo no lo utilizaremos de esta forma,
sino llamando a los comandos de GNU/Linux que exporta tras su instalación.
Otra de las principales ventajas del proyecto Festival es la creación de Festvox, una suite
de herramientas que cuenta con la misma licencia de código abierto y que pretende
facilitar el proceso de creación de una voz que podrá ser utilizada en festival. Esta
facilidad es otro de los factores que ha permitido al proyecto Festival expandirse como
se ha expandido.
2.3. OBTENCIÓN DE DATOS DE LA API REST
El análisis de la emoción corre a cargo de la API REST de la empresa MeaningCloud
mediante el envío de un HTTP Request en el que debemos especificar los siguientes
campos:
1. Key: clave de uso. Es un número único que la empresa distribuye a cada usuario
y que representa el número de licencia que posee.
2. Of: output format. Formato en el que queremos que se nos entreguen los datos.
Se escogió JSON debido a que presenta menos variaciones que XML, lo que
aseguraba mejor su compatibilidad con el resto del sistema. Además, es un
formato mucho más legible para humanos.
3. Lang: el idioma del texto a analizar. En este proyecto hemos trabajado siempre
con textos en español.
4. Txt: texto del que solicitamos el análisis
5. Model: modelo que queremos que se use. Dependiendo de la versión del programa
desarrollado que estemos usando, este campo podrá indicar si queremos que use
el modelo de propósito general o el modelo específico para Twitter.
6. Verbose: indicamos al servidor si queremos activar el modo verbose o no. Para
nuestro estudio todos los datos son devueltos con este modo desactivado, por lo
que por defecto este campo valdrá siempre “no”.
La respuesta del servidor de MeaningCloud contendrá en el formato solicitado los
siguientes campos:
1. Status: objeto JSON contenido en el objeto principal que incluye campos sobre
el estado de la licencia, el número de peticiones que puede realizar el usuario hasta
que esta acabe, el número de palabras analizadas… El único campo de este objeto
que tomaremos en consideración será el indicador “msg”, el cual nos informa de
si ha podido realizarse el análisis o no y, en su caso, las causas por las que este no
ha sido realizado.
2. Model: nos asegura que el texto ha sido analizado con el modelo con el que
pretendíamos analizarlo.
11
3. Score: número decimal con precisión de centésimas y con un rango de -1 a 1 en
el que se corresponde el máximo valor negativo con la emoción más negativa, el
cero con la emoción neutra y el valor más positivo con la emoción más positiva.
Este campo será el más importante de todos y el que usaremos para realizar las
síntesis.
4. Score tag: representación textual del campo anterior. Hace corresponder el score
con las etiquetas P+, P, NEU, N, N+ o NONE. Al ser redundante con la
información, únicamente la usaremos cuando su valor sea NONE, ya que en este
caso informa de que el texto no tiene emoción alguna (como por ejemplo en el
texto “¡Hola!”) y no devuelve score. En este caso, con el fin de poder realizar la
sintetización del texto, consideraremos como si el servidor hubiera devuelto el
score 0.
5. Agreement: toma únicamente dos valores con los que se nos informa de si el texto
tiene coherencia emocional
6. Subjectivity: toma dos posibles valores indicando si el texto es objetivo o
subjetivo. Para el análisis que vamos a realizar este campo nos es indiferente, ya
que solo vamos a tomar la emoción del texto independientemente de que esta sea
provocada por un hecho objetivo o no.
7. Confidence: devuelve un número entero entre 0 y 100 indicando la seguridad que
tiene la API sobre si la información que nos está devolviendo es correcta o no.
Para los textos que se han usado en la evaluación del sistema se ha asegurado que
este valor fuera como mínimo del 75 por ciento.
8. Irony: informa de si el texto es irónico o no. Para facilitar el análisis emocional
se ha procurado escoger textos a la hora de la evaluación que no fueran irónicos.
9. Sentimented entity list: objeto JSON con la lista de entidades que ha analizado
para obtener el score. Analiza grupos nominales y adjetivos por separado. Es un
análisis muy detallado para nuestro objetivo, por lo que no se tendrá en cuenta.
10. Sentimented concept list: objeto JSON con la lista de conceptos encontrados.
Por ejemplo, lugares o fechas. A la hora de la síntesis no es relevante, por lo que
no se tendrá en cuenta.
11. Sentence list: objeto JSON que contiene el mismo análisis para cada frase más el
análisis especifico de estas. Los campos añadidos a los ya comentados son:
a. Inip: posición de inicio de la frase
b. Endp: posición final de la frase. Junto con el anterior nos va a permitir ver
donde empieza y acaba cada una de forma que podamos separarlas y
sintetizarlas por separado.
c. Bop: indica el principio de un párrafo.
d. Score: el análisis de la emoción para cada frase por separado. Será este
valor el que usemos para sintetizar cada frase.
Con el fin de poder reutilizar la mayor cantidad de código entre los distintos programas
desarrollados, se ha procurado que el código sea lo más modular posible. De esta parte
de la ejecución del programa se encargará el módulo “cliente.py”, que podrá ser
importado desde cualquiera de los módulos principales del proyecto.
12
2.4. SÍNTESIS DE VOZ MEDIANTE LA INTERPOLACIÓN DE
DOS MODELOS
Como hemos comentado anteriormente, el proceso para sintetizar un texto consta de dos
partes principales: la generación de etiquetas y la generación del audio.
Para generar las etiquetas vamos a usar el script “txt2lab.sh” proporcionado por el Grupo
de Tecnología del Habla. Podremos hacer uso de él mediante el emulador de terminal del
sistema operativo usando el comando:
>bash tex2lab.sh local.conf frase.txt directorio_etiquetas
siendo local.conf el fichero de configuración del script en el que especificamos valores
como la ruta en la que hemos instalado Festival o las variables de entorno de las que
depende la ejecución del script. El texto para el que generará las etiquetas será el que
encuentre en el fichero frase.txt, el cual deberá estar obligatoriamente en codificación
ISO-LATIN-1. Dado que la mayoría de sistemas usan ISO-LATIN-9 o UTF-8, como es
el caso de API REST de MeaningCloud, será necesario reconvertir la codificación
mediante el comando iconv del sistema operativo GNU/Linux. Es posible que el
conversor se encuentre caracteres en el texto a tratar que no puedan ser trasladados a la
codificación ISO-LATIN-1 debido a que no existan en esta. Este es el caso, por ejemplo,
del símbolo del euro, de los símbolos de fracciones o de ciertos caracteres de escape no
imprimibles.
En el caso de que el usuario haya introducido un texto que incluya uno de los posibles
caracteres problemáticos, se le notificará mediante un aviso en la salida estándar del
sistema. No obstante, en la batería de textos que se usará para la realización de los
experimentos, se han cambiado parte de ellos por su representación textual donde sea
posible (por ejemplo, el símbolo “€” se ha sustituido por la palabra “euro”) y el resto de
caracteres especiales se evitarán siempre, de forma que el usuario no deba preocuparse
por su presencia. Como comentamos antes, esta es una labor que debería hacer el
generador de etiquetas, el cual sí sustituye parte de los caracteres problemáticos. No
obstante, no puede trabajar con los caracteres que estén excluidos de su codificación de
trabajo, por lo que ha debido hacerse manualmente antes de la llamada al programa.
Una vez generadas las etiquetas, las guardará en formato de texto plano (también con
codificación ISO-LATIN-1) en el directorio que se le ha especificado y con la extensión
lab. Al generador de etiquetas deberá llamársele una vez que se haya hecho la consulta
al servidor de MeaningCloud y tengamos el texto separado en frases de forma que
podamos generar una etiqueta para cada frase y sintetizar cada una por separado con su
score correspondiente.
El siguiente paso será la generación de los audios. Para ello, debemos tener en nuestro
directorio de trabajo para cada voz que queramos tener disponible tres modelos: uno
13
completamente negativo, uno completamente positivo y uno neutro. En este caso, para
generar un audio con un score positivo de 0.33, siendo esta emoción un tercio neutra y
dos tercios positiva, interpolaremos en esta proporción los modelos neutro y positivo.
Para el caso en el que el score sea de -0.33, tendremos que interpolar un tercio del modelo
neutro y dos tercios del modelo negativo.
Si quisiéramos hacer el sistema con menos carga en lo que a ocupación de disco se refiere,
podríamos disponer únicamente de dos modelos, siendo estos el más positivo y el más
negativo, e interpolarlos al 50% cada uno para obtener una emoción neutra. No obstante,
el resultado será mucho peor que utilizando un tercer modelo neutro. De la misma forma,
si no tenemos problema en usar algo más de espacio en disco, podríamos disponer de más
modelos con distintas emociones entre la neutra y la positiva o negativa de manera que
siempre interpolemos entre los dos modelos más cercanos a la emoción que queramos
representar. De esta forma el resultado será mucho más natural, pero se complica el
cálculo de cuánto porcentaje tomar de cada modelo ya que este factor dependerá del score
que queramos obtener y de los scores emocionales que represente cada modelo
disponible. Para el caso que tratamos aquí tres modelos emocionales son suficientes.
Además, de esta forma, el score obtenido del objeto JSON podrá usarse de forma casi
directa en el siguiente paso.
Para ejecutar la síntesis, partiremos de las etiquetas ya generadas para cada frase del texto
completo que estarán disponibles en el directorio que le especificamos al script
“txt2lab.sh”. Estos ficheros estarán nombrados como sentenceN.lab, siendo N la posición
que ocupa la frase en el texto. El script encargado de esta parte del procese será syn-
interpolate-v2.sh, el cual también ha sido proporcionado por el Grupo de Tecnología del
Habla.
Antes de poder ejecutar el script, deberemos modificar en el directorio que lo contiene el
fichero ratio.txt que contiene el tanto por uno de uso del primer modelo que le
especifiquemos; siendo, por supuesto, lo que falte para llegar a uno la fracción que
representa el uso del segundo modelo. Esta ratio deberá escribirse siempre en positivo,
por lo que para sintetizar una frase con una emoción cualquiera escribiremos en este
fichero el valor absoluto del score a sintetizar y usaremos siempre el modelo neutro como
primer modelo y el modelo emocional (positivo o negativo) como segundo modelo. Para
la llamada a este script utilizaremos el siguiente comando en el emulador de terminal:
>tcsh syn-interpolate-v2.sh voz_neutral voz_emocional lab_dir out_dir
Siendo voz_neutral y voz_emocional los directorios donde tengamos almacenados estos
modelos, lab_dir el directorio donde el generador de etiquetas las haya guardado y out_dir
el directorio donde queremos que nos devuelva los audios generados. Entre las llamadas
al script será necesario actualizar el fichero ratio.txt con el score de la frase siguiente.
El formato de audio utilizado será WAV, el cual es un formato sin compresión y sin
pérdidas, lo que nos permitirá trabajar con la mayor calidad posible (sin tener en cuenta
14
la pérdida de calidad que hayamos obtenido en la grabación de los modelos). Es un
formato muy poco extendido por la cantidad espacio que ocupa en disco, pero que no
obstante, puede ser leído por casi todos los reproductores de audio. En nuestro caso, para
reproducirlo recurriremos cuando sea necesario a la librería PyAudio, de forma que
podamos integrar la reproducción con la interfaz gráfica desarrollada.
Una vez ejecutados ambos scripts, nos encontraremos con tantos ficheros con extensión
wav como frases hayamos tratado. El último paso será concatenar todos estos ficheros
para obtener uno único que contenga la síntesis del texto entero. Para ello, deberemos
tener instalado el programa sox el cual está disponible en todos los repositorios de las
distribuciones GNU/Linux más populares.
Para ejecutar esta concatenación llamaremos al comando de la siguiente manera:
>sox sentence1.wav sentence2.wav … sentenceN.wav … allText.wav
Tras su ejecución obtendremos el fichero allText.wav con, por fin, el resultado de la
síntesis del texto completo.
2.5. DESARROLLO DEL PROGRAMA DE PROPOSITO
GENERAL
El primer programa que se ha desarrollado pretende ser un analizador para cualquier tipo
de texto y no solo para una red social. Este programa cuenta con un cuadro de entrada
para que el usuario pueda escribir el texto a analizar y este después del intercambio HTTP
correspondiente mostrará el score del texto completo, además de la información necesaria
para la síntesis emocional de cada frase por separado. A saber: el score emocional
predicho por MeaningCloud, el score que el usuario entrega como realimentación, y el
score que se usará verdaderamente como síntesis independientemente de los otros dos.
Además, incorpora una casilla para activar o desactivar el filtro sigmoidal y un selector
de voz que permite escoger entre tres voces masculinas y tres voces femeninas.
15
Figura 2.2: Programa General sin sigmoide
En la captura de pantalla 2.2 podemos ver la existencia de los tres campos y cómo el
usuario puede modificar a su gusto el score de síntesis. Cuando sintetiza una frase con un
score nuevo, este se guarda (reemplazando el último score de esa frase si ya existiera) de
forma que pueda pasarse por un regresor lineal que ajuste la predicción a los gustos del
usuario y que aumente su fidelidad según se va usando.
2.5.1. MANUAL DE LA APLICACIÓN
La aplicación desarrollada cuenta con una interfaz gráfica desarrollada mediante el
programa Glade. Este programa permite diseñar una GUI definiendo sus elementos y los
listener events necesarios, exportando un fichero XML para que el programa en Python
lo interprete.
La primera línea del script es el shebang, el cual en entornos UNIX le indica al sistema
operativo con qué interprete debe ejecutar el fichero y que, en nuestro caso, apunta al
intérprete de Python. Por tanto, para ejecutarlo el usuario simplemente deberá hacer doble
clic en el fichero GUI.py.
El usuario podrá introducir en el cuadro de entrada aquel texto que desee sintetizar, sea
este de cualquier longitud. Una vez escrito el texto, dándole al botón de aceptar, el sistema
leerá el texto y ejecutará una petición HTTP GET contra el servidor web indicándole
según los parámetros ya explicados el modelo, el contenido y el idioma del texto a tratar.
16
El servidor deberá responder con un objeto JSON del cual obtendrá el score general del
texto, así como su división en frases y el score emocional de cada frase. Una vez ha
separado la información en frases, el código pintará en la interfaz gráfica de forma
programática tantas filas como frases haya obtenido. Cada una de estas filas contendrá:
Una etiqueta de texto con el contenido de la frase.
Un campo de texto con el score de MeaningCloud el cual no es editable.
Un campo de texto editable para que el usuario nos otorgue realimentación sobre
su preferencia emocional.
Un campo de texto editable para indicar el score con el que se quiere sintetizar
cada frase por separado.
Una vez que el usuario ha ajustado estos valores a su gusto podrá pulsar la casilla filter.
La activación de esta casilla leerá los valores del segundo campo de texto y les aplicará
el regresor lineal del apartado 2.5.3 devolviendo su salida en los campos de texto del
score de síntesis. Al desactivarlo deshará esta operación copiando los scores de usuario
El selector situado a la derecha del botón del regresor lineal permite al usuario escoger
entre cualquiera de las seis voces disponibles para sintetizar. El sistema dispone de tres
voces masculinas y tres voces femeninas. El escoger una u otra voz no afectará de ninguna
manera al cálculo y al ajuste de los parámetros de los filtros.
Por último, cuando el usuario haya ajustado los scores, seleccionado la voz y la presencia
de filtro o no, deberá pulsar el botón de TTS. Este botón realizará la síntesis completa del
texto, tanto la generación de etiquetas como la generación de los audios. Por último,
mirará si para ese texto ya se ha incluido un valor en el regresor lineal. En caso de que no
lo hubiera, lo creará; en caso contrario, el valor será sustituido por el último que se usase.
Todos los datos generados por este programa se guardarán en ficheros de texto en su
carpeta de ejecución. Cada carpeta contendrá el texto separado en oraciones, el score de
cada oración y del texto en general, así como sus etiquetas y sus audios.
2.5.2. REGRESOR LINEAL
Este filtro pretende aprender de los gustos que el usuario nos asegura tener mediante la
realimentación que nos entrega.
Este filtro está caracterizado la función:
𝑓(𝑥) = 𝑚𝑥 + 𝑛
Siendo esta la correspondiente a una recta y cuyos parámetros de pendiente y corte con
el eje de ordenadas se vayan ajustando cada cierto número de ejecuciones. Para ello, cada
vez que el usuario otorgue realimentación sobre su experiencia con el sistema, se
almacenará en un fichero tanto el punto recibido de la consulta a la API de MeaningCloud
como el punto que el usuario considera correcto. Cuando el filtro sea llamado, procederá
17
a ordenar todos los puntos que tenga almacenados según su variable x y a agruparlos en
parejas tal que el primero se empareje con el último, el segundo con el antepenúltimo y
así sucesivamente.
Una vez emparejados todos los puntos, se calculará la pendiente como la media de las
pendientes de las rectas que forman cada pareja de puntos y la ordenada en el origen como
la media de las ordenadas menos la nueva pendiente multiplicada por la media de las x.
Es decir, siendo n el número de parejas de puntos:
𝑚 = 𝑚�̂�
𝑛 = �̂� − 𝑚 ∗ �̂�
Tras un tiempo de uso del sistema la función del regresor suele acabar como la imagen
siguiente en el que se ajusta un pequeño offset hacia la zona positiva y la pendiente se
vuelve tal que se evitan los extremos recortando el dominio del score filtrado. De estos
resultados se hablará con más detalle en el apartado de conclusiones.
Este método de ajuste de rectas es conocido como el método de mínimos cuadrados.
La implementación en Python de este regresor lineal se hace en el módulo
regresor_lineal.py, cuya función más importante es la siguiente, la cual calcula los nuevos
parámetros del regresor:
def get_recta(puntos):
puntos = ordenar_puntos(puntos)
if len(puntos) % 2 != 0:
18
puntos = puntos + (puntos[len(puntos) / 2 + 1],)
puntos = ordenar_puntos(puntos)
n_pares = len(puntos) / 2
acum_pendiente = 0.0
for i in range(0, n_pares):
acum_pendiente = acum_pendiente + get_pendiente(puntos[i],
puntos[i + n_pares])
pendiente = acum_pendiente / n_pares
acum_y = 0.0
acum_x = 0.0
for p in puntos:
acum_x = acum_x + p.get_x()
acum_y = acum_y + p.get_y()
media_x = acum_x / len(puntos)
media_y = acum_y / len(puntos)
ordenada_origen = media_y - pendiente * media_x
return pendiente, ordenada_origen
2.5.3. FILTRO SIGMOIDAL
Este filtro pretende dar cohesión emocional a las distintas frases del texto a sintetizar. Es
decir, acercará los scores entre ellos para evitar grandes saltos entre la síntesis de una
frase y la siguiente.
Figura 2.3 Ejemplo pre filtrado
En la imagen 2.3 podemos ver un ejemplo de scores de un posible texto. Definimos los
siguientes valores:
�̂�: 𝑚𝑒𝑑𝑖𝑎 𝑎𝑟𝑖𝑡𝑚é𝑡𝑖𝑐𝑎 𝑑𝑒 𝑙𝑜𝑠 𝑠𝑐𝑜𝑟𝑒𝑠
∆𝑛𝑃: 𝑣𝑎𝑟𝑖𝑎𝑐𝑖ó𝑛 𝑑𝑒𝑙 𝑠𝑐𝑜𝑟𝑒 𝑛 𝑒𝑛 𝑓𝑢𝑛𝑐𝑖ó𝑛 𝑑𝑒𝑙 𝑠𝑐𝑜𝑟𝑒 𝑛 − 1
𝑝𝑛: 𝑠𝑐𝑜𝑟𝑒 𝑑𝑒 𝑙𝑎 𝑚𝑢𝑒𝑠𝑡𝑟𝑎 𝑛 − 𝑒𝑠𝑖𝑚𝑎
19
Figura 2.4 Scores obtenidos tras el filtrado
A su vez, en la imagen 2.4 se muestran los scores a la salida del filtro sigmoidal, siendo
estos mucho más cercanos a la media y, por tanto, mucho más cercanos entre sí.
Cada score se ha calculado como:
𝑘𝑛 = �̂� + (𝑝𝑛 − �̂�) ∗ 𝐹(‖∆𝑛𝑃‖)
Y siendo F la función sigmoidal a aplicar definida como:
𝐹(𝑥) = 1
(1 + 𝑒𝐵(𝑥−𝑀))1𝑣
Los valores para sintonizar el filtro son B = 5, M = 0.5 y v = 3, los cuales de momento
son fijos, pero a vistas de futuro debería implementarse el mismo mecanismo que en el
regresor lineal para que el sistema pudiera aprender también de los gustos del usuario y
cohesionar los textos de forma cada vez más precisa.
Con estos valores, la función F(x) tiene la función de transferencia que se muestra en la
imagen siguiente:
20
Figura 2.5: Representación de la función F(x)
De esta forma, el nuevo score será la suma de la media de todos los scores más un valor
directamente proporcional a la diferencia del score original con respecto a la media y
proporcional al valor devuelto por la función F(x).
Para el ejemplo de distribución de scores de la figura 2.3 obtendríamos lo siguiente:
Figura 2.6: Comparación valores pre y post filtrado
En azul se muestran los scores originales y en rojo los scores post filtrado. Se observa
claramente una tendencia de acercamiento a la media, y en algunas muestras, como en
la número cuatro, hasta un cambio de la polaridad de síntesis, pasando de ser levemente
21
negativa a ser levemente positiva. Su efecto se nota también especialmente en la muestra
5, la cual tenía un score de menos uno siendo este el más negativo posible. Tras el
filtrado obtiene un valor de -0.4, lo que evita picos exagerados entre frases consecutivas.
Figura 2.8: Programa general con sigmoide
En la imagen 2.8 se muestra cómo, al pulsar la casilla filter, se activa automáticamente el
filtro con los valores de los campos de score del usuario como valores de entrada y se
modifican los scores de síntesis con los valores de su salida. De esta forma, el filtro
sigmoidal no afecta a la realimentación que da el usuario y no le obliga a tener en cuenta
sus efectos antes de modificar su valor.
Este filtro se implementa en el módulo filtro.py quedando el código que lo genera
bastante sencillo debido a la librería math de Python:
#!/usr/bin env python
# Filtro
# Grupo de Tecnología del habla (GTH-DIE-UPM)
# www-gth.die.upm.es
# @version 1.0
# @author Borja Escanilla Rodríguez
from math import *
def filtrar_scores( scores):
B = 5.0
22
M = 0.5
v = 3.0
media = 0.0
for s in scores:
media = media + float(s)
media = media / len(scores)
d = tuple()
d = d + (float(scores[0]) - media,)
for index in range(1, len(scores)):
temp = float(scores[index]) - float(scores[index - 1])
d = d + (temp,)
F = tuple()
for element in d:
denom = (1 + exp(B * (abs(element) - M)))
denom = denom ** (1 / v)
F = F + (1 / denom,)
k = tuple()
for index in range(0, len(F)):
temp = media + (float(scores[index]) - media) * F[index]
temp = round(temp, 2)
k = k + (temp,)
return k
2.6. DESARROLLO DEL PROGRAMA ESPECÍFICO PARA LA
RED SOCIAL TWITTER
La red social Twitter es una plataforma de microblogging que permite a los usuarios
compartir entre las personas que se hayan suscrito a sus contenidos (en adelante,
seguidores) textos de hasta 140 caracteres acompañados si se quisiera de algún elemento
de apoyo como puede ser una foto, una ubicación, un hipervínculo o una encuesta. A cada
uno de estos textos se le llama tweet o, dependiendo de la API utilizada para tratarlos,
status, siendo la primera de las opciones la más extendida.
La razón principal de haber escogido esta red social para el estudio es la longitud de los
textos a tratar, lo que acortará los tiempos de generación de audios y permitirá tratar un
volumen mucho mayor de tweets en cada experimento. Además, esta longitud asegura
que las frases también sean cortas y simples, sin muchas oraciones subordinadas que
dificulten el análisis de cada uno de los tweets.
Debido también a la corta longitud, en este programa no se hará uso del filtro sigmoide,
ya que la presencia de varias frases en 140 caracteres es poco común. De esta forma
aplicaremos sólo el regresor lineal y podremos observar mejor sus resultados. El código
del regresor lineal será el mismo que el utilizado en el programa de propósito general.
La primera versión de este programa hace uso de la librería tweepy para descargarse los
últimos 50 tweets del homeline (lista de todos los tweets que hayan publicado las personas
a las que se esté suscrito ordenadas según su timestamp) del usuario. Para cada tweet
mostraremos varios campos de información: el nickname del autor, su foto de perfil y el
23
contenido textual que haya compartido. Además, incluiremos para cada uno dos campos
de texto, siendo el primero de sólo lectura y conteniendo el score devuelto por
MeaningCloud; y siendo el segundo el valor del score que se usará para sintetizar la frase.
El valor por defecto será el que devuelve el regresor lineal tras el análisis de los gustos
del usuario. Incluye, además, un botón de llamado TTS que ejecutará los scripts de
Python necesarios para la síntesis del texto con el score pedido. Una vez que este botón
haya sido pulsado, se activarán los siguientes, siendo estos: el botón de play, que hace
uso de la librería pyaudio para reproducir el fichero; el botón de play neutral, que
reproduce el mismo texto pero con una emoción neutra; el selector de preferencia en el
que el usuario indicará cuál de los dos audios le ha gustado más; y el botón de salvar, que
guardará los datos para su posterior análisis y añadirá el par de puntos a la base de datos
del regresor lineal. Este programa, al igual que el anterior, se ha desarrollado de forma
declarativa usando un fichero XML generado con el programa de diseño Glade, que es
interpretado por la librería PyGTK+.
El fichero XML sólo define la estructura de la aplicación gráfica para una sola página,
siendo necesario repintar la interfaz cuando el usuario avanza a la siguiente. Por tanto, es
importantísimo para poder guardar los datos adecuadamente que la interfaz pinte también
datos no visibles al usuario pero que deberá entregar al listener de los botones para poder
saber a qué tweet se refiere. Uno de estos datos es, por ejemplo, el identificador único del
tweet.
Para poder conectar correctamente con la aplicación de Twitter es necesario contar con
una cuenta de desarrollador en esa plataforma. Para poder autenticar al usuario, la librería
hace uso del protocolo OAuth, el cual se basa en dos pares de claves. El primer par consta
del consumer key y del consumer secret, los cuales identifican a la aplicación. El segundo
par consta del access key y del access secret, los cuales identifican al usuario dentro de
la aplicación. Hay que tener cuidado con estos cuatro valores pues en caso de ser copiados
permitirían a cualquier persona leer o publicar en la cuenta del usuario.
Para simplificar el desarrollo de la interfaz gráfica y dado que no necesitamos que el
usuario ejecute más de una acción a la vez, todo el programa será ejecutado bajo el mismo
thread. Esta circunstancia llevará al bloqueo del programa tras la realización de una
acción de interfaz gráfica hasta que esta haya concluido. Es decir, el programa se
bloqueará completamente al pulsar un botón hasta que la acción realizada por ese botón
concluya. Si bien debería lanzarse un nuevo thread cada vez que el usuario realice una
acción, ejecutando el programa de esta manera evitará que intente pulsar dos veces el
botón de TTS y por tanto se llame por segunda vez a un script sobreescribiendo los
ficheros de configuración mientras la primera ejecución todavía hace uso de ellos.
A continuación, se describe con detalle la función de los botones del sistema:
Botón TTS:
Inicia el regresor lineal pasándole como parámetro la carpeta donde se
estén guardando los datos de la aplicación. Esto será necesario para poder
actualizar sus valores cuando se le introduzca el nuevo valor añadido por
el usuario.
24
Obtiene del campo oculto el identificador único del tweet que se está
tratando.
Actualiza el log del programa con el timestamp.
Desplaza la ejecución del programa al directorio donde se almacenan los
datos del tweet al que se refiere su identificador.
Lee ambos scores de la interfaz gráfica y los almacena en sendos ficheros
de texto.
Genera las etiquetas para la síntesis.
Genera los audios con voz emocional a partir de las etiquetas y los
concatena con el comando sox.
Genera los audios con voz neutra a partir de las etiquetas y los concatena
de la misma manera.
Activa el resto de botones de la aplicación correspondientes a ese tweet.
Elimina los archivos intermedios necesarios para la síntesis.
Botón Play:
Obtiene el identificador único del tweet de los parámetros ocultos de la
interfaz gráfica.
Actualiza el log del programa con la hora de reproducción del audio con
voz sentimental.
Llama a la librería PyAudio para su reproducción.
Botón Neutral:
Obtiene el identificador único del tweet de los parámetros ocultos de la
interfaz gráfica.
Actualiza el log del programa con la hora de reproducción del audio con
voz sentimental.
Llama a la librería PyAudio para su reproducción.
Selector de preferencia: Permite al usuario seleccionar que audio le ha gustado
más, si el audio con voz sentimental o el audio con voz neutral. Además, cada vez
que se produzca un cambio de selección, actualizará el log con el nuevo valor y el
timestamp a pesar de que el usuario no haya pulsado Save.
Botón Save:
Obtiene el identificador del tweet a partir de los parámetros ocultos.
Obtiene la preferencia del usuario indicada en el selector y la guarda en un
fichero de texto.
Obtiene el valor del score de MeaningCloud y el proporcionado por el
usuario y los ingresa en el conjunto de valores del regresor lineal.
Actualiza el CSV con los datos del último tweet.
Esta versión del programa también nos obliga a ser muy cuidadosos con el tema de la
codificación de caracteres, pues empiezan a entrar tres en juego: la de MeaningCloud, la
de Twitter y la que necesita el sintetizador. Estas son ISO-LATIN-9, UTF-8 e ISO-
LATIN-1 respectivamente.
En resumen, el usuario para cada tweet deberá escoger el score que quiere probar a
sintetizar, darle a TTS y escucharlo tanto en su versión emocional como neutra. Si cree
que ese es el score correcto deberá seleccionar su preferencia y darle a Save. En caso
contrario deberá sintetizar con el nuevo score que considere hasta que encuentre el score
correcto.
25
Figura 2.9: Primera versión del programa de Twitter
En la imagen 2.9 se observa que los tweets se van mostrando en páginas de diez elementos
cada una, disponiendo la interfaz gráfica de usuario de dos botones para ir a la página
anterior o a la página siguiente. De esta forma, cuando se pulse el botón de página
siguiente se hará una llamada al regresor lineal para que actualice sus parámetros antes
de presentar los siguientes diez elementos.
También podemos darnos cuenta de la cantidad de la cantidad de textos especiales que
salen en una ejecución cualquiera. Por ejemplo, el uso del carácter “arroba” más el
nickname para mencionar a alguien, el uso del carácter “#” para incluir un hashtag o el
uso de la cadena “RT” para hacer un retweet. La solución a estos casos ha sido:
Para la arroba: Cambiar el carácter y el nickname del usuario por su nombre real
cuando este se haya compartido. De esta forma evitamos además el problema de
que el nickname no sea pronunciable.
Para la almohadilla: Este carácter únicamente se usa para el etiquetado temático
del contenido. Dado que no estamos usando este tipo de etiquetas, en este proyecto
se han eliminado completamente.
Para la cadena “RT”: Analizar los enlaces que comparta el usuario y mostrar, en
vez del contenido compartido, el contenido original.
Esta versión del programa presenta un gran inconveniente: su elevado tiempo de
ejecución. Cada vez que es ejecutado tiene que: hacer las peticiones HTTP necesarias a
la API de twitter para poder descargarse los últimos cincuenta tweets, hacer cincuenta
peticiones a la API de MeaningCloud para obtener los respectivos cincuenta scores y una
vez hecho esto pintar la interfaz gráfica. Por tanto, su tiempo de encendido rondaba los
dos minutos más o menos dependiendo de la conexión de red con la que se contase. Una
26
vez estaba en marcha, cada vez que se quisiera sintetizar un elemento con un score
distinto debía llamarse al script correspondiente que tardaba del orden de cuarenta
segundos por elemento para realizar esa síntesis. Además, si era la primera vez que se
estudiaba ese tweet debía generar las etiquetas y la versión de emoción neutra, lo que
añadía otros treinta segundos.
Por último, hay que tener en cuenta también el tiempo de reproducción de los audios que
para elementos tan cortos será del orden de ocho o diez segundos. Por tanto, la realización
del experimento por parte de un único usuario podría llevar mucho más de hora y media.
Para evitar este problema, se ha decidido descargar seiscientos tweets y quedarnos
únicamente con cincuenta cuyos scores estén repartidos en los siguientes intervalos de
forma homogénea:
Primer intervalo: de -1.0 a -0.6
Segundo intervalo: de -0.6 a -0.2
Tercer intervalo: de -0.2 a 0.2
Cuarto intervalo: de 0.2 a 0.6
Quinto intervalo: de 0.6 a 1.0
Para escoger esta batería de textos se ha optado por aquellos que cumplieran una serie de
requisitos:
Ser emocionalmente homogéneos: es decir, no más de una frase con un gran salto
de score de una a otra.
Que la API de MeaningCloud considere estar segura de la información que nos ha
proporcionado al menos en un 75%.
Que no presente faltas de ortografía o gramaticales.
Que la cadena entera de texto sea pronunciable.
Una vez seleccionados los tweets, se han ordenado de forma aleatoria y guardado en
formato CSV junto con el score que devuelve la API de MeaningCloud para poder ser
pasados como argumento en la llamada al programa.
Para evitar también el retraso que produce la generación de las etiquetas y la creación de
los audios en el tiempo de ejecución del programa, se ha creado otro script en Python
que, para cada uno de los tweets, genera las etiquetas necesarias y sintetiza con los todos
los scores entre menos uno y uno en saltos de cinco centésimas.
De esta forma, durante la ejecución del programa, no tendrá que sintetizarse nada ni
hacerse ningún tipo de petición HTTP. El único retardo que sufrirá el sistema será aquel
que necesita para reproducir cada uno de los audios, el cual no es evitable de ninguna de
las formas.
27
Para la realización del experimento se modificó la versión primigenia de este programa
para que, además de contar con las nuevas características y con todos los audios
necesarios en su base de datos, ocultase el botón de Text-To-Speech y el campo de texto
que mostraba el score obtenido de la web. La razón de ocultarlo en vez de eliminarlo es
que seguimos mostrando el score que se usa para la síntesis, el cual por defecto incluye
el score original tras el regresor lineal con los gustos del usuario. Además, todos los
botones empezaban a estar disponibles por defecto, pues no tenían que esperar a que se
pulsase el botón de sintetizar.
De esta forma la interfaz gráfica final queda de la siguiente manera:
Figura 2.10: Segunda versión del programa de Twitter
No obstante, cuando empezamos a pedir a voluntarios que la usaran durante una ejecución
completa observamos que el usuario tendía a variar mínimamente o no variar el score que
se encontraba allí indicado. Por tanto, la realimentación que daba el usuario estaba muy
influenciada por la información que nosotros le proporcionábamos y no nos era válida.
Tras esta observación decidimos ir un paso más allá y realizar una evaluación ciega del
sistema. Es decir, no le daríamos al usuario ningún score y este mediante prueba y error
debería encontrar el que él consideraba oportuno escuchando el texto cuantas veces
necesitase con el score que el considerase.
Este método de evaluación es muchísimo más cansado para el usuario el cual tiene que
escuchar varias veces el audio variando el score para decidir qué valor es el que
definitivamente va a guardar. Sin embargo, debido precisamente a esto, es el que
consideramos que va a entregarnos datos más reales.
28
Figura 2.11: Programa de evaluación ciega
Como vemos en la figura 2.11, el programa es simplemente una modificación del anterior
en el que el usuario no recibe ningún tipo de información sobre la verdadera polaridad de
los textos a analizar.
Para poder usar estas dos últimas versiones del programa, debe indicársele el fichero CSV
mediante la entrada estándar al ser ejecutado. Por tanto, es obligatorio que sea ejecutado
desde un emulador de terminal. Además de esta forma también podremos ver la salida
estándar que nos informará de fallos y de actualizaciones del regresor lineal. El comando
necesario para ejecutarlo será:
>python evaluacion_ciega.py –-input ruta_fichero.csv
El fichero deberá estar codificado en UTF-8 usando el formato CSV tradicional, es decir,
usando comas como separadores de columnas y retornos de carro como separadores de
filas. No obstante, se permite entrecomillar el contenido del tweet para que este pueda
contener comas.
El fichero deberá constar para cada fila de:
Una primera columna con el identificador único.
Una segunda columna con la fecha de publicación del tweet.
Una tercera columna con el nickname del usuario que lo ha publicado.
El texto del tweet entrecomillado si este tuviera alguna coma en su contenido.
Una quinta columna con el score predicho por MeaningCloud.
La última columna, con el intervalo al que pertenece este tweet. Si bien el
programa no la usa, nos será útil para analizar los resultados.
29
El programa finalmente guardará varios datos que nos servirán para comprobar nuestra
hipótesis. El primero de ellos es un fichero CSV por cada usuario que contendrá las
siguientes columnas:
Número de identificador único del tweet.
El tipo de audio que ha marcado como definitivo, ya sea neutro o sentimental.
El score que recibimos de MeaningCloud.
El score que calculamos nosotros tras la salida del regresor lineal.
El score que el usuario ha decidido como score final y que posteriormente ha
pasado a la base de datos del regresor.
El segundo será el log del programa, en el que para cada evento del usuario podemos ver
un timestamp con la marca de tiempo en la que ha ocurrido además de un descriptor del
evento.
Este dato nos permitirá ver cuántas veces ha sido reproducido un tweet en concreto y
cuánto tiempo ha tardado el usuario en decidirse por un valor u otro del score, así como
si ha decidido modificar algún valor anterior.
30
3. RESULTADOS
Tras la realización del experimento por ocho personas hemos obtenido sendos ficheros
CSV con los datos a analizar. Para la interpretación de estos datos, los hemos reconvertido
a formato de hoja de cálculo mediante la herramienta Calc de la suite LibreOffice y
generado sus gráficas con la librería Matplotlib.
Nos interesa ver cómo varía la diferencia entre el score proporcionado por el usuario y el
score que nosotros calculamos tras el regresor lineal además de la diferencia del primero
con el score proporcionado por MeaningCloud.
En las gráficas siguientes, observamos para los ocho experimentos los resultados
obtenidos, siendo representado en rojo el error con signo cometido por el regresor lineal
implementado y en azul el error con signo cometido por MeaningCloud.
Por tanto, siendo U el score del usuario, M el de MeaningCloud y R el score predicho por
el regresor lineal definimos los errores como:
𝐸𝑅 = (𝑅 − 𝑈)2
𝐸𝑀 = (𝑀 − 𝑈)2
31
32
Figura 3.1: Errores del regresor y de MeaningCloud
Como primera observación, podemos ver cómo el error es coincidente para los diez
primeros valores, dado que el regresor no se activa hasta la segunda página del conjunto
de tweets al no tener información previa con la que ser entrenado.
A simple vista, obedeciendo a la línea de tendencia, parece que los errores se suavizan
cuando se aplica el regresor pero necesitamos ver esta información de una forma más
exacta. Para ello, compararemos los dos errores restando el valor del error del regresor
menos el valor del error de MeaningCloud. La comparación de ambos errores mediante
la división no es posible (al menos de forma directa, sin preparación de los datos) por la
posibilidad de que cualquiera de los scores que se definan en el denominador valga cero.
Definiremos por tanto el error comparado como:
𝐸 = 𝐸𝑅2 − 𝐸𝑀2 = (𝑅 − 𝑈)2 − (𝑀 − 𝑈)2
De esta forma, la opción de proveer al sistema de un regresor lineal será mejor que la
opción de no hacerlo, siempre y cuando el error comparado sea menor que cero.
Además, para observar la tendencia de este error con respecto al número de tweets que
se han sintetizado, representaremos el ajuste mediante una recta obtenida por el método
de mínimos cuadrados.
En las gráficas siguientes se representa para cada uno de los experimentos el error
comparado en verde y la tendencia lineal en amarillo.
33
34
Figura 3.2: Comparación de errores
De las gráficas y del fichero CSV de salida de los experimentos sacamos las siguientes
observaciones:
1. Los picos superiores (regresor lineal) son, para todos los casos, menores estrictos
que los picos inferiores (MeaningCloud) de lo cual inferimos que el error máximo
que cometemos es menor que error máximo sin regresor.
35
2. La línea de tendencia para todos los casos acaba en valores menores que cero, por
lo que podemos deducir que el regresor lineal ha mejorado la tendencia general
del predictor de la API WEB.
3. Los errores correspondientes a la que sería la página número 3 de nuestro
programa presentan picos muy favorables a la presencia del regresor con respecto
a la media general.
4. Por el contrario, los valores obtenidos para la página número 4 de nuestro
programa son los que más dispersión presentan.
5. Para todos los casos salvo para el del usuario número 7, la línea de tendencia tiene
una pendiente negativa lo cual indica que la tendencia del sistema es la de mejorar
cada vez más con respecto a MeaningCloud.
6. En un porcentaje altísimo de los textos se ha preferido la voz sentimental a la
neutral. Al preguntar a los usuarios sobre cuando han preferido usar la voz neutra
han contestado que es mejor para textos que eran parte de una noticia.
7. Los usuarios han evitado las emociones extremas cercanas a los scores menos uno
y uno, recortando el rango de la función especialmente en la parte negativa.
A la vista de la observación número tres, analizamos la página para la que el regresor se
ha comportado mejor. En ella observamos que casualmente han predominado los tweets
que hablan sobre noticias u hechos históricos, en los cuales la emoción parece uniforme
y no se emiten juicios de valor sobre el hecho que se narra. Estos tweets además presentan
unos valores más cercanos a cero.
Como hemos comentado antes en la descripción del regresor lineal, la recta que lo
caracteriza suele tener una pendiente entre 0 y 1 y una ordenada en el origen ligeramente
positiva, por lo que lo más común es pensar que, en valores más cercanos a la emoción
nula, este se vaya a comportar mejor que en valores más extremos, donde el recorrido de
la función esté más limitado y no incluya todos los valores.
Para analizar el conjunto de datos y hacernos una idea más precisa, en la gráfica siguiente
calcularemos el error total para cada uno de tweets como la media aritmética de todos los
errores para ese tweet.
36
Figura 3.3: Errores y tendencia generales
A la vista de la figura, podemos corroborar que el regresor se ha comportado como
esperábamos y ha mejorado en líneas generales el score predicho por la API WEB.
Únicamente en nueve de los cincuenta textos, el regresor ha empeorado el resultado y,
cuando esto ha ocurrido, ha cometido errores mucho menores que los que comete
MeaningCloud.
Además, la línea de tendencia tiene pendiente negativa lo cual implica que el error
cometido por el sistema sin regresor es cada vez mayor que el error cometido por el
sistema que sí que lo implementa, mejorando cada vez más su predicción y ajustándose
a los gustos del usuario. Es decir, a más ejecuciones mejor funciona el sistema.
Para comprobar el comportamiento en función de los scores que se estén tratando,
analizaremos el error que se comete para cada uno de ellos tomando como veraz el score
que el usuario ha introducido.
37
Figura 3.4: Distribución de los errores
De la figura observamos que el regresor se comporta especialmente bien para todo score
menor a 0.4. A partir de este score, el error cometido por el regresor es mayor que el error
que se cometería sin este. Esto se debe a que el regresor tiende a evitar valores extremos
a su salida y por tanto cuando un texto tiene una emoción extrema el error se hace
inevitable.
En la gráfica ha de notarse que el eje x, correspondiente al score proporcionado por el
usuario, tiene dominio de -0.8 a 1.0, lo que quiere decir que ningún usuario ha introducido
valores negativos menores a -0.8 pero sí que se ha considerado todo el rango de valores
positivos. Por tanto, aunque no quede reflejado en la gráfica, el error para scores menores
que -0.8 sería también mayor con regresor que sin él.
Las últimas páginas del programa tenían una concentración emocional algo más alta que
las anteriores debido a la distribución aleatoria de estas. Esto ha podido implicar un error
mayor en ellas. No obstante, y a pesar de ello, el regresor ha demostrado ser un buen
algoritmo de mejora de la predicción emocional.
38
3.1.1. COMENTARIOS DE LOS USUARIOS
Al terminar la realización del experimento con cada usuario, se le preguntó a cada uno
cuál era su opinión sobre la voz emocional que habían escuchado y sobre cómo ven la
implementación de este tipo de sintetizadores en las redes sociales y en los gestores de
noticias.
Todos ellos manifestaron que la síntesis de voz emocional ofrece un añadido importante
con respecto a la síntesis de voz neutra y que el resultado era mucho más humano y se
hacía más cercano al interlocutor. No obstante, un porcentaje importante de ellos
manifestó que no usaría de forma habitual un sintetizador de voz (neutro o no), ya que la
reproducción de un audio toma mucho más tiempo que la lectura de un texto y que
reservarían su uso para aquellos momentos en los que no tuvieran prisa por obtener esa
información o no estuvieran en una conversación, en la cual la velocidad de respuesta es
algo importante.
A pesar de este hecho, absolutamente todos alabaron la mejora que puede significar la
implementación de este tipo de sintetizadores para una persona con necesidades de
comunicación especiales que no pueda leer por sí mismo.
Otro comentario importante en la que gran parte de ellos coincidía fue en lo difícil que
fue catalogar la emoción de una frase que contuviera citas con estilo directo,
especialmente si la emoción era muy positiva o muy negativa. Un ejemplo de tweet al
que hacían referencia contenía el texto:
El Ministro de Finanzas Griego Varoufakis: "El Banco Central Europeo nos quita el
aire para respirar"
Podemos entender que en este tipo de oraciones haya dudas sobre si deben considerar que
el texto es una noticia y debe sintetizarse con la voz neutra del citador, o si debe
sintetizarse con la emoción del texto citado.
Por último, otro comentario extendido entre los usuarios ha sido que, si bien la emoción
era identificable fácilmente, todavía se notaba “poco humana” y que a pesar de expresar
la emoción adecuadamente le faltaba “calidez”, volviéndose especialmente metálica en
la tristeza o en la alegría puras.
39
4. CONCLUSIONES Y LÍNEAS FUTURAS
4.1. CONCLUSIONES
Como primera conclusión, destacamos que todos los usuarios han afirmado preferir la
voz sintetizada con emoción a la voz sintetizada sin ella en la mayor parte de los textos.
El que más veces ha seleccionado como preferencia la voz neutra no lo ha hecho más que
seis veces. Por tanto, aseguramos que la implementación de este tipo de sintetizadores
con emociones tendrá una acogida favorable en comparación con la voz neutra.
A vista de las gráficas del apartado 3 podemos concluir que el aprendizaje automático
realizado por un regresor lineal de este tipo mejora la experiencia del usuario. No
obstante, el regresor lineal comete errores en las emociones extremas, las cuales, al
ocurrir con menos frecuencia, suelen ser obviadas por este.
El regresor lineal muestra tendencia a mejorar con el número de puntos considerados por
él, haciendo cada vez un seguimiento más fiel de los gustos del usuario.
Por tanto, la implementación de este tipo de algoritmos en las plataformas web o en las
redes sociales supondrá una mejora considerable de la calidad de vida y de la calidad de
las relaciones interpersonales de aquellos usuarios finales con algún tipo de discapacidad
que les impida usar estas de la forma habitual.
Además, dada la preferencia manifestada por los voluntarios que han usado el sistema,
no solo las personas con alguna discapacidad podrán beneficiarse de una implementación
de este tipo, sino todas aquellas personas que quieran usar las redes sociales, los gestores
de noticias o ciertas páginas web de esta manera podrán disfrutar de una mejora en su
experiencia de usuario con respecto al uso de una voz sintetizada neutra.
4.2. LÍNEAS FUTURAS
En el presente proyecto se ha demostrado que con el tipo de regresor lineal se ha mejorado
la experiencia del usuario y se ha hecho una predicción mejor de sus gustos. No obstante,
como se ha comentado antes el sistema presenta algunos fallos, como la imposibilidad de
predecir emociones muy extremas. El primer paso que debería darse sería mejorar el
predictor lineal e intentar entrenar un regresor como el sigmoide explicado en el apartado
2.5.3, el cual tendría una zona casi lineal en el rango de scores donde mejor funciona el
estudiado en este proyecto y unas zonas no lineales en los rangos de scores en los que
este ni siquiera otorga datos.
40
Dada la información que maneja la API REST que se ha consultado, debería mejorarse
el sistema haciéndole detectar mediante más consultas a esta el tipo de texto que se quiere
sintetizar y comprobar que este deba ser sintetizado con emoción o sin ella. Por ejemplo,
antes de ponerse a predecir emociones consultar a la API, si este hecho es una noticia que
pretende informar de forma neutra a pesar de que su contenido sea claramente positivo o
negativo.
Como última mejora, deberían estudiarse los casos especiales como las citas con estilo
directo, detectándolas y tratándolas según la forma que el usuario manifieste, de forma
que estas sean tratadas de forma especial al reentrenar el regresor sin que creen grandes
variaciones en la función característica de este.
41
5. ANEXO DE TÉRMINOS
API: Abreviatura de la traducción en inglés de Interfaz de Programación de Aplicaciones.
Es un conjunto de software destinado a ser importado en otro código que proporciona una
capa de abstracción sobre la funcionalidad que se quiere implementar.
API REST: Es un tipo de API especial en el que no se distribuye el código o el binario
correspondiente sino que se accede mediante el envío de peticiones a un servidor como
si de una petición web se tratara.
AWK: Lenguaje de programación usado para el procesado de datos que estén
representados como texto, ya sean estos ficheros o flujos de datos.
Bash: Es un lenguaje de programación del emulador de terminal. Su función es
interpretar las ordenes que se le dan a la consola. Es una mejora del Shell original de
Unix.
Codificación de caracteres: Cada uno de los métodos para representar caracteres en
formato binario.
Comando: Es una instrucción hecha al sistema operativo para que realice determinada
operación. Puede ser invocado desde el emulador de terminal o desde una llamada de
programación.
Corpus: Conjunto completo de unidades del que consta un determinado sistema de
síntesis de voz.
CSV: Abreviatura en inglés de Comma Separated Values. Tipo de fichero que representa
datos en formato texto. Simula una tabla de datos mediante la separación de columnas
por comas y la separación de filas por retornos de carro.
Debian: Distribución GNU/Linux basada en el manifiesto Debian. No es la más amigable
para el usuario inexperto pero aun así se la considera la más estable, por lo que es perfecta
para usar en servidores y en investigación.
Difonema: Conjunto de dos fonemas.
Difono: Transición entre dos fonemas consecutivos. Se considera un difono desde la
mitad del primer fonema hasta la mitad del segundo.
Directorio: Sistema de organización de ficheros en forma de árbol en el cual cada
directorio “cuelga” del directorio que lo contiene.
Distribución GNU/Linux: Conjunto de software con base en el kernel de Linux que
incluye determinados paquetes para satisfacer las necesidades de un grupo específico de
usuarios. Además del kernel suelen incluir un entorno de escritorio y software de
utilidades generales.
42
Emulador de Terminal: Es un programa que simula el comportamiento de un terminal
de computadora. También puede ser llamado Shell, intérprete de comandos, intérprete de
ordenes o simplemente consola.
Festival: Suite de programas de código abierto con base GNU/Linux desarrollados por
la Universidad de Edimburgo que pretende facilitar el proceso de síntesis de habla.
También es llamado así el proyecto del que nació esta suite informática.
Festvox: Programa del Proyecto Festival que pretende facilitar el proceso de creación de
un modelo de voz.
Fonema: En fonética, es la unidad mínima. Consiste en la representación un sonido de
la lengua.
Formante: Pico de potencia en el espectro de un sonido formada por dos polos complejos
conjugados en el filtro que caracteriza el tracto vocal.
GCC: Abreviatura de GNU Compiler Collection. Es una suite de programas encargada
del preprocesado, compilación, ensamblado y enlazado de programas en C. Es el utilizado
para la compilación de Festival.
G++: Programa parte similar a GCC para el lenguaje C++.
GUI: Interfaz gráfica de usuario. Tipo de interfaz que no está destinada a ejecutarse en
un emulador de terminal sino en un entorno de escritorio. Facilita al usuario el manejo de
programas mediante el uso del ratón y el teclado.
Homeline: En la red social Twitter, todo el contenido que han compartido los usuarios a
los que estas suscrito, el cual se presenta ordenado cronológicamente.
Interpolación: En nuestro contexto, método de sintetización de textos en el que se usan
varios modelos del mismo actor con distintas emociones para obtener como resultado una
emoción intermedia entre ellos.
Hashtag: Etiqueta que se inserta en un tweet añadiendo a una palabra un carácter “#” al
principio de esta. De esta forma se categorizan los tweets de forma temática y se facilita
su búsqueda.
ISO-LATIN-1: Codificación de caracteres de la norma ISO consistente en una
ampliación de ASCII en el que incluye todos los caracteres del alfabeto latino, más
caracteres de puntuación y más caracteres no imprimibles.
JSON: Formato de texto ligero para el intercambio de datos en formato texto. Tiene la
misma finalidad que XML pero ha conseguido mucha más popularidad debido a que es
mucho más fácil desarrollar un parser para él.
43
Label: Etiqueta en inglés. Fichero de texto que contiene los datos necesarios para la
síntesis de un texto como, por ejemplo, los fonemas involucrados o la duración de los
mismos.
Listener Event: Evento que se activa cuando el usuario realiza una acción. Determina
que acción ha ocurrido (pulsar un botón software, pulsar un botón físico, cambiar el valor
en un campo de texto…) y llama al método oportuno para que se ejecute.
Logotoma: Palabra sin significado que se usa en la creación de un modelo de voz
consistente en tres difonemas siendo el del medio el que se quiere aislar para incorporarlo
a la batería de audios necesaria.
Nickname: Para la red social Twitter, seudónimo que un usuario ha escogido y por el
que será identificado en esta. Este nombre será exclusivo para cada usuario.
Petición HTTP: Solicitud que un cliente hace a un servidor web para que le sea entregado
un recurso. Es el tipo de peticiones que hacen las API REST.
Pitch: Frecuencia fundamental del habla.
Prosodia: Estudio de los rasgos fónicos que afectan a la métrica del lenguaje.
Especialmente de la distribución de acentos en la oración.
Regresor lineal: Modelo matemático que ajusta un conjunto de puntos por una recta.
Retweet: Acción por la que un usuario comparte contenido de otro usuario con sus
suscriptores.
Score: Número decimal entre menos uno y uno cuyo valor es proporcional a la emoción
del texto analizado, siendo menos uno la emoción más negativa, cero la emoción neutra
y uno la emoción más positiva.
Síntesis: Proceso mediante el cual se parte de un texto y se genera a partir de él un audio
que contiene la articulación vocálica de ese texto.
Sintetizador: sistema computarizado que realiza la síntesis de textos. Puede ser software
o hardware.
Sox: Comando multiplataforma desarrollado para el tratamiento de ficheros de audio.
Permite operaciones como la reproducción, la concatenación, la aceleración, la grabación
y la transformación de datos sonoros.
Status: Para determinadas APIs de Twitter, es el nombre del objeto que representa un
tweet.
Tcsh: Es un lenguaje de programación del emulador de terminal de Unix compatible con
la Shell en C que incluye autocompletado y edición en línea de comandos.
44
Text2lab: Script en bash que se encarga de la generación de etiquetas de un texto para
su posterior sintetización.
Thread: En un lenguaje de programación, cada una de las partes de ejecución paralela
que se ejecuta sobre el mismo proceso.
Timestamp: Marca de tiempo con la que se etiqueta un evento para saber en qué
momento ocurrió.
TTS: Abreviatura del inglés Text To Speech.
Tweet: Cada uno de los contenidos compartidos en la red social Twitter. Suelen ser auto
conclusivos y de 140 caracteres como máximo. Permiten le sean adjuntados elementos
multimedia como una foto, un enlace, un video o una encuesta.
UTF-8: Es una de las codificaciones de caracteres que más se usa actualmente. Su
importancia se debe a que contiene todos los caracteres de Unicode los cuales codifica
con longitud variable e incluyendo sincronía.
XML: Traducción del inglés de Lenguaje de Marcas Extensible. Es un lenguaje destinado
a almacenar datos de forma legible para ser compartida entre varias plataformas.
45
6. BIBLIOGRAFÍA
[1] «Portal web de la ETSIT UPM,» Available: http://www.etsit.upm.es/.
[2] Página web del proyecto Debian. www.debian.org
[3] Página web del lenguaje Python www.python.org
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
Portal de la empresa MeaningCloud https://www.meaningcloud.com/es/.
Página del proyecto NINJA-IDE http://ninja-ide.org/
Instrucciones de uso de VirtualBox https://www.virtualbox.org/
API de la librería Tweepy http://www.tweepy.org/
Portal de desarrolladores de la red social twitter https://dev.twitter.com/
Instrucciones de uso de matplotlib http://matplotlib.org/
Página del proyecto PyGtk+ http://www.pygtk.org/
Página del proyecto Festival de la Universidad de Edimburgo
http://www.cstr.ed.ac.uk/projects/festival/
Página del proyecto FestVox http://www.festvox.org/festival/
Página del proyecto GCC https://gcc.gnu.org/
Apuntes del CIEMAT sobre regresión lineal
http://wwwae.ciemat.es/~cardenas/docs/curso_MD/regresionlineal.pdf
Página web del Grupo de Tecnología del Habla. lorien.die.upm.es
Statistical Parametric Speech Synthesis
Heiga Zena, Keiichi Tokudaa, Alan W. Black
