[Homika + Shiroisora] Fate/Stay Night [Unlimited Blade Works] – 00 – Prólogo

Sinceramente esto… no me lo esperaba ni yo pero salió y pues bueno, aquí estamos con Fate/Stay Night [Unlimited Blade Works], para variar solo 4 semanas tarde (Qué dolor), pero no es mi culpa, se los juro (es en serio ._.)

Esto irá a paso de tortuga con parkinson en reversa, dado que es en joint con los vagos de Homika.

 

Los vagos:

Traducción: Archer

Corrección: Harutora (?)

Edición: Gordigo (No me lo creo ni yo)

Karaokes: Shujin0

QC: Catherine, Gordigo, Harutora (?)

Encode: Gordigo

Aguador: Hirako21 (¡Está vivo!)

El que nos putea: [Belial]

Torrent

Descarga Directa (Algo lenta, mi seedbox tiene problemas)

Vi por ahí Hi444 para encodear, ¿por qué no la usan?

A ver a ver, primeramente, ¿qué es Hi444? Dicho de otra forma, es High 4:4:4 Predictive, otro perfil de H.264 que permite encodear con Chroma Subsampling 4:4:4.

¿Y  qué es Chroma Subsampling 4:4:4? usen google, ¡tengo pereza!

En resumen, se refiere a la información de color e iluminación de una imagen, o vídeo, en este caso, se le llama completa, o sin pérdidas (Si quieren información extra, usen google, es un tema, algo corto, pero con bastantes cosas técnicas).

Actualmente se encodea usando Chroma Subsampling 4:2:0, en el cual se genera mucha pérdida de información de color para reducir el tamaño de un vídeo, esto se debe al hecho de que el ojo humano es mucho más sensible a cambios de brillo, que a cambios de color, por tanto es posible “descartar” dicho detalle y reducir el tamaño final de un vídeo, actualmente todos los Blu-rays son producidos con profundidad de 8-bits(Sí, usar profundidad de color de 10-bits en x264 es técnicamente un up-scale, dado que no hay información con esa profundidad, más adelante hablaré del tema)  y Chroma Subsampling 4:2:0, por tanto “no existe” la información para crear un 4:4:4 real (De por sí ya hay información faltante, incluso podría considerarse que el vídeo ya está comprimido en un Blu-ray, y realmente lo está), lo que sucede es que los sistemas de decodificación de vídeo vuelven a crear, o reconstruyen la información que no estaba presente obviamente este proceso no genera imágenes con la misma cantidad de información que un 4:4:4 real, de igual forma estas imágenes no presentan una diferencia crítica al ser comparadas con una 4:4:4 real.

Dicho lo anterior, lo ideal sería pensar que un Hi444 es la evolución desde un Hi10, pero es algo completamente incorrecto, es posible crear un Hi444 con profundidad de 8-bits, 10-bits, o de 12-bits, el detalle reside en el hecho que x264 solo soporta 8 y 10bits, por tanto no es una evolución, más bien es algo completamente natural de x264 junto a las profundidades de color, solo que está destinado a guardar otro tipo de información, en este caso, información de color.

 

Hi8p vs Hi10p vs Hi444

Los dos primeros se refieren a profundidad de color como ya he dicho, así que compararlos con Hi444 es… inútil, lo realmente importante es conocer los beneficios de agregar Hi444 a Hi10p.

Beneficios

  1. En teoría se puede obtener una mejor calidad de vídeo comparada a un video Hi10p 4:2:0 con los mismos parámetros de x264
  2. Dichos vídeos tienen menos peso. (¡¿Acaso no se supone que 4:4:4 tiene más información que un 4:2:0?!, sí, pero x264 logra guardarla de forma más eficiente)

