Settantasettesimo articolo dedicato alle web radio.

Cominciamo le guide avanzate dedicate ad icecast su linux, studiando i file XML di esempio che vengono forniti a corredo con ices2.

E’ chiaro che il server icecast può non essere utilizzato necessariamente con ices2, ma in questo caso, risulta secondariamente necessario alla trasmissione (quantomeno per passare da un livello amatoriale ad uno semi-professionale) conoscere e sapere manipolare i file di configurazione, che in questo caso sono del tipo Extensive Markup Language.

Il primo di questi file che considereremo è quello dedicato allo streaming da ALSA. Alsa sta per Advanced Linux Sound Architecture e contraddistingue in questo caso una modalità di streaming improntata sul live o sull’ingresso della scheda audio, ad esempio un banale simulcasting.

Andiamo quindi a considerare le parti di questo file, che è meglio ricordare, si trova in /usr/share/doc/ices2/examples

La prima parte del file è questa:

Il tag background va settato ad 1 se si vuole porre ices in background.

Il tag logpath identifica una directory che può essere scritta dall’utente che ices2 sta identificando. Può essere piazzata ovunque, ma chiaramente devono essere abilitati i permessi di scrittura.

Il tag logfile identifica il nome del file di log. Alla riapertura del log file l’esistente viene rinominato come “logfile”.1

Il tag logsize indica la massima grandezza del file di log prima di andare in modalità ciclica di scrittura.

Il tag loglevel Indica un numero che rappresenta il livello di logging prescelto.
1 – Loggati solo i messaggi d’errore
2 – Come il punto uno, ma anche i Warnings verranno loggati
3 – Come il punto due, ma anche i messaggi informativi verranno loggati.
4 – Come il punto tre, ma anche i messaggi di debug verranno loggati.

Il tag consolelog, se impostato ad 1 causa l’apparizione dei messaggi loggati in console, piuttosto che in un log file.

Nelle applicazioni più sensibili al ritardo (tra cui OVVIAMENTE una radio), è sconsigliato avere logging in console. E’ un opzione utile in fase di studio del software.

Il tag pidfile consente di creare un file in cui è scritto il ProcessID del processo ices2 corrente.

Veniamo adesso alla sezione stream.

La sezione stream è composta da tre sottoparti, chiamate metadata, input e instance.

Esaminiamole tutte e tre nel dettaglio.

Metadata intuitivamente si capisce già su cosa abbia influenza, ovvero si occupa di trasmettere tutti i dati a corredo della trasmissione stessa.

Le sue sottoparti sono nome, genere, descrizione e url, esattamente gli stessi campi che si trovano in generale nei server shoutcast, ma in realtà praticamente in tutti.

Input invece tratta la parte hardware della trasmissione, vediamo come.

Module, ci indica di scegliere quale modulo hardware stiamo trattando, qui si parla di alsa, per cui scriviamo alsa.

I successivi parametri sono rate, channels, device e i metadata.

Rate indica la frequenza di campionamento del segnale analogico di partenza. E’ normalmente settata a 44100 hertz, se non sapete come mai, vi invito caldamente a leggere il teorema divino.

Channels indica se vogliamo una trasmissione mono o stereo.

Device indica la posizione della scheda audio nell’elenco delle periferiche del nostro sistema.

Metadata e metadatafilename rappresentano uno switch di scrittura e un nome file dove vengono scritti i metadati.

Istance rappresenta la generica istanza di trasmissione. Dico “generica” in quanto, se conoscete il software di cui stiamo parlando, o avete letto altri articoli (non per forza di questo blog) su ices2, saprete che è un source multi-instanziabile, ovvero ha la possibilità di trasmettere, a differenza di molti software per shoutcast ad esempio, lo stesso stream a più server contemporaneamente.

hostname indica l’indirizzo ip del server da contattare, può essere sia un ipv4 che ipv6.

port indica la porta del processo sul server da contattare, vi ricordo che si comunica in tcp.

password non necessità spiegazioni

mount, identifica il cosidetto mountpoint, ovvero un particolare stream in un singolo server icecast, che può trasmettere più stream contemporaneamente.

yp è uno switch che abilita o disabilita la visione pubblica dell’emittente.

La sezione Encode indica i parametri di codifica dello stream, che devono matchare chiaramente quelli impostati in hardware nella sezione precedente.

