Mordant d-Moll

Lo que escuchas es la primera nota de la Toccata y Fuga en Re menor de Bach (BWV 565), en 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.

What you hear is the opening note of Bach's Toccata and Fugue in D minor (BWV 565), from the live recording by organist Dr. James Kibbie. Between the moment a key is pressed and the file before you, dozens of physical variables intervene: the room's acoustics (reverberation, reflections, absorption), the type and position of microphones, the chain of preamplifiers and analog-to-digital converters, the instrument's tuning, the ambient temperature affecting the speed of sound, and the performer's interpretive decisions—tempo, dynamics, articulation.

The result of that entire physical chain is stored as a WAV file (Waveform Audio File Format): a sequence of integers representing air pressure at successive instants. This file uses a 44,100 Hz sample rate—a "snapshot" of the sound wave taken 44,100 times per second, sufficient to capture frequencies up to 22,050 Hz, above the human hearing limit (≈ 20,000 Hz)—and a 16-bit depth, meaning each sample is an integer between −32,768 and 32,767: 65,536 possible amplitude levels.

With two stereo channels and 2.09 seconds of recording, this file contains exactly 184,320 numeric values (92,160 samples × 2 channels). That is all there is: a list of numbers. Sound emerges when a speaker converts that list into air vibrations.

FLAC (Free Lossless Audio Codec) comprime el audio sin pérdida: al descomprimirlo se recuperan exactamente los mismos números que había en el WAV, ni uno distinto. La caja de arriba lo demuestra en directo: tu navegador decodifica el FLAC y compara, uno por uno, sus 184.320 valores con los del WAV de la sección 01.

¿Cómo se comprime algo sin perder nada? Aprovechando que el sonido es predecible. FLAC divide la señal en bloques y, en cada uno, estima cada muestra a partir de las anteriores (predicción lineal). Solo guarda el error de esa predicción, el residuo: números pequeños que se codifican con pocos bits mediante códigos de Rice. En estéreo, además, codifica la suma y la diferencia de los canales cuando eso sale más barato. Una nota de órgano sostenida es muy regular, así que aquí el archivo queda en algo más de la mitad del WAV.

La cabecera STREAMINFO guarda la frecuencia de muestreo, la resolución, el número de muestras y una huella MD5 del audio original, de modo que el propio archivo permite comprobar su integridad. Las etiquetas (título, intérprete, álbum) van en bloques Vorbis comment. Creado por Josh Coalson en 2001 y mantenido por la fundación Xiph.Org, es un formato abierto y libre de patentes; la IETF lo publicó como estándar en 2024 (RFC 9639).

FLAC (Free Lossless Audio Codec) compresses audio losslessly: decompressing it gives back exactly the same numbers the WAV contained, not one different. The box above proves it live: your browser decodes the FLAC and compares its 184,320 values one by one with those of the WAV in section 01.

How do you compress without losing anything? By exploiting the predictability of sound. FLAC splits the signal into blocks and, in each, estimates every sample from the previous ones (linear prediction). It stores only the prediction error, the residual: small numbers encoded in few bits with Rice codes. In stereo it also encodes the sum and difference of the channels when that is cheaper. A sustained organ note is very regular, so here the file ends up at just over half the size of the WAV.

The STREAMINFO header stores the sample rate, bit depth, sample count and an MD5 fingerprint of the original audio, so the file itself can verify its integrity. Tags (title, performer, album) go in Vorbis comment blocks. Created by Josh Coalson in 2001 and maintained by the Xiph.Org Foundation, it is an open, patent-free format; the IETF published it as a standard in 2024 (RFC 9639).

MP3 (MPEG-1 Audio Layer III) comprime con pérdida: no intenta conservar los números del WAV, sino lo que un modelo psicoacústico predice que vas a oír. Desarrollado sobre todo en el Fraunhofer IIS (Karlheinz Brandenburg y su equipo) y normalizado en ISO/IEC 11172-3 (1993), este archivo, codificado con LAME a 128 kbit/s, ocupa unas once veces menos que el WAV.

El codificador trocea la señal en tramas de 1.152 muestras, las pasa al dominio de la frecuencia (un banco de filtros seguido de una MDCT) y cuantifica cada banda con la precisión justa para que el ruido que introduce quede por debajo del umbral de enmascaramiento: los sonidos fuertes tapan a los débiles cercanos en frecuencia y en tiempo, y lo tapado no necesita bits. A esta tasa, además, el codificador aplica un filtro paso bajo.

