miércoles, 16 de diciembre de 2015

Decodificador de imagenes JPG para Gameboy Advance

Descarga aquí.
Bueno, pues como sabreis la GBA no fue muy conocida por la calidad y cantidad de imagenes usadas en juegos. Esto es porque una unica imagen que ocupe toda la pantalla (240x160) sin comprimir ocupa  37 KB en modo 256 colores (baja calidad) o 74 KB a 32.768 colores (alta calidad, apenas usado). Por esto se me ocurrió crear el primer decodificador de ficheros JPG que permiten mostrar estos ficheros de imagen de alta calidad que no ocuparían mas de 15 KB en este formato a resolución nativa en una GameBoy.


Este ROM habría sido un gran adelanto para la consola. Lastima que en 2001 solo era un crio :')

Tenia pensado crear un programa que pudiera adjuntar vuestras propias imagenes al ROM, pero dudo que mas de 1 o 2 personas lo utilizasen, asi que lo abandoné.
En el zip teneis un ROM de 104 KB con 9 imagenes "random" en alta calidad que muestra la presentacion de imagenes junto a los *.jpg utilizados. Si mirais dentro del ROM con un editor hexadecimal comprobareis que estos *.jpg estan contenidos dentro del ROM. A continuación detalles tecnicos:


Resulta que hace unos días encontré el codigo para un decodificador de imagenes orientado a dispositivos embebidos (Como puede ser un marco de fotos digital) el cual era muy simple, y estaba orientado a procesadores con pocas capacidades como el Z80.
Se trata de TJpgDec y lo primero que se me ocurrio al verlo es que podia adaptarlo para hacerlo funcionar en la GameBoy (Plataforma con la cual ya estaba familiarizado) pero antes de intentarlo siquiera me di cuenta de que en la GBC la escasa paleta de colores, resolución, memoria, y potencia del procesador, iban a hacer del trabajo algo inutil.
Viendo esto, informandome sobre las caracteristicas tecnicas de su sucesora, la Game Boy Advance y sobre los distintos modos graficos que tiene, vi que en GBA todo cuadraba, y podria implementar sin problemas el primer decodificador de archivos JPG para GameBoy de la historia, usando para esto el compilador DevKit Advance r5 beta 3 compilando siempre con el maximo de optimizaciones (-O3).

Puestos al trabajo tuve que retocar el codigo de TJpgDec para que en primer lugar, no trabajase con archivos, sino con array de bytes con el contenido de los archivos JPG que se incluirian dentro del ROM, reemplazanto para esto todas las intrucciones como fopen() o fseek() por un codigo que haria su correspondiente funcionamiento en los arrays de bytes.
Cuando ya habia acabado y el codigo me habia compilado con exito vi que salian colores sin sentido y la imagen apenas se reconocia.

De los distintos modos graficos que tiene la GBA yo utilizo el modo 3.

Como el modo 3 trabajaba con pixeles de 16 bit usé el modo RGB565 del decodificador, pero me di cuenta de que la GBA no usaba RGB565, sino un BGR555 en el que deja sin usar el bit mas significativo de estos 16 bit (Apenas encontré documentación sobre los modos graficos). Por esto, otra vez me toco modificar el codigo de TJpgDec para que convirtiera a el espacio de color de la GBA tal y como se ve en la imagen.

El programa final compilado al maximo de optimizaciones (-O3) le lleva al procesador de la GBA unos 2-3 segundos para decodificar un archivo, es por esto que mi ROM de prueba se trata de una simple presentación de imagenes en la que el procesador trabaja siempre al 100% para cargar lo antes posible la siguiente imagen

jueves, 10 de diciembre de 2015

Bug grave en Lovoo: El like infinito

En esta ocasion y viendo que mi post vulnerabilidades de Badoo tuvo un existo mucho mayor del esperado, decidí crearme un perfil de la red social Lovoo solo para comprobar su seguridad como ya hice con Badoo, no obstante, tras varios test, la unica vulnerabilidad grave que encontré fue la siguiente:

Bug del like infinito (Fallo grave):

Al parecer recientemente cambiaron la interfaz de Lovoo añadiendo la funcion de dar likes a las fotos. Estas fotos guardan la referencia de las personas que dieron like y un contador de likes aparte que hace mucho mas simple las consultas a los perfiles de usuario a los servidores. No obstante, por un descuido de los desarrolladores, cuando pulsas el boton like en una foto el contador incrementa, pero si decides quitar el like, este no decrementa. Como resultado, si haces click repetidamente en el boton del like, puedes dar a esa foto los likes que quieras, incluso si la foto es tuya propia. Este proceso se puede automatizar con programas como Fiddler web debugger. Usando Fiddler, se podría automatizar el proceso durante horas si se quisiera (obteniendo miles y miles de likes), no esta del todo comprobado pero yo lo hice funcionar durante 10 minutos obteniendo mas de 1000 likes y no hay captchas ni nada que te detenga.

Captchas poderosos muy mal utilizados:
La version web de Lovoo utiliza un metodo de captcha muy poderoso de "reCaptcha" en el que el usuario debe seleccionar 2 o 3 fotos con muy mala calidad y a veces manipuladas que contengan lo que se le pide (Se permite seleccionar una imagen incorrecta como maximo). Este captcha solo se usa en las nuevas solicitudes de chat, los cuales tienen limite diario, lo cual convierte a este capcha en algo inutil.

A continuación os comento rápidamente otras vulnerabilidades menos importantes relacionadas con las fechas y horas, las cuales deberían estar ocultas al usuario:

Revelación fecha de creación de los usuarios:
Igual que ocurria con Badoo, en Lovoo el ID de usuario consiste en 24 cifras hexadecimales, de las cuales solo las primeras son la ID de usuario, siendo las ultimas una verificación para que la gente no vaya curioseando quien se creó la cuenta de Lovoo 5 segundos despues como si se podia hacer en Badoo. Estas IDs de usuario se crean secuencialmente permitiendo estimar cuanto tiempo lleva creada una cuenta.

Fechas y horas precisas:
Pero... La cosa no acaba aquí: Cuando la aplicación accede a un usuario, sus fotos tienen una fecha de subida y el usuario una fecha de ultima conexion entre otras fechas. Estas se muestra en la web con mensajes que dan muy poco detalle como "Hace un par de semanas" o "Hace una hora", pero si vemos la respuesta que ha mandado el servidor, dentro de la respuesta encontraremos parametros como "CreatedAt" en el caso de las fotos o "LastOnlineTime" en el caso de la fecha de ultima conexión, que contienen un numero.
Este numero es equivalente al entero de 32 bits que transformado en time_t es la fecha y hora GMT con precisión de un segundo.


martes, 8 de diciembre de 2015

Superresolution: Conseguir fotos de 20 MP con una camara de 5 MP ¿Merece la pena?

En este post, tras hablaros de los nuevos formatos de compresion de imagenes os voy a hablar de una forma para conseguir fotos de una resolución mayor a la que os permita vuestra camara mediante interpolacion cubica y mediante superresolution. Para ello yo usaré el programa GIMP.
Os muestro un detalle de la siguiente imagen sacada con la camara de un Iphone 4 (5 MP) aumentadas tras aplicarle los dos metodos.