Contras

  1. Toma más tiempo encodear con Hi10p 4:4:4 que con Hi10p 4:2:0
  2. La decodificación de un Hi10p 4:4:4 consume más recursos que un Hi10p 4:2:0 (Si tu tostadora ya va a patadas con un Hi10p 4:2:0 a 1080p con su karaoke, seguramente te irá patadas con un 1080p Hi10p 4:4:4 sin el karaoke)
  3. Encodear a 1080p usando los mismos parámetros de Hi10p 4:2:0, toma una cantidad absurda de recursos, es necesario hacer pipe del vídeo a x264_64, dado que normalmente a 1080p usando parámetros fuertes consume entre 2gb a 2.6gb de ram, al aplicar 4:4:4 a la formula, x264 (de 32 bits) se queda sin memoria ram para seguir trabajando, dada la limitación que poseen las aplicaciones de 32 bits, por tanto se vuelve necesario el pipe, o primero generar un lossless del vídeo en  4:4:4, y enviarlo a x264_64, resultando en un consumo de 3-3.5gb de memoria ram (rogando que no tenga algún Karaoke salvaje con efectos flamán en vsfiltermod, o un overlay en AE), y obviamente el aumento de tiempos de encodeo que esto conlleva (La factura de la electricidad  joderá :v).
  4. Si no tienes más de 4GB de ram, es mejor ni pensar en encodear a 1080p con Hi10 4:4:4, x264 irá a unos hermosos 0.2-0.3fps, generando tiempos de encode que hacen parecer rápido a x265.
  5. Si todavía quieres encodear a 1080p con hi444, te verás forzado a reducir varios parámetros de x264, especialmente aquellos que consumen mucha ram, como los B-frames (Debí reducir de 16 a 10 para que el encode superara los 0.7fps y el uso de cpu estaba a un 10%, y debí reducirlos a 7 para que x264 lograra usar el 30-50% de mi i7 3770k) reducir este parámetro en específico reducirá la compresión, o mejor dicho, la efectividad de la misma, lo cual a su vez, hace inútil el primer beneficio.

PC Usado en la prueba

Procesador: Intel Core i7 3770K @ 3.5GHz Turbo-Boost OFF
Ram: Corsair Vengeance 4GB @ 1600MHz
HDD: WD Caviar Blue 1TB @ 7200RPM
Fuente de video: BDMV Da Capo III.

Hechos

Para esta prueba usé el NCOP de Da Capo III, con un downscale a 720p, como se puede ver en la primera imagen el bitrate bajó casi 300kbps, lo cual  a su vez, redujo el tamaño del vídeo en 4mb, aunque esto es un opening, en un vídeo de 24 minutos esta reducción sin mucho problema podría aumentar a 40-100mb dependiendo de la complejidad del mismo, pero de igual forma se pierde velocidad, en este caso 0.30fps lo cual a su vez, representa sin mucho problema unos 30 mins más para encodear y eso es malo cuando para un volumen de un anime en Blu-ray pueden ser 2 encodeos si solo da para 720p, o 4 si da para 1080p(aquí la demora es mucho más notable), eso sin agregar  NCOP, NCED, y menús si es del gusto del encoder.

 

Parámetros registrados por Mediainfo para el hi444

Parámetros registrados por Mediainfo para el hi10p

Ajá, son exactamente los mismos en x264, y el resultado en el tamaño final de un NCOP no es demasiado fuerte para ser apreciable, en cuanto a recursos usados, el hi444p para encodearse usó 2gb de ram, mientras que el Hi10p usó 1.4gb, para reproducción el hi444 sin audio, tomó 27% de uso de CPU al arranque y se estabilizó a 15-20%, el hi10p, usó 16% para el arranque, y se estabilizó en 5-9%, lo cual en PCs decentes, y potentes, no es nada, para las cafeteras… será infernal.

 

RAW entregada por AvsP Mod

RAW

 

 

Hi10p  + 4:4:4

Hi444p

 

 

Hi10p + 4:2:0

hi10p

Más allá de las diferencias notables entre la RAW a los encodeos, entre 4:2:0 y 4:4:4 las diferencias son, casi subjetivas, ambas tienen ruido, y banding, problemas normales al encodear, la única diferencia notable, es cómo se presentan estos problemas, pero ambos persisten, así que “mejor” queda a gusto del observador, la mejora en el tamaño es apreciable, y en capítulos completos, se notará bastante más, ¿se justifica? No, sinceramente no, la molestia para el encoder es bastante grande, o mejor dicho, para su billetera con los costos al tardar más encodeando, o directamente necesitar una PC más potente para poder mantener una velocidad decente, sin verse forzado a dejar su PC encendida por periodos extendidos de tiempo con uso de CPU +90%.

Ahora me dirán “¡He visto otro(s) fansub(s) que usan Hi444p y sus vídeos sí tienen menor peso!” He visto a mediainfo reportar 4 reference frames, y 5-6 b-frames en encodeos de dichos fansubs, esto lo hacen para conservar la velocidad del mismo, a costa de aumentar el tamaño del video al reducir la compresión efectiva del mismo, y para conservar un peso bajo usan o bitrate fijo, o CRF por encima de 17, he visto 18 de hecho, y la verdad, 18 se ve bien, pero el estándar para que el vídeo tenga una calidad decente, es 16, cualquier cosa por debajo de 16 es gusto del encoder, y con mejoras en el vídeo poco apreciables  (Ya sé, yo uso 13 en BBAM, pero lo necesita, dada la poca calidad del Blu-ray) de igual forma por encima de 16, la pérdida de calidad y reducción en el tamaño del vídeo saltan a la vista, sin mucho problema, especialmente si hay 3DCGI, escenas oscuras, etc.

