TESIS DEFENDIDA POR

Fernando Luque Suárez

Y APROBADA POR EL SIGUIENTE COMITÉ

Dr. Edgar Leonel Chávez González

Director del Comité

Dr. Carlos Alberto Brizuela Rodríguez Dr. José Alberto. Fernández Zepeda
Miembro del Comité Miembro del Comité

Dr. Luis Armando. Villaseñor González

Miembro del Comité

Dr. Hugo Hidalgo Silva Dr. David Hilario Covarrubias Rosales

Coordinador del programa de Director de Estudios de Posgrado
posgrado en ciencias de la
computación

3 de diciembre del 2010.

CENTRO DE INVESTIGACIÓN CIENTÍFICA Y DE EDUCACIÓN SUPERIOR
DE ENSENADA

PROGRAMA DE POSGRADO EN CIENCIAS

EN CIENCIAS DE LA COMPUTACIÓN

Un marco de trabajo para la recuperación de objetos

multimedia.

TESIS

que para cubrir parcialmente los requisitos necesarios para obtener el grado de
MAESTRO EN CIENCIAS

Presenta:
FERNANDO LUQUE SUÁREZ

Ensenada, Baja California, México, diciembre del 2010.

 i

RESUMEN de la tesis de Fernando Luque Suárez, presentada como requisito

parcial para la obtención del grado de MAESTRO EN CIENCIAS en CIENCIAS
DE LA COMPUTACIÓN. Ensenada, Baja California. Diciembre del 2010.

UN MARCO DE TRABAJO PARA LA RECUPERACIÓN DE OBJETOS

MULTIMEDIA.
Resumen aprobado por:

________________________________
Dr. Edgar Leonel Chávez González
Director de Tesis

RESUMEN
La representación perceptual de objetos multimedia ha evolucionado
considerablemente los últimos años. Este avance permite tener representaciones
de objetos robustas a deformaciones; sin embargo los métodos de búsqueda en
repositorios han quedado rezagados y el avance es mínimo. El desarrollo de
índices multimedia y su relación con la representación robusta de objetos da como
resultado la recuperación de información en multimedia (MIR).

En este trabajo de tesis se presenta un marco de trabajo, en forma de biblioteca

de programación, que permite modelar los repositorios multmedia como espacios
de objetos abstractor y genera estructuras o índices que permiten la búsqueda de
objetos multimedia por contenido.

El caso de estudio en este trabajo fue el audio utilizando técnicas de

representación perceptual sobre una colección de canciones. Se implementaron
técncias secuenciales y con el marco de trabajo generado se implementaron
técnicas de indización para hacer las búsquedas sublineales, escalables. Por
último se programó una aplicación que utilizando el marco de trabajo toma una
muestra de audio, grabada con un micrófono, como consulta y regresa los k-
vecinos más cercanos a la consulta como respuesta.

Los resultados obtenidos son: Una plataforma de la cual se puede partir para
realizar aplicaciones que requieren la búsqueda por similitud de objetos
multimedia utilizando el contenido, un índice para espacios que son secuencias de
bits bajo la distancia de Hamming.

Palabras Clave: Recuperación de información en multimedia, natix, índice.

 ii

ABSRACT of the thesis presented by Fernando Luque Suárez as a partial

requirement to obtain the MASTER OF SCIENCE degree in COMPUTER
SCIENCE Ensenada, Baja California, México mes y año.

A FRAMEWORK FOR MULTIMEDIA OBJECTS RETRIEVAL.

ABSTRACT

The perceptual representation of multimedia objects has evolved considerably in

the last few years. This evolution allows to have robust object representations;
nevertheless the search methods have been left behind and the evolution is
minimal. The development of multimedia indexes and its relationship with robust
object representation bring us multimedia information retrieval (MIR).
In this thesis we present a framework, as a library, that allows to model multimedia
repositories as abstract object space and generates structures or indexes allows
us to search for multimedia objects by content.
The case of study of this thesis was audio using perceptual representation
techniques no a collection of songs. We implemented sequential techniques and
with the presented framework we implemented indexation techniques to do
sublineal and scalable searches.
Finally, we implemented an application using the presented framework that takes
an audio sample recorded from the microphone as query and return as result using
the nearest k-neighbor criteria.
The results presented in this work ar: A platform that can be taken as base to
develop applications that need to search multimedia objects by content. Also we
present n index for spaces that are bit sequences under the hamming distance.

Keywords: Multiemdia information retrieval, natix, index.

 iii

Dedicatorias

A mis padres
 iv

Agradecimientos

Un agradecimiento especial a mi director de tesis Dr. Edgar Chávez González, por todo el
apoyo proporcionado en la realización de este trabajo. Gracias.

A los miembros del comité de tesis:

Dr. José Alberto Fernández Zepeda, Dr. Carlos Alberto Brizuela Rodríguez, Dr. Luis
Villaseñor González., por sus valiosos comentarios durante el desarrollo del trabajo.

A mis padres por creer en mí y brindarme su apoyo incodicional. Gracias.

A los profesores del Departamento de Ciencias de la Computación que contribuyeron en

mi formación. Gracias.

A mis compañeros Javier Velarde, Daniel Hernández, Raúl Loredo, Orlando Barrera,
Fermín Armenta, Vanessa Miranda, Iveth Corona, Jorge Álvarez, Rene Navarro, Jorge
Cortez, Marco Sánchez, Martin Mancilla, Amador Velázquez, por la buena vibra y el
apoyo durante estos dos anos. Gracias.
Al Centro de Investigación Científica y Educación Superior de Ensenada
Al Consejo Nacional de Ciencia y Tecnología (CONACYT) por apoyarme económicamente
con mis estudios de posgrado. Gracias.
 v

Contenido
Página
RESUMEN ..........................................................................................................................i
ABSTRACT....................................................................................................................... ii
Dedicatorias ...................................................................................................................... iii
Agradecimientos................................................................................................................iv
Contenido............................................................................................................................ v
LISTA DE FIGURAS ..................................................................................................... vii
LISTA DE TABLAS ..........................................................................................................x
CAPITULO I Recuperación de objetos complejos en espacios métricos ..................... 1
I.1 Introducción ..........................................................................................................1
I.2 Búsquedas por similitud........................................................................................ 8
I.3 Recuperación de objetos multimedia ....................................................................9
I.4 Representación perceptual de objetos multimedia.............................................. 10
I.5 Objetivos ............................................................................................................. 13
I.5.1 Objetivo General ........................................................................................... 13
I.5.2 Objetivos Particulares .................................................................................... 14
I.6 Motivación ..........................................................................................................14
I.6 Metodología de investigación ............................................................................. 17
1.7 Organización de la tesis ..................................................................................... 18
CAPITULO II Caso de estudio ...................................................................................... 19
II.1 Introducción .......................................................................................................19
II.2 Escenario de aplicación ..................................................................................... 21
II.3 Características del caso de estudio ....................................................................25
CAPITULO III Estado del arte. ..................................................................................... 29
III.1 Introducción .....................................................................................................29
III.2 Extracción de características de la señal .......................................................... 31
III.3 Modelado de las características ........................................................................33
III.4 Búsquedas en espacios métricos ......................................................................35
III.5 Aplicaciones .....................................................................................................40
III.5.1 Shazam ........................................................................................................40
CAPITULO IV Propuesta de solución...........................................................................47
IV.1 Introducción .....................................................................................................47
IV.2 Técnica de obtención de AFPs .........................................................................48
IV.2 Librería Natix ...................................................................................................52
IV.2 Técnica de indización. ..................................................................................... 55
 vi

Contenido (continuación)

IV.3 Interfaz de consulta. ......................................................................................... 59

CAPITULO V Extensión de propuesta de solución ..................................................... 63
V.1 Introducción ......................................................................................................63
V.2 Locality Sensitive Hashing................................................................................ 66
V.3 Construcción de un índice LSH ........................................................................67
V.4 Búsqueda en el índice LSH ............................................................................... 70
V.5 Implementación del índice LSH ........................................................................73
CAPITULO VI Experimentos y resultados...................................................................74
VI.1 Introducción .....................................................................................................74
VI.2 Características ..................................................................................................75
VI.3 Construcción del índice.................................................................................... 77
VI.3 Experimento 1. Tomando la consulta desde el micrófono ............................... 78
VI.4 Experimento 2. Integrando metadatos a la biblioteca digital de música ..........79
VI.5 Experimentación con LSH ............................................................................... 80
VI.5.1 Experimentación con Indice Secuencial con desplazamiento en el
tiempo .................................................................................................................... 82
VI.5.1 Experimentación con indice LSH con desplazamiento en el tiempo .........84
VI.6 Análisis de resultados ...................................................................................... 87
CAPITULO VII Conclusiones, aportaciones y trabajo a futuro ................................ 89
VII.1 Conclusiones. ..................................................................................................89
VII.1.1 Percepción de objetos multimedia ............................................................... 90
VII.1.2 Búsquedas escalables en colecciones heterogeneas ....................................91
VII.2 Aportaciones ...................................................................................................92
VII.3 Trabajo a futuro .............................................................................................. 93
Bibliografía ....................................................................................................................... 94
Apéndice A Implementación de Natix ...........................................................................97
A.I Introducción .......................................................................................................97
A.II Modelando un espacio métrico con Natix ........................................................ 99
A.III Implementando un índice en Natix ............................................................... 101
A.IV Creando un índice en Natix. ..........................................................................103
A.V Buscando dentro de un índice en Natix .......................................................... 104
A.VI Montando Natix en un servicio web ............................................................. 104
 vii

LISTA DE FIGURAS
Página
Figura

Tabla relacional con estructura definida, para alamcenar datos

1
estructurados ...…………………………………….……...…………….. 2
2 Ejemplo de colección de datos no estructurados ……………….………. 3
Representación de un índice invertido o archivo invertido aplicado en
3
texto libre.………………………..…..…………………………….……. 5
Conjuntos de elementos relevantes recuperados, recuperados y
4
relevantes……………………………...………………………………… 6
5 Gráfica de presión en varios puntos del recall ...……………………...… 7
Proceso genérico para indexar y realizar búsquedas de objetos
6
multimedia ……………………….……………………………………... 13
Metodología de investigación aplicada en la generación de un marco de
7
trabajo para la búsqueda de objetos multimedia por contenido …...……. 16
8 Proceso para generar tabla relacional con metadatos …………………… 21
9 Diagrama del primer escenario de aplicación ……………………........... 23
10 Diagrama del segundo escenario de aplicación …………………............ 24
Representación de la interacción del reproductor de música en el caso
11
de estudio ……………………………………………………….............. 25
12 Diagrama a detalle del primer escenario de aplicación …………............. 26
13 Diagrama a detalle del segundo escenario de aplicación ……….............. 27
Flujo de preguntas para generar una técnica de recuperación de objetos
14
multimedia ……………………………………………………………… 29
15 Proceso genérico para la obtención de un AFP …………………………. 33
16 División del espacio tomando como pivote u11………………..……….. 36
17 Ejemplo de primer nivel de BST o GHT y una consulta q ....................... 37
 viii

LISTA DE FIGURAS (Continuación)

Figura Página

18 Ejemplo del primer nivel de un GNAT ……………….………...………. 38

19 Espectro de la frecuencia de una señal de audio ……………………..…. 40
20 Constelación de puntos tiempo-frecuencia ……………………………... 41
Gráfica tiempo-frecuencia de una consulta sobre puesta en la gráfica
21
tiempo-frecuencia de una canción en la colección …..………………….. 41
22 Punto de anclaje representante de una zona objetivo …………………… 42
23 Representación de la generación de un valor hash …………………...… 43
Histograma resultado de la comparación de una canción de la colección
24
contra una consulta ……………………………………………………… 45
25 Proceso genérico para recuperar audio …………………………………. 46
26 Representación de la entropía en escalas de grises ……………............... 49
27 Representación de una canción con MBSES …………………………… 50
28 Proceso para la obtención de un AFP con MBES ………………………. 50
29 Diagrama de interacción de Natix …………………………………......... 52
30 Utilización de servicios web con Natix ………………………….……… 54
31 Obtención de un permutación para un elemento u …………………….... 56
32 Proceso de búsquedas sobre un índice basado en permutaciones ………. 57
33 Pantalla de captura dentro de la interfaz de consulta …………………… 59
34 Ilustración de la propuesta de solución …………………………………. 61
Implementación de una tabla hash utilizando el método de
35
direccionamiento directo ……………………...……………………….... 63
36 Resolucion de colisones utilizando el metodo de encadenamiento …….. 64
37 Generación de un AFP con MBSES ………………………………..…... 66
38 Obtención de los valores hash en LSH .………………………………… 67
39 Obtenacion de valores hash cada n bits ………………………………… 68
 ix

LISTA DE FIGURAS (Continuación)

Figura Página

41 Histograma con las canciones candidatas x, y, z ……………………….. 71

42 Diagrama de implementación de LSH ………………………………….. 72
Gráfica de resultados del expermiento variación de bits realizado sobre
43
el indice LSH …………………………………………………………… 80
44 Gráfica de Resultados del experimento secuencial ……………………... 81
45 Gráfica de distancias con hamming determinístico …………………….. 82
46 Gráfica tiempo de búsqueda en Secuencial ……………………………... 83
47 Gráfica de Resultados del experimento LSH …………………………… 84
48 Gráfica con el número de marcos que hacen match …………………….. 85
49 Gráfica tiempo de búsqueda en LSH …………………………………… 85
50 Interfaces centrales para implementar un espacio métrico en Natix ……. 96
51 Interfaces que modelan un espacio en Natix ……………………………. 97
52 Ejemplo de implementación de un espacio en Natix …………………… 99
53 Ejemplo de implementación de un índice en Natix …………………….. 100
 x

LISTA DE TABLAS

Tabla Página

I Tabla hash que representa la colección de canciones indexada …… 43

II Distribución de ritmos y deformaciones …………………………... 78
III Comparación del índice secuencial contra el índice LSH …………. 86
IV Descripción de métodos y propiedades de la interface Space ……... 97
V Descripción de métodos y propiedades de la interface Space<T> … 98
VI Métodos y propiedades de la interface BaseIndex<T> ……………. 100
CAPITULO I

Recuperación de objetos complejos en espacios métricos

I.1 Introducción

Desde el principio de la civilización, los seres humanos han buscado la manera de

conservar información a través del tiempo de diversas maneras. Desde jeroglíficos hasta la
escritura en editores de texto, desde imprentas hasta bibliotecas electrónicas, la comunicación de
información ha sido un tema de preocupación primaria para la existencia humana. En la
actualidad, con la incursión de las bibliotecas digitales y el intercambio de información
electrónica, es evidente la necesidad de desarrollar técnicas para el manejo de grandes cantidades
de información.

El incremento del uso de tecnologías de información, a escalas sin precedentes en

nuestros tiempos, ha detonado la creación de repositorios o depósitos inmensos de información
alrededor del mundo. Además de las grandes cantidades de datos que existen, con los avances en
digitalización de señales de audio, imágenes video, etc., la diversidad en los tipos de datos
también se ha venido incrementando, haciendo necesaria la recuperación de información, no solo
en datos o documentos de texto, sino en todos los tipos de datos existentes.

Actualmente, en los repositorios alrededor del mundo, se encuentran almacenados

conjuntos de datos electrónicos, los cuales se pueden clasificar por la manera en que están
organizados, en dos clases: los conjuntos de datos estructurados y los no estructurados. Por lo
general, los estructurados se organizan en bases de datos relacionales tradicionales. Una base de
datos relacional se puede definir como un conjunto de datos pertenecientes a un mismo contexto,
almacenados sistemáticamente para su uso posterior. Tradicionalmente estas bases de datos se
dividen en registros, los cuales, cuentan con campos que se pueden comparar fácilmente. Las
búsquedas en estas clases de bases de datos se construyen bajo el concepto de búsqueda exacta,
donde una búsqueda sobre un conjunto de registros, recupera los registros que sean iguales al
criterio de la consulta (Chávez et al., 2001).
 2

Un ejemplo de un conjunto de datos electrónicos estructurados es el siguiente: una base

de información conformada por una lista de fichas personales electrónicas, donde cada ficha
cuenta con el mismo contenido de datos, es decir, cuenta con nombre, apellido, teléfono, etc.
Este tipo de información se puede insertar como registros en una tabla de bases de datos
tradicional, donde como se muestra en la Figura 1, la estructura de la tabla la define el contenido
de las fichas personales, es decir el contenido homogéneo de cada uno de los elementos o
documentos del conjunto de datos electrónicos.

Figura 1. Tabla relacional con estructura definida para alamcenar datos estructurados.

Si se requiere hacer una búsqueda de alguna ficha en particular o realizar un filtro sobre
el contenido de la tabla que se muestra en la Figura 1, el proceso a seguir es generar una consulta
alfanumérica, que dependiendo del resultado deseado se compone de cierta sintaxis propia del
objetivo de la consulta. Por ejemplo, si se quiere obtener la ficha de José, se tiene que someter a
búsqueda una consulta como la siguiente: “ select * from table where Nombre=’José’ ”, con esta
consulta bajo el criterio de búsqueda exacta, el manejador de base de datos busca aquellos
registros que en la columna “Nombre” que tengan como contenido “José” y como respuesta a la
consulta retorna la lista de registros. Si bien este enfoque funciona en conjuntos de datos
estructurados o de contenido homogéneo, la presencia de millones de datos heterogéneos
alrededor del mundo incrementa la necesidad de poder realizar búsquedas sobre cualquier tipo de
conjuntos de datos electrónicos.

Para la clase de conjuntos de datos no estructurados, se tiene que hacer referencia a

Internet, el ejemplo más significativo existente, que por el hecho de conformarse de elementos de
contenido heterogéneo, no se puede establecer una estructura definida en donde se puedan incluir
 3

todos los elementos que lo conforman. Por esta razón, las técnicas tradicionales de búsquedas en
bases de datos no se aplica a conjuntos de datos no estructurados o de contenido heterogéneo.

La Recuperación de Información, es el área de las ciencias de la computación encargada

de extraer información útil de conjuntos de datos o documentos no estructurados. En sus
principios, el objetivo de la recuperación de información era recuperar datos o documentos
relevantes a una consulta, aplicando este objetivo a documentos de texto libre, y aunque el
objetivo de estudio que se ha utilizado durante varias décadas es el mismo, con la introducción
de tipos de datos más complejos como audio, imágenes, video, etc., y la necesidad de recuperar
información útil sobre cualquier conjunto de datos han incrementado la dificultad de llevar a
cabo las tareas de la recuperación de información.

Figura 2. Ejemplo de colección de datos no estructurados.

Un ejemplo mostrado en (Manning et al., 2008) de un problema clásico al que se enfrenta

la recuperación de información en texto libre es el siguiente: supongamos que se cuenta con la
colección completa de las obras de Shakespeare como la que se muestra en la Figura 2, y se
quiere saber en cuáles obras aparecen las palabras Brutus y Cesar y no Calpurnia. Una manera
para realizar esta tarea, es comenzar desde el principio de la colección y leer obra por obra
 4

buscando la expresión anterior. Este proceso de barrido de texto puede ser un proceso efectivo
tomando en cuenta las velocidades de los procesadores actuales. Si consideramos un libro que
cuenta con un millón de palabras, con un proceso de este tipo podría ser suficiente, pero resulta
insuficiente cuando se consideran otros propósitos como lo son:

 Realizar la búsqueda en una colección muy grande en el menor tiempo posible. En la

actualidad, la cantidad de información en línea ha crecido considerablemente y se
presenta la necesidad de buscar en colecciones de documentos que cuentan con una
cantidad de billones o trillones de palabras.
 Tener la posibilidad de realizar consultas más flexibles. Por ejemplo, es impráctico o
improcedente realizar una consulta de la expresión “romanos near campesinos”. Para
esto se tendría que definir el término near como “dentro de 5 palabras” o “dentro de la
misma oración”.
 Realizar una recuperación ponderada. En la mayoría de los casos, se quiere conocer la
mejor respuesta posible entre una gran cantidad de documentos que cumplen con la
consulta.

