Mordant d-Moll

Lo que escuchas es la grabación en vivo del organista Dr. James Kibbie. Entre el momento en que presiona una tecla y el archivo que tienes delante intervienen decenas de variables físicas: la acústica de la sala (reverberación, reflexiones, absorción), el tipo y la posición de los micrófonos, la cadena de preamplificadores y conversores analógico-digitales, la afinación del instrumento, la temperatura del ambiente que afecta a la velocidad del sonido, y por supuesto las decisiones interpretativas del músico —tempo, dinámica, articulación.

El resultado de toda esa cadena física se almacena como un archivo WAV (Waveform Audio File Format): una secuencia de números enteros que representan la presión del aire en instantes sucesivos. Este archivo usa 44.100 Hz de frecuencia de muestreo —es decir, se toma una «fotografía» de la onda sonora 44.100 veces por segundo, suficiente para capturar frecuencias de hasta 22.050 Hz, por encima del límite de audición humana (≈ 20.000 Hz)— y una profundidad de 16 bits, lo que significa que cada muestra es un número entero entre −32.768 y 32.767: 65.536 niveles posibles de amplitud.

Con dos canales estéreo y 2,09 segundos de grabación, este archivo contiene exactamente 184.320 valores numéricos (92.160 muestras × 2 canales). Eso es todo lo que hay: una lista de números. El sonido emerge cuando un altavoz convierte esa lista en vibraciones de aire.

La forma de onda es la representación visual directa de los 184.320 valores numéricos del archivo de audio. Cada punto en el eje horizontal corresponde a un instante de muestreo (1⁄44.100 de segundo) y su posición vertical indica la amplitud de esa muestra: qué tan comprimido o rarificado estaba el aire en ese instante, normalizado entre −1 y +1 (equivalente a valores PCM entre −32.767 y +32.767).

A vista general reconoces la estructura: el ataque de la nota, su sustain y el silencio que sigue. Al hacer zoom, las curvas aparentemente lisas se revelan como una secuencia discreta de puntos unidos por líneas rectas —no existe información entre ellos. Con el máximo nivel de zoom puedes ver cada muestra individual como un punto aislado: un único número capturado en 1⁄44.100 de segundo.

Al pasar el cursor sobre el gráfico, la barra inferior muestra tres valores: t es el tiempo en segundos desde el inicio del archivo; amp es la amplitud normalizada (−1 a +1, siendo 0 silencio absoluto); y PCM es el entero almacenado en el archivo WAV de 16 bits (de −32.767 a +32.767). Los botones Y+ / Y− amplían o reducen la escala vertical para revelar variaciones de amplitud muy pequeñas que serían invisibles a escala completa.

La forma de onda informa sobre dinámica, envolvente y silencios. No contiene información directa sobre altura ni timbre: una flauta y un órgano tocando el mismo La a igual volumen producirían amplitudes similares pero morfologías completamente distintas —sin análisis frecuencial no podrías distinguirlos. Para eso está el espectrograma (sección 03).

La forma de onda te dice cuánto sonido hay en cada instante, pero no qué nota suena. El espectrograma resuelve eso añadiendo una tercera dimensión: la frecuencia. El eje horizontal es el tiempo; el eje vertical son las frecuencias en Hz (de 0 arriba de los 20.000 Hz); y el color indica la energía de cada frecuencia en cada instante, expresada en decibelios (dB). La escala de color va del negro (silencio) al blanco intenso (máxima energía), pasando por morado y naranja —un «termómetro espectral».

Para construirlo se utiliza la Transformada de Fourier de Tiempo Corto (STFT). El algoritmo recorre la señal completa dividiéndola en ventanas solapadas de 2.048 muestras (≈ 46,4 ms a 44.100 Hz). A cada ventana se le aplica una función de Hann —una curva suave que pondera las muestras centrales más que los extremos— para evitar la fuga espectral: el artefacto que aparecería si cortáramos la señal bruscamente. Después se calcula la FFT (Fast Fourier Transform) de esa ventana, obteniendo 1.024 «cubetas» de frecuencia de 21,5 Hz de anchura cada una (44.100 / 2.048). Con un salto de 512 muestras entre ventanas —solapamiento del 75 %— se obtiene un fotograma espectral cada 11,6 ms, lo que produce 177 fotogramas en total para los 2,09 segundos de audio.

