Levysoft
  • Home
  • Portfolio
  • WordPress Plugin
  • Contattami

Dal 2004 il blog di Antonio Troise

RSS FeedTwitterFacebook
Mar 6 2009

Tutti i vantaggi del nuovo formato di archiviazione XAR

Posted by Antonio Troise
Tweet

Stavo aggiornando all’ultima release stabile BetterZip, un’ottima e completa utility per Mac per la gestione di archivi compressi, quando, tra le note del changelog leggo che è stato introdotto il supporto agli archivi di tipo XAR.

Furthermore, XAR archives (the format of the new Leopard installer packages) are now first-class citizens in BetterZip, i.e., you can open, extract, and create XAR archives.

Francamente non ero a conoscenza di questo nuovo formato, anche perché è stato introdotto solo recentemente nel 2006 e il primo sistema operativo ad adottarlo ufficialmente è stato Mac OS X Leopard per i suoi installer packages.

Caratteriche

L’acronimo XAR sta per eXtensible ARchive format, e altro non è che un formato di file che può contenere altri file (proprio come il TAR) e sta ad indicare una tipologia di archiviazione di nuova concezione che offre numerosi vantaggi rispetto agli altri formati come la facile estrazione di dati arbritari, metadata all’inizio del file ed estensibilità.

Infatti, questo formato ha una particolarità non indifferente: i file contenuti in un archivio XAR sono compressi singolarmente e ciò permette un’estrazione veloce di file individuali, non richiedendo, quindi, l’uso di ulteriore spazio su disco e un utilizzo maggiore della CPU necessario per estrarre l’intero archivio, come accade, invece, ad esempio con un archivio TAR.

Ecco, quindi, spiegato perché il formato di archiviazione XAR è stato adottato da Leopard: per come è stato progettato, XAR è molto utile per un veloce ripristino di file cancellati o sovrascritti accidentalmente da un archivio di backup.

Inoltre, cosa non indifferente, vi è anche la possibilità di usare differenti metodi di compressione per ogni file dell’archivio. Per esempio, si potrebbe adottare, per un file di grandi dimensioni, la compressione bzip2, mentre per un piccolo file di testo potrebbe convenire la compressione gzip.

Infine, ogni archivio XAR, è costituito da 3 parti:

Xar Data Structure
  1. Header binario: contiene informazioni circa il documento XML, tipo se il file è compresso, qual è il suo hash, quale algoritmo di hash è stato usato, etc.
  2. Documento XML (TOC: Table Of Contents): è la parte importante poiché contiene tutte le informazioni sui file contenuti nell’archivio. L’uso dell’XML permette al formato di essere molto estensibile e di poter essere gestito dagli strumenti software già esistenti tramite piccole modifiche degli stessi.
  3. Heap (il “mucchio” in inglese): contiene file compressi singolarmente e altri dati (come attributi, resource forks, etc.) che si susseguono linearmente. L’offset, la lunghezza e il tipo di compressione usati per immagazzinare il singolo file nell’heap sono contenuti nell’header del file XML.

Questa struttura flessibile permette, come potete intuire, di gestire informazioni aggiuntive e arbitrarie dei file contenuti (metadati) come i tag dei file MP3 o informazioni EXIF in un file JPEG. Addirittura potrebbe essere possibile immagazzinare un interprete di script o delle librerie, direttamente dentro al singolo file dello script.

Come avete visto, le caratteristiche peculiari del formato XAR lo rendono uno strumento davvero unico, una piattaforma conveniente su cui costruire strumenti come un formato di packing.

Altre risorse su internet

Se siete convinti come me, che, prima o poi, questo formato di archiviazione si diffonderà molto velocemente, potete approfondire il discorso leggendo l’articolo di Rob Braun: Why xar is interesting e scaricare i sorgenti dal sito di Google Code che ha dato una casa al progetto XAR che rischiava di perdersi dopo la chiusura di OpenDarwin.org nel 2007 (è possibile ancora trovare un mirror della storica comunità della piattaforma Darwin) che si è nel frattempo trasformata in PureDarwin.

Tag:archiviazione, compressione, gzip, tar, xar, zip
CONTINUE READING >
9 comments
Gen 13 2009

Codec Cappelli: il rivoluzionario sistema di compressione di foto e video made in Italy. Dubbi e riflessioni sulla sua possibilità di diffusione

Posted by Antonio Troise
Tweet

Ieri è stato presentato a Roma nella sala capitolare del Senato un nuovo codec per la compressione digitale made in Italy: lo standard di compressione “Cappelli” (in omaggio al suo ideatore Claudio Cappelli che è anche presidente della società napoletana Eco Controllo) che, a detta degli esperti, ha una capacità di archiviazione di foto e video 3-4 volte superiore agli standard normali. Se l’invenzione del codec MP3 ha permesso l’avvento della musica digitale e il codec MPEG2/4 quello del video digitale, il codec Cappelli promette di fare miracoli: si legge che è possibile comprimere, nell’esiguo spazio di 1,44 MB di un floppy disk ben 20 minuti di un filmato ad alta qualità (su alcune fonti si parla di qualità DVD ma non credo che la qualità MPEG 2 possa arrivare ad occupare così tanto per appena 20 minuti di filmato visto che un film da due ore entra appena in un DVD da 4,7GB!) dal peso complessivo di 3,1 Gigabyte!
Di fatto, il nuovo codec è superiore a qualsiasi altro sistema di compressione in vigore, ivi compresi quelli di ultimissima generazione denominati H264 ed Mpeg4, tanto che sarà possibile archiviare molte più di ore di video sugli stessi supporti multimediali di adesso. Ma il nuovo sistema permette anche di ottenere immagini compresse di qualità media più elevata rispetto agli altri codec attualmente in circolazione. Tale capacità è data dall’ottimizzazione dell’organizzazione dei dati che si traduce anche in un uso più efficiente delle bande su cui viaggiano i dati per la tv digitale. «Con la possibilità – prosegue Cappelli – di moltiplicare i canali digitali e la tv interattiva».

Ma, sebbene molte società dell’IT Technologies siano interessate a comprare i diritti di questo nuovo formati, Claudio Cappelli ha dichiarato di non avere alcuna intenzione di cedere il brevetto e punta a mantenere il marchio in Italia. Attualmente ancora non è disponibile in commercio ma tra le prime applicazioni si punta alla IPTV, la televisione via Internet. Il sistema, garantisce Cappelli, permette la fruizione dei programmi via web senza disturbi e distorsioni causati dall’elevata compressione, che rendono la tv via Internet spesso poco soddisfacente»

