Sign in to follow this  
Guest

MULTIMEDIA

Recommended Posts

Guest

A scuola abbiamo un iMac 400 DV collegato in una rete di PC; system 10.2.3, 320 MB di RAM. In rete non vi sono problemi, tutto funziona perfettamente. Però ho un grosso problema: quando avvio Internet explorer 5.2.2 questo va continuamente in crash; quando va bene, riesco a rimanere collegato per dieci minuti! Ho notato che i crash sono frequenti con alcuni siti: ilsole24ore.com è il più tremendo, ma anche con macworld.it ogni tanto dà problemi. E' un problema del software (che ho reinstallato più volte) o mi manca qualche tool? Vi prego, datemi una soluzione !!!.

Share this post


Link to post
Share on other sites
Guest

Butta Explorer e installa, a tua scelta:

Netscape 7

Chimera

Mozilla

Safari

Share this post


Link to post
Share on other sites

Installali tutti. Anche Opera. E provali tutti.

Se un browser va in crash con un sito particolare, verifica che il sito sia valido (con i robot W3C). Non e' detto che sia colpa del browser.

Share this post


Link to post
Share on other sites
Guest

io personalmente mi sono trovato divinamente con Chimera Navigator! Essendo un Mac-integralista, da quando Safari mi è resuscitato uso SOLO safari Posted Image

se dovessi fare una classifica di browser per Mac OSX dico:

1) Chimera, (per i tabs)

2) Safari, (per la velocità e ...Posted Image )

3) OmniWeb, (efficiente)

4) Opera, (veloce, ma grezzo)

6) Mozilla, (comodo per i tabs, ma pesante)

7) Internet Explorer, (un boc*hino di browser, su tutte le piattaforme, ma in Italia gli facciamo i siti ad hoc Posted Image )

ciao vincenzo

Share this post


Link to post
Share on other sites
Guest

Se un browser va in crash guardando un determinato sito, è colpa del browser: dovrebbe essere stabile anche con siti scritti male.

Non è ovvio?

Share this post


Link to post
Share on other sites
Guest

<font color="ff0000">Ma mp3 è meno complesso di AAC, ed è così diffuso che ormai lo leggono anche gli orologi. Secondo me, lasciando l'audio in MP3 non si avrebbero problemi di compatibilità, mentre la qualità ne guadagnerebbe, perché si eviterebbe la ricompressione.</font>

Esattissimo. Esiste poi solo un mp3 come formato, per cui non ci sono problemi: mp3pro è praticamente sconosciuto e non porta a vantaggi sopra i 128 kbps, che sono peraltro veramente pochi: ora che uso le casse dello stereo col computer trovo fastidiosi anche gli mp3 a 192, vado bene solo con i >256.

<font color="ff6000">Purtroppo le varianti nascono come i funghi; la gente le usa pensando di ottenere una migliore qualità e non funziona più niente... </font>

Esempio? citiamo però quelle diffuse: mp3pro non esiste, aac non è mp3, vqf neppure, poi?

Io comunque (oltre a sconsigliare la ricompressione nella TOTALITÀ dei casi) consiglio OGG. Almeno è free.

Share this post


Link to post
Share on other sites

Olaf: Se un browser va in crash guardando un determinato sito, è colpa del browser: dovrebbe essere stabile anche con siti scritti male.

Non è ovvio?

No. Non e' ovvio per niente. La procedura ormai dovresti conoscerla:

1) effettuare la convalida del codice sorgente per verificare che non contenga errori critici

2) se e' valido, provare a leggerlo con vari browser per vedere quali sono conformi agli Standard e quali non lo sono affatto

3) se non e' valido, inviare un email allo sviluppatore del sito per dirgli che se non si adegua agli Standard del W3C danneggia tutti gli utenti di Internet

Share this post


Link to post
Share on other sites
Guest

OK, però io non accetto che un browser crashi mentre guardo una pagina che qualcuno ha scritto male.

Un browser deve leggerle tutte, al limite male (se il codice è errato), però non deve mai andare in crash.

Share this post


Link to post
Share on other sites

Olaf,

Ovviamente è meglio non ripetere una compressione lossy ma per fare un ISMA compliant credo tu lo debba fare (credo perchè le specifiche - non le indiscrezioni - sono accessibili solo dai soci). Tutti gli Enc MPEG-4 che conosco (Sorenson Squeeze in testa) usano l'audio AAC.

Il discorso, ancora ovviamente, non vale quando la sorgente è compressa con un algoritmo lossless come gli MPEG-audio che usano l' MLP (Meridian Lossless Package)

http://www.ambisonic.net/mlp.html

http://www.meridian-audio.com/welcome.htm

