Standards in the warez scene are defined by groups of people who have been involved in its activities for several years and have established connections to large groups. These people form a committee, which creates drafts for approval of the large groups. In organized warez distribution, all releases must follow these predefined standards to become accepted material. The standards committee usually cycles several drafts and finally decides which is best suited for the purpose, and then releases the draft for approval. Once the draft has been signed by several bigger groups, it becomes ratified and accepted as the current standard. There are separate standards for each category of releases.

more

An overview of these rules can be found here

If you're a hardcore scener, you can probably leave this thread right now, there's no use in reading the following paragraphs. However, there are also many people who are not so familiar with a scene slang and that's why I've decided to collect a list of most common nuke reasons and explain them for you. This way, you will always know what to expect from a release which is nuked.

General DELPRE reasons

pre.spam
Any abuse of the prebots is considered prespam. For example adding fake releases or putting out personal messages (HELLO.WORLD-SCC etc)

cut.echo
Relaying pre's all depends on well configured filters. For example releases by the group VH-PROD often get cut. If you look at the default naming of movie releases the groupname always follows after the first - for example HELLO.WORLD-VH-PROD. Since this group uses a - in their name misconfigured bots will pass on the release as HELLO.WORLD.XVID-VH leaving out the -PROD. THis is one example of a cut echo.

General NUKE reasons

missing.region.info.or.tag
For some releases it's mandatory to list which region the material is from either in the dirname of the release or in the nfo.

selfmade.compilations.not.allowed
Generally nothing selfmade is allowed. For example music (best of) compilations or collections of classic games which are not available for sale. This to ensure quality and keep the amount of duplicate material at bay.

internal.shields.dupe.only
The effects of the "INTERNAL" tag are a general misconception. This tag is supposed to be used for rereleases of popular old titles according to todays standards. It can also be used when the original release is of bad quality. Quality isn't a legit reason to nuke a release as long as all rules were applied correctly. This is when an INTERNAL copy can be released. The original release wont be nuked this way. It only prevents releases from being nuked for being a dupe. All other rules should be applied. *INTERNAL release aren't allowed on the majority of sites (because they are dupes by default) This is what makes them so rare.

stolen.from.p2p
lately a very popular and common nuke reason. This basically means that the scene group which pred the release stole it from another source - specifically a peer to peer network (p2p) in this case. In most cases, this means a private BitTorrent tracker, DC hub or webblog which obtained and released the copy of a title faster than any other scene source. This nuke reason will not affect your viewer�s experience and many sceners consider it useless as we basically steal the movies anyway.

stolen.src
stolen source. Similar or same as the above nuke reason. Scene groups can steal the video or audio also from each other, apart from stealing from peer to peer networks.

dupe
dupe means simply a dupe. The nuked release was already released by another group earlier, so the nuked one is basically useless, doubled. This doesn�t really matter if you don�t care about the strict scene rules.

undersized
a release is nuked for being undersized when it doesn�t fully use the capacity of one or two CDs. This means that the final rip is for example 680 MB, while it could be 700 MB and offer a better quality of image and audio. Once again, this is not a serious deal unless it�s undersized by hundreds of megabytes.

oversized
guess what.

mislabeled
a release trying to look like a better quality rip. A good example would be an R5 rip from Russian video source released as dvdrip - the difference isn�t that big in this case and scene groups always get more props for releasing dvdrips. The another case can be a typo or wrong year in the release name.

grp.req
a nuke requested by the release group. Happens when a scene group releases something and realize it�s completely wrong, not working or simply bad, so they request a nuke.

bad.pack
bad packing. The group didn�t pack their release properly, according to scene rules. This means they either forgot to pack it into 15/20/50 MB RARs or it�s completely impossible to unpack it.

compression.used/m0
One mistake often made when packing releases is the use of the wrong compression mode when creating the archives. Depending of the files inside the archives there might or might not be use for compression. For example an already compressed (XViD) movie wont decrease in size while compressing a raw image will decrease by 50% or more in size. ISO's of (console) games often contain text files and images which can be compressed. This is why each section has a rule on using m0 (no compression just "storing" the files inside archives) or m1 (minor compression). The higher the level of compression the longer it takes to compress and decompress the archives.