La manera de evitar la realización un barrido lineal al texto para realizar una consulta y
poder cumplir con los propósitos que se mencionaron anteriormente, es estableciendo con
anterioridad una estructura o índice de los documentos. El concepto más importante de
recuperación de información en texto libre es el índice invertido. La idea básica de un índice
invertido se muestra en la Figura 3, donde se cuenta con un conjunto de términos, para este caso,
un diccionario de palabras que aparecen en cada una de las obras. Después, para cada uno de los
términos o palabras se asigna una lista que cuenta con aquellos documentos o para este caso
obras en las que se incluye el término o palabra. Cada una de estas listas se llama lista invertida.
Luego de hacer las listas invertidas, el diccionario de términos se ordena así como las listas
invertidas. El algoritmo genérico para crear un índice invertido es el siguiente:

1. Agrupar los documentos que se van a ser indizar.

2. Analizar gramaticalmente el texto de cada unos de los documentos para obtener
una lista de términos de cada uno de los documentos.
3. Hacer una normalización de los términos de las listas que se obtuvieron en el
análisis gramatical realizado previamente para obtener los términos de índice.
 5

4. Indizar cada uno de los documentos, es decir agregar a la lista invertida de un

término el documento si éste contiene el término en su lista de términos.

Figura 3. Representación de un índice invertido o archivo invertido aplicado en texto libre (Manning et al., 2008).

Una vez creado el índice, existen varios enfoques para realizar búsquedas sobre este tipo
de estructuras, el más básico es el enfoque booleano. Tome en cuenta el ejemplo de la Figura 3,
si se quisiera encontrar la siguiente consulta “Brutus y Calpurnia”, el proceso es el siguiente:
primero encontrar las listas invertidas del término “Brutus” y la del término “Calpurnia”.
Después realizar una intersección entre ambas listas. Para el ejemplo anterior el documento
recuperado es el 31, el único miembro que aparece en ambas listas invertidas.

Utilizando este enfoque booleano, uno puede obtener siempre todos aquellos documentos
que sean relevantes a una consulta de una colección, el tiempo en la respuesta al utilizar
este enfoque en las búsquedas depende del número de elementos en la colección, con
esto, este método no escala en colecciones muy grandes, al tener que realizar operaciones
de acuerdo al tamaño de la entrada. Por otra parte, existen enfoques de búsquedas como
el vectorial o el probabilístico que sacrifican la precisión en las respuestas por obtener un
tiempo de respuesta constante que escale en colecciones de millones de documentos.

Como se muestra en la Figura 4, en la respuesta a una consulta sobre todos los

documentos de un conjunto de datos, están por un lado el conjunto de los documentos relevantes
 6

y por otro lado el conjunto de los documentos recuperados. En un sistema perfecto estos dos
conjuntos son iguales o equivalentemente, recuperar solo aquellos documentos que son
relevantes. Pero en la realidad, los sistemas de recuperación de información, traen en su
respuesta muchos documentos que no son relevantes a una consulta y para medir la eficiencia de
estos sistemas de recuperación se utilizan dos parámetros: la precisión y el recall.

Figura 4. Conjuntos de elementos relevantes recuperados, recuperados y relevantes (Grossman y Frieder, 2004).

La precisión es la razón del número de documentos relevantes recuperados entre el

número de documentos que son recuperados. La precisión da un indicador de la calidad de
respuesta que se le da a las consultas, pero cuando se considera solo este parámetro, no se puede
afirmar que un sistema es totalmente efectivo, porque si se consideran por ejemplo, una consulta
en la cual se recuperan 10 documentos y 9 son relevantes, la consulta tendría una precisión muy
alta (0.9), pero si en el universo de documentos había 100 documentos que eran relevantes a la
consulta, el resultado en realidad es pobre en cuanto al número de documentos relevantes no
recuperados que no se toman en cuenta pero en realidad si deberían de serlo. El recall considera
el número total de documentos relevantes recuperados entre el número de documentos relevantes
en la colección, dando como resultado la porción de documentos recuperados de la base de datos
que son relevantes a la consulta (Grossman y Frieder, 2004).
 7

Una curva precisión/recall normalmente se muestra como en la Figura 5. El

comportamiento típico de un sistema de recuperación cuenta con un recall más elevado del
deseado, o lo que es lo mismo, más de los documentos relevantes en la colección se recuperan
para obtener una precisión aceptable. En un sistema perfecto, solo documentos relevantes se
recuperan lo que significa que en cualquier punto del recall, la precisión es 1.0 (Grossman y
Frieder, 2004).

1
0.9
0.8
0.7
0.6
Presición

0.5 comportamiento
0.4 típico
0.3 comportamiento
0.2 óptimo
0.1
0
0 0.2 0.4 0.6 0.8 1
Recall

Figura 5. Gráfica de presición en varios puntos del recall (Grossman y Frieder, 2004).

Con la evolución de las tecnologías de información y comunicación, los repositorios de

datos no estructurados han crecido a escalas sin precedentes, no solo en tamaño sino también en
nuevos tipos de datos más complejos. Si bien por una parte se podría pensar que el problema de
la recuperación de información es un problema resuelto con las técnicas de recuperación de texto
libre, hay otros tipos de datos como el sonido, video, imágenes, cadenas de ADN, etc., en los
que estas técnicas no se pueden aplicar o por lo menos no de manera directa.

El motivo por el cual no se pueden utilizar los métodos que actualmente se usan para el
texto libre en recuperación de información en los casos de datos o documentos anteriormente
mencionados, se basa en que la recuperación de texto, hace uso de diccionarios de términos que
 8

no varían a través de los documentos. En cambio en datos más complejos, como cadenas de
ADN, video, imágenes, audio, etc., no se pueden definir una lista de términos estáticos, debido a
las modificaciones que estos tipos de datos sufren. Es decir no se puede definir un diccionario de
manera directa donde se incluyan todos los posibles casos de solución a futuras consultas.

I.2 Búsquedas por similitud

Por lo anterior y por la gran cantidad de áreas de las ciencias de la computación donde
uno puede llegar a enfrentarse con el mismo problema pero en diferentes escenarios, se ha
introducido un concepto que intenta unificar estos escenarios. Este concepto es el de búsquedas
por similitud que se basa en la siguiente idea: dado un conjunto, se busca encontrar los elementos
del conjunto más cercanos o similares al elemento de una consulta. Entonces, las búsquedas
dentro de un conjunto de objetos complejos, requieren de una manera de evaluar el nivel de
similitud entre los elementos del conjunto. Para ello se utiliza el concepto de función distancia (o
métrica) (Chávez et al., 2001).

Formalmente, dado un conjunto arbitrario X, una distancia o métrica es una función d

definida en el conjunto de parejas de elementos que satisface las siguientes propiedades.

Positiva.

Reflexiva. ,

Simétrica.

Desigualdad del Triángulo.

Dependiendo del conjunto al que se apliquen, estas funciones distancia pueden tomar un
pequeño conjunto de valores o la cantidad de los valores que pueden tomar puede ser infinita.
Dependiendo de lo anterior se pueden diferenciar entre discretas (si el conjunto de valores es
finito o numerable) y continuas (si el conjunto de valores es un intervalo de números reales)
(Chávez et al., 2001).
 9

Una vez que se han definido los elementos del conjunto y la manera en la que van a ser
comparados (es decir, se ha definido la distancia d), generalmente son tres los tipos de consultas
que se utilizan en el contexto de espacios métricos.

Búsquedas por Rango . Considera todos aquellos elementos del conjunto que
están a una distancia menor o igual que r del elemento q, esto es, los elementos del conjunto
.

Búsqueda del vecino más cercano. . Considera los elementos más cercanos a q
en , esto es . En algunos casos la búsqueda se satisface
con un elemento, normalmente esto sucede en espacios que son continuos. Además, se puede
definir un umbral como distancia máxima y se puede dar el caso de no encontrar el elemento más
cercano en el radio correspondiente al umbral, entonces la respuesta es que no existe ningún
elemento que satisface la condición.

Búsqueda de los k-vecinos más cercanos. . Considera un conjunto k de

elementos más cercanos a q en . Esto es, un subconjunto tal que y tal que
.

I.3 Recuperación de objetos multimedia

El recuperar objetos multimedia por contenido, es una particularidad del problema de

búsquedas por similitud y se puede definir de la siguiente manera: dado un conjunto de objetos,
determinar si un nuevo objeto pertenece a dicho conjunto y si así fuera, con cuáles de los
elementos del conjunto se identifica.

Considere el siguiente ejemplo: suponga que se cuenta con un repositorio con millones de
canciones y se quiere obtener información en este repositorio de la canción “19 días y 500
noches”. Se podría utilizar el enfoque tradicional de bases de datos para poder llevar a cabo la
recuperación de un objeto, pero entonces, primero hay que representar con metadatos a cada uno
de los elementos del repositorio. Un metadato es información adjunta a un documento que
describe alfanuméricamente el contenido del documento. Para después hacer una estructura de
 10

columnas y campos con los metadatos, tarea que es bastante costosa dado que a un profesional le
lleva alrededor de 30 minutos el etiquetar una canción y además la consulta que se aplica para
este caso y con este enfoque, requiere de un conocimiento previo de la canción que se quiere
recuperar, en este caso el nombre de la canción. Por otra parte, una consulta más natural sería el
someter un fragmento, un silbido o un tarareo de la canción y comparar todos aquellos elementos
en el repositorio no por una descripción de éstos, sino directamente por el contenido de
información que tienen las señales de audio.

Ahora supongamos que el mismo problema se llevara a un escenario real. Imagine que
va manejando por la carretera y de pronto escucha que se transmite por la radio una canción que
tiene años queriendo saber su nombre. Lo ideal sería grabar 10 segundos de esta canción con el
teléfono celular y someterlo como consulta a un sistema de recuperación de audio, para obtener
como resultado información de la canción. Si bien pareciera ser el mismo problema anterior, las
deformaciones que sufren las señales en escenarios reales afectan directamente a la información
que arroja el contenido de éstas. En particular, en este caso podría darse una combinación de
deformaciones por regrabación con pérdida por compresión, tal vez con un poco de
desplazamiento, etc., y es la recuperación de objetos multimedia a pesar de las deformaciones
que sufren los elementos los que definen qué tan robusto es un sistema de recuperación
multimedia.

I.4 Representación perceptual de objetos multimedia

Para poder hacer uso de técnicas de recuperación de información en texto, en particular

de índices que hagan que las técnicas de recuperación de objetos multimedia escalen, es
necesario hacer un proceso previo o representación de los elementos, por ejemplo en audio se
hace un proceso previo de las señales y se representan con los llamados “audio fingerprints” o
huellas. Estas representaciones tienen como objetivo principal, el mantener la igualdad
perceptual de dos objetos multimedia, y el no tener que comparar los objetos sino las
representaciones de éstos. La mayoría de los sistemas de recuperación de objetos multimedia en
la actualidad cuentan con una gran base de datos de objetos multimedia junto con sus respectivos
 11

metadatos y por otra parte, se construyen las representaciones de los objetos que están asociados
cada uno a un objeto del conjunto generando un índice con las representaciones. Entonces, las
búsquedas por contenido se realizan primero obteniendo la representación de la consulta y
comparándola con las representaciones de los objetos multimedia en la base de datos, para
después obtener información útil del objeto original o de sus metadatos.

Las ventajas de utilizar las representaciones de los objetos multimedia en vez de usar el
contenido de la señal directamente son:

 Reducir la memoria de almacenamiento, ya que las representaciones son de dimensiones

más pequeñas que los objetos en sí.
 Comparar eficientemente, ya que únicamente se representan aquellas características de
los objetos que se perciben, lo demás se suprime.
 Eficiencia en la búsqueda, ya que el conjunto de datos necesarios para dar respuesta a una
consulta es más pequeño en términos de dimensionalidad.

La representación de los objetos multimedia, se puede definir como un resumen del

contenido del objeto multimedia. Por ello, se tiene una función que mapea un objeto
multimedia , que consiste en un largo número de bits, a su representación que consta de
unos cuantos bits (Haitsma y Kalker, 2003).

Hasta este punto, uno podría confundirse con las funciones hash conocidas en el área de
criptografía. Una función hash mapea un objeto multimedia normalmente grande a su
representación hash pequeña normalmente, haciendo posible comparar dos objetos
comparando solamente los valores hash . Pero solamente si los objetos son
estrictamente iguales los valores hash también lo son con una probabilidad de error muy baja.
Este tipo de funciones se pueden usar para buscar un objeto que está contenido en un conjunto de
objetos multimedia, pero solo si el objeto está sin ninguna deformación, en el conjunto (Haitsma
y Kalker, 2003).

Suponga que dentro de una biblioteca digital de música se cuenta con la versión original
de la canción de Joaquín Sabina “nos sobran los motivos”. Con calidad de grabación de estudio a
128 Kb suena igual o muy parecido a la misma canción grabada en vivo en un auditorio, pero el
contenido que arrojan los espectros de ambas canciones son distintos. Por esto, las funciones
 12

hash no pueden decidir si dos canciones son perceptualmente iguales y peor aún, las funciones
hash son altamente sensitivas por lo que un cambio en un bit en el objeto resulta en una
representación totalmente distinta.

Ahora el por qué no se pueden realizar representaciones exactamente iguales para objetos
multimedia que son perceptualmente iguales, es porque la percepción de similitud no se puede
modelar matemáticamente ya que no cuenta con la propiedad de transitividad. Esto es, si un par
de objetos son perceptualmente similares a , y por otro lado también son similares
esto no implica que sean similares (Haitsma y Kalker, 2003).

Lo que se busca entonces es encontrar una función que represente los objetos que
pueda discriminar entre objetos multimedia, es decir, si los objetos son distintos entonces las
representaciones también deben ser distintas. Si se define un umbral , si dos objetos son
similares entonces , de lo contrario .

Se puede observar que se trata de una función tal que de un espacio métrico se mapean
los objetos a otro espacio métrico buscando que los objetos mantengan su similitud perceptual
(robustez), fiabilidad, tamaño, velocidad en las búsquedas y escalabilidad.

Una vez que se representan los objetos multimedia y la manera en cómo se van a
comparar estos objetos, el siguiente paso es ver cómo reducir el número de comparaciones entre
representaciones para dar respuesta a una consulta. Esto regularmente se hace mediante el uso de
un índice, que es una estructura de datos que tiene como tarea lo anterior.

En la Figura 6 se muestra el proceso genérico para la recuperación de objetos multimedia.

Una métrica para evaluar similitud, una técnica de indizamiento y un criterio de búsqueda son
necesarios para la búsqueda de objetos multimedia por contenido.
 13

Figura 6. Proceso genérico para indizar y realizar búsquedas de objetos multimedia.

I.5 Objetivos

En esta sección se presenta el objetivo general del presente trabajo de investigacion, así
como los objetivos epecíficos planteados.

I.5.1 Objetivo General

Generar un marco de trabajo1, que sirva como base para poder desarrollar aplicaciones
que se desenvuelvan en escenarios donde se requiera solucionar el problema de búsqueda de
objetos multimedia por contenido.

1
En el desarrollo de software, un marco de trabajo es una estructura conceptual y tecnológica de soporte definida,
normalmente con artefactos o módulos de software concretos, con base en la cual otro proyecto de software puede
ser organizado y desarrollado. Típicamente, puede incluir soporte de programas, bibliotecas y un lenguaje
interpretado entre otros programas para ayudar a desarrollar y unir los diferentes componentes de un proyecto.
 14

I.5.2 Objetivos Particulares

 Generación del API2 de consulta necesario para recibir y dar respuesta a consultas
multimedia por contenido.

 Desarrollar una interfaz de usuario 3para la realización de experimentos con señales de

audio.

 Generar una base de datos con la representación de miles de señales de audio.

 Establecer las herramientas necesarias para la comparación de técnicas de recuperación

de audio por contenido.

 Realizar experimentos entre sistemas para la recuperación de audio por contenido.

I.6 Motivación

Los tipos de datos como imágenes, audio, video, etc., también llamados multimedia, no
pueden se pueden buscar en el sentido del enfoque tradicional de búsquedas exactas. No solo
porque no se pueden ordenar, sino porque el sentido perceptual de igualdad no se puede
comparar de manera exacta. No es importante encontrar un segmento de audio que sea
exactamente el mismo de una consulta, lo que si importa es encontrar segmentos cercanos que
sean muy parecidos a la consulta, aun si el segmento ha sufrido deformaciones.

2
. Interfaz de programación de aplicaciones o API (del inglés Application Programming Interface) es el conjunto de
propiedades y metodos, que ofrece cierta librería de programación para ser utilizada por otro software como una
capa abstracción.
3
La interfaz de usuario es el medio con que el usuario puede comunicarse con una máquina, un equipo o
una computadora, y comprende todos los puntos de contacto entre el usuario y el equipo, normalmente suelen ser
fáciles de entender y fáciles de accionar.
 15

El problema de buscar objetos multimedia de un conjunto los cuales son más cercanos a
una consulta dada bajo algún criterio de similitud o métrica, tiene un gran número de
aplicaciones.

En audio, los equipos dedicados a la investigación y creación de sistemas para la

recuperación de audio dedican sus esfuerzos a tres tipos de paradigmas que se han planteado en
este campo. “Query by Humming”, en este paradigma las consultas para la búsqueda son
fragmentos de canciones cantadas, tarareadas o silbadas (Haus y Pollastri, 2001). Otro
paradigma es el de “Query by Note” donde las consultas se transforman a su representación en
partituras musicales (Doraisamy y Ruger, 2002). Actualmente, en el campo de recuperación de
música, el paradigma más común es el de “Query by Example”, en el cual, las consultas son
formadas por un fragmento de una canción (Haitsma y Kalker, 2003). En general, la diferencia
entre estos paradigmas, es el tipo de consulta pero la tarea es la misma, recuperar de manera
automática información de una canción de una base de datos que contiene partes o aspectos
similares a la consulta. Algunas de las aplicaciones que motivan las búsquedas de audio por
contenido se enlistan a continuación.

Monitoreo de medio. Para obtener información relativa a la efectividad de un patrocinio

en una emisión de radio.

Detección de duplicación. Para determinar si dentro de una base de datos, dos archivos de
audio tienen el mismo contenido. Aunque muchas veces los objetos no son exactamente iguales,
corresponden a la misma canción. Esta herramienta es de gran utilidad para mantener la
integridad de la base de datos multimedia.

Etiquetado automático. En general, los reproductores proveen información de una base

de datos con el nombre de los archivos de audio, como el álbum, título, etc., pero si los datos de
determinado objeto multimedia no se encuentran en la base de datos, se podría hacer uso de las
técnicas de recuperación multimedia para encontrar información del objeto multimedia.

Búsquedas con ejemplos. Se utiliza un pequeño fragmento del audio para reconocer una
canción en particular. En la actualidad Shazam es la aplicación que ha obtenido mejores
resultados en esta clase de búsquedas.
 16

Filtrado de redes p2p. Cuando la música se transmite en redes de tipo punto a punto, los
“fingerprints” pueden se pueden obtener con los paquetes y buscados en una base de datos que
contenga los que están protegidos por derechos de autor.
 17

I.6 Metodología de investigación

La metodología utilizada para el desarrollo de este trabajo consta de seis etapas, las
cuales se muestran en la Figura 7. A continuación se describen las actividades llevadas a cabo en
cada una de las diferentes etapas durante el desarrollo de esta investigación.

Figura 7. Metodología de investigación aplicada en la generación de un marco de trabajo para la búsqueda de objetos
multimedia por contenido.

Etapa 1. Primero se realizó una revisión de bibliografía para conocer los alcances y limitaciones
que se tienen en el área de estudio.

Etapa 2. Se realizaron estudios de las diferentes maneras que se aplican en la actualidad para
representar el contenido de las señales. En esta etapa se eligió una técnica adecuada para el caso
de estudio.

Etapa 3. En esta etapa, se estudiaron las distintas estructuras aplicadas a la búsqueda de objetos
multimedia con el fin de escoger una que se pudiera acoplar con la representación de señales
elegida.

Etapa 4. Se desarrolló una interfaz de consulta que es capaz de recibir consultas por contenido y
buscar información de canciones similares a la consulta.

Etapa 5. Se generaron escenarios reales de posibles deformaciones de la señal que la interfaz de

consulta puede enfrentar.

Etapa 6. Finalmente, se evaluó el comportamiento de la interfaz de consulta realizada

comparándola con otra interfaz que, por su popularidad, actualmente se toma como referencia.
 18

