Riepilogo Tecnico: DECOMPOSER – Imparare a decompilare la musica simbolica in programmi

Definizione del Problema

Il documento affronta la decompilazione di musica simbolica, definita come il compito di recuperare programmi musicali eseguibili e modificabili a partire da input musicali simbolici (nello specifico, MIDI). Sebbene l'esecuzione musicale comporti l'esecuzione di istruzioni di alto livello, il recupero di tali istruzioni dalla performance risultante è un problema inverso complesso.

Gli autori istanziano questo compito come decompilazione da MIDI a Strudel. Strudel è un linguaggio dominio-specifico (DSL) per la composizione algoritmica e il live coding con sintassi JavaScript. A differenza del MIDI, che rappresenta la musica come una sequenza di basso livello di eventi di note, Strudel rappresenta la musica attraverso espressioni di pattern di alto livello, operatori per la ripetizione, la stratificazione e la struttura temporale.

La sfida principale risiede nel bilanciare due obiettivi contrastanti:

1. Fedeltà (Faithfulness): Il programma generato, quando eseguito, deve riprodurre accuratamente il MIDI di input.
2. Leggibilità (Readability): Il programma generato deve essere leggibile dall'uomo e modificabile, esponendo strutture musicali latenti (ad esempio, progressioni di accordi, pattern ritmici) piuttosto che offrire una traslitterazione verbosa nota per nota.

Gli approcci esistenti non riescono a bilanciare questi aspetti: i convertitori euristici ottengono un'alta fedeltà ma producono codice poco leggibile, mentre i frontier Large Language Models (LLM) spesso generano codice leggibile che però non riesce a ricostruire fedelmente il MIDI di input. Inoltre, il compito è caratterizzato da scarsità di dati; i dataset naturalmente accoppiati (MIDI, Strudel) sono virtualmente inesistenti e Strudel è un linguaggio a basse risorse.

Metodologia

Gli autori propongono DECOMPOSER, un framework di post-training a due stadi progettato per ottimizzare direttamente l'obiettivo di decompilazione.

1. Costruzione dei Dati: STRUDEL-SYNTH

Per affrontare la mancanza di dati di addestramento accoppiati, gli autori costruiscono STRUDEL-SYNTH, un corpus sintetico di 21.174 coppie (programma Strudel, MIDI renderizzato).

• Generazione: Un LLM di frontiera (Claude-Opus-4.6) viene istruito per generare programmi Strudel basati su semi musicali (genere, mood, tonalità, ecc.) e semi di stile di codice (idiomi come mini-notazione, stacking o arrangiamento).
• Pulizia: I programmi generati subiscono una pipeline di pulizia che prevede riscritture regex per correggere comuni errori sintattici e un processo di pruning basato su AST per rimuovere le "voci morte" (layer che compilano ma non emettono audio).
• Rendering: I programmi puliti vengono eseguiti tramite un runtime Strudel headless per produrre il relativo MIDI.

2. Pipeline di Addestramento a Due Stadi

DECOMPOSER impiega una strategia di addestramento sequenziale utilizzando modelli open-weight (Qwen3-4B e Qwen3-8B):

• Stadio 1: Supervised Fine-Tuning (SFT)
  Il modello viene sottoposto a fine-tuning sul dataset STRUDEL-SYNTH. Questa fase insegna al modello a produrre codice Strudel valido e idiomatico, fornendo un "warm start" che impedisce al modello di collassare in soluzioni degenerate durante il successivo apprendimento per rinforzo.