Estos metodos, no obstante, no permiten obtener la misma calidad que si usamos una camara de mayor resolución, pero si dan una mejor impresion. En mi opinion estos metodos (y sobre todo el primero) no deberian usarse con frecuencia ya que suponen un desperdicio de memoria, ya que se obtienen fotos con mas megapixeles pero con una calidad inferior a una imagen obtenida a esos mismos megapixeles. No obstante, si por ejemplo se quiere obtener un fondo de pantalla con mayor calidad si que podria resultar util el metodo superresolution.


-Interpolación cubica: 
Como ya sabreis algunos, mediante la interpolación cubica es posible aumentar la resolución de una imagen prediciendo cuales serian los pixeles intermedios. Estos pixeles son "inventados" pero al añadirlos pueden dar una sensacion de mayor calidad de imagen.

En Gimp, cuando cambias el tamaño de una imagen, se hace por interpolación cubica por defecto.

-Superresolution:
Consiste en realizar varias fotos iguales (en los ejemplos uso 4 fotos), aumentarlas mediante interpolación cubica y superponerlas unas con otras, obteniendo mayor calidad que si solo aplicamos interpolacion cubica a una imagen.

Para aplicar superresolution en Gimp, se deben abrir las imagenes como capas, aumentarlas con interpolacion cubica, añadirles transparencia, y alinearlas manualmente.

-Conclusiones:
Vosotros mismos podeis ver y juzgar si existe diferencia entre la foto original y la foto con superresolution. Desde mi punto de vista el hecho de superponer varias fotos (superresolution) la mayor mejora que da a la imagen es reducir los pixeles "defectuosos" que obtenemos cuando una foto es demasiado oscura y la hacemos con una camara de un movil, pero tampoco puede hacer magia, y tal vez en vez de aumentar de 5 MP a 20 MP seria mas viable aumentar a resoluciones mas aceptables como 10 MP.

domingo, 29 de noviembre de 2015

¿Cual es el mejor formato de imagen? Buscando el futuro sucesor del JPG

Primero hablé de los nuevos y mejores formatos de audio, luego de los formatos de compresion de datos, y ahora para finalizar mis post sobre comparativas de nuevos formatos, voy a hablaros sobre como esta el tema en la compresión de imágenes:






Aquí podéis ver como queda una imagen PNG de 800x600 comprimida al mismo tamaño (24 KB) en varios formatos para que comprobéis vosotros mismos las diferencias.




Si os interesan las comparativas de estos codecs os recomiendo acceder al siguiente enlace:

http://xooyoozoo.github.io/yolo-octo-bugfixes


donde podéis comprobar vosotros mismos las diferencias de compresión de todos estos formatos de forma interactiva con gran variedad de imágenes.


Cuando apareció JPEG fue una revolución en cuanto a fotografía digital, ya que su calidad de compresión era muy buena. Mas tarde apareció una mejora de este llamado JPEG2000 que trabajaba de forma distinta a como lo hacia JPG. Esta mejora al ser muy poca, y no ser compatible con los anteriores decodificadores de JPEG, no adquirió mucha popularidad.

Mas tarde, de manos de Google llegó WebP, un formato de imagen orientado a la web y con una eficiencia notablemente mayor.
Este formato lo bueno que tenia es que era soportado de forma nativa por Google Chrome, no obstante es un formato que a los demás navegadores les esta costando aceptar al pertenecer a Google. Es por esto, que hoy dia hay muchas paginas web que detectan si el navegador que se esta usando es Chrome, Opera, o cualquier otro navegador compatible para cargar sus imágenes en formato WebP.
Cuando se detecta que el navegador no es compatible con WebP, las paginas cargan su equivalente en JPG con mayor tamaño de imagen (mas tiempo de carga) o menor calidad.

Por ultimo y gracias a Fabrice Bellard's (http://bellard.org/) también conocido por otros grandes proyectos como FFMPEG o QEMU, Apareció el año pasado un codec de imagen mejor aun basado en la codificación de los frames en el codec de video H265.
Este codec conocido como BPG (Better Portable Graphics) ya consigue una notable diferencia frente a JPEG, pero de momento ni los navegadores ni los visores/editores de imagenes quieren reconocerlo.
Por suerte, existe un pequeño fichero Javascript (también desarrollado por Fabrice) que permite visualizar estos archivos en cualquier navegador, y mostrar imágenes de este formato en cualquier sitio web.

Desde la aparición de JPG han aparecido multitud de formatos intentando superarlo y ganar popularidad. Ademas de los formatos que aqui os he enseñado existen otros mas como JPEG-XR o PGF pero ninguno de estos han ganado popularidad.
Con JPG pasa lo mismo que con MP3, son formatos que están desde siempre y aunque no son los mejores,  no nos importa usarlos en una época donde la memoria cada vez es mas barata.

Recordad que podéis comentar si tenéis alguna duda o queréis decir algo. No es necesario registrarse para comentar.

viernes, 4 de septiembre de 2015

Vuelve la aventura de Flappy... Esta vez en HTML5

Descarga el juego aquí.

El juego tiene soporte tactil y de teclado. En el teclado debeis usar las teclas de direccion izquierda, derecha, y arriba. En soportes tactiles podeis moveros pulsando a la izquierda o a la derecha inferior de la pantalla, ademas, si pulsais en la zona superior de la pantalla, tambien saltareis.

Bueno, pues como ya creo que comenté, mi juego de Gameboy "La aventura de Flappy" (Mas info aqui) tuvo menos descargas de las esperadas. Probablemente por la incomodidad de tener que usar emulador y lo basto que podia parecer a simple vista el formato GameBoy.
Pues ahora esta renovado, y para ello he utilizado un formato que aunque ahora no este muy de moda, parece que lo estará en el futuro, el formato HTML5 (Javascript).
Obviamente, Javascript utiliza compilacion en tiempo de ejecución, lo que significa que disponeis del codigo fuente, y no solo eso, sino que ademas esta comentado.
Aunque al inicio pone que es la versión 1.1, no penseis que aparecerán mas versiones. No tengo en mente seguir trabajando en el juego, sino que al ser codigo libre, os invito si os gustó el juego a hacerle modificaciones, editarle los niveles o incluso hacer una segunda parte del juego. (Siempre que me hagais referencia a mi, en el caso de que publicaseis una version modificada)

Mejoras de la versión 1.1 respecto a anteriores:

-El juego es compatible con muchos mas navegadores y dispositivos con los que no funcionaba la beta v.0.1, incluido IE.

-Los niveles han sido modificados en dos ocasiones, tanto en flores como en estructura para la v.1.0 y otra vez para la v.1.1, para darle mas emocion al juego.

-Con la versión 1.1, el juego ahora se adapta al tamaño de la ventana del navegador o la pantalla del movil.

-Con la version 1.1 El juego se detiene cuando el movil no esta en modo apaisado o el navegador no tiene el tamaño correcto, mostrando un mensaje.

-La pantalla de inicio de la versión 1.1 esta totalmente renovada, y ahora muestra unas instrucciones basicas del juego

Para la version 1.1, los menus iban a tener su propia música (On your own - Vibro DwarfsLMIX, Milk inc.) pero al final no se añadió para evitar que la aplicación ocupase mas memoria.

