121 lines
7.0 KiB
HTML
121 lines
7.0 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>2009_MP3R.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">
|
||
|
|
▀▀▀▀▀███ ▀▀▀▀▀███ ▀▀▀▀▀███ ▀▀▀▀▀███
|
||
|
|
███ ██▀ ███ ▀▀▀ ███ ███ ███ ▀▀▀
|
||
|
|
███▀███ ███▀ ███▀██▄ ███
|
||
|
|
███ ███ ███ ███ ███ ███ ███ ███
|
||
|
|
███ ███ ███ ███ ███ ███ ███ ███
|
||
|
|
███ ███ ███ ███ ███ ███ ███ ███
|
||
|
|
███ ███ ███ ███ ███ ███ ███ ███
|
||
|
|
███ ███ ███ ███ ███ ███ ███ ███
|
||
|
|
███ ███ ███ ███ ███ ███ ███ ███
|
||
|
|
███▀███ ███▀███ ███ ███ ███▀███
|
||
|
|
███ ███ ███ ███
|
||
|
|
███ ███ ███▄ ███
|
||
|
|
|
||
|
|
Bleeding Edge Ripping Crew
|
||
|
|
─────────────────────────────────────────────────────────────
|
||
|
|
|
||
|
|
Presents:
|
||
|
|
|
||
|
|
RESPONSE/QUESTIONS ABOUT MP3RULES 2.0
|
||
|
|
|
||
|
|
Notes:
|
||
|
|
|
||
|
|
We noticed new ruleset was pred, and we read them, unlike the guys
|
||
|
|
who signed it...
|
||
|
|
|
||
|
|
We noticed a few problems with rule 20, section 2.
|
||
|
|
|
||
|
|
(Which would have been avoided had you simply enforced jpegs on
|
||
|
|
every release, instead of this silly system...)
|
||
|
|
|
||
|
|
> 2. A release might get "pre-nuked" if the source of the release is
|
||
|
|
> questionable. You are able to identify such a nuke by the string
|
||
|
|
> "SCANS.REQUESTED" in nukereason.
|
||
|
|
|
||
|
|
> The releasegroup then has 72 hours (starting when it gets nuked)
|
||
|
|
> to supply/release scans/photos which prove that the source is real.
|
||
|
|
|
||
|
|
> If useable scans/photos are supplied then the release gets unnuked.
|
||
|
|
> If no scans/photos are provided it remains nuked
|
||
|
|
> and then every other group is allowed to release it if scans/photos
|
||
|
|
> are included.
|
||
|
|
|
||
|
|
As you can see i separeted the rule-item in pieces, so you can see my
|
||
|
|
interpretations problems. Here we go:
|
||
|
|
|
||
|
|
1. First part says you can see the nuke by the string SCANS.REQUESTED.
|
||
|
|
Well, it is assumed (because we know how the system works) that only
|
||
|
|
the 34 crews who signed the rules have access to view this pre-nuke.
|
||
|
|
|
||
|
|
The question is:
|
||
|
|
|
||
|
|
How will this be announced to those without access? Will the releases
|
||
|
|
be nuked on sites (those with access to these pre-nukes)?
|
||
|
|
|
||
|
|
If not, then it's a useless rule when the majority of the groups
|
||
|
|
can't even see the pre-nuke. If it's viewable via
|
||
|
|
"site nukestatus/mp3dupe" on sites, then it's still rather useless
|
||
|
|
for most groups. Remember, the release that might end up being
|
||
|
|
pre-nuked doesn't have to be a recent release. Sometimes problems
|
||
|
|
are noticed after some time has gone by.
|
||
|
|
|
||
|
|
2. Then you have 72hrs to provide the scan, until that its a pre-nuke,
|
||
|
|
after 72hrs it's a real nuke and everybody can proper.
|
||
|
|
|
||
|
|
Hypothetical scenario: -GRP pre a release, it get's pre-nuked, and
|
||
|
|
no scans are provided within 72hrs. Release = NUKED.
|
||
|
|
|
||
|
|
5-10 days goes by, nobody propers.
|
||
|
|
|
||
|
|
-GRP pre's covers, what happens? is release still nuked?
|
||
|
|
|
||
|
|
or
|
||
|
|
|
||
|
|
-GRP pre's a repack with covers, what happens? is release dupe?
|
||
|
|
both nuked?
|
||
|
|
|
||
|
|
3. Last example, if jpg's are crappy (imagine some cellphone crap)
|
||
|
|
- who defines what is crap? is it solely based upon random ppl
|
||
|
|
nuke-requesting the release?
|
||
|
|
|
||
|
|
Does the -GRP get 72hrs to provide better quality proof? and same
|
||
|
|
question as above, if release is nuked cause of bad quality pictures,
|
||
|
|
can you supply new pictures, or pre entire release again without
|
||
|
|
problem?
|
||
|
|
|
||
|
|
--
|
||
|
|
It's all in the writing. This ruleset is open for interpretation,
|
||
|
|
since they are not clearly written. Maybe if you included some of the
|
||
|
|
older crews you excluded, this would not have happened.
|
||
|
|
|
||
|
|
Signed,
|
||
|
|
BERC (2009-08-20)
|
||
|
|
|
||
|
|
─────────────────────────────────────────────────────────────
|
||
|
|
|
||
|
|
</pre>
|
||
|
|
</body>
|
||
|
|
</html>
|