Questi i dati del codec Castelli o codec Eco Controllo: il programma è stato realizzato da 12 programmatori in 1 anno e mezzo di lavoro in collaborazione con alcune Università campane (il consorzio Cerict che associa cinque università campane, il Cnr, la Fondazione Pascale e il Cini, il Consorzio interuniversitario per l’informatica, ha testato e validato il sistema) e 5 milioni di euro investiti nel progetto, di cui il 60% finanziato dal Ministero dello Sviluppo Economico.

Qualche dubbio

Sebbene ci si da rimanere finalmente orgogliosi di questo successo tutto italiano (non se ne vedevano forse da anni) che mette in luce come la ricerca in Italia funziona (tanto da dire la sua anche in campo internazionale) ma merita solo di essere maggiormente finanziata, nutro qualche dubbio sui dati passati dalle testate giornalistiche. Dire prima che il codec Cappelli ha una capacità di archiviazione di foto e video 3-4 volte superiore agli standard normali e poi asserire che in un floppy disk da 1,44 MB possono essere compressi ben 20 minuti, di un filmato ad alta qualità, mi sembra un po’ esagerato se si vuole mantenere la stessa buona qualità di immagine. E’ possibile comprimere 20 minuti di filmato in un divx da 4 MB (col giusto rapporto di compressione), per cui, se è vero che il codec Cappelli comprime anche 3-4 volte un codec Mpeg4, allora arriviamo ad occupare poco meno di 1,44 MB. Ma il problema è la qualità: sarà accettabile? Sono curioso di visionare qualche video di prova per valutare la bontà del nuovo codec. Al momento è disponibile solo un complicato draft in italiano che snocciola cifre e numeri su un’analisi comparativa del codec video “Eco Controllo”.

Errata Corrige della Eco Controllo

E in effetti, mentre stavo scrivendo questo articolo, sul sito della Eco Controllo è comparsa questa Errata Corrige:

13 gennaio 2009

UNA PRECISAZIONE DAL PRESIDENTE
DELLA ECO CONTROLLO

In merito alla notizia apparsa su alcuni organi di informazione si precisa quanto segue: “Nel corso della conferenza stampa, tenutasi ieri, 12 gennaio 2009 alla Sala Capitolare del Senato della Repubblica, il dr. Claudio Cappelli, presidente della Eco Controllo SpA, ha portato l’esempio di un video in alta definizione a 1080i, della durata di 20 secondi, archiviato su un floppy da 1,44 MB. Evidentemente la notizia di un filmato di 20 minuti è frutto di un equivoco”.

Quindi non si tratta di 20 minuti, bensì di 20 secondi, il che è già più accettabile!
Peccato non specifici i dati reali del filmato di esempio utilizzato. Sul draft si legge di Test Oggettivi e Soggettivi su Video 720P e PAL; in particolare in merito ai test soggettivi:

Mediante un’estrazione sono stati selezionati 8 video proiettati in tre differenti bitrate (1000,2000 e 3000Kbps) a 16 valutatori. I valutatori sono stati suddivisi in due gruppi e per ogni gruppo è stata svolta una distinta sessione di test della durata di 30 minuti.
[…]
Sono stati selezionati solo video in formato 720P, cioè ad una risoluzione di 1280×720 Pixel, con cadenza di 25 e 50Hz. Tale scelta è motivata dal fatto che questi parametri sono quelli scelti per la cosidetta Televisione Digitale ad alta definizione (HDTV) in tutti quei paesi, Italia inclusa, che tradizionalmente sono legati al sistema di trasmissione PAL e SECAM.
[…]
Come previsto dalla metodologia DSIS, le persone sono state collocate in una sala confortevole e posizionate in modo tale da avere sempre l’angolo di visualizzazione ottimale per il dispositivo di visualizzazione adottato, consistente nella fattispecie in un televisore al plasma FullHD. Ai partecipanti è richiesto di descrivere la qualità da loro percepita utilizzando una scala lineare continua costituita da 5 regioni etichettate con i seguenti aggettivi:

• nessun difetto
• difetti visibili, ma non fastidiosi
• difetti leggermente fastidiosi
• difetti fastidiosi
• difetti molto fastidiosi

I soggetti sono stati selezionati tra una popolazione eterogenea composta da studenti e lavoratori. Ognuno di essi è stato preventivamente sottoposto al test di Ishihara per la percezione dei colori. Quest’ultimo è un test pubblicato nel 1917 dal Prof. Shinobu Ishihara, e consiste nel sottoporre all’utente un numero di dischi colorati, chiamati dischi di Ishihara, ognuno contenente un cerchio di punti di taglie e colori diversi disposti a caso. L’insieme dei punti forma un numero visibile a coloro che hanno una visione normale, ed invisibile o difficile da vedere per quelli che hanno problemi di visione, in particolare nella percezione del colore rosso-verde.

I risultati ottenuti confermano sostanzialmente quanto osservato con le metriche oggettive, anche se il divario tra i differenti codec, in questo caso, appare maggiormente marcato. Il supporto dell’indice di confidenza, sembra evidenziare una maggiore stabilita dell’algoritmo Cappelli. Anche in questo caso se si considera il voto medio massimo, gli algoritmi H.264 e Cappelli ottengono lo stesso risultato, evidentemente questo deriva dal fatto che in alcune circostanze, particolarmente favorevoli a tutti i codec, gli utenti non percepiscono significativi difetti. Tuttavia, nel caso peggiore e medio l’algoritmo Cappelli ottiene voti caratterizzati da una maggiore precisione, ciò e una variabilit inferiore agli altri codec, e questo ci fa dedurre che la qualità di questo codec nelle condizioni riprodotte di test adottate ha performance significativamente superiori.

Diffusione del codec

Nutro altri dubbi sulla fattiva diffusione di questo codec. Perché possa divenire uno standard deve essere accettato dalle Major dell’IT Tecnhnologies ma molti, per comodità e per far fruttare gli investimenti passati, tendono a usare le tecnologie che già possiedono: i soli codec H264 e Mpeg4 sono ottimi e già diffusissimi. L’unica speranza sarebbe quella di liberare da royalties il nuovo codec e lasciarlo libero alla comunità di sviluppatori Open Source (come per il codec XviD, nato in contrapposizione al chiuso codec DivX), relegando la società di Eco Controllo ad ente di consulenza.

Purtroppo di codec meravigliosi, più potenti e maggiormente performanti per la trasmissione sul web ne ho visti molti ma quasi nessuno di questi ha avuto sullo strapotere dell’MPEG2/4 e dell’H264. Staremo a vedere come andrà a finire.

UPDATE: Sul sito di Attivissimo si susseguono interessanti commenti di critica e analisi all’articolo errato dell’ANSA, ripreso poi da diverse testate giornalistiche, riguardo i 20 minuti di filmati su un floppy disk da 1,44 MB (invece che 20 secondi).