Versión 1.2 disponible junto con Flappy Adventure 2.
-Ahora flappy se inclina en los saltos
-Ahora la musica entra en bucle al terminar
-HUD del jefe final mejorado
-Mensaje del jefe final mejorado
-Jefe final ahora tiene sonidos
-...

viernes, 21 de agosto de 2015

Experimento casero: imprimir en B/N y recomponer en RGB

Hola de vuelta a todos. Este verano se ha notado mi ausencia por aqui, pero... ¿A quien le importa?
Bueno, pues queria traeros otro de mis experimentos caseros sin ninguna utilidad real para que os fascineis por la informatica (o al menos se os quite el aburrimiento durante 5 min).
Bueno, pues esta idea es producto de lo que pasa cuando se te acaba el cartucho de tinta a color en la impresora. Lo que hacemos en este "experimento" es imprimir una imagen en B/N 3 veces, correspondientes a los 3 canales rojo, verde y azul de las imagenes a color. Mas tarde escaneamos estas tres imagenes impresas en B/N, y recomponemos la 3 imagenes obteniendo la imagen a color.
Para ello se puede usar el Gimp, el cual si lo sabeis usar es intuitivo, pero si quereis realizar el experimento y teneis alguna duda podeis comentar aqui.
Basicamente lo que hacemos en Gimp es, con la imagen original vamos a la seccion de los canales rojo azul y verde y los arrastramos a la seccion capas. Las colocamos separadas, e imprimimos en B/N.
Despues de escanear, recortamos del escaneo tres capas del mismo tamaño con las tres imagenes en B/N. Para el siguente paso debemos estar en modo escala de Grises. Ahora si nos vamos a Colores>Componentes>Componer, podremos obtener la imagen resultante de componer los tres canales B/N.

En las imagenes podeis ver el experimento realizado con una foto del ayuntamiento de Hellín: Arriba del todo la imagen original, despues una foto de como quedaría el folio impreso en B/N y al final del post el resultado final al escanear y componer en RGB.



martes, 16 de junio de 2015

Actualizacion Insta-script

Bueno, pues recientemente empecé a seguir nueva gente en Instagram, y viendo que muchos no me seguian de vuelta, decidí organizar un evento en el que dejaría de seguir a todos los que no me siguieran de vuelta en un mismo día, a la vez que celebrariamos una fiesta al mas puro estílo hardcore. Se tarta de #UnFollowProjectFest2015.


Bueno, pues tonterías aparte, con mi reciente incremento de seguidos y seguidores en mi cuenta, me di cuenta al ejecutarlo, de que el instascript que hice tiene una gran limitación: Solo carga los primeros 200 seguidos/seguidores, ya que la pagina de texto plano de Instagram que carga los seguidos seguidores esta limitado a 200, dando un link a una pagina con los siguientes repetidamente hasta que ya no hay mas y no hay mas links. Bueno pues he actualizado el post y ahora si teneis mas de 200 seguidores/seguidos el script funcionará correctamente. Cualquier comentario o duda aquí.

sábado, 13 de junio de 2015

Transmitir datos por la toma de auriculares: archivos de cualquier tipo

Bueno, pues en el anterior articulo os enseñé como transmitir imagenes sin compresion a traves de la toma de auriculares con los defectos que esta transmisión analogica suponia (Desincronización, alteracion de los valores,...) por lo que no pasé de las imagenes en blanco y negro sin compresion. No obstante, aprovechando que tenia un par de dias de descanso entre los examenes finales, analicé las limitaciones que esta transmisión analogica de audio me suponía, y decidí buscar una forma de transmitir datos digitales de forma fiable y a una velocidad aceptable.
Pues lo conseguí, despues de analizar el comportamiento de las señales de audio analogicas de la entrada de audio, conseguí crear un codificador y un decodificador de archivos que permiten transmitir cualquier tipo de archivo de forma fiable (y con sincronizacion) a una velocidad de hasta 48kbps (con una señal de audio a 48Khz con mis equipos).
Esta forma de transmitir los datos es haciendo variar la señal de audio de 1 a -1 en intervalos muy pequeños transmitiendo los datos de forma binaria. Esto es distinto a por ejemplo como se codificaban los datos en cassetes de ZX Expectrum o similares, los cuales al codificar en medios mas sensibles como son los cassetes, utilizaban tonos (a una velocidad de datos mucho menor). Os adjunto los programas con... Atencion... El codigo fuente (Es la primera vez en la historia de mi blog que adjunto un codigo fuente, sin contar scripts linux).
Podeis decargar todo aquí. Dentro del zip hay un fichero con instrucciones detalladas sobre el uso.

Por ultimo recomiendo transmitir los archivos siempre comprimidos (en zip por ejemplo) ya que los valores altos o bajos continuados hacen que la señal acabe cayendo (Como se puede apreciar en la imagen), lo cual puede arruinar la transmision.

Cualquier duda o comentario aqui me teneis ;)

sábado, 6 de junio de 2015

Transmitiendo datos (imagenes) por la toma de auriculares

Bueno, pues lamentablemente aqui teneis otro articulo chorra de los que se que no os interesan XD
Si leisteis el articulo en el que imprimí canciones en formato PCM en un folio, este se trata del experimento a la inversa. Lo que hago es transmitir una imagen a traves de la toma de auriculares, la cual como sabeis trabaja con audio analogico, por lo que usaremos imagenes sin comprimir (*.BMP)

-Procedimiento:
¿Como lo haremos? Lo primero es pasar la imagen a transmitir en formato jpg o png (o el que sea) a formato BMP, ya sea abriendolo con Paint, Gimp, o vuestro programa favorito, para pasarlo a BMP.
Ahora conectamos dos equipos toma de auriculares con toma de entrada (Usando un cable de auriculares 3,5mm macho-macho). Yo en mi caso utilizo de equipo emisor una Raspberry-Pi (mas tarde un radio-cassete-cd) y de receptor mi portatil. Ahora en el equipo receptor debemos grabar la transmision, en Audacity por ejemplo, y en el emisor reproducir la imagen BMP como audio RAW sin comprimir (Unsigned 8bit PCM dará los mejores resultados). Ahora, creamos un archivo BMP usando la cabecera de archivo del archivo emitido, y mediante un editor hexadecimal como Hex Workshop, insertamos el contenido grabado con la toma de entrada (el cual deberiamos haber grabado en un archivo PCM U8) en el contenedor BMP.

-Resultados:
El primer problema que vemos con este experimento es la desincronización, aunque la tasa de bits es igual en los dos equipos, hay una ligera diferencia, la cual al no haber ningun modo de sincronización no se puede evitar. Esto hace que sea imposible transmitir una imagen en RGB, ya que se distorsionan los colores como podeis ver en la imagen de ejemplo mas adelante.

El segundo problema es el contraste. Al no conservar en la grabacion y la emisión el mismo volumen de audio, los resultados son que hay distintos niveles de color/BN.

Aunque he realizado el experimento con varias imagenes os dejo las 2 mas relevantes:

La primera es de una imagen de ejemplo de Windows, a la cual bajé bastante la resolución y transmití a 16.000 Hz desde la Raspberry-Pi. Como veis, incluso a bajos rates de audio, es imposible evitar la desincronizacion y los colores salen alterados. Si queremos obtener resultados buenos debemos utilizar imagenes B/N.

