Cómo construir un corpus de audio para investigación musical

Un corpus de audio no es una playlist. Una playlist es una secuencia de escucha; un corpus es una colección con estructura, etiquetas y unas condiciones de grabación conocidas que permiten reproducir el experimento. La diferencia importa porque un sistema de MIR (Music Information Retrieval) —ya sea de transcripción, detección de tonalidad o clasificación de instrumentos— solo es tan bueno como los datos con los que lo entrenas o evalúas.

Aquí explico cómo se monta un corpus desde cero con herramientas accesibles, y qué decisiones separan una colección de archivos de un recurso que otra persona pueda reutilizar.

Qué define un corpus (y qué lo diferencia de una colección)

Tres propiedades distinguen un corpus de una carpeta con archivos WAV:

• Estructura: los archivos están organizados con criterio. No importa si es por instrumento, por intérprete, por contexto de grabación o por tarea de análisis — lo que importa es que el criterio está explícito y es consistente.
• Etiquetas: cada archivo va acompañado de metadatos que describen lo que contiene. Sin etiquetas, el corpus no puede servir de dato de entrenamiento ni de referencia para evaluación.
• Reproducibilidad: alguien que no eres tú debería poder usar el corpus y obtener los mismos resultados. Esto implica documentar cómo se grabó, con qué equipo y bajo qué condiciones.

Si falta cualquiera de las tres, tienes material, no corpus.

Equipo mínimo viable

No hace falta un estudio de grabación. Hace falta control sobre el ruido.

Lo mínimo que funciona para empezar:

• Un micrófono de condensador de entrada media (o, en su defecto, un móvil moderno grabando a 44.1 kHz / 16 bit WAV, sin compresión). La calidad de la cápsula importa más que la marca del interfaz.
• Una grabadora de campo — el formato H4n o similar — si vas a grabar fuera del estudio o en contextos de actuación en vivo. El registro en tarjeta SD evita la latencia de USB y el ruido de ventilador de un ordenador.
• Silencio controlado: un cuarto sin reverb artificial, sin HVAC audible, sin tráfico de fondo. El ruido que entra en la grabación no se puede sacar del todo en postproceso.

La regla práctica: graba en WAV sin comprimir desde el principio. El MP3 descarta información que quizás necesites para análisis espectral.

Software: de la grabación a la anotación

Audacity es la puerta de entrada lógica. Es libre, multiplataforma y permite grabar, recortar, normalizar y exportar en los formatos que necesita cualquier pipeline de MIR. Para un corpus inicial, es suficiente.

Cuando el análisis se vuelve más exigente, Sonic Visualiser entra en escena. No graba, pero permite visualizar espectrogramas, añadir capas de anotación temporal (onset, pitch, segmentación) y exportarlas en formatos estándar como CSV o .svl. Es la herramienta que uso para la anotación temporal fina.

Para corpus más grandes, con anotaciones colaborativas o control de versiones del dataset, herramientas como Label Studio o Praat (este último orientado a fonética pero útil para análisis de pitch) cubren necesidades que Audacity no alcanza.

Para el análisis exploratorio inicial, los cuadernos Jupyter son el entorno de trabajo habitual antes de formalizar el pipeline: permiten cargar un archivo WAV, trazar un espectrograma y anotar decisiones metodológicas en el mismo documento. La base matemática de lo que visualiza Sonic Visualiser —la descomposición en frecuencias— está explicada en la transformada de Fourier.

Metadatos: qué registrar para que el corpus sea útil

Los metadatos son la mitad del trabajo. Sin ellos, las grabaciones no se pueden filtrar, reproducir ni comparar. Como mínimo:

Más campos se añaden según la tarea: si el corpus es para detección de melodía, necesitas la transcripción de referencia; si es para identificación de instrumento, el instrumento ya es la etiqueta.

Organización de ficheros

Una estructura plana no escala. Una estructura que funciona:

corpus/
  metadata.csv          # tabla maestra (una fila por grabación)
  recordings/
    <id>_<context>.wav  # ficheros de audio con ID consistente
  annotations/
    <id>.csv            # anotaciones temporales por fichero
  README.md             # protocolo de grabación y criterios

El README.md del corpus es tan importante como los datos: debe explicar quién grabó, cuándo, con qué equipo y bajo qué protocolo. Sin ese documento, el corpus no es reproducible.

Empezar pequeño

El error más común al montar un corpus es buscar exhaustividad desde el principio. No hace falta. Un conjunto inicial pequeño pero bien anotado —con criterios claros de qué se graba, cómo y por qué— vale más que miles de archivos sin etiquetar. La pregunta que guía el diseño no es «cuánto audio puedo reunir», sino «qué quiero poder evaluar con estos datos».

Ese es el cruce entre el cacharreo del laboratorio y el rigor de la investigación: construir el dato que no existe para poder hacerse la pregunta que no se puede responder sin él.

Bibliografía

Las referencias en las que se apoya este artículo y por dónde seguir leyendo:

• Müller, M. (2015). Fundamentals of Music Processing: Audio, Analysis, Algorithms, Applications. Springer.
• Cannam, C., Landone, C. y Sandler, M. (2010). «Sonic Visualiser: An Application for Viewing and Analysing Music Audio Files». En Proceedings of the ACM Multimedia International Conference.
• Wilkinson, M. D. et al. (2016). «The FAIR Guiding Principles for scientific data management and stewardship». Scientific Data, 3, 160018.
• Herramientas libres: Audacity · Sonic Visualiser.