Anche l’iPhone ha i suoi bug. Uno particolarmente fastidioso fa sì che l’icona dell’applicazione che gestisce gli SMS mostri sempre che ci sono uno o più messaggi da leggere, ma di fatto tali messaggi non compaiono nel’applicazione stessa, rendendo impossibile leggerli o eliminarli. Se ne parla, ad esempio, qui.

In realtà, il problema è facilmente risolvibile agendo manualmente sul database in cui vengono memorizzati i messaggi, che è un normalissimo database SQLite. Dato che questo può non essere alla portata di tutti, e siccome volevo divertirmi un po’ col Python appena installato sul mio iPhone, ho scritto un’applicazioncina che permette di risolvere il problema lanciando un singolo comando. Essa va sotto il fantasiosissimo nome di iPhone SMS Fixer, ed è disponibile per il download al seguente link: iPhone SMS Fixer.

Una caratteristica degna di nota è che l’applicazione può essere usata sia su un PC (con qualunque OS, essendo scritta appunto in Python) o sull’iPhone stesso, installando il pacchetto di Python attraverso Cydia. Il rovescio della medaglia è che serve per forza un iPhone jailbreakato.

Riporto uno spezzone del README in inglese, giusto per farmi indicizzare opportunamente da Google ;):

iPhone SMS Fixer – Fix wrong unread SMS count on an iPhone
===============================================================================
This program can fix a “corrupt” SMS database on an iPhone, which always
shows an unread message count of 1 (or possibly more). This issue seems to
happen quite frequently with the “missed call” SMS notifications sent by
Vodafone Italia and other operators. It seems present in all versions of the
iPhone firmware released so far (2.1 is the latest, at the time of writing).

Beh, è tutto. Ricordatevi di fare un backup del vostro telefono, e divertitevi :).

Stasera volevo ascoltare un veeeeecchio bootleg degli U2 procuratomi mediante trading moooooolto tempo fa. Prendo la custodia, la apro e… AAAAAAAAAAAARGH! La “vernice” del CD stava cadendo a pezzi, bucherellandosi qua e là! Al che faccio una rapida cernita dei miei bootleg e scopro che tutti i CD di quella marca stanno facendo la stessa fine!

Era da un po’, in realtà, che volevo controllare i miei bootleg di vecchia data, proprio per paura che finissero a questo modo, ma non ne avevo mai trovato il tempo. L’idea era quella di passarli tutti in un formato digitale lossless, in modo da poterli conservare facilmente, e anche di poterli condividere su qualcuno dei tanti siti di scambio bootleg. Si imponeva dunque un’anticipazione della procedura, almeno per quanto riguardava i CD problematici, al fine di salvare il salvabile.

Per il ripping ho ovviamente utilizzato hCDrip, ovvero il programmino Python che mi sono fatto da solo tempo addietro, che fa un po’ da frontend a cdparanoia e ai vari encoder MP3, FLAC, Shorten, ecc…, condendo il tutto con un po’ di supporto CDDB (Forse ne ho anche già pubblicato una versione, non ricordo! Al momento ha trovato qualche problema minore, ma prima o poi ne pubblicherò una nuova versione). Il formato che ho scelto è il FLAC, uno dei più diffusi e supportati.

Comunque, a parte questo, riascoltando uno dei bootleg salvati, mi sono accorto che l’audio era decisamente più lento del dovuto. Ovviamente questo si notava anche dal pitch, troppo basso. Era quindi il caso di sistemare il problema. E questo mi ha permesso di apprezzare un tool come sox che, unito alla potenza di una shell Unix, rende il lavoro rapido e indolore. Ecco come ho fatto:

for i in *.flac; do flac -d -c "$i" | sox -t wav - "$(basename "$i" .flac).wav" speed 1.07; done
rm *.flac
flac --best *.wav
rm *.wav

Tutto qua! Evito di spiegare ogni passo, dato che dovrebbe essere tutto abbastanza comprensibile. Aggiungo solo che il valore 1.07 l’ho trovato a tentativi, provandone di diversi e ascoltando il risultato.

A qualcuno interessa il concerto degli U2 di Werchter 1982? :)

Per la sempre maggiore gioia di NoKo, ieri ho deciso che volevo assolutamente vedere il video di It’s no good sul mio Nintendo DS.