La segunda, es una imagen obtenida esta vez desde un radio-cassete-cd domestico. Grabando en un CD-RW un disco de audio con la imagen RAW, y mas tarde conectando la toma de auriculares del radio-cassete-cd a la entrada de audio del ordenador, conseguimos transmitir la imagen desde el cd (el cual lee el radio-cassete) a nuestro ordenador. De esta forma, ademas de estar limitados a usar 44.100 Hz (tasa de bits de los CD de audio), la calidad de la imagen, incluso en B/N, es inferior, ademas de que la sincronización tambien es peor, por lo que tuve que reajustar la imagen en Gimp, ya que salia torcida. En cualquier caso los resultados los podeis ver vosotros mismos, tampoco sale muy mal. En fin, cualquier comentario o duda aquí ;)


Imagen original:






Imagen obtenida desde la toma de auriculares del radio-cd

viernes, 22 de mayo de 2015

(OBSOLETO) Como saber quien no te sigue de vuelta en Instagram

Bueno, pues en esta ocasión, he hecho este script por peticion de una amiga, ya que como sabréis en la mayoria de los casos mis articulos los hago buscando llamar vuestra atención, no porque me pidáis por ejemplo como hacer las descargas de internet mas rapido, sino porque yo me adelanto a vosotros (porque os interesa todo lo que publico ¿a que si?).

En este caso se trata de un shell script para linux que igual que el script para hackear vendecookies esta basando en wget y comandos linux de edicion de texto.

Este script lo que hace en primer lugar es obtener el ID de usuario (un numero) asociado al nombre de usuario. Para ello y para ahorrarnos un poco de trabajo, el script accede a una pagina web de un tercero "jelled.com" que a partir de un nombre de usuario nos obtiene el ID de usuario.

Para obtener la lista de seguidores y seguidos, el script manda una peticion web a instagram como si estuviesemos usando la version movil (recordemos que en modo escritorio Intagram no deja ver los seguidores).
Estas listas son almacenadas en el ordenador (ya de paso) y mas tarde son procesadas para obtener en primer lugar los usuarios que sigues y no te siguen, y los usuarios que te siguen y no sigues.

Por ultimo aclarar que no es necesario introducir la contraseña, y este script se puede utilizar con cualquier usuario que querais, no solo el vuestro.
Este script no funcionará si teneis el usuario privado
En esta ocasion dado que es un simple shell script, en vez de subirlo a Google drive os lo dejo aqui a continuación. Si no teneis Linux y quereis saber vuestros resultados me podeis escribir un comentario en el post y lo puedo ejecutar por vosotros.

echo Introduce usuario instagram:
read us
usid=`wget 'http://jelled.com/ajax/instagram?do=username&username='$us -q -O -| awk -F '"id":"' '{print $2}' | awk -F '"' '{print $1}'`

wget http://instagram.com/api/v1/friendships/$usid/followers/ -q -O - | awk -F 'username":"' '{ i=2; do {print $i; i ++} while ( $i > 0) }' | awk -F '"' '{print $1}' > seguidores.txt
maxid=`wget http://instagram.com/api/v1/friendships/$usid/followers/ -q -O - | awk -F 'next_max_id":' '{print $2}' | awk -F '"' '{print $2}'`
while [ ! -z $maxid ]
do
wget 'http://instagram.com/api/v1/friendships/'$usid'/followers/?ig_sig_key_version=5&max_id='$maxid -q -O - | awk -F 'username":"' '{ i=2; do {print $i; i ++} while ( $i > 0) }' | awk -F '"' '{print $1}' >> seguidores.txt
maxid=`wget 'http://instagram.com/api/v1/friendships/'$usid'/followers/?ig_sig_key_version=5&max_id='$maxid -q -O - | awk -F 'next_max_id":' '{print $2}' | awk -F '"' '{print $2}'`
done

wget http://instagram.com/api/v1/friendships/$usid/following/ -q -O - | awk -F 'username":"' '{ i=2; do {print $i; i ++} while ( $i > 0) }' | awk -F '"' '{print $1}' > seguidos.txt
maxid=`wget http://instagram.com/api/v1/friendships/$usid/following/ -q -O - | awk -F 'next_max_id":' '{print $2}' | awk -F '"' '{print $2}'`
while [ ! -z $maxid ]
do
wget 'http://instagram.com/api/v1/friendships/'$usid'/following/?ig_sig_key_version=5&max_id='$maxid -q -O - | awk -F 'username":"' '{ i=2; do {print $i; i ++} while ( $i > 0) }' | awk -F '"' '{print $1}' >> seguidos.txt
maxid=`wget 'http://instagram.com/api/v1/friendships/'$usid'/following/?ig_sig_key_version=5&max_id='$maxid -q -O - | awk -F 'next_max_id":' '{print $2}' | awk -F '"' '{print $2}'`
done

seguidos=`cat seguidos.txt | wc -l`
seguidores=`cat seguidores.txt | wc -l`
echo
echo USUARIOS QUE SIGUES Y NO TE SIGUEN
echo -----------------------------------
echo
for (( i=1 ; i <= $seguidos ; i++ ))
do
us=`sed -n "$i"p seguidos.txt`
if [ -z `grep "$us" seguidores.txt` ]
then
echo $us
fi
done
echo
echo USUARIOS QUE TE SIGUEN Y NO SIGUES
echo -----------------------------------
echo
for (( i=1 ; i <= $seguidores ; i++ ))
do
us=`sed -n "$i"p seguidores.txt`
if [ -z `grep "$us" seguidos.txt` ]
then
echo $us
fi
done

martes, 28 de abril de 2015

Acelerar las descargas con "axel"

No se si recordareis un post que hice ya bastante tiempo donde os enseñé como programar un router wifi para descargar archivos de internet con el objetivo de evitar tener el ordenador encendido 3 horas para descargar un archivo grande. Por entonces años atras quien tenia internet solia contratar 3 Mbps (megabits por segundo) o a lo mejor hasta 6 (Como yo por entonces).
Ahora las cosas han cambiado, y ahora lo normal es tener mas de 10 Mbps. No obstante si intentais descargar archivos, notareis que muchas veces nunca se llega a esta velocidad, lo que ha hecho pensar a muchos que la compañia les ha puesto velocidad de menos. Si es vuestro caso, hay muchas paginas de test de velocidad de internet que podeis usar.
Volviendo al tema, los problemas por los que nunca se llega a la maxima velocidad son:

-Velocidad de subida del servidor limitada por descarga
-Servidores saturados (Un dia va mas rapido que otro)
-Uso de la red LAN en otras cosas

¿Que podemos hacer para sacar partido de la velocidad que tenemos?
Hay un programa de descargas no muy conocido llamado "axel" el cual es conocido sobre todo por usuarios de Linux (Aunque ahora tambien tiene version de windows) que funciona en la terminal y que lo que hace es realizar varias peticiones de descarga a un mismo servidor para intentar "forzar" un aumento de velocidad.
Tambien nos aporta otra ventaja, y es que en el caso de que un mismo archivo esté alojado en varias URLs, puedes utilizarlas simultaneamente para aumentar aun mas la velocidad.