La gráfica compara el espectro medio de los dos archivos, decodificados en tu navegador: hasta unos 15 kHz las curvas casi coinciden; por encima, la del MP3 se desploma. Y aunque suene casi igual, la forma de onda no se conserva: tras alinear las dos señales, casi ninguna muestra coincide exactamente. El MP3 guarda una aproximación perceptiva, no los datos. Sus patentes vencieron en 2017.

MP3 (MPEG-1 Audio Layer III) compresses lossily: it does not try to keep the WAV's numbers, only what a psychoacoustic model predicts you will hear. Developed mainly at Fraunhofer IIS (Karlheinz Brandenburg and his team) and standardized as ISO/IEC 11172-3 (1993), this file, encoded with LAME at 128 kbit/s, is about eleven times smaller than the WAV.

The encoder cuts the signal into frames of 1,152 samples, moves them to the frequency domain (a filter bank followed by an MDCT) and quantizes each band just finely enough for the added noise to stay below the masking threshold: loud sounds hide quieter ones nearby in frequency and time, and what is hidden needs no bits. At this bitrate the encoder also applies a low-pass filter.

The chart compares the average spectrum of both files, decoded in your browser: up to about 15 kHz the curves nearly coincide; above that, the MP3 curve collapses. And although it sounds almost the same, the waveform is not preserved: after aligning both signals, hardly any sample matches exactly. MP3 stores a perceptual approximation, not the data. Its patents expired in 2017.

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 (el entero PCM dividido entre 32.768; los valores almacenados van de −32.768 a +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.768 a +32.767), leído directamente del fichero. 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 07).

The waveform is the direct visual representation of the 184,320 numeric values in the audio file. Each point on the horizontal axis corresponds to a sampling instant (1⁄44,100 of a second) and its vertical position indicates the amplitude of that sample: how compressed or rarefied the air was at that moment, normalized between −1 and +1 (the PCM integer divided by 32,768; stored values range from −32,768 to +32,767).

At a broad view you can see the structure: the note's attack, its sustain, and the silence that follows. Zooming in, the apparently smooth curves reveal themselves as a discrete sequence of points connected by straight lines—no information exists between them. At maximum zoom you can see each individual sample as an isolated point: a single number captured in 1⁄44,100 of a second.

Hovering over the graph, the info bar shows three values: t is the time in seconds from the start of the file; amp is the normalized amplitude (−1 to +1, with 0 being absolute silence); and PCM is the integer stored in the 16-bit WAV file (from −32,768 to +32,767), read directly from the file. The Y+ / Y− buttons expand or compress the vertical scale to reveal very small amplitude variations that would be invisible at full scale.

The waveform provides information about dynamics, envelope, and silences. It contains no direct information about pitch or timbre: a flute and an organ playing the same A at equal volume would produce similar amplitudes but completely different morphologies—without frequency analysis you could not distinguish them. That is what the spectrogram (section 07) is for.

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 a 22.050 Hz, el límite de Nyquist; por defecto se muestran 0–6.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 escrita es La5, doblada a la octava inferior (La4), como en todas las partituras de esta página. Pero el órgano de esta grabación no está afinado al diapasón moderno (La4 = 440 Hz): suena casi un semitono más alto, con el La4 en ≈ 466 Hz, un diapasón habitual en órganos históricos alemanes. Esa es la banda más intensa. La más grave aparece en ≈ 233 Hz, porque la registración suma tubos una octava por debajo y varias por encima de la tecla pulsada. Todas las bandas visibles son múltiplos de esos 233 Hz: 466, 699, 932, 1.165, 1.398, 1.865, 2.331 Hz… Los parciales superiores aportan el brillo característico del instrumento.

Las bandas son horizontales porque el tubo de órgano mantiene una frecuencia constante, sin vibrato, con una excepción visible: el mordente. Entre 0,26 y 0,31 s todas las bandas bajan un tono (466 → ≈ 416 Hz, del La al Sol) y vuelven enseguida. Son los 50 milisegundos del adorno que la partitura escribe con un solo signo.

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.

The waveform tells you how much sound exists at each instant, but not which note is playing. The spectrogram solves this by adding a third dimension: frequency. The horizontal axis is time; the vertical axis is frequency in Hz (from 0 to 22,050 Hz, the Nyquist limit; 0–6,000 Hz shown by default); and color indicates the energy of each frequency at each instant, expressed in decibels (dB). The color scale runs from black (silence) to bright white (maximum energy), through purple and orange—a "spectral thermometer."