• Stadio 2: Reinforcement Learning (RL)
  Il modello viene ulteriormente ottimizzato utilizzando la Group Reward-Decoupled Normalization Policy Optimization (GDPO).

  • Input: Dati MIDI non accoppiati (senza codice di riferimento richiesto).
  • Processo: Per un dato input MIDI, il modello campiona un gruppo di programmi candidati. Ogni candidato viene eseguito tramite il runtime Strudel.
  • Funzione di Ricompensa: Una ricompensa composta $R(\hat{y}, x)$ viene calcolata sulla base di:
    1. Fedeltà ($R_{faith}$): Misurata tramite il punteggio F1 degli onset multi-strumento tra il MIDI di input e il MIDI renderizzato.
    2. Leggibilità ($R_{read}$): Misurata tramite un giudice LLM che valuta una checklist fissa di 12 criteri binari (rubrica) che coprono la qualità generale del codice (formattazione, commenti) e le astrazioni specifiche di Strudel (uso di operatori di pattern, simboli di accordi, riutilizzo di variabili).
  • Ottimizzazione: GDPO normalizza le ricompense per ogni componente indipendentemente prima dell'aggregazione, permettendo al modello di ottimizzare sia la fedeltà che la leggibilità senza che una domini sull'altra.

Contributi Chiave

1. Formulazione del Task: L'introduzione della decompilazione di musica simbolica come un compito distinto, focalizzato sul recupero di una struttura programmatica di alto livello ed editabile da musica simbolica di basso livello.
2. Framework (DECOMPOSER): Un framework di post-training a due stadi che combina SFT su dati sintetici con RL basato su esecuzione su dati non accoppiati. Questo approccio permette al modello di apprendere su larga scala senza richiedere codice di riferimento per lo stadio RL.
3. Dataset (STRUDEL-SYNTH): Il rilascio di un corpus sintetico su larga scala di 21.174 coppie (Strudel, MIDI), costruito tramite generazione LLM ed esecuzione di runtime, che è circa 30 volte più grande del codice Strudel scritto da umani disponibile pubblicamente.
4. Risultati Empirici: La dimostrazione che un modello open-weight da 8B addestrato con questa pipeline supera sostanzialmente i modelli LLM chiusi di frontiera nella fedeltà di decompilazione, mantenendo una leggibilità comparabile.

Risultati

Gli esperimenti sono stati condotti su benchmark MIDI sintetici (STRUDEL-SYNTH) e reali (LMD, GigaMIDI, NES-MDB, Nottingham).

• Fedeltà: DECOMPOSER supera significativamente i modelli LLM di frontiera (Claude-Opus-4.6, Gemini-3.5-Flash, GPT-5.5) nella ricostruzione del MIDI di input. Sul dataset LMD, il modello DECOMPOSER (8B) ha migliorato il punteggio Onset F1 di +0.32 rispetto al miglior LLM di frontiera.
• Leggibilità: A differenza dei convertitori euristici, che ottengono un'alta fedeltà attraverso traslitterazioni verboriche nota per nota (risultando in bassi punteggi di leggibilità), DECOMPOSER produce codice con punteggi di leggibilità (Rubric) di un ordine di grandezza superiori, comparabili agli LLM di frontiera.
• Diversità: Il modello evita il "collasso della diversità", producendo strutture di codice variegate invece di collassare in un singolo template di traslitterazione.
• Generalizzazione: Il modello generalizza bene su dataset fuori dominio (es. chiptune, musica folk), sebbene le prestazioni varino in base alla regolarità ritmica e alla complessità strutturale del genere di input.

Significato e Rivendicazioni

Il documento sostiene che DECOMPOSER riesce a colmare il divario tra la fedeltà richiesta per una ricostruzione accurata e la leggibilità necessaria per l'utilità umana. Il recupero della "struttura musicale latente" che il MIDI appiattisce in singoli eventi consente:

• Editing Programmatico: Permettere agli utenti di modificare strutture musicali di alto livello (accordi, scale, layer) tramite codice anziché regolando le singole note.
• Comprensione Musicale: Fornire una rappresentazione intermedia (codice) che è più interpretabile per l'analisi musicale basata su LLM rispetto alle sequenze di note grezze.
• Pipeline Audio-to-Code: Servire come componente critico per futuri sistemi di decompilazione audio-to-code quando combinati con la trascrizione musicale automatica.

Gli autori sottolineano che l'equivalenza funzionale da sola è insufficiente per la decompilazione; il programma recuperato deve essere leggibile ed editabile per essere utile. DECOMPOSER dimostra che l'apprendimento per rinforzo basato sull'esecuzione può ottimizzare efficacementamente questo compromesso in un contesto di linguaggio dominio-specifico a basse risorse.