Intanto, com’è possibile fare ciò, se il DS non ha uno slot per schede di memoria? Serve una cosiddetta Flashcart (in realtà in modo un po’ improprio), ossia una cartuccia in cui si inserisce una SD o simile, che permette poi di lanciare sul DS i programmi e giochi che si trovano su questa. Ce ne sono diversi modelli in giro: in particolare io ho una SuperCard Lite, che monta schede MicroSD/TransFlash.

Trovata una flashcart, serve un qualche media player. No problem: per DS c’è il buon Moonshell (LOL! Mentre scrivo questo hanno appena rilasciato una nuova versione :D), di cui, fra l’altro, sono disponibili i sorgenti completi.

Ora viene il difficile: infatti, mentre per quanto riguarda l’audio, Moonshell riproduce file OGG e MP3, per i video il programmatore si è inventato un formato tutto suo, che ha chiamato nDs-mPeG, per gli amici DPG. Si tratta in sostanza di video MPEG-1 e audio MPEG-2, rinchiusi in un container (che in realtà è un semplice header) assolutamente non standard che ha il seguente formato:

The header is 36 bytes. (Note: all of the numbers below are hexadecimal.)
44 50 47 30 (this stands for DPG0 in ASCII)
Four bytes for the number of frames in the video
00 00 00 00
Two bytes for the frames per second that the video runs
00 00
Four bytes for the audio sample rate
00 00 00 00
00 00 00 00 (this was the number of audio channels, now deprecated in favor of MP2 audio)
24 00 00 00 (this is the start of the audio file, i.e. right after the header)
Four bytes for the length, in bytes, of the audio
Four bytes for the above length + 36 bytes (i.e. the start of the video file)
Four bytes for the length, in bytes, of the video

Di nuovo, chi è interessato a vedere come concilare tutto ciò col solito ffmpeg, legga l’articolo intero! :)

Il primo passo consiste ovviamente nel rippaggio del DVD, di cui ho già parlato nel precedente articolo, e che quindi non ritratterò :). Dirò solo che il video proviene dal DVD del Best of Depeche mode uscito da poco.

Passiamo direttamente alla transcodifica: purtroppo ffmpeg non supporta questo strano container, quindi dovremo creare gli stream a parte e poi integrarli con l’header. È ora il caso di dire che molti hanno lamentato problemi di compatibilità di Moonshell con gli stream creati da ffmpeg, e consigliano di usare Mencoder, un programma simile a ffmpeg, addirittura creato dallo stesso team (e, in effetti, mi sfugge la necessità di avere 2 programmi diversi). Io non ne ho assolutamente avuti, forse perché nel frattempo Moonshell si è evoluto, e per questo presento il mio procedimento.

Data la fighezza di ffmpeg, possiamo addirittura creare i due stream contemporaneamente. La linea di comando è la seguente:

sukko@unholycathedral tmp $ ffmpeg -y -v 2 -i stream.dump -strict -1 -s 256x192 -b 256k -r 15 -flags +bitexact+mv0+trell+cbp -cmp 2 -subcmp 2 -precmp 2 -f mpeg1video nogood.mpg -ab 128 -ar 32000 -f mp2 nogood.mp2
FFmpeg version SVN-r7150, Copyright (c) 2000-2006 Fabrice Bellard, et al.
  configuration:  --prefix=/usr --disable-debug --enable-gpl --enable-mp3lame --enable-libogg --enable-vorbis --enable-faad --enable-faac --enable-libgsm --enable-xvid --enable-a52 --enable-pp --enable-shared --enable-pthreads --enable-amr_nb --enable-amr_wb --enable-x264 --enable-dts
  libavutil version: 49.1.0
  libavcodec version: 51.25.0
  libavformat version: 51.6.0
  built on Nov 22 2006 01:08:24, gcc: 3.4.6
Input #0, mpeg, from 'stream.dump':
  Duration: 00:04:17.3, start: 4112.417267, bitrate: 8227 kb/s
  Stream #0.0[0x1e0], 1/90000: Video: mpeg2video, yuv420p, 720x576, 1/25, 9800 kb/s, 25.00 fps(r)
  Stream #0.1[0xa0], 1/90000: Audio: pcm_s16be, 48000 Hz, stereo, 1536 kb/s