UPDATE 2: Nella sezione Tecnologia del sito di Eco Controllo, c’è il Rapporto Tecnico Finale al al progetto “Nuove Tecnologie nel Campo della Compressione delle Immagini Digitali” in cui sono presenti ulteriori dettagli sul funzionamento di questo codec. Il caso strano è che risale addirittura al Maggio 2008!

Tag:alta definizione, cappelli, codec, compressione, dgtv, Digitale Terrestre, divx, h.264, iptv, mpeg, mpeg2, mpeg4, televisione, Video
CONTINUE READING >
7 comments
Lug 3 2008

Il punto della situazione sulle droghe virtuali nei file audio e spiegazione sull’origine del software I-Doser e dei file DRG

Posted by Antonio Troise
Tweet

Twilight Zone Ricordo un episodio della serie di fantascienza “Ai Confini della Realtà” in cui gli alieni riescono a trasmettere per radio un segnale subliminale in grado di condizionare il genere umano, tanto da riuscire a modificare il suo DNA e trasformarlo, nel giro di pochi giorni, in una sorta di armadillo pseudo-umano. Lo scopo, si scopre alla fine dell’episodio, è quello di rendere l’umanità in grado di resistere alla radiazioni nucleari di una prossima Terza Guerra Mondiale, garantendo così la sopravvivenza della civiltà sulla Terra. Curiosamente è stato proprio a questo episodio che ho pensato quando il 1 Luglio, ho sentito al TGCOM, la notizia del I-Doser, la droga virtuale che si aggira nei file mp3.
Devo dire, però che, oltre a credere di stare vivendo in un racconto di fantascienza (nel cinema troviamo anche altri esempi, da Morte a 33 giri a Nirvana, in cui il protagonista Jimi Dini è un programmatore che per sbarcare i lunario spaccia anche programmi droghe), ho subodorato il solito allarmismo tipico dei giornalisti nei confronti di internet.

Se siete soliti andare nelle librerie, ogni tanto forse vi sarà potuto capitare di imbattervi in qualche CD New Age che è in grado di farvi rilassare in pochi minuti sfruttando qualche particolare frequenza sonora (battiti binaurali) che interagisce direttamente col nostro cervello, per favorire la meditazione, il sonno o curare il mal di testa. Ma non pensavo che l’ingegneria del suono fosse giunta al punto di creare addirittura delle droghe virtuali. Ma sarà tutta verità o forse è stata condita con troppi elementi creativi?

Le prime notizie

Il TGCOM asserisce che:

Il fenomeno si chiama I-Doser ed è nato negli Stati Uniti e sta sbancando in Europa, dove ha attecchito soprattutto in Spagna, per poi diffondersi in modo rapido anche negli altri paesi. Italia compresa.

Il problema è che nessuno dei miei amici e conoscenti era a conoscenza di questa particolare droga virtuale. Ma neanche i cibernauti della blogosfera, sempre informata di tutto, ne era al corrente. E ciò risulta strano, perché, di solito, se una cosa funziona, sul web ci mette 5 minuti a fare il giro del mondo, anche grazie a canali P2P. Ma anche se nel canali di file sharing è possibile trovare i file per i-Doser, perché nessuno ne ha mai parlato prima? E se era un fenomeno nascosto nei bassifondi di internet, perché parlarne su un telegiornale a diffusione nazionale, tanto da contribuire a diffondere la notizia in pochi giorni? Se il fenomeno è reale ma ancora relegato a pochi, perché parlarne così apertamente mettendo in pericolo i giovani che, si sa, sono curiosi e sicuramente saranno andati a scaricarsi qualche demo di dose?

Le prime apparizioni di I-Doser

Dalle mie ricerche ho scoperto che per esempio, su Yahoo! Answers se ne è parlato circa 3 mesi fa, ma il fenomeno si era fermato li. Su Youtube compare qualche video, presumo tutti frutto di messe in scena, e nel frattempo qualche sito di riferimento era nato, a partire da quello ufficiale in inglese I-Doser.com fino ad arrivare ai nostrani TarantoHipHop e NonApriteQuelPortale, che hanno tentato di spiegare il meccanismo dell’I-Doser.
Ma diciamoci la verità, se non si conosceva il termine, era quasi impossibile venirne a conoscenza!

Oggi, invece, tutti i maggiori quotidiani nazionali ne parlano apertamente, ovviamente copiandosi l’un l’altro, Il Messaggero, Il Tempo, il Corriere della Sera, Panorama e La Stampa.
E questi sono solo alcuni giornali, per non parlare poi della Blogosfera che ha fatto rimbalzare la notizia su più fronti e, più saggiamente della controparte mediatica, è molto più scettica delle conclusioni dei media!

Il principio di funzionamento di I-Doser

Tutti segnalano che l’allarme è stato lanciato dal GAT il Nucleo Speciale Frodi Telematiche della Guardia di Finanza, che ha scoperto la novità nei blog e nei forum dove i giovani si scambiano informazioni (forse è stata colpa di quel tizio che su Yahoo! Answers ha chiesto informazioni?)

Le nuove cyber droghe, infatti, sono normali file in mp3 (in realtà sono file GDR). “Agiscono sulle onde a bassa frequenza – ci spiega il colonnello del GAT Umberto Rapetto – soprattutto quelle che vanno dai 3 ai 30 hertz, ossia le frequenze della fascia di lavoro del cervello.
L’orecchio assorbe questi suoni che non riesce a distinguere e che, nella maggior parte dei casi, sono mescolati a musiche psichedeliche“.
Proprio perchè gioca con diverse lunghezze d’onda e perchè fatto di suoni impercettibili, se ascoltati da un solo orecchio, i file non producono alcun effetto. Di qui la necessità delle cuffie.

[…]

Per ora non è stato accertato quali danni possa arrecare la cyber-droga, nè se dia dipendenza. “Il fenomeno è agli albori”, afferma Rapetto. “Chi diffonde i file sostiene che non ci siano effetti collaterali, che le dosi provocano delle semplici sbornie, ma è bene che a stabilirlo siano i medici.

Ma come funzionano queste droghe virtuali? Una spiegazione semplice ci arriva dal solito sempre informato Paolo Attivissimo che ci spiega che:

Si tratta di binaural beat: due suoni, a frequenze udibili e riproducibili dalle cuffie normali, e leggermente differenti l’uno dall’altro come frequenza: per esempio, uno è a 300 Hz e l’altro è a 307. Ascoltati in cuffia, in modo che uno solo dei due suoni raggiunga ciascun orecchio, producono un terzo suono per battimento.
Per fare un paragone stiracchiato, è come se vi arrivasse un MI in un orecchio e un FA nell’altro e il vostro cervello generasse una nota che è la differenza fra il MI e il FA.

Secondo un’altra fonte sembra che:

