--- title: "Cómo construir un corpus de audio para investigación musical" slug: construir-corpus-audio kind: guide summary: "Un corpus de audio no es una playlist: es una colección estructurada, etiquetada y reproducible. Qué hace falta para que sirva de verdad en investigación MIR y cómo empezar con herramientas accesibles." publishedAt: 2026-06-22 updatedAt: 2026-06-22 --- import { Image } from "astro:assets"; import infografiaCorpus from "../../assets/blog/posts/infografias/infografia-corpus-audio.jpg"; 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.
Infografía del flujo de construcción de un corpus de audio: de la partitura a la digitalización, al audio (forma de onda y espectrograma), a la anotación con metadatos y al corpus estructurado final. El ejemplo usa una grabación de dominio público de Beethoven.
El recorrido completo de un corpus de audio, de la partitura al dato estructurado. El ejemplo —la Sonata n.º 14 de Beethoven en una grabación histórica de dominio público (Schnabel, 1932)— muestra cómo cada grabación se acompaña de metadatos que la hacen filtrable, comparable y reproducible.
## 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. ## 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: | Campo | Descripción | |---|---| | `instrument` | Nombre canónico del instrumento grabado | | `performer` | Identificador del intérprete (puede ser anonimizado) | | `context` | Estudio / campo / actuación en vivo | | `date` | Fecha de grabación (ISO 8601) | | `recorder` | Dispositivo y micrófono usados | | `sample_rate` | Frecuencia de muestreo en Hz | | `bit_depth` | Profundidad de bit (16 / 24) | | `duration_s` | Duración en segundos | | `annotation` | Ruta al archivo de anotación si existe | 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/ _.wav # ficheros de audio con ID consistente annotations/ .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*](https://doi.org/10.1007/978-3-319-21945-5). Springer. - Cannam, C., Landone, C. y Sandler, M. (2010). [«Sonic Visualiser: An Application for Viewing and Analysing Music Audio Files»](https://doi.org/10.1145/1873951.1874248). En *Proceedings of the ACM Multimedia International Conference*. - Wilkinson, M. D. et al. (2016). [«The FAIR Guiding Principles for scientific data management and stewardship»](https://doi.org/10.1038/sdata.2016.18). *Scientific Data*, 3, 160018. - Herramientas libres: [Audacity](https://www.audacityteam.org) · [Sonic Visualiser](https://www.sonicvisualiser.org).