Voxtrama

Che fine fa l'audio

L'audio non esce mai dal tuo computer. Una registrazione caricata in Voxtrama fa questo percorso, dall'inizio alla cancellazione.

La retention è spenta in modo predefinito, quindi una registrazione resta sul disco finché non la cancelli tu o non imposti un limite di 7, 30, 90 o 365 giorni. Clean up rimuove da sola le registrazioni che nessun job usa, caricate da almeno una settimana.

Perché ho scritto Voxtrama

L'idea è nata durante una riunione di lavoro importante, registrata per farne il verbale. Gli strumenti che conoscevo chiedevano di caricare l'audio sul loro servizio, e dalle loro pagine era difficile capire su quale server sarebbe finito e con quale licenza. Volevo un sistema che funzionasse anche senza connessione a internet, con tutto il necessario per far girare Whisper dentro un container.

Oggi uso Voxtrama sulle mie call di lavoro. Seguo la riunione senza prendere appunti, e a fine chiamata ho i punti salienti e le decisioni già estratte. L'obiettivo di partenza era preciso: riassumere registrazioni di diverse ore con modelli piccoli, da 7 miliardi di parametri, che girano su un computer qualunque.

Voxtrama serve a chi registra conversazioni su cui deve decidere o studiare e preferisce tenere l'audio in casa: un gruppo di lavoro che tiene i verbali, chi fa ricerca con le interviste, uno studente che riascolta una lezione. Per un ufficio pubblico o uno studio professionale il GDPR rende la stessa domanda un obbligo.

Dall'audio al verbale: che cosa succede a una registrazione

Una registrazione attraversa quattro passaggi, tutti sulla stessa macchina.

1. Pulizia dell'audio. Un filtro passa-alto, la riduzione del rumore e un volume uniforme

preparano il file alla trascrizione.

1. Trascrizione. faster-whisper trascrive sul processore, con tre profili: small, medium e

large-v3.

1. Separazione dei parlanti. Il modello ECAPA-TDNN di SpeechBrain distingue le voci dentro la

registrazione. Nella scheda Speakers dai un nome a ogni voce, ne ascolti il primo minuto, aggiungi un parlante sfuggito e sposti una singola frase a chi l'ha detta davvero.

1. Riassunto. Un modello linguistico servito da Ollama, sulla stessa macchina o su un server

che scegli tu, scrive il riassunto secondo il workflow scelto.

Accetta file WAV, FLAC, MP3, M4A e OGG. Più file si possono unire uno dopo l'altro, oppure trattare come microfoni diversi della stessa riunione.

Perché ogni punto del riassunto cita la registrazione

Ogni punto che il modello scrive deve portare una citazione della trascrizione, e Voxtrama la cerca nel testo parola per parola, uniformando soltanto maiuscole e spazi. Se la trova una sola volta, collega il punto al parlante e al minuto: un clic e ascolti il passaggio. Se la citazione manca, o compare in più punti, il punto resta visibile con l'etichetta Needs review.

Ho scelto il confronto esatto perché un confronto più largo accetterebbe una parafrasi del modello, ed è nella parafrasi che un riassunto si allontana da ciò che è stato detto. Un punto segnato si corregge a mano, o si collega al turno di parola giusto, e da quel momento porta l'etichetta Edited. Il testo originale del modello resta salvato a parte. Il meccanismo è spiegato per intero nell'articolo sul verbale verificabile.

I workflow: la finalità del riassunto

Un workflow dice a Voxtrama che cosa estrarre da una registrazione. La versione Community ne porta tre, più la sola trascrizione:

Un workflow è un file YAML, e funziona come una skill: la stessa call diventa un verbale di decisioni o una mappa dei temi a seconda del workflow e del modello che lo esegue. Per aggiungerne uno basta scriverlo, senza toccare il codice. Nella versione Community puoi definirne uno tuo accanto ai tre di serie, per esempio un verbale con la struttura richiesta dal tuo ufficio.

Ore di audio con un modello piccolo

Voxtrama legge una trascrizione lunga a finestre di circa 12.000 caratteri, due alla volta, e passa a ciascuna un tratto della precedente e della successiva perché il filo del discorso regga. Una risposta già data dal modello resta salvata: se una chiamata fallisce, al nuovo tentativo chiede solo le finestre mancanti. Ogni chiamata ha un tetto di 1.800 secondi, tarato su una misura reale: 33 minuti di processore per riassumere una call di 59 minuti.

Ogni job lascia una traccia

Per ogni job Voxtrama scrive un file manifest.json con i modelli usati, le impostazioni e il file di partenza. Da lì il job si rigenera con un altro modello o altre impostazioni, e i passaggi con gli stessi input vengono riusati invece di ripetuti. Il comando voxtrama compare confronta due job e riporta solo le differenze che contano: un altro modello, altre impostazioni, un altro file.

Il riassunto si esporta in PDF, HTML e DOCX. Il manifest scaricato sostituisce con [removed] il contesto e gli indirizzi dei server, mentre la copia nella cartella dei dati li conserva.

Che cosa esce in rete, e quando

Nessuna parte del codice spedisce il file audio fuori dalla macchina. In rete escono soltanto due cose, in due momenti precisi.

Per non far uscire niente basta tenere Ollama sulla stessa macchina. Se configuri un server remoto, a quel server arriva il testo della trascrizione, mai l'audio; la pagina Settings › Data & privacy mostra passo per passo dove gira ogni workflow, e un passo marcato local_only rifiuta i server remoti.