invalid.proper
proper is a release fixing other, previously nuked release. When a certain group releases proper and the first release is actually fine, the new one becomes nuked for invalid proper.

Foreign NUKE reasons

Season.shield
A nukereason seen in the german TV scene where the group that pres the first episode of a season gets to pre every following ep that season. If another group pres an episode of the shielded season it will get nuked. (yes ... retarded)

Movie NUKE reasons based on TDX 2005.

bad.res
bad image resolution. The scene rules define allowed image resolutions and their aspect ratios. If a movie doesn�t fit in these rules, it means the image will be probably malformed in a certain way. Many advanced video players allow to change the image resolution, so this can be sometimes fixed at your computer.

bad.ar
bad aspect ratio. A similar reason to the above one. Each video was originally filmed and released in a specific aspect ratio (horizontal vs. vertical side). The most common AR is 2.35:1 which is for example a resolution of 640x272 pixels. Bad aspect ratio leads to inproportional image, where characters appear to be either too wide or, more often, too tall. This can be also fixed with some media players.

bad.crop, overcropped
movies on DVD contain black parts of the image above and below the actual video. In order to decrease the final size and offer the best possible quality, these black parts must be removed before encoding and releasing in xvid. Sometimes, scene groups don�t properly remove / crop these parts and it means that the image misses top or bottom part, therefore you don�t see the whole scene. Cropping is often used also for removing watermarks or hardcoded subtitles, but it still means a serious loss of the image. The other, not so common extreme, is when a group forgets to remove these black boxes.

bad.ivtc, no.ivtc
quite a common nuke reason which affects mostly lower-quality releases. IVTC means inverse telecine and it�s basically a process of converting a movie (usually PAL) with high FPS (30 frames per second) to lower FPS (for example 24) in order to save space and offer better image quality. This conversion often goes wrong (bad.ivtc) or completely lacks (no.ivtc, lazy sceners)). As a result, the image appears to be jerky and the final release uses too much space for no reason.

interlaced
the image contains visible black lines, which often cause the video to be completely unwatchable. These black lines are visible mostly during movement on the image and are caused by incorrect field order. I won�t go into details explaining the reasons for this � it�s caused by different way of displaying frames and fields (half-frames) in the video, more details are available for example here. It�s highly recommended to not download any interlaced release.

cbr.audio
audio can be either CBR (constant bit rate), or VBR (variable bit rate). According to the scene rules, all releases should contain VBR audio, so any release with CBR is instantly nuked. Variable bit rate allows better quality, according to the current sound, while constant one sets the same quality for the whole movie, including the quiet parts. However, releases with AC3 audio almost always use CBR. It�s often hard to distinguish the difference between CBR and VBR for an untrained ear, so this nuke reason isn�t too serious if you don�t care about the rules.

bad.fps
bad frame rate. The frame rate should be close to the original framerate. Not a very common nuke reason, but it�s better to beware any release with this nuke.

oos, out.of.sync
out of sync, audio isn�t synced with video. Extremely annoying mistake which makes most of such release completely unwatchable. This happens very often with cams, telesyncs and telecines, which require a synchronization of audio and video from different source. Some releases are completely out of sync, while others have this problem only for a few seconds or minutes.

qpel.not.allowed
qpel or quarter pixel is a feature of modern encoding codecs such as H.264 which allows better and more efficient compression. Videos encoded with quarter-pixel precision motion vectors require up to twice as much processing power to encode, and 30-60% more processing power to decode. Thus, such releases often cause software problems or are completely unplayable at certain DVD players.

ghosting
annoying feature of a release, which result into ghost effect during every movement in the movie. It�s caused by inproper encoding and can�t be easily fixed.

field.shifted, dupe.frames, blended.frames, custom.quant.matrix
other mostly serious faults affecting the image, caused during encoding the final video.