1.7 Organización de la tesis

El presente documento se desarrolla en siete capítulos, mismo que se describen

brevemente a continuación.

En el Capítulo I se explican los conceptos básicos del marco teórico, presentando el

problema de búsquedas de objetos complejos, además de motivar la necesidad de solventar este
problema en diferentes escenarios.

En el Capítulo II se presenta el caso de estudio de interés en esta tesis. Particularidades y

escenarios de aplicación se describirán a detalle.

En el Capítulo III se presenta el estado del arte en recuperación de audio. En esta parte se
llevara a cabo una recopilación de formas de representar una señal y formas de indexar un
conjunto de representaciones de señales. Para después mostrar algunas aplicaciones que realizan
la tarea de recuperación de audio en algunos escenarios.

En el Capítulo IV se propone una forma de resolver el caso de estudio de interés, además

se presenta la librería de programación natix, la interfaz de consulta songIndex, y la manera en la
que estos interactúan.

En el Capítulo V se detalla una la construcción de un índice basado en el funcionamiento

de tablas hash, para después poder recuperar información de este índice, haciendo uso de una
métrica probabilística.

En el Capítulo VI se explica el diseño de los experimentos realizados. Características y

parámetros de los experimentos son detallados. Primeramente se experimenta con la interfaz de
consulta, para después experimentar con el índice LSH.

En el Capítulo VII se presentan las conclusiones en base a los resultados obtenidos, las
aportaciones al estado del arte y el trabajo a futuro con respecto a la línea de investigación que se
siguió en este trabajo.
 19

CAPITULO II

Caso de estudio

II.1 Introducción

En años recientes, la investigación en el reconocimiento de música ha sido motivada por

los enormes avances en el cómputo y digitalización de señales, y adicionalmente, el uso en
crecimiento de tecnologías de información, que permiten a los usuarios acceder y experimentar
con el contenido multimedia a escalas sin precedentes.

En la actualidad, se puede tener acceso fácilmente a la música en su forma digital, de tal

manera que las bibliotecas digitales de música pueden sin ningún problema exceder el tiempo
que tenemos para escucharlas, por ejemplo, 10 mil canciones en una biblioteca digital de música
que se encuentra en un dispositivo de reproducción personal tiene un total de aproximadamente
30 días de audio continuo.

La necesidad de desarrollar estrategias que permitan el acceso a colecciones de música,

es impulsada por las expectativas de funcionalidades como búsqueda y navegación. Estas
estrategias en conjunto se llaman Music Information Retrieval (MIR) y ha sido el tema de un
intenso estudio de una comunidad académica cada vez más grande y de laboratorios de
investigación industrial.

En el presente, el método más común de acceder a la música es a través de metadatos.

Los metadatos consisten en textos descriptivos o etiquetas adjuntas al documento que expresan el
contenido de las canciones, por lo que hay muchos escenarios en los cuales este método es
suficiente. Sin embargo, cuando las bibliotecas multimedia se hacen muy grandes (más de 100
mil canciones), es extremadamente difícil mantener los metadatos consistentes que expresen las
descripciones, debido a que se tiene que realizar una descripción manual por cada una de las
canciones. Se ha estimado que a un experto en música le toma alrededor de 20 a 30 minutos
realizar los metadatos descriptivos de una canción. El costo entonces es enorme en el tiempo que
 20

toma el preparar una biblioteca digital de música que contiene toda la información necesaria para
realizar búsquedas basadas en metadatos. Para el caso de una biblioteca digital de música de un
millón de canciones, realizar los metadatos tomaría aproximadamente 50 años.

Los metadatos son el conductor para los sistemas de MIR. Por ello, existen servicios
dedicados a brindar metadatos confiables para bibliotecas digitales de música. La mayoría de los
usuarios que escuchan música, utilizan metadatos en los ambientes de reproducción que utilizan.

Para que un sistema de metadatos funcione, las descripciones deben ser precisas y el
significado del vocabulario de los metadatos debe ser comprensible. El realizar este proceso por
contribución de usuarios, asegura que por lo menos una comunidad obtenga información
consistente, pero diferencias culturales, de caracteres especiales, distintos alfabetos, etc. hacen
aun más difícil mantener consistentes las bases de datos de metadatos para todas las
comunidades.

Además de la descripción que brindan los metadatos a las canciones, el contenido de las
señales de audio se puede utilizar para ayudar a los usuarios a buscar música. Lo interesante de
los métodos que se basan en el contenido de la música es que identifican lo que los usuarios
desean encontrar, aun sin que éstos conozcan completamente lo que están buscando.

Un posible escenario de aplicación donde se pueden utilizar métodos basados en

contenidos es al estar frente a una computadora, o algún dispositivo de captura como un teléfono
móvil, y realizar una consulta en forma de un fragmento de una canción cantada, silbada o
grabada. El dispositivo acepta la consulta, y automáticamente muestra en una pantalla una lista
con las sugerencias a las posibles canciones que pueden parecerse a la consulta solicitada.

Un ejemplo de este tipo de aplicaciones, es el caso de un reproductor de música que

además de realizar las tareas comunes de reproducción, cuenta con motor de búsqueda que
permite buscar en toda una colección de música. La consulta se puede realizar de varias maneras
como con el ritmo, un fragmento o silbando la canción. Entonces, el motor de búsqueda acepta la
consulta y recupera una lista con canciones que se encuentran dentro de la colección, y que están
musicalmente relacionadas a la consulta.
 21

II.2 Escenario de aplicación

En el presente trabajo, el problema de búsquedas de audio por contenido se enfoca a las

bibliotecas digitales de música personales, que por lo general en la actualidad escalan a miles de
canciones (en una colección de este tipo). Pero ¿qué tan fiable es la información con la que
cuentan dichas canciones o elementos de la colección? Normalmente los metadatos de una
canción varían su calidad dependiendo del origen de dicha canción. Es decir, se sabe que una
canción puede haber sido adquirida de muy diversas fuentes, como por ejemplo, grabada desde
un disco compacto original a nuestra computadora, que si este fuera el caso, normalmente estas
canciones tienen metadatos muy confiables, pero si la canción fue grabada con el celular o si se
descarga de una aplicación p2p, en este caso normalmente no se cuentan con metadatos y por lo
tanto, no se puede afirmar que la información que brindan los metadatos es confiable.

Por lo anterior, se puede pensar que una manera de obtener información que sea fiable
para las canciones de una biblioteca digital, es utilizando el contenido mismo de las canciones.
La idea central se muestra en la Figura 8, donde se puede observar que al tener una colección
con miles de canciones que cuentan con metadatos fiables, se pueden compartir metadatos con
señales que son musicalmente similares con algún elemento en la colección. El poder encontrar
un elemento de dicha colección se basa en buscar características similares entre un elemento que
no pertenece a la colección y el contenido de los elementos de la colección.

En la actualidad, el medio principal para acceder a las bibliotecas digitales de música son
los reproductores multimedia, que en general, presentan los metadatos de cada canción y
permiten hacer búsquedas y filtros sobre dicha información. Básicamente, el enfoque que se
sigue al hacer uso de estos buscadores, es el enfoque clásico de bases de datos relacionales,
donde para poder hacer comparaciones entre canciones, primero se tienen que verter en una
estructura definida, en este caso dividida en campos, para después hacer estas comparaciones con
el valor de los campos. Supongamos el ejemplo de la Figura 8. Para todas las canciones de la
colección se tienen que extraer los metadatos para después organizarlos e insertarlos en una
tabla; esto con el fin de poder hacer comparaciones de elementos alfanuméricos que representan
a las canciones en dicha tabla.
 22

Figura 8. Proceso para generar tabla relacional con metadatos.

Si bien se pueden encontrar elementos usando este enfoque, el hacer búsquedas sobre
estructuras clásicas como las tablas de bases de datos tradicionales es un método que no escala
para colecciones muy grandes. Por otra parte, para poder hacer una consulta sobre una
representación alfanumérica de una canción, se debe tener un conocimiento previo de lo que se
está buscando, es decir, para poder encontrar la canción “Nos sobran los motivos”, se tiene que
conocer previamente ese nombre de canción. En este caso la consulta tradicional sería de esta
forma “select * from tabla where canción=Nos sobran los motivos”, y como resultado regresaría
el registro de la tabla que cumple con esta condición.

De lo anterior, se puede observar la necesidad de contar con una manera de consultar

teniendo el conocimiento de alguna característica textual de la canción. Es decir, poder someter
una característica perceptual de la canción como consulta y obtener el elemento o los elementos
de la colección que sean similares musicalmente a esta canción.

Los escenarios de aplicación del caso de estudio en el que se enfoca el presente trabajo
son muchos y se van incrementando; esto debido primeramente por la cantidad de música
alrededor del mundo, no tan solo de orígenes fiables como un disco compacto realizado en un
estudio de grabación, sino por todas aquellas grabaciones que se realizan por personas ajenas a la
industria musical. Sumado a lo anterior, en la actualidad una colección significativa de canciones
 23

sin metadatos, son las transmisiones que se hacen en internet. Son muchas las fuentes de música
alrededor del mundo, pero muy pocas cuentan con información que se puede considerar fiable.

Un ejemplo de un escenario de aplicación es el siguiente: una estación de radio realiza

una transmisión continua 12 horas al día. Esta estación desea conocer datos estadísticos de las
canciones que se reproducen en el tiempo al aire. Al no existir metadatos sobre la transmisión, el
único medio con el que se cuenta para realizar esta tarea es el contenido de la transmisión. La
idea es ir tomando trozos de la transmisión y someterlos como consulta a una búsqueda, en
donde se busca encontrar la canción similar al trozo o consulta. Con este procedimiento la
estación podría obtener estadísticos interesantes de la reproducción de canciones en la radio.

En esta tesis son dos los escenarios de aplicación de interés. El escenario que se muestra
en la Figura 9 se desarrolla cuando de pronto alguien escucha en algún medio como la radio, la
televisión, el mismo internet o cualquier medio de reproducción de canciones, una canción que le
es familiar, del gusto o interesante al oído. Aunque los deseos pueden ser adquirirla y hacerla
parte de la colección de música personal o simplemente conocer el nombre de la canción para
tener información de esta canción que es particular a la persona de alguna manera, utilizando
métodos de búsquedas tradicionales, sin conocimiento previo de la canción no se puede realizar
otra actividad más que escucharla en el momento. Pero utilizando el contenido de la canción y
haciendo uso de algún dispositivo de captura como un micrófono, un teléfono celular, un
reproductor mp3, etc., se podría grabar un trozo de la canción para someterla como consulta a
una búsqueda y obtener como resultado una canción similar a la que recién se escuchó. Con esto,
el que ha escuchado la canción de la cual no tenía conocimiento, agranda las posibilidades de
conocer más acerca de la canción o en futuro disponer de esta canción.
 24

Figura 9. Diagrama del primer escenario de aplicación.

El segundo escenario de aplicación es el siguiente: se agrega una canción a nuestra

biblioteca digital de música. Esta canción pudo haber sido descargada, grabada en un concierto
con el celular, grabada con el micrófono de la computadora o simplemente grabada desde un
disco compacto. Los metadatos o información que se puede esperar de estas canciones son
inexistentes. Lo que en general en estos casos realiza un manejador de bibliotecas digitales de
música, es poner metadatos genéricos como “Track 01” a el nombre de la canción o “Artist
unknown” al nombre del artista. Si bien por la falta de metadatos es imposible recuperar
información con el método tradicional de búsquedas en bases de datos, el contenido de las
canciones de fuentes como las que se citan anteriormente, se puede utilizar como consulta y así
realizar una búsqueda que responda con aquellas canciones similares al contenido que se sometió
como consulta, para posteriormente brindar a canciones que contaban con metadatos genéricos,
metadatos propios de la canción. Con esto se puede mantener la consistencia e integridad de los
metadatos en una biblioteca digital de música.
 25

Figura 10. Diagrama del segundo escenario de aplicación.

En ambos escenarios de aplicación, el medio por el cual se realizan las búsquedas es el

contenido de la señal de audio, en este caso de una canción. Y si bien en el presente trabajo se
experimenta dentro de estos escenarios, también se puede experimentar el mismo problema en
escenarios que se desarrollan en autos, radiodifusoras, televisoras, aplicaciones en dispositivos
móviles, reproductores de música, entre otras. Lo anterior motiva la creación de aplicaciones que
brinden una solución a los escenarios de aplicación que se presentan en la actualidad.

II.3 Características del caso de estudio

En escenarios de aplicación en los que se centra el presente trabajo se requiere de una

forma de poder interactuar con las bibliotecas digitales de música. Esta interfaz debe contar con
características que faciliten la solución del problema de recuperación de música en los escenarios
 26

propuestos. La interfaz que permite la interacción de un usuario con las bibliotecas digitales de
música es el reproductor multimedia de uso cotidiano, este tipo de interfaces por lo general,
como se mencionó anteriormente, cuentan con las herramientas necesarias para realizar
búsquedas, navegación y filtrado sobre metadatos. Aprovechando las ventajas que brindan los
reproductores multimedia en la actualidad, en nuestro caso de estudio, serán estos la interfaz de
interacción con usuarios finales.

Figura 11. Representación de la interacción del reproductor de música en el caso de estudio.

Dentro de la interfaz que hace que un usuario interactúe con la biblioteca digital, debe
incorporarse una nueva forma de búsqueda por contenido. La manera más sencilla es agregando
al reproductor de uso cotidiano la funcionalidad de buscador. Este buscador debe ser capaz de
aceptar consultas que utilicen el contenido de las canciones y dar como resultado información o
metadatos fiables, que posteriormente el manejador de bibliotecas digitales de música en este
caso el reproductor de música, pueda hacer uso de de estos.
 27

Una vez definida la interfaz de consulta, para este caso el reproductor multimedia, las
búsquedas por contenido se llevarán a cabo dentro de éste. Para el primer escenario el proceso es
el siguiente: como se muestra en la Figura 12, la obtención de una consulta se hace utilizando el
micrófono, del cual se graban 10 segundos de una canción que como ya se mencionó
anteriormente puede provenir de fuentes diversas. Esto con el fin de obtener desde medios ajenos
al manejador de bibliotecas digitales de música, información de posibles canciones de interés de
un usuario.

Figura 12. Diagrama a detalle del primer escenario de aplicación.

Para el segundo escenario como se muestra en la Figura 13, la consulta se obtiene

tomando aquellas canciones que pertenecen a la biblioteca digital de música, pero no cuentan
con metadatos fiables con los que se puedan hacer búsquedas ni filtrados usando el buscador
convencional de un reproductor multimedia. Entonces, tomando el contenido de estas canciones
y sometiéndolo como consulta en el buscador de música por contenido, se espera como respuesta
 28

los metadatos necesarios para etiquetar con esta información las canciones que anteriormente
contaban con metadatos genéricos. Este escenario lo motivan las colecciones de miles de
canciones de música que se encuentran desorganizadas, por no contar con metadatos.
Resolviendo el problema de reconocimiento de música por contenido en este escenario se brinda
una solución para mantener organizadas las bibliotecas digitales de música.

Figura 13. Diagrama a detalle del segundo escenario de aplicación.

 29

CAPITULO III

Estado del arte.

III.1 Introducción

La búsqueda en conocimiento digital comenzó hace varias décadas cuando los medios
para la digitalización de información era ya algo común, pero en realidad, los libros seguían
siendo el principal medio para conservar y transmitir el conocimiento. Previo a la existencia del
campo de investigación en recuperación de información multimedia, se realizó una reunión de
una comunidad científica, donde se hicieron contribuciones de una gran cantidad de campos ya
existentes de distintas áreas. Desde una perspectiva teórica como la inteligencia artificial,
optimización teórica, visión por computadora, y reconocimiento de patrones, hicieron
contribuciones significativas para las bases matemáticas fundamentales de las búsquedas
multimedia por contenido.

En la Figura 14, se muestra cómo son en la actualidad las etapas del proceso para realizar
una aplicación de recuperación de audio por contenido. La primera etapa es la obtención de las
representaciones de las señales de audio o AFPs; en esta etapa son varias las decisiones que se
debe tomar. Primero cuál es la característica perceptual que se tomará en cuenta para representar
la señal. Una vez tomada esta decisión, implícitamente se decide en cuál dominio se trabajará, si
bien existen técnicas como la utilizada por (Kurth y Scherzer, 2003), que trabajan directamente
en el dominio amplitud-tiempo, la mayoría de las técnicas realizan una transformación de
dominio para trabajar con la frecuencia de la señal.

Una vez extraída la característica de la señal que se toma en cuenta, el siguiente paso es
cómo representar o modelar esa característica, es decir, cómo insertar esa característica en una
estructura de datos que mejore el rendimiento de la técnica. Son varias las técnicas de modelado
de características y se han utilizado estructuras como vectores, vectores binarios, estadísticas de
las propias características extraídas, etc. Más adelante se describirán con más detalle las técnicas
que se utilizan en la actualidad para modelar las características de una señal.
 30

Figura 14. Flujo de preguntas para generar una técnica de recuperación de objetos multimedia.

Después de definir la manera en la que se representarán las señales de audio, es decir, la

técnica que se usará para generar AFPs, el siguiente paso es encontrar la forma de comparar estas
representaciones. Esta forma es definiendo una función de distancia que refleje qué tan similares
son dos AFPs. Una vez seleccionada esta función, queda definido el espacio métrico del cual
forman parte los elementos de la colección. En cuanto a las distancias que pueden definir el
espacio se pueden clasificar en dos tipos. Por un lado están las discretas que son funciones que
toman solamente un conjunto finito o numerable de valores predefinidos y por otra parte están
las continuas, funciones cuyo conjunto de valores es un intervalo (no numerable).

Una vez que se ha definido el espacio métrico, la siguiente etapa es encontrar la forma en
la que las búsquedas puedan responder de manera eficiente. En esta etapa es donde entran las
técnicas de recuperación de información, particularmente la creación de índices. Con estos
 31

índices se realiza una estructura con la cual se mejora el tiempo que se requeriría comparar el
elemento por elemento para dar una respuesta a una búsqueda.

III.2 Extracción de características de la señal

Una manera natural de comparar señales de audio de una manera significativa, es

extrayendo una descripción abstracta que refleje aspectos relevantes perceptuales de esas señales.
En audio el nombre que se le da a estas representaciones son AFPs, además de una función de
distancia sobre la información extraída. Normalmente, una señal se segmenta en pequeños
pedazos, posiblemente marco traslapados lo suficientemente pequeños tales que distinguen
varios eventos en un marco.

En (Wold et al., 2002) se clasifican una serie de características acústicas perceptuales de

una señal de sonido que se pueden analizar.

Volumen, se obtiene una aproximación con la raíz cuadrada, la cual se calculad

obteniendo una serie de marcos de sonido a los cuales se le aplica una ventana y procesando la
raíz cuadrada de la suma de los cuadrados de los valores de la muestra después de aplicar la
ventana, es como se obtiene una aproximación del volumen.

La nota, se estima obteniendo la transformada rápida de Fourier después de haber

dividido la señal en marcos. Para cada uno de estos marcos, se miden la frecuencia y la amplitud
de los picos y utilizando el algoritmo del máximo común divisor se obtiene una aproximación de
la nota de una señal.

El tono de la señal, es una medida de las altas frecuencias con las que cuenta la señal,
como ejemplo el poner las manos en la boca cuando se quiere hablar disminuye el brillo del
sonido como el volumen también. Se calcula como el centroide del espectro magnitud después
de aplicar la transformada rápida de Fourier.
 32

La característica ancho de banda es la magnitud del promedio de los valores del espectro
y el centroide del mismo. Por ejemplo, una señal simple como la senoidal tiene un ancho de
banda cero, pero una que cuenta con mucho ruido tiene un alto ancho de banda.

Otras características son “Mel-filtered Cepstral Coefficients” normalmente abreviados

MFFCs, y se obtienen aplicando una serie de filtros triangulares a la transformada de Fourier. La
palabra “cepstrum”, es una variación de la palabra en inglés “spectrum” que indica la
transformación del espectro en algo que describe mejor las características del sonido que son
percibe el oído humano. Un mel es la unidad de medida para la nota percibida en un tono. El
oído humano es sensible a cambios lineales debajo de los 1000Hz y cambios logarítmicos arriba
de 1000Hz. Un “Mel-filter”, es un filtro que se aplica para escalar la frecuencia y tomar en
cuenta el factor anterior.