Il sistema funziona sulla base dei cosiddetti ‘battiti binaurali‘ (dall’inglese: binaural beats) sperimentati sul cervello negli anni Settanta dal dr. Gerald Oster alla clinica newyorkese Mount Sinai, e che consistono nell’applicare frequenze herziane diverse ai due orecchi per stimolare il cervello a seconda della loro intensita‘. Le frequenze cerebrali vanno da 1 a 4 Hz per il livello Delta, quello del sonno profondo, fino ad un massimo di 30Hz allo stato vigile che corrisponde alla frequenza Beta, passando per Theta e Alfa, uno stato quest’ultimo di semiveglia usato nei sistemi di Controllo Mentale perche’ consente di sincronizzare i due emisferi potenziando l’attivita’ cerebrale.
Le ‘dosi’ proposte da I-Doser si ottengono applicando, con auricolari, alte frequenze asincrone ai due orecchi, per esempio 500 e 510 Hz rispettivamente, causando nel cervello un tono di 10 Hz cioe’ in pieno livello Alfa e favorendo cosi’ gli effetti di alterazione della percezione.

L’origine del software I-Doser e cosa sono i file DRG?

Tutti hanno parlato del I-Doser fino allo sfinimento ma non tutti conoscono bene quale sia la sua origine. Dovete infatti sapere che I-Doser altro non è che un rip di un programma Open Source (GNU GPL v2) chiamato Sbagen in grado di generare onde sonore per il cervello (Brain-Wave generating) capace di rilassare l’individuo che le ascolta. Questa applicazione usa dei preset file con estensione .SBG che possono essere suonati e registrati come file WAV.
Ovviamente dire che sono file MP3 è errato perché, proprio per la natura stessa del formato di compressione audio, usare dei file MP3 significherebbe tagliare la banda di frequenza usata per generare quei fantomatici effetti di cui tutti parlano.

Quello che dovete sapere, quindi, è che la società che ha creato I-Doser altro non ha fatto che rifarsi al modello del software Sbagen e, per evitare che chiunque potesse ascoltare più volte la stessa “droga”, hanno creato un preset file di tipo DRG, che altro non è che un file .SBG criptato e contenente anche uno screenshot e le informazioni sul contenuto della dose! Questo file, di solito, viene venduto ad un prezzo di 5-10 euro, dura circa 45 minuti e, nelle intenzioni dei suo creatori, si può ascoltare una sola volta (appunto come una droga), costringendovi, per ripetere l’esperienza, a ricomprare più volte le dosi.

In realtà, come spesso accade per tutto ciò che ha lucchetti digitali, prima o poi, qualcuno è riuscito a sbloccare le limitazioni dei software e, per questo, è facile trovare versioni craccate di I-Doser e delle dosi ascoltabili senza limitazioni, grazie anche all’ausilio del software open source Sbagen.

E’ solo suggestione come nei placebo?

Con questo articolo non invito nessuno a provare questa “esperienza” perché, oltre a non credere ai fantomatici effetti psicotropi, ho dei seri dubbi sulla effettiva non pericolosità di un ascolto cacofonico di lunga durata (una sessione, ricordiamo, dura circa 45 minuti) sia sull’udito che sul cervello umano.

Comunque, la maggior parte di chi li ha scaricati e ascoltati in cuffia, non ha percepito alcun effetto psicotropo, se non quello di una notevole irritazione (in gergo tecnico, orchiclastia), perché non è musica ma solo rumore fastidiosissimo.

C’è chi asserisce che tutto dipende dalla sensibilità alle onde binaurali della singola persona ma io sospetto che, semplicemente, dipenda dal grado di suggestionabilità individuale. Come nell’effetto placebo, credo che chi ascolta questo rumore di fondo, vedendo il nome della droga, si autosuggestioni e, magari, un semplice cerchio alla testa o uno stato confusionario prodotto dal rumore cacofonico, viene facilmente attribuito al effetto specifico della droga virtuale!

UPDATE: Il programma Le Iene è tornato sulla faccenda con un test pratico condotto su un gruppo di studenti e con un’intervista a Michelangelo Iannone, ricercatore del CNR.
Il lavoro delle Iene lascia ben poco spazio a dubbi sulla natura di quest’allarme gonfiato acriticamente dai media. Se i giudizi di Iannone sono lapidari, quelli degli studenti sono tombali. Il servizio è consultabile su Internet. (via attivissimo)

Tag:blogosfera, compressione, drg, fantascienza, i-doser, mp3, Musica, opensource, p2p, Radio, scienza, Software
CONTINUE READING >
18 comments
Lug 2 2008

Come risparmiare banda: ridurre le email dei commenti e i backup via FTP, usare le AJAX Library API di Google con il plugin per WordPress e disattivare Google Translator che non porta traffico utile ad Adsense

Posted by Antonio Troise
Tweet

Più volte mi sono dovuto imbattere in ottimizzazioni certosine per ridurre i consumi di banda mensile sul mio sito: riducendo le dimensioni dei file javascript, attivando la compressione HTTP e, a volte, anche spostando le immagini su un altro server. Ma non ho mai dovuto affrontare incrementi di banda di oltre 10/20 GB in un solo mese.
Infatti, lo scorso Giugno, con mia grande sorpresa a soli 20 giorni dall’inizio del mese, il mio sito aveva già esaurito la banda di 40 GB messa a disposizione dal Blooweb, arrivando, a fine mese, ad oltre 50 GB di banda totale. Grazie alla gentilezza dello staff del mio hosting, mi hanno ripristinato temporaneamente il servizio in attesa che capissi da cosa fosse dipeso questo improvviso aumento di banda.

Sicuramente nell’ultimo mese avevo ricevuto un incredibile aumento di visitatori e questo aveva sicuramente influenzato le statistiche: oltre 30.000 visitatori unici in più (103.000 solo a Giugno) rispetto alla media dei mesi scorsi con un incremento di banda sproporzionato di oltre 16 GB in più (giungendo a 39.52 GB a fine mese di solo traffico HTTP).

La banda è la somma del traffico HTTP, FTP, SMTP e POP

Quello che mi aveva colto impreparato, però, era che il traffico HTTP (evidenziato da tool statistici com Awstats) non era l’unico elemento che veniva conteggiato nella soglia di banda messa a disposizione da un hosting (ed evidenziato nella homepage del mio cPanel): infatti, oltre al traffico HTTP, veniva conteggiato anche quello FTP, SMTP e POP. Normalmente, però, questi valori sono sempre trascurabili rispetto alla banda generata dal traffico delle pagine web. Questo, però, fino a questo mese, visto che il 20 Giugno, a fronte di un traffico HTTP di soli 28.76 GB, il sistema misurava una banda totale che superava i 40 GB! Ovvero, stavo consumando oltre 10 GB tra traffico FTP, SMTP e POP! Una cosa davvero incredibile rispetto alla media dei mesi precedenti.