L'ho verificato il 30 settembre 2026 sui log di tre job eseguiti su giorgioserver. Il primo ha scaricato i due modelli e ha contattato huggingface.co tre volte, tutte per il download. Gli altri due job, con i modelli già sul disco, hanno contattato zero server esterni; il riassunto è andato all'Ollama della stessa macchina.

Il codice registra anche un difetto già corretto: il modello dei parlanti, pur essendo sul disco, interrogava huggingface.co quattro volte a ogni job per controllare i propri file. Nessun audio usciva, ma usciva l'informazione che quella macchina stava usando quel modello. Oggi il caricamento del modello avviene in modalità offline, e un test verifica che resti così.

Le altre protezioni stanno nel codice:

• l'applicazione risponde soltanto su 127.0.0.1 e rifiuta le richieste con un nome host o

un'origine diversi, anche contro il DNS rebinding;

• una credenziale per il server del modello viaggia solo in https o verso la stessa macchina;
• le versioni dei modelli scaricati sono fissate, perché SpeechBrain costruisce oggetti a partire

dal file di configurazione del modello;

• la retention cancella i job conclusi dopo 7, 30, 90 o 365 giorni.

La separazione dei parlanti vale per una registrazione alla volta: la stessa persona, in una call successiva, è di nuovo una voce senza nome. È una scelta. Un'impronta vocale è un dato biometrico, e conservarla trasformerebbe uno strumento di trascrizione in un sistema di identificazione. Per la stessa ragione Voxtrama lavora solo su file che hai già, e lascia alle piattaforme video i loro contenuti.

Due scelte che ho fatto in partenza

Voxtrama arriva senza un modello di riassunto predefinito. Un modello scelto da me diventerebbe, di fatto, una raccomandazione, e la scelta giusta dipende dalla macchina e dalla lingua delle registrazioni. Al primo avvio Voxtrama cerca Ollama sulla macchina, elenca i modelli che ci trova, e scegli tu.

Allo stesso modo Voxtrama misura la macchina e propone il profilo di trascrizione e quanti core dedicare a ogni blocco di audio, ma applica la proposta solo dopo la tua conferma. Un profilo sbagliato fa sembrare lento il prodotto, e chi conosce la propria macchina decide meglio di una stima.

Com'è costruito

I container sono la coda Redis, una migrazione del database che parte una volta sola, il server web e il worker che esegue i job. Tutto ciò che Voxtrama conserva sta in una cartella dell'host, ~/Voxtrama in modo predefinito: registrazioni, risultati, modelli, database e impostazioni.

Come l'ho rilasciato

Il 28 settembre 2026 ho pubblicato la 0.1.0-alpha1, la prima versione pensata per essere installata da qualcun altro. Il giorno dopo è uscita la 0.1.0-alpha2, con quattro correzioni trovate usando Voxtrama su registrazioni reali. La più pesante riguardava la trascrizione: su una macchina con venti processori, un job impostato su quattro core e due blocchi decodificava con quattro thread soltanto, perché il secondo blocco veniva preparato e poi restava fermo.

Rami e tag seguono il modello dei progetti di drupal.org, lo stesso che uso per i miei moduli Drupal: un ramo di sviluppo per serie, 0.1.x, e tag che dichiarano la stabilità, da alpha a rc fino alla release.

Stato del progetto

Voxtrama è un'alpha. L'ho provato con Docker su un iMac Pro del 2017 con processore Intel e, il 30 settembre 2026, su un server Linux con un Ryzen 9 9950X: lì 30 minuti di audio hanno richiesto 10 minuti e 40 secondi, dalla trascrizione con large-v3 fino alle decisioni. Il prossimo passo è farlo girare su altri sistemi operativi. Fino alla 1.0 un aggiornamento può cambiare il formato dei workflow e dei job salvati, e le note di rilascio lo dicono. Mancano ancora le misure automatiche che impediscono a una release di peggiorare la qualità. L'interfaccia è in inglese e il codice è già pronto per le traduzioni: aspetto i primi riscontri d'uso per scegliere le lingue.

Se lo provi, i riscontri mi servono sulle issue del repository.

Fonti

Tutte le fonti sono state consultate il 30 settembre 2026.

• Voxtrama su GitHub (si apre in una nuova scheda): README, licenza, requisiti, workflow, rami e tag. Fonte primaria.
• Changelog di Voxtrama (si apre in una nuova scheda): contenuto della 0.1.0-alpha1 e le quattro correzioni della 0.1.0-alpha2. Fonte primaria.
• Release di Voxtrama (si apre in una nuova scheda): 0.1.0-alpha1 del 28/09/2026 e 0.1.0-alpha2 del 29/09/2026. Fonte primaria.
• Guida alla pagina del job (si apre in una nuova scheda): Needs review, correzione di un punto, esportazioni. Fonte primaria.
• Riga di comando (si apre in una nuova scheda): doctor, run, compare, retention. Fonte primaria.
• Profilo di tuning generico (si apre in una nuova scheda): 33 minuti di processore per una call di 59 minuti, tetto di 1.800 secondi. Fonte primaria.
• Test sulle richieste a Hugging Face (si apre in una nuova scheda): le quattro richieste per job registrate prima della correzione, e il controllo che il modello dei parlanti resti offline. Fonte primaria.
• Caricamento del modello dei parlanti (si apre in una nuova scheda): la modalità offline forzata una volta scaricato il modello. Fonte primaria.
• Log dei job eseguiti su giorgioserver il 30/09/2026: richieste a huggingface.co solo nel job che ha scaricato i modelli. Misura dell'autore.
• SECURITY.md (si apre in una nuova scheda): ascolto su 127.0.0.1, controllo di host e origine, credenziali. Fonte primaria.