La representación “Joint acoustic and modulation frequency” (JAMF) es una

transformación en el tiempo de la demodulación del estimado del espectro en corto plazo. Para la
mayoría de las señales tales como música, el estimado del espectro en corto plazo cambia con el
tiempo. Si una señal se observa por mucho tiempo y el espectro cambia periódicamente, entonces
la señal se puede modelar como un ciclo estacionario (Sukittanon y Atlas, 2002).

Existen otras características que han sido tomadas en cuenta, algunas como Spectral
Flatness Measure (SFM) (Herre et al., 2002), Spectral Crest Factor (SCF) (Herre et al., 2002),
Spectral Sub-Bands Centroids (SSC) (Seo et al., 2005), Spectral Sub-Band Moments (SSM) (Kim
y Yoo, 2007), el signo de la energía en la segunda derivada (Haitsma y Kalker, 2003) y valores
croma (Pauws, 2004).

En (Seo et al., 2005) se muestra cómo con la normalización de los SCC se tiene una
técnica más robusta que los MFCC. En (Kim y Yoo, 2007) se mostró que la normalización de
JAMF es más robusta que estimados en el espectro para compresión y ecualización.

En (Herre et al., 2002) se reporto que SFM es más robusta que el volumen y también que
SCF. Por ello SFM lo adoptó el estándar MPEG-7 con fines utilizarse en AFPs.
 33

III.3 Modelado de las características

Una vez escogida la característica a ser tomada en cuenta dentro del contenido de la
señal, el siguiente paso con fines de AFPs es modelar esas características en una estructura para
compararse posteriormente. Algunas estructuras que se utilizan, se enlistan a continuación.

Trayectorias (Trayectories). Las características extraídas en espacios iguales de tiempo

se guardadan en listas de vectores o tablas, un renglón por ventana. Un ejemplo es la trayectoria
utilizada en vector binario en (Haitsma y Kalker, 2003).

Estadísticas (Statistics). A diferencia de las trayectorias, solamente guardan información

estadística en un vector más corto. En MPEG-7 (Allamanche et al., 2001) se procesa la media, la
varianza y el valor máximo y mínimo de los valores cada 32 marcos. Entonces, las
comparaciones se hacen utilizando únicamente esos valores que se calculan previamente.

Códigos (CodeBooks). Las características obtenidas del contenido de la señal se

remplazan por un valor perteneciente a un conjunto finito de valores llamado “codebook”.

Cadenas (Strings). Las trayectorias pueden ser cadenas grandes de enteros usando la
cuantificación de vectores. Con esto se tratan a las señales como texto para usar técnicas un poco
más flexibles en las búsquedas (Guo y Siegelmann, 2004).

Vectores (Vectors). Este modelado de características es el más compacto, se construyen

normalmente promedios de la característica elegida, es decir, unos cuantos valores representa la
señal completa.

Sumando a la tarea de extraer características, el modelado de características, en señales

de audio, se genera una técnica para la obtención de un AFP y son éstas las representaciones del
contenido al que se hacía referencia con anterioridad. El proceso genérico de obtención de un
AFP se muestra en la Figura 15.
 34

Figura 15. Proceso genérico para la obtención de un AFP.

La elección de la técnica para obtener AFPs de un sistema depende de las necesidades

del mismo sistema. Algunas técnicas poseen invariancia a ciertas transformaciones, con otros se
tiene la ventaja de rapidez en la búsqueda y otros pueden poseer otro tipo de ventajas, por lo que
es importante conocer las fortalezas y debilidades de cada técnica.

Una vez representadas las señales con los conjuntos de características a partir de alguna
propiedad del contenido, entonces se pueden realizar comparaciones utilizando dichos conjuntos.
Para realizar estas comparaciones, se utiliza una medida de similitud, propia de la técnica
 35

utilizada. Una medida de similitud entre una consulta y una señal de audio de la base de datos
indica el parecido entre ambas mediante algún valor o porcentaje según sea el caso.

III.4 Búsquedas en espacios métricos

Un espacio métrico utilizado para la recuperación de audio lo conforma el conjunto de

representaciones de señales de audios o AFPs y la función de distancia que representa la
similitud perceptual que existe entre los elementos de dicho conjunto.

En el caso general de espacios métricos la única información que se puede obtener del
conjunto es la distancia entre los elementos del conjunto, pero evaluar distancias es costoso
computacionalmente. El enfoque al hacer uso de espacios métricos es ser capaz de realizar de
manera eficiente y precisa una búsqueda sobre los elementos de dicho espacio. Son algunos los
avances que se han hecho en el caso general de espacios métricos, los mejores resultados utilizan
índices cuyo objetivo es evaluar el mínimo número de distancias en una consulta.

En cuanto a las distancias que pueden definir en el espacio, se pueden clasificar en dos
tipos. Por un lado están las discretas que son funciones que toman solamente un conjunto finito o
numerable de valores predefinidos. Un ejemplo de este tipo de funciones es la siguiente:
Considerar un conjunto arbitrario no vacío y la función definida por

Se puede comprobar fácilmente que esta función cumple con los axiomas necesarios para
tomarse en cuenta como métrica o distancia, además solamente puede tomar dos valores, por lo
que el espacio formado se llama espacio métrico discreto.

Por otra parte están las continuas, funciones cuyo conjunto de posibles valores es un
intervalo infinito. Un ejemplo de este tipo de funciones conocidas como , las cuales se definen
para vectores en y se definen de la siguiente manera.
 36

Además de poder clasificar las técnicas por el tipo de distancia que se utiliza para
comparar elementos, también se pueden clasificar las técnicas de acuerdo al tipo de algoritmo
utilizado en la indexación. Por un lado están los algoritmos basados en pivotes; en estos
algoritmos se escogen arbitrariamente un subconjunto de elementos que se utilizan como
referencia para dar una respuesta rápida a una consulta. El otro enfoque es el de los algoritmos
que realizan particiones compactas del espacio.

Los algoritmos basados en pivotes, usan de manera directa o indirecta el siguiente

proceso para realizar búsquedas de rango: si el universo de objetos se denota por , entonces la
base de datos es un subconjunto de objetos . Dado el espacio métrico definido por
(donde es la métrica o distancia definida para ), un objeto llamada consulta y un rango
de tolerancia , una consulta por rango se define como los elementos en que están
dentro de una distancia menor o igual que de (Bustos y Navarro, 2004).

Entonces, para una búsqueda por rango y un subconjunto de pivotes

, por la desigualdad del triangulo se tiene que para cada elemento se
cumple que y también que . Puesto
que los elementos que interesan son aquellos que satisfacen , entonces, se
pueden excluir los elementos que cumplen esta condición de exclusión:
para algún pivote sin tener que evaluar (Bustos y Navarro, 2004).

Si el espacio tiene elementos, entonces para crear el índice se requieren evaluar

distancias entre cada elemento y cada pivote. Por esto, cuando se somete una consulta es
necesario evaluar distancias entre los pivotes y la consulta (Bustos y Navarro, 2004).

Son varios los algoritmos usados para realizar búsquedas en espacios métricos que se
basan en pivotes, como el BKT Tree (BKT) (Burkhard y Keller, 1973), Fixed Query Tree (FQT)
(Baeza-Yates et al., 1994), Fixed Height Query Tree (FHQT) (Baeza-Yates, 1997), Fixed
Queries Array (FQA) (Chávez, 1999), Vantage Points Tree (VPT) (Yianilos, 1993), Multi
 37

Vantage Point Tree (MVPT) (Bozkaya y Ozsoyoglu, 1997), Excluded Middle Vantage Forest
(VPF) (Yianilos, 1999) y Approximating Elimating Search Algorithm (AESA) (Ruiz, 1986).

Figura 16. División del espacio tomando como pivote u11 (Chávez et al., 2001).

Por otra parte, existen las técnicas que utilizan algoritmos que como base tratan de dividir
el espacio en particiones o zonas lo más compacta posibles. Cada zona guarda un objeto
representativo al que se le llama centro, además de información que permite descartar una zona
completa al momento de realizar una consulta, sin tener que realizar las evaluaciones de los
objetos en la zona con el objeto de consulta. Cada zona se puede particionar recursivamente en
más zonas induciendo una búsqueda jerárquica. Existen dos criterios para realizar las particiones:
Voronoi partition y covering radius.

El diagrama Voronoi de una colección de objetos, es una partición del espacio en celdas,
donde cada una se compone de los objetos más cercanos a un centro que de cualquier otro. Un
subconjunto de m centros se seleccionan y los demás objetos se asignan a una zona por el centro
que se encuentre más cercano. Dada una consulta de rango , las distancias entre y los centros
se procesan. Suponga que es el centro más cercano a q. Para toda zona se satisface
 38

se puede descartar, porque la zona Voronoi no se intersecta con la zona

de consulta (Bustos y Navarro, 2004).

Un algoritmo que usa el criterio de Voronoi es Generalized Hyperplane Tree (GHT)

(Uhlmann, 1991).

Figura 17. Ejemplo de primer nivel de BST o GHT y una consulta q (Chávez et al., 2001) .

El criterio covering radius es la máxima distancia entre el centro y un objeto que

pertenece a su zona. Entonces dada una consulta de rango , si
entonces la zona no intersecta la zona de interés de la consulta por lo que los objetos de esa
zona se pueden descartar. La Figura 17 ilustra el criterio covering radius (Bustos y Navarro,
2004).

Algunas técnicas que utilizan el criterio covering radius son Bisector Tree (BST)
(Kalantari y McDonald, 2006), Monotonous Bisector Tree (MBST) (Noltemeier et al., 1992),
Voronoi Tree (VT) (Dehne y Noltemeier, 1987), M-Tree (MT) (Ciaccia et al., 1997).
 39

Figura 18. Ejemplo del primer nivel de un GNAT (Chávez et al., 2001).
 40

III.5 Aplicaciones

III.5.1 Shazam

Shazam es un sistema de recuperación de audio, que tiene como objetivo brindar una
herramienta para conectar a la gente con el ambiente de reconocimiento de música haciendo uso
del contenido de las señales. La técnica de recuperación de audio que utiliza en este sistema, se
mostro en (Wang, 2003), es robusta ante ruido ambiental y desplazamiento en el tiempo, además,
las búsquedas se realizan en el orden de milisegundos sobre una base de datos de más de dos
millones de canciones.

Esta aplicación tiene como objetivo tomar consultas de 15 segundos con un dispositivo
móvil. Estos 15 segundos se toman como consulta y se obtiene como resultado el candidato más
cercano a la consulta dentro de una colección de canciones, esto con el fin de dar al usuario la
opción de comprar la canción que se obtuvo como resultado. Los 15 segundos de consulta viajan
a través de internet y se realiza la búsqueda en servidores en donde se encuentra una colección de
canciones indexada.

Esta aplicación utiliza técnicas de extracción de AFPs para representar las señales de
audio, tanto las consultas como las canciones de la colección se someten al mismo análisis. El
análisis del cual se extraen valores de las señales las cuales se llaman valores hash. La respuesta
se obtiene encontrando un emparejamiento entre los valores hash que se obtienen de una canción
desconocida y las canciones de la colección para obtener candidatos posibles como el vecino más
cercano de la consulta.

Actualmente en este sistema se toman como entrada 15 segundos de audio para después
representar con AFPs las características de la señal. Cuentan con una colección de canciones de
más de 2.5 millones y la aplicación de Shazam es exclusivamente para dispositivos móviles.
http://www.shazam.com/

III.5.2.1 Técnica de extracción de AFPs

En esta técnica la característica a representar son los picos de frecuencia que ocurre en
una región de la señal, esto debido a la robustez de los picos de la frecuencia cuando se le aplica
 41

algún tipo de ruido a la señal original. Entonces, el primer paso para obtener la huella de una
canción es reducir el espectrograma complejo Figura 19. Espectro de la frecuencia de una señal
de audio. a como se muestra en Figura 20, en una constelación de puntos con coordenadas que
representan el tiempo en el que ocurren y el valor de la frecuencia. Un punto tiempo-frecuencia
es candidato para ser un pico, si dentro de una ventana es el punto que cuenta con el valor más
alto de frecuencia.

4000
3500
3000
Frecuencia

2500
2000
1500
1000
500
0
0 1 2 3 4 5 6 7 8 9
Tiempo

Figura 19. Espectro de la frecuencia de una señal de audio.

Si se grafican tanto los puntos tiempo-frecuencia elegidos como picos de una consulta y
los de una canción que pertenece a la base de datos. Se podría observar que en algún punto de la
gráfica de la canción completa, en la gráfica de la canción consulta en algún momento un
número significativo de puntos comienzan a ser iguales con respecto a la grafica de la canción
completa, esto comienza a darse una vez que se encuentra el desplazamiento que tiene la señal
consulta con respecto a la canción de la base de datos. Como se muestra en la Figura 21.
 42

4000

3500

3000

Frecuencia
2500

2000

1500

1000

500

0
0 2 4 6 8
Tíempo

Figura 20. Constelación de puntos tiempo-frecuencia. Cada punto en la gráfica representa el pico de frecuencia en una
región.

Los picos de frecuencia se toman de acuerdo a un criterio de densidad con el cual se

asegure que una serie de picos tiempo-frecuencia, representen de manera significativa el
contenido de la señal. Los picos se toman de acuerdo al valor más alto con la justificación que es
más probable que los picos de frecuencia se mantengan a pesar de que el espectro de la señal
sufra deformaciones.

4000

3500 Cancion en BD
3000 Consulta
Frecuencia

2500

2000

1500

1000

500

0
0 2 4 6 8
Tíempo

Figura 21. Gráfica tiempo-frecuencia de una consulta sobre puesta en la gráfica tiempo-frecuencia de una canción en la
colección.
 43

III.5.1.2 Técnica de indización

Los AFPs son un conjunto de puntos tiempo-frecuencia pertenecientes a un elemento en

una colección, estos puntos fueron elegidos por ser el pico de frecuencia en una región. Para
indizar esos puntos se toman en cuenta puntos de anclaje, un punto de anclaje es un punto que se
elige para combinarse con una zona objetivo. La combinación de los valores de un punto anclaje
y una zona objetivo se lleva a cabo secuencialmente concatenando cada punto de anclaje con los
puntos de la zona objetivo a la que pertenecen. Adicionalmente a la concatenación de los valores
de frecuencia se agrega la diferencia de tiempos en que ocurre cada valor.

4000
zona objetivo
3500

3000

2500
Frecuencia

2000

1500 punto anclaje

1000

500

0
0 2 4 6 8

Tíempo

Figura 22. Punto de anclaje representante de una zona objetivo.

Cada combinación de un punto de anclaje con los puntos de una zona objetivo representa
un valor hash y se representa con un entero de 32 bits. Además de estos 32 bits, se almacenan
tanto el tiempo que existe desde comienzo de la canción al momento en el que ocurre el pico de
frecuencia y también un identificador único en la colección para la canción, esto no es parte del
valor hash sino información adjunta. Para la información adjunta también se representa con un
entero de 32 bits por cada emparejamiento se guarda un objeto de 64 bits.
 44

4000

3500

3000

Frecuencia 2500

2000 (t2,f2)

1500
(t1,f1)
1000 t=t2-t1
500 hash|trackId: t1= [f1:f2:t]| trackId:t1

0
0 2 4 6 8

Tíempo

Figura 23. Representación de la generación de un valor hash.

Al realizar los valores hash utilizando la combinación entre puntos de anclaje y picos de
frecuencia en una zona, en lugar de buscar encontrar directamente de la constelación de puntos
tiempo-frecuencia se gana mucha aceleración en el proceso de búsqueda. Por ejemplo si en un
valor de frecuencia tiene a lo más una densidad de 10 bits, y t otros 10bits, entonces el hash a
encontrar consta de 30 bits de información, contra solo 10 si se tomaran puntos individuales.
Estos 20 bits hacen que el valor hash pueda ser millones de veces más grande, a su vez esto
ocasiona que el número de colisiones de un valor hash sea menor y por consecuencia, la
búsqueda sea más rápida.

Valor Hash Tiempo, id de la canción

82343 53.352, 2
82344 34.678, 1
82345 108.65, 4
… …
189231 34.945, 3

Tabla I. Tabla hash que representa la colección de canciones indexada.

III.5.1.3 Búsqueda y puntuación

Para realizar una búsqueda, la técnica de obtención de AFPs se aplica en una señal
desconocida, de la cual se obtienen un conjunto de valores hash. Cada valor hash que se obtiene
 45

se utiliza para buscar y encontrar en la colección de AFPs por valores hash iguales a los de la
consulta.

Para cada hash encontrado se toma en cuenta la información adicional con la que cuenta,
para este caso el tiempo con respecto al comienzo de la canción y el identificador. Los tiempos
son agrupados en bins. Cada bin representa el identificador de una canción de las cuales se
obtuvieron los valores hash. Cuando se terminan de buscar por todos los valores hash que se
obtienen de una consulta, se tiene una lista de bins que contienen tiempos de ocurrencia de
hashes que aparecen en una canción.

Para dar sentido en el tiempo de las ocurrencias de los valores hash en una canción
candidata, se hace uso de histogramas. Para cada bin de la lista que obtiene de la búsqueda de
hash en la tabla, se genera un histograma, donde como rangos de clase se toman en cuenta rangos
de tiempo. Entonces, lo que se grafica es el desplazamiento de la ocurrencia del hash en una
canción de la colección con respecto a la señal consulta. Supongamos que se encuentra un hash
en una canción de la colección, el tiempo en el que se encuentra ese valor con respecto a la
consulta es:

Donde es el tiempo en el que ocurre el hash en la colección y es el tiempo en el que

ocurre el mismo hash en la cosulta. Para cada par , se calcula:

Después se calcula el lugar en el histograma de los valores y se busca por el pico más
alto en el histograma. Esto lo hacen ordenando los y buscando el grupo más grande con el
mismo . Como los valores en cada bin es pequeño debido a la manera como se calculan los
valores hash, el tiempo de generación de un histograma es del orden de microsegundos para un
bin. La distancia entre una señal consulta y una canción en la base de datos es el pico más alto
que se genera en un histograma. Como se observa en la Figura 24, en una canción candidata no
se espera un pico con todos los valores hash de una consulta, pero sí significativamente más
grande que los demás rangos en el histograma.
 46

35

30

25

20

15

10

0
0 10 20 30 40 50 60 70 80
Rangos de desplazamiento

Figura 24. Histograma resultado de la comparación de una canción de la colección contra una consulta.

El algoritmo que utiliza Shazam ha demostrado ser robusto ante niveles significativos de
ruido y distorsión. Puede identificar música aun cuando existe la presencia de voces, ruido de
tráfico e incluso con música de fondo.
 47

CAPITULO IV

Propuesta de solución

IV.1 Introducción

Si bien el estado del arte para búsquedas de audio por contenido muestra que existen
varios sistemas propuestos que intentan dar una solución escalable al problema de recuperación
de música en ciertos escenarios de aplicación, en cada uno de esos sistemas se puede observar, el
proceso genérico para realizar búsquedas de algún tipo de objeto complejo. En la Figura 25, se
ilustra el proceso genérico para realizar búsquedas de audio por contenido. Este proceso no solo
aplica para objetos como audio, sino que también se generaliza para objetos complejos como
imágenes, video, cadenas de ADN, etc.

Figura 25. Proceso genérico para recuperar audio.

El proceso comienza dando una representación a las señales de audio o canciones para el
caso de estudio de interés. En este trabajo, se hizo uso de una técnica que toma como
característica a representar, la entropía de la señal. Esta técnica, presentada en (Camarena-
 48

Ibarrola y Chávez, 2006), considera como entrada una señal de audio y aplica un algoritmo que
como resultado genera una representación en forma de vectores binarios. Estos vectores binarios
tienen como ventaja el ser muy compactos y por ello se pueden utilizar en escenarios donde se
requiera de alguna manera la transferencia de las representaciones o AFPs.

Como se mencionó anteriormente el objetivo de esta tesis, es la creación de un marco de