Troppi commenti con false email generano traffico SMTP

Analizzando con calma la situazione ho scoperto che la funzione di segnalazione dei commenti (del plugin per WordPress Subscribe To Comments) inviava quotidianamente molti messaggi che non venivano mai recapitati correttamente (nell’ordine di alcune centinaia al giorno), probabilmente perché molti utenti che lasciavano commenti sul mio blog non inserivano email reali. Ciò creava un indubbio traffico SMTP anche se credo non della portata di 10 GB mensili, visto che i messaggi recapitati erano solo ASCII.
Comunque, onde evitare problemi, ho provveduto ad eliminare tutte le email che si erano registrati su un solo articolo del mio sito (oltre il 95% delle mail memorizzate), supponendo che chi scrive un commento con una email fittizia sia un visitatore di passaggio e quindi non un commentatore abituale. In tal modo non ho dovuto disattivare completamente questa funzione.

Fare spesso via FTP i backup di siti molto grandi riduce la banda mensile

Un altro problema che ho messo in luce è che, se è vero che nel conteggio del traffico totale mensile, era prevista anche la banda FTP usata, allora ogniqualvolta eseguivo un backup del mio sito, questo erodeva la quota mensile. Ora siccome dal cPanel è possibile eseguire un backup di tutta la mia home directory e non solo della directory in cui risiedono le mie pagine web, ogni volta che faccio il backup del sito, scarico ben 639 MB (a fronte di un peso effettivo del mio blog di poco più di 200 MB). Se in un mese, come è accaduto a Giugno, eseguo 4-5 backup, consumo oltre 3 GB di banda mensile.
Per risolvere questo problema ho deciso di scaricare solo il contenuto effettivo del mio sito e, laddove possibile, sempre verso fine mese, in modo da tenere sotto controllo il consumo di banda.

Il problema ricorrente delle dimensioni dei file Javascript e le AJAX Library API di Google

Se questi ultimi 2 punti sono stati volti a risparmiare quel fattore di banda invisibile e difficilmente monitorabile, ho deciso anche di intervenire, ancora una volta, su quella HTTP. Devo dire che, mano a mano che avanza lo stato di ottimizzazione del sito, affrontare il problema della banda, è un lavoro davvero certosino e occorre considerare diverse variabili prima trascurate e, non da ultimo, alcuni elementi nuovi (come l’installazione di nuovi plugin) che sono intercorsi dall’ultima analisi.

Tra questi troviamo anche un vecchio problema: i file javascript. Infatti, nonostante la precedente volta li abbia compressi più che mai, nel solo mese di Giugno, i soli file JS occupavano ben 8.96 GB di banda mensile!

Per risolvere parzialmente questo problema, ho pensato, quindi, di poter sfruttare le AJAX Library API di Google. In pratica, Google, recentemente ha messo a disposizione di tutti le maggiori librerie javascript e ajax compresse, linkabili direttamente dai loro server: jQuery, Prototype, script.aculo.us, Mootools e Dojo!

Centralizzando la distribuzione dei framework javascript e sfruttando le infrastrutture della rete di Google è possibile ottenere innumerevoli vantaggi: caching (utilizzando il medesimo URL per i file, c’è la probabilità che il browser dell’utente abbia già scaricato la libreria precedentemente), compressione Gzip/Minify, e file ospitati sui server veloci di Google e quindi riduzione del traffico generato dal proprio sito.

E’ possibile richiamare gli script all’interno delle proprie pagine utilizzando la classica sintassi:

oppure con il metodo google.load(), che di fatto è molto più potente e performante, perché permette di indicare anche la versione desiderata della libreria:

Nel caso di script.aculo.us dovremo caricare anche prototype:

Infatti, per garantire la compatibilità delle applicazioni, Google offre anche una serie di versioni diverse per ogni libreria Javascript e permette di specificare quella desiderata. Il versioning è, però, anche intelligente. Infatti, se si specifica una versione parziale della libreria (p.es 1.8), Google ci farà scaricare l’ultima release stabile di quella revision (p.es. 1.8.4), mentre se si specifica solo la versione “1” allora lui scaricherà l’ultima disponibile, ovvero, la “1.9.1”.

Plugin per WordPress per le Google AJAX Libraries API

Se non volete mettere mano al codice della funzione wp_head() di WordPress per eliminare il riferimento al file prototype residente sul server ed inserire il link a quello residente sul server di Google, esiste un comodissimo plugin: Google AJAX Libraries API Plugin. Una volta attivato non farà altro che sostituire (con un add_filter()) il riferimento a tutti i framework gestiti con la versione ospitata sui server di Google.

L’unico svantaggio è che non usa la versatile funzione google.load() (che permette di puntare dinamicamente alla ultima release stabile) bensì il classico link diretto al file javascript. Ciò vi costringerà a tenere sotto controllo la versione di Prototype usata da WordPress e aggiornare di conseguenza il plugin (che ancora non è inserito nella Repository Ufficiale dei Plugin per WordPress) oppure modificarlo a mano.
Inoltre, non punta neanche alla versione compressa del file javascript, il che comunque non rallenta minimamente il caricamento della pagina.

Infatti, come è possibile vedere, eseguendo i test con i Pingdom Tools, usando la versione non compressa di Google abbiamo un peso di 123,2 KB (che comunque non influenza la banda del proprio sito) e un tempo di caricamento di 0.5 secondi

Google AJAX Libraries API

mentre usando la versione ospitata sul mio server, a fronte di un peso complessivo di 46,6 KB abbiamo un tempo di caricamento di oltre 1,2 secondi!

Prototype self hostes

Disabilitazione di alcuni plugin

Inoltre, tra i file più letti ho trovato tutta una serie di plugin per i commenti:

  • quoter.php (plugin: Quoter)
  • ajax-comment-preview-js.php (plugin: AJAX Comment Preview)
  • lmbbox-comment-quicktags.php (plugin: LMB^Box Comment Quicktags)

Ho deciso, quindi, in via del tutto sperimentale, di disattivarli (visto che comunque non sono essenziali per l’inserimento di un commento), per capire che influenza avevano sulla banda totale e sulla velocità del sito (monitorabile facilmente con i Pingdom Tools).

Disattivare Google Translator che non porta traffico utile ad Adsense

Al termine di queste mie analisi ho scoperto che un plugin che avevo installato stava producendo un aumento di banda non indifferente in maniera totalmente indiretta e difficilmente monitorabile: sto parlando del plugin per WordPress Global Translator, un tool per la traduzione automatica delle pagine nelle principali lingue sfruttando le API di Google Translator.

