Introduction:

This section displays the file types commonly found in a.b.w*, and the applications used to deal with them.

Archive Files

RAR:

RARs are identified by the extensions:

• RAR: either the first of an R##-Z## set, or the standard extension for all RAR archives starting with version 3.0 of WinRAR.
• R00-Z99: The extensions of RAR archive files that begin with an .RAR file.  
• 001-999:  Alternate all-numeric numbering system preferred by many release groups. The 001-file corresponds to the *.RAR file, or the part001.RAR file of the newer naming convention. Some file-splitting applications also use this form of numeric extension, but such file-splitting programs are not used in the warez or cd-image groups (including the video cd/dvd image groups.)
• REV: Starting with WinRAR v3.0, REV stands for "REcovery Volume", it is a parity-volume file which can be used to recover missing or (starting with WinRAR v 3.1,) damaged archive volumes. See the section on Parity files for <more-info>

To use RARs you should use WinRAR, obtainable from the authors at http://www.rarlabs.com/  WinRAR is well-tested and has been proven stable in release versions 2.9 and 3.1, 3.2 and beyond. Version 3.0 didn't have the ability to repair damaged archives with REV files, although it could replace missing ones! 2.9 didn't have the ability to use REV files at all, so the staff at the WarezFAQ recommends you get at least v3.1. WinRAR also has the ability to create a self-extracting-executable, as an .EXE file. These are generally not recommended for UseNet, as people are very leery of executable files, and some have filters in place to prevent them from being seen or downloaded.

ZIP:

Zips are readily identified by any extension beginning with the letter "Z". While there are other applications that use files beginning with "Z", they aren't discussed here because their use in binary UseNet is negligible.

Common zip file extensions:

• ZIP: by far the most common.
• Z and GZ: used by Unix-based zippers, but a standard "ZIP" none-the-less.
• Z00-ZZZ: used by WinZIP v8.1 or later, to indicate sequential volumes in an archive set.

Non-sequential zips are handled routinely by any standard "ZIP-capable" application, with WinZip being by far the most popular. WinRAR also handles them quite well.  Sequential zip volumes are a feature of WinZip v8.1 or later, and should be handled by that application or WinRAR.  WinZip is obtainable from the authors at http://www.winzip.com/  It is extremely stable.

Mass unzipping of a release is easily done by a number of applications such as "Unziplify" or WinRAR or WinZip 8.1 or later.

ACE:

ACE files typically have the extension series .ACE .C00 .C01..C99, etc.  They can be handled by WinACE, or by WinRAR. ACE is little used in the applications groups, but remains common among the game groups. Overall compression is inferior to WinRAR 3.1 and later, but the format remains popular among the gamers nonetheless.

Handling is otherwise identical to RAR archives.  WinACE can be obtained at http://www.winace.com/

UHA:

UHA or UHarc, is another archive compression algorithm. It is extremely efficient, often achieving greater compression than any other algorithm (RAR, ZIP, ACE, etc.) but is not much used in the binary groups on UseNet because implementations of it tend to be quite a bit slower than RAR, without offering sufficient improvement in compression to justify the additional CPU-time needed to compress or decompress an archive, and there is no convenient archive-splitting as there is with WinRAR. When size considerations are of paramount importance UHarc should be considered as the primary compressor. The resulting single archive can be split and encapsulated in RARs by WinRAR with no additional compression, gaining the benefit of extreme compression and convenient file sizes.

As UHA program binaries can come from multiple sources, no one particular version is linked-to here, rather we recommend you web-search on "UHA+compression", which should yield some links to current implementations. UHA implementations tend to be freeware. At this writing (June 2006) a nice implementation called WinUHA is available in beta and RC versions as "donation ware".

Support Files:

PAR

PAR = Parity ARchive and represents an attempt at implementing RAID-5-type Reed-Solomon redundancy for files, and not just hard drives. The idea is an offshoot of the Huffman ECC (Error Correcting Code) used to provide on-the-fly error correction for memory. In RAM, three (3) bits are used to provide an error-correcting code for an eight (8)-bit byte, and five (5) are needed for a 16-bit word, etc. That sort of ECC can correct errors of a single-bit per byte, and three bits per 16-bit word, and also adds the ability to notify the system on "some" errors of more than the specified number of incorrect bits. That algorithm is unsuitable for disk drives, but another algorithm named Reed-Solomon is  very well suited to drives (and files). It is that algorithm which is used in PAR and PAR2.

See <more_info> for examples of how this works.

The small PAR file itself is an index and can be used to verify that a downloaded file has the same CRC as it had on the original poster's, computer. In the event of a mismatch, then you need one or more of the P## files (where # = 0-9) in the ratio of one P## file per missing or damaged RAR/ZIP file.  The P## files themselves are the ones that contain the actual correction information. To use parity files you need a special program designed to deal with them. See <here> for a list of some programs, with download links.

PAR2

PAR2 is a different way of dealing with files which may be much larger than those commonly posted to the warez groups, such as an entire movie for example, in un-rared, un-split form. You would never make a 700MB PAR file to provide error correction for a 700MB AVI, but you can use PAR2 to make some smaller files, able to repair a number of damaged segments. The large files are "logically divided" into smaller segments of user-defined size, and PAR2 then proceeds to make a (user-defined) number of parity segments, which it then clusters into PAR2 files, according to a controllable order, i.e. first PAR2 file has one segment, the second has two, the third has four, the fourth has eight, etc. You define how many segments you think you will need over all, and cluster them into PAR2 files of varying size. Thus a user will be able to download only as many PAR2 files as contain the necessary number of segments needed to repair the downloaded files.