trabajo, que sirva como base para la creación de aplicaciones de reconocimiento de objetos
multimedia. Este marco de trabajo tiene como primer objetivo particular, modelar el conjunto de
las representaciones de audio como un espacio métrico, es decir, una vez que se han representado
las señales de audio, el marco de trabajo debe contar con la capacidad de definir una función de
distancia, con el fin de realizar comparaciones entre las representaciones de las señales.

El segundo objetivo particular del marco de trabajo, es la creación de una estructura o

índice, que incluya todos los elementos del espacio métrico definido. Este índice tiene como
finalidad realizar búsquedas sobre los elementos del espacio métrico, de manera eficiente y
escalable.

IV.2 Técnica de obtención de AFPs

Las propiedades del escenario en el que se desenvuelve este trabajo, exigen de ciertas
características en la obtención del los AFPs. Por un lado las señales se enfrentan a deformaciones
de alto impacto en la variación del espectro debido a la regrabación, ruido y pérdida por
compresión entre otras, y por otra parte, puesto que las transmisiones de las representaciones se
realizan a través de internet, se requiere generar representaciones compactas para la transmisión
de los AFPs lo más rápido posible.

MBSES (Multi Band Spectral Entropy Signature) (Camarena-Ibarrola y Chávez, 2006),

es una técnica para la generación de AFPs que cubre los requerimientos del escenario de
aplicación. Se usa como característica del espectro, la entropía de la señal, la cual se define como
la cantidad de energía que el espectro lleva en un momento (Shanon y Weaver, 2001).
 49

En esta técnica se consideran aquellas bandas de frecuencia baja, que son las que mejor
percibe el oído humano. En la escala de frecuencia de Barks, se definen 25 bandas críticas para
la percepción del humano. En particular, en esta técnica se descartó la banda 25 de la escala de
Barks, no solo por el hecho de ser la que tiene la frecuencia más alta, sino además con fines de
mantener el AFP lo más compacto posible.

A continuación se enlistan los pasos para determinar los valores de entropía que toma
cada banda en la señal:

1. Si la señal está en dos canales se hace una conversión a un solo canal.

2. La señal se divide en marcos de 185 ms, con este tamaño se asegura un tiempo
adecuado para el proceso. El tiempo que se toma para la división de marcos varía
de 10 ms a 500 ms (Cano et al., 2005).
3. Los marcos se traslapan en un 75 por ciento, entonces un vector de características
se toma cada 46 ms.
4. A cada marco se le aplica una ventana de Hann y después se aplica la
transformada rápida de Fourier.
5. Se procesa la entropía de Shannon para las 24 primeras bandas críticas de la
escala de Bark, descartando solamente la banda 25 por ser la de frecuencia más
alta y casi imperceptible por el oído humano.

Este algoritmo, arroja como resultado un vector con 24 valores de entropía, uno para cada
banda de la escala de Bark. Entonces, para un pedazo de canción de 5 segundos, se obtiene una
matriz de 24 columnas por 24 renglones en donde las columnas representan las bandas y los
renglones representan los marcos, el número de renglones crece dependiendo del tiempo que se
toma de la canción y el tamaño de los marcos en los que se divide la señal. En la Figura 26, se
ilustra el ejemplo anterior.
 50

Figura 26. Representación de la entropía en escalas de grises.

Para definir el paso de codificación en esta técnica, simplemente se usa un indicador para
notar si la entropía en una banda sube o baja en un marco . La relación que define la
codificación es la siguiente:

donde representa la entropía en la banda y en el marco .

De la relación anterior, se puede observar que el bit que corresponde a la banda y al

marco del AFP se determina usando los valores de la entropía del marco y del marco
para la banda .

Después de someter una canción al proceso de obtención de AFPs, el resultado es una

matriz binaria que cuenta con 24 columnas, cada una de las cuales representa una banda de la
escala de Bark, y el número de renglones depende de la cantidad de marcos en que se divide la
señal. En la Figura 27, se muestra la representación de la matriz binaria usando colores blanco y
negro como representación de los valores que pueden tomar las celdas.
 51

Figura 27. Representación de una canción con MBSES.

El proceso completo para la obtención de un AFP que representa a una canción y un

elemento en el nuevo espacio métrico es el que se muestra en la Figura 28.

Figura 28. Proceso para la obtención de un AFP con MBES.

 52

IV.2 Librería Natix

El marco de trabajo propuesto en el presente trabajo, es la librería Natix la cual es una

librería de programación que sirve como base para generar aplicaciones que tienen como
requerimiento búsquedas en espacios métricos. Como se mencionó anteriormente, el caso de
estudio son las señales de audio, en particular la música, también se mencionó que el proceso de
búsquedas por similitud se puede aplicar en algunos objetos complejos que no se pueden
comparar con métodos tradicionales. Por lo tanto, si se da solución al caso de estudio propuesto,
el mismo proceso puede utilizarse para algún otro objeto complejo.

La creación de esta librería de programación, la motivada la gran cantidad de situaciones

en las que se requiere hacer el reconocimiento de una imagen por su contenido, de audio por
contenido, búsquedas en cadenas de ADN, etc. Desde el punto de vista de programación, la
mayor parte del código necesario para definir el espacio métrico y hacer que la respuesta de las
búsquedas sea escalable, se repite en los casos mencionados. Intentando no repetir todo el
proceso en cada aplicación a realizar, dentro de esta librería se realiza el trabajo necesario para
obtener respuesta a una búsqueda por similitud.

Si bien esta librería abstrae gran parte del trabajo necesario para realizar las búsquedas
por similitud, no realiza representaciones de objetos, es decir, esta librería toma como entrada las
representaciones de objetos complejos y una métrica o distancia, definida en el conjunto de las
representaciones. Como resultado, se obtiene un espacio métrico con el cual se construye una
estructura o índice, el cual permite aplicar criterios de búsqueda como el vecino más cercano,
búsquedas por rango y los k-vecinos más cercanos.
 53

Figura 29. Diagrama de interacción de Natix.

Una característica de la librería Natix, es que está escrita en Mono, un lenguaje de

programación orientado a objetos. La principal ventaja de utilizar este lenguaje es que usa
interfaces de programación, que definen la manera de trabajar dentro de esta librería. Las
principales interfaces modelan las dos entidades más utilizadas dentro de esta librería. Por una
parte la entidad “Espacio”, está definida por algunas interfaces que proponen las reglas para
extender la funcionalidad de esta librería, es decir, si se requiere definir un nuevo espacio
métrico dentro de la librería, el único requerimiento es implementar en una nueva clase, las
interfaces que definen la entidad “Espacio”. Esto con el fin de modelar dentro de la librería el
espacio métrico con el que se planea trabajar. El mismo caso es para la entidad “Índice”, entidad
que tiene como requerimiento principal el poder dar respuesta a los tres principales criterios de
búsquedas en espacios métricos, siempre intentando evadir el proceso de búsqueda secuencial
dentro del espacio métrico.

Como se puede ver, uno de los enfoques de esta librería es la utilización de interfaces
genéricas, lo cual permite modelar cualquier conjunto de elementos que se pueden comparar
entre sí además de tener la facilidad de representar todas aquellas estructuras e índices, que sean
aplicables a búsquedas en espacios métricos.
 54

Una vez que se han definido tanto el espacio, como el índice que se va a utilizar en una
aplicación particular, dentro de la librería se escribe el código que modela el comportamiento de
los elementos del espacio, la distancia entre ellos, y el índice sobre el cual se hacen las
búsquedas. Son varias las ventajas que brinda esta marco de trabajo y se enlistan a continuación.

 Abstracción de la construcción del espacio métrico. Esto se hace accediendo a un

método que toma como entrada los elementos del espacio y la función distancia
con la que se desea comparar los elementos.
 Generación del índice. El índice es generado a partir del espacio métrico y se
construye automáticamente, utilizando los parámetros asociados al índice, con lo
que se genera la estructura sobre la cual se comparan elementos para dar respuesta
a una búsqueda de algún elemento del espacio.
 Respuesta a criterios de búsqueda. Cada uno de los índices dentro de la librería
cuentan con la funcionalidad de dar respuesta a los tres principales criterios de
búsqueda en espacios métricos.

Estas tres etapas, conforman la mayor parte del proceso genérico para la búsqueda de
objetos complejos en espacios métricos, por lo que este marco de trabajo, no solo sirve como
base a señales de audio sino que también, puede ser la base para crear aplicaciones que requieran
la búsqueda de algún otro tipo de objeto complejo.

Debido a la arquitectura propia de esta librería, se podría pensar que tiene limitado su
margen en cuanto a las aplicaciones que se programan en la actualidad. Si bien esta librería está
escrita en el lenguaje específico Mono, con la introducción de los servicios web, el consumo de
la funcionalidad de las librerías puede realizarse desde cualquier lenguaje de programación y
arquitectura con la que se tenga planeado trabajar. La idea del funcionamiento de los servicios
web, es hacer invisible a la aplicación que consume el funcionamiento interno de la librería, la
estructura de la misma, pero poner a disposición las funciones que la librería puede llevar a cabo.
Con este tipo de tecnología se puede tomar la libertad de escoger entre diversas plataformas de
trabajo.

La ventaja de usar los servicios web para el caso de estudio, es poder continuar el trabajo
de aplicaciones que tengan funcionalidades ya implementadas, que sirven como plataforma para
 55

montar la funcionalidad de búsquedas por contenido sobre ellas. Para el caso de estudio estas
aplicaciones son los reproductores multimedia, cuya principal ventaja es tomar las funciones que
ya brinda un reproductor multimedia, al ser generalmente un manejador de bibliotecas digitales
de música. Al realizarlo así, se evita tener que repetir la escritura de código necesario para
realizar listados de canciones, presentación de metadatos y otras funciones que ya brinda
cualquier reproductor de uso cotidiano.

Figura 30. Utilización de servicios web con Natix.

IV.2 Técnica de indización.

Hasta este punto, se podrían realizar las búsquedas sobre el espacio métrico definido
anteriormente por las representaciones de las señales de audio o AFPs extraídos, pero para poder
realizarlas, se tendría que comparar un elemento consulta con todos los elementos del espacio y
entonces, el tiempo de respuesta a una consulta dependería directamente de la cantidad de
elementos en el espacio. Para evitar lo anterior, se utilizó un índice presentado en (Chávez et al.,
2008), donde se introducen las técnicas de indización basadas en permutaciones. La idea central
es la siguiente: suponga el conjunto de elementos y , donde es un conjunto de
 56

elementos referencia tomados de forma aleatoria, llamados permutantes. Para todos los AFPs
dentro del conjunto, se define su permutación , la cual se conforma de los elementos de
ordenados de manera creciente, de acuerdo a la distancia con . En la Figura 31, se muestra un
ejemplo de cómo se obtiene una permutación.

Para realizar comparaciones entre permutaciones, se utiliza la métrica Spearman Rho

(Fagin et al., 2003) la cual se define como:

Para determinar esta métrica basta con obtener la permutación inversa de y y

calcular la distancia euclidiana de las inversas. Además, se pueden reducir los cálculos
necesarios, al obtener solamente la sumatoria del valor absoluto de las diferencias de las
inversas, evitando tener que calcular el cuadrado de las sumas, sin penalización en los resultados
de búsquedas en el índice (Chávez et al., 2008).

El proceso de obtención de una permutación inversa , de una permutación . Se

ilustra en el siguiente ejemplo.

Donde y la imagen de
Utilizando la notación de dos renglones, se intercambian el primer renglón por el segundo o lo
que es igual se intercalan el rango por la imagen de la permutación. Se evalúa
. La permutación inversa
 57

Figura 31. Obtención de una permutación para un elemento u.

La permutación , se compone de todos los elementos ordenados de manera

ascendente de acuerdo a su distancia con el objeto , por lo que
. Donde n es el número de elementos en .

Entonces el índice está conformado por todas las permutaciones , con , como se
muestra en la Figura 31. A cada canción en una colección de música, le corresponde un AFP y a
cada AFP una permutación . Para realizar búsquedas en este índice en (Chávez et al., 2008) se
propone el siguiente algoritmo:

1. Utilizando la distancia de Hamming , definida en el espacio de las representaciones, se

obtiene , para todo , para obtener .
2. Dada la función distancia entre permutaciones , se ordenan los elementos de de
manera creciente de tal forma que el primer elemento será el de menor valor de la
distancia . Con esto se requiere considerar solamente el subconjunto de los
primeros M elementos después de ordenar. Hay que notar que entre más grande sea M, es
mayor la probabilidad de encontrar el vecino más cercano.
3. Después se evalúa la distancia , entre la consulta y los M elementos ordenados que se
obtuvieron y el mejor candidato de los M elementos es aquel que cuente con la menor
distancia a la consulta.
 58

Figura 32. Proceso de búsquedas sobre un índice basado en permutaciones.

 59

IV.3 Interfaz de consulta.

La interfaz de consulta es el medio por el cual un usuario final hace uso de las búsquedas
por contenido. La interfaz de consulta que se definió en el presente trabajo, es un reproductor
multimedia, el elegido en el presente trabajo es “Songbird”, por ser un reproductor que cuenta
con funcionalidades y características que hacen que sea el candidato principal para utilizarse
como base para desarrollar el caso de estudio.

Algunas de las características que brinda este reproductor se enlista a continuación.

 Extensiones de código. La arquitectura con la que está escrito este reproductor

brinda una manera sencilla de extender las funciones del código base.

 Manejador de bibliotecas digitales de música. Cuenta con los métodos para

acceder y navegar con metadatos de canciones.

 API de programación. API con el cual se acceden a las funciones que puede
realizar el reproductor.

 JavaScript. Las extensiones de código se escriben en lenguaje JavaScript, un

lenguaje que tiene la capacidad de consumir servicios web, el único requerimiento
para acceder a las funcionalidades de Natix.

Dentro de la interfaz de consulta, se montó un buscador que de manera visual pone a

disposición de usuarios comunes del reproductor multimedia, la posibilidad de realizar una
búsqueda de información para una canción en particular. En la Figura 33, se muestra una pantalla
del buscador.

La escritura de este buscador por contenido se realizó en forma de extensión para el

reproductor “Songbird”. Esta extensión como se mencionó anteriormente fue escrita en
JavaScript, haciendo uso, mediante el uso de servicios web, de las funciones de Natix para llevar
a cabo los objetivos trazados en los escenarios planteados.
 60

Entre los elementos que forman la pantalla del buscador de audio por contenido, se
encuentran un botón para la captura de consulta, un listado de las canciones que pertenecen a la
biblioteca digital de música, un botón para verificar la consulta y un listado para mostrar los
resultados de la búsqueda. Los detalles de los elementos se muestran a continuación.\

Figura 33. Pantalla de captura dentro de la interfaz de consulta.

Botón para la captura de consulta. Este botón se presiona justamente al comenzar a

grabar desde el micrófono, l0 segundos de una consulta. Una vez pasados los 10 segundos se
guardan esos 10 segundos en un archivo que se usará como consulta posteriormente.

Listado de canciones de la biblioteca digital de música. Este listado es necesario para

poder someter a búsqueda aquellas canciones que cuentan con metadatos genéricos. Dando clic
derecho sobre una canción de la lista se despliega un menú en el cual se incluye la opción
“buscar metadatos”. Si se presiona estaa opción se toman 10 segundos de la canción sobre la cual
se desplegó el menú y se guarda en un archivo para posteriormente usarla como consulta.

Botón para verificar la consulta. Si se requiere escuchar la consulta, es necesario dar clic
sobre el botón verificar consulta, y entonces se reproduce la consulta que se sometió a la
búsqueda justo después de dar clic.
 61

Listado para mostrar los resultados. Los resultados que se muestran justo después de
realizar una búsqueda, se muestran en una lista en la parte inferior de la pantalla, donde se puede
observar información útil de la canción.

Tomando en cuenta los elementos principales de la pantalla, el proceso para dar solución
al primer escenario de aplicación es el siguiente.

 Se orienta el micrófono de la computadora al origen de la canción que se quiere

conocer.
 Se presiona el botón para la captura de consulta, para esperar los 10 segundos que
se graban como consulta.
 Una vez grabados los 10 segundos, se realiza la búsqueda (invisible para el
usuario). Después de hacer la búsqueda, se muestran en el listado de resultados,
información de canciones parecidas musicalmente a la consulta.

Para el segundo escenario de aplicación, el proceso es muy parecido, con ciertas

diferencias en cómo se toma la consulta y el cómo se utilizan los resultados. Los detalles de la
forma en que se da solución dentro de esta pantalla a este escenario se enlista a continuación.

 Se da clic derecho sobre una canción que aparezca en el listado de canciones de la

biblioteca digital de música. Generalmente las canciones que interesan al caso son
las que contienen metadatos genéricos.
 Se selecciona dentro de las opciones de un menú que se despliega al dar clic
derecho, la opción “buscar metadatos”.
 Se toman 10 segundos de la canción seleccionada como consulta. Se realiza la
búsqueda (invisible para el usuario) y después se muestran en el listado de
resultados, información de canciones parecidas musicalmente a la consulta.
 Dentro del listado de resultados, se da clic derecho sobre la canción de la cual se
quieran tomar los metadatos, para desplegar un menú.
 Por último, dar clic sobre la opción “agregar metadatos” dentro del menú, para
agregar o editar los metadatos con los que cuenta la canción seleccionada en el
listado de canciones de la biblioteca digital de música.
 62

La Figura 34, muestra el diagrama con los elementos principales que forman parte de la
propuesta de solución en el presente trabajo.

Figura 34. Ilustración de la propuesta de solución.

 63

CAPITULO V

Extensión de propuesta de solución

V.1 Introducción

Si bien en la solución propuesta anteriormente, se utilizó una técnica que evade la

necesidad de realizar las búsquedas dentro de una colección de manera secuencial tomando como
referencia objetos permutantes, la necesidad de realizar un proceso de verificación posterior
hace que la escalabilidad de esta técnica disminuya.

Lo anterior, motivó la necesidad de diseñar una técnica que no requiriera realizar un

barrido sobre todos los elementos de una colección y además fuera escalable a colecciones con
millones de elementos. La técnica que se diseñó utiliza como base el funcionamiento de las
tablas hash.

Las tablas hash son estructuras de datos efectivas para implementar diccionarios. Aunque
puede ocurrir que buscar por un elemento dentro de una tabla hash, sea tan tardado como buscar
dentro de una lista ligada, que en el peor caso es de orden O(n), donde n es el número de
elementos de entrada a la tabla. En la práctica, el rendimiento de las tablas hash resulta ser, en
promedio, mucho mejor. Bajo ciertas suposiciones, el tiempo esperado para encontrar un
elemento en una tabla hash es de orden O(1).
 64

Figura 35. Implementación de una tabla hash utilizando el método de direccionamiento directo. Cada valor clave en el
universo U, corresponde a un índice en el arreglo T. (Cormen et al., 2001)

En la creación de una tabla hash se asocian llaves o claves con índices dentro de una
estructura de acceso aleatorio. Esto permite el acceso directo a los elementos almacenados a
partir de una clave. Esta asociación se lleva a cabo aplicando una función hash h la cual
transforma una clave en un valor hash h(k). Un valor hash es un número que la tabla hash utiliza
para localizar el valor deseado. Como se puede observar en la Figura 35, en la construcción de
una tabla hash se requiere de una estructura de acceso aleatorio que generalmente es un arreglo T
y una función hash cuyo dominio es el espacio de claves y su imagen (o rango) los valores hash.

Existe además en la construcción de una tabla hash, el problema de colisión que se puede
observar en la Figura 35, donde las claves k2 y k5, después de evaluarse con la función hash
tienen el mismo valor hash. Para resolver este problema, se utiliza comúnmente la técnica de
encadenamiento, Figura 36. Esta técnica, pone todos los elementos que cuentan con el mismo
valor hash dentro de una lista ligada. Como se puede observar en la Figura 36, el índice j dentro
del arreglo T contiene un apuntador a la cabeza de la lista que contiene todos los elementos que
se mapean al valor hash h(k)=j; si no existen elementos cuya imagen bajo la función hash sea j,
entonces el apuntador será nulo.
 65

Figura 36. Resolucion de colisones utilizando el metodo de encadenamiento. Cada espacio T(j) contiene una lista ligada
con todas las llaves cuyo valor hash es j. Por ejemplo h(k2)=h(k5).