Infatti, da quando a fine Maggio lo avevo installato, il traffico proveniente dagli Stati Uniti è quasi raddoppiato, passando da 15.08 GB a ben 28.06 GB! Considerando che il mio sito è scritto in italiano, è facilmente intuibile che quel plugin aveva avuto il pregio di allargare la mia fetta di visitatori ad un pubblico che solitamente non mi leggeva.

Ma allora mi sono chiesto: il traffico in più proveniente dagli Stati Uniti era traffico utile e valido e poteva essere vantaggioso per il mio sito oppure era solo uno spreco inutile di banda? Il fatto che la traduzione automatica di Google non potrà mai rispecchiare fedelmente il testo scritto nella propria madre lingua, può portare gente realmente interessata a quello che dico o solo a visitatori passivi che incappano per errore nelle mie pagine? Devo dire che, per certe keyword specifiche, il mio sito risultava primo anche in lingua inglese, e ciò conferma il fatto che Google ha svolto un ottimo lavoro di indicizzazione delle mie pagine. Ma la mia esperienza con le pagine tradotte in automatico non è delle migliori, perché spesso non si riesce a cogliere il senso più profondo delle frasi ma solo una descrizione sommaria. E purtroppo non è questo quello che desidero dare ad un lettore!

Inoltre, per i più veniali, un altro indubbio svantaggio è che, a fronte di un raddoppio di banda usata e di pagine viste, ciò non portava ad alcun incremento degli introiti di Google Adsense che si attestavano sempre sugli stessi valori dei mesi precedenti. Questo capita perché, come ho potuto constatare, anche se la pagina risulta tradotta in inglese (o in qualsiasi altra lingua), i banner Adsense risultano sempre visibili in italiano, vanificando quindi il loro scopo perché nessun inglese cliccherà mai su una pubblicità scritta in un’altra lingua.

Quindi, a ragione, ho provvedduto a disabilitare la traduzione automatica del sito, sperando che, quando Google avrà tolto dal suo indice le pagine scritte in un altra lingua al di fuori dell’italiano, la quota mensili di banda consumata si possa attestare su valori ragionevoli.

Il problema della banda dei server italiani

Il problema dei server che risiedono in Italia è che la banda viene ceduta quasi a peso d’oro: un upgrade di soli 5 GB di traffico mensile mi viene a costare bene 42.00 € in più; considerando che, in teoria, avrei bisogno di almeno altri 20 GB di banda, il costo di gestione del mio sito lieviterebbe di oltre 120.00 €!
Capite bene perché, ogni 2-3 mesi, sono costretto ad ottimizzare al massimo le prestazioni del mio sito riducendo inutili sprechi! Spero che questa mia testimonianza possa essere utile a qualcuno che, come me, combatte quotidianamente con il traffico mensile.
Se poi avete qualche altra idea o suggerimento sono sempre disponibile ad ascoltarvi.

Tag:adsense, Ajax, api, backup, banda, bandwidth, blooweb, compressione, ftp, Google, google translator, Javascript, Php, Plugin, prototype, Wordpress
CONTINUE READING >
17 comments
Apr 8 2008

Nuove modalità per risparmiare banda con WordPress 2.5: addio alla compressione Gzip direttamente da WordPress e comprimere del 60% il file prototype.js v1.6.0

Posted by Antonio Troise
Tweet

Tempo fa scrissi un paio di guide su come risparmiare banda sul proprio sito comprimendo tutte le pagine con Gzip e riducendo le dimensioni del file javascript prototype. Le operazioni che, però, avevo descritto in quei tutorial non sono più del tutto valide in WordPress 2.5. Ecco, in particolare, cosa è cambiato e come agire di conseguenze.

Addio alla compressione Gzip da WordPress

Su WordPress 2.3, per attivare la compressione delle pagine web, era sufficiente andare nel Pannello di Controllo di WordPress e, nella sezione Opzioni/Lettura (Options/Reading per la versione in lingua inglese), spuntare la voce “WordPress deve comprimere gli articoli (gzip) se il browser lo richiede“. Questo permetteva, in tutta semplicità, di comprimere in formato Gzip (attivando la compressione HTTP) prima di inviarlo al browser, in modo da alleggerire la dimensione della pagina (risparmiando quasi il 70% di dimensioni in una pagina di puro testo) e diminuirne il tempo trasferimento facendo lavorare un po’ di più il computer dei vostri lettori.

Ora, con WordPress 2.5, tutto questo non è più possibile. Sono andato a vedere in tutti i menu e sottomenu dell’Area di Amministrazione di WordPress, ma della voce per la compressione del contenuto delle pagine web tramite gzip, non ve ne era più traccia. Ho trovato la conferma anche qui: pare che in In WordPress 2.5 questa opzione non sia più presente!

Pare che la spiegazione, data da Ryan Boren, sia quella che era nata nel Team di Sviluppo di WordPress, l’esigenza di voler spostare la decisione della compressione delle pagine web al server stesso; infatti, oramai, qualsiasi webserver è in grado di gestire la compressione del contenuto, e la maggioranza dei piani di hosting prevede questa funzione, sia abilitata per default, sia opzionale (come nel caso di cPanel). Evidentemente questo dovrebbe avere ovvi vantaggi prestazionali, anche se non ho ben chiaro quanto possa essere.

Riattivare la compressione gzip da php

Se, però, il vostro webserver è tra i pochi che non supporta la compressione gzip (sul mio per esempio no ho trovato la funzione), potete verificare, come suggerisce Elliott C. Back, se almeno il vostro interprete php offre le funzioni di controllo dell’output, e attivarle tramite .htaccess con queste due righe di comando:

Altrimenti, dovrete modificare il vostro file index.php nel seguente modo:

Attenzione, però: se attivate la compressione via php, dovrete modificare il file tiny_mce_config.php (in wp-includes) come suggerito da Andrew Ozz nella lista wp-testers, e disabilitare la compressione in questo file, altrimenti l’editor visuale verrà compresso due volte!

Riattivare la compressione gzip con un plugin per WordPress

Se, però, come immagino, non volete mettere mano ai file php e non potete comunque attivare la compressione sul vostro webserver, potete allora installare il plugin realizzato da Sergej Müller. Si chiama Compress for WordPress 2.5, ed è un plugin che agisce pressoché allo stesso modo descritto nel capitolo precedente senza, però, richiedere alcuna modifica manuale. Purtroppo è in tedesco ma è abbastanza chiaro quello che fa: è sufficiente attivarlo e lui comprimerà e vostre pagine web da php.

Wordpress Content-Encoding Gzip
Come verificare che il plugin Compress for WordPress 2.5 svolga il suo lavoro

