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 posgrado en ciencias de la

computación

Director de Estudios de Posgrado

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

Figura Página

1 Tabla relacional con estructura definida, para alamcenar datos

estructurados ...…………………………………….……...…………….. 2

2 Ejemplo de colección de datos no estructurados ……………….………. 3

3 Representación de un índice invertido o archivo invertido aplicado en

texto libre.………………………..…..…………………………….……. 5

4 Conjuntos de elementos relevantes recuperados, recuperados y

relevantes……………………………...………………………………… 6

5 Gráfica de presión en varios puntos del recall ...……………………...… 7

6 Proceso genérico para indexar y realizar búsquedas de objetos

multimedia ……………………….……………………………………... 13

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 …...……. 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

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

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

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

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

21 Gráfica tiempo-frecuencia de una consulta sobre puesta en la gráfica

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

24 Histograma resultado de la comparación de una canción de la colección

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

35 Implementación de una tabla hash utilizando el método de

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

43 Gráfica de resultados del expermiento variación de bits realizado sobre

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).

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

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 0.2 0.4 0.6 0.8 1

Pre

sici

ón

Recall

comportamiento típico

comportamiento óptimo

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.

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.

0

500

1000

1500

2000

2500

3000

3500

4000

0 1 2 3 4 5 6 7 8 9

Fre

cuen

cia

Tiempo

42

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.

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.

0

500

1000

1500

2000

2500

3000

3500

4000

0 2 4 6 8

Frec

uen

cia

Tíempo

0

500

1000

1500

2000

2500

3000

3500

4000

0 2 4 6 8

Frec

uen

cia

Tíempo

Cancion en BD

Consulta

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.

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.

punto anclaje

0

500

1000

1500

2000

2500

3000

3500

4000

0 2 4 6 8

Frec

uen

cia

Tíempo

zona objetivo

44

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

(t1,f1)

t=t2-t1

(t2,f2)

[f1:f2:t]| trackId:t1hash|trackId: t1=

0

500

1000

1500

2000

2500

3000

3500

4000

0 2 4 6 8

Frec

uen

cia

Tíempo

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

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.

0

5

10

15

20

25

30

35

0 10 20 30 40 50 60 70 80

Rangos de desplazamiento

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

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.

0

10

20

30

40

50

60

1000 2000 3000 4000 5000 6000 7000 8000 9000

Canción x

Canción y

Canción z

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.

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.

0

10

20

30

40

50

60

70

80

90

100

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

10 vecinos mas cercanos

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.

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

0

20

40

60

80

100

120

100 consultas

NN

KNN

Mal

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.

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.

0

2000

4000

6000

8000

10000

12000

14000

1

54

10

7

16

0

21

3

26

6

31

9

37

2

42

5

47

8

53

1

58

4

63

7

69

0

74

3

79

6

84

9

90

2

95

5

Hamming determinística

Distancia

84

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

0

5

10

15

20

25

30

35

40

1 6

11

16

21

26

31

36

41

46

51

56

61

66

71

76

81

86

91

96

Min

uto

s

Tiempo de búsqueda

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.

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

0

20

40

60

80

100

120

100 consultas

NN

KNN

Mal

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.

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.

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.

0

100

200

300

400

500

600

700

800

900

1 8

15

22

29

36

43

50

57

64

71

78

85

92

99

Hamming probabilística

No. Frames con match

0

1

2

3

4

5

6

7

8

9

1 5 9

13

17

21

25

29

33

37

41

45

49

53

57

61

65

69

73

77

81

85

89

93

97

Tiempo de búsqueda

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

Métrica Hamming probabilística Hamming

determinística

Tamaño de la colección 500 500

Número de consultas 100 100

Recall 100% 100%

Tiempo aproximado por consulta 3.060539 Minutos

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;

}