Existe un límite físico insuperable: el principio de incertidumbre tiempo-frecuencia, análogo al de Heisenberg en mecánica cuántica. Ventanas más grandes ofrecen mejor resolución en frecuencia (cubetas más estrechas) pero peor localización temporal; ventanas más pequeñas permiten detectar eventos rápidos pero no distinguir frecuencias cercanas. Con los 2.048 puntos elegidos aquí se puede distinguir frecuencias separadas ≥ 21,5 Hz, pero los eventos temporales solo se localizan con una precisión de ≈ 46 ms. No hay forma de mejorar ambas simultáneamente.

En el espectrograma puedes identificar la estructura armónica del órgano. La nota es La5 (A5), con frecuencia fundamental de 880 Hz —la banda horizontal más brillante en la parte baja del gráfico. Por encima aparecen sus armónicos naturales: 1.760 Hz (2.º), 2.640 Hz (3.º), 3.520 Hz (4.º), 4.400 Hz (5.º)... El órgano de tubos tiene un perfil armónico especialmente rico: los parciales superiores aportan el brillo y la penetración características del instrumento. Las bandas son perfectamente horizontales porque la nota se mantiene sostenida a frecuencia constante —ninguna modulación ni vibrato.

Los controles permiten explorar el espectrograma en detalle. Los botones −/+, la barra deslizante y la rueda del ratón amplían o reducen el eje temporal; arrastrar desplaza la ventana de tiempo. Los botones F+ / F− amplían o reducen el rango de frecuencias visible (eje vertical), útil para examinar de cerca la zona de los armónicos. Al pasar el cursor sobre el gráfico, la barra inferior muestra el tiempo exacto en segundos, la frecuencia en Hz del punto señalado y su energía en dB.

Lo que ves no es el autógrafo de Bach —que no se conserva— sino la fuente más antigua conocida de la obra: una copia manuscrita realizada por Johannes Ringk (1717–1778), organista y alumno de Johann Peter Kellner (copista habitual de Bach). Ringk transcribió la pieza entre 1740 y 1760, dos a cinco décadas después de su composición. El título que escribió fue: «Toccata Con Fuga: pedaliter. ex. d. #. di J. S: Bach: Scrips: Johannes Ringk» —confirmando autoría, tonalidad (re menor) y que la obra es «pedaliter», para órgano con pedal obligado.

El manuscrito forma parte del colectáneo D-B Mus.ms. Bach P 595 (fascículo 8, páginas 57–64), conservado en la Staatsbibliothek zu Berlin – Preußischer Kulturbesitz. Su proveniencia está documentada con precisión: Ringk → Eduard Grell (director de la Sing-Akademie zu Berlin, 1800–1886) → el librero Leo Liepmannssohn (1840–1915) → la Staatsbibliothek de Berlín, donde ingresó en 1887. El papel presenta sangrado de tinta y foxing propios del tiempo.

En la imagen se ve el primer sistema de la Toccata: el gran mordente inicial que da comienzo a la obra. La zona que aparece con mayor luminosidad (transparencia blanca) ya corresponde a las notas que van más allá de los 2 segundos de referencia que cubre este proyecto —el mordente que escuchas en la sección 01 ocupa únicamente los compases iniciales, hasta donde la imagen permanece más oscura. La notación manuscrita no es solo información musical: el tamaño de los trazos, el ángulo de la pluma, las ligaduras dibujadas a mano transmiten indicaciones que ninguna tipografía reproducirá de la misma manera. Curiosamente, aunque escuchamos tres notas, en la partitura solo aparece una nota escrita: el símbolo del adorno (Mordant) condensa toda la ornamentación en un único glifo gráfico sobre la cabeza de la nota, siguiendo la convención barroca de notación de ornamentos.