Con esto podemos plantearnos por ejemplo descargar una pelicula en la mitad de tiempo que si la descargamos normalmente, o incluso menos si utilizamos varias URLs.

Os dejo el link del proyecto para Windows, y en el caso de que useis linux: sudo apt-get install axel.

Ahora os comento: muchos pensaran, si esto permite acelerar las descargas... ¿Porque no se implementa esto en los navegadores o programas como JDownloader?
Si todo el mundo usase axel para sus descargas, los servidores estarían mas saturados, y todos acabariamos teniendo velocidades de descarga inferiores a las actuales sin axel.
Por esto, axel es, y debe seguir siendo un programa poco conocido.

No obstante aviso que hay algunos servidores mas estrictos que no permiten mas de un hilo de descargas por IP. Esto consigue que no se puedan acelerar descargas con Axel, con el inconveniente de que solo se puede hacer una descarga simultanea en una red LAN, lo cual es un gran problema si por ejemplo en un aula de ordenadores varios usuarios deben descargar un mismo programa.

No quiero enrollarme mas asi que para cualquier duda podeis comentar aqui, como siempre.

lunes, 13 de abril de 2015

Almacenando música en un folio: metodo final 1:41 de audio

Si leisteis mi anterior post sobre el tema http://tragicomedy-hellin.blogspot.com/2015/03/almacenando-datos-en-un-folio-audio-en.html visteis que el ruido que se genera al imprimir y al escanear una hoja hace casi implanteable almacenar datos en formato barcode, a menos que sea para almacenar una cantidad inferior a 10 KB y escaneando la hoja varias veces.
Bueno, pues queriendo ir mas allá (por aburrimiento como no) quise dar un paso atras, para poder dar dos adelante, como dice el dicho. Con esto me refiero a olvidarme del audio comprimido, el cual al fallar un bit se carga grandes fragmentos de audio, y pasar a audio sin comprimir el cual tiene una tolerancia grandísima a fallos. Ademas, cambiaría el formato barcode blanco y negro por escala de grises codificando en UNSIGNED 8BIT PCM (En el audio sin comprimir, aunque todas las muestras fallen, con valores similares al original, se puede recuperar). Esta gran tolerancia me permite utilizar resoluciones muy grandes, sin preocuparme demasiado (sin llegar a los limites tecnicos de la impresora y escaner, claro).
Esto me permitió, que mientras que con el barcode conseguí codificar 0:07 en baja calidad, asi he conseguido meter en una cara de un folio... ¡1:41 de audio! para conseguir tanta cantidad de audio, he tenido que utilizar un muestreo de tan solo 6000 Hz, suficiente para que se entiendan y reconozcan las voces.
Para esto, cada pixel tiene una muestra (8 bits = 1 byte). En total he imprimido a 1152x531 px, lo que es equivalente a unas 597 Kb. El motivo por el que la resolución horizontal es mayor que la vertical (el triple concretamente) es que las interferencias entre muestras consecutivas no son relevantes, mientras que las interferencias entre muestras alejadas, crean un "efecto eco", el cual es mas dificil de evitar cada vez que se aumenta la resolución. ¿Podria haber almacenado mas audio? Si, pero no mucho mas. Horizontalmente, la impresora llega a sus limites tecnicos, y no se puede aumentar mas, mientras que verticalmente si se puede pero nos arriesgamos a aumentar el "efecto eco".
Sin enrollarme mas, os adjunto ademas de las fotos que podeis ver aqui, el audio que se obtiene al escanear la hoja codificado y reescalado a 48000 Hz en *.opus a 16kbps para que podais comparar con el post anterior. En concreto en esta prueba he codificado la cancion de Alex Sintek y Ana Torroja. Escucha aquí el audio escaneado.
¿Comentarios? ¿Dudas? pos oc.

sábado, 4 de abril de 2015

Como copiar DVDs al ordenador: Tutorial facil

Bueno pues hoy en este tutorial, os enseñaré como pasar un DVD (o bluray, el metodo es el mismo) a formato MP4 o simplemente copiarlo en formato nativo (*.VOB) al ordenador, para almacenarlo ahi, copiarlo a un disco, o compartirlo. Como sabreis, en MP4 la pelicula ocupará mucho menos espacio.
Esto os permitirá copiar peliculas con restriccion anticopia  hacer copias de seguridad de películas sin copyright.
Todo esto lo haremos con el reproductor multimedia VLC:
Lo primero que debemos hacer es Introducir el disco en el ordenador y abrir VLC.

En VLC, accedemos a la pestaña medio y pulsamos emitir.

Ahora en el recuadro que nos aparece debemos acceder a la pestaña disco y marcar la casilla Sin menus (Para emitir unicamente la película). Si experimentais problemas porque el reproductor no sabe donde esta la pelicula, poned en marcha la pelicula desde el menu de DVD antes de emitir.

Ahora nos saldra un asistente, donde debemos seleccionar salida a archivo. Este archivo se nos guardará a formato *.ts, pero podremos renombrarlo mas tarde a formato *.mp4 o *.vob. Es importante darle al boton añadir (depende de la version de VLC que tengais) para poder especificar donde se guardará el archivo.
En el siguiente paso, es cuando tenemos que decidir si pasamos la pelicula a MP4 o la guardamos en formato nativo (*.VOB si se trata de un DVD). Os comento que en el caso de pasarla a MP4 el proceso tardará un poquito más, pero merece la pena por el espacio que os podeis ahorrar, sobre todo si teneis pensado compartirla, o simplemente porque preferis que os ocupe 700 MB en vez de 8 GB.
Para pasar la pelicula a MP4 marcamos la casilla de transcodificar, y seleccionamos el perfil de MP4 (En la imagen), en caso contrario, desmarcamos la casilla.
Os recomiendo si vais a transcodificar, que accedais a las opciones (El icono de las herramientas) para modificar por ejemplo el bitrate de video (512 kbps de video es suficiente para que la pelicula os quepa en un CD-R, o incluso mas si la pelicula no es muy larga) y el bitrate de audio (Os recomiendo a partir de 128 kbps).
En el ultimo paso del asistente os pregunta si quereis emitir todas las "transmisiones elementales". Esto se refiere a por ejemplo los distintos idiomas del DVD. Recomiendo a menos que la vayais a compartir con gente del extranjero, desmarcar esta casilla, ya que si no el archivo os crecerá mucho inutilmente.
Finalizamos el asistente, y el reproductor empezará a emitir al archivo. No debeis utilizar el reproductor hasta que termine, o si no el proceso se quedará a medio. Lo que si podeis hacer es abrir otra ventana de VLC para hacer otra cosa con el reproductor mientras tanto.

sábado, 28 de marzo de 2015

The Pirate Bay: Saltando las restricciones geograficas en España mediante DNS y proxy

Bueno chic@s. Hoy es un dia bastante especial y quizas triste para los usuarios de internet españoles, ya que se ha bloqueado el acceso a la famosa web "The pirate bay".
¡Que gran suerte que me teneis a mi! Como siempre para enseñaros mis "trucos de hacker" para saltaros estas restricciones tan tontas. Os hare una breve introducción al bloqueo y os enseñaré a evitarlo de dos maneras (Os recomiendo la segunda, la del proxy, si sois inexpertos):