Di solito mi fido delle descrizioni che gli autori danno dei propri plugin, ma siccome, in questo caso, ci troviamo di fronte ad un plugin che non rilascia alcun feedback su quello che fa e risulta essere del tutto trasparente a tutti tranne che al browser, ho deciso di verificare se Compress for WordPress 2.5 funzionava correttamente, anche perché non volevo segnalare qualcosa di cui non ero neanche io certo sul suo funzionamento!

Per farlo ho installato una comoda estensione per Firefox, Live HTTP Headers 0.13.1, che permette di catturare e analizzare l’headers delle pagine HTTP che il browser visualizza. Infatti, l‘informazione che ci dice se la pagina è stata compressa, è contenuta in una variabile: Content-Encoding.

Se, quindi, attivo il plugin Compress for WordPress 2.5, e ricarico l’homepage del mio sito, vedrò che la maschera di Live HTTP Headers (raggiungibile da Firefox dal menu Strumenti/Live HTTP Headers) mostra il parametro suddetto settato come:

Content-Encoding: gzip

Se, invece, disabilito il plugin, il parametro di Content-Encoding non viene neanche passato e, l’unica cosa che è possibile trovare (e che si trova anche nel caso) precedente, è il parametro “Accept-Encoding: gzip,deflate” che sta ad indicare che il nostro browser è in grado di gestire i contenuti compressi.

Quindi, in soli due minuti, abbiamo verificato che il plugin svolgesse correttamente il suo lavoro!

Compressione del 150% del file prototype.js 1.6.0

Per quanto riguarda, invece, la compressione del voluminoso framework Prototype (un file JavaScript che ha loscopo di facilitare lo sviluppo di applicazioni web dinamiche di tipo Ajax) in uso su WordPress, non è cambiato molto se non la versione da utilizzare. Infatti, rispetto a WordPress 2.3, che usava la versione 1.5.1.1, la nuova release di WordPress 2.5 usa la versione 1.6.0.
Potete controllarlo voi stessi: basterà leggere la prima riga del file wp-includes/js/prototype.js

Quindi, se non volete comprimere voi stessi il file javascript (che di per sé è grande 121 KB), con un dei tanti tool online che ho descritto in precedenza, dovete fare riferimento all’ottimo lavoro svolto da John-David Dalton che ha compresso per noi tutte le versioni di Prototype.

Quello che dovrete fare voi, quindi, è scaricare il file protopack_v2.19b.zip dal sito Prototype: Core (nel vecchio tutorial era il protopacked_v2.17.zip), scompattarlo e vi troverete una ricca collezione di framework Prototype/Scriptaculous.
In particolare questo package contiene le release 1.4, 1.5, 1.5.1.2 e 1.6.0.2 di Prototype e la release 1.7.1_beta3, 1.8.1 di Scriptaculous. Se sul vostro sito usate anche Scriptaculous allora potete far riferimento direttamente al file Protoculous (esistono le versioni 1.5.1.2 + 1.7.1_beta3 e 1.6.0.2 + 1.8.1), che altro non è che la combinazione in un unico file di Prototype and Scriptaculous.

In generale, però, nel nostro caso sarà sufficiente scegliere la versione compressa del file prototype.js. Quindi, una volta scaricato e scompattato il pacchetto zip protopack_v2.19b.zip, aprite la cartella “files” e vi troverete 3 cartelle: qui aprite la cartella “compressed“, quindi la cartella “prototype” e, infine, entrate nella directory “v1.6.0.2“ (non è esattamente la stessa versione rilasciata con WordPress 2.5, ma i cambiamenti sono davvero minimi e comunque compatibili con una release inferiore).
Qui, vi troverete, dinanzi a due differenti versioni compresse dello stesso file Prototype.js:

prototype-1.6.0.2-packer.js : compresso con Dean Edward’s Packer 3 \w con le opzioni “Base62 encode” e “Shrink variables”
prototype-1.6.0.2-shrinkvars.js : compresso con Dean Edward’s Packer 3 \w con la sola opzione “Shrink variables”.

La differenza, sostanzialmente, sta nelle dimensioni: il prototype-1.6.0.2-packer.js è grande 48 KB (la versione 1.5.1.1 compresso, che si usava con WordPress 2.3, invece, era grande solo 40 KB) mentre prototype-1.6.0.2-shrinkvars.js arriva fino a 76 KB.
Io, per il mio sito, ho usato prototype-1.6.0.2-packer.js (risparmiando oltre il 60% di spazio) che ho, ovviamente, rinominato in prototype.js e, quindi, salvato nel percorso “wp-includes/js” sostituendo il precedente file (magari fatene un backup per sicurezza).

Tag:Ajax, banda, bandwidth, browser, compressione, cpanel, gzip, Javascript, Php, prototype, Web 2.0, Wordpress, wordpress 2.5
CONTINUE READING >
12 comments
Gen 28 2008

Cosa è il Calgary Corpus e come si eseguono i test di compressione

Posted by Antonio Troise
Tweet

Nonostante, per gli usi quotidiani, tutti noi siamo soliti usare uno o due tool di compressione come, per esempio Zip o Rar, in realtà esistono numerosi altri tool (7zip, UHARC, KGB…) in grado di eccellere nella compressione di particolari formati di file piuttosto che altri. Questo significa che, ad ogni nuova release di questi programmi, nasce una vera e propria sfida a chi comprime di più e più velocemente. In queste gare “virtuali”, è possibile stabilire in diversi metodi il tasso di compressione, ma, normalmente, siccome il tasso di compressione può variare a seconda del formato di file usato (che sia un file ascii o binario, che sia una bitmap o un jpeg) di solito si usano dei file di test creati appositamente per tenere in considerazione più aspetti.

Il più famoso è sicuramente il Calgary Corpus, una collezione di testo e dati binari creato da Ian Witten e Tim Bell (due ricercatori dell’Università di Calgary in Nuova Zelanda) nel 1980 e comunemente usato dal 1990 sino al 1997, anno in cui è stato sostituito dal Canterbury Corpus, una collezione di dati creata dall’Università di Canterbury in Nuova Zelanda, creata appunto per migliorare e sostituire il precedente in modo da realizzare migliori benchmark sugli algoritmi di compressione dati di tipo lossless.
Attualmente, però, il Calgary Corpus è ancora molto usato per i test di comparazione tra programmi di archiviazione e compressione.

Se volete sperimentare voi stessi il tasso di compressione dei programmi che usate, da qui è possibile scaricare, via anonymous ftp, il Calgary Corpus, dove è possibile trovare diverse tipologie di file (sempre in lingua inglese) a seconda se si voglia eseguire test su codice sorgente, pacchetti compilati, libri, articoli di giornali, bibliografie, immagini etc: bib, book1, book2, geo, news, obj1, obj2,
paper1, paper2, paper3, paper4, paper5, paper6, pic, progc, progl, progp
.