En el peor caso, el tiempo que toma insertar un elemento en una tabla hash con
encadenamiento es de orden O(1). El proceso de inserción es rápido, en parte, porque los
elementos se almacenan sin ordenar, pero si se requiere mantener ordenadas las listas, es
necesario sumar un costo adicional en el tiempo computacional requerido. En cuanto al tiempo
necesario para la búsqueda, esté es proporcional al tamaño de la lista de valor hash en la que se
busca un elemento.

Algoritmo de inserción.

1. Para almacenar un elemento en la tabla hash se debe convertir su clave a

su valor hash. Esto se consigue aplicando la función hash a la clave del elemento.
2. El resultado de la función resumen, ha de mapearse al espacio de
direcciones del arreglo T que se emplea como soporte.
3. El elemento se almacena en la posición de la tabla que se obtuvo en el
paso anterior. Esto se hace almacenando el elemento en la cabeza de la lista ligada que
contiene los valores hash iguales al valor que se obtuvo.
 66

Algoritmo de búsqueda

1. Para recuperar los datos, es necesario únicamente conocer la clave del elemento
que se quiere recuperar, a la cual se le aplica la función hash.
2. El valor obtenido se mapea al espacio de direcciones de la tabla.
3. Se busca dentro de la lista ligada perteneciente al valor hash que se obtuvo en el
paso anterior.

Para la técnica de indización implementada en esta propuesta de solución, la propiedad

principal a tomar en cuenta para el rendimiento escalable, es el acceso aleatorio a las listas
ligadas de un valor hash específico. Es decir, si se buscan los elementos que contengan la clave k
en una tabla hash, solamente se obtiene el valor hash de la clave k y se toma como respuesta la
lista que se tiene enlazada a ese valor hash.

V.2 Locality Sensitive Hashing

Locality sensitive hashing (LSH) es una técnica utilizada en (Tellez y Chavez, 2010), y es
una opción natural para la búsqueda por similitud en modelos vectoriales. Es rápida, con
precisión ajustable, fácil de implementar y además se puede utilizar para manejar bases de datos
muy grandes y con altas dimensiones. Para poder utilizar la técnica LSH se requiere definir una
familia de funciones con características particulares para la colección a la cual va a ser
aplicada, además de una función distancia para evaluar similitudes.

Las familias hash aplicadas en esta técnica consisten en un muestreo aleatorio sobre
las cadenas de bits que representan las señales de audio. Por ejemplo, supongamos que
es una función que copia y concatena los bits de la cadena binaria s y es la
familia . Si se considera dentro de un espacio de haming binario
definidos de la siguiente manera: .
Ejemplificando, , esto dado a que las funciones hash
retornan los siguientes valores
 67

. Se puede observar que , que

en efecto son las tripletas más cercanas.

V.3 Construcción de un índice LSH

Para la construcción del índice, al igual que en la primera propuesta de solución del
presente trabajo se tomó en cuenta la representación binaria de canciones que se extrae al aplicar
la técnica de MBSES. Esta técnica por naturaleza define un espacio de hamming, el cual si bien
se puede aplicar directamente a la técnica LSH, evadir la necesidad de evaluar distancias con una
métrica tan costosa computacionalmente hablando como hamming, motivó utilizar una métrica
distinta a hamming.

Los AFPs generados por MBSES como se muestran en la Figura 37, calcula un vector
binario para cada ventana en la que se divide la señal. Es por esta división de ventanas que se
puede tener referencia temporal de la ocurrencia del vector binario que se genera. En la Figura
38, se muestra la generación de un AFP con un traslape de 75% y un tamaño de ventana de
8192, por lo que se evalúa una ventana cada 46 ms. Es importante notar que el tiempo en el que
ocurre varía dependiendo de estos dos parámetros.

Figura 37. Generación de un AFP con MBSES.

 68

Se puede observar que son tres los datos que se pueden extraer de cada uno de los
vectores generados por MBSES: el valor de la cadena binaria, el tiempo en el que ocurre y la
canción a la que pertenece, y son estos tres datos los que van a ser de utilidad en el momento de
indexar el espacio. Ejemplificando con la Figura 38, el valor clave en este conjunto de datos es el
valor en la cadena binaria y tanto el tiempo como la canción son propiedades adjuntos a dicha
clave. Es decir, los elementos dentro del espacio tienen la forma {valor binario, tiempo, id de la
canción}.

La familia de funciones hash para este caso son funciones que copian y concatenan
bits, el índice de bits a tomar en cuenta se genera de manera aleatoria, es decir, si se quieren
tomar en cuenta 5 bits como se muestra en la Figura 38, se generan 4 funciones de 5 bits
aleatoriamente. Para cada cadena binaria se evalúa cada una de las funciones pertenecientes a ,
por lo que para el ejemplo de la Figura 38 se generarían 4 valores hash por cada cadena binaria o
clave.

Figura 38. Obtención de los valores hash. Se definen las funciones a, b, c y d. Se evalúan cada una de las funciones para
cada cadena binaria, por lo que por cada cadena binaria se obtienen 4 valores hash.

Una vez definidas las funciones, es necesario definir dos parámetros, primeramente hay
que decidir el tamaño de la cadena binaria sobre la cual se evaluarán las funciones, es decir, si se
tomaran las cadenas binarias directamente de los vectores binarios por cada ventana que genera
MBSES, se tomarían en cuenta cadenas binarias de longitud 24 pero realizarlo de esta manera
 69

generaría un índice muy sensible al cambio de un bit. Por lo que es recomendable incrementar la
longitud de la cadena binaria a tomar en cuenta. Por ejemplo, si se toma una longitud de 72,
habrá que concatenar los 24 bits generados para 3 vectores binarios consecutivos en un AFP.
Posteriormente hay el traslape en el avance para obtener el siguiente grupo de valores hash.
Ejemplificando, en la Figura 39, se muestra una longitud de cadena de 96 bits con un traslape del
50%. Entonces, cada 96 bits se evalúan las funciones de la familia . Una vez realizada la
evaluación se recorren 48 bits y a partir del bit 48 se toman en cuenta los siguientes 96 bits como
la siguiente sub matriz y sobre ésta se realiza una nueva evaluación. Este proceso se repite hasta
finalizar el AFP.

Figura 39. Obtención de valores hash cada n bits. Para este caso n=96 y un traslape de 50%.

Hasta este punto, se obtienen los valores hash que se pueden extraer de cada uno de las
canciones en la colección, ahora la tarea es insertar dentro de una tabla hash los valores que se
obtuvieron. El primer paso, es definir el arreglo T que se usará como base para la búsqueda
dentro de la tabla. Para el caso de la familia que se muestran en la Figura 40, en las cuales se
toman en cuenta 5 bits, el tamaño de T será el valor máximo que se puede generar con 5 bits, el
cual es 31. Como se muestra en la Figura 40, para cada elemento en T se asociará un lista ligada
la cual contiene elementos de la forma {id canción, tiempo}. De esta manera se podrán localizar
 70

los elementos en la tabla hash de manera directa para tener la capacidad de realizar
comparaciones posteriormente.

Figura 40. Mapeo de cadenas binarias a valores hash.

El proceso anterior se repite para cada uno de los AFPs que representan las canciones
dentro de la colección y al final se obtiene una tabla hash con soporte a colisiones utilizando la
técnica de encadenamiento.

V.4 Búsqueda en el índice LSH

Como se mencionó anteriormente, LSH es un candidato natural para hacer uso de la

métrica de hamming para evaluar distancias, pero buscando hacer más escalable la técnica
motivó la implementación de una métrica probabilística que se basa en el uso histogramas, que
haciendo un agrupado y conteo de los elementos que se encuentran en las tablas hash se da
respuesta a una búsqueda. A continuación se detalla el uso de esta técnica.

Supongamos que se requiere encontrar el objeto consulta dentro de una colección de

canciones el cual se representó previamente con la técnica MBSES. El primer paso es obtener
los valores hash aplicando las funciones de la familia definida anteriormente, utilizando los
 71

mismos parámetros con los que se realizó el índice. Una vez que se obtienen los valores hash hay
que buscar dentro de la tabla hash por las listas ligadas que están relacionadas con los valores
hash que se obtuvieron, uno se puede dar cuenta que encontrar las listas ligadas dentro de una
tabla hash sigue una complejidad constante y es esta propiedad la que se explota en esta técnica
de búsqueda para aumentar la escalabilidad.

Una vez que se obtienen las listas ligadas de cada valor hash encontrado en el objeto
consulta, el siguiente paso es realizar un agrupado por el identificador de la canción. Para poder
identificar cuando ocurre un valor hash dentro de una canción. De este modo, se convierten las
tuplas de {canción id, tiempo} a {valor hash, tiempo} y como resultado ahora se tiene un
conjunto de listas y cada lista en este conjunto representa una canción y tiene elementos de la
forma {valor hash, tiempo}. Hasta este momento cada lista pertenece a una canción y esta
canción se puede ver como un candidato para ser el vecino más cercano en la colección del
objeto consulta .

El siguiente paso es la generación de un histograma con cada una de las listas o canciones
candidatas que se han obtenido hasta este momento. Esto se realiza primeramente definiendo
lapsos de tiempo previamente al proceso de búsqueda, por ejemplo, para consultas de 10
segundos se definen lapsos de 10,000 ms. Entonces, los lapsos quedarían definidos de la
siguiente manera (0-10000, 10000-20000, 20000-30000, 30000-40000-…). Suponga que una
consulta tiene como tamaño 10 segundos y cada uno de los lapsos de 10,000 ms define una
intervalo de clase dentro del rango del histograma. Veamos el ejemplo en la Figura 41, se puede
observar que para el objeto consulta se encuentran como candidatas dentro de la tabla hash las
canciones . El siguiente paso es, para cada valor hash que se extrae del objeto consulta ,
poner cada uno de los elementos pertenecientes a la lista de ese valor hash dentro del intervalo en
el histograma en el cual cae el valor en el tiempo que tiene. Con esto se busca tener el máximo
número de coincidencias dentro de un lapso de 10 segundos o el tamaño de la consulta. Esto
genera no solo un soporte en las búsquedas por las comparaciones por valores hash, sino también
permite valorar el tiempo en el que ocurren dichos valores hash. Este proceso se repite tanto para
la canción y y entonces, la canción que genere el pico más grande en el histograma, es la
canción candidata para ser el vecino más cercano del objeto consulta en la colección .
 72

60

50

40

Canción x
30
Canción y
20 Canción z

10

0
1000 2000 3000 4000 5000 6000 7000 8000 9000

Figura 41. Histograma con las canciones candidatas x, y, z. Si bien la canción z contiene más valores hash a lo largo del
histograma, la canción ganadora es x por tener el pico más alto.

Algoritmo de búsqueda

 Evaluación de los valores hash de objeto consulta q aplicando la familia de funciones .

 Obtención de las listas ligadas dentro de las tablas hash, pertenecientes a los valores hash.
 Agrupación de las listas por la propiedad id canción, para generar otras listas que
representan cada una de las canciones candidatas.
 Evaluación de cada una de las canciones candidatas.
o Buscar para cada uno de los valores hash de la consulta los valores en la listas.
o Sumar uno al intervalo clase, de acuerdo al tiempo que tiene el valor hash en la
lista canción.
o Retornar el valor del pico máximo en el histograma
 Retornar el pico máximo de los histogramas generados el cual representa la canción
candidata como vecino más cercano.
 73

V.5 Implementación del índice LSH

Haciendo uso de la librería de programación natix, se implementó la funcionalidad del

índice LSH, además de definir un nuevo espacio que lo conforman objetos de la forma {cadena
binaria, tiempo, canción id}. A su vez, este espacio se hace un espacio métrico definiendo la
distancia por histogramas definida anteriormente.

Para poder realizar experimentos con la técnica de indexación LSH que lograran simular
un escenario real, se requería llevar a cabo pruebas sobre una colección significativa. Pero
realizar estas pruebas con una colección más grande de 500 canciones y mantenerlas en memoria
principal es una tarea imposible, tomando en cuenta una cantidad de 4 gigas de memoria
principal, que es la cantidad con la que cuenta la computadora con la que se realizaron los
experimentos. Para poder realizar esta tarea se tomó en cuenta la base de datos Berkeley DB
(Olson et al., 1999).

Berkeley DB, es una herramienta de código abierto, que da soporte a índices con
estructuras tanto de árbol b y tabla hash. Con esta herramienta las estructuras pasan de disco
secundario a memoria principal en tiempo de ejecución, con esto, no es necesario mantener en
memoria principal todo el contenido de la tabla hash en todo momento. Como se muestra en la
Figura 42, los valores hash pasan de natix a Berkeley DB y viceversa.

Figura 42. Diagrama de implementación de LSH.

 74

CAPITULO VI

Experimentos y resultados

VI.1 Introducción

La experimentación de la propuesta de solución, aplicable en el caso de estudio que se

propuso en el presente trabajo, se realizó simulando los dos escenarios en los que se desenvuelve
el caso de estudio. Esta simulación se basa en modelar aquellos elementos de ambos escenarios
que realizan alguna actividad dentro de la recuperación de música.

Como se mencionó anteriormente, uno de los factores de interés en este tipo de sistemas,
es la robustez ante ciertas deformaciones que se presentan en escenarios reales, como los que se
propusieron en el caso de estudio. La primera de las deformaciones que se tomó en cuenta en la
experimentación, fue la regrabación. Esta deformación se presenta dentro del primer escenario,
cuando se toma del ambiente, el sonido o señal de consulta utilizando el micrófono. Dentro de
este tipo de deformación, por la forma en la que se graban las señales, lleva consigo
implícitamente otra deformación, el ruido, porque es imposible encontrar señales originales en
el ambiente sin tener algún tipo de ruido que deforme en cierto porcentaje el espectro de la
señal.

Otro factor interesante es el desplazamiento, una señal que se representa con una técnica
de generación de AFPs, normalmente divide en marcos la señal, para después representar alguna
característica dentro de esos marcos. Pero el problema es que algunas veces el principio de una
consulta, o la forma en que se dividen los marcos de una consulta, no es exactamente igual al de
un elemento en la colección que se esperaría ser el elemento con el que se identifique la consulta.
Razón por la cual, los AFPs que se generan en ambos elementos son diferentes.

Dentro de los experimentos las consultas sufren una deformación en particular o alguna
combinación de las deformaciones anteriores, por lo que en gran medida, el éxito de una
 75

aplicación de este tipo es la robustez de la técnica para generar AFPs que se toma en cuenta para
realizar los experimentos.

Una característica importante en las aplicaciones para la recuperación de música, es el

tamaño de la consulta, es decir, hay varios escenarios en los que se dispone una cantidad
considerablemente grande de segundos para ser tomados en cuenta como consulta, pero es
importante notar que entre más segundos se consideran, la representación o AFP deja de ser
compacta y la transmisión del mismo es muy tardada. Por lo tanto, entre menos segundos se
toman en cuenta como consulta, se incrementa la eficiencia para una aplicación de este tipo.

Además, un sistema de recuperación de música debe ser capaz de dar respuesta lo más
rápido posible a una consulta, en general, para hacer escalable las búsquedas en aplicaciones de
este tipo, se hacen uso de índices. El objetivo de aplicar índices en la recuperación de audio, es
reducir al máximo las comparaciones que se hacen entre AFPs, aunque a veces se sacrifica un
poco la precisión para tener una mejor eficiencia en la búsqueda.

Sumado a los problemas o características anteriores a los que se enfrentan estos sistemas,
los ritmos de música que en general se presentan en bibliotecas digitales de música personales,
son de muy diversos tipos que van desde pop, rock, instrumental, clásico, etc. y lo que se espera
de una aplicación de este tipo, es que su comportamiento no dependa de los tipos de ritmos que
conforman las bibliotecas digitales de música. Si bien existen aplicaciones que se desenvuelven
mejor con cierto tipo de canciones, en los escenarios que se plantean en el presente trabajo es
necesario tener un comportamiento uniforme ante cualquier tipo de ritmo.

VI.2 Características

La herramienta principal dentro de los experimentos en esta tesis, es la interfaz de

consulta “SongIndex”. Si bien para un usuario final, esta herramienta se ve y se utiliza como un
solo componente, esta herramienta se auxilia de otros componentes o aplicaciones para llevar a
cabo cada una de las etapas necesarias para resolver los escenarios propuestos. Estas etapas y
herramientas, así como los parámetros utilizados se enlistan a continuación.
 76

 Captura de la consulta desde el micrófono. Esta captura se realiza utilizando la

funcionalidad de “Sox Exchange”, herramienta que permite tomar de manera
genérica la entrada de un dispositivo de captura como el micrófono y grabar
localmente en forma de archivo la grabación. Para tener una consulta aceptable
dentro de un escenario real utilizando “Sox Exchange”, se agrega primeramente
el parámetro, tasa de muestreo a 44100 Hz, que es un parámetro que define el
número de muestras de la señal continua que se toman en cuenta cada segundo en
la digitalización de la señal. Otro parámetro que se consideró, fue el número de
canales, en particular se tomaron en cuenta dos canales, al tomar dos canales se
define una calidad “stereo” de grabación. Otro característica importante en este
punto, fue el tamaño de las consultas, en particular, en esta aplicación se tomaron
en cuenta 10 segundos como consulta. El comando que dispara la acción anterior
es:

SoX -r 44100 -c 2 -d Query10secs.wav trim 0 10

 Generador de AFPs. Para la generación de AFPs se utilizo MBSES, una técnica

que en (Camarena-Ibarrola y Chávez, 2006) mostró ser robusta ante las
deformaciones a las que se enfrenta la aplicación. Como parámetros en esta
herramienta se consideraron 185 ms como tamaño de marcos en los que se divide
la señal, y un traslape del 75 por ciento.

 El índice que se utilizó se basa en permutaciones, presentado en (Chávez et al.,

2008), donde se muestra la efectividad y eficiencia de este índice, el cual si bien
sigue dependiendo del tamaño de la colección, disminuye el tiempo de respuesta
significativamente al utilizar distancias entre permutaciones para responder a una
consulta. Como parámetros de este índice se tomaron 512 permutantes aleatorios
de 2 y 3 segundos como referencia.
 77

 Como biblioteca de música se utiliza una colección de 3,000 canciones de

diversos géneros, las cuales cuentan con metadatos fiables. A esta colección se les
generó su respectivo AFP y se realizó el índice de permutaciones, para realizar
búsquedas sobre este índice.

VI.3 Construcción del índice

Previamente a realizar búsquedas por contenido de audio, se llevó a cabo la construcción

del índice basado en permutaciones, que fue posteriormente donde se realizaron las
comparaciones de elementos en los experimentos. Esta construcción se llevó a cabo utilizando
una colección menciona de 3,000 canciones. Los pasos para la creación del índice y la forma en
que se montó la funcionalidad de búsquedas dentro del índice en forma de servicios web se
muestra a continuación.

 Generación de AFPs para las canciones de la colección. Para la construcción del

índice, se hizo uso primeramente de MBSES para la extracción de AFPs de la
colección (los parámetros requieren ser los mismos utilizados para las consultas).

 Modelación del espacio en Natix. Para dar soporte a vectores binarios dentro de
Natix, se realizó la extensión de la funcionalidad de esta librería, con el fin de
modelar las representaciones de objetos de este tipo, es decir, modelar el espacio
dentro de la librería (véase Apéndice A).

 Codificación del índice basado en permutaciones dentro de Natix. Este índice

construye la estructura que da respuesta a los criterios de búsqueda más comunes,
haciendo uso del espacio definido por los AFPs que se obtuvieron con MBES de
cada uno de las canciones de la biblioteca (véase Apéndice A).
 78

 Construcción de servicios web. Hasta este punto, se tenía construido un índice por
permutaciones que podía dar soporte a aplicaciones escritas en Mono. Pero una de
las necesidades de un marco de trabajo en la actualidad, es poder aplicar su
funcionalidad en cualquier lenguaje de programación en que se esté trabajando.
Es por esto que se montaron servicios web que toman como entrada cadenas
binarias, que representan AFPs de consultas, y como respuesta, los servicio web
retornan un archivo xml con metadatos que representan los k-vecinos más
cercanos a la consulta (véase apéndice A, sección 3).

VI.3 Experimento 1. Tomando la consulta desde el micrófono

El primer experimento consistió en simular el primer escenario de aplicación del caso de