It is built using the Short-Time Fourier Transform (STFT). The algorithm sweeps through the complete signal, dividing it into overlapping windows of 2,048 samples (≈ 46.4 ms at 44,100 Hz). Each window is multiplied by a Hann function—a smooth curve that weights central samples more than edges—to avoid spectral leakage: the artifact that would appear if we cut the signal abruptly. Then the FFT (Fast Fourier Transform) is computed for each window, yielding 1,024 frequency "bins" of 21.5 Hz width each (44,100 / 2,048). With a 512-sample hop between windows—75% overlap—one spectral frame is produced every 11.6 ms, yielding 177 frames total for the 2.09 seconds of audio.

There is an inescapable physical limit: the time-frequency uncertainty principle, analogous to Heisenberg's in quantum mechanics. Larger windows give better frequency resolution (narrower bins) but worse time localization; smaller windows detect fast events but cannot distinguish nearby frequencies. With the 2,048 points chosen here, frequencies separated by ≥ 21.5 Hz can be distinguished, but temporal events can only be localized to ≈ 46 ms precision. There is no way to improve both simultaneously.

In the spectrogram you can identify the harmonic structure of the organ. The written note is A5, doubled at the lower octave (A4), as in every score on this page. But the organ in this recording is not tuned to modern pitch (A4 = 440 Hz): it sounds almost a semitone higher, with A4 at ≈ 466 Hz, a pitch standard common on historical German organs. That is the most intense band. The lowest appears at ≈ 233 Hz, because the registration adds pipes an octave below and several octaves above the key played. Every visible band is a multiple of those 233 Hz: 466, 699, 932, 1,165, 1,398, 1,865, 2,331 Hz… The upper partials give the instrument its characteristic brilliance.

The bands are horizontal because an organ pipe holds a constant frequency, with no vibrato, with one visible exception: the mordent. Between 0.26 and 0.31 s every band drops a whole tone (466 → ≈ 416 Hz, from A to G) and immediately returns. Those are the 50 milliseconds of the ornament that the score writes with a single sign.

The controls allow detailed exploration. The −/+ buttons, the slider and the mouse wheel zoom the time axis; dragging pans the time window. The F+ / F− buttons zoom the visible frequency range (vertical axis), useful for examining the harmonic region up close. Hovering over the graph shows the exact time in seconds, the frequency in Hz at the pointed location, and its energy in 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» —que atribuye la obra a Bach, indica la tonalidad («ex d»: en re) y precisa que 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.

What you see is not Bach's autograph—which has not survived—but the earliest known source of the work: a manuscript copy made by Johannes Ringk (1717–1778), organist and pupil of Johann Peter Kellner (a regular Bach copyist). Ringk transcribed the piece between 1740 and 1760, two to five decades after its composition. The title he wrote was: "Toccata Con Fuga: pedaliter. ex. d. #. di J. S: Bach: Scrips: Johannes Ringk"—which attributes the work to Bach, gives the key ("ex d": in D) and specifies that it is "pedaliter," for organ with obligatory pedal.

The manuscript is part of the collection D-B Mus.ms. Bach P 595 (fascicle 8, pages 57–64), held at the Staatsbibliothek zu Berlin – Preußischer Kulturbesitz. Its provenance is precisely documented: Ringk → Eduard Grell (director of the Sing-Akademie zu Berlin, 1800–1886) → the bookseller Leo Liepmannssohn (1840–1915) → the Staatsbibliothek Berlin, where it entered in 1887.

The image shows the first system of the Toccata: the great opening mordent that begins the work. The area with greater brightness (white transparency) corresponds to notes beyond the 2-second reference covered by this project. Interestingly, although we hear three notes, the score shows only one written note: the ornament symbol (Mordant) condenses all the ornamentation into a single graphic glyph above the notehead, following baroque ornament notation convention.

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. Este archivo, exportado desde Keynote, guarda la imagen de 1 bit con compresión Flate (la de ZIP), también sin pérdida. 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.

A scanned PDF is essentially a raster image encapsulated in a PDF container. Unlike a native PDF generated by notation software, it contains no vector graphic primitives or real text: it stores one or more compressed image objects (JBIG2, CCITT Group 4, or JPEG) along with minimal page metadata. The musical "intelligence"—pitches, rhythms, dynamics, articulations—does not exist as structured data; it is implicit in the pixels and can only be extracted via Optical Music Recognition (OMR).

The digitization process converts the paper's light reflectance into a grid of discrete values using a photodiode array. Resolution is measured in DPI (dots per inch): archival guidelines recommend 300–600 DPI in grayscale or bitonal (1 bit per pixel) for scores. JBIG2 compression (or CCITT Group 4, the high-resolution fax algorithm) achieves ratios of 10:1 to 50:1 without perceptible loss on binary images. This file, exported from Keynote, stores its 1-bit image with Flate compression (the one used by ZIP), also lossless. Despite this, the resulting file is 5 to 50 times larger than an equivalent vector PDF.

