¿Que qué? En esta entrada explico los caminos para pasar de un formato a otro. ¿Pero de qué formatos hablas? Pues de estos:

Si ya sabes de lo que hablo (bien porque me has hecho caso y te acabas de leer la entrada anterior, o porque eres muy confiado), seguimos. En esta entrada vamos a analizar caminos para transformar formatos de notación musical («partituras») de unos a otros. No vamos a explorar todas las vías posibles (por eso he puesto el «I» en números romanos en esta entrada, seguramente hayan más para explorar los terrenos no recorridos), sino las que podrían ser las «autopistas» con más tránsito habitual.

El mapa: cuatro niveles y una sola rotonda

En la entrada anterior los formatos quedaron ordenados en cuatro subcategorías —semántico-notacional, performativo, renderizado visual y renderizado sonoro—, y el principio organizador era la distancia al texto simbólico. Ese principio, leído en clave de conversión, se convierte en algo muy práctico: bajar de nivel es trivial y barato; subir es caro, lento y nunca del todo fiable.

Bajar es renderizar: de un código simbólico sale un PDF, una imagen, un MIDI o un audio con una orden y sin decisiones. Subir es reconstruir: hay que inferir lo que el formato de partida nunca guardó. Un PDF no sabe que aquello es un calderón, un MIDI no sabe si el fa es fa sostenido o sol bemol, y un MP3 no sabe ni siquiera cuántas voces hay.

Y en medio del mapa hay una rotonda por la que pasa casi todo el tránsito: MusicXML. No porque sea el formato más elegante (es enorme y farragoso), sino porque es el único que leen y escriben prácticamente todos los programas. Casi ninguna autopista va de A a B directamente: casi todas pasan por ahí.

graph LR
    subgraph N1["1 · Semántico-notacional"]
        ABC["ABC"]
        LY["LilyPond"]
        MXL["MusicXML"]
        MSC["MuseScore"]
    end

    subgraph N2["2 · Performativo"]
        MID["MIDI"]
    end

    subgraph N3["3 · Renderizado visual"]
        IMG["PDF · imagen"]
    end

    subgraph N4["4 · Renderizado sonoro"]
        AUD["Audio"]
    end

    ABC -->|abctools| MXL
    MXL -->|abctools| ABC
    MXL -->|musicxml2ly · Hacklily Desktop| LY
    MXL -->|abrir| MSC
    MSC -->|exportar| MXL

    ABC -->|abc2midi| MID
    LY -->|lilypond| MID
    LY -->|lilypond| IMG
    MSC -->|mscore -o| IMG
    MSC -->|mscore -o| AUD

    MID -->|MuseScore · midi2ly| MXL
    IMG -->|Audiveris · OMR| MXL
    AUD -->|Basic Pitch · Piano Scribe · AMT| MID

Las flechas que bajan son órdenes de una línea. Las que suben —las tres de la derecha hacia la izquierda— son las que tienen premio y castigo, y son las que ocupan la mitad de esta entrada.

Para no hablar en abstracto, todos los caminos que siguen están recorridos con el mismo archivo de prueba: una melodía popular de ocho compases, en 3/4, con anacrusa, repetición y letra silabeada. Es un ejemplo deliberadamente humilde —cabecera, ocho compases y dos líneas de texto—, y esa es justamente la gracia: si algo se pierde aquí, con una sonata se pierde a lo grande.

Escrito en ABC, ese archivo ocupa 275 caracteres. Guardad la cifra, porque va a volver.

Cuesta abajo: renderizar

Es el camino que nadie discute porque siempre funciona. Los formatos basados en código traen su propio renderizador, y la conversión es una orden de terminal o un botón:

# De ABC a MIDI y a imagen
abc2midi melodia.abc -o melodia.mid
abcm2ps -g melodia.abc -O melodia   # -g = salida SVG

# De LilyPond a PDF (y a MIDI, si el archivo lleva un bloque \midi)
lilypond melodia.ly

# De casi cualquier cosa a casi cualquier cosa, con MuseScore sin abrir ventana
mscore -o melodia.musicxml partitura.mscz

Aquí la pérdida no es un fallo: es el objetivo. Al renderizar se fija todo lo que la notación dejaba abierto —el tempo exacto, el timbre, la maquetación— y se tira todo lo que no se ve ni se oye. El PDF ya no sabe que el si del compás 3 era la sensible; solo sabe que hay una elipse negra en la cuarta línea.

La misma melodía, medida en cada formato, dibuja el principio mejor que cualquier párrafo:

Fijaos en la paradoja: el archivo que más información musical contiene pesa 275 bytes, y el que menos contiene pesa medio megabyte. El peso mide la distancia al símbolo, no la cantidad de música.

En horizontal: traducir entre formatos simbólicos