Un PDF escaneado es esencialmente una imagen ráster encapsulada en un contenedor PDF. A diferencia de un PDF nativo generado por software de notación, no contiene primitivas gráficas vectoriales ni texto real: almacena uno o varios objetos de imagen comprimidos (JBIG2, CCITT Group 4 o JPEG) junto con los metadatos mínimos de página. La «inteligencia» musical —alturas, ritmos, dinámica, articulaciones— no existe como dato estructurado; está implícita en los píxeles y solo puede extraerse mediante OCR musical (Optical Music Recognition, OMR).

El proceso de digitalización convierte la reflectancia lumínica del papel en una rejilla de valores discretos mediante una matriz de fotodiodos. La resolución se mide en ppp (puntos por pulgada, DPI): las guías archivísticas recomiendan 300–600 ppp en escala de grises o bitonal (1 bit por píxel) para partituras. La compresión JBIG2 (o CCITT Group 4, el algoritmo fax de alta resolución) alcanza ratios de 10:1 a 50:1 sin pérdida perceptible en imágenes binarias. Pese a ello, el archivo resultante es entre 5 y 50 veces mayor que un PDF vectorial equivalente.

El escaneo introduce distorsiones sistemáticas: sesgo (skew) si la página no quedó alineada con el cristal; gradientes de iluminación que producen fondos no uniformes; ruido de grano del papel amplificado en zonas claras; halo de umbralización en trazos finos. Estos artefactos deben corregirse antes del OMR mediante enderezado (deskewing), binarización adaptativa y filtrado morfológico. Las ediciones antiguas en tipografía móvil presentan además rastros de entintado irregular que complican el reconocimiento automático.

La zona que aparece con transparencia blanca corresponde al contenido musical que supera los 2 segundos de referencia. Solo el inicio —el Mordant (mordente) sobre el La, marcado Adagio— queda dentro del fragmento analizado en las demás representaciones. Todo lo que aparece más claro ya está fuera de ese intervalo.

La imagen funciona en tres niveles de zoom. La vista completa muestra el primer sistema con la transparencia de referencia. El primer clic amplía la zona del mordente: se aprecia el Mordant grabado, la plica de la nota y el ligado. El segundo clic llega al nivel de píxel individual del escáner: los contornos de las figuras se revelan como escaleras de cuadrados discretos, la naturaleza ráster que distingue este formato de las representaciones vectoriales o simbólicas. Un tercer clic devuelve a la vista completa.

Un PDF vectorial generado por software de notación no almacena píxeles sino instrucciones geométricas: cada elemento de la partitura —líneas de pentagrama, cabezas de nota, plicas, ligaduras, dinámica— se describe mediante curvas de Bézier, segmentos y formas rellenas en el lenguaje PostScript subyacente al PDF. El visor reconstruye la imagen en el momento de la visualización o impresión a la resolución exacta del dispositivo, sin pérdida de calidad independientemente del factor de escala.

La diferencia con el escaneado es estructural. En el PDF ráster (sección 05), la línea de un pentagrama es una cadena de píxeles negros. En el PDF vectorial, esa misma línea es el comando l x1 y1 x2 y2 w —posición inicial, posición final y anchura de trazo— que el intérprete convierte en la línea perfecta que el dispositivo de salida sea capaz de reproducir. A 600 ppp ocupa exactamente 600 puntos por pulgada; a 2.400 ppp ocupa 2.400. El fichero es idéntico en ambos casos; solo cambia el renderizador.

Los glifos musicales especiales —claves, corchetes, cabezas de nota, adornos— se almacenan como fuentes tipográficas embebidas o como trazados vectoriales directos. LilyPond embebe su fuente nativa Feta —diseñada exclusivamente para notación musical— junto con LilyPond Serif para el texto; el visor PDF las usa igual que haría con Arial o Times New Roman. Esto explica por qué el fichero vectorial (42 KB) es siete veces más pequeño que el escaneado (295 KB) a pesar de contener exactamente la misma información visual: la geometría comprimida ocupa infinitamente menos espacio que la rejilla de píxeles correspondiente.

Una diferencia notable respecto al escaneado: aquí no hay artefactos ni ruido de digitalización. La partitura es exactamente lo que LilyPond generó, sin degradación alguna. El fragmento de análisis —el Mordant sobre el La, marcado Adagio— se corresponde con las primeras notas visibles en la esquina superior izquierda.

