264 lines
12 KiB
HTML
264 lines
12 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>misc.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">RE: MP3 BONUS TRACKS RULE
|
||
|
|
(taken from Jennifer_Hudson-I_Remember_Me-(Deluxe_Edition_Bonus_Tracks)-2011-C4)
|
||
|
|
|
||
|
|
It seems for the past few years we've been using the wrong
|
||
|
|
calculation for bonus tracks. The rules specifically say "of
|
||
|
|
your version," but we've been using the ratio of new tracks on
|
||
|
|
our release to the number of old tracks on the previous release,
|
||
|
|
which in this case yields 33% (4/12). This is wrong according to
|
||
|
|
the rules, and the calculation should be 25% (4/16). Our apologies
|
||
|
|
for this mixup.
|
||
|
|
|
||
|
|
________________________________________________________________________________________________________
|
||
|
|
|
||
|
|
Regarding 0DAY:
|
||
|
|
|
||
|
|
crack == regged (dupe each other)
|
||
|
|
keygen doesn't dupe cracked/regged IF it's keygen.only
|
||
|
|
incl.keygen = dupe.CRACKED/REGGED.YYYY-MM-DD_release.keygen.only IF cracked/regged release is out first
|
||
|
|
|
||
|
|
Releases do NOT dupe universal keygens
|
||
|
|
|
||
|
|
Maximum size of releases should be 300MB, however countless releases are over this size, and can't be
|
||
|
|
made any smaller. Numerous 0DAY sites no longer follow this rule, numerous groups/applications cannot
|
||
|
|
follow this rule, etc, nuking for this reason is not reccomended.
|
||
|
|
|
||
|
|
________________________________________________________________________________________________________
|
||
|
|
|
||
|
|
Regarding IVTC/AR on CAMs:
|
||
|
|
(taken from Death.Race.REPACK.READ.NFO.TELESYNC.XviD-OPTiC)
|
||
|
|
|
||
|
|
"
|
||
|
|
The subject of NTSC CiNEMA needs to be addressed, it would
|
||
|
|
seem that there's some serious confusion about incorrect ivtc,
|
||
|
|
specifically on 29.970 fps source content, when it's filmed there
|
||
|
|
are naturally more frames present in a span of 1 second compared
|
||
|
|
to the projection equipment which runs at 23.976 fps, in this
|
||
|
|
situation you will experience some frames which are a combination
|
||
|
|
of 2 film frames. This is not a typical way of broadcasting and
|
||
|
|
thus there is no consistent pattern in where the dupe frames occur.
|
||
|
|
these are the only bad frames that are really present in the
|
||
|
|
recording. But, naturally some decimation is expected by everyone,
|
||
|
|
so if you want 23.976 fps as the end result than you can only
|
||
|
|
simply ivtc in this case, you never really have "dupe frames" to
|
||
|
|
work with. Due to flickering, changing lights, noise, etc., the
|
||
|
|
same frame filmed twice will not be 100% identical. That's why
|
||
|
|
it's nearly impossible to remove dupe frames when capturing a
|
||
|
|
broadcast by camera. It's decimated to 23.976, but keep in mind
|
||
|
|
you can't be sure if the removed frames are unique or the "dupe"
|
||
|
|
frames. The idea behind bitching "improper ivtc" is that you don't
|
||
|
|
want to waste bits on frames that are identical obviously - and
|
||
|
|
you want an encode that runs at the same framerate as the original
|
||
|
|
film. That's a great idea, but impossible to perfect when you're
|
||
|
|
capturing the movie off a cinema screen with a camera. This encode
|
||
|
|
runs at the correct framerate and has been treated as good as
|
||
|
|
possible with regards to dupe frames. I know what you're thinking
|
||
|
|
"go through all 141332 frames manually and delete those that are
|
||
|
|
dupes"? Bad idea. You can't just go randomly deleting frames since
|
||
|
|
there's no pattern in the presence of dupe frames on our source.
|
||
|
|
You'd had to be sure you remove those extra frames on every second
|
||
|
|
of footage. Since there's no pattern, you'll have to delete good
|
||
|
|
frames too and some times not in a consistant pattern and guess
|
||
|
|
what that gives you. Yup, jerky movement.
|
||
|
|
|
||
|
|
Also, regarding proper size when refering to resolution, honestly
|
||
|
|
this is the discretion of the encoder, based on the source you
|
||
|
|
have. The resolution is mod16 and AR is correct to the source.
|
||
|
|
Whining about AR just because it isn't 2.35, 2.5 1.77 or whatever,
|
||
|
|
doesn't make it a valid nuke reason. Given the source, this is the
|
||
|
|
perfect AR (2 vs. 2.006).
|
||
|
|
"
|
||
|
|
|
||
|
|
________________________________________________________________________________________________________
|
||
|
|
|
||
|
|
Various no-no's on DVDR (re)authoring:
|
||
|
|
http://dvdafteredit.com/node/1121
|
||
|
|
|
||
|
|
"NOP This is a no operation command, which essentially does nothing.
|
||
|
|
In general the use of the Nop command should be avoided since
|
||
|
|
many DVD-Video players interpret a Nop command as a Stop command."
|
||
|
|
|
||
|
|
Ralph LaBarge, DVD AUTHORING & PRODUCTION (CMP Books, 2001) 201.
|
||
|
|
|
||
|
|
Other DVDR Resources:
|
||
|
|
http://www.dvd-replica.com/
|
||
|
|
|
||
|
|
________________________________________________________________________________________________________
|
||
|
|
|
||
|
|
New resolution rules in txd2k9:
|
||
|
|
|
||
|
|
" the new xvid rules contain a gay
|
||
|
|
clause not allowing a resolution above 640x due to some
|
||
|
|
piece of shit $20 Philips divx player that is apparently
|
||
|
|
popular and is unable to disply the correct aspect ratio
|
||
|
|
on a WS tv (or some other bullshit) when the res is over 640."
|
||
|
|
|
||
|
|
from Law.and.Order.SVU.S08E16.PROPER.DVDRip.XviD-NODLABS
|
||
|
|
|
||
|
|
________________________________________________________________________________________________________
|
||
|
|
|
||
|
|
FPS Based runtime differences:
|
||
|
|
|
||
|
|
movie frame count / fps * 60 = minutes
|
||
|
|
|
||
|
|
Count the movie frames (minus studio intro + credits)
|
||
|
|
If they are the same, = dupe.
|
||
|
|
|
||
|
|
eg:
|
||
|
|
|
||
|
|
Green.Street.Hooligans.2.UNRATED.DVDRip.XviD-HNR
|
||
|
|
http://scenerules.irc.gs/fpsdif.png
|
||
|
|
|
||
|
|
________________________________________________________________________________________________________
|
||
|
|
|
||
|
|
"BivX (for Bi-DivX - Bilingual-DivX) is a DivX which includes two audio tracks, as with a DVD, which you
|
||
|
|
can choose between one language or another."
|
||
|
|
|
||
|
|
http://tinyurl.com/ydcdbrj
|
||
|
|
http://tinyurl.com/ycxa8wy
|
||
|
|
|
||
|
|
________________________________________________________________________________________________________
|
||
|
|
|
||
|
|
RE: UBISOFT DRM / SKiDROW
|
||
|
|
|
||
|
|
http://scenerules.irc.gs/t.html?id=rzr-set7.nfo
|
||
|
|
^ The_Settlers_7-Razor1911
|
||
|
|
|
||
|
|
http://scenerules.irc.gs/t.html?id=dormine.nfo
|
||
|
|
^ Assassins_Creed_2_READNFO_ONLY-DORMINE
|
||
|
|
________________________________________________________________________________________________________
|
||
|
|
|
||
|
|
What is PDTV?
|
||
|
|
|
||
|
|
http://scenerules.irc.gs/t.html?id=pdtv.nfo
|
||
|
|
^ found as "pdtv.nfo"
|
||
|
|
________________________________________________________________________________________________________
|
||
|
|
|
||
|
|
RE: DOWNSAMPLED AUDIO ON NON-RETAIL MOVIE-XVID SOURCES
|
||
|
|
|
||
|
|
"We noticed that there became popular such nuke reason
|
||
|
|
as downsampled audio for TS/TC releases. Dunno if all these nukers ever
|
||
|
|
heard about Nyquist-Shannon theorem. Many direct audio today doesn't
|
||
|
|
contain any frequencies above 16kHz. (Check spectral-mvs.jpg for
|
||
|
|
example). So according to sampling theorem there is no need to raise
|
||
|
|
audio sampling rate above 32kHz. So 48kHz audio on TS/TC xvid ain't
|
||
|
|
necessary at all, but even more is just a waste of bitrate."
|
||
|
|
|
||
|
|
taken from: A.Note.To.maVenssupplieR.TC.XviD-ASTEROiDS
|
||
|
|
read more at: http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem
|
||
|
|
|
||
|
|
________________________________________________________________________________________________________
|
||
|
|
|
||
|
|
RE: LOL
|
||
|
|
|
||
|
|
How.I.Met.Your.Mother.S05E22.PROPER.READNFO.HDTV.XviD-LULZ (2010-05-11)
|
||
|
|
|
||
|
|
It appears as though LOL have watermarked yet another release from their supposed
|
||
|
|
pre-air source (note that the timestamp of the extracted AVI is often earlier than
|
||
|
|
the time of which the show airs in the east-coast[1], though this may not
|
||
|
|
necessarily prove anything).
|
||
|
|
|
||
|
|
LOL may have taken a content rating logo[2] and the Citytv logo[3] and overlayed
|
||
|
|
it on their source perhaps via an AVISynth filter such as Overlay[4].
|
||
|
|
|
||
|
|
Citytv broadcasts in HD DTT in the east- and west-coast.[5] Our source is the 1080i
|
||
|
|
public broadcast from the only east-coast Citytv station (CITY-TV) via DTT. Notice
|
||
|
|
that the timings, appearance, and alignment of both the content rating and station
|
||
|
|
logos are different compared to LOL's release. For instance, LOL's Citytv logo fades
|
||
|
|
in as a whole, whereas our legitimate Citytv logo flies in letter by letter. Also,
|
||
|
|
CITY-TV did not broadcast the scene at the end of LOL's release with the man in
|
||
|
|
the elevator.
|
||
|
|
|
||
|
|
So if LOL actually capped from east-coast CITY-TV, and released the show before
|
||
|
|
another HD Citytv station had aired it (which they did), why would such
|
||
|
|
discrepancies exist? Remember, there's only one Citytv station in the east-coast
|
||
|
|
and evidently[6] LOL didn't do a great job of making their source seem legitimate,
|
||
|
|
even though they shouldn't have tried to from the get-go.
|
||
|
|
|
||
|
|
Assuming (the possibly unlikely case) that their pre-air source is a "backhaul"
|
||
|
|
feed[7] in which flagship stations distribute shows to their affiliates, then it
|
||
|
|
may be expected to be sans-logo as affiliates are to overlay their own logo.
|
||
|
|
|
||
|
|
There's even a rule in the 2008 TV-X264 ruleset stating that "group watermarks
|
||
|
|
of any kind on the video will not be tolerated,"[8] so it seems perplexing as
|
||
|
|
to how DIMENSION are preing some of their releases scot-free.
|
||
|
|
|
||
|
|
Moreover, it is interesting to note that for many of their releases, regardless of
|
||
|
|
show or station (i.e., "Citytv" or "WDRB"), the content-rating logo usually fades
|
||
|
|
in at 2s and fades out at 11s.
|
||
|
|
|
||
|
|
LOL are welcome to disprove these allegations of group watermarking by providing
|
||
|
|
an unedited source sample and an explanation. If they cannot in a timely manner,
|
||
|
|
or choose to continue to pre these group-watermarked releases, we may continue
|
||
|
|
to proper them. In the meantime, here is the actual broadcast of the show on
|
||
|
|
CITY-TV for the interested (ours is cropped to the widest frame[8]).
|
||
|
|
|
||
|
|
On another note, the recent biases and hypocrisies that have been rotting the scene
|
||
|
|
have grown out of hand. It may be very likely that this release will be nuked and
|
||
|
|
LOL's release might not be nuked, both on the basis of a reason such as "no.such.
|
||
|
|
rule_there.are.no.tv.xvid.rules"[9]. If that is the case, why nuke any TV-XVID
|
||
|
|
release at all?
|
||
|
|
|
||
|
|
1. What was the point of the nukewar between P0W4 and 2HD regarding Flashforward
|
||
|
|
S01E12? Perhaps, that a group can proper another group's release for the most
|
||
|
|
minute of reasons, but only if the group that has propered has seniority.
|
||
|
|
Remember, P0W4 was unable to successfully use the same argument that was used
|
||
|
|
to unnuke LOL's release of Happy Town[9]. For instance, LULZ has absolutely no
|
||
|
|
seniority over LOL, so would we have the "right" to proper?
|
||
|
|
|
||
|
|
2. Groups with seniority do not deserve any leeway on their own technical flaws.
|
||
|
|
They must be held accountable just like any other TV-XVID group. If a group
|
||
|
|
has consistently ruined their releases, a "warning" nuke must not be made, but
|
||
|
|
all of the ruined releases must be retroactively nuked--regardless of group
|
||
|
|
seniority. For instance, this series is not the only one that LOL may have
|
||
|
|
watermarked with the Citytv logo (see Modern Family and Community). Will their
|
||
|
|
previous releases be retroactively nuked? Time will tell.
|
||
|
|
|
||
|
|
The bottom line is that all groups must be treated fairly and if there is a
|
||
|
|
proven and reasonable technical flaw with a release, it deserves to be nuked.
|
||
|
|
Any nuker that disagrees, does not deserve to be one.
|
||
|
|
|
||
|
|
Included:
|
||
|
|
1. Our source sample of the show (sample.mpg).
|
||
|
|
2. A clip of the local news (news.mpg) to prove that this source is CITY-TV.
|
||
|
|
3. A screenshot of the timestamp (timestamp.png) of the AVI of LOL's release.
|
||
|
|
4. Frame comparisons of both releases (comparisons/).
|
||
|
|
|
||
|
|
References:
|
||
|
|
1. See timestamp.png.
|
||
|
|
2. http://en.wikipedia.org/wiki/Television_content_rating_systems#Canadian_ratings
|
||
|
|
3. http://en.wikipedia.org/wiki/File:Citytv_HD_logo.svg
|
||
|
|
4. http://avisynth.org/mediawiki/Overlay
|
||
|
|
5. http://en.wikipedia.org/wiki/Citytv#Citytv_HD
|
||
|
|
6. See frame comparisons.
|
||
|
|
7. http://news.cnet.com/2100-1023-258229.html
|
||
|
|
8. http://rules.nukenet.info/t.html?id=2008_TV_X264.nfo
|
||
|
|
9. See nuke history for Happy.Town.S01E01.HDTV.XviD-LOL.
|
||
|
|
|
||
|
|
- We did it for teh lulz. ;)
|
||
|
|
|
||
|
|
</pre>
|
||
|
|
</body>
|
||
|
|
</html>
|