estudio. Para llevar a cabo el experimento, se tomó en cuenta el micrófono de una computadora
personal que tiene una sensibilidad dB, un micrófono que cualquier computadora personal
posee en la actualidad. Además, como fuente de reproducción de canciones en el ambiente, es
decir, la simulación de los posibles medios en donde se puede escuchar una canción, como la
televisión, radio, internet, etc., se utilizó un reproductor mp3 convencional, el cual cuenta con
una bocina que emite la reproducción de las canciones.

Tanto el micrófono, como el reproductor mp3, conformaron la forma de tomar la consulta

en este escenario, es decir, se emitieron canciones en el reproductor mp3 y utilizando el
micrófono se grabaron 10 segundos como consulta. Se tomaron 100 consultas, repitiendo el
proceso anterior, esto con el fin de tomar una muestra representativa para evaluar la precisión de
la aplicación en este escenario.

La búsqueda de las canciones se hizo utilizando la interfaz de consulta que se construyó,

es decir, usando el índice basado en permutaciones construido previamente, se grabaron las 100
consultas, y se sometieron a búsquedas, para después, usando la funcionalidad de “SongIndex”,
mostrar los resultados de las búsquedas.
 79

VI.4 Experimento 2. Integrando metadatos a la biblioteca digital de

música

En este experimento se tomó como consulta 10 segundos de canciones que contaban con
metadatos genéricos. Estas canciones provenían de fuentes diversas, como descargas de internet,
radio, grabaciones con celular, etc. Para estas consultas se tomaron 10 segundo aleatorios del
primer minuto de canción, esto con el fin de evadir silencios al comienzo de las canciones,
aplausos en canciones en vivo, etc. La distribución de los tipos de consultas y deformaciones que
sufren las consultas se muestran en la siguiente tabla.

Ritmo de consulta Número de consultas Deformación

Pop 5 Desplazamiento
Rock 10 Desplazamiento
Rock (vivo) 15 Desplazamiento y ruido
Clásico 10 Desplazamiento
Instrumental (vivo) 5 Desplazamiento y ruido
Variado (descargas) 15 Desplazamiento y ruido

Tabla II. Distribución de ritmos y deformaciones.

Las consultas se sometieron a búsquedas dentro del índice de permutaciones construido

previamente, basado en las canciones de la biblioteca digital de música. Los resultados de estas
búsquedas se presentaron dentro de la interfaz de consulta, estos resultados correspondían a los
metadatos de las canciones candidatas en el índice para ser el vecino más cercano.
 80

VI.5 Experimentación con LSH

Para la realización de los experimentos se tomó en cuenta una base de datos de 1,500
canciones a las cuales se les extrajo su representación binaria o AFP. Partiendo de esta colección
de AFPs, se inició la experimentación, de la siguiente manera:

Como primer parámetro de variación a tomar en cuenta, se consideró el número de bits

tomados en cuenta en la familia de funciones , se hizo una variación comenzando por 24 bits
hasta llegar a 64 bits. Los parámetros que también son ajustables, pero para el caso se dejaron
estáticos, se enlistan a continuación:

 Tamaño de la ventana al obtener el AFP 8192 bits.

 Traslape al obtener el AFP; se mantuvo en 75%.
 Tamaño de la sub matriz para obtener valores hash, 120 bits.
 Traslape al mover la sub matriz del 80%.
 Número de funciones en la familia , 4.

Se realizaron índices con cada uno de los valores entre 24 y 64 bits, para posteriormente
realizar búsquedas sobre estas estructuras. Las consultas que se aplicaron a las búsquedas eran de
una longitud de 10 segundos y la deformación a la que fueron sometidas fue desplazamiento en
el tiempo.

La obtención de las consultas se pudo llevar a cabo utilizando la herramienta Sox

Exchange, la cual permite extraer fragmentos de una canción del tamaño que se desee y además
comenzar el fragmento dentro de la canción en el momento que se requiera. Por lo tanto, para
simular el desplazamiento en el tiempo fue suficiente con tomar un número aleatorio dentro del
tiempo de la canción, para después tomar en cuenta los 10 segundos consecutivos a este número
como consulta. El comando utilizado fue el siguiente:

SoX nombreCacion.wav Query10secs.wav trim %al 10

Se tomaron 150 consultas con las características que se mencionaron anteriormente y se

sometieron a búsqueda dentro de la colección haciendo uso del índice LSH construido bajo los
parámetros mencionados anteriormente, solamente variando el número de bits tomados en
 81

cuenta. El régimen de búsqueda fue el de los k vecinos más cercanos y como k se consideró 10.
Es decir, se consideraron como resultados positivos, aquellos elementos que aparecieran dentro
de los 10 vecinos más cercanos. Los resultados se muestran a continuación.

100

90

80

70

60

50
10 vecinos mas cercanos
40

30

20

10

0
24 bits 32 bits 40 bits 48 bits 56 bits 64 bits

Figura 43. Gráfica de resultados del expermiento variación de bits realizado sobre el indice LSH.

Como se puede observar en la Figura 43, al subir el número de bits tomados en cuenta en
las familia de funciones que mapea, disminuye el recall dentro de los 10 vecinos más cercanos.
Esto ocurre por la necesidad de encontrar exactamente los valores hash dentro de la tabla y al
subir el número de bits, es más probable que un bit no sea igual, por lo que la lista ligada que
debería de pertenecer a ese valor hash no se recupera y por lo tanto no forma parte del
histograma.

El siguiente paso en la experimentación es variar el parámetro de traslape al mover la sub

matriz. Para el primer experimento se tomó un traslape del 80%, el cual se planea ajustar hasta
un 98%. Lo mismo se requiere realizar con los distintos parámetros ajustables de la técnica y es
un trabajo que se dejará a futuro.
 82

VI.5.1 Experimentación con Indice Secuencial con desplazamiento en el tiempo

Parámetros:

 Tamaño de ventana: 8192 bits con muestro de 44100 muestras por segundo son
aprox. 185ms
 Traslape de la huella: 95% cada 12 ms se calculan 24 bits
 Tamaño de la colección: 500 canciones.
 Número de consultas: 100
 Métrica: Hamming "exacta"

Resultados:

 NN=100
 KNN=0 (dentro de los 10 vecinos)
 Mal=0
 Precisión=100%
 Tiempo promedio de búsqueda= 30 minutos.


120

100

80

NN
60
KNN
40 Mal

20

0
100 consultas

Figura 44. Gráfica de resultados del experimento secuencial.

 83

El comportamiento del experimento se muestra en la Figura 45, en donde se genera una

diferencia entre las canciones que no se consideran como respuesta o relevante a una consulta,
esta separación refleja la robustez ante esta deformación. Si bien este comportamiento es muy
bueno, y además es el mejor que se puede alcanzar con esta técnica de obtención de AFPs, el
tiempo que requiere realizar una búsqueda es demasiado tomando en cuenta la colección sobre la
cual se realizó este experimento.

Hamming determinística
14000
12000
10000
8000
6000 Distancia
4000
2000
0
1
54

531
107
160
213
266
319
372
425
478

584
637
690
743
796
849
902
955

Figura 45. Gráfica de distancias con hamming determinístico. Se puede notar claramente como se separan en la parte de
abajo los objetos ganadores de los demás.

El tiempo promedio de realizar una consulta como se muestra en la Figura 46, es

aproximadamente 30 minutos, tiempo que no es aceptable para escenarios que se desenvuelven
haciendo uso de internet, lo cual se ha convertido una necesidad en la actualidad.

El siguiente experimento es realizar con los mismos parámetros con los que se realizó el
experimento de búsqueda secuencial en el índice LSH, esto con el fin de tener una relación en la
mejora con respecto al tiempo haciendo uso de este índice.
 84

Tiempo de búsqueda
40
35
30
25
Minutos

20
15
10
5
0
6
1

91
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86

96
Figura 46. Gráfica tiempo de búsqueda en secuencial. El eje (x) representa las consultas realizadas mientras que el eje (y)
el tiempo en minutos.

VI.5.1 Experimentación con indice LSH con desplazamiento en el tiempo

Parámetros:

 Tamaño de ventana: 8192 bits con muestro de 44100 muestras por segundo son
aprox. 185ms
 Traslape de la huella: 95% cada 12 ms se calculan 24 bits
 Tamaño de la colección: 500 canciones.
 Número de consultas: 100
 Métrica: Hamming "probabilística" (utilizando histograma)
 Tamaño de la submatriz: 24 bits o 1 ventanas
 Número de funciones H: 3
 Número de bits en la función: 8
 Rangos de tiempo {0-50,50-100……}

Resultados:

 NN=100
 85

 KNN=0 (dentro de los 10 vecinos)

 Mal=0
 Precisión=100%
 Tiempo promedio de búsqueda= 30 minutos.

En la Figura 47 se muestra que con el LSH se puede mantener el recall, si bien la manera
de obtener los resultados es de manera probabilística, aun con desplazamiento en el tiempo lo
cual hace que varíen los bits que arroja la técnica de obtención de AFPS utilizado se puede
considerar una técnica robusta ante desplazamiento en el tiempo.

120

100

80

NN
60
KNN
40 Mal

20

0
100 consultas

Figura 47. Gráfica de Resultados del experimento LSH.

El tiempo de búsqueda promedio para este experimento fue como se muestra en la

Figura 49, 3 minutos por lo que con parámetros muy altos se mejora 10 veces el tiempo que se
requiere para realizar las mismas búsquedas con el índice secuencial.

En una consulta con los parámetros que se realizó el experimento una consulta genera
1058 ventanas que se pueden encontrar en el índice LSH, y como se observa en la Figura 48, el
 86

número de ventanas que se encuentran son suficientes para diferenciar entre canciones de la
colección que no se toman en cuenta con candidatos para el vecino más cercano a la consulta.

Hamming probabilística
900
800
700
600
500
400 No. Frames con match
300
200
100
0
29
1
8
15
22

36
43
50
57
64
71
78
85
92
99

Figura 48. Gráfica con el número de marcos que hacen match. El número máximo de marcos en 10 segundos de consulta
y un traslape del 95% es de 1058.

Tiempo de búsqueda
9
8
7
6
5
4
3
2
1
0
1
5
9

33
13
17
21
25
29

37
41
45
49
53
57
61
65
69
73
77
81
85
89
93
97

Figura 49. Gráfica tiempo de búsqueda en LSH. El eje (x) representa las consultas realizadas mientras que el eje (y) el
tiempo en minutos.
 87

Comparando el índice secuencial con el LSH como se muestra en la Tabla III, se puede
dar una idea del comportamiento de un índice LSH con parámetros que si bien están muy altos
en términos de traslape al obtener la huella, el tiempo se mejora significativamente. Un
experimento posterior sería bajar el traslape al obtener la huella hasta 75%, parámetro con el cual
ya se vió que con el índice secuencial se sigue manteniendo un recall de 100% ante ciertas
deformaciones del espectro.

Tabla de comparación
Indice LSH Secuencial
Parámetro
Hamming
Métrica Hamming probabilística determinística
Tamaño de la colección 500 500
Número de consultas 100 100
Recall 100% 100%
3.060539 Minutos
Tiempo aproximado por consulta 30 Minutos

Tabla III. Comparación del índice secuencial contra el índice LSH.

VI.6 Análisis de resultados

Como resultados de los experimentos realizados en ambos escenarios, se observó que

para cada una de las consultas sometidas a búsqueda, se obtuvo el elemento que se esperaba
como vecino más cercano, es decir, de 100 búsquedas realizadas en cada escenario, todas
tuvieron una respuesta aceptable. Este resultado muestra que como era de esperarse, la técnica
para la obtención de AFPs mostrada en (Camarena-Ibarrola y Chávez, 2006) es robusta ante las
deformaciones, que una interfaz de consulta como “SongIndex”, que se desenvuelve en los
escenarios como los planteados en los experimentos. Además, la combinación de la técnica de
AFPs y la utilización de índice basado en permutaciones, mostró ser efectiva, lo cual es muy
 88

importante debido a la componente probabilística del proceso, que se presenta en la parte de

búsqueda dentro del índice.

Los resultados que generarón los experimentos, haciendo uso de “Natix”, mostró la
forma en que se puede utilizar este marco de trabajo como base en la creación de una aplicación
que requiera de la búsqueda de canciones por contenido. La creación de un marco de trabajo de
este tipo fue la motivación primordial de esta tesis.

Otro factor importante a analizar, es la utilización de servicios web en el proceso de

búsquedas, que fueron usados como la forma de abstraer la arquitectura nativa de “Natix”, es
decir, se consumió la funcionalidad de “Natix” haciendo uso de la interfaz de consulta
“SongIndex”, interfaz que se construyó en el lenguaje XUL, mediante los servicios web. Los
resultados muestran que esta manera de abstraer el funcionamiento de la librería funciona en la
creación de aplicaciones que requieren de funciones especificas de “Natix”, aunque estas
aplicaciones no sean propias del mismo lenguaje.
 89

CAPITULO VII

Conclusiones, aportaciones y trabajo a futuro

VII.1 Conclusiones.

En la actualidad los escenarios de aplicación donde se presenta la recuperación de objetos

multimedia, siguen incrementando, no solo por la necesidad de obtener información útil sin
conocimiento previo textual de los objetos de interés, sino además, la necesidad de tener un
control sistemático, claro y accesible sobre colecciones de objetos multimedia.

Para llevar a cabo el trabajo de investigación, se tomó en cuenta como caso de estudio la
recuperación de información aplicada en la música, el cual tiene como objetivo obtener
información de canciones utilizando el contenido mismo de las canciones, además, el poder
hacer búsquedas escalable en colección significativamente grandes. Esto motivado no solo por el
hecho de presentarse en múltiples escenarios de aplicación en la actualidad, sino para también
mostrar una tarea particular que se puede realizar con el marco de trabajo propuesto en esta tesis,
es decir, si bien se trabajó con recuperación de música, el mismo proceso y funcionalidad del
marco de trabajo se puede aplicar en recuperación de imágenes, cadenas de ADN, recuperación
de video, etc.

Si bien en cada escenario de aplicación donde se requiere realizar una búsqueda por
contenido, cuenta con parámetros particulares propios de problema al que se enfrenta, el proceso
abstracto de cómo resolver el problema de búsquedas multimedia por contenido se repite en cada
una de las aplicaciones que se han realizado hasta este momento. Es por esto que es fácil darse
cuenta que en aplicaciones que buscan objetivos distintos en escenarios de aplicación diferentes,
pueden seguir el mismo proceso para obtener el resultado deseado. Esto motivó la generación de
un marco de trabajo capaz de adaptarse a cada uno de los escenarios que se pueden presentar en
la actualidad.
 90

El incremento en el tamaño de las bibliotecas digitales de música personales, y sobre todo

las diversas fuentes, de las cuales en la actualidad se pueden obtener canciones, generan la
necesidad de contar con interfaces de usuario como la construida en este trabajo de tesis. Con el
fin de mantener la fiabilidad de los metadatos de las canciones en las colección de música.

VII.1.1 Percepción de objetos multimedia

La representación de los objetos multimedia es una de las etapas más importantes en la

recuperación de objetos multimedia y en la actualidad los mejores resultados toman como
características que simulan la percepción del oído humano.

En la actualidad no se puede generar una técnica que modele la percepción de lo objetos

multimedia como lo hace un ser humano, entonces lo que se hace es generar heurísticas que
aproximen el comportamiento y después evalúan el comportamiento de estas técnicas, buscando
las siguientes características:

 Robustez. La representación de un objeto multimedia debe ser similar entre

objetos muy parecidos, por ejemplo, si una canción original y una canción
ecualizada se representan con la misma técnica, los AFPs que se generan deben
ser similares.

 Compacto. Las representaciones algunas veces se utilizan en aplicaciones que se

desenvuelven en tiempo real, por lo que es deseable generar las representaciones
de la manera más compacta posible.

 Tiempo computacional. Las representaciones se deben generar con el menor

esfuerzo computacional posible. Las colecciones en la actualidad son muy
grandes por lo que es necesario realizar las representaciones en un tiempo
razonable.
 91

La eficiencia y eficacia de una técnica de representación de objetos multimedia, está

fuertemente ligada al balance de las tres características que se citaron anteriormente, por
ejemplo, no servirá de mucho una técnica que generara representaciones muy compactas que no
fueran robustas ante deformaciones sencillas.

VII.1.2 Búsquedas escalables en colecciones heterogeneas

En la actualidad las colecciones de objetos complejos como los multimedia, han rebasado
a aquellos conjuntos de datos que pueden ser representados dentro de una base de datos
tradicional. Esto debido a la gran cantidad de información que se genera de fuentes como las
cámaras digitales, grabadores de sonido, celulares, radios digitales, transmisión por internet, etc.

Por lo anterior, la posibilidad de obtener información de las colecciones existentes, ha

dejado de ser un lujo y se ha convertido en una necesidad. Pero los problemas que se agregan
tanto por la estructura no definida de un conjunto heterogéneo de datos y las variantes que se
pueden presentar en algunos tipos de datos como la música, las imágenes, el video, etc.,
incrementan significativamente la búsqueda en este tipo de colecciones, por el hecho de no poder
aplicar técnicas que anteriormente eran suficientes en la búsqueda de información útil.

La creación de técnicas para recuperar objetos complejos como los multimedia, es un

área relativamente nueva en la recuperación de información. El objetivo general de estas técnicas
es encontrar un objeto en una colección. La evaluación de estas técnicas se realiza utilizando los
indicadores de precisión y recall, pero existen otras características de las técnicas de búsquedas
de objetos complejos utilizando una métrica, que son importantes.

 Tamaño de la consulta. Algunos escenarios de aplicación tienen la condición de

solo contar con una pequeña muestra del objeto a buscar, para posteriormente
recuperar el objeto completo de una colección

 Escalabilidad. Esta característica se refiere a la posibilidad de buscar objetos en

una colección, obteniendo un tiempo de respuesta aceptable. Una técnica que
 92

cuenta con una escalabilidad al máximo, es aquella que su respuesta a una

búsqueda no depende directamente del tamaño de la colección.

VII.2 Aportaciones

Las principales aportaciones que se consideran del presente trabajo de investigación se

enlistan a continuación.

 Incorporar a las herramientas que se pueden utilizar en el campo de la

recuperación de información, la librería de programación “Natix”, la cual realiza
de manera sistemática la generación de las estructuras y métodos para poder
obtener respuesta a búsquedas en espacios métricos.

 La generación de los servicios web como abstracción de la arquitectura de

“Natix”, con el fin de hacer posible, a tecnologías y lenguajes de programación
distintos a los que se utilizaron para la construcción de “Natix”, consumir las
funciones que brinda esta librería.

 El diseño y creación de una interfaz de consulta, para generar una nueva forma de
realizar búsquedas de canciones por contenido. La característica de la interfaz
creada es utilizar los servicios web para recibirla y transmitirla a la librería. El
diseño de esta interfaz ilustra la manera de cómo se utilizan las funciones de
“Natix”, teniendo como base una aplicación con una arquitectura distinta.

El trabajo realizado puede aplicarse en la solución de problemas como:

Detección de duplicación. Determinar si dentro de una colección, dos archivos de audio

tienen el mismo contenido. Aunque muchas veces no es exacto, dos archivos distintos
representan la misma canción. Esta herramienta es de gran utilidad para mantener la integridad
de la base de datos multimedia.
 93

Etiquetado automático. En general, los reproductores proveen información de una base

de datos con el nombre de los archivos de audio, como el álbum, título, etc. Pero si no se
encuentra en la base de datos, se podría buscar con las técnicas de MIR.

Búsquedas con ejemplos. Se utiliza un pequeño trozo del audio para reconocer una
canción en particular.

VII.3 Trabajo a futuro

El trabajo de esta tesis se realizó de acuerdo a los alcances planeados al inicio de la

misma. Si bien se realizó la implementación de una interface para realizar búsquedas de audio
por contenido, existe mucho trabajo por realizar con respecto al diseño e implementación de
nuevas interfaces de consulta, además del trabajo necesario para realizar las búsquedas por
contenido. Por lo cual se consideran como trabajo a futuro los siguientes puntos.

 Realizar una técnica de representación de señales basada en características

geométricas propias del espacio.

 Generar una estructura o índice, donde el tiempo de respuesta a una consulta sea
