El siguiente post es un trabajo de sondeo y categorización sobre diferentes formatos de notación musical, con el objetivo de organizar un marco teórico que los agrupe con coherencia académica, así como establecer una base para analizar posteriormente los trabajos de conversión entre ellos. La finalidad última es trabajar desde la Inteligencia Artificial la creación y comprensión en estos formatos: algunos —principalmente los basados en código— son directamente legibles por un modelo de lenguaje; otros requieren conversión previa desde otro formato, ya sea para ser interpretables por humanos o por la propia IA.
Por transparencia, se informa que este trabajo se ha desarrollado en colaboración con Claude Sonnet 4.6 (Anthropic). La IA ha participado en el proceso: sugiriendo formatos que no estaban inicialmente contemplados (MEI, MuseData, Braille musical), explorando y refinando conjuntamente las categorías taxonómicas, y revisando críticamente el marco teórico de referencia -Seeger-, para valorar su pertinencia, y conocer matizaciones y críticas de otros autores a los mismos (Goodman, Nattiez, Cook y Nettl); así como los límites en este contexto. Las referencias académicas citadas han sido verificadas por el autor, comprobando que los argumentos atribuidos a cada obra reflejan fielmente su contenido original. El criterio de selección, la orientación del proyecto y las decisiones finales sobre el marco son del autor.
Marco teórico
La distinción prescriptivo/descriptivo (Seeger, 1958)
El punto de partida de este trabajo es la distinción formulada por Charles Seeger en su artículo «Prescriptive and Descriptive Music Writing». Seeger propone que toda notación musical mantiene una relación asimétrica con la música que representa, y que esa relación puede orientarse en dos direcciones:
- Notación prescriptiva: precede a la música y la instruye. Es un guión para una acción futura.
- Notación descriptiva: sigue a la música y la registra. Es una huella de algo que ya ocurrió.
Seeger observó que la notación occidental clásica es prescriptiva en su intención pero inevitablemente descriptiva en su resultado, pues nunca captura la totalidad de lo que ocurre en la ejecución real. Esta brecha entre lo escrito y lo sonado es el núcleo productivo de su argumento.
Este trabajo adopta el marco de Seeger como punto de partida operativo, pero lo matiza con aportaciones posteriores que complejizan la dicotomía original. La distinción prescriptivo/descriptivo no es discreta sino un continuo, y la mayoría de los formatos aquí estudiados se sitúan en posiciones distintas de ese espectro según el contexto de uso.
Autográfico y alográfico (Goodman, 1968)
Nelson Goodman, en Languages of Art , propone una distinción complementaria: las obras autográficas tienen una instancia única cuya identidad depende de su historia de producción (una pintura, una escultura); las obras alográficas pueden tener múltiples instancias correctas, por ejemplo definidas por un sistema notacional (una sinfonía, un poema).
La notación musical occidental funciona como sistema alográfico: define qué cuenta como ejecución correcta. Esta distinción resulta especialmente relevante cuando se contrasta la interpretación humana con la reproducción computacional:
- Cuando un intérprete humano lee una partitura, la obra funciona como alográfica: hay un margen legítimo de variación en tempo, dinámica, articulación y ornamentación que no compromete la identidad de la obra.
- Cuando un ordenador renderiza el mismo archivo, la obra tiende a funcionar como autográfica: el resultado es determinista y unívoco, salvo que se hayan codificado explícitamente propiedades interpretativas (como el swing de corcheas en MuseScore, o las curvas de expresión de una librería de sonidos MIDI, o los propios sonidos de esa librería).
Esta tensión entre lo alográfico y lo autográfico es especialmente productiva para el estudio de la interoperabilidad: un formato puede ser semánticamente equivalente a otro pero producir instancias sonoras radicalmente distintas según el motor de renderizado.
La semiología tripartita (Nattiez, 1990 / Molino)
Jean-Jacques Nattiez, desarrollando el modelo semiológico de Jean Molino, propone analizar los fenómenos musicales en tres niveles (Nattiez, 1990):
- Nivel poiético: el proceso de producción, la intención del compositor.
- Nivel neutro: el texto, el objeto en sí, independiente de su producción y recepción.
- Nivel estésico: el proceso de recepción e interpretación por parte del oyente o intérprete.
Este trabajo opera exclusivamente en el nivel neutro: se analizan los formatos como objetos textuales, con independencia de las intenciones de quien los produjo o de las interpretaciones que puedan suscitar. Esta delimitación es metodológicamente necesaria para abordar la interoperabilidad de forma sistemática, aunque implica reconocer que se excluyen dimensiones relevantes de la práctica musical.
La partitura como objeto complejo (Cook) y el situacionismo cultural (Nettl)
Nicholas Cook ha argumentado que tratar la partitura como texto autoritativo simplifica una relación mucho más compleja entre notación, intérprete y obra (Cook, 1987). La partitura no prescribe completamente la ejecución sino que abre un espacio de negociación donde el intérprete es un agente constitutivo, no meramente ejecutor.
Por su parte, Bruno Nettl y la tradición etnomusicológica recuerdan que cualquier marco analítico sobre notación está culturalmente situado (Nettl, 1983). La distinción prescriptivo/descriptivo, y la propia noción de partitura como objeto autoritativo, asumen una tradición notacional occidental específica. En músicas de tradición oral la notación es siempre descriptiva por definición, y la pregunta por la identidad de la obra se disuelve.
Este trabajo asume explícitamente ese situacionismo: el corpus estudiado pertenece a la tradición notacional occidental, y las categorías utilizadas son válidas dentro de ese marco. No se pretende universalidad. Y los códigos musicales informáticos que permiten codificaciones más puramente descriptivas se analizarán en otro trabajo posterior.
Síntesis: el continuo prescriptivo/descriptivo
Integrando estos marcos, la distinción prescriptivo/descriptivo se entiende aquí no como una dicotomía sino como un continuo con varios ejes relevantes:
| Eje | Polo prescriptivo | Polo descriptivo |
|---|---|---|
| Temporalidad | La notación precede a la obra | La notación sigue a la obra |
| Determinación | Todos los parámetros están fijados | Parámetros abiertos a decisión del intérprete |
| Agencia | Intérprete como ejecutor | Intérprete como coautor |
| Instancia (Goodman) | Autográfica (renderizado computacional) | Alográfica (interpretación humana) |
| Recuperabilidad | La obra es reconstruible desde la notación | La notación es insuficiente para reconstruir la obra |
Los formatos estudiados en este trabajo se definen operativamente como Codificaciones de Notación Musical Prescriptiva: fijan «completamente» los parámetros musicales relevantes de una obra de forma que cualquier instancia de ejecución es verificable contra ellos. Esta definición excluye formatos abiertos a la improvisación (lead sheets, estándares de jazz), generativos (Strudel, TidalCycles, SuperCollider) o de notación gestual indeterminada (partituras gráficas de Cage o Cardew), que ya hemos comentado estudiaremos en ocasiones posteriores.
Taxonomía de formatos
Proponemos organizar los formatos en cuatro subcategorías según su naturaleza semiótica y la tecnología de recuperación necesaria para convertirlos a otros formatos. Cada nivel implica mayor pérdida de información y mayor complejidad técnica de conversión.
Principio organizador: a medida que descendemos en las subcategorías, la distancia al texto simbólico aumenta, la información implícita crece y la recuperación requiere tecnologías más sofisticadas y menos fiables.
| Subcategoría | Recuperación | Tecnología |
|---|---|---|
| 1. Semántico-notacional | Directa / parseable | Conversores de formato |
| 2. Performativo | Inferencia notacional | Cuantización, análisis de voz |
| 3. Renderizado visual | Reconocimiento óptico | OMR (Optical Music Recognition) |
| 4. Renderizado sonoro | Transcripción automática | AMT (Automatic Music Transcription) |
Semántico-notacional
Contienen la información musical estructurada y simbólica en forma parseable por máquina. Son los formatos más próximos al polo prescriptivo del continuo.
| Formato | Extensión | Carácter | Pérdida específica al salir de él |
|---|---|---|---|
| MusicXML | .musicxml / .xml | Estándar abierto W3C. Hub de interoperabilidad. | — |
| MXL | .mxl | MusicXML comprimido. Mismo contenido semántico. | — |
| MSCZ | .mscz | Formato nativo propietario de MuseScore. | Layout visual, estilos de página, instrumentos personalizados |
| MEI | .mei | Académicamente más rico. Ediciones críticas y notación histórica. | Metadatos de edición crítica, variantes, aparato crítico |
| ABC Notation | .abc | Texto ligero. Orientado a música monofónica y folk. | Limitaciones en polifonía compleja, ornamentación avanzada |
| LilyPond | .ly | Basado en código. Tipografía de alta calidad. | Lógica programática, variables, funciones del código fuente |
| Humdrum/**kern | .krn | Estándar de facto en musicología computacional. | Representaciones analíticas propias |
| MuseData | — | Formato académico histórico. Corpus CCARH. | Metadatos específicos de corpus académicos |
| Partitura manuscrita | — | Objeto físico único. Información gestual irreproducible. | Gestualidad del trazo, orientaciones visuales al intérprete, unicidad autográfica |
Performativo
Codifican una interpretación concreta, no la partitura simbólica subyacente.
| Formato | Naturaleza | Pérdida específica al salir |
|---|---|---|
| MIDI | Digital. Codifica notas, duraciones, velocidades y canales. No distingue enarmónicos ni ligaduras escritas. | Enarmónicos, articulaciones escritas, semántica de compás |
| Piano roll físico (básico, 65 notas) | Analógico. Sin control expresivo. | Toda expresión dinámica y temporal |
| Piano roll expresivo (Welte-Mignon, Duo-Art, Aeolian Themodist) | Analógico con codificación de dinámica y expresión. | Idiosincrasia del sistema propietario de cada fabricante |
Renderizado visual
Son representaciones gráficas de la partitura. La recuperación requiere OMR (Optical Music Recognition).
| Formato | Tipo | Calidad para OMR | Pérdida al salir |
|---|---|---|---|
| PDF desde software de notación | Vectorial | Alta | Toda la semántica musical |
| PDF escaneado / imagen | Raster (píxeles) | Variable | Idem, con ruido adicional del escaneo |
| PNG / JPG de partitura | Raster | Similar al PDF escaneado | Idem |
| Braille musical | Táctil | Muy baja (dirección Braille→MusicXML) | Sistema de contracción propio sin equivalente visual |
Nota sobre raster y vectorial: una imagen raster está formada por una cuadrícula de píxeles con color fijo; si se amplía, se pixela. Una imagen vectorial se define mediante fórmulas matemáticas (curvas, formas) y puede escalarse sin pérdida. Para el OMR, el vectorial es mucho más limpio de procesar.
Renderizado sonoro
Son señales acústicas digitalizadas. La recuperación requiere AMT (Automatic Music Transcription).
| Formato | Compresión | Calidad para AMT |
|---|---|---|
| WAV | Sin compresión | Máxima |
| FLAC | Sin pérdida | Equivalente a WAV en calidad |
| MP3 | Con pérdida | Algo inferior; artefactos de compresión |
| OGG, AIFF, otros | Variable | Según códec y tasa de bits |
Descripción detallada de los formatos
MusicXML
Tipo: Semántico-notacional
Extensión: .musicxml (sin comprimir) / .xml (uso legacy)
Web oficial: musicxml.com / W3C spec
Mantenedor: W3C Music Notation Community Group (presidido por Michael Scott Cuthbert, Adrian Holovaty y Daniel Spreadbury)
MusicXML es el estándar abierto de intercambio de notación musical. Fue desarrollado originalmente por MakeMusic (fabricante de Finale) a principios de los 2000 y transferido al W3C Music Notation Community Group, que publicó la versión 4.0 como W3C Community Group Final Report en junio de 2021 (W3C Music Notation Community Group, 2021). La versión 4.0 es compatible con versiones anteriores y amplió el soporte para partituras de conjunto, seguimiento de partitura en tiempo real y reproducción con swing.
Internamente es XML puro, legible en cualquier editor de texto. Organiza la información musical en dos posibles jerarquías: partwise (organizado por partes/instrumentos) y timewise (organizado por compases). La mayoría del software exporta en partwise. Representa con precisión alturas, duraciones, articulaciones, dinámicas, ligaduras, ornamentos, texto, acordes, sistemas de compases, indicaciones de tempo y mucho más.
Es el hub central de interoperabilidad del ecosistema: prácticamente todo software de notación puede importarlo y exportarlo, y es el formato pivote por el que pasan la mayoría de conversiones entre otros formatos. Está soportado por más de 250 aplicaciones (W3C Music Notation Community Group, 2021).
Software que lo genera o consume: MuseScore, Finale (D.E.P.), Sibelius, Dorico, Noteflight, Flat.io, Verovio, music21, y cientos más.
MXL
Tipo: Semántico-notacional
Extensión: .mxl
Web oficial: misma que MusicXML
Mantenedor: W3C Music Notation Community Group
MXL es MusicXML comprimido mediante ZIP estándar. El contenido semántico es idéntico al de un archivo MusicXML sin comprimir; la diferencia es exclusivamente de tamaño y conveniencia. El archivo ZIP contiene un fichero rootfile que apunta al XML principal, y desde MusicXML 4.0 puede contener también las particellas de las partes junto a la partitura completa en un único archivo (W3C Music Notation Community Group, 2021).
La compresión típica reduce el tamaño entre 5 y 10 veces respecto al XML sin comprimir. Algunas herramientas online (como ciertas versiones de Verovio) requieren el archivo descomprimido y no aceptan MXL directamente.
Software que lo genera o consume: los mismos que MusicXML.
MSCZ
Tipo: Semántico-notacional
Extensión: .mscz
Web oficial: musescore.org
Mantenedor: MuseScore BVBA (empresa belga) / comunidad open source en GitHub
MSCZ es el formato nativo de MuseScore, el software de notación libre y de código abierto más extendido del mundo. Fue creado en 2002 por Werner Schweer como bifurcación del secuenciador MusE. MuseScore es software libre bajo licencia GPLv3, con repositorio activo en GitHub (musescore/MuseScore).
Internamente, MSCZ es un archivo ZIP que contiene un fichero .mscx (XML interno de MuseScore), miniaturas y metadatos. El XML interno usa una estructura propia de MuseScore, distinta de MusicXML, aunque ambas son XML. Almacena toda la información de la partitura: notas, ritmos, dinámicas, articulaciones, texto, pero también información de maquetación visual (posición de los pentagramas, márgenes, estilos tipográficos, fuentes), configuración de instrumentos, soundfonts vinculadas y estado del editor.
A diferencia de MusicXML, MSCZ no es un estándar de interoperabilidad sino un formato de autoría. Solo MuseScore y herramientas del ecosistema MuseScore (MuseScore.com, algunas extensiones) pueden abrirlo directamente. La ruta de interoperabilidad es siempre MSCZ → MusicXML.
Software principal: MuseScore Studio (Windows, macOS, Linux). También accesible online en musescore.com.
MEI (Music Encoding Initiative)
Tipo: Semántico-notacional
Extensión: .mei
Web oficial: music-encoding.org
Mantenedor: Music Encoding Initiative, co-hospedada por la Akademie der Wissenschaften und der Literatur (Mainz) y el RISM Digital Center (Berna)
MEI es un estándar abierto basado en XML, desarrollado por una comunidad académica internacional de tecnólogos, bibliotecarios, historiadores y teóricos de la música. Comenzó a principios de los 2000 con Perry Roland en la Universidad de Virginia y se formalizó como proyecto comunitario en torno a 2010.
A diferencia de MusicXML, MEI está diseñado desde una perspectiva de humanidades digitales: puede codificar no solo la notación musical sino también metadatos de edición crítica (variantes de fuentes, aparato crítico, múltiples versiones de una misma obra), historia del documento, y notaciones históricas como notación mensural medieval o notación neumática. Usa el formato ODD (One Document Does-it-all) desarrollado por la Text Encoding Initiative (TEI), lo que permite customizaciones del esquema para repertorios específicos.
MEI tiene módulos para distintos tipos de notación: mei-cmn para Common Music Notation (notación tonal occidental moderna), mei-mensural para notación mensural, mei-neumes para neumas. Cada módulo valida con su propio esquema RelaxNG.
Su adopción es fundamentalmente académica: ediciones digitales críticas, proyectos de humanidades digitales, bibliotecas de investigación. No está integrado en el flujo de trabajo del músico práctico cotidiano.
Software relacionado: Verovio (renderización y conversión), meico (conversión), Oxygen XML Editor (edición), VHV (Verovio Humdrum Viewer).
ABC Notation
Tipo: Semántico-notacional
Extensión: .abc
Web oficial: abcnotation.com
Mantenedor: Chris Walshaw (University of Greenwich, Londres); estándar 2.1 mantenido comunitariamente
ABC Notation fue creado por Chris Walshaw a principios de los años 90 como sistema para anotar melodías folk usando solo caracteres ASCII, legibles tanto por personas como por ordenadores. El nombre de las notas se representa con letras (a–g, A–G), las duraciones con números, y la información de clave, compás y tonalidad en cabeceras de texto simples. La versión actual del estándar es ABC 2.1, publicada en diciembre de 2011 (Walshaw, 2011).
Originalmente diseñado para música monofónica folk de Europa occidental (irlandesa, escocesa, inglesa), el estándar ha sido extendido para soportar polifonía, acordes y otras características, aunque sus limitaciones en notación compleja son reconocidas por sus propios desarrolladores.
Su fortaleza principal es la simplicidad y la legibilidad humana: un músico con algo de práctica puede leer y tocar directamente desde el código ABC sin necesidad de renderizarlo. También es el formato más extendido en internet para música folk tradicional: existen cientos de miles de melodías en repositorios como The Session (thesession.org) o el ABC Music Project.
Software relacionado: abcmidi, EasyABC, BarFly, abc2xml, y la mayoría de conversores pasan por abcmidi para MIDI y abc2ly para LilyPond.
LilyPond
Tipo: Semántico-notacional
Extensión: .ly
Web oficial: lilypond.org
Mantenedor: Comunidad de voluntarios del Proyecto GNU; código en GNU Savannah y GitHub
LilyPond es un programa de grabado musical (engraving) de código libre, parte del Proyecto GNU, con historial de commits desde 1996. Su filosofía es análoga a la de LaTeX para la tipografía: el usuario escribe un archivo de texto con código LilyPond y el programa compila una partitura de alta calidad tipográfica, basada en los principios estéticos del grabado musical tradicional a mano.
El lenguaje LilyPond es un lenguaje de dominio específico con una sintaxis propia, construido sobre el lenguaje de programación Scheme (GNU Guile). Esto significa que un archivo .ly puede contener no solo información musical sino también lógica programática: variables, funciones, bucles, condicionales. La separación entre contenido musical y presentación es completa, lo que permite un control muy fino sobre cada aspecto del grabado.
Produce salida en PDF (a través de PostScript), SVG, PNG y MIDI. Su calidad tipográfica es considerada por muchos la más alta entre el software de notación, comparable al grabado manual profesional. Es usado extensamente por la comunidad académica y en el proyecto Mutopia (partituras de dominio público en LilyPond).
Su principal limitación para el usuario no técnico es la ausencia de interfaz gráfica WYSIWYG. El editor recomendado es Frescobaldi, que ofrece previsualización en tiempo real del PDF compilado.
Software relacionado: Frescobaldi (editor con previsualización), Denemo (interfaz gráfica que exporta a LilyPond), HackLily (editor online).
Humdrum / **kern
Tipo: Semántico-notacional
Extensión: .krn (para **kern); el sistema Humdrum acepta muchas otras extensiones de datos
Web oficial: humdrum.org / kern.humdrum.org (KernScores)
Mantenedor: Desarrollado originalmente por David Huron (Ohio State University) desde 1986; mantenido actualmente por Craig Sapp (Stanford) y colaboradores
Humdrum es un sistema de análisis musical computacional diseñado por David Huron en los años 80 para facilitar la investigación musicológica empírica (Huron, 1999). No es un formato único sino un ecosistema: un conjunto de más de 70 herramientas de línea de comandos que operan sobre archivos de texto estructurados según la sintaxis Humdrum.
La sintaxis Humdrum organiza los datos en columnas llamadas «spines», cada una representando un tipo de información. El intérprete más usado es **kern, que codifica notación musical en texto ASCII legible: las notas se representan por nombre, la duración por números (4 = negra, 8 = corchea), los compases por el símbolo =. Con algo de práctica, según el propio Huron, se puede leer a primera vista un coral a cuatro voces en código kern.
Su adopción es prácticamente exclusiva del ámbito de la musicología computacional académica. KernScores alberga más de 100.000 archivos **kern, incluyendo grandes corpus de Bach, Beethoven, Mozart y otros compositores del período de práctica común. Es el formato de corpus estándar en estudios como el análisis de la armonía tonal, la contrapuntística o la predicción melódica.
Herramientas del ecosistema: Humdrum Toolkit (original), Humdrum Extras (Craig Sapp), humlib (C++), VHV / Verovio Humdrum Viewer (edición y visualización online), humdrumR (extensión para R).
MuseData
Tipo: Semántico-notacional
Extensión: variable (.md o sin extensión estándar)
Web oficial: musedata.org (Center for Computer Assisted Research in the Humanities, Stanford)
Mantenedor: CCARH (Center for Computer Assisted Research in the Humanities), Stanford University; Walter B. Hewlett como creador
MuseData es uno de los formatos más antiguos de codificación musical digital, desarrollado por Walter B. Hewlett en el CCARH de Stanford desde 1983. Fue uno de los primeros intentos sistemáticos de representar música de partitura de forma que fuera útil tanto para análisis computacional como para generación de audio MIDI y producción de partituras impresas.
Internamente es texto ASCII, organizado por compases y voces. Cada evento musical (nota, silencio, indicación dinámica) ocupa una línea con campos de anchura fija. Almacena alturas con grafía notacional (no solo número de pitch), duraciones métricas, articulaciones y algunos datos de performance.
MuseData ha sido eclipsado en gran medida por MusicXML como estándar de intercambio, pero sigue siendo relevante por su corpus: el CCARH mantiene codificadas en MuseData obras de Bach, Handel, Vivaldi, Mozart, Beethoven y otros compositores del período de práctica común, muchas de las cuales están disponibles también en Humdrum y MusicXML. Es un formato casi exclusivamente de consulta e investigación, rara vez utilizado como destino de nuevas codificaciones.
Software relacionado: Humdrum incluye herramientas para procesar MuseData; el propio CCARH proporciona conversores a MIDI y MusicXML.
Partitura manuscrita
Tipo: Semántico-notacional (con propiedades autográficas únicas)
Soporte: Físico (papel, pergamino, otros materiales)
Repositorios digitales: IMSLP, Petrucci Music Library, colecciones de bibliotecas nacionales (BnF Gallica, British Library Digital Collections, etc.)
La partitura manuscrita ocupa una posición singular en esta taxonomía, en el límite entre lo semántico y lo autográfico. A diferencia de todos los demás formatos de esta categoría, es un objeto físico único cuya identidad está vinculada a su historia de producción en el sentido pleno de Goodman (1968): no puede haber dos instancias idénticas de un manuscrito.
El trazo manual contiene información que no tiene equivalente en ningún formato digital:
- Gestualidad del trazo: la presión del lápiz o la pluma, la velocidad del gesto, la inclinación de plicas y barras.
- Correcciones y tachones: rastros del proceso compositivo, visibles como estratos superpuestos.
- Distribución espacial no ortogonal: a diferencia de la partitura informática, donde los elementos se alinean con precisión geométrica, en el manuscrito la posición relativa de las notas, la densidad del pentagrama o el tamaño de los compases puede transmitir información interpretativa implícita.
- Unicidad material: manchas, desgastes, anotaciones posteriores, sellos y marcas de propiedad.
Esta información puede funcionar como orientación interpretativa para el intérprete, de forma análoga (pero inversa) a como la ortogonalidad perfecta de la partitura informática transmite una intención de exactitud métrica. En el manuscrito, la grafía orgánica puede sugerir respiraciones, agrupaciones, intensidades y tempos que ningún formato digital captura.
La digitalización (fotografía, escaneado) genera un PDF o imagen que es técnicamente un Renderizado visual (subcategoría 2.3).
MIDI (Musical Instrument Digital Interface)
Tipo: Performativo
Extensión: .mid / .midi
Web oficial: midi.org (MIDI Manufacturers Association)
Mantenedor: MIDI Manufacturers Association (MMA) y AMEI (Japan)
MIDI es un protocolo de comunicación entre instrumentos electrónicos, desarrollado en 1983 por una coalición de fabricantes de sintetizadores (Roland, Sequential Circuits, Korg, Yamaha, entre otros). La especificación Standard MIDI File (SMF) define el formato de archivo .mid, que registra eventos MIDI con marcas temporales.
Un archivo MIDI almacena eventos de performance: qué nota sonar (número de pitch 0–127), con qué intensidad (velocity 0–127), en qué canal (0–15) y cuándo (en ticks de reloj). No almacena grafía notacional: no distingue entre Fa# y Solb (son el mismo número de pitch), no sabe si una nota está ligada a la siguiente en la partitura o separada, no tiene compases en sentido notacional (aunque puede tener marcas de compás), no distingue voces dentro de un mismo instrumento con la misma precisión que una partitura.
Su posición en la taxonomía es fronteriza: tiene más estructura semántica que el audio (cada nota es un evento discreto con parámetros definidos) pero menos semántica notacional que MusicXML o Humdrum. Desde la perspectiva de Goodman, el MIDI tiende hacia lo autográfico cuando es interpretado por un ordenador: el resultado sonoro es determinista, salvo variaciones introducidas por la librería de síntesis.
A pesar de sus limitaciones notacionales, MIDI es el formato de intercambio más extendido en el mundo de la producción musical y los instrumentos electrónicos. Su universalidad práctica es incomparable.
Software relacionado: prácticamente cualquier DAW (Ableton, Logic, Pro Tools, Cubase), secuenciadores, y la mayoría del software de notación.
Piano roll físico
Tipo: Performativo
Soporte: Rollo de papel perforado
Principales sistemas: Welte-Mignon (1904), Ampico (1913), Duo-Art / Aeolian (1914), rollo básico de 65 notas (ca. 1900)
El piano roll físico (también llamado rollo de pianola) es un medio analógico de codificación de ejecución musical mediante perforaciones en papel. Fue el sistema dominante de reproducción musical doméstica entre aproximadamente 1900 y 1930, con decenas de millones de rollos producidos.
Hay diferencias significativas entre sistemas:
- Rollo básico de 65 notas: sin control expresivo. Las perforaciones codifican únicamente qué notas suenan. El tempo y el volumen son controlados manualmente por el oyente. Análogo a un archivo MIDI sin velocity.
- Welte-Mignon (1904): primer sistema con control expresivo codificado. Perforaciones adicionales en los márgenes controlan crescendos, diminuendos y pedal. Permite reproducir ejecuciones de pianistas reales (el sistema registraba interpretaciones de Grieg, Debussy, Mahler, entre otros).
- Duo-Art (Aeolian, 1914) y Ampico (1913): sistemas propietarios competidores, con sus propios esquemas de codificación de la expresión dinámica.
La relación entre el piano roll expresivo y el MIDI es de ancestro directo: ambos codifican una ejecución más que una partitura, ambos tienen resolución temporal discreta y ambos pierden información de grafía notacional. La diferencia es el soporte (analógico vs. digital) y la resolución expresiva (el Welte-Mignon captura matices que el MIDI de 128 niveles de velocity no siempre reproduce fielmente).
Proyectos de preservación como el de Stanford University Libraries y el CHARM (Centre for the History and Analysis of Recorded Music) han trabajado en la digitalización y conversión de rollos físicos a MIDI, enfrentando el problema de la traducción entre el sistema de codificación propietario de cada fabricante y los estándares digitales actuales.
PDF (desde software de notación)
Tipo: Renderizado visual
Extensión: .pdf
Formato: Vectorial (Portable Document Format, ISO 32000)
Un PDF generado directamente desde software de notación (MuseScore, Finale, Sibelius, LilyPond) es un archivo vectorial: los elementos gráficos (líneas de pentagrama, cabezas de nota, plicas, texto) están definidos como objetos matemáticos que pueden escalarse a cualquier tamaño sin pérdida de calidad. PDF es un estándar abierto mantenido por ISO (desde PDF 1.7 en adelante).
Aunque visualmente reproduce la partitura con alta fidelidad, un PDF de notación no contiene información musical semántica directamente accesible: no hay una estructura de datos que diga «aquí hay una nota Do4 de duración de negra». Toda la información está codificada en la posición y forma de los elementos gráficos. La recuperación de información musical requiere OMR.
La calidad vectorial hace que este tipo de PDF sea el mejor punto de partida para OMR entre todos los formatos de renderizado visual: los contornos son matemáticamente perfectos y no hay ruido por digitalización.
Software que lo genera: cualquier software de notación musical con exportación a PDF.
PDF (escaneado / imagen)
Tipo: Renderizado visual
Extensión: .pdf
Formato: Raster (imagen de mapa de bits dentro de un contenedor PDF)
Un PDF generado a partir del escaneado de una partitura impresa o manuscrita es técnicamente distinto del PDF vectorial anterior, aunque comparten extensión. Internamente contiene imágenes raster (JPEG, TIFF o PNG embebidos) de las páginas escaneadas. La calidad para OMR depende de la resolución del escaneado (300 dpi como mínimo recomendado para OMR), la limpieza del original y la calidad de la impresión o escritura.
Las principales fuentes de degradación para el OMR son: papel amarillento, tinta corrida o desgastada, manchas, subrayados o anotaciones añadidas, encuadernación que impide el escaneo plano, y la propia variabilidad tipográfica entre editoriales y épocas.
PNG / JPG de partitura
Tipo: Renderizado visual
Extensión: .png / .jpg / .jpeg
Son imágenes raster de partitura, funcionalmente equivalentes al PDF escaneado en cuanto a su tratamiento por OMR. PNG usa compresión sin pérdida (adecuado para partitura, donde los contornos duros se preservan mejor) mientras que JPEG usa compresión con pérdida (introduce artefactos en los bordes que pueden dificultar el reconocimiento de símbolos). Para uso en OMR, PNG es preferible a JPEG.
Pueden generarse tanto por escaneado de partituras impresas como por exportación directa desde software de notación (MuseScore, LilyPond y otros permiten exportar a PNG con resolución configurable).
Braille musical
Tipo: Renderizado visual (con propiedades semánticas propias)
Soporte: Papel braille embosado, pantalla braille electrónica, archivo BRF
Estándar de referencia: New International Manual of Braille Music Notation (ICEVI, 1996)
El Braille musical es una notación táctil para personas con discapacidad visual, basada en el sistema braille de 6 puntos de Louis Braille pero con signos específicos para representar notas, ritmos, articulaciones y otros elementos musicales. El estándar internacional es el New International Manual of Braille Music Notation (ICEVI, 1996), aunque existen variantes nacionales (código braille anglosajón, francés, alemán, etc.) con diferencias en algunos signos.
Su posición en la taxonomía es peculiar: aunque se incluye en la subcategoría de renderizado visual (es una representación de la partitura para un medio de acceso alternativo), tiene propiedades semánticas propias que lo distinguen de una imagen de partitura. El braille musical tiene su propio sistema de abreviaciones, contracciones y signos de repetición que no tienen equivalente directo en la notación visual: puede comprimir información de forma que no es posible en una partitura convencional. En ese sentido, es el único formato de este grupo que tiene su propio modelo semántico.
La conversión MusicXML → Braille está razonablemente madura: herramientas como Sao Mai Braille (SMB, desarrollado por el Sao Mai Center for the Blind de Vietnam con apoyo del proyecto DAISY Music Braille) y MakeBraille (Centro Alemán de Lectura Accesible) realizan esta conversión con alta calidad y son de uso extendido en la comunidad de personas con discapacidad visual.
La conversión Braille → MusicXML (la dirección inversa) es el problema abierto: el proyecto Braille Music Compiler (BMC) de Mario Lang es el intento más prometedor de abordarla sistemáticamente, pero sigue en desarrollo. Una dificultad estructural es que el braille permite formas de repetición y contracción que no tienen equivalente en la notación visual, y «desplegar» esas contracciones para exportar a otros formatos requiere un análisis sintáctico complejo.
Software relacionado: Sao Mai Braille (SMB, Windows + online), MakeBraille (online), FreeDots (Java, open source), BrailleMUSE (servidor online de Yokohama National University), Goodfeel (comercial, Windows).
MP3, WAV, FLAC y otros formatos de audio
Tipo: Renderizado sonoro
Extensiones: .mp3, .wav, .flac, .ogg, .aiff, entre otros
Los formatos de audio son la representación más alejada del texto simbólico musical. Son señales acústicas digitalizadas: muestras de amplitud de onda a una determinada frecuencia de muestreo (44.100 Hz es el estándar para calidad CD; 48.000 Hz para audio profesional; resoluciones más altas como 96.000 Hz en audio de alta definición).
Las diferencias entre formatos son principalmente de compresión:
- WAV (Microsoft/IBM): sin compresión. Archivo grande, calidad máxima. Estándar para producción y masterización.
- FLAC (Free Lossless Audio Codec): compresión sin pérdida. Tamaño aproximadamente la mitad de WAV, misma calidad. Open source.
- MP3 (MPEG-1 Audio Layer III): compresión con pérdida. Descarta información que el oído humano supuestamente no percibe (psicoacústica). Tamaños muy reducidos (factor 10 respecto a WAV) con calidad subjetivamente aceptable.
- OGG Vorbis: alternativa open source al MP3, con patentes libres.
- AIFF (Apple): similar a WAV, común en ecosistemas Apple.
Para la recuperación de información musical mediante AMT, la calidad del audio de partida es importante: WAV y FLAC son preferibles, y la compresión con pérdida de MP3 puede afectar frecuencias relevantes para el análisis. Sin embargo, el estado del arte de la AMT sigue siendo un problema no resuelto para música polifónica compleja, independientemente de la calidad del audio de entrada.
Principio organizador: niveles de abstracción y pérdida
| Nivel | Subcategoría | Abstracción | Pérdida acumulada |
|---|---|---|---|
| 1 | Semántico-notacional | Máxima (texto simbólico) | Mínima — pérdida solo entre modelos semánticos distintos |
| 2 | Performativo | Media (ejecución codificada) | Semántica notacional: enarmónicos, articulaciones, voz |
| 3 | Renderizado visual | Baja (imagen de la partitura) | Toda la semántica. Solo queda la apariencia gráfica |
| 4 | Renderizado sonoro | Mínima (señal acústica) | Toda la semántica y la estructura visual |
MusicXML actúa como hub central de interoperabilidad: la mayoría de rutas de conversión entre formatos de distintas subcategorías pasan por él como nodo intermedio. Las conversiones dentro del grupo semántico-notacional son las más fiables; las conversiones que cruzan entre grupos implican siempre pérdidas irreversibles.
Conclusión
La taxonomía propuesta no pretende ser exhaustiva sino operativa: un instrumento para orientarse en un ecosistema de formatos heterogéneo y, con frecuencia, mal documentado fuera de sus comunidades de uso específicas. Las cuatro subcategorías —semántico-notacional, performativo, renderizado visual, renderizado sonoro— no son compartimentos estancos sino posiciones en el continuo prescriptivo/descriptivo que Seeger formuló y que los marcos de Goodman, Nattiez, Cook y Nettl contribuyen a matizar: a medida que descendemos por los niveles, la distancia al símbolo crece, la información implícita se acumula y la tecnología de recuperación se vuelve más costosa y menos fiable.
Este trabajo es el primero de una serie. Antes de poder trabajar con inteligencia artificial en la creación y comprensión de notación musical, es necesario saber exactamente con qué objetos se trabaja: qué codifica cada formato, qué pierde y dónde se sitúa en el continuo prescriptivo/descriptivo. Esa distinción tiene además una consecuencia práctica inmediata: algunos formatos —principalmente los basados en texto o código— son directamente legibles por un modelo de lenguaje; otros requieren conversión previa antes de ser interpretables, ya sea por humanos o por la propia IA. Ese mapa es lo que este post ha intentado trazar para los formatos de carácter prescriptivo.
El siguiente paso será cartografiar los caminos de conversión entre ellos: qué rutas son directas, cuáles requieren formato pivote, dónde se producen las pérdidas más significativas y qué herramientas existen hoy para recorrerlas. Comprender esa red de tránsitos es la condición previa para que la IA pueda moverse por ella con criterio —ya sea generando, analizando o transformando notación musical— sin ignorar lo que se pierde en cada travesía.
Si esta entrada te ha parecido interesante:
Bibliografía
Center for Computer Assisted Research in the Humanities. (n.d.). MuseData. Stanford University. https://musedata.org
Cook, N. (1987). A guide to musical analysis. Norton.
Goodman, N. (1968). Languages of art: An approach to a theory of symbols. Bobbs-Merrill.
Huron, D. (1999). Music research using Humdrum: A user’s guide. Center for Computer Assisted Research in the Humanities.
IMSLP/Petrucci Music Library. (2006). IMSLP: International Music Score Library Project. https://imslp.org
International Council for Education of People with Visual Impairment. (1996). New international manual of Braille music notation. ICEVI.
Lang, M. (n.d.). Braille Music Compiler (BMC) [Software]. https://bmc.braillemusic.org
MIDI Manufacturers Association. (1983). MIDI 1.0 detailed specification. MIDI Manufacturers Association. https://midi.org
MuseScore BVBA. (2002). MuseScore [Software]. https://musescore.org
Music Encoding Initiative. (2023). MEI guidelines (Version 5.0). Music Encoding Initiative. https://music-encoding.org
Mutopia Project. (2000). The Mutopia Project. https://www.mutopiaproject.org
Nattiez, J.-J. (1990). Music and discourse: Toward a semiology of music (C. Abbate, Trans.). Princeton University Press.
Nettl, B. (1983). The study of ethnomusicology: Twenty-nine issues and concepts. University of Illinois Press.
RISM Digital Center. (2014). Verovio music notation engraving library [Software]. https://www.verovio.org
Sao Mai Center for the Blind. (n.d.). Sao Mai Braille (SMB) [Software]. https://saomaicenter.org
Sapp, C. (n.d.). Verovio Humdrum Viewer (VHV) [Software]. Stanford University. https://verovio.humdrum.org
Seeger, C. (1958). Prescriptive and descriptive music writing. The Musical Quarterly, 44(2), 184–195. https://doi.org/10.1093/mq/XLIV.2.184
The Session. (n.d.). The Session: Traditional Irish music community. https://thesession.org
W3C Music Notation Community Group. (2021). MusicXML version 4.0. World Wide Web Consortium. https://www.w3.org/2021/06/musicxml40/
Walshaw, C. (2011). ABC music standard 2.1. abcnotation.com. https://abcnotation.com/wiki/abc:standard:v2.1
Deja un comentario