Scanning introduces systematic distortions: skew if the page was misaligned on the glass; illumination gradients producing uneven backgrounds; paper grain amplified in light areas; thresholding halos on thin strokes. These artifacts must be corrected before OMR through deskewing, adaptive binarization, and morphological filtering.

The image works at three zoom levels. The full view shows the first system with the reference transparency. The first click zooms in on the mordent area. The second click reaches the individual scanner pixel level: figure outlines reveal themselves as staircases of discrete squares—the raster nature distinguishing this format from vector or symbolic representations. A third click returns to the full view.

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 de descripción de página del PDF, heredero de PostScript. 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 07), la línea de un pentagrama es una cadena de píxeles negros. En el PDF vectorial, esa misma línea es una secuencia de operadores como 0.5 w 72 700 m 540 700 l S —grosor de trazo, punto inicial (m, moveto), punto final (l, lineto) y «traza» (S)— que el intérprete convierte en la línea más nítida que el dispositivo de salida sea capaz de reproducir. Se imprima a 600 ppp o a 2.400 ppp, el fichero es idéntico; 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 musical Emmentaler (cuyo juego de glifos se llama Feta), diseñada exclusivamente para notación musical, junto con C059, una Century Schoolbook, para el texto; el visor PDF las usa igual que haría con Arial o Times New Roman. El fichero vectorial ocupa 42 KB y el escaneado 295 KB, aunque la comparación es solo orientativa: no contienen lo mismo (el escaneado reproduce un sistema completo de la Neue Bach-Ausgabe; este PDF, solo el compás inicial). Aun así ilustra la idea: describir la geometría ocupa mucho menos que almacenar la rejilla de píxeles.

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 la página. El primer clic amplía la zona del mordente: se aprecian el Mordant, el calderón y la cabeza de la nota. El segundo clic llega al máximo detalle. Ambas ampliaciones se dibujan en el momento a partir del propio PDF, a la resolución de tu pantalla, y por eso contrastan con los píxeles escalonados del escaneado (sección 07): los bordes del glifo son curvas matemáticas, sin escalera ni ruido. Un tercer clic devuelve a la vista completa.

A vector PDF generated by notation software stores not pixels but geometric instructions: each element of the score—staff lines, noteheads, stems, slurs, dynamics—is described through Bézier curves, segments, and filled shapes in PDF's page-description language, a descendant of PostScript. The viewer reconstructs the image at render time to the exact resolution of the device, with no quality loss regardless of scale.

The difference from a scanned file is structural. In a raster PDF (section 07), a staff line is a chain of black pixels. In the vector PDF, that same line is a sequence of operators such as 0.5 w 72 700 m 540 700 l S—stroke width, start point (m, moveto), end point (l, lineto) and "stroke" (S)—that the renderer converts into the sharpest line the output device can produce. Whether printed at 600 or 2,400 DPI, the file is identical; only the renderer changes.

Special musical glyphs—clefs, brackets, noteheads, ornaments—are stored as embedded typefaces or direct vector paths. LilyPond embeds its music font Emmentaler (whose glyph set is called Feta), designed exclusively for music notation, along with C059, a Century Schoolbook, for text. The vector file takes 42 KB and the scan 295 KB, although the comparison is only indicative: they do not hold the same content (the scan reproduces a full system of the Neue Bach-Ausgabe; this PDF, only the opening bar). Still, it illustrates the point: describing geometry takes far less space than storing a pixel grid.

The image works at three zoom levels. The full view shows the page. The first click zooms in on the mordent area, showing the Mordant, the fermata and the notehead. The second click reaches maximum detail. Both zooms are drawn on the fly from the PDF itself, at your screen's resolution, which is why they contrast with the stepped pixels of the scan (section 07): glyph edges are mathematical curves, no stairstepping or noise. A third click returns to the full view.

Este PNG fue exportado por LilyPond 2.24.4, que, a través de Ghostscript, 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í, tres canales RGB de 8 bits: además del blanco y el negro hay más de un centenar de grises intermedios en los bordes, fruto del suavizado o antialiasing). 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, apenas disimulados por esos grises intermedios. 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.

This PNG was exported by LilyPond 2.24.4, which rasterizes its internal vector representation to a pixel grid. Unlike a scanned PDF—where a printed score was photographed—no photographic process exists here: the software converts every Bézier curve, every Feta glyph, and every staff line into a color dot matrix with full mathematical precision.