divx.not.allowed, no.audio, missing.audio, get.rerip, get.proper
no need to explain these I guess.

0DAY NUKE reasons based on 0DAY ruleset 2010.1.

MU
MU stands for Minor Update. This term denotes an update of a previously released application within a certain time-period, the MU-period. Major updates are allowed regardless of the last time a previous version was released. In this case, the nfo must include some motivation for considering this a major update (security- and stability-critical hotfixes for instance). Typical major updates are defined as a version-change for the most significant number in the version, for instance v9.1 being updated to v10.0. Exceptions are possible, but must be noted in the nfo.
The minimum MU-period is 1 month

WII NUKE Reasons

scrubbed.dumps.not.allowed
WII games use "garbage" data to fill up the size of a DVD5/9. This data is useless and a waste of storage space and bandwith however it's forbidden to release an ISO without this data (dump)

MP3 NUKE Reasons

low.audio.bitrate
It's forbidden to use a minimum or maximum bitrate when encoding an MP3 release however the minimum bitrate for CBR MP3's bought from an online store is 192kbit.

The following article will describe the process of distributing a preannouncement from the site it was issued on to the prechan it ended up.

As with every scene there will always be sub scenes. Even in the world of filesharing the definitions of being a "scener" widely vary. A scener might be someone who's on a ranked site or he who's part of a releasegroup where a racer on unranked sites is considered a "site-scener". This also goes for the pre scene. Those with access to sitepre are considered elite while those on prenets are the average and those who are afiliated with p2p/public or echo are considered noobs.

This article is split in three sections matching above mentioned groups.

SitePRE
When a release is pred the directory containing the files is first uploaded to an FTP by a member of the releasegroup. The FTP uses a set of scripts (zipscript) to verify and index the release. A set of these scripts is called a sitebot. This bot will for example index the name, size and filecount of the release.
Next is issueing the actual !pre command where the release is made public and announced by an eggdrop bot which queries the sitebot and announces it in the site's IRC channel, sitechan,  and addpre chan. The term addpre chan gives away that it's a channel where pre's are added and uses a uniform style. This makes it easier for bots to understand the information that passes by.

Example of a release that was pred being announced in the sitechan:

<SITEBOT>  [PRE-RELEASE] ==] MiSTAKE PRE [== Met.Het.Mes.Op.Tafel.S03E13.DUTCH.WS.PDTV.x264-MiSTAKE - (with 245MB in 20 Files) - [TV]

Example of the release being announced in the addpre chan:

<BOT1> !addpre Met.Het.Mes.Op.Tafel.S03E13.DUTCH.WS.PDTV.x264-MiSTAKE TV
<BOT2> !info Met.Het.Mes.Op.Tafel.S03E13.DUTCH.WS.PDTV.x264-MiSTAKE 245MB 20F

At this point the members of the site have noticed the announcement of the bot in the sitechan and the bots in the addpre chan have picked up the addpre signal.

PreNet
A PreNet is an IRC network that operates as a central hub where announcements relayed from above mentioned sites come together. Since each site has a couple affils it takes access to a lot of sites to make up the amount of releases you see passing by in the average prechan.
A PreNet is also the place where nukes are issued and rules are debated.
If you're on a PreNet you have access to a feed which carries about every preannouncement made globally. Next up is the local part. The term local is used because owners of prebots relay the feed from a prenet to a local, private channel where they are alone with their prebot. This is where the prebot gets the info from which he outputs in a fancy way in the prechan you have access to.

P2P-Pre-Scene
Getting into sites and prenets takes some skill and especially the right contacts. People who don't have these assets but still want to run a prebot can resort to echoing. Echoing is simply copying information from one chan or another. This behaviour is against the etiquette and will get you in trouble.
WebPreDB's often use these sources which isn't a real problem just that they contain more spam than the pure feed and are a bit slower. Sites like OrlyDB are known for echoing prechannels run by private trackers.

This can be best shown by a real life Example