FabrizioMondo.com

Settantacinquesimo articolo dedicato alle web radio

Questo articolo potrebbe risultare leggermente fantascientifico, ma in realtà non risulterà esserlo affatto.
Cominciamo a discutere e valutare la possibilità, di idealizzare, cercare e perchè no creare un parser audio, o quantomeno, di andarci molto vicini.

Secondo Wikipedia:

Il parsing o analisi sintattica è il processo atto ad analizzare uno stream continuo in input (letto per esempio da un file o una tastiera) in modo da determinare la sua struttura grammaticale grazie ad una data grammatica formale. Un parser è un programma che esegue questo compito.

Considereremo vari casi nella studio del parsing audio applicato alle web radio, cominceremo dividendo dicotomicamente il problema di studio:

Vedremo che le cose non sono poi cosi diverse, ma vanno valutate separatamente.

Un file audio digitalizzato non compresso è composto, come abbiamo già visto tempo addietro da una frequenza di campionamento, una risoluzione ed un numero di canali.

Possiamo quindi esprimere in sintassi XML un file audio in un primo modo:

<brano>
<titolo>Titolo Brano</titolo>
<infoAggiuntive>Informazioni Aggiuntive</infoAggiuntive>
<canale>
<campione>
<id>ID</id>
<risoluzione>Risoluzione</risoluzione>
</campione>
</canale>
</brano>

In questo modo è rispettata una struttura gerarchica che riproduce esattamente il contenuto di un file audio.

Un file audio, normalmente, ovvero per la maggior parte dei generi musicali, ha una struttura LOGICA di questo tipo:

<brano>
<intro>introduzione</intro>
<strofa>strofa</strofa>
<refrain>refrain</refrain>
<strofa>strofa</strofa>
<outro>Outro</outro>
</brano>

Tale struttura divide il file in parti, ovvero l’introduzione, il ritornello, le strofe e l’uscita.

Combinando le due rappresentazioni è possibile effettivamente creare una struttura gerarchica suscettibile al parsing ad opera di un parser, che potrebbe quindi strutturare un file audio dato in input.

Passando dai file alle web radio, il discorso non cambia molto.

Si potrebbe benissimo considerare una web radio alla stregua di un brano, ottenendo ad esempio:

<flusso>
<brano>NomeBrano</brano>
<Vocal>InterventoVocale</vocal>
<brano>NomeBrano</brano>
</flusso>

Oppure la stessa programmazione:

<webradio>
<Day>
<hour>
<programma>Nomeprogramma</programma>
</hour>
</day>
</webradio>

e così via…

Abbiamo già parlato di un programma che segmentava l’input di una web radio in parti in base a dei pattern, tale programma si chiama streamripper.

In quel caso il discrimen è dato dal volume, che può essere preso come delimitatore di sezione all’interno del secondo modello di parsing.
Si può passare dal campo intro al campo strofa in base ad un superamento di soglia di volume prefissata, oppure esattamente all’inizio della parte vocale, quindi in base ad un controllo del timbro o delle frequenze in gioco.

La trasposizione in linguaggio XML di un brano non è un puro esercizio matematico fine a se stesso.

Alcune sue applicazioni, oltre allo stesso streamripper, possono essere Tunatic e Midomi, di cui parleremo in prossimi articoli.

Il primo programma riconosce titolo e autore di un brano semplicemente ascoltandolo, mentre il secondo tenta di riconoscere i dettagli di un brano, quando viene cantato. Sono per lo più applicazioni da cellulare, per chi non riesce a trovare un titolo di un brano sentito alla radio.

Tuttavia queste applicazioni, applicate a stream digitali quali ad esempio le web radio o le radio fm stesse, consentono di controllare in modo proporzionale alla precisione dell’algoritmo di riconoscimento dei brani, se una radio ha difformità tra i tracciati cartacei e il flusso, ad esempio nella reportistica siae.

Ho effettuato un controllo a tappeto della web radio che ascolto più spesso (radio mela) e della radio in fm in cui ho lavorato più recentemente (dabliuradio)

In entrambi i casi i risultati sono stati soddisfacenti ma non perfetti. Spesso la mia memoria ha vinto su tunatic, ma altrettanto spesso è accaduto il contrario.