PNG stores each pixel as a value tuple (here, three 8-bit RGB channels: besides black and white there are over a hundred intermediate greys along the edges, the result of antialiasing). Compression uses DEFLATE—lossless, the same algorithm as ZIP—which efficiently encodes large uniform white areas. The resolution is fixed at export time. Zooming beyond 100% makes pixels visible and staff lines, noteheads, and stems appear stepped, barely softened by those intermediate greys. The zoom shows this behavior at the opening Mordant.

PNG is the standard for raster scores for a specific technical reason: JPEG uses lossy compression designed for photographs, which generates blocking artifacts and blurry edges at the sharp black-white transitions of music notation. PNG preserves every edge without distortion. The only limitation is fixed resolution: for lossless scaling, vector formats like SVG or PDF are the correct choice.

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, de forma simplificada, cómo se descompone la nota inicial (La5 con Mordant: línea adicional, cabeza, plica con corchete y adorno). 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: las líneas del pentagrama son <line>; las plicas, líneas adicionales y barras de compás, <rect>; cabezas y adornos, <path>. Ningún elemento dice «soy una plica»: solo las coordenadas lo revelan. 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.

This SVG was generated by LilyPond 2.24.4, the same software that produced the vector PDF and PNG. Unlike those binary formats, SVG is pure XML: a text document where every staff line, notehead, and ornament exists as a labeled element, inspectable and modifiable directly with a text editor or JavaScript.

Each graphic element—a note, a stem, a dynamic symbol—is conceptually an independent layer. The interactive diagram shows, in simplified form, how the opening note (A5 with Mordant: ledger line, notehead, flagged stem and ornament) decomposes. Toggle each layer to see its constituent elements, and hover over the buttons to see the corresponding SVG code.

In practice, LilyPond generates a flat sequence of individual <g transform="translate(x,y)"> elements without semantic grouping: staff lines are <line>; stems, ledger lines and barlines, <rect>; noteheads and ornaments, <path>. No element says "I am a stem": only coordinates reveal it. But any <g> can receive an id or class and be manipulated with CSS or JavaScript: fill, opacity, animations, highlighting synchronized with audio playback. That addressability is what distinguishes SVG from any other visual format.

Transcripción exacta de lo escrito en la partitura: las notas A5 y A4 (cada una en su pista), con duración de corchea a 30 BPM (negra = 30, como en MusicXML y **kern). El mordente no aparece: MIDI no tiene forma de representar un adorno, solo notas; por eso la sección siguiente lo escribe nota a nota. 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í:

An exact transcription of what is written in the score: notes A5 and A4 (each on its own track), eighth-note duration at 30 BPM (quarter = 30, as in MusicXML and **kern). The mordent is absent: MIDI cannot represent an ornament, only notes; that is why the next section writes it out note by note. MIDI encodes discrete events—note_on, note_off—with their note number (0–127), velocity, and position in ticks. It contains no audio: it is a sequence of instructions for a synthesizer.

A Standard MIDI File (SMF) consists of blocks called chunks. The first, MThd, is a 14-byte header indicating the format (0 = one track, 1 = multi-track synchronized), number of tracks, and temporal resolution in ticks per quarter note. This file uses format 1 with 384 ticks/beat and four tracks, as generated by LilyPond.

Each track begins with MTrk followed by its byte length. Events are preceded by a delta time: the time relative to the previous event, encoded in Variable Length Quantity (VLQ). In VLQ, bit 7 of each byte indicates whether another byte follows; the remaining 7 bits are data.

Note A5 corresponds to MIDI number 81 (0x51). The formula is: n = 12×(octave + 1) + semitone, with A = semitone 9. The four bytes of the note_on event are read as follows:

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. El tempo de este archivo es de 60 BPM: 48 ticks son 125 ms, en la línea de los ≈ 50–100 ms que dura el adorno en la grabación.

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 a la única corchea de 192 ticks del literal—, en que aquí aparece la nota auxiliar del adorno, G (4F, un tono por debajo: la nota inferior de la escala de re menor y la misma que se oye en la grabación), 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.

The same mordent in three MIDI events written by hand: A → G → A, in both hands (A5+A4 simultaneous), forte. Unlike the literal MIDI—mechanically generated from the score—this file captures an interpretive decision: the durations are not equal and the final note is extended to give weight to the return. This file runs at 60 BPM: 48 ticks last 125 ms, in the range of the ≈ 50–100 ms the ornament takes in the recording.

MIDI contains no audio. The file is a sequence of instructions—such note at such time with such intensity—that a synthesizer executes in real time. What you hear is generated by the browser using a soundfont: a collection of pre-recorded audio samples, one per instrument and dynamic. The MIDI file itself does not change; only who reads it changes.

