# Progettare una sala all'inverso: RaySound, e chi arbitra i numeri > Perché un simulatore acustico che risolve solo il problema forward non basta in fase di progetto, e cosa rende difendibile un numero acustico: i limiti in forma chiusa, le identità di conservazione e la misura. Pubblicato: 2026-06-25 Aggiornato: 2026-08-25 Categoria: acustica Tag: acustica-sale, fdtd, raysound, bras, design-inverso, open-source Pagina: --- L'acustica delle sale sta smettendo di essere un "di più" e sta diventando un **requisito d'appalto**. I Criteri Ambientali Minimi per l'edilizia fissano soglie su riverberazione e intelligibilità del parlato che non bastano più a promettere: vanno **dimostrate**. E qui i committenti scoprono una cosa scomoda: i simulatori acustici commerciali — Odeon, CATT-Acoustic, il più recente Treble — rispondono bene a *una* domanda, ma è la domanda sbagliata per chi progetta. ## Il problema forward, e i due passi che restano scoperti Tutti questi strumenti risolvono il **problema forward**: data la sala e dati i materiali, predicono come suonerà. È utilissimo per verificare un progetto già fatto. Ma un progettista parte dall'altra parte: ha un **target** (un tempo di riverbero, una soglia di chiarezza) e deve trovare il trattamento delle superfici che lo raggiunge. Il forward, da solo, ti lascia a tirare a indovinare: cambi un materiale, rilanci, guardi, ripeti. Restano scoperti due passi. Il primo è **progettare all'inverso**: dal capitolato al trattamento, possibilmente sapendo *quale* superficie conviene toccare e non solo *quanti* metri quadri di fonoassorbente buttare in stanza. Il secondo è ancora più sottile: **sapere se i dati che ho bastano** a stimare quello che voglio stimare. Misuro una sala, provo a ricavare i coefficienti di assorbimento dei materiali — ma quei dati contengono davvero l'informazione, o sto restituendo un numero che non regge a un controllo serio? ## RaySound: un ibrido, perché nessun metodo copre tutto **RaySound** è il motore di simulazione proprietario che ST-LINE sviluppa per affrontare entrambi i passi. La prima scelta strutturale è che è **ibrido**, e non per gusto: nessun singolo metodo copre con efficienza l'intero spettro di una sala. Alle basse frequenze il campo è **modale** — poche risonanze ben separate — e va trattato con un vero **solver d'onda**: RaySound usa un metodo a Galerkin discontinuo. Alle alte frequenze il campo diventa **diffuso**, la densità delle risonanze esplode e conviene un approccio **geometrico**, cioè un **ray-tracer** su GPU. Fra i due regimi c'è una transizione — la frequenza di Schroeder — e RaySound la attraversa con un crossover, confinato fra 250 e 500 Hz, costruito per **conservare l'energia**: niente buchi e niente doppi conteggi alla giunzione. Un dettaglio che fa la differenza nel design inverso: **lo stesso modello di materiale** alimenta entrambi i rami, così il problema di "ricavare i materiali dai dati" è ben posto e non si spacca in due descrizioni scollegate. ## Chi arbitra i numeri: le equazioni, non un secondo programma Quando un engine dichiara dei numeri, resta da stabilire che cosa li controlli. La risposta che si sente più spesso è "un altro software", e regge poco. Un'altra implementazione ha i suoi errori, le sue scelte di discretizzazione e il suo autore: al massimo è un secondo parere, e quando i due non concordano non dice nemmeno quale dei due ha sbagliato. Ad arbitrare serve qualcosa che **non dipenda da nessuna implementazione**. Nel forward di RaySound quel qualcosa sono tre cose, in quest'ordine. **I limiti in forma chiusa.** Il tempo di riverbero diffuso non esce dal ray-tracer ma da **Eyring**, ri-pesato sulla frazione di rimbalzi che il campo compie su ciascuna superficie invece che sull'area. Ciò che rende difendibile la scelta è l'**ancoraggio**: quando i pesi dei colpi degenerano nelle frazioni d'area, la formula degenera **esattamente** in Eyring classico, a precisione di macchina. Non è un modello nuovo con uno scarto proprio da giustificare — è Eyring ri-pesato, e se se ne discosta è perché la geometria conta. **Le identità che devono chiudere.** Il crossover fra i due rami usa pesi cos² a somma unitaria, confinati alla banda 250–500 Hz: la conservazione dell'energia alla giunzione è una **proprietà costruttiva**, si verifica come identità e non come accordo da misurare. Lo stesso vale per i gradienti del design inverso, calcolati col **complex-step** e con lo **stato aggiunto** — due strade indipendenti alla stessa derivata, che concordano entro 8·10⁻¹⁰. E il confine fra i due rami non è una manopola da girare: lo fissa la **legge di Weyl** completa attraverso la sovrapposizione modale, col criterio classico M ≳ 3. **La misura.** In fondo c'è il dato sperimentale, e su quello non si negozia: quattro sale reali, geometria rilevata, materiali dichiarati, nessun parametro ritoccato per avvicinare la curva. Il fork FDTD ha avuto un ruolo, ed è un ruolo più modesto di quello che gli avevamo attribuito qui: durante lo sviluppo è servito come implementazione indipendente di uno schema numerico **diverso** — differenze finite su griglia, invece di Galerkin discontinuo su mesh — su cui incrociare i risultati del ramo d'onda. Un controllo incrociato, non un arbitrato. Ed è finito: il fork è stato **rimosso dalla pipeline a giugno 2026**, e oggi l'unico forward wave-based è dg-acoustics. Resta pubblico, con la licenza **MIT** e l'attribuzione a [Brian Hamilton](https://github.com/bsxfun/pffdtd) (University of Edinburgh, 2021), perché il lavoro che ci abbiamo fatto sotto il cofano sta meglio fuori: build per l'architettura reale della scheda, multi-GPU vero, iniezione delle sorgenti in batch, **schema numerico intatto** — a parità di input restituisce l'output di riferimento a precisione di macchina. La fisica è quella di Hamilton; noi abbiamo reso il calcolo pratico su hardware moderno. Codice, licenza e attribuzione sono sulla [scheda Open Lab](/open-lab/pffdtd/), come dev'essere. ## I numeri, con le virgolette giuste Il forward è stato validato su **quattro sale reali** del benchmark pubblico **BRAS** della TU Berlin — un dataset di stanze misurate, non un caso di laboratorio costruito ad arte. Il tempo di riverbero misurato è riprodotto **entro l'1,1 %** e l'**1,3 %**, nella banda centrale, e il pattern spaziale della chiarezza C50 correla con la misura a **+0,89 / +0,68**. Quel primo numero è il T60 analitico; la predizione indipendente, quella del ray-tracer, sulle stesse bande sta al **17,1 %** e all'**11,5 %**. Su questi numeri serve precisione, perché è facile dire una cosa più grossa di quella vera. L'1,1 % **non è una stima cieca** dei materiali e **non è una calibrazione**: i coefficienti di BRAS sono già noti, e quel confronto verifica che la pipeline — geometria, coefficienti, descrittori — sia **coerente a materiali noti**, **senza ricalibrazione**. È un'affermazione volutamente modesta: "dato il materiale, l'engine produce il descrittore giusto", non "abbiamo indovinato i materiali all'1 %". Chi lavora in *due diligence* riconosce subito la differenza, ed è la differenza che tiene. Il vero differenziatore, in ogni caso, **non è il forward**: il previsionale è la parte consolidata del dominio. È quello che viene dopo. Il **design inverso** position-aware sposta il risultato fino al 12 % scegliendo *quale* superficie trattare. E la **diagnosi di identificabilità**: su una delle sale BRAS l'engine ha rilevato che i dati **non** permettevano di recuperare tutti i materiali — due "direzioni cieche" — e l'ha **detto**, invece di restituire un numero non difendibile. Per un consulente, sapere *prima* che un dato non è stimabile vale quanto la stima stessa. ## Cosa significa, in pratica Questo non è un prodotto da scaffale: RaySound è un **motore proprietario**, un progetto di ricerca, non qualcosa che si scarica. È il tipo di competenza che ST-LINE porta dentro una **consulenza** di acustica delle sale. La differenza, per un committente, è fra un report che dice "il riverbero sarà 0,7 secondi" e uno che dice "sarà 0,7 secondi, ecco *quale* parete trattare per arrivarci, ed ecco dove i tuoi dati non bastano e te lo dico in faccia". In appalto, il secondo è un numero difendibile. Per chi vuole il dettaglio tecnico — equazioni, stencil, correzione dello staircasing, la tabella di confronto fra i due metodi e la validazione BRAS sala per sala — c'è la [wiki di RaySound](/wiki/raysound/). Lo schema numerico del fork, con equazioni e stencil, sta nella [sua nota tecnica](/wiki/pffdtd/).