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, which obtained and released the copy of a movie 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.
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 640×272 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.
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 - file size is over what the CD/DVD holds.
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.
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.
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.
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.
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.
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…