La imagen funciona en tres niveles de zoom. La vista completa muestra el primer sistema con la transparencia de referencia. El primer clic amplía la zona del mordente vectorial: se aprecian el Mordant, la calderón y la ligadura con contornos perfectamente nítidos. El segundo clic llega al nivel de máximo detalle —contrasta directamente con los píxeles escalonados del escaneado (sección 05): los bordes del glifo son curvas matemáticas, sin escalera ni ruido. Un tercer clic devuelve a la vista completa.

Este PNG fue exportado por LilyPond 2.24.4, que rasteriza su representación vectorial interna a una cuadrícula de píxeles. A diferencia del PDF escaneado —donde la partitura impresa fue fotografiada—, aquí no existe proceso fotográfico: el software convierte cada curva de Bézier, cada glifo Feta y cada línea de pentagrama en una matriz de puntos de color con total precisión matemática.

El formato PNG almacena cada píxel como una tupla de valores (aquí: blanco o negro). La compresión usa DEFLATE —sin pérdida, el mismo algoritmo que ZIP—, lo que permite que las grandes zonas blancas uniformes se codifiquen eficientemente. Así, una partitura de varias páginas en PNG puede ocupar menos espacio que una fotografía de tamaño comparable, sin sacrificar calidad.

La resolución queda grabada en el momento de la exportación. Al ampliar más allá del 100%, los píxeles se hacen visibles y los bordes de plicas, cabezas de nota y líneas de pentagrama aparecen escalonados —efecto denominado aliasing—. El zoom muestra este comportamiento en la zona del Mordant inicial.

PNG es el estándar para partituras raster por una razón técnica concreta: JPEG utiliza compresión con pérdida diseñada para fotografías, que genera blocking artifacts y bordes borrosos en las transiciones abruptas negro-blanco propias de la notación musical. PNG preserva cada borde sin distorsión. La única limitación es la resolución fija: si se necesita escalar sin pérdida, los formatos vectoriales como SVG o PDF son la elección correcta.

Este SVG fue generado por LilyPond 2.24.4, el mismo software que produjo el PDF vectorial y el PNG. A diferencia de esos formatos binarios, el SVG es XML puro: un documento de texto en el que cada línea de pentagrama, cabeza de nota y adorno existe como un elemento etiquetado, inspeccionable y modificable directamente con un editor de texto o con JavaScript.

Cada elemento gráfico —una nota, una plica, el símbolo de dinámica— es conceptualmente una capa independiente. El diagrama interactivo muestra cómo se descompone la nota inicial (La con Mordant). Activa y desactiva cada capa para ver los elementos que la componen, y pasa el cursor sobre los botones para ver el código SVG correspondiente:

En la práctica, LilyPond genera una secuencia plana de <g transform="translate(x,y)"> individuales sin agrupación semántica: una línea de pentagrama y una plica son estructuralmente idénticas en el XML —ambas son <line>— y se distinguen solo por coordenadas. Pero cualquier <g> puede recibir un id o clase y manipularse con CSS o JavaScript: fill, opacity, animaciones, resaltado sincronizado con la reproducción de audio. Esa direccionabilidad es lo que distingue el SVG de cualquier otro formato visual.

Transcripción exacta de lo escrito en la partitura: la nota A5, duración de corchea a 60 BPM. MIDI codifica eventos discretos —note_on, note_off— con su número de nota (0–127), velocidad y posición en ticks. No contiene audio: es una secuencia de instrucciones para un sintetizador.

Un archivo SMF (Standard MIDI File) se compone de bloques llamados chunks. El primero, MThd, es la cabecera de 14 bytes: indica el formato (0 = una pista, 1 = multi-pista sincronizado), el número de pistas y la resolución temporal en ticks por negra. Este archivo usa formato 1 con 384 ticks/negra y cuatro pistas, tal como lo genera LilyPond.