Aqui en España el bloqueo de webs es algo muy poco común, ya que esto es mas frecuente en paises como china.
Y quizas que el bloqueo sea menos comun, es la causa de que la efectividad sea bastante mala, os explico:

De momento, a dia de hoy de Marzo de 2015, los servidores DNS españoles tienen bloqueada la pagina, no obstante, las IPs de los servidores NO. ¿Que significa esto? Un servidor DNS es el encargado de traducir una direccion web (Ej: www.blogger.com) en una ip (Ej: 192.168.1.1).
Lo que pasa en España es que el servidor de The Pirate Bay es accesible, pero no hay forma de "Encontrar el camino a ella".

¿Podemos entonces acceder a la pagina desde España? SI para ello haremos uso de un servidor DNS extranjero:

Buscando en Google me encuentro la siguiente pagina en la que tenemos servidores DNS muy interesantes. Ademas de ser de distintos paises permiten bloquear sitios de por ejemplo pornografía, lo cual es muy util en por ejemplo equipos que usan menores. De momento nos centraremos en buscar un servidor DNS extranjero que no restrinja el acceso a http://thepiratebay.se

En este caso me quedo con el servidor DNS Censurfridns.dk de IPs 89.233.43.71 y 89.104.194.142 ubicado en Dinamarca.
Para usar este servidor DNS en vez del que estemos utilizando, accedemos a las propiedades de nuestra conexion a internet, y en el apartado "Protocolo de Internet version 4" accedemos a las propiedades.

Aquí en el apartado de las direcciones DNS, desmarcamos la obtencion automatica de DNS e insertamos la direccion de nuestro servidor de Dinamarca. Deberíais marcar tambien la casilla de "Validar configuración al salir" para que los cambios se hagan efectivos de forma inmediata. Aceptamos, y ahora accedemos a http://thepiratebay.se ... ¡Magia!

En fin, ahora supongamos... ¿Y si nos hubiesen censurado tambien el servidor? ¡Pues tampoco pasa nada!
Existe una cosa llamada servidor proxy. No es algo que se usa habitualmente, pero existe. Explicado de forma que se entienda: consiste en un servidor a la que le enviamos una peticion web. este servidor la consulta en internet, y nos la devuelve. Es como acceder a la web desde un ordenador en cualquier otra punta del planeta (Y con diferente IP, claro)
Si buscamos en Google "Servidor proxy online" nos encontramos con muchas opciones con las que ni siquiera tenemos que tocar la configuracion de red. El primer resultado es https://hide.me/en/proxy
Si accedemos a esta web y en el recuadro introducimos la dirección de Pirate Bay, tambien podremos acceder a la pagina de forma virtual sin problemas ;)

En fin, si teneis alguna duda, sugerencia, o incluso agradecimiento, no dudeis en comentar. Recordad que esto es un blog pequeño y agradezco vuestros comentarios ;)

martes, 17 de marzo de 2015

Almacenando datos en un folio: audio en un codigo de barras 2D

Hace ya tiempo surgio la moda de los BIDIs o codigos QR, unos codigos de barras 2D que podias escanear con la camara del movil y acceder a contenido multimedia.
Estos BIDIs, no obstante, tienen una capacidad muy limitada, y en la inmensa mayoria de los casos contienen enlaces a paginas web, aunque tambien son capaces de almacenar numeros de telefono, pass de wifi, o texto, como en el ejemplo que pongo a continuación.
  Hay muchas paginas para crear estos BIDIs o codigos QR, yo he usado http://www.codigos-qr.com/ 
La cuestion es que yo me propuse algo mas grande, almacenar en un simple codigo de barras en papel algo mas que un texto o un enlace.
Para ello hice uso de la impresora y el escaner.
Lo primero que pensé era en almacenar una imagen jpg, pero vi que era un ejemplo bastante aburrido, ya que aunque se pueda representar una imagen en color de poca resolucion en un barcode B/N, cualquiera puede imprimir una imagen en una hoja.

Luego pense en un ROM o .exe, pero suponiendo las limitaciones de espacio de un barcode descarté la idea.

Finalmente me acordé de el codec OPUS que os comenté en una entrada anterior, el cual puede comprimir el sonido mas incluso que MP3 y permite mas flexibilidad en cuanto a bitrates que OGG. Asi que hice calculos, y podriamos decir que hice tres intentos:

1.
Usando una resolucion de cuadrado de 2x2 (Respecto a la resolucion de mi impresora) conseguí hacer un barcode de hasta 352x500, o lo que es lo mismo, 176.000 bits que son unas 21,4 KB.
Aprovechando este tamaño, codifiqué en OPUS un fragmento de una cancion a 16 kbps, una calidad de sonido aceptable para el caso. Asi pude codificar 15 segundos de música en el barcode.
Cuando lo escanee y vi el resultado... ¡fracaso! aunque la impresión se hizo bien y la canción esta correctamente en la hoja, a la hora de escanear, el ruido de la imagen escaneada alteró gran cantidad de bits, haciendo que ni la cabecera del fichero quedase correctamente, por lo que no conseguí ningún resultado.

2.
Esta vez, asumiendo que iba a usar el escaner, aumenté el tamaño de pixel del barcode a 4x4 un tamaño de pixel ridiculamente grande, asi, aun sin utilizar el folio del todo (No necesito gastar demasiada tinta en una "demo") hice un barcode de 160x244, o sea 39.040 b
its que son unas 4,75 KB.
Para este ejemplo, codifico solo 4 segundos de audio a 12 kbps, una calidad ligeramente inferior.
imprimo, escaneo y... ¡casi! La cabecera del fichero es correcta, VLC me detecta el archivo, pero lamentablemente al haber algunos bits corruptos, el formato OPUS no reproduce los fragmentos de archivo que no cumplen su correspondiente checksum, en este caso hay 3 fragmentos (que se pueden distinguir a simple vista en la imagen) y ninguno cumple el checksum. Me pareció increible que hubisen fallos incluso con este tamaño de pixel.
Tras comparar el archivo escaneado y el original, vi que solo habian 3 bits corruptos, los cuales (que casualidad) estaban cada uno en un fragmento distinto. Estos fallos solo corresponden: 3/39040*100= 0,008% y arruinan los resultados.

3.
Simplemente, como habia tenido mala suerte, volví a escanear este segundo folio... 3 veces. Tras escanear y abrir el archivo por 3ª vez... Consigo oir la música! Conseguí reproducir 2 segundos de música almacenados en el barcode del folio. ¿Por que solo 2? Porque como dije, habia 3 fragmentos de sonido. El fragmento del final tenia un bit corrupto y no se reproducia, pero al estar la cabecera y los dos primeros fragmentos correctos, se reproducian estos y en total 2 segundos de audio de los 4 iniciales.
Aunque iba a finalizar aquí, se me ocurrió combinar los 3 primeros escaneos fallidos que hice (Sin contar este ultimo) a ver que pasaba. Los escaneos los tenia en escala de grises en GIMP, asi que los combiné en 3 capas superpuestas (cada uno con una transparencia de 33%) para pasarlos entonces a monocromo y probar con los resultados. Finalmente conseguí oir el audio original completo: Combinando los 3 escaneos conseguí recuperar el  archivo desde la hoja sin fallos.

