Simpaticamente, comunicare

Una delle cose che ci si aspetta da sistema operativo è che si comporti in modo prevedibile. O per lo meno che comunichi a lettere cubitali l'inserimento o la modifica di qualcosa che può non funzionare.

OK, edgy è la versione di sviluppo (non solo nel senso che non è ancora finalizzata, ma anche che è banco di prova delle ultime novità) e per un ambiente stabile c'è dapper, ma mi spiegate perché nelle note di rilascio della Beta, accanto a "Hey, guarda che abbiamo tolto di mezzo il vecchi init" non c'è scritto "Hey, guarda che /bin/sh non è più un collegamento alla bash"?

OK, c'è la specifica DashAsBinSh che indica motivi e altro, ivi compreso il fatto che è già stata confermata la sua POSIX compliant da Debian.

Però la shell è un componente essenziale del sistema, non tanto per le console (o terminali) degli utenti, che comunque sono ancora bash per le funzionalità offerte nell'utilizzo interattivo, quanto per tutta quella serie di script che si possono avere per l'automatizzazione di una serie di compiti (backup in primis). La shell dash è sicuramente un buon prodotto, non sarò certo io ad afffermare il contrario basandomi su dati inesistenti, ma chi si scrive uno scrip non lo fa leggendo lo standard POSIX, ma il manuale inline e quello online della bash (e tutti i vari tutorial, guide definitive, trip&tricks e via dicendo). Magari, nel corso degli anni, a qualcuno è scappata una opzione bash-only in uno script che comincia per #!/bin/sh

La disponibilità immediata e rapida di una "base di conoscenze" è fondamentale in progetti di ampio respiro. Se un qualche script utente dovesse fallire dopo il passaggio da dapper a edgy sarebbe utile avere un articolo, una nota, un brogliaccio da qualche parte che dica "Hey, sappiamo già cosa è successo".

A proposito di base di conoscenze: se avete attivato il profilo per la codifica di MP3 in GNOME come consigliato dal manuale utente di Sound Juicer, fate attenzione al bitrate impostato. Se non sapete di cosa sto parlando, allora spiego tutto dal principio.

GNOME fornisce delle chiavi GConf per la definizione di profili audio da usare nel ripping dei CD audio. Ogni profilo corrisponde a una serie di chiavi che specificano, ciascuna, se il profilo è attivo, il nome, la descrizione, l'estensione del file risultante e, cosa importante, la pipeline di GStreamer da usare per effettuare l'encoding. Le trovate in /system/gstreamer/0.10/audio/profiles e le potete modificare con una più o meno comoda interfaccia nelle preferenze di Sound Juicer.

Con i plugin giusti, quindi, oltre ai formati predefiniti, è possibile realizzare anche file MP3. La pipeline da usare è indicata nel manuale di Sound Juicer. C'è però un problema. Il plugin di lame accetta delle opzioni, praticamente le stesse offerte dal programma a riga di comando (per conoscere tutte le opzioni del plugin eseguire 'gst-inspect-0.10 lame'). Ora, la vecchia versione del manuale riportava questa configurazione

... ! lame name=enc bitrate=192 vbr=0 ! id3mux

La nuova versione riporta invece

... ! lame name=enc bitrate=196 vbr=0 ! id3v2mux

Un miglioramento, direte, visto che usa il nuovo plugin per i tag ID3 e aumente un po' il bitrate. Sì, peccato solo che il plugin lame fallisce l'inizializzazione con valori di bitrate diversi da quelli standard (128 e 192 funzionano, altri non ne ho provati). Per testare il funzionamento o meno di un valore provate il seguente comando, invece di provare il ripping di un cd

gst-launch-0.10 audiotestsrc ! audioconvert ! lame bitrate=192 ! fakesink

Se la pipeline non restituisce errori (e rimane quindi in esecuzione) allora il valore di bitrate è "buono". Ovviamente il cambiamento id3mux --> id3v2mux è altamente consigliato (non so però in quale tra i vari pacchetti di GStreamer si trovi).