386 lines
18 KiB
HTML
386 lines
18 KiB
HTML
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
|
|
|
||
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
||
|
|
<head>
|
||
|
|
<title>2014_ES_HD.nfo</title>
|
||
|
|
<style type="text/css">
|
||
|
|
@font-face {
|
||
|
|
font-family: nfo;
|
||
|
|
font-style: normal;
|
||
|
|
font-weight: normal;
|
||
|
|
src: url(nfo.eot);
|
||
|
|
}
|
||
|
|
.nfo {
|
||
|
|
padding: 12px;
|
||
|
|
font-family: nfo, courier new;
|
||
|
|
font-size: 11px;
|
||
|
|
line-height: 1em;
|
||
|
|
}
|
||
|
|
</style>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<pre class="nfo"> 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)</pre>
|
||
|
|
</body>
|
||
|
|
</html>
|