Anexo: ¿Como imprimir los archivos?
Para imprimir los archivos en un folio cree un archivo BMP monocromo con la resolucion requerida y lo dejé en blanco.
Con un editor hexadecimal remplacé el contenido de este BMP en blanco con los datos del archivo de sonido. Ahora solo hay que abrir el BMP e imprimirlo.

¿Como escanear los archivos?
Tras escanear la hoja en formato BMP (Para evitar las perdidas de JPG), abro el archivo con Gimp y extiendo el barcode a las 4 esquinas del area de dibujo.
Cambio la resolución de la imagen escaneada a la resolucion del barcode y guardo en monocromo.
Ahora con un editor hexadecimal extraigo el archivo desde el BMP obtenido.

Conclusiones:
Es interesante saber que es posible almacenar un archivo de audio de esta manera, no obstante, el ruido a la hora de escanear hace que se aun metodo bastante poco recomendado XD
Cuando escaneas un BIDI ademas de que es mas pequeño y hay menos probabilidades de fallo, se esta comprobando su checksum en cada fps de la camara, es por eso por lo que a veces hay que tenerlo con la camara un tiempo, pero siempre acierta.
En este caso, al ser los barcodes de un tamaño enorme, a pesar de que un escaner tiene una calidad mucho mayor que una camara para este objetivo, al obtener una unica imagen, las probabilidades de que hayan fallos son altas.

martes, 20 de enero de 2015

Ejemplo de game-hack en ensamblador (x86)

Bueno chicos, como no recibo ninguna sugerencia, os enseño un ejemplo de las modificaciones o hacks que se pueden hacer fácilmente en ensamblador/hexadecimal.
En esta ocasión quería centrarme en algún juego para Windows, que es lo que se lleva hoy en día (Aunque modificar ROMs es mas sencillo, este formato ya no se lleva)
Me centraré en lo que viene siendo modificación de código, si quisierais modificar gráficos o música, es tan sencillo como acceder a la carpeta donde esta instalada la aplicación o juego, y buscar el archivo que queréis cambiar. El código por el contrario se suele encontrar en el *.exe

Concretamente en este ejemplo os enseñaré un hack que hice para el juego "Midtown Madness 2",
un juego que tiene ya unos años, no es un juego legendario, pero me basta para haceros un ejemplo de lo que se puede hacer de forma muy sencilla en ensamblador.


Concretamente, en este juego de coches, el hack consiste en que al activar el claxon del coche, el coche se eleva por los aires, permitiendo acceder a escenarios que no se puede acceder normalmente en el juego y pasar encima de los edificios.

Para ello, necesitamos encontrar el codigo que se ejecuta cuando activamos el claxon.
Gracias al programa "Cheat Engine" pude encontrar este codigo con facilidad. (Recordemos que Cheat Engine ademas de ser un conocido programa para modificar variables in-game, tambien tiene un desensamblador muy bueno)
Cuando encendemos el claxon se ejecuta un procedimiento en la dirección 0x000d17dc y cuando se apaga, otro procedimiento en la dirección 0x000d181c.
Si vamos a estas direcciónes encontramos:

...................
000D17DC - mov [esi],00000001
000D17E2 - pop esi
000D17E3 - ret 
000D17E4 - nop 
000D17E5 - nop 
000D17E6 - nop 
000D17E7 - nop 
000D17E8 - nop 
000D17E9 - nop 
000D17EA - nop 
000D17EB - nop 
000D17EC - nop 
000D17ED - nop 
000D17EE - nop 
000D17EF - nop 
000D17F0 - push esi
...................

...................
000D181C - mov [esi],00000000
000D1822 - pop esi
000D1823 - ret 
000D1824 - nop 
000D1825 - nop 
000D1826 - nop 
000D1827 - nop 
000D1828 - nop 
000D1829 - nop 
000D182A - nop 
000D182B - nop 
000D182C - nop 
000D182D - nop 
000D182E - nop 
000D182F - nop 
000D1830 - push ebp
...................


Como veis, el registro esi en estos dos casos contiene la dirección de memoria de un entero que se pone a 1 cuando el claxon esta encendido y a 0 cuando esta apagado. Esta variable ha sido la que me ha ayudado a encontrar el código. Y ademas vemos una buena noticia, y es que hay muchos bytes sin utilizar hasta el siguiente fragmento de código, lo cual nos ayuda a implementar el mod.
Ahora para hacer que el coche vuele, lo que tendremos que hacer es meter un código en este hueco que ponga el valor de la velocidad vertical del coche a un valor alto.
Este valor es un float que se debe encontrar con un puntero (situado en la dirección 0x005dfd20 al que hay que añadir a su valor 2450 en hexadecimal).
Yo personalmente le he puesto 30.0 de valor al float (41f00000), aunque se le puede dar cualquier otro, mayor o menor. Podemos aprovechar el registro esi que como vemos es reemplazado inmediatamente después cargando desde stack. El código queda así:

...................
000D17DC - mov [esi],00000001
000D17E2 - mov esi,[005DFD20]
000D17E8 - add esi,00002450
000D17EE - jmp 000D1824
000D17F0 - push esi
...................

...................
000D181C - mov [esi],00000000
000D1822 - pop esi
000D1823 - ret 
000D1824 - mov [esi],41F00000
000D182A - pop esi
000D182B - ret 
000D182C - nop 
000D182D - nop 
000D182E - nop 
000D182F - nop 

000D1830 - push ebp
...................

Como veis, he aprovechado parte de los bytes sin utilizar tras el procedimiento de apagar el claxon, ya que con el hueco del procedimiento al encender el claxon me quedaba corto de espacio.
¡Y con esto ya esta implementado! 
Si lo vemos con un editor hexadecimal vemos que los bytes que hemos cambiado son muy pocos.


Y sorprendentemente estos pocos bytes nos han permitido hacer un mod de vuelo totalmente funcional.

Ya sabeis, cualquier comentario o sugerencia (con otros juego si queréis) que queráis hacer... No es necesario registrarse para comentar. Aunque creo que ya lo sabeis :')

martes, 13 de enero de 2015

¿Cual es el mejor formato de audio? ¿MP3? ¿OGG?

Compara tu mismo os formatos aqui ;)
Bueno chicos, todos hemos usado siempre el formato MP3 de toda la vida para almacenar y compartir música, al menos la inmensa mayoría. MP3 como todos sabemos en un formato de compresión de audio con perdidas que ahorra mucho espacio respecto al audio sin comprimir PCM (Como en los CDs de audio).
Pero MP3 no es el único, de hecho, es yo creo, el formato mas antiguo que se usa actualmente en la actualidad, en cuanto formatos de audio buenos con perdida.
Otros formatos que salieron mas tarde son:
*.WMA, *.AAC y *.OGG.
Recientemente el equipo xiph.org creador de OGG Vorbis ha desarrollado otro formato de audio del cual hablaré tambien brevemente: *.OPUS

MP3 fue desarrollado por la fundación MPEG en 1994, y el mayor problema que presentaba era que este formato tenia una patente por la que se debia pagar a MPEG por su uso (o algo de eso). Esto fue el motivo de que por ejemplo mas tarde la fundacion Xiph.org creara el formato de audio abierto OGG Vorbis (Como podeis ver en la Wikipedia)