Este es el tránsito habitual de cualquiera que trabaje con partituras: tengo la música en un formato y la necesito en otro. Como todos los formatos de esta subcategoría contienen la misma clase de información, la traducción es posible; lo que cambia es qué matices sobreviven al viaje.

ABC ↔ MusicXML: la puerta pequeña

ABC es el formato más ligero del ecosistema, y la forma más cómoda de entrar y salir de él es abctools, el editor en línea de Michael Eskin: se pega el código a la izquierda, la partitura aparece a la derecha y el menú de exportación deja MIDI, MusicXML y la imagen. En sentido contrario también abre un MusicXML y lo devuelve como ABC. No hay que instalar nada, así que es la vía que funciona en cualquier ordenador de un aula.

Qué sobrevive: notas, compás, armadura, anacrusa, repeticiones, letra con su silabación. Qué no: todo lo que ABC nunca supo decir —polifonía compleja, matices colocados con precisión, digitaciones, pedal—. Si la música necesita eso, ABC no es el origen correcto.

Y dentro del propio ABC hay conversores exactos que casi nadie usa. Una transposición, por ejemplo, no es trabajo para una IA: abc2abc melodia.abc -t 2 devuelve la melodía un tono más arriba, con la letra y la repetición intactas, en el tiempo que se tarda en pulsar Intro. Eso sí, el programa aprovecha para avisar de que el primer compás «solo» tiene un tiempo —es la anacrusa— y mete la advertencia como comentario dentro del propio archivo. Exacto no significa silencioso.

MusicXML → LilyPond: musicxml2ly

Esta es la autopista que más me interesa, porque conecta la rotonda con el formato de mayor calidad tipográfica. Y la buena noticia es que el conversor ya viene instalado con LilyPond: no hay que descargar nada aparte.

musicxml2ly -l español melodia.musicxml -o melodia.ly

Con -l español las notas salen como do re mi fa sol la si en lugar de c d e f g a b, que para un aula de conservatorio cambia bastante las cosas. Y con -a las octavas se escriben absolutas en lugar de relativas, que evita el error más típico de LilyPond (un apóstrofo de más arrastra toda la frase una octava arriba).

Sobre el archivo de prueba, el resultado conserva lo importante: \partial 4 para la anacrusa, \repeat volta 2 para la repetición, la letra con sus guiones dobles, el título y la autoría. Compila a la primera. Pero conviene mirar lo que añade:

PartPOneVoiceOne = \relative sol' {
  \clef "treble" \time 3/4 \key do \major \partial 4 \repeat volta 2 {
    \U sol8 [ \U fa8 ] \U mi4 \U mi8 [ \U fa8 ] \U sol8 [ \U la8 ] | % 1
    ...

Ese \U delante de cada nota es una dirección de plica fijada a mano: el conversor no se fía del criterio de LilyPond y congela lo que decía el MusicXML. En la letra ocurre algo parecido: cada sílaba que lleva tilde o signo de puntuación sale entrecomillada, y una elisión —dos sílabas cantadas sobre una misma nota— acaba convertida en una cadena con un espacio dentro. Todo correcto, todo feo: es código generado por una máquina para otra máquina, no para que lo edite una persona. Si el objetivo era seguir trabajando el archivo a mano, hay un rato de limpieza por delante.

Para quien no quiera abrir una terminal, Hacklily Desktop hace el mismo camino con un menú: importa MusicXML (y MIDI) y deja el código LilyPond en el editor, con la partitura al lado.

La rotonda: MuseScore como conversor universal

MuseScore importa MusicXML, MXL, MIDI y karaoke, MSCZ, MEI, MNX, Guitar Pro, Capella, Overture, Power Tab, Band-in-a-Box y Bagpipe Music Writer, y exporta MusicXML, MIDI, PDF, PNG, SVG, MP3, WAV, FLAC y LilyPond (este último, con calidad discutible). En la práctica funciona como la pieza que une el resto del mapa: cuando dos formatos no se hablan, se hablan a través de MuseScore.

Y se puede hacer sin abrir la ventana, que es lo que permite convertir cien archivos de una tacada:

# macOS
"/Applications/MuseScore 4.app/Contents/MacOS/mscore" -o salida.musicxml entrada.mid

# Windows
"C:\Program Files\MuseScore 4\bin\MuseScore4.exe" -o salida.musicxml entrada.mid

La extensión del archivo de salida decide el formato. Es la orden más útil de toda esta entrada y no aparece en ningún menú. Y tiene dos opciones que valen su peso en oro: -j lote.json procesa una lista entera de conversiones descrita en un archivo, y -M ajustes.xml aplica a todas ellas los mismos ajustes de importación de MIDI, que es justo lo que uno quiere cuando tiene cuarenta archivos que corregir igual.

El camino que no existe

Conviene decirlo claro: LilyPond no exporta. Es un compilador, no un formato de intercambio. De LilyPond se sale hacia abajo (PDF, MIDI, imagen), pero no hacia MusicXML. Existe lilypond-export y algún experimento más, pero ninguno con la fiabilidad de las otras autopistas. Si un proyecto va a tener que viajar entre programas, LilyPond es un buen destino final y un mal formato de trabajo intermedio.

Cuesta arriba I: del MIDI a la partitura

Aquí empieza lo interesante, porque aquí es donde la conversión deja de ser una traducción y pasa a ser una interpretación. Un MIDI codifica cuándo empieza cada nota, cuándo acaba y con qué fuerza. No codifica compases, ni anacrusas, ni enarmonías, ni letra, ni repeticiones. Todo eso hay que adivinarlo.

Hay dos caminos, y conviene conocer los dos porque fallan de maneras distintas.

midi2ly: literal hasta el absurdo

También viene con LilyPond. Convierte un MIDI en código .ly sin cuantizar nada, y ahí está su virtud y su desgracia. Este es el resultado real sobre el MIDI generado desde el ABC de prueba:

  r4*1/480 f4*239/480 r4*1/480 g4*239/480 r4*1/480 e4*959/480
  | % 17

Eso es un compás. Cada corchea se ha convertido en 239/480 de negra seguida de un silencio de 1/480, porque el sintetizador acorta mínimamente cada nota para que se oiga articulada, y midi2ly transcribe esa microscopía con una fidelidad devota. La letra que el archivo MIDI traía como texto de karaoke aparece, sílaba a sílaba, en forma de comentario: está en el archivo, pero no es letra de la partitura. Y donde el original tenía ocho compases con repetición, aquí hay diecisiete, porque la repetición viaja desplegada.

De 275 bytes de ABC hemos llegado a 4,2 kB de LilyPond que dicen menos música. midi2ly sirve para rescatar las alturas de un archivo del que no hay nada más; no sirve como conversor de partituras.

MuseScore: cuantiza, y ahí toma decisiones

El camino sensato. MuseScore redondea las duraciones a una rejilla y produce una partitura legible. En MuseScore 4 el ajuste quedó reducido a dos opciones, en Preferencias → Importar → MIDI: la nota más corta admitida y si se redondean los tempos. La primera importa más de lo que parece: si la pieza no tiene semicorcheas, decirle que la nota más corta es la corchea limpia de golpe la mitad de la basura.

Mismo archivo MIDI, convertido por lotes con mscore -o. El resultado, contado sobre el MusicXML que sale:

• 68 notas: las 34 del original, dos veces, porque la repetición viene desplegada.
• 16 compases y ninguno marcado como incompleto: la anacrusa desaparece y todos los compases quedan desplazados un tiempo.
• Compás de 3/4 correcto… pero solo porque el MIDI venía de una partitura y traía la indicación dentro. Un MIDI obtenido de un audio no la trae, y entonces MuseScore pone 4/4 y hay que arreglarlo a mano.
• Cero letra. Bueno: cero letra útil. Lo único que ha aterrizado como sílaba, colgando de la primera nota, es la cadena note track, que era el nombre interno de la pista en el archivo MIDI.

Ese note track pegado a la primera corchea resume bastante bien el nivel performativo: el formato no distingue entre una sílaba cantada y una etiqueta técnica, porque para él ambas son texto suelto en el mismo sitio.

Subiendo desde el nivel performativo, las alturas se recuperan casi siempre; lo que se pierde es la estructura: compás, anacrusa, repeticiones, letra y enarmonías. Y la estructura es justo lo que convierte un montón de notas en una partitura.

Cuesta arriba II: de la imagen a la partitura (OMR)

El reconocimiento óptico de música es, seguramente, el camino que más ilusión hace y más decepciones da. La herramienta libre de referencia es Audiveris: se instala, trae su propio Java, acepta PDF, PNG, JPG y TIFF, y exporta un .mxl. Funciona por lotes desde la terminal y tiene una interfaz donde se ve, con colores, qué ha entendido de cada símbolo.

Sobre nuestro escaneo acertó las 34 notas, el compás, la anacrusa y la repetición. Y se inventó una colección de puntos de staccato que no existen en el papel: manchas del escaneo ascendidas a articulaciones.

El otro factor decisivo es la imagen de partida: recta, con buen contraste y escaneada a 300 ppp. Y partituras impresas: los manuscritos, de momento, no son terreno de Audiveris.

Cuesta arriba III: del sonido a la partitura (AMT)

El escalón más alto. Aquí el punto de partida es una onda: ni símbolos, ni líneas, ni notas separadas. Hay que decidir cuántas notas suenan a la vez, dónde empieza cada una y qué altura tiene, y después todo lo del apartado anterior. Dos herramientas gratuitas, las dos en el navegador y las dos con una propiedad que en un centro educativo no es menor: el audio no sale del ordenador.

• Basic Pitch (Spotify, licencia Apache-2.0). Acepta cualquier instrumento y polifonía, graba desde el micrófono y descarga MIDI. Tiene ajustes que cambian mucho el resultado: segmentación de notas, umbral de confianza del modelo, altura mínima y máxima en hercios y duración mínima de nota. También se instala con pip si se quiere usar por lotes.
• Piano Scribe (Google Magenta, modelo Onsets and Frames). Entrenado para piano solo: lo que no es piano lo traduce a piano igualmente. No funciona en iPhone ni iPad.

Con un audio de piano de 29 segundos, Basic Pitch recuperó 68 alturas de 68, y añadió tres notas fantasma. Ni una sola de las decisiones estructurales: compás de 4/4 donde había 3/4, ritmo lleno de silencios minúsculos, repetición desplegada y, evidentemente, ninguna letra. Para convertirlo en algo legible hay que pasar por MuseScore y arreglarlo a mano.

¿Y la IA? Una autopista que no siempre conviene coger

Un modelo de lenguaje convierte formatos. Se le pega un ABC y devuelve MusicXML; se le pega un MusicXML y devuelve LilyPond. Funciona, y la tentación es evidente. Pero después de recorrer los caminos anteriores, la conclusión que me llevo es bastante poco espectacular: cuando existe una herramienta exacta, la IA sobra.

Tres razones concretas, no ideológicas:

1. El determinismo. musicxml2ly se equivoca siempre igual, y por eso se puede aprender dónde se equivoca. Un modelo se equivoca distinto cada vez.
2. El tamaño. Nuestra melodía ocupa 275 caracteres en ABC y 11 318 en MusicXML: unos 300 caracteres por nota. Pedirle a un modelo que escriba MusicXML es pedirle que genere cuarenta veces más texto para decir lo mismo, con el coste y la lentitud correspondientes.
3. El corte. Y ese texto largo tiene un fallo característico: la respuesta se interrumpe a media partitura. El archivo parece bueno hasta que no encuentras el </score-partwise> del final.

Dicho lo cual, hay tres sitios donde la IA sí es la mejor herramienta disponible, y los tres tienen algo en común: no son conversiones.

• Transformar, que es distinto de convertir: cifrar una melodía, añadirle una segunda voz, simplificarla para flauta, adaptarla a un ámbito vocal concreto. Ahí no hay conversor que valga porque hay que decidir.
• Leer los errores. Pegarle el registro de LilyPond entero junto con el código es, con diferencia, el uso que mejor funciona de todos los que he probado.
• Escribir el programa que hace la conversión. Si el chat puede ejecutar código, pedirle que modifique el archivo con un script es mucho más seguro que pedirle que lo reescriba entero: toca lo que tiene que tocar y deja el resto intacto.

Lo que queda para la II

Quedan fuera, y me los apunto: los caminos hacia y desde los formatos académicos (MEI, Humdrum **kern), el Braille musical en las dos direcciones, la conversión de partitura a interpretación —que es modificar el MIDI para que suene humano, y da para una entrada entera—, y el terreno más incómodo de todos: qué ocurre cuando la partitura de partida es un manuscrito.

Herramientas citadas

• abctools — editor ABC en línea, con exportación a MIDI, MusicXML e imagen.
• abcMIDI (abc2midi, abc2abc) y abcm2ps — ABC hacia MIDI, hacia ABC transformado y hacia partitura.
• LilyPond 2.26 — compilador de partituras; trae musicxml2ly y midi2ly.
• Hacklily y Hacklily Desktop — LilyPond sin instalar nada, e importación de MusicXML y MIDI con menú.
• MuseScore 4 — la rotonda, también desde la línea de órdenes con mscore -o.
• Audiveris 5.11 — OMR libre, de imagen a MusicXML.
• Basic Pitch y Piano Scribe — de audio a MIDI, en el navegador y sin subir nada a ningún servidor.

Nota metodológica: todas las conversiones descritas en esta entrada están hechas sobre el mismo archivo de prueba, en un macOS con LilyPond 2.26.0, MuseScore 4.7.5, abcMIDI 5.03, abcm2ps 8.14.18 y Audiveris 5.11. Las cifras (tamaños, número de compases, notas recuperadas, elementos perdidos) están contadas sobre los archivos resultantes, no estimadas. Como en la entrada anterior, el trabajo se ha desarrollado con asistencia de Claude (Anthropic): ejecución de las conversiones, recuento sobre los archivos de salida y redacción; la selección de caminos, la interpretación de los resultados y las conclusiones son del autor.