The same file can sound radically different depending on the player. A pipe organ soundfont renders something close to Bach; the standard GM soundfont that operating systems carry sounds like a toy keyboard from the nineties. Three opposing sounds, one 160-byte file. This ambiguity is both the strength of MIDI (universality, lightness) and its limitation (it does not define timbre).

Compare it to the literal MIDI from the previous section: both files are SMF Type 1, both encode A5 as 51 and use status byte 90. The difference lies in proportions—48 / 48 / 160 ticks versus the single 192-tick eighth note of the literal file—, in the ornament's auxiliary note, G (4F, a whole tone below: the lower neighbour in the D minor scale and the same note heard in the recording), and in each note sounding in two octaves at once. The format does not distinguish between "literally transcribed" and "interpreted"; that semantics is supplied by whoever writes the data.

Antes del MIDI ya existía una manera de guardar qué teclas se pulsan y durante cuánto tiempo: el rollo de pianola. Una tira de papel perforado avanza sobre una barra lectora con una hilera de orificios, uno por tecla. Cuando una perforación pasa por encima de su orificio, entra aire en el mecanismo neumático y la tecla se acciona; la longitud del agujero es la duración de la nota. Es, literalmente, un piano roll: la vista de notas sobre el tiempo de los secuenciadores actuales hereda de aquí su nombre.

Lo que ves es un esquema generado a partir del MIDI interpretado (sección 12): las mismas notas La → Sol → La, en las dos octavas, perforadas en un rollo estándar de 88 notas, el formato que acordaron los fabricantes en la convención de Buffalo de 1908 (11¼ pulgadas de ancho, 9 orificios por pulgada). A la velocidad «tempo 70», que significa 7 pies de papel por minuto (≈ 35,6 mm/s), las dos primeras notas del mordente son agujeros de apenas 4,4 mm y la nota final, de unos 15 mm. Pulsa reproducir y el papel avanzará sobre la barra al ritmo del MIDI; el botón «escala real» muestra el rollo sin la ampliación temporal ×8 que se aplica por defecto para que se lea mejor.

Lo que se pierde: un rollo básico solo sabe si una tecla está pulsada o no. Las velocidades del MIDI (105, 100, 112, 108) no tienen dónde perforarse; la dinámica la ponía el pianolista con pedales y palancas. Los rollos de reproducción (Welte-Mignon, 1904; Ampico; Duo-Art) añadieron perforaciones en los márgenes para codificar la intensidad, y Welte llegó a producir rollos para órgano. Pero, igual que el MIDI, el rollo no conoce voces, compases ni alteraciones: registra una ejecución, no una partitura.

Long before MIDI there was already a way to store which keys are pressed and for how long: the player-piano roll. A strip of perforated paper travels over a tracker bar with a row of holes, one per key. When a perforation passes over its hole, air enters the pneumatic mechanism and the key is played; the length of the slot is the duration of the note. It is literally a piano roll: today's sequencers borrow the name for their notes-over-time view.

What you see is a diagram generated from the interpreted MIDI (section 12): the same notes A → G → A, in both octaves, punched into a standard 88-note roll, the format manufacturers agreed on at the 1908 Buffalo convention (11¼ inches wide, 9 holes per inch). At "tempo 70", meaning 7 feet of paper per minute (≈ 35.6 mm/s), the first two notes of the mordent are slots of just 4.4 mm and the final note about 15 mm. Press play and the paper will move over the tracker bar in time with the MIDI; the "real scale" button shows the roll without the ×8 time magnification applied by default for legibility.

What is lost: a basic roll only knows whether a key is down or not. The MIDI velocities (105, 100, 112, 108) have nowhere to be punched; dynamics were supplied by the pianola player with pedals and levers. Reproducing rolls (Welte-Mignon, 1904; Ampico; Duo-Art) added perforations in the margins to encode intensity, and Welte even produced rolls for organ. But, like MIDI, the roll knows nothing of voices, bars or accidentals: it records a performance, not a score.

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.

The native format of MuseScore 4. Although it has a .mscz extension, it is internally a ZIP file containing the score in XML (.mscx), the complete visual style, a thumbnail, and audio settings. It preserves the exact document state in MuseScore but only that software interprets it fully. The ZIP explorer above lets you examine every internal file directly in the browser.

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.

MusicXML compressed as ZIP, the interchange format between notation software. The MXL file contains the internal MusicXML plus a manifest file META-INF/container.xml. Uncompressing it yields the same content as the .musicxml. It is the distribution format recommended by the W3C Music Notation Community Group. The list above shows both internal files.

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.