Imagine the 700MB AVI file being split by a splitter program into 1,400 files of 1/2 megabyte (500,000-byte) each, and making some PAR files for them. PAR2 does this without physically splitting the original files at all, but it does do so logically, and makes a number of  PAR2 segments which it then clusters into PAR2 files of either the same or varying size (user-selectable.) A PAR2 file may contain any number of segments. Generally the programs that create PAR2 files do so with progressive sizes as a user-selectable option. Since you only need to download as many PAR2 segments as you have damaged segments in your downloaded file or file-set, the overhead is low. The PAR2 program (such as QuickPAR) will tell you how many segments you need to download to repair damaged or missing segments. PAR2 files are named in such a way that you can tell how many segments are contained in each one. You need merely download as many PAR2 files as will total the number of segments you need to repair/replace.

At this writing (September 2003) PAR2 is not used much in a.b.w* or its related groups yet, where individual file sizes tend to be small, but it is used quite a bit in the movie groups where 15 to 50 MB RAR files are common. It is more likely that you will only need some segments of a very-large RAR rather then all of them. You can "force download" the incomplete file with many newsreaders, Agent included. (With Agent, "join sections" - make sure they are in the correct order!) Download such PAR2 files as contain the same (or greater) number of segments that you need to repair the files you have downloaded, and let the PAR2 program work its magic.

 From http://parchive.sourceforge.net, a statement from the developers of both levels of PARchives:

Editors note: As of May, 2007 the Version 2.0 format, as embodied in QuickPAR, dominates the PAR formats in use on UseNet.

SFV

SFV is from "Simple File Verification" and is simply a CRC (Cyclic Redundancy Check sum) for each file in the set. In simple terms an SFV is a text file that is used by specific programs to verify that what you downloaded is precisely the same as what was uploaded. It will tell you if any of the files in the archive set are missing or corrupt. It is very fast. See here for <more_info>  The files are small, and quickly made and posted, using the appropriate client.

NFO

NFO = INFOrmation, and is a DOS-readable text file containing any information the release-group or poster believes is important. You can read it with Notepad or with any other text-reading program, but NFOs display best in a program designed specifically to read them, such as DAMN's NFOVIEW. Click here for <more_info> and a link to such a program.

CD/DVD Image Files:

These files contain a complete "image" of a CD or a DVD. These are not ordinary data-files, but contain track and sector information, the CD/DVD-file system data, etc. These files require special handling, and special programs to deal with each data-type, although there are some programs that can very capably deal with a multitude of image-file types.

BIN

BIN = Binary file. It typically has a small text file with, with the extension .CUE. Both are needed to burn the CD-image contained in the BIN file.  If you have a BIN without the CUE, you will need to make a CUE in order to burn the BIN. This is not as hard as it used to be, as it's now automated. Just visit the Downloads page and get a copy of Lior Chen's CueMaker program. It will read the format information from the BIN and write the CUE for you. Easy as eating pie. 

ISO

ISO = International Standards Organization #9660. That is a document defining the precise standards for a particular file-system and format which is used in the creation of most data-CDs. ISO9660-compliant discs are cross-platform, having native support in Windows, Unix, SUNOS, Linux, BSD, and MAC Operating Systems, etc. No special hardware or software is needed to read CD's that follow the ISO 9660 standard. An ISO file is similar to a BIN in mode 1, 2048 bytes per sector, no subcode or other positioning information is recorded, no ECC is used, and the standard ISO file-system is maintained.

NRG

NRG is a Nero Burning Rom image file. It's a proprietary format, unique to Nero. Use either Nero or Alcohol 120% to burn it. An NRG file isn't a standard file format, and really shouldn't be posted to UseNet. The only standard, multi-program image files are ISO and BIN. Because all image burning programs can burn ISO, and almost all can burn BIN. 

IMG

IMG/CCD is a Clone CD or Clone DVD image file. Clone CD was a product of Elaborate Bytes, a Swiss company, which has dropped support for CDs due to new copyright laws, only supporting DVD-writing software. You will occasionally run into an IMG file as a movie image, but very rarely will you find any warez posted that way any more. Alcohol 120% supports burning CCD images, which are essentially BIN files.

Other image file types:

There are as many image file types as there are programs used to burn CDs and DVDs. MDS/MDF is an Alcohol image file type, CIF is a format proprietary to Roxio's burning programs, etc. The default DiscJuggler Image file extension is .CDI. None of the proprietary file types should really be posted to UseNet, as it forces people to obtain either the specific program which creates that image file, or to get one of the multi-file-type burning programs, such as Alcohol. Of the major applications, only Roxio applications can't seem to manage to burn a BIN, and all can burn an ISO, so those are the preferred file types for images.

NTX

An NTX is a yEnc-encoded file that was most probably uploaded to UseNet with a non-yEnc program. It was created by a program like yEnc32. It shouldn't have been uploaded at all, and should be avoided, as obviously the person who uploaded it doesn't know what he/she is doing. yEnc32 is a program that you can use to yEncode a file for test purposes, for example to check final file-size to see how many bytes will be uploaded. An NTX can be decoded using yDec (Q.V.) if you must have that particular file.  It is a questionable practice to rely upon files posted by people who obviously do not know what they are doing. It rarely turns out well—just a word of advice.

NZB

An NZB is a "NewzBin" XML file (text) containing Message-ID's. NZB files are created by some news posting programs, and the web site www.newzbin.com, and can be used by some newsreaders - notably NewsBin Pro- to get binary files without having to download a few zillion bytes of headers. If you have a news-reader that can use them, they can be very handy.  Click here for the WarezFAQ's NZB Primer to learn more.