Hoy en día, el problema de MP3 ya no es la patente (Hoy en día la gente usa MP3 con total libertad) sino que al ser el formato de audio mas antiguo de los que hay en la comparativa, es el que en general tiene menor eficacia.

La eficacia  de un formato o de otro tambien depende del bitrate entre otros. Por ejemplo. El formato AAC que utiliza itunes a 192 kbps es el mejor formato de compresión a este bitrate, por encima de MP3 y OGG, pero solo a partir de este bitrate.

En general, y en mi opinión, a 128 kbps que es la tasa de bits mas utilizada y para abajo, el mejor formato es OGG.

la ventaja de AAC (Ademas de su eficacia a partir de 192 kbps) por lo que lo utiliza itunes, es la posibilidad de incluir proteccion de datos de derechos de autor (anticopia).
No obstante, a bajos bitrates puede ser incluso peor que MP3.

MP3 y WMA, son en general y para mi gusto los peores. WMA, que parece ser un poco mejor que MP3, fue el segundo formato de audio mas usado en la anterior decada (2000-2009). Muchos discmans y reproductores de MP3 fueron compatibles con WMA, hoy en dia este formato casi ni se usa, se podria decir que ha sido reemplazado por AAC (Gracias a la popularidad de Itunes).

OGG Vorbis, a pesar de su muy baja popularidad entre la gente, es un muy buen formato de compresión, y lo mejor de todo, es abierto.
Su alta calidad de compresión y su formato abierto, hace que sea uno de los formatos favoritos en los desarrolladores de videojuegos, por ejemplo: OGG es el formato elegido para la música de la saga de videojuegos GTA, incluido GTA San Andreas.
OGG tambien es el formato de audio utilizado en Spotify.

OPUS es el nuevo formato de audio desarrollado por Xiph.org como un formato pensado para audio en streaming. Es un formato de audio que combina los codec SILK (de skype) para el audio hablado y CELT para la música (CELT era el codec de audio que estaba desarrollando Xiph.org como sucesor de Vorbis). Este formato apenas tiene un par de años, y a pesar de que tiene una gran eficacia, esta totalmente enfocado en el streaming y la baja latencia. Una gran desventaja de este formato pese a su eficacia, es que la tasa de muestras esta fija a 48000 Hz, haciendo que si por ejemplo queremos convertir un archivo de audio a 44100 hz (Como en un CD de audio y la mayoria de MP3s) a esta nueva tasa de frecuencia, se tendria que reescalar.

Se que es muy dificil distinguir la calidad en canciones a 128 kbps, asi que como prueba para que compareis la eficacia de los distintos formatos, os adjunto la cancion de Bon Jovi - Living on a prayer a 64 kbps en formatos MP3, AAC, OGG y OPUS. Todos ocupan casi lo mismo, unos 1,80 Mb.
Para ello convertire un fichero original en MP3 a 160 kbps tambien adjunto, por lo que la calidad final si convirtieramos directamente desde CD seria un poco mejor tal vez.
Vosotros mismos podeis ver la comparación. En mi opinion los mejores formatos a este bitrate son en orden: OPUS, OGG, MP3, AAC. Descarga arriba del todo.
¿Os esperabais esta calidad de sonido de OGG y OPUS en un archivo de solo 1,80 mb? Comentad ;)

miércoles, 7 de enero de 2015

WinRar -vs- 7zip

Nota: tal vez os interese este articulo reciente sobre mi propio formato de compresion que combina 7z y rar para obtener la mejor compresión hasta el momento.

Seguramente todos nosotros hayamos usado alguna vez WinRar. Cuando apareció WinRar y el formato RAR, muchos aptamos por utilizar este formato para comprimir nuestros archivos, ya que este era (y sigue siendo) mucho mejor que zip.
Este formato no es malo, y por ello no me extraña que se use tanto, no obstante me sorprende que no se use el formato .7z tanto como se usa .RAR.
Para los que no hayais oido hablar de 7z, os lo comento brevemente:
Al contrario que RAR, el formato 7z es abierto, y a pesar de ser bastante menos popular, tiene tasas de compresión mayores.

Mas info sobre RAR: http://es.wikipedia.org/wiki/RAR
Mas info sobre 7z: http://es.wikipedia.org/wiki/7z

-Los programas:
Hablando brevemente de los programas correspondiestes a los dos formatos, tanto los compresores WinRAR como 7zip dan soporte para descomprimir ambos archivos. 7zip ademas tiene soporte para muchos mas formatos de compresión que WinRar.
WinRAR por otra parte tiene una interfaz grafica mejor que la de 7zip, la cual imagino que es simple para poder ser portado a varias plataformas sin dificultades.

-La compresión:
7zip tiene tasas de compresión mayores que RAR casi siempre. De momento el unico tipo de archivo que he comprobado que RAR comprime un poco mejor que 7z son los archivos de audio WAVE sin comprimir, los cuales no se usan frecuentemente. En el resto de los casos 7zip gana con diferencia.
7zip tarda aproximadamente entre un 125-150% de tiempo en comprimir en comparación con RAR en mi ordenador con procesador dual core. No lo he probado en otras plataformas, pero 7zip puede usar controlar varios nucleos. sobre esto no tengo información de WinRAR. Asi que no sabria deciros la comparacion de tiempo de los dos formatos en un ordenador quad-core actual, pero seguramente sean similares.

-Comparativa:
A continuación hare la compresión de varios archivos cotidianos en formato ZIP, RAR, y 7Z con el maximo nivel de compresión para que veais los resultados.
Los archivos a complimir seran un ROM de Nintendo 64 (SM64) otro de MegaDrive (Sonic 2) y Pokemon Hellín.
A continuación una carpeta con modelos 3D de SketchUp.
Un PDF aleatorio, y por ultimo un archivo de audio WAVE en formato CD (S16_LE a 44,1 kHz)

SM64
Tamaño original: 8,00 Mb
ZIP: 6,01 Mb
RAR: 5,59 Mb
7z: 5,43 Mb

Sonic 2
Tamaño original: 1,00 Mb
ZIP: 740 Kb
RAR: 735 Kb 
7z: 712 Kb

Pokemon Hellín
Tamaño original: 1,00 Mb
ZIP: 485 Kb
RAR: 467 Kb 
7z: 439 Kb

Carpeta modelos SketchUp
Tamaño original: 25 Mb
ZIP: 13,3 Mb
RAR: 10,9 Mb
7z: 9,65 Mb

Documento PDF
Tamaño original: 7,09 Mb
ZIP: 6,51 Mb
RAR: 6,45 Mb
7z: 6.19 Mb

Musica WAVE sin comprimir
Tamaño original: 36,3 Mb
ZIP: 34,2 Mb
RAR: 26,8 Mb
7z: 33,0 Mb

La comparativa habla por si sola, exceptuando los archvos de audio WAVE que no se suelen usar habitualmente, 7zip obtiene los mejores resultados. Logicamente si comprimimos archivos ya comprimidos como pueden ser JPG o MP3, obtendremos siempre una compresion muy mala y casos en los que por ejemplo el archivo comprimido ocupa mas que el original, o que la mejor compresion es la ZIP o/y la 7Z es la peor con diferencias muy bajas, es por esto que no se suelen comprimir estos tipos de archivos.