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.

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).

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 (equivalent to PCM values between −32,767 and +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,767 to +32,767). 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 03) 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 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.

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 up to over 20,000 Hz); 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 note is A5 (La5), with a fundamental frequency of 880 Hz—the brightest horizontal band near the bottom of the graph. Above it appear the natural harmonics: 1,760 Hz (2nd), 2,640 Hz (3rd), 3,520 Hz (4th), 4,400 Hz (5th)... The pipe organ has a particularly rich harmonic profile: the upper partials contribute the brightness and penetrating quality characteristic of the instrument. The bands are perfectly horizontal because the note is sustained at constant frequency—no modulation or vibrato.

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» —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.

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"—confirming authorship, key (D minor) and that the work 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. 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. 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 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.

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 the PostScript language underlying the PDF. 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 05), a staff line is a chain of black pixels. In the vector PDF, that same line is the command l x1 y1 x2 y2 w—start position, end position, and stroke width—that the renderer converts into the perfect line the output device can produce.

Special musical glyphs—clefs, brackets, noteheads, ornaments—are stored as embedded typefaces or direct vector paths. LilyPond embeds its native Feta font—designed exclusively for music notation—along with LilyPond Serif for text. This explains why the vector file (42 KB) is seven times smaller than the scanned one (295 KB) while containing exactly the same visual information.

The image works at three zoom levels. The first click zooms in on the mordent area, showing the Mordant, the fermata, and the slur with perfectly crisp outlines. The second click reaches maximum detail—contrasting directly with the stepped pixels of the scan (section 05): 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 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.

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: black or white). 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—the aliasing effect. 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 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.

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 how the opening note (A with Mordant) 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: a staff line and a stem are structurally identical in the XML—both are <line>—distinguished only by coordinates. 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: 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í:

An exact transcription of what is written in the score: note A5, eighth-note duration at 60 BPM. 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. 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.

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.

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 uniform value of the literal—and in that the ornament note here is G# (50, lower semitone). The format does not distinguish between "literally transcribed" and "interpreted"; that semantics is supplied by whoever writes the data.

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 ZIP explorer 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, 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.

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) 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: 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.

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: lowercase for the middle octave (A4–G5), uppercase for the lower (A3–G4); apostrophes and commas modify the octave. 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 (F sharp). 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 18 characters what MusicXML needs more than 15 lines of XML to express: the pitch (A, middle octave), two ornaments (Mordant + fermata), and the implicit duration (one eighth note = L). This compactness is ABC's strength. The trade-off: the exact octave depends on accumulated context, and the format lacks representation for precise typographic positions.

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.

Music Encoding Initiative: an academic XML standard extending MusicXML's expressiveness with critical edition capabilities. 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 metadata that no other format in this demo can express as standard: 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, 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.

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=mordent, r=rest. Global metadata uses !!! prefixes: !!!COM (composer), !!!OTL (title), !!!CDT (dates). Developed by David Huron (Ohio State University, 1993).

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.

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.

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.

A tactile notation system for musicians with visual impairments. Developed by Louis Braille in 1829, just three years after his general writing system. Each 6-dot cell simultaneously encodes both the pitch and the duration of a note. It is not a transliteration of the staff: it has its own independent musical grammar. The table below shows the symbols used to encode this opening mordent.