Hi10p  + 4:4:4 (Reference 5, B-frames 5, CRF 16, tamaño final 37.8mb)

v2

 

 

Solo al reducir los B-frames y los Reference frames a 5, el tamaño aumentó casi 2mb respecto a la versión con 16 y 16, en un capítulo completo, sin mucho problema pueden ser 20mb a 100mb más, de nuevo, dependiendo del tipo de vídeo que sea.

Sí, directamente no se nota nada “diferente” respecto a la versión 16 y 16, pero miren la esquina inferior derecha, notarán que el ruido es más apreciable, esto en escenas con movimiento será muy notable, más cuando se sube el CRF uno o dos puntos para conservar un tamaño menor al ofrecido por Hi10p +4:2:0, esto es extremadamente apreciable en cosas como el opening de JoJo s1 (Sono chi no Sadame) que es un compression hell, o en Sidonia no Kishi.

 

¿Veredicto?

Las ventajas de agregar 4:4:4 a Hi10p, son apreciables, más no “necesarias” o mejor dicho, no son razones de suficiente peso como para migrar a este perfil es más, no es como el cambio de 8-bits a 10-bits que el ruido, y banding reducidos fueron apreciables al instante, aquí queda a gusto del encoder/fansub, personalmente digo NO, no es necesario agregar 4:4:4 a los vídeos, solo aumenta los problemas del encoder, y de la persona final que ve el vídeo, es más, la promesa del 4:4:4 se torna casi un placebo, dado que las mejoras visuales, no son apreciables, es más, los contras de usar este perfil son bastante más fuertes para los encoders, no todos tienen una PC con un i7 o un FX de gama alta, es más, pocos superan los 4GB de ram en sus PCs, de igual forma, reproducir estos capítulos completos se torna infernal para personas que usan tostadoras, hay que admitirlo, la mayor parte de las personas que ve anime en latino américa tiene dinero para consolas de videojuegos, pero les resulta imposible tener un procesador decente, muchos todavía viven con sus pentium 4 HT (son buenos, pero vamos, les falta potencia), incluso hay vídeos en 1080p y hi10p que son infernales para procesadores Core 2 Duo y similares, no hay necesidad de generar todavía más problemas de aceptación al MKV en latino américa al agregar Hi444, y por encima de todo, los fansubs antes de hacer algo para sus seguidores, lo hacen para sí mismos, si algo les da muchos problemas, o consume mucho tiempo, sencillamente no lo hacen, o lo hacen de la forma que menos problemas les de, y una de esas, es sin lugar a dudas, NO USAR Hi444P.

Grisaia no Kajitsu -Le fruit de la Grisaia- 03

Bueno, para variar esta semana no estoy tan tarde… este capítulo es ligeramente “especial” ya notarán el por qué, más allá de eso, vamos unas 5-8 horas en la ruta común del juego, no sería raro que en el próximo capítulo llegáramos a una ruta, por el título del capítulo 4, podría ser la ruta de Makina, o la de Amane, al igual que parece que por fin se dará a conocer algo más del “trabajo” de Yuuji.

 

Sin más por decir, disfruten del cap, lo usual,  BS11 bla bla bla.

Agradecimiento especial a JMuR, gracias a él hay romajis para el ending.

 

[SsnF]_Grisaia_no_Kajitsu_03_[BS11_1080p_x264-Hi10P_AAC]_[FF4BE86F]

[SsnF]_Grisaia_no_Kajitsu_03_[BS11_720p_x264-Hi10P_AAC]_[47850400] 

[SsnF]_Grisaia_no_Kajitsu_03_[BS11_1080p_x264-Hi10P_AAC]_[FF4BE86F].mkv_snapshot_01.09_[2014.10.21_18.00.38] [SsnF]_Grisaia_no_Kajitsu_03_[BS11_1080p_x264-Hi10P_AAC]_[FF4BE86F].mkv_snapshot_02.13_[2014.10.21_18.01.05] [SsnF]_Grisaia_no_Kajitsu_03_[BS11_1080p_x264-Hi10P_AAC]_[FF4BE86F].mkv_snapshot_06.59_[2014.10.21_18.02.17] [SsnF]_Grisaia_no_Kajitsu_03_[BS11_1080p_x264-Hi10P_AAC]_[FF4BE86F].mkv_snapshot_07.11_[2014.10.21_18.02.28] [SsnF]_Grisaia_no_Kajitsu_03_[BS11_1080p_x264-Hi10P_AAC]_[FF4BE86F].mkv_snapshot_07.44_[2014.10.21_18.03.01] [SsnF]_Grisaia_no_Kajitsu_03_[BS11_1080p_x264-Hi10P_AAC]_[FF4BE86F].mkv_snapshot_09.04_[2014.10.21_18.03.13] [SsnF]_Grisaia_no_Kajitsu_03_[BS11_1080p_x264-Hi10P_AAC]_[FF4BE86F].mkv_snapshot_12.01_[2014.10.21_18.03.28] [SsnF]_Grisaia_no_Kajitsu_03_[BS11_1080p_x264-Hi10P_AAC]_[FF4BE86F].mkv_snapshot_17.17_[2014.10.21_18.04.27]

 