Cada pista comienza con MTrk seguido de su tamaño en bytes. Los eventos van precedidos de un delta time: el tiempo relativo al evento anterior, codificado en Variable Length Quantity (VLQ). En VLQ, el bit 7 de cada byte indica si sigue otro byte; los 7 bits restantes son datos. Un delta de 192 ticks se escribe 0x81 0x40: 192 = 1×128 + 64, cuyo bit de continuación activa el primer byte.

La nota A5 corresponde al número MIDI 81 (0x51). La fórmula es: nº = 12×(octava + 1) + semitono, con La = semitono 9. El silencio llega con note_off —o un segundo note_on con velocidad 0—. La pista de control (track 0) contiene solo metaeventos: título, creador (LilyPond 2.24.4), tempo y compás, sin emitir sonido.

Los cuatro bytes del evento note_on se leen así:

El mismo mordente en tres eventos MIDI escritos a mano: A → G# → A, en ambas manos (A5+A4 simultáneos), forte. A diferencia del MIDI literal —generado mecánicamente desde partitura— este archivo recoge una decisión interpretativa: las duraciones no son iguales y la última nota se alarga para dar peso al regreso. Compárese con el MIDI literal: mismos bytes, distintas proporciones.

MIDI no contiene audio. El archivo es una secuencia de instrucciones —nota tal a tal tiempo con tal intensidad— que un sintetizador ejecuta en tiempo real. Lo que escuchas aquí lo genera el navegador usando una soundfont: una colección de muestras de audio pregrabadas, una por instrumento y dinámica. El archivo MIDI en sí no cambia; cambia quién lo lee.

El mismo archivo puede sonar radicalmente distinto según el reproductor. Una soundfont de órgano de tubos rinde algo cercano a Bach; la soundfont GM estándar que llevan los sistemas operativos suena a teclado de juguete de los años noventa; un sintetizador de hardware Yamaha de los ochenta lo interpreta con sus propias muestras de fábrica. Tres sonidos opuestos, un único archivo de 160 bytes. Esta ambigüedad es a la vez la fortaleza de MIDI (universalidad, ligereza) y su limitación (no define el timbre).

Compáralo con el MIDI literal de la sección anterior: ambos archivos son SMF Type 1, ambos codifican A5 como 51 y usan el status byte 90. La diferencia está en las proporciones —48 / 48 / 160 ticks frente al valor uniforme del literal—, en que aquí la nota de adorno es G# (50, semitono inferior) en lugar del valor literal, y en que cada nota suena en dos octavas a la vez. El formato no distingue entre «literalmente transcrito» e «interpretado»; esa semántica la aporta quien escribe los datos.

Formato nativo de MuseScore 4. Aunque tiene extensión .mscz, internamente es un archivo ZIP que contiene la partitura en XML (.mscx), el estilo visual completo, una miniatura y ajustes de audio. Preserva el estado exacto del documento en MuseScore pero solo ese software lo interpreta íntegramente.

MusicXML comprimido en ZIP, formato de intercambio entre software de notación. El archivo MXL contiene el MusicXML interno más un archivo de manifiesto META-INF/container.xml. Al descomprimirlo se obtiene el mismo contenido que en el .musicxml. Es el formato de distribución recomendado por el consorcio W3C Music Notation.

Estándar de intercambio de partituras basado en XML, con jerarquía <score-partwise> → <part> → <measure> → <note>. La altura de cada nota se codifica en <pitch> mediante tres campos: step (nombre), octave (entero) y alter (semitonos cromáticos). La duración usa dos capas: <duration> cuenta divisiones enteras por negra —definidas en <divisions>— mientras <type> indica la figura gráfica con independencia de la duración real, lo que permite codificar tresillos y notas de adorno sin ambigüedad. Un mismo documento mezcla datos musicales, instrucciones de renderizado y configuración MIDI por instrumento. Desarrollado por Michael Good en Recordare desde 2000; estándar abierto mantenido por el W3C Music Notation Community Group desde 2015.