Il tag downmix è uno switch che indica se, in caso di necessità, si preferisce diminuire il numero di canali da due ad uno, ovvero passare da stereo a mono.

La sezione Resample definisce la frequenza in hertz a cui passare in caso ad esempio di problemi di rete. Tipicamente si preferisce passare ad un valore pari alla metà della frequenza di partenza. Ricordatevi sempre che sempre per il teorema divino, se volete ricostruire senza aliasing un segnale che ha banda N hertz, avete bisogno di una frequenza di campionamento NON INFERIORE a 2N hertz. Quindi avere 22050 hertz di frequenza di campionamento, consente di sentire discretamente una banda di 10000 hertz. Sufficiente per il parlato ma non certo per la marcia turca di mozart.

Con questa sezione finisce la parte alsa, vedremo nei prossimi articoli di considerare anche le altre opzioni possibili, ovvero OSS e una playlist.

Categories: Web Radio
No Comments »

Settantaseiesimo articolo dedicato alle web radio

Carissimi internauti vi ricordate di questo articolo?

In quell’articolo si parlava di Icecast, un server di streaming rilasciato con licenza GPL e che permette lo streaming audio/video dei file Ogg, sia Vorbis che Theora. Lo abbiamo introdotto in ambiente windows, adesso, vedremo di parlarne anche in ambiente linux.

Cominceremo dall’inizio, ovvero dall’installazione dei componenti fino all’effettiva messa in onda della radio. Successivamente, in una guida avanzata, procederemo a vagliare e valutare tutte le possibili opzioni. Per adesso, mettiamo in moto la nostra radiolina linuxiana.

Supponiamo di lavorare su una debian-based

Una volta installati i due programmi, effettuiamo una modifica al file /etc/default/icecast2 tramite un qualsiasi editor di testo modificando il parametro ENABLE, da false a true. Ciò permetterà di potere effettuare la prossima operazione.

Facciamo partire il nostro server icecast2 tramite il comando:

Potremo quindi trovare l’interfaccia web, comprensiva di pannello di amministrazione, all’indirizzo http://localhost:8000
Studieremo successivamente le peculiarità web di questo server di streaming,

In questo momento abbiamo il nostro server di streaming funzionante (almeno in locale) e possiamo cominciare a lavorare su ICES2.

Ices2 è:

usato per fornire a server audio streaming Icecast2 flussi
audio Ogg Vorbis. Supporta sia input audio live dalla scheda audio, sia la
ricodifica di file Ogg Vorbis da una scaletta.

Creiamo tre cartelle da terminale:

La prima servirà a contenere i log, la seconda servirà invece a contenere i file di configurazione mentre la terza conterrà i file musicali.

All’interno della cartella /usr/share/doc/ices2/examples/ si trovano tre files:

I tre files corrispondono alle tre modalità di streaming, ovvero tramite ALSA (Advanced Linux Sound Architecture) oppure OSS (Open sound system) oppure tramite una playlist di file OGG, che è il caso che tratteremo in questa guida basilare.

Copiamo il file ices-playlist.xml all’interno della cartella /etc/ices2 ad esempio con il comando

a questo punto dobbiamo verificare che vi sia matching perfetto tra la password impostata su ices2 e quella del server icecast, come del resto avviene per qualsiasi accoppiata, encoder/server.

La password del server di streaming icecast2 si trova nel file /etc/icecast2/icecast.xml alla sezione AUTHENTICATION.
La password da impostare in ices2, che deve chiaramente essere uguale a quella (per adesso di default) del server icecast2, è nella sezione INSTANCE del file ices-playlist.xml.

Penseremo a tutti i parametri opzionali (tra cui anche la modifica delle password) nella guida avanzata. Per adesso il nostro unico obiettivo è quello di mettere (almeno localmente) la radio in trasmissione.

Dopo avere controllato la corrispondenza tra le password passiamo al riempimento della cartella music, precedentemente impostata con i file ogg vorbis che ci interessa trasmettere.

Una volta riempita la cartella music, creiamo il file playlist.txt all’interno della cartella /etc/ices2 e scriviamo una riga per ciascun file OGG che dobbiamo trasmettere, con tanto di PATH completo.

Una volta creato il file, startiamo ices2 con il seguente comando:

In questo modo il server icecast avrà come mountpoint il flusso creato da ices2.

Categories: Web Radio
2 Comments »

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.

Categories: Web Radio
No Comments »