The score interchange standard based on XML, with the hierarchy <score-partwise> → <part> → <measure> → <note>. Each note's pitch is encoded in <pitch> with three fields: step (name), octave (integer), and alter (chromatic semitones). Duration uses two layers: <duration> counts integer divisions per quarter note—defined in <divisions>—while <type> indicates the graphic note figure independently of actual duration, allowing tuplets and grace notes to be encoded without ambiguity. Developed by Michael Good at Recordare from 2000; open standard maintained by the W3C Music Notation Community Group since 2015.

The separation between semantic duration and graphic figure is one of the format's most important mechanisms. A triplet of three quarter notes in 4/4 can have <duration>2</duration> (two divisions) but <type>quarter</type>: the actual duration is ⅔ of a quarter note, but typography shows it as a quarter. The engine knows it is a triplet because <time-modification> declares the 3:2 ratio.

The document also includes presentation blocks in <defaults> (margins, scaling in millimeters per tenth, typefaces) and per-instrument MIDI configuration in <score-instrument> / <midi-instrument> (bank, GM program, volume). This duality explains why 63% of the lines in this file are not notes: they are metadata, appearance, and playback instructions that the standard requires to guarantee interoperability across editors.

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, el mordente inferior: nota principal, la de abajo y regreso; aquí La–Sol–La, un tono) 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.

A music typography compiler: the .ly file is processed by a Scheme/Guile interpreter that converts the declarative syntax into graphic objects (Grobs). In \relative mode, pitches are expressed as intervals from the previous note: a'' places the note in octave 5, where each apostrophe raises one octave from the reference. The figure 8 denotes an eighth note; \mordent and \fermata are articulations that the engine positions automatically. Free software under GPL, developed by Han-Wen Nienhuys and Jan Nieuwenhuizen since 1996.

In this fragment, \relative sets the reference pitch for each voice. The first voice starts on a'' (A5); the second on a' (A4). Both articulate the same gesture: an eighth note with Mordant (\mordent, the lower mordent: main note, the one below and back; here A–G–A, a whole tone) and fermata (\fermata), followed by silence to complete the measure. This is the exact opening of the Toccata in D minor.

LilyPond compiles in two passes. In the first, the Scheme interpreter traverses the music calculating durations, proportions, and voice hierarchies. In the second, the spacing engine—based on the Knuth-Plass algorithm, the same one TeX uses to justify text—optimizes horizontal spacing globally. The result is pure PostScript: no graphics framework, no real-time rendering. This is why LilyPond systematically produces the highest-quality typography: it optimizes the whole, not note by note.

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: mayúsculas para la octava del Do central (C = Do4 … B = Si4) y minúsculas para la siguiente (c = Do5 … b = Si5); cada apóstrofo sube una octava y cada coma la baja. Así, A es La4 y a es La5. 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 (un bemol: Si♭). 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 19 caracteres lo que MusicXML necesita más de 15 líneas de XML: la altura (La5), dos decoraciones (Mordant + calderón) y la duración implícita (una corchea = L). Esta compacidad es la fortaleza de ABC. La contrapartida: las extensiones %% no son universales y el formato carece de representación para posiciones tipográficas precisas.

Linear ASCII notation where each header field carries a letter identifier followed by a colon: X: (index), T: (title), M: (meter as fraction), L: (base note unit), Q: (tempo in BPM), K: (key in Anglo-Saxon notation). Notes are written as letters: uppercase for the middle-C octave (C = C4 … B = B4) and lowercase for the next one (c = C5 … b = B5); each apostrophe raises an octave and each comma lowers one. So A is A4 and a is A5. Durations are multipliers of L. Decorations like !mordent! and !fermata! immediately precede the note. Originated in 1991 (Chris Walshaw) to share folk melodies by email.

K:Dm sets the implicit D minor key signature (one flat: B♭). The directives %%MIDI program 19 and %%staves are non-standard extensions recognized by tools like abcjs and abcm2ps but ignored by basic parsers. The rest z7 is a rest of 7 units: with L:1/8, equivalent to 7 eighth notes, completing the 4/4 measure.

The expression !mordent!!fermata!a encodes in 19 characters what MusicXML needs more than 15 lines of XML to express: the pitch (A5), two ornaments (Mordant + fermata), and the implicit duration (one eighth note = L). This compactness is ABC's strength. The trade-off: %% extensions are not universal, and the format lacks representation for precise typographic positions.

Music Encoding Initiative: estándar XML académico, inspirado en TEI, pensado para la edición crítica y con más capacidad expresiva que MusicXML en ese terreno. 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 de la plica). 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 académicos que los demás formatos de esta demo recogen solo en parte (**kern, por ejemplo, admite el número de catálogo en !!!ONM): 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 Beethovens Werkstatt.