PD: 4.22GB la TS de esta semana, como para llorar cuando el internet trabaja a 200kb/s para descargas desde mi FTP ._.

GRISAIA NO KAJITSU -LE FRUIT DE LA GRISAIA- 01v2 + 02 1080p y 720p

Bueno, varios días tarde, pero al fin el segundo cap de Grisaia no Kajitsu, eso de tener GOPs corruptas en la TS del cap 2 realmente retrasó mucho esto, más allá de eso, disfruten el segundo capítulo, como siempre BS11, esta vez 1080p y 720p.

Para variar, están las lyrics del insert que viene desde Grisaia no Rakuen (Eden’s Song), para el BDs debería tener FX, debería…

PD: Incluye versión 2 del capítulo 1 (720p) que corrige un error de escritura, cambia la fuente de las notas para BGM, y cambia el nombre de las mismas a japonés.

[SsnF]_Grisaia_no_Kajitsu_01+02_[BS11_1080p_x264-Hi10P_AAC]

[SsnF]_Grisaia_no_Kajitsu_01v2+02_[BS11_720p_x264-Hi10P_AAC]

 

 

[SsnF]_Grisaia_no_Kajitsu_02_[BS11_1080p_x264-Hi10P_AAC]_[A28EB350].mkv_snapshot_22.07_[2014.10.17_00.33.07] [SsnF]_Grisaia_no_Kajitsu_02_[BS11_1080p_x264-Hi10P_AAC]_[A28EB350].mkv_snapshot_18.24_[2014.10.17_00.32.50] [SsnF]_Grisaia_no_Kajitsu_02_[BS11_1080p_x264-Hi10P_AAC]_[A28EB350].mkv_snapshot_09.08_[2014.10.17_00.32.00] [SsnF]_Grisaia_no_Kajitsu_02_[BS11_1080p_x264-Hi10P_AAC]_[A28EB350].mkv_snapshot_08.59_[2014.10.17_00.30.50] [SsnF]_Grisaia_no_Kajitsu_02_[BS11_1080p_x264-Hi10P_AAC]_[A28EB350].mkv_snapshot_01.21_[2014.10.17_00.28.58]

Grisaia no Kajitsu -Le fruit de la Grisaia- 01

Bueno gente, seguramente se preguntan “¿Por qué carajos se mete en otro proyecto, si ni ha terminado BlazBlue Alter Memory?”, resulta que a esta novela le tengo mucho cariño, a eso sumemos que BlazBlue tendrá el volumen 5 el fin de semana si hay suerte, entonces no hay drama (?)

Por otra parte el análisis FFT de esta serie, en el cap 1 usando la TS de BS11 (3.6gb Aprox) mostró una resolución de 816p, básicamente lo que estaba en pantalla con el cinemascope, igual con resolución horizontal de 1920px, por tanto es posible afirmar que está dibujado a 1080p como Witch Craft Works, ¡hurra! Usando la TS de BS11 sin mucho problema podría dar un 1080p, pero eso va en ustedes.

La traducción es una edición de Crunchyroll, quienes hicieron un trabajo relativamente bueno con esto, por tanto simplemente edito lo que está mal, agrego el Typesetting (el motion tracking que usé es diferente al de TLWiki), y puse los cambios necesarios en traducción para Sachi, la identidad de algunas palabras de Makina (Sí, sus palabras están escritas de manera “correcta”, dado que en las primeras partes de la ruta común tiene la costumbre de cambiar “Dame” por “Rame” y cosas así), se agregaron las BGM respecto a las que regresan desde la Novela Visual, y se encodeó usando la TS de BS11.

Siendo así…

“El árbol del mundo, Grisaia” El nombre del árbol gris es Grisaia.
Tiene frutos que maduraron en sus ramas, pero flores que jamás florecen.

[SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12]

Usar como tracker Nyaa, dado que Frozen-Layer todavía no tiene la serie en su base de datos.

 

[SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_01.41_[2014.10.07_14.47.58] [SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_22.12_[2014.10.07_14.51.42] [SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_20.46_[2014.10.07_14.51.26] [SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_18.07_[2014.10.07_14.51.12] [SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_17.25_[2014.10.07_14.50.43] [SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_12.54_[2014.10.07_14.50.11] [SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_10.46_[2014.10.07_14.49.41] [SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_08.38_[2014.10.07_14.49.16] [SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_08.16_[2014.10.07_14.49.00] [SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_04.31_[2014.10.07_14.48.38] [SsnF]_Grisaia_no_Kajitsu_01_[BS11_720p_x264-Hi10P_AAC]_[F4305A12].mkv_snapshot_02.20_[2014.10.07_14.48.14]

Análisis FFT, 817.1p, 816p efectivos, este capítulo fue mostrado de la misma forma que EVA 3.33, en el caso de Grisaia, maneja toda la resolución vertical y horizontal de la imagen original, por tanto es 1920×816, si los capítulos siguientes no tienen el CinemaScope, con mucha seguridad será 1920×1080, sin mucho problema podría dar un 1080p basado en BS 11 y seguiría viéndose bien.

Grisaia 1 BS11.ts_snapshot_09.28_[2014.10.07_13.23.49] FFT

PD: Para aquellos “pros” que joden diciendo que usé como raw lo que Zero publicó en Nyaa… díganme cómo algo de menos de 230mb, termina de casi 270mb, si se re-encodeo en hi10p.

BlazBlue Alter Memory Volumen 4

Para variar, esto fue rápido, de esta forma me pongo al “día” con esto, obviamente comparándolo con el punto en el cual se pausó, siendo así, disfruten, como siempre dos capítulos y el respectivo scan, respecto a BuruRaji, solo tengo el DVD del cap 2/5/6 lo demás lastimosamente no, si alguien los desea con gusto subo un DVDiso.

Terminando edición de Fortune Arterial, no desesperen.

[SsnF]_BlazBlue_Alter_Memory_Vol.4_[BDrip_720p_x264-Hi10P_FLAC]

[SsnF]_BlazBlue_Alter_Memory_08_[BDrip_720p_x264-Hi10P_FLAC]_[F025246E].mkv_snapshot_11.10_[2014.06.15_23.01.18] [SsnF]_BlazBlue_Alter_Memory_07_[BDrip_720p_x264-Hi10P_FLAC]_[8AC000C5].mkv_snapshot_00.07_[2014.06.15_22.59.13] [SsnF]_BlazBlue_Alter_Memory_08_[BDrip_720p_x264-Hi10P_FLAC]_[F025246E].mkv_snapshot_17.48_[2014.06.15_23.01.22]

BlazBlue Alter Memory Volumen 3

Bueno gente, han pasado casi 21 días desde que publiqué el volumen 2 de BlazBlue, la verdad no tenía la intención de tardarme tanto, pero la vida y otras cosas no ayudan en esto, como tampoco la llegada de la Nendoroid Petit de Mu-12 (Kawaiiii).

Detalles importantes:

  1. El karaoke del opening tiene un nuevo efecto, el cual personalmente creo que le queda mejor y reduce el cambio brusco de colores.
  2. Ya están los parches para el problema de audio y de duración para los capítulos 1,2 y además traen el efecto nuevo para el OP.
  3. Agregué los scans del volumen 1, y ya vienen los del 3, no trae los del CD y demás dado que son la misma imagen que viene por separado

PD: Ya tengo ripeada toda la serie (oh god comprar esos BDs si que dolió), y encodeado todo hasta el Vol 5.

Parche correcto capítulo 4

[SsnF]_BlazBlue_Alter_Memory_Vol.3_[BDrip_720p_x264-Hi10P_FLAC]

[SsnF]_BlazBlue_Alter_Memory_06_[BDrip_720p_x264-Hi10P_FLAC] [9568D997].mkv_snapshot_21.24_[2014.06.07_00.42.53] [SsnF]_BlazBlue_Alter_Memory_05_[BDrip_720p_x264-Hi10P_FLAC] [949E9EBC].mkv_snapshot_08.34_[2014.06.07_00.41.46] [SsnF]_BlazBlue_Alter_Memory_05_[BDrip_720p_x264-Hi10P_FLAC] [949E9EBC].mkv_snapshot_13.49_[2014.06.07_00.42.02] [SsnF]_BlazBlue_Alter_Memory_06_[BDrip_720p_x264-Hi10P_FLAC] [9568D997].mkv_snapshot_09.47_[2014.06.07_00.42.38]