o per i SACD che usano la campionatura differenziale ad un bit.

Non vale per codec video quali huffyuv per PC

http://math.berkeley.edu/~benrg/

oppure il nuovo SheerVideo Pro per Mac

http://bitjazz.com/sheer/

Gianni

Share this post


Link to post
Share on other sites

Mandare in crash un browser e' molto facile. Come e' facile agire sul codice 'balcanizzato' per far si' che il tal browser carichi agevolmente la pagina e quell'altro faccia fatica.

Per avere dei riscontri oggettivi bisogna testare i browser con le pagine valide. Altrimenti si puo' dire tutto e il contrario di tutto.

HTML e' un linguaggio che ammette errori, nel senso che il browser riesce spesso a caricare la pagina - adattandola in qualche modo - anche in presenza di qualche magagna. Ma XML e' tutta un'altra musica: non ammette il minimo errore di sintassi.

Dunque non ha senso fare dei confronti sul codice balcanizzato o sui siti che mettono una etichetta 'Transitional': bisogna cominciare a ragionare diversamente, impostando la marcatura in base a XHTML 1 (minimo, ma se usate la 1.1 non sbagliate) e usare CSS per la presentazione.

Anche i telefoni UMTS - come i piu' recenti cellulari GPRS tipo il Sony-Ericsson P800 e il Nokia 3650 - supportano XHTML Basic e CSS 1 Mobile Profile.

Traetene le conseguenze. Adeguatevi agli Standard. E se Apple-Microsoft vi fa perdere tempo e denaro per testare le vostre pagine con Safari - che e' largamente incompleto - inviatele email di protesta e di indignazione.

Share this post


Link to post
Share on other sites

Difatti XML non si diffonderà MAI per fare pagine web, perchè uno NON PUO' rompere le balle ai grafici con le megapippe. Ne' si può umanamente pensare che l'output XML di programmi come QuarkXpress o Microsoft word (pieno al 99% di tag che consentono la bidirezionalità di quei programmi della mia emerita fava) venga messo in produzione da gente che in teoria dovrebbe sapere quello che c'è dentro (noi poveri webmaster).

Ricordo che 3 anni fa c'era che diceva che nel giro di qualche settimana tutti i siti del mondo sarebbero stati in XML.

Seee. Questa fava è in XML.

Scusate ma l'argomento XML mi fa incazzare perchè tutti ne parlano e nessuno ci capisce nulla.

(Alberto, NON mi sto riferendo a te, non andare in paranoia!).

Share this post


Link to post
Share on other sites

Chest > 'XML non si diffonderà MAI per fare pagine web, perchè uno NON PUO' rompere le balle ai grafici con le megapippe'

NS 7 ha un sontuoso supporto di XSLT (la versione 'estensibile' di CSS). In attesa che anche gli altri browser supportino in pieno XML e XSLT ci possiamo consolare con XHTML e CSS: il primo e' facilissimo. E col secondo puoi riprodurre qualunque tipo di layout (giuro!). Le megapippe ci saranno fino a quando esistera' un solo browser che supporta questi Standard al cento per cento: il che ci costringe a limitare la nostra creativita' per farli coesistere tutti. E i layout diventano spartani (comunque non peggiori di quelli fatti con le tabelle dai piu' famosi designer del mondo).

Poi bisogna partire dal concetto di scrivere *a mano* le nostre pagine, perche' se ci affidiamo alla esportazione in XML di Quark XPress e altre menate simili, le megapippe sono inevitabili.

La pubblicita' e' ingannevole. Ti faccio un esempio: nel sito di Handsprings ci sono foto del 'Treo' in cui si vede il display che mostra svariate immagini a colori. Poi scarichi la documentazione per gli sviluppatori e ti dicono in buona sostanza: 'Andateci piano con le immagini, perche' questi PDA fanno una fatica boia a caricarle'.

>'Ricordo che 3 anni fa c'era chi diceva che nel giro di qualche settimana tutti i siti del mondo sarebbero stati in XML'

Negroponte non azzecca mai le previsioni in senso 'temporale': a XML ci arriveremo, ma non subito.

>'Scusate ma l'argomento XML mi fa incazzare perchè tutti ne parlano e nessuno ci capisce nulla'

Scrivere i manuali e' di gran lunga l'attivita' piu' dispendiosa in termini di tempo. Forse e' anche per questo che le documentazioni del W3C sono lacunose e vengono pubblicate in maniera assai disordinata, cervellotica e delirante.

Io non ho approfondito piu' di tanto lo studio di XML/XSLT perche' ad un certo punto mi trovo a dover fare i conti solo con NS 7. Allora punto tutto su XHTML/CSS e attendo tempi migliori.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this