constante, es decir, al someter una búsqueda el tiempo de espera para un usuario
final no dependa de la cantidad de elementos en una colección. Este índice debe
tener una precisión y un recall aceptable comparado con los resultados que se
pueden observar en el estado del arte.

 La implementación de una interfaz para la consulta de audio por contenido, esta

interfaz se desenvolvería en escenarios donde no se cuenta con una computadora,
pero si con un dispositivo móvil como un celular.
 94

Bibliografía

Allamanche, E., Herre, J., Hellmuth, O., Fröba, B., Kastner, T., Cremer, M. (2001).
Content-based identification of audio material using MPEG-7 low level description. En
Proceedings of the International Symposium of Music Information Retrieval 2001.páginas 197-
204, Octubre 15-17, Indiana, USA.

Baeza-Yates, R. (1997). Searching: an algorithmic tour. Encyclopedia of Computer

Science and Technology, 37(1): 331-359.

Baeza-Yates, R., Cunto, W., Manber, U., Wu, S. (1994). Proximity matching using fixed-
queries trees. En Proceedings of the 5th Combinatorial Pattern Matching 1994. páginas 198-
212, Junio 5-8, California, USA.

Bozkaya, T., Ozsoyoglu, M. (1997). Distance-based indexing for high-dimensional

metric spaces. En Proceedings of the ACM SIGMOD international conference on Management
of data 1997. páginas 357-368. Mayo 13-15, Arizona, USA.

Burkhard, W. A., Keller, R. M. (1973). Some approaches to best-match file searching.

Communications of the ACM, 16(4): 230-236.

Bustos, B., Navarro, G. (2004). Probabilistic proximity searching algorithms based on

compact partitions. Journal of Discrete Algorithms, 2(1), 115-134.

Camarena-Ibarrola, A., Chávez, E. (2006). A Robust Entropy-Based Audio-Fingerprint.

En Proceeding of the International Conference on Multimedia and Expo (ICME 2006). páginas.
1729 - 1732, Junio 9-12, Toronto, Canada.

Cano, P., Batlle, E., Kalker, T., Haitsma, J. (2005). A review of audio fingerprinting. The
Journal of VLSI Signal Processing, 41(3): 271-284.

Chávez, E. (1999). Optimal discretization for pivot based algorithms. Manuscript.

ftp://garota. fismat. umich. mx/pub/users/elchavez/minimax. ps. gz.

Chávez, E., Figueroa, K., Navarro, G. (2008). Effective proximity retrieval by ordering
permutations. IEEE transactions on pattern analysis and machine intelligence, 30(9): 1647-
1658.

Chávez, E., Navarro, G., Baeza-Yates, R., Marroquín, J. L. (2001). Searching in metric
spaces. ACM Computing Surveys (CSUR), 33(3): 273-321.

Ciaccia, P., Patella, M., Zezula, P. (1997). M-tree: An efficient access method for
similarity search in metric spaces. En Proceedings of the International Conference on Very
Large Data Bases 1997. páginas 426-435, Agosto 25-29, Atenas, Grecia.
 95

Cormen, T. H., Leiserson, C. E., Rivest, R. L., Stein, C. (2001). Introduction to

algorithms. The MIT press. 1184.

Dehne, F., Noltemeier, H. (1987). Voronoi trees and clustering problems. Information
Systems, 12(2), 171-175.

Doraisamy, S., Ruger, S. (2002). A Comparative and Fault-tolerance Study of the Use of
N-grams with Polyphonic Music. En Proceedings of the International Conference on Music
Information Retrieval 2002. páginas 53-70, Octubre 13-17, Paris, Francia.

Fagin, R., Kumar, R., Sivakumar, D. (2003). Comparing top k lists. En Proceedings of
the fourteenth annual ACM-SIAM symposium on Discrete algorithms 2003. páginas 28-36,
Enero 12-14, Baltimore, USA.

Grossman, D. A., Frieder, O. (2004). Information retrieval: Algorithms and heuristics.

Kluwer Academic Pub. 332.

Guo, A., Siegelmann, H. (2004). Time-warped longest common subsequence algorithm

for music retrieval. En International Conference on Music Information Retrieval 2004, Octubre
10-14, Barcelona, Espana.

Haitsma, J., Kalker, T. (2003). A highly robust audio fingerprinting system with an
efficient search strategy. Journal of New Music Research, 32(2): 211-221.

Haus, G., Pollastri, E. (2001). An audio front end for query-by-humming systems. En
International Symposium on Music Information Retrieval 2001. páginas 65-72, Octubre 15-17,
Indiana, USA.

Herre, J., Allamanche, E., Hellmuth, O. (2002). Robust matching of audio signals using
spectral flatness features. In Workshop on the Applications of Signal Processing to Audio and
Acoustics, 2001 IEEE. páginas. 127-130, Octubre 21-24, Nueva York, USA.

Kalantari, I., McDonald, G. (2006). A data structure and an algorithm for the nearest
point problem. IEEE Transactions on Software Engineering, 9(5): 631-634.

Kim, S., Yoo, C. D. (2007). Boosted binary audio fingerprint based on spectral subband
moments. En International Conference on Acoustics, Speech and Signal Processing, 2007.
ICASSP 2007. páginas 241-244, Abril 15-17, Honolulu, Hawai.

Kurth, F., Scherzer, R. (2003). Robust Real-Time-Identification of PCM Audio Sources.

Preprints-Audio Enginering Society, páginas 5821.

Manning, D., Prabhakar, R., Hinrich, S. (2008). Introduction to Information Retrieval (1

ed.). Cambridge University Press. 496.
 96

Noltemeier, H., Verbarg, K., Zirkelbach, C. (1992). Monotonous Bisector* Trees—a tool
for efficient partitioning of complex scenes of geometric objects. Data structures and efficient
algorithms, 594(1), 186-203.

Olson, M. A., Bostic, K., Seltzer, M. (1999). Berkeley db. En Proceedings of the
FREENIX Track: USENIX Annual Technical Conference 1999. páginas 183-192, Junio 6-11,
California, USA.

Pauws, S. (2004). Musical key extraction from audio. En Proceedings of the

International Symposium of Music Information Retrieval 2004, Octubre 10-14, Barcelona,
España

Ruiz, V. (1986). An algorithm for finding nearest neighbours in (approximately) constant

average time. Pattern Recognition Letters, 4(3): 145-157.

Seo, J. S., Jin, M., Lee, S., Jang, D., Lee, S., Yoo, C. D. (2005). Audio fingerprinting
based on normalized spectral subband centroids. En Proceedings in the Acoustics, Speech, and
Signal Processing 2005. páginas 213-216, Marzo 18-23, Philadelphia, USA

Shanon, C. E., Weaver, W. (2001). The mathematical theory of communication. ACM

SIGMOBILE Mobile Computing and Communications Review, 5(1): 3-55.

Sukittanon, S., Atlas, L. (2002). Modulation frequency features for audio fingerprinting.
En Proceedings on the Acoustics, Speech, and Signal Processing, 2002. páginas 1773 - 1776,
Mayo 13-17, Florida, USA.

Tellez, E. S., Chavez, E. (2010). On locality sensitive hashing in metric spaces. En

Proceedings of the Third International Conference on SIiilarity Search and Applications 2010.
páginas 67-74, Septiembre 18-19,Istanbul, Turquía.

Uhlmann, J. (1991). Implementing metric trees to satisfy general proximity/similarity

queries. Information Processing Letters, 40(4): 175-179.

Wang, A. (2003). An industrial strength audio search algorithm. En Proceedings of the

International Symposium of Music Information Retrieval 2003. páginas 7-13, Octubre 26-30,
Maryland, USA.

Wold, E., Blum, T., Keislar, D., Wheaten, J. (2002). Content-based classification, search,
and retrieval of audio. IEEE Multimedia, 3(3): 27-36.

Yianilos, P. N. (1993). Data structures and algorithms for nearest neighbor search in
general metric spaces. En Proceedings of the fourth annual ACM-SIAM Symposium on Discrete
algorithms 1993. páginas 311-321, Enero 25-27, Texas, USA.

Yianilos, P. N. (1999). Excluded middle vantage point forests for nearest neighbor
search. In In DIMACS Implementation Challenge, ALENEX'99.
 97

Apéndice A

Implementación de Natix

A.I Introducción

Mono es un proyecto de código abierto de la compañía Novell. El objetivo de este

proyecto es la creación de un compilador ECMA compatible con las herramientas de .NET, tanto
el compilador para C# y CLR. El objetivo de este compilador no es solo poder ejecutar
aplicaciones de .NET en cualquier plataforma, sino además brindar una herramienta de
desarrollo para Linux.

Natix es una librería de programación desarrollada en Mono. Específicamente haciendo

uso del compilador de C#. Es una colección de interfaces genéricas, se pueden implementar para
expandir la funciones de Natix, es decir, si bien Natix en este momento ya cuenta con clases que
implementan las funciones de las interfaces mencionadas, el núcleo de esta librería es la
definición de estas interfaces.

Las interfaces centrales de Natix son las que se muestran en la Figura 50, por un lado
están las interfaces que modelan un espacio métrico y por otro lado el índice que reduce las
comparaciones necesarias para dar respuesta a una búsqueda.

Figura 50. Interfaces centrales para implementar un espacio métrico en Natix.

 98

Con las interfaces Space y Space<T>, se definen las reglas para modelar dentro de la
librería un espacio métrico. Los detalles de la interfaz se muestran a continuación.

Figura 51. Interfaces que modelan un espacio en natix.

Como se muestra en la Figura 51, la interfaz Space se compone de las propiedades y

métodos que se describen a continuación.

Propiedades Tipo
Count Retoma el número de objetos en el espacio Entero
Name Retoma y establecer el nombre del espacio Cadena
NumberDistances Retoma el número de distancias evaluadas en el espacio Entero
SpaceType Retoma el tipo de espacio Type

Metodos Tipo
CreateResult() Formatea los resultados de búsquedas IResult
SubSpace() Guarda un sub conjunto de objetos del espacio. Void

Tabla IV. Descripción de métodos y propiedades de la interface Space.

 99

Uno de los objetivos principales de esta librería es poder modelar cualquier tipo de
conjunto de objetos que puedan compararse de alguna forma. Es por ello, que se utiliza las
interfaces genéricas que forman parte del compilador de Mono. Como se puede ver en la Figura
51, la forma de la interface es Space<T>, donde <T> representa una colección de cualquier tipo
de objeto.

Space<T> es una interfaz que implementa cualquier espacio que se desea modelar y al
implementarla las propiedades y métodos que se requieren agregar se enlistan a continuación.

Propiedades Tipo
this Retoma un objeto en el índice j T

Metodos Tipo
Dist() Evalúa la distancia entre dos objetos del espacio Double
Parse() Analiza objetos, para agregarlos al espacio Bolean

Tabla V. Descripción de métodos y propiedades de la interface Space<T>.

A.II Modelando un espacio métrico con Natix

Para modelar un espacio es necesario primeramente crear una clase, darle un nombre que
represente el espacio que modela. Después hay que implementar la interfaz Space<T> y de paso
definir el tipo de objeto que es T, en el ejemplo que se muestra en la Figura 52 se puede observar
que en la clase “BinaryHammingSpace” se quiere modelar un espacio binario de haming. Esta
clase implementa la interface Space<T>, por lo que es necesario agregar dentro la clase
“BinaryHammingSpace” las propiedades y métodos de las interfaces Space y Space<T>, además
se pueden agregar más, según se necesiten dependiendo del espacio.
 100

Figura 52. Ejemplo de implementación de un espacio en Natix

Para el ejemplo presentado en la Figura 52, T lo definen objetos del tipo IList<byte>, esto
significa que el espacio lo componen listas de bytes. Un ejemplo de objetos que se pueden
mapear a este espacio son los AFPs que se obtienen de la técnica MBSES. Como se explicó
anteriormente, la funcionalidad mínima de espacio dentro de Natix la definen las interfaces y el
código que se ejecuta dentro de las propiedades y métodos implementados dependerán del
resultado que se desee. El código a continuación ejemplifica el espacio mencionado dentro de
Natix.

public class BinaryHammingSpace : Space< IList<byte> >

{
public string Name
{
set { /*Se agrega el código*/}
get { /*Se agrega el código*/}
}
public IResult CreateResult (int K, bool ceiling)
{
///*Se agrega el código*/
}
public IList<byte> this(int docid)
{
get { /*Se agrega el código*/}
set { /*Se agrega el código*/ }
}
public void SubSpace (string name, IList<int> sample)
{
/*Se agrega el código*/
}
public IList<byte> Parse (string name, bool isquery)
{
/*Se agrega el código*/
}
public int Count {
get { /*Se agrega el código*/}
}
public int NumberDistances
{
get { /*Se agrega el código*/}
 101

}
public string SpaceType {
get { /*Se agrega el código*/}
set {/*Se agrega el código*/ }
}

public double Dist (IList<byte> a, IList<byte> b)

{
/*Se agrega el código*/
}
}
Si bien con el código anterior se define el espacio binario de hamming, cambiando el
objeto genérico T y la manera en la que se comparan dos objetos T se define un nuevo espacio.
Es por ello que dentro de Natix se puede modelar cualquier conjunto de objetos que se puedan
comparar de alguna manera.

A.III Implementando un índice en Natix

Al igual que en el caso de la creación de espacios en Natix, agregar un índice va a

depender de la implementación de interfaces que definen el comportamiento básico de un índice.
Las interfaces encargadas de definir las reglas para agregar un índice a Natix son Index,
Index<T> y además la clase abstracta BaseIndex<T>, también como es el caso de los espacios
además de requerir implementar las propiedades y métodos de estas interfaces. Un índice dentro
de Natix tiene como propiedad principal un espacio, es decir, cualquier estructura parte del
espacio al cual se quiere mejorar el rendimiento en el proceso de búsqueda de un objeto dentro
del mismo.

Para implementar un nuevo índice dentro de Natix es necesario seguir la jerarquía que se
muestra en la Figura 53, donde para un usuario solo se requiere heredar dentro de una clase la
clase abstracta BaseIndex<T>, aunque la definición de la clase BaseIndex<T>, la definen tanto
Index e Index<T>, que son interfaces en un nivel jerárquicamente hablando más alto.
 102

Figura 53. Ejemplo de implementación de un índice en Natix

Los métodos y propiedades básicos a sobrescribir de la clase abstracta BaseIndex<T> se

enlistan y detallan a continuación.

Propiedades Tipo
Cost Retoma el costo empleado en la búsquedas Object
IndexType Retoma y establecer el tipo de índice Type
MainSpace Retoma el espacio con el que se construye el índice Space<T>

Metodos Tipo
Build() Construye un índice Void
FinalizeLoad() Carga los parámetros del espacio al finalizar la carga Void
KNNSearch() Busca por el régimen de los k-vecinos IResult
Search() Busca por el régimen de búsqueda por radio IResult

Tabla VI. Métodos y propiedades de la interface BaseIndex<T>

Ejemplificando lo anterior el código que se muestra a continuación muestra la sobre

escritura de los métodos de la clase BaseIndex<T> un índice secuencial.
 103

public class Sequential<T> : BaseIndex<T>

{

public override void Build (IEnumerable<string> args)

{
/*Se agrega el código*/
}
public override void FinalizeLoad (string name,
{
/*Se agrega el código*/
}

public override IResult Search (T q, double radius)

{
/*Se agrega el código*/
}

public override IResult KNNSearch (T q, int k, IResult R)

{
/*Se agrega el código*/
}

A.IV Creando un índice en Natix.

Una vez que se han implementado un índice dentro de Natix, la tarea es hacer uso del
mismo, el ejemplo de código a continuación ejemplifica el uso de un índice.

Sequential<IList<byte>> indexObject = new Sequential<IList<byte>>();

indexObject.Build("SequentialIndex.xml", "binaryhamming", "Dblist.list");

Con estas dos líneas de código Natix, tomará de un archivo de texto una lista de rutas que
apuntan a objetos que conformarán el espacio métrico, después definirá el espacio con la
distancia de hamming y por último guardará en un archivo xml los propiedades del índice para
poder usarlo después de ejecutar las búsquedas necesarias. Si bien la creación de los índices
puede variar dependiendo de los parámetros que requiere cada índice, al ser el método Build un
método abstracto en la clase BaseIndex<T>, siempre se crearán los índices haciendo uso de éste.
 104

A.V Buscando dentro de un índice en Natix

Una vez construido el índice ya se pueden realizar búsquedas de objetos dentro del índice,
suponga que se quiere encontrar los 10 vecinos más cercanos a un objeto q en el espacio que
utiliza el índice creado anteriormente.

Index indexObject = IndexLoader.Load(("SequentialIndex.xml");

Sequential<IList<byte>> idx=(Sequential<IList<byte>>)indexObject;
Result res = idx.ParseKNNSearch("Query10secs.ntx", 10);

Con la primera línea se carga el espacio y el índice en memoria, utilizando los parámetros que se
guardaron en la construcción del índice en el archivo “SequentialIndex.xml”.

Después se realiza un “cast” del objeto genérico Index a uno específico como Sequential, esto
puede realizarse gracias a la herencia utilizada en la jerarquía de Natix.

Por último, utilizado el método ParseKNNSearch, se puede dar como parámetro una cadena que
represente un archivo físico que cuente con la ruta donde está el objeto q, este método se encarga
de pasar de un archivo de texto al objeto T y poder entonces comparar los objetos espacio con q.
Este método toma como parámetros, la cadena que representa el archivo y los vecinos que se
quieren recuperar. Como resultado se obtiene un objeto Result, que básicamente se puede tratar
como un arreglo.

A.VI Montando Natix en un servicio web

El enfoque de crear un cliente para Natix era mostrar la efectividad y sencillez de uso de la
librería, pero además la característica de ser multiplataforma y además poder ser usada en
arquitecturas que se desenvuelvan en internet.

Es por ello que se montó el servicio web http://www.natix.org/natix-web/audio/wsNatix.asmx,

este servicio lo puede consumir por cualquier lenguaje que soporte este tipo de tecnologías, que
hoy en día son casi todos.
 105

Dentro de este servicio web se encuentra el método KNNSearchMBSES, el cual toma una
cadena binaria como entrada y la compara con una colección de canciones que se tienen
representadas en el servidor natix.org. Como respuesta regresa un archivo con formato Json que
representa los metadatos de las 10 canciones más cercanas a la cadena binaria que se tomó como
consulta.

El código dentro del método KNNSearchMBSES se detalla a continuación.

(WebMethod)
public string KNNSearchMBSES(string query)
{
string serverpath = base.Server.MapPath(".");
StreamWriter SW = File.CreateText(serverpath + "Query10secs.ntx");
SW.WriteLine(query);
SW.Close();
Sequential<IList<byte>> idx = (Sequential<IList<byte>>)
IndexLoader.Load("/home/fluque/Index_Sequential2/Index.audio.Seq.xml");
Result res = idx.ParseKNNSearch(serverpath + "Query10secs.ntx", 10);
BinaryHammingSpace Space = (BinaryHammingSpace) idx.MainSpace;
List<Resultado> mListResultado = new List<Resultado>();
for (int i = 0; i < 10; i++)
{
ResultPair RsPair = res.PopFirst();
string dcname = Space.GetItemName(RsPair.docid).Replace(".wav.afp", "");
Console.WriteLine(dcname);
File Tagfile = File.Create(dcname);
Resultado ObjResultado = new Resultado();
ObjResultado.Album = Tagfile.Tag.Album;
ObjResultado.Artist = (Tagfile.Tag.Artists.Length != 0) ? Tagfile.Tag.Artists(0).ToString() :
"Untitled";
ObjResultado.Dist = RsPair.dist.ToString();
ObjResultado.Genre = (Tagfile.Tag.Genres.Length != 0) ? Tagfile.Tag.Genres(0).ToString() :
"Untitled";
ObjResultado.Id = RsPair.docid;
ObjResultado.PathDoc = dcname;
ObjResultado.TrackName = Tagfile.Tag.Title.ToString();
ObjResultado.Year = Tagfile.Tag.Year.ToString();
mListResultado.Add(ObjResultado);
}
string json = JsonConvert.SerializeObject(mListResultado, Formatting.Indented);
Console.WriteLine(json);
return json;
}