The.Spanish.Retail.HD.Releasing.Standards.2014-ESCOUNCiL (2014-07-21)
--------------------------------------------------------------
Special note to nukenets: This ruleset aims to clean the actual spanish
p2p crap pre from ours. From now on, proof is mandatory for every single
release. At the moment, only the following teams are recognised as legit
and follow those rules:
0ld - ASS - FCC - JODER - LPH - MAHOU - sPHD - TORO - XPERT - XPERT_HD
Ha pasado mucho tiempo desde la ultima revisi≤n de rules para material
retail en Espa±ol. XviD es un c≤dec muy dθbil y obsoleto frente a X264.
Adicionalmente, debido a la cantidad de pre's P2P, sospechosas y err≤neas
que se han podido ver a lo largo de estos a±os, hemos acordado una serie
de reglas que cubren las releases SD para material retail en Espa±ol (Castellano).
Todo lo especificado aquø solo se aplica para las releases preadas despuθs de que
este documento entre en funcionamiento (2014-07-21).
1) Video:
1.1) Watermarks, intros, outros o cualquier otro tipo de desfiguraci≤n
a±adida en el video estan prohibidos, incluido durante los crθditos.
1.2) Quitar los creditos queda prohibido, y estos deben ser encodeados
a la misma calidad que el resto de la release.
1.3) Los bordes deben ser cropeados completamente.
1.4) Solo se permiten "Sharp Resizers" tales como Lanczos/Lanczos4, Spline36,
o Blackman. "Simple Resizers" (bicubic, simple, etc) estan prohibidos.
1.5) La anchura y altura de la release deben ser de la siguiente manera:
- 1080p: Cropear el vødeo. Prohibido redimensionar. Resoluci≤n de entrada (1920x1080) - crop.
- 720p: Cropear el vødeo y redimensionar. La anchura debe ser 1280 y la altura mod2, 8 o 16.
A excepci≤n de cualquier fuente con relaci≤n de aspecto menor a 1.78 (16:9) vertical.
En este caso se debe usar 720 como altura, y el ancho debe ser mod2, 8 o 16.
Ejemplo: Relaci≤n de aspecto 2.35 serβ 1280x544.
Ejemplo: Relaci≤n de aspecto 1.78 serβ 1280x720.
Ejemplo: Relaci≤n de aspecto 1.33 serβ 960x720.
1.6) Queda prohibido reescalar el video. Siempre redimensionar despuθs de cropear.
1.7) Se debe aplicar desentrelazado si es necesario, con alguna herramienta
inteligente como Yadif. Una release entrelazada estβ considerada un fallo
tθcnico (nuke). Rara vez el material retail viene entrelazado, pero existe.
1.8) Las fuentes BluRay y HDDVD se dupean entre ellas.
2) Audio:
2.1) Espa±ol Castellano. Estas rules no afectan al LATiN.SPANiSH.
2.2) El audio debe ser AC3, DTS o FLAC, preferiblemente el mismo que la fuente.
2.3) DTS debe sacarse de la pista DTS HR/HD Master Audio. Las pistas DTS deben
ser compatibles por los decodificadores (hardware) antiguos.
El audio FLAC debe ser creado desde la pista LPCM, DTS HD o TRUEHD.
2.4) El bitrate de audio nunca debe estar por debajo de 640 kbps, a excepci≤n de
que la fuente tenga un bitrate de audio mβs bajo.
2.5) El audio debe ser 5.1 con los canales correctos, a excepci≤n de que la fuente
sea stereo/mono. Queda prohibido reescalar audio stereo/mono a 5.1.
2.6) Se permiten varios audios a parte del Espa±ol Castellano. Todos los audios deben
ser muxeados en el mismo .mkv de la release.
2.7) Si se decide usar mβs de un audio se debe taggear la release teniendo en cuenta
lo siguiente:
Espa±ol Castellano: SPANiSH
Espa±ol Castellano + otro/s (2 o mβs): SPANiSH.MULTi
2.8) SPANiSH y SPANiSH.MULTi se dupean entre ellas significando esto
que solo una de estas dos opciones puede ser preada normalmente, para cada
calidad (720p y 1080p). El resto deben ser preadas como INTERNAL.
Ejemplo: Si hay release SPANiSH preada INTERNAL.SPANiSH.MULTi
Ejemplo: Si hay release SPANiSH.MULTi preada, usar INTERNAL.SPANiSH.
2.9) En el caso de MULTi, la pista que contiene audio Espa±ol Castellano
debe ser la por defecto (default) en el contenedor .mkv.
2.10) Si se decide usar MULTi, el segundo audio en el contenedor .mkv deberβ ser el
versi≤n original de producci≤n del contenido. Los demβs pueden variar.
3) FPS:
3.1) La tasa de FPS debe ser igual a la fuente y constante. FPS variables estan
prohibidas ya que no funcionan correctamente en muchos reproductores. Solo
se permiten FPS variables en caso de que la fuente sea asø, y en este caso
se debe demostrar con una captura con informaci≤n tθcnica sobre el vødeo fuente
extraido del medio føsico dentro de la carpeta Proof, que asø lo justifique.
De cualquier otra manera, queda prohibido.
4) Codec:
4.1) Debe ser H264 encodeado con x264 8 bits y a Level 4.1. x264 10-bits estβ baneado.
4.2) Mantener x264 actualizado. Hay muchas formas de actualizaci≤n,
incluso automβticas. Matrices y deblocking a gusto del grupo. Por defecto
vienen configurados.
4.3) Ninguna opci≤n puede estar por debajo de lo especificado por --preset
slow exceptuando --subme 7 que sø se permite. Se cuenta tambiθn como excepci≤n
--ref 4 que puede ser usado, si la resoluci≤n vertical (altura) de la release es
mβs que 864 pøxeles.
4.4) Las zonas (--zones) no se permiten.
4.5) El encode debe ser realizado a calidad constante pudiendose usar una pasada
a CRF o dos pasadas a tama±o (--bitrate), a gusto del grupo. Queda prohibido
usar solamente una pasada para encode a tama±o (--bitrate), deben ser mønimo dos.
4.6) En el caso de series de televisi≤n u otro contenido capitulado, el tipo
de encode debe ser respetado para todos los captøtulos/partes correspondientes
de por lo menos aquella temporada o volumen, por cada calidad.
Ejemplo: Si se decide usar CRF para la release 720p.BluRay de una serie en el
S01E01, toda la S01.720p debe ser a CRF. Las releases 1080p podrøan ser todas
a CRF tambiθn o todas a tama±o, pero nunca mezcladas o variado.
4.7) Si tama±o (--bitrate) mθtodo de encode usado, la media de bitrate del video
resultante debe estar obligatoriamente siempre entre 4000 kbps y 8000 kbps para
releases 720p mientras que entre 8000 kbps y 14000 kbps para releases 1080p.
4.8) Si se decide usar CRF, se debe seguir el siguiente rango:
720p: 18-19 / 1080p: 17-19 -> Cine, guionizado, talk, animaci≤n.
720p: 20-21 / 1080p: 20-21 -> Docs, realities, variedad.
720p: 22-24 / 1080p: 22-24 -> Deportes, espectβculos, directos, competicion.
4.9) Si se decide usar CRF, en el caso de series de televisi≤n u otro contenido capitulado,
el valor del CRF debe ser respetado para todos los captøtulos/partes correspondientes
de por lo menos aquella temporada o volumen, por cada calidad.
Ejemplo: Si se decide usar CRF 18 para la release 720p.BluRay de una serie en el
S01E01, toda la S01.720p debe ser a CRF 18. Las releases 1080p podrøan ser todas
a CRF 18 tambiθn todas a 17 o 19 o todas a tama±o, pero nunca mezcladas o variado.
4.10) Si se decide usar tama±o como mθtodo de encodeo se debe respetar la siguente lista
de tama±os finales. Este tama±o incluye todas las pistas de audio en caso de MULTi
o la Espa±ol Castellano mβs el vødeo y subtøtulos o øndice de capøtulos del propio .mkv:
1 MiB = 1048576 bytes
- M˙ltiples de 1120, 2713 o 8140.
- DVD5/x 896, 1120, 1493, 2240 o 4480.
No hay tama±o mønimo o mβximo especificado, va en funci≤n al bitrate y el n˙mero de
pistas, pero la media de bitrate de vødeo resultante siempre debe ser como estβ
explicado en el punto 4.7. Se permite un sobrepaso / falta de 30 MB en el tama±o
total del contenedor final.
4.11) Linea de comando sugerida:
- CRF: x264.exe --crf ## --preset slow --level 4.1 -o salida.mkv entrada.avs
- Tama±o: x264.exe --pass 1 --stats datos.stats --bitrate #### --preset slow --level 4.1 -o NUL entrada.avs
x264.exe --pass 2 --stats datos.stats --bitrate #### --preset slow --level 4.1 -o salida.mkv entrada.avs
5) Contenedores:
5.1) El contenedor debe ser Matroska (MKV).
5.2) El release debe estar en un solo contenedor, no se permite dividir la release
en varios contenedores.
5.3) Se recomienda muxear con mkvmerge, aunque se permiten tools personalizadas.
El resultado debe ser demuxeable y compatible con las herramientas mkvtoolnix.
6) Sample:
6.1) Obligatorio, debe estar en una carpeta separada llamada "Sample", ser
de entre 60-120 segundos y ser de la rls, no encodeado por separado.
7) Empaquetamiento:
7.1) La release debe ser empaquetada en partes RAR de 50 MiB o m˙ltiples de 50.
Nunca mβs de 99 partes. No se permite la compresi≤n. 1 MiB = 1048576 bytes.
7.2) NFO y SFV obligatorios. Los archivos Sample, Proof, RAR y SFV deben tener
el mismo nombre, en minusculas y con la tag del grupo.
7.3) RAR's o SFV corruptos u olvidados despues de prear = REPACK o PROPER.
7.4) Se recomienda a±adir la siguiente informaci≤n en el NFO:
-Nombre del grupo
-Titulo
-Fecha del release
-Valor de CRF
-IMDB
-N˙mero de rars (e.g.30x100MiB)
8) Proof:
8.1) OBLIGATORIA para cada release (para cada capøtulo en una serie, por
ejemplo). Sin proof cuando se prea = NUKE no.proof.provided en un
rango de 6 horas (si no se saca una version PROPER antes). Despuθs
de estas 6 horas, un PROOFFIX no serβ aceptado. La proof debe ser una
foto (no se permiten escaneos) del medio føsico (disco/s) por el lado
impreso con una nota que tenga el nombre del grupo, en formato JPEG.
La imagen debe ser de buena calidad, donde se aprecien claramente los
detalles y sea legible. Peque±as partes de la imagen se pueden ocultar,
recortar o censurar si contienen informacion sensible. Para series de
TV u otros medios que puedan venir separados por discos, es obligatorio
que aparezcan todos los discos.
8.2) La imagen debe estar en una carpeta (dentro de la relase) separada llamada
/Proof. Sigue la misma estructura que otros archivos de la release, ver punto
7.2.
8.3) Algunos m≤viles u otros dispositivos a±aden la metadata EXIF en las fotos.
Esta metadata puede contener informaci≤n como por ejemplo localizaci≤n por
GPS. Es MUY IMPORTANTE que te asegures de borrar esta metadata de tu Proof,
si la tiene. Es suficiente con abrir y re-guardar con Microsoft Paint o usar
cualquiera de las tools freeware que encontrarβs buscando "exif remover" por
la red.
8.4) Se recomienda, pero no es obligatorio, a±adir un enlace web en el NFO de la
release hacia la Proof (Tinypic, Imgur...) con tal de evitar los fallos de
los autotraders que pueden inducir a error/skip de la Proof.
9) Propers:
9.1) Properear solo se permite si la release original tiene un fallo tecnico.
ejemplos: falta contenido, mal cropeo, contiene errores, drops, audio
fuera de sincronizaci≤n, parametros x264 erroneos, errores en los subtøtulos,
etc.
9.2) Se debe explicar y justificar la razon de PROPER en el NFO de la rls PROPER.
Se recomienda adjuntar sample/s o captura/s para demostrar.
9.3) Los propers basados en las reglas aquø explicadas solo se permiten para las
rls que se prearan despues de que este documento entre en efecto.
9.4) No se permite prear una release PROPER por raz≤n de subtitulos, si la release
PROPER no contiene los subtøtulos correctos o sin fallos. Debe contener los
mismos idiomas que la release nukeada, o mβs. De lo contrario sera considerado
un PROPER no vβlido.
9.5) Una rls con fallos tecnicos, experimental, o con mβs pistas de audio puede ser
preada como INTERNAL. Explicar el porquθ en el NFO es obligatorio = nuke.
10) Internals:
10.1) El tag debe ser .INTERNAL.
10.2) No hace falta seguir la parte tθcnica de estas reglas pero si debe contener
obligatoriamente Proof, Sample, NFO, SFV y ser empaquetada siguiendo las reglas
arriba expuestas. La Proof es obligatoria tambien para los INTERNAL.
11) Subtitulos:
11.1) Solo se permiten los subtitulos .SRT y .IDX/.SUB. Cualquier otro formato de subtitulos
estβ considerado fallo tθcnico. La extraccion y/o conversi≤n debe ser completamente correcta.
Se recomienda hacer esto usando tools como tsMuxer, VobSub, SubRip, BDSup2Sub, SupRip... etc.
11.2) Subtitulos en formato .SRT se han de muxear obligatoriamente, en formato .IDX/.SUB queda
prohibido muxearlos y hay que incluirlos en el folder /Subs dentro de la release, con la
siguiente estructura de directorios: Release/Subs/releasesubs.rar+idx+sfv. Este releasesubs.rar
contiene el archivo .SUB rareado (se permite y recomienda usar la mejor compresi≤n) acompa±ado
de su correspondiente .IDX sin rarear. El SFV de la carpeta /Subs (en caso de usar subtitulos
.IDX/.SUB) solo ha de listar el contenido de esta, y no el de la release. El SFV de la release
no debe listar el contenido de ninguna /Carpeta.
11.3) Los subtitulos Espa±ol son obligatorios para las releases que contengan partes habladas en otros
idiomas que no sean Espa±ol Castellano o Latino, aunque se recomienda incluirlos para todas las
releases. Solo se permiten los subtitulos extraidos del medio føsico, no fansubs, no custom subs
o subs de otras fuentes. Otros idiomas de subtøtulos son bienvenidos, pero no obligatorios en
ning˙n caso.
12) Nombre de los directorios:
12.1) Tags de fuentes: 1080p.BluRay, 720p.BluRay, 720p.HDDVD, 1080p.HDDVD
12.2) Nombre.Pelicula.A╤O.SPANiSH.<DUAL/MULTi>.<1080p/720p>.BluRay.x264-GRUPO.
12.3) Nombre.Serie.<Codigo>.<A╤O>.SXXEXX.SPANiSH.<DUAL/MULTi>.<1080p/720p>.BluRay.x264-GRUPO.
12.4) Es obligatorio a±adir el a±o de PRODUCCION para peløculas, no el de publicaci≤n
en cines/tv/otros. Para series/miniseries el a±o es opcional pero recomendado
si ya ha existido otra serie/miniserie con el mismo nombre en un a±o diferente.
En el caso de que ya haya existido otra serie/miniserie con el mismo nombre en
otro pais, se debe usar el c≤digo del pais (UK, US, ES, AU...) o el a±o siempre
que no coincidan.
12.5) Se permite el uso de la tags: REAL, REMASTERED, RERIP, PROPER, INTERNAL, REPACK,
FINAL, UNCUT, DOC, EXTENDED y READ.NFO.
V.EXTENDIDA u otros derviados quedan prohibidos. Deben ir antes de .SPANiSH.
12.6) Los carβcteres aceptables en los nombres de directorio son:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789._-
Sin espacios o dobles puntos, puntos ˙nicos exclusivamente.
13) Reglas especiales:
13.1) Reencodear releases de otros sources que no sean discos BluRay y/o HDDVD queda
prohibido. Ademas, se debe presentar proof obligatoriamente para cada release.
13.2) Cualquier otro tipo de pre que no sea lo que cubre este documento (retail HDDVD/BluRay)
se rige por lo aquø explicado y debe seguir todas las reglas, a excepci≤n de la Proof.
Ejemplos: CAM, TS, TC, SCREENER, DVDSCR o BDSCR. Estos releases no cuentan como dupe
cuando se prea de retail.
13.3) Nuestras releases no son dupe del pre spam P2P que dice ser algo,
no nos preocuparemos de mirar dupecheck o utilizar tags como PROPER,
INTERNAL mβs alla de los grupos conocidos en prear bien y legit, que
son los que han firmado este documento.
13.4) Debido a la gran cantidad de pre p2p que hay actualmente, cualquier otro nuevo
grupo (o ex) interesado en prear releases retail HD en SPANiSH deberβ seguir
todo lo especificado en este documento y contactar con nosotros con tal de su
adhesi≤n en el concilio. GUSTE O NO GUSTE, es la ˙nica manera de saber quiθn
quiere hacer las cosas bien y quien no. De lo contrario serβ ignorado como
se explica en el punto anterior 13.3.
[Changelog]:
2014-07-21 - Primera versi≤n.
---------------------------------------------------------------
Ruleset x264 para releases HDDVD o BluRay en Espa±ol (Castellano)
-> Firmado por los siguientes grupos:
0ld - ASS - FCC - JODER - LPH - MAHOU - sPHD - TORO - XPERT - XPERT_HD
-> Declinado por los siguientes grupos:
--------------------------------------------------------------
The.Spanish.Retail.HD.Releasing.Standards.2014-ESCOUNCiL (2014-07-21)