<!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>