La separación entre duración semántica y figura gráfica es uno de los mecanismos más importantes del formato. Un tresillo de tres negras en un compás de 4/4 puede tener <duration>2</duration> (dos divisiones) pero <type>quarter</type>: la duración real es ⅔ de negra, pero la tipografía la muestra como negra. El motor sabe que es tresillo porque el elemento <time-modification> declara la proporción 3:2. Separar ambos planos permite que distintos software lean el mismo archivo para fines distintos —renderizado visual, reproducción MIDI, análisis musicológico— sin perder precisión en ninguno.

El documento también incluye bloques de presentación en <defaults> (márgenes, escalado en milímetros por tenth, fuentes tipográficas) y configuración MIDI por instrumento en <score-instrument> / <midi-instrument> (banco, programa GM, volumen). Esta dualidad explica por qué el 63% de las líneas de este archivo no son notas: son metadato, apariencia e instrucción de reproducción que el estándar exige para garantizar interoperabilidad entre editores.

Compilador de tipografía musical: el archivo .ly es procesado por un intérprete Scheme/Guile que convierte la sintaxis declarativa en objetos gráficos (Grobs). En modo \relative, las alturas se expresan como intervalos respecto a la nota anterior: a'' sitúa la nota en la octava 5, donde cada apóstrofe eleva una octava desde la referencia. La figura 8 denota corchea; \mordent y \fermata son articulaciones que el motor posiciona automáticamente. El algoritmo de salto de línea usa programación dinámica para minimizar una función de penalización sobre la tensión horizontal —el mismo principio que TeX para texto—. La salida es PostScript o PDF directo, sin representación gráfica intermedia. Software libre bajo GPL, desarrollado por Han-Wen Nienhuys y Jan Nieuwenhuizen desde 1996.

En este fragmento, \relative establece la altura de referencia para cada voz. La primera voz comienza en a'' (A5, octava 5); la segunda en a' (A4, octava 4). Ambas articulan el mismo gesto: una corchea con Mordant (\mordent, impulso de semitono superior) y calderón (\fermata), seguida de silencio hasta completar el compás. Es el arranque exacto de la Toccata en re menor: una única nota con adorno que resuena suspendida antes del silencio.

LilyPond compila en dos pasadas. En la primera, el intérprete Scheme recorre la música calculando duraciones, proporciones y jerarquías de voces. En la segunda, el motor de espaciado —basado en el algoritmo de Knuth-Plass, el mismo que usa TeX para justificar texto— optimiza el espaciado horizontal globalmente, resolviendo saltos de línea con mínima penalización. El resultado es PostScript puro: sin framework gráfico, sin renderizado en tiempo real. Por eso LilyPond produce sistemáticamente la tipografía de mayor calidad: optimiza el conjunto, no nota a nota.

Notación ASCII lineal donde cada campo del encabezado lleva un identificador de letra seguido de dos puntos: X: (índice), T: (título), M: (compás como fracción), L: (unidad de nota base), Q: (tempo en BPM), K: (tonalidad en notación anglosajona). Las notas se escriben como letras: minúsculas para la octava media (A4–G5), mayúsculas para la inferior (A3–G4); apóstrofes y comas modifican la octava. Las duraciones son multiplicadores de L: una nota sin número vale L, a2 vale 2×L. Las decoraciones como !mordent! y !fermata! preceden inmediatamente a la nota. Voces múltiples se declaran con V: y se activan con [V:Nombre]. Surgió en 1991 (Chris Walshaw) para compartir melodías folk por correo electrónico.

K:Dm establece la armadura implícita de re menor (Fa sostenido). Las directivas %%MIDI program 19 y %%staves son extensiones no-estándar reconocidas por herramientas como abcjs y abcm2ps pero ignoradas por parsers básicos. El silencio z7 es un silencio de 7 unidades: con L:1/8, equivale a 7 corcheas, completando el compás de 4/4 junto a la corchea inicial.

La expresión !mordent!!fermata!a codifica en 18 caracteres lo que MusicXML necesita más de 15 líneas de XML: la altura (La, octava media), dos decoraciones (Mordant + calderón) y la duración implícita (una corchea = L). Esta compacidad es la fortaleza de ABC. La contrapartida: la octava exacta depende del contexto acumulado, las extensiones %% no son universales y el formato carece de representación para posiciones tipográficas precisas.