Music Encoding Initiative: an academic XML standard, inspired by TEI, designed for critical editions and more expressive than MusicXML in that area. Each note is defined with semantic attributes: pname (note name), oct (octave in Scientific Pitch Notation), dur (figure: 8=eighth, 4=quarter), stem.dir (stem direction). Ornaments—<mordent>, <fermata>—are independent elements that reference the note via startid="#n1", decoupling ornamentation from musical data. Maintained by the MEI Community since 2010.

The separation between note and ornament is a fundamental philosophical difference from MusicXML. In MusicXML, the mordent is a child of <notations> inside <note>, structurally tied to it. In MEI, <mordent startid="#n1"/> is a sibling of <note xml:id="n1"/> within the measure: both are equal in the hierarchy and linked by reference. This allows adding, removing, or editing ornaments without modifying note data.

The file includes scholarly metadata that the other formats in this demo capture only in part (**kern, for instance, allows the catalogue number in !!!ONM): the composer's GND identifier (codedval="11850553X"), BWV classification, performance medium (<perfRes>), and editorial declaration of encoding scope. These capabilities make MEI the preferred standard in digital musicology projects such as Bach Digital.

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 de tono entero (m, de semitono), r=silencio. Los metadatos globales usan prefijos !!!: !!!COM (compositor), !!!OTL (título), !!!CDT (fechas). Desarrollado por David Huron a finales de los años 80 y comienzos de los 90 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.

The Humdrum Toolkit format: tabular text where each column (spine) represents a voice separated by tabs and each row a temporal instant. The **kern prefix declares the representation type. Notes follow the pattern [duration][pitch][modifiers]: duration is a divisor of a whole note (8=eighth, 4=quarter); pitch uses repeated letters for octave—a=A4, aa=A5, aaa=A6; modifiers are suffixes: ;=fermata, M=whole-tone mordent (m, semitone), r=rest. Global metadata uses !!! prefixes: !!!COM (composer), !!!OTL (title), !!!CDT (dates). Developed by David Huron in the late 1980s and early 1990s.

Octave encoding by letter repetition is one of **kern's most distinctive features. The letter a represents A4; doubling it—aa—raises to A5; tripling—aaa—to A6. Uppercase lowers: A=A3, AA=A2.

The spine system is Humdrum's fundamental architecture. Spines are declared with **type and terminate with *-; they can branch (*^), merge (*v), or swap (*x). Interpretation records (lines with *) modify the active context. This separation between data, local interpretations, and global metadata makes Humdrum an analytical system—designed to be processed with Unix tools like grep, awk, and pipes—rather than a visual interchange format.

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.

Es un formato de columnas fijas, heredero de las tarjetas perforadas: en cada registro de nota la altura ocupa las columnas 1–4, la duración (en divisiones de negra) la 6–8, la figura la 17, la plica la 23 y los adornos, a partir de la 32 (M = mordente, F/E = calderón arriba/abajo). El encabezado $ fija armadura (K:-1), divisiones (Q:2), compás (T:4/4) y clave (C:4, sol).

Format of the Center for Computer Assisted Research in the Humanities (CCARH, Stanford). One of the first digital music encoding systems, developed in the 1980s by Walter Hewlett. It served as the basis for the academic collections of Bach, Beethoven, Vivaldi, and Mozart digitized by the CCARH. A direct precursor to MusicXML.

It is a fixed-column format, inherited from punched cards: in each note record the pitch occupies columns 1–4, the duration (in quarter-note divisions) 6–8, the note type 17, the stem 23 and ornaments from 32 onwards (M = mordent, F/E = fermata above/below). The $ record sets key (K:-1), divisions (Q:2), meter (T:4/4) and clef (C:4, treble).

Sistema de notación táctil para músicos con discapacidad visual. Louis Braille la incluyó ya en 1829, en la primera publicación de su sistema. Cada célula de nota codifica a la vez el nombre de la nota (puntos 1, 2, 4 y 5) y su valor (puntos 3 y 6). No es una transliteración del pentagrama: no hay pentagrama ni claves obligatorias; la altura absoluta la fijan las marcas de octava. Dentro de un compás las células van seguidas, sin espacios; el ornamento precede a la nota y el calderón la sigue.

A tactile notation system for musicians with visual impairments. Louis Braille included it as early as 1829, in the first publication of his system. Each note cell encodes both the note name (dots 1, 2, 4 and 5) and its value (dots 3 and 6). It is not a transliteration of the staff: there is no staff and no mandatory clef; absolute pitch is set by octave marks. Within a bar, cells are written together without spaces; the ornament precedes the note and the fermata follows it. The table below shows the symbols used to encode this opening mordent.