Si tenéis la versión 10 del Flash Player, puede que algunas canciones de cualquier página se os escuchen como distorsionadas. El problema no está en el mp3, es un bug de esta versión del Player al reproducir mp3 a 48khz. No se produce esa distorsión cuando es un mp3 a 44Khz.
Ayer mismo salió la actualización que arregla este bug (10.0.22.87), puedes bajarla desde Adobe: http://get.adobe.com/flashplayer/
Si tratas con FLASH seguro que alguna vez te has topado con esta “característica”. Si no usas archivos externos no hay ningún problema, pero si haces uso de archivos de configuración externos en formato txt, carga de imágenes externas, te habrás dado cuenta de que no importa donde hayas puesto tu SWF en el arbol de directorios, la ruta relativa a esos archivos externos siempre se hace desde el HTML donde se carga.
Por ejemplo tienes un SFW visor.swf y una imagen arbol.jpg que están dentro de la carpeta MULTIMEDIA colgando de la raiz que es donde está tu index.html.
Al editar el flash lo lígico es que pongas que la ruta de la imagen sea “arbol.jpg“, ya que está en la misma carpeta que la imagen, y si abrimos el SWF a pelo comprobarás que la carga correctamente. El problema viene cuando cargamos el SWF en el index.html, cosa bastante normal. El flash por defecto tomará la ruta actual de carga, no donde se encuentra el archivo SWF realmente, con lo que buscará en este caso en el raiz el archivo arbol.jpg y no lo encontrará.
Una solución es que si sabemos que el flash se va a cargar en el index.html que está en raiz, cambiar la ruta de carga del flash a “multimedia/arbol.jpg” y funcionará. Para sitios sencillos esto funciona bien, pero ¿que pasa cuando queremos cargar ese flash en otro HTML que no está en raiz?, no funcionará, y por lo tanto no podemos usar el mismo SWF para 2 lugares (o 3, 7, 200) siendo que el visor es el mismo. También surgen problemas cuando usamos gestores de contenido con URL dinamicas, tipo permalinks, etc, donde una dirección como www.nerv.es/blog/titulo-del-articulo dará error al cargar el visor ya que el flash se cree que está en una estructura de directorios “/blog/titulo-del-articulo” que no existe físicamente.
La mejor solución es usar un atributo que no es muy conocido llamado base.
Si en el código de carga del flash usamos:
<param name=”base” value=”.”>
para <object> y para <embed>:
base=”.”
No importa desde donde se cargue el archivo SWF que la ruta base para él será donde esté ubicado realmente dentro del arbol de directorios. Con esto conseguimos que funciones siempre sin importar desde donde ser carge. ( dentro del mismo dominio al menos )
Si estás haciendo alguna aplicación en flash que corre sobre un servidor https puede que te encuentres con un error que abortará la ejecución. Te dirá que no puede abrir la dirección pedida.
Si tienes ese problema prueba con alguna de estas dos soluciones:
1. Sube el archivo crossdomain.xml a tu servidor https.
<cross-domain-policy>
<allow-access-from domain=”*”/>
</cross-domain-policy>
2. Inserta las siguientes líneas en tu actionscript:
System.security.allowInsecureDomain(”www.tudominio.com”);
System.security.allowDomain(”www.tudominio.com”);
Las dos soluciones parece que funcionan bien.
Los preloaders en Flash pueden dar dolores de cabeza algunas veces, pero hay una funcionalidad oculta dentro del Flash Player ( el que salta para testear nuestra película pulsando CTRL+ENTER, por ejemplo) que te ayudará a resolver los problemas mucho más fácil. El visor de anchos de banda.
Usando el visor:
Una vez abierto el visor, tienes muchas información a tu disposición. Observa que tienes todas las propiedades del SWF, incluido tamaño y tiempos de carga. Esta información es muy útil cuando estás intentando bajar el peso del archivo.
En cuanto al preloader, la propiedad más util en este caso es el gráfico frame por frame. La mayoría de los preloaders van del frame 1 al 2 y del 2 al 1 todo el rato hasta que todos los bytes se cargan y van hacia el frame 3. Prueba tu preloader frame por frame y asegúrate que tu actionscript se comporta correctamente. Puedes ver instantáneamente si tu película salta a un frame que no debería.
El problema más común al hacer un preloader.
La primera pregunta de todos los foros que hablar sobre los problemas de los preloaders es “Porqué no puedo ver mi preloader hasta que no está casi del todo cargado (70%-90%)?
Este artículo tiene ya algún tiempo pero me ha parecido interesante traducir esta entrevista. Sobre todo la parte referente a la herramienta de extracción de texto.
Como todos sabéis, usar Flash para toda la página siempre ha sido un gran problema para la optimización de los motores de búsqueda. Simplemente no hay contenido para los motores de búsqueda que puedan indexar.
Así que cuando me enteré de que Google podía indexar el contenido de los archivos Flash, me sorprendió. Al parecer, este notable descubrimiento ha pasado casi inadvertido en la comunidad SEO.
Sin embargo, como probablemente ya sabes, Google siempre ha sido pionero en indexar contenido de diferentes formatos: Archivos PDF, .DOC, etc. Google también ha hecho muchos avances para indexar el contenido dinámico.
Y ahora es el primer motor de búsqueda en indexar Flash, otro paso adelante en la industria SEO.
Entonces, ¿por qué Flash presentó estos problemas en el pasado?
Antecedentes de Flash y SEO
Con una pagina principal en Flash surge el problema de decirle al buscador de que trata la página. Sin este texto, los motores de búsqueda no tienen nada que indexar. Por lo tanto, la página principal rara vez está bien posicionada, a menos que factores externos a la página como enlaces entrantes la hagan más popular.
En el pasado, se han hecho pocas pruebas y dispersas para solucionar esta dificultad. Esto puso las cosas muy difíciles a las empresas que querían mostrar una rica experiencia de usuario con una página en Flash, como las empresas de diseño gráfico, estudios fotográficos, empresas de diseño de páginas web, etc.
Asi, estas empresas a menudo sacrificaban el ranking por la experiencia de usuario, ya que rara vez se puede tener tanto tiempo para seguir todas las directrices que requieren los motores de búsqueda.
Entrevista a Michael Marshall
Cuando me enteré de que google indexaba flash por Michael Marshall, creador de ThemeMaster y moderador de nuestros cursos de marketing de motores de búsqueda, y de los fascinantes descubrimientos que había hecho, inmediatamente quería una entrevista con él.
A raíz de la reestructuración de la página de nerv me di cuenta de que Google había indexado los textos de unos SWF que tenía en una sección y sin embargo otros no. Me refiero a los 3 archivos Flash que hay en Portada y a los otros 3 dentro de la sección de Diseño Web y Servicios. Estuve un tiempo buscando la razón de porque había indexado los textos de los 3 últimos SWF y no los de portada, si eran casi identicos. Hasta que caí que los interiores estaban exportados como Flash versión 7 y los nuevos de portada en la versión 8, que por lo visto Google aún no puede leer por alguna razón que desconozco.
Eso por una parte, más tarde me encontré con una herramienta para extraer un HTML del SWF, y sacar los textos que pueden ser indexables. La herramienta se llama swf2HTML, es un poco fea porque tienes que ejecutarla desde la línea de comandos ( en la opción Ejecutar.. en el menu inicio, escribe “cmd”, sin comillas ), pero funciona bien. La sintaxis básica para que te muestre los textos que puede sacar de tu SWF es la siguiente:
C:\swf2html tuarchivoflash.swf
Si es que teneis el ejecutable swf2html.exe en el disco C: y el SWF en la misma ruta. De todas maneras dentro de la carpeta tenéis instrucciones con la sintaxis de uso.
Haciendo pruebas con esta herramienta pude verificar que no extraía ningún texto de los SWF de portada y sí de los de la sección interior.
Podéis leer algo más en la entrevista a Michael Marshall.
Esta característica…
Estamos hablando del tiempo de respuesta.
En el mundo real, tocas algo y se mueve. No tienes que esperar a que el universo tarde 3 segundos en calcular la nueva posición del objeto. Una respuesta inmediata es lo que espera el cerebro. Cualquier aplicación te hace esperar, esto mata el flujo de las acciones y el disfrute de la aplicación.
Sonic tenía un tiempo de respuesta inmediato. ¿Lo tiene tu aplicación?
Piensa sobre usar un ordenador 8 horas al día. Piensa cuanto tiempo estás esperando cosas:
Coge estos tiempos y multiplícalos por las millones de veces que los has experimentado y tendrás un montón de tu tiempo malgastado.
En Flash 7, cada vez que escalabamos o rotabamos una imágenen se suavizaba automáticamente. Sin importar que la imagen se cargara dinámicamente o incrustada. El suavizado da un aspecto suave a la imagen, sin él resulta cortante y con bordes duros, es decir que se notan los pixels demasiado.
Ahora con Flash 9 cuando cargas dinámicamente una imagen usando la clase Loader, el suavizado está desactivado por defecto. El método recomendado para suavizar la imagen es copiar el contenido en un objeto Bitmap y permitir el suavizado sobre el mismo. El problema es que las imágenes que están alojadas en otro servidor, no tiene acceso BitmapData, por lo que no hay forma de suavizar la imagen.
Hay 2 soluciones, las cuales lamentablemente no son factibles en la mayor parte de los casos:
En mi opinión, debería ser posible obtener el suavizado con imágenes alojadas en otros servidores. Se podría solucionar de 2 formas:
Si quieres que Adobe añada la propiedad de suavizado a la clase Loader en su próxima versión del Flash Player, puedes pedirlo en la página de consulta de adobe.
Nota del traductor: Creo que no hay mas opciones que estas pero si conoceis alguna manera de hacerlo podeis compartirlo en los comentarios y actualizaré el post.
(libre traducción de Airtight Interactive)
Recibir artículos por email