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
1 Comment »

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 »

Settantaquattresimo articolo dedicato alle web radio

Continuiamo il nostro excursus attraverso l’hardware necessario per strutturare degnamente una web radio, argomento di questo articolo sono i mixer.

Un mixer è un apparecchiatura che di base effettua una miscelazione, ovvero una emissione contemporanea di due o più strumenti musicali (intesi in senso lato, teoricamente qualsiasi attrezzo che sia in grado di generare onde sonore).

Tale strumento, fondamentale per una radio che effettui interventi vocali o strumentali live, è rappresentabile in questa immagine:

Le sorgenti etichettate con S, possono essere rappresentative di tutto, dai microfoni, a strumenti musicali qualsiasi, come precedentemente detto. L’anello di congiunzione tra le sorgenti e il mixer stesso è detto connettore, e ne abbiamo già parlato.

Tra i tre connettori di cui abbiamo parlato è sempre meglio optare per XLR in quanto bilanciato, ma il bilanciamento non è esattamente argomento di questo articolo, e la sua trattazione è rinviata ai commenti, o ad un altro articolo.

Approfondiamo allora il processo di percorso di un segnale (che in generale è una qualsiasi funzione dipendente dal tempo) all’interno di un mixer, e per farlo, approfitto a piene mani di chi ne sa qualcosina meglio di me, in fatto di mixer e attrezzature audio.

Tra gli stadi di ingresso abbiamo:

Il primo stadio, chiamato (1) in figura, è un amplificatore operazionale e rappresenta il primo stato in assoluto di qualsiasi mixer, generalmente il primo con guadagno o amplificazione significativi.

Il secondo stadio, chiamato (2) in figura, è un equalizzatore e per questo si rimanda alla pagina di wikipedia apposita, io posso anticiparvi che è principalmente uno strumento che consente di incrementare o decrementare l’ampiezza di componenti in frequenza desiderata di un segnale.

Il terzo stadio, chiamato (3) in figura, è un fader, collegato ad un LED picco di canale, rappresentanti uno dei migliori strumenti per il controllo di guadagno di un canale.

Tra gli stadi della sezione master abbiamo:

Il primo stadio, chiamato (4) in figura, è il mixaggio vero e proprio, composto da un sommatore di segnale, che mixa, appunto, tutti i segnali dei vari canali, qualunque cosa essi rappresentino.

Il secondo stadio, chiamato (5) in figura, è invece un altro fader, chiamato fader master, antecedente l’output del mixer.

Per tutto quello che riguarda l’ottimizzazione dell’audio e il miglioramento dell’output del mixer, consiglio la lettura del manuale da cui questo articolo è nato, ovvero questo.

Continuiamo invece trattando un caso specifico, ovvero vediamo cosa sono i vari componenti e le varie parti di un mixer, il mixer MG16/6FX.

Esaminiamolo parte per parte:

La prima manopola rappresenta il cosiddetto GAIN, o guadagno e regola il livello del segnale di ingresso.

Il rilevatore PEAK si accende quando il livello del segnale sale fino ad essere 3dB inferiore al livello di saturazione del segnale. E’ un potenziale campanello d’allarme.

Il pulsante 80 attiva il filtro passa alto con frequenza di taglio pari ad 80 hertz.

Questa fila di manopole rappresenta invece l’equalizzatore. Consentono di regolare l’ampiezza della porzione di frequenze interessate dalla manopola. Sono divise in alti (frequenza base 10 Khz), medi (frequenza base regolabile da 250 a 5000 Hz) e bassi (sotto i 250 Hz).

Le due manopole AUX regolano il segnale che viene inviato ai canali ausiliari. Il tasto PRE permette di scegliere se inviare al canale ausiliare 2 il segnale in pre o post fading.

La manopola EFFECT regola il livello del segnale inviato al bus effetti.

La manopola PAN|PAN/BAL|BAL regola il posizionamento del canale sui canali gruppo o bilancia il segnale nel caso in cui ci si occupasse di un ingresso stereo in un canale stereo.

Abilita il canale al missaggio.

Il PreFader Listen button serve ad abilitare il monitoraggio (effettuato tramite output ai jack phones e c-r out). Il segnale viene trasmesso pre-fading.

I pulsantini 1-2 e 3-4 abilitano il canale alla trasmissione ai bus group corrispondenti, che avviene A PRESCINDERE dallo stato del tasto ST.
Il fader invece serve per regolare il livello generale di segnale del canale.

Categories: Web Radio
No Comments »