Music Encoding Initiative: estándar XML académico que extiende la expresividad de MusicXML con capacidades para edición crítica. Cada nota se define con atributos semánticos: pname (nombre de nota), oct (octava en Scientific Pitch Notation), dur (figura: 8=corchea, 4=negra), stem.dir (dirección del plico). Las decoraciones —<mordent>, <fermata>— son elementos independientes que referencian la nota mediante startid="#n1", desacoplando ornamentación y datos musicales. El encabezado <meiHead> admite metadatos académicos: identificadores GND, referencias bibliográficas, declaraciones editoriales y vínculos a fuentes primarias. Mantenido por la MEI Community (music-encoding.org) desde 2010.

La separación entre nota y ornamento es una diferencia filosófica fundamental respecto a MusicXML. En MusicXML, el mordente es hijo de <notations> dentro de <note>, estructuralmente ligado. En MEI, <mordent startid="#n1"/> es un elemento hermano de <note xml:id="n1"/> dentro del compás: ambos son iguales en la jerarquía y se vinculan por referencia. Esto permite añadir, eliminar o editar ornamentos sin modificar los datos de la nota, facilitando el trabajo con variantes de fuentes y aparatos críticos.

El archivo incluye metadatos que ningún otro formato de esta demo puede expresar de forma estándar: el identificador GND del compositor (codedval="11850553X"), la clasificación BWV (identifier type="BWV"), el medio de interpretación (<perfRes>) y la declaración editorial del alcance de la codificación. Estas capacidades hacen de MEI el estándar preferido en proyectos de musicología digital como Bach Digital o el Beethoven Werkzeug.

Formato del Humdrum Toolkit: texto tabular donde cada columna (spine) representa una voz separada por tabuladores y cada fila un instante temporal. El prefijo **kern declara el tipo de representación; otros tipos del toolkit incluyen **harm (armonía), **dynam (dinámica) o **midi. Las notas siguen el patrón [duración][pitch][modificadores]: la duración es un divisor de redonda (8=corchea, 4=negra, 2=mínima); el pitch usa letras repetidas para la octava —a=A4, aa=A5, aaa=A6—; los modificadores son sufijos: ;=calderón, M=mordente, r=silencio. Los metadatos globales usan prefijos !!!: !!!COM (compositor), !!!OTL (título), !!!CDT (fechas). Desarrollado por David Huron (Ohio State University, 1993) para el análisis computacional de música.

La codificación de octavas por repetición de letras es una de las características más distintivas de **kern. La letra a representa A4; duplicarla —aa— sube a A5; triplicarla —aaa— a A6. Las mayúsculas bajan: A=A3, AA=A2. Esto hace la octava directamente legible sin notación adicional, pero produce tokens de longitud variable que dependen del registro. El mismo principio aplica a todas las notas: c=Do4, cc=Do5, C=Do3.

El sistema de spines es la arquitectura fundamental de Humdrum. Las spines se declaran con **tipo y terminan con *-; pueden bifurcarse (*^), fusionarse (*v) o intercambiarse (*x). Los registros de interpretación (líneas con *) modifican el contexto activo: *M4/4 establece el compás, *clefG2 la clave, *k[b-] la armadura. Los registros de medida (=) marcan barras. Esta separación entre datos, interpretaciones locales y metadatos globales hace de Humdrum un sistema analítico —diseñado para ser procesado con herramientas Unix como grep, awk y pipes— más que un formato de intercambio visual.

Formato del Center for Computer Assisted Research in the Humanities (CCARH, Stanford). Uno de los primeros sistemas de codificación musical digital, desarrollado en los años 1980 por Walter Hewlett. Fue la base de las colecciones académicas de Bach, Beethoven, Vivaldi y Mozart digitalizadas por el CCARH. Precursor directo de MusicXML.

Sistema de notación táctil para músicos con discapacidad visual. Desarrollado por Louis Braille en 1829, solo tres años después de su sistema de escritura general. Cada célula de 6 puntos codifica simultáneamente la altura y la duración de una nota. No es una transliteración del pentagrama: tiene su propia gramática musical independiente.