Output #0, mpeg1video, to 'nogood.mpg':
  Stream #0.0, 1/90000: Video: mpeg1video, yuv420p, 256x192, 1/15, q=2-31, 256 kb/s, 15.00 fps(c)
Output #1, mp2, to 'nogood.mp2':
  Stream #1.0, 1/90000: Audio: mp2, 32000 Hz, stereo, 128 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #1.0
Press [q] to stop encoding
frame= 3875 q=2.0 Lsize=    7936kB time=258.0 bitrate= 252.0kbits/s dup=4 drop=2578
video:7935kB audio:4031kB global headers:0kB muxing overhead -33.679230%

Avrete notato che ho usato alcune “nuove” opzioni, vediamole in dettaglio:
- -v 2: Fa sì che ffmpeg ci dia qualche informazione aggiuntiva sul quel che sta facendo. In particolare, ci servono i dettagli sul numero di frame che ha effettivamente codificato.
- -strict -1 -r 15: Sebbene distanti, queste opzioni sono correlate fra di loro. Infatti, -r serve a specificare il framerate (il numero di fotorgrammi al secondo). Ho usato 15 perché, purtroppo, il DS ha una potenza di elaborazione limitata, e non riesce a reggere framerate più alti. Pare che il massimo realmente utilizzabile sia 18, ma anche con 15 il risultato è decente. Ora, lo standard MPEG-1 non ammette un framerate a caso, ma solo quelli standard (tipo 25, lo standard PAL), e quindi ffmpeg si rifiuterebbe di creare un file MPEG-1 a 15 fps… non fosse per l’opzione -strict -1, che gli dice di non rompere le scatole e darci retta, perché sappiamo quel che stiamo facendo ;).
- -s 256x192 -b 256k: Ridimensionamento e bitrate: anche questi parametri non devono essere “esagerati”, per lo stesso motivo del punto precedente. Questi valori sono accettabili per la maggior parte dei casi.
- -flags +bitexact+mv0+trell+cbp -cmp 2 -subcmp 2 -precmp 2: Senza andare troppo nei dettagli, questi sono parametri “di qualità”. Li ho scoperti solo recentemente, e servono a migliorare la compressione, a leggero scapito della velocità. Consiglio di usarli sempre (anche nei casi che abbiamo visto in precedenza), perché la differenza si vede a occhio nudo (e soprattutto in questo caso, date le restrizioni sugli altri parametri).
- -ar 32000: Frequenza di campionamento dell’audio, conviene usare sempre questa per evitare incompatiblità.

Bene, abbiamo così ottenuto gli stream. Per unirli insieme serve un programmino particolare, DPG Maker, che trovate qui: DPG Maker. È uno script Python, quindi dovete averlo installato per utilizzarlo, ma solitamente si trova già installato su tutte le distribuzioni GNU/Linux. Si usa così:

sukko@unholycathedral tmp $ dpgmaker.py nogood.mpg 3875 256 15 nogood.mp2
Video file.....: nogood.mpg
Video frames...: 3875
Video bitrate..: 256
Video FPS......: 15
Audio file.....: nogood.mp2
Output file....: nogood.dpg
Creating nogood.dpg
Creating header
Removing temporary files
Done!

I parametri:
- 3875: È il numero di fotogrammi presenti nello stream video. Grazie al parametro -v 2 che abbiamo passato a ffmpeg, questo ce lo sputa direttamente fuori: è il primo numero della penultima riga, quello dopo frame=.
- 256: È Il bitrate dello stream video. Questo lo sappiamo per forza, dato che l’abbiamo passato a ffmpeg, dove però era seguito da una k.
- 15: È il numero di fotogrammi al secondo. Anche questo è noto, dato anche lo sproloquio di cui sopra :).

Eseguito questo comando, abbiamo finalmente il nostro bel nogood.dpg, che possiamo copiare sulla MicroSD e goderci tramite Moonshell, se abbiamo fatto tutto correttamente:

Per chi volesse fare il tutto più in fretta, esiste il buon DPG Converter: si tratta dello script Python che io ho riadattato per creare il DPG Maker di cui sopra. Esso si preoccupa dell’encoding (usando Mencoder) e della creazione dell’header, tutto da solo.

A questo punto… dove accidenti posso vedere il video di Personal Jesus? Aspetto idee :).