Calary Corpus

Ultimamente è stato realizzata una nuova homepage per il Calgary Corpus dove è possibile scaricare anche tutto il pacchetto completo del Calgary Corpus, ma, per completezza, è possibile scaricare anche altre collezioni di testo, come il The Canterbury Corpus, The Artificial Corpus, The Large Corpus, The Miscellaneous Corpus.

Non mi resta che augurarvi buon divertimento!

Tag:compressione, kgb, winrar, zip
CONTINUE READING >
0 comments
Ago 29 2007

KGB Archiver: recensione sul miglior tool di compressione esistente anche se estremamente lento

Posted by Antonio Troise
Tweet

KGB Archiver è un tool di compressione gratuito che vanta un’altissimo tasso di compressione, addirittura meglio di 7zip e UHARC. Il programma è dotato di un nuovo formato di compressione, il KGB, che promette migliori compressioni rispetto a programmi più famosi di compressione e può anche criptare files utilizzando AES a 256bit rendendo molto sicura la riservatezza dell’archivio stesso (tanto da renderlo uno dei sistemi di crittografia più potenti al momento conosciuti).

Purtroppo, KGB Archiver, oltre alla lentezza nel comprimere, non supporta alcun formato oltre a quello proprietario KGB e ha dei requisiti hardware minimi piuttosto elevati rispetto a software analoghi (si raccomandano un processore da 1,5GHz e almeno 256MB di RAM).

Anche se KGB Archiver è un programma ancora poco conosciuto, è comunque in grado di mettere a disposizione degli utenti ben 10 diversi livelli di compressione utilizzando l’algoritmo PAQ.

KGB Archiver, inoltre, consente di creare archivi compressi autoestraenti, supporta il drag and drop e si integra con l’interfaccia di Windows aggiungendo alcune pratiche voci al menù contestuale.

Il prodotto non è destinato, almeno per il momento, a sostituire utilità più complesse e complete come WinZip ma è una soluzione particolarmente indicata per chi desidera ridurre al minimo le dimensioni dei propri archivi compressi.
KGB Archiver in modalità “Extreme” (il penultimo livello di compressione) ha evidenziato le migliori prestazioni in tutti i campi rispetto ai vari formati Zip, Rar e 7Zip. Per poter usare il livello di compressione massimo è necessario disporre di un notevole quantitativo di memoria RAM, comunque superiore ad 1 GB.

La minore pesantezza degli archivi creati con KGBArchiver si paga però nei tempi di elaborazione: la creazione di un file compresso (così come l’operazione di estrazione) potrebbe richiedere diversi minuti prima di essere completata.

Confronto con gli altri tool di compressione

Anche se il formato di compressione KGB è eccezionale, è facile intuire, però, che non esiste un programma che comprima meglio di un altro, per la semplice ragione che i migliori programmi sono ottimi in certi settori (cioè con certi tipi di file), e meno in altri. La scelta di un programma di archiviazione, dipende, in pratica, molto dall’utilizzo che se ne intende fare e su quale tipologia di file è stato applicato: potete utilizzare un programma generico, che è veloce e si comporta bene con tutti, oppure un programma più specifico, che eccelle in certe categorie.

Come si può notare da questa comparazione, Uharc è risultato ottimo soprattutto nella compressione di ISO e di file eseguibili (exe), a prezzo comunque di tempi abbastanza elevati (meno nei documenti), WinAce ha fatto un buon lavoro con WAV e BMP, 7z ha brillato negli stessi settori di Uharc (compressione inferiore, ma anche tempi molto più contenuti), mentre Stuffit X è risultato l’unico valido per i file di immagine JPG. Il vecchio WinZip si è difeso tutto sommato bene, se non altro per i tempi molto contenuti.

KGB Archiver, invece, ha ottenuto ottimi risultati quasi ovunque, ma a costo di tempi altissimi (oltre 10 volte il tempo rispetto a WinRar già con l’opzione Normal, oltre 90 volte con l’opzione Maximum). E’ stato tuttavia molto interessante vederlo superare gli altri nella maggior parte dei test e prenderlo come punto di riferimento.

Una delle cose che, osservando i dati del confronto, più riescono a incuriosire, è quanto un programma specifico possa migliorare rispetto ad uno generico: è il caso dei programmi specifici per la compressione audio, che hanno letteralmente travolto (sia come compressione che come tempi) quelli generici, o anche il caso delle immagini jpeg, in cui Stuffit X ha ottenuto risultati inarrivabili (24% di compressione contro percentuali vicine allo zero).

Considerando il rapporto tra compressione e velocità, è possibile in definitiva indicare WinRar come il programma più affidabile, dato che è sempre risultato nelle prime posizioni come compressione, e con tempi costantemente tra i migliori. Non è una vittoria netta, tuttavia è stato il più costante con tutti i tipi di file, anche se programmi interamente open source o freeware (7z, Uharc, KGB Archiver) non hanno minimamente sfigurato, ma che anzi, tranne nel caso delle immagini jpeg, hanno validamente tenuto testa a tutti gli altri.

Tag:compressione, kgb, paq, winrar, zip
CONTINUE READING >
3 comments
Ott 24 2006

SmsZipper

Posted by Antonio Troise
Tweet

SMS Zipper Avete mai pensato di comprimere la lunghezza del testo, così da condensare magari 2 messaggi in uno?
SmsZipper è un’applicazione brevettata dall’università di Aalborg e sviluppata in Java, che serve a comprimere i messaggi di testo (SMS) di un fattore variabile tra 2 e 3, a seconda del contenuto (in realtà sono possibili anche compressioni piu alte, ma non in questa versione gratuita). Sebbene sia disponibile anche una versione in Italiano, la User Interface è sempre in inglese, ma -chiariscono sul sito- la compressione è maggiore se si sceglie di scrivere un SMS usando la versione della lingua corrispondente a quella del testo da inviare.

Tag:cellulare, compressione, java, sms, zip
CONTINUE READING >
0 comments
SeguiPrezzi - Risparmia con Amazon.it

Categorie

Commenti Recenti

  • Antonio Troise on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Fioredicollina on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Antonio Troise on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Emanuele on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Luca on iDatabase: la valida alternativa di Bento per macOS e iOS per i database personali

Meta

  • Accedi
  • Entries RSS
  • Comments RSS
  • WordPress.org

Friends Link

  • GamerTagMatch
  • SeguiPrezzi.it – Risparmia con Amazon.it
  • Trendy Nail

Seguimi su:

  • facebook
  • twitter
  • rss
Creative Commons License
Levysoft by Antonio Troise is licensed under a Creative Commons Attribuzione-Non commerciale 2.5 Italia License.
© Copyright 2004 - 2014 - Levysoft by Antonio Troise