1. Home
2. Usenet Glossary
3. Binaries, Encoding & Repair

Usenet carries text, so every file has to be encoded, split into thousands of articles, and reassembled at the other end. This section defines yEnc, PAR2, RAR sets, segments, and the repair process that fixes what arrives damaged or missing. These are the terms that explain why a download succeeds or ends up incomplete.

Search the Usenet glossary Search

52 terms in this category.

Binary Post

A Usenet article carrying encoded file data rather than readable text. Since NNTP moves only text, the file is encoded, usually with yEnc, then split across many articles posted to a binary newsgroup. A single feature-length video release can occupy tens of thousands of such articles, which a newsreader collects, decodes, and joins back into the original file.

yEnc

An encoding scheme that packs binary data into Usenet articles with roughly 1-2% overhead, compared to about 35% for uuencode or Base64. Introduced in 2001, it works by escaping only the handful of byte values that would otherwise break the NNTP protocol. Nearly every binary posted to Usenet today is yEnc-encoded, and every modern newsreader decodes it automatically.

=ybegin

The header line that opens a block of yEnc-encoded data, carrying the original filename, the total file size, and the line length used. Multipart posts follow it with an =ypart line giving the byte range this article covers, and the block closes with =yend, which reports a CRC32 checksum. Newsreaders read these markers to reassemble segments in order and verify that nothing was corrupted.

uuencode

The original Unix method for carrying binary data over text-only channels, dating to the late 1970s and used on Usenet for two decades. It maps every three bytes onto four printable ASCII characters, inflating the post by roughly 35%. Sections are marked by begin and end lines. Superseded by yEnc after 2001, though old archived posts and a few text groups still contain uuencoded data.

uudecode

The reverse of uuencode: reading the printable ASCII of an encoded post and writing back the original bytes. On multi-part uuencoded posts the sections had to be concatenated in the correct order first, with headers and signatures stripped by hand, which made recovery fragile. Modern newsreaders still include a decoder for archived material, but almost nothing new arrives in this format.

Base64

An encoding that represents binary data using 64 printable characters, four output characters for every three input bytes, adding about 33% to the size. Standard inside MIME email and web protocols, and occasionally used for small Usenet attachments, but its overhead made it impractical for large binaries. yEnc replaced it on binary groups because it adds only a fraction of the same bulk.

MIME

Multipurpose Internet Mail Extensions, the standard that lets a message declare content types, character sets, and transfer encodings, and carry several parts in one body. Usenet articles inherit MIME from mail, so headers like Content-Type and Content-Transfer-Encoding appear on posts. Binary groups largely ignored it in favor of yEnc, which sits in the article body without MIME structure and costs far less overhead.

Multipart Post

A file too large for one article, encoded and spread over a numbered series of posts. yEnc marks each one with an =ypart line stating which byte range it holds, and subject lines conventionally carry a (n/m) counter. Every part must be retrieved before the file can be rebuilt, so a single missing article turns the whole set into an incomplete unless PAR2 blocks cover it.

Segment

One article's worth of a larger encoded file, typically between 300KB and 768KB of source data. Splitting keeps individual articles within server limits and lets a client fetch many pieces in parallel across several connections. NZB files list every segment by Message-ID so a download client can request them directly. Losing segments beyond what PAR2 can rebuild leaves the file unusable.

Part

Another word for segment, one numbered article in a multipart binary post. Usage varies: indexers and NZB files usually say segment, while subject lines and RAR sets say part, as in the (14/97) counter or a .part14.rar volume. Both refer to a piece that must be collected before reassembly, and the distinction matters only when reading a client's error messages closely.

Article Split

The step where an encoded file is cut into article-sized chunks before posting. Posting software picks a chunk size, commonly a few hundred kilobytes, then writes each chunk into its own article with =ybegin and =ypart markers. Smaller chunks mean more articles and more per-article overhead; larger ones risk rejection by servers that cap article size. A 50GB release can produce tens of thousands of articles.

RAR

A compressed archive format used to package Usenet releases before encoding. Its appeal on Usenet was never compression, since video is already compressed, but its ability to split output into fixed-size volumes and to carry recovery records. Files arrive as .rar plus numbered volumes and are rejoined by any archiver that understands the format, a step download clients normally perform automatically once repair has finished.

RAR Set

The complete group of RAR volumes making up one archive, named either .part01.rar through .partNN.rar or, in the older scheme, .rar followed by .r00, .r01 and upward. Every volume must be present and intact for extraction to succeed, which is why PAR2 recovery files are posted alongside. Unpackers open the first volume and pull the rest in automatically.

.r00 Files

Continuation volumes in the older RAR naming scheme, where the first volume is named .rar and the rest run .r00, .r01, .r02 and so on. The sequence caps out at .r99 before rolling into further letters, which is one reason large releases moved to .partNN.rar naming. Opening the .rar file pulls in every .rNN volume; opening an .r00 on its own fails.

ZIP

The general-purpose archive format, common for software and small file collections but rare for large Usenet releases. Standard ZIP has no multi-volume convention as reliable as RAR's, and no built-in recovery record, so posters preferred RAR for anything split across many articles. ZIP still shows up inside releases for subtitles, sample clips, and documentation bundled with the main archive.

7-Zip

An open-source archiver and its .7z format, offering stronger compression than RAR and multi-volume output as .7z.001, .7z.002 and upward. The Windows tool also unpacks RAR and ZIP, so it serves as a general extractor for downloaded material. Some posters use .7z for text-heavy or source-code releases; video releases still overwhelmingly use RAR, largely by long-standing convention.

PAR

Short for Parity Archive, a family of recovery formats that let a damaged or partly missing download be rebuilt without reposting. PAR1, the 1990s original, could only substitute whole missing files and failed if a file was present but corrupted. PAR2 replaced it and remains standard on binary groups. Loose usage of PAR on forums and in client settings almost always means PAR2.

PAR2

Parity Archive Volume Set 2, the recovery format posted alongside almost every binary release. It applies Reed-Solomon erasure coding to produce recovery blocks, commonly 5-15% of the release size, spread over files named .par2 and .volNNN+NN.par2. If missing or corrupt blocks number no more than the recovery blocks available, the set rebuilds exactly; beyond that, repair fails and the download is an incomplete.

Parity Block

The unit PAR2 works in. Source files are divided into equal-sized blocks, and recovery data is computed across them so any block can be reconstructed from the others plus enough parity. Repair is arithmetic on whole blocks, not bytes, so one bad byte costs a full block. Smaller block sizes give finer-grained repair at the cost of larger PAR2 files and slower verification.

Recovery Block

A block of Reed-Solomon parity data stored in the .volNNN+NN.par2 files, where the filename states which block it starts at and how many it contains. Each recovery block can stand in for any one missing or damaged source block, so the count available sets the exact repair ceiling. Clients download extra PAR2 volumes only when verification shows blocks are actually needed.

PAR Repair

The verify-and-rebuild pass a client runs after downloading. The small index .par2 file is read first to check every block against its hash; if damage is found, enough recovery volumes are fetched and the missing blocks are reconstructed. Download clients perform this automatically, while standalone utilities do the same job on files already on disk. Repair succeeds only when recovery blocks match or exceed missing blocks.

QuickPar

A Windows PAR2 tool from the early 2000s that became the reference implementation for verifying and repairing Usenet downloads. Its progress display, showing blocks found, blocks missing, and blocks needed, set the vocabulary still used today. Development stopped years ago and it does not handle very large modern releases well, so MultiPar is the usual replacement on Windows.

MultiPar

The actively maintained Windows successor to QuickPar, reading and writing both PAR1 and PAR2 sets. It adds multithreaded and GPU-accelerated repair, handles releases of hundreds of gigabytes, and can create recovery sets at a chosen redundancy percentage. Mostly used by people repairing downloads by hand or by posters generating PAR2 volumes, since automated clients repair internally.

par2cmdline

The cross-platform command-line PAR2 implementation, available on Linux, macOS, and BSD as well as Windows. Typical use is par2 verify or par2 repair against the index file in a download directory. Its code, and the faster par2cmdline-turbo fork, underpins repair in several download clients and post-processing scripts, which is why headless servers can repair without any graphical tool installed.

SFV

Simple File Verification, a plain text file listing each archive volume next to its CRC32 checksum. Running a check confirms whether every file arrived byte-perfect, but SFV carries no parity data, so it can only report damage, never fix it. PAR2 covers both jobs, leaving .sfv files a legacy inclusion in many releases rather than a working part of repair.

CRC32

A 32-bit checksum used throughout Usenet binaries to detect corruption. Every yEnc =yend line carries the CRC32 of the data it closes, SFV files list one per archive volume, and RAR stores one per compressed file. A mismatch proves the bytes changed in transit or on disk. Detection only: identifying damage is what triggers PAR2 repair, which does the actual reconstruction.

CRC Error

Reported when a computed checksum does not match the stored one, meaning the data is not what was posted. On Usenet the usual causes are a truncated or corrupted article, a segment fetched from a server holding a damaged copy, or disk problems during writing. A client that hits one marks the affected blocks bad and hands the set to PAR2 repair rather than aborting.

Incomplete

A file set missing more articles than the available PAR2 blocks can rebuild. Causes include articles that aged past retention and propagation gaps that left parts of the post on some servers only. Adding a second provider on a different backbone often fills the gap, since the missing articles may exist elsewhere. Otherwise the release has to be found again or reposted.

Completion

How much of a given post a server actually holds, expressed as the percentage of its articles present. High completion matters more than raw retention for old material, because a set missing even a few percent of its articles may exceed what PAR2 can repair. Providers quote a headline completion rate; real results vary by group, by age, and by release.

Fill Server

A secondary news server queried only for articles the primary one cannot supply. Because backbones propagate independently, an article missing from one network is often present on another, so a small block account on a different backbone can rescue sets that would otherwise be incomplete. Download clients handle this through server priority settings, trying the cheap primary first and falling through on 430 responses.

Repost

Posting a file again because the original set has decayed past repair or was removed. A repost gets fresh Message-IDs and a new date, so old NZB files still point at the dead articles and a new NZB must be fetched. Requests for reposts were once made in the group itself; on modern binary groups the practice is far less visible.

Obfuscation

The practice of posting so that nothing in the article headers identifies the content: randomized subject lines, meaningless filenames inside the archive, and often a password on the RAR set. Headers carry no clue as to what the post holds. The tradeoff is that such posts are useless without an NZB from an indexer that recorded what they contain.

Obfuscated Post

A binary post whose subject lines, filenames, and sometimes archive password reveal nothing about its contents. Header-based searching cannot find it, so retrieval depends entirely on an NZB listing the Message-IDs. After download the archive unpacks to files with random names, and the client or a post-processing step has to rename them from other metadata carried alongside the release.

Password-Protected Archive

A RAR or 7-Zip set locked with a password so its contents cannot be listed or extracted without it. On obfuscated posts the password is distributed separately, often through an indexer that stores it in the NZB metadata and passes it to the download client automatically. A missing or wrong password stops extraction after a complete, verified download.

Subject Obfuscation

Replacing the descriptive subject line of a binary post with a random string, so that the header index carries no clue to the content. Traditional header downloading and subject parsing both break, since there is nothing to match on. Indexers that captured the post at the time hold the mapping between the random subject and the real release name, and serve it in the NZB.

Random Filenames

Filenames inside an obfuscated post replaced with random strings, so that an archive unpacks to items like a7f3b9c2.mkv rather than a recognizable title. The extension and container may also be stripped. Recovering the real name is the deobfuscation step, handled either by the indexer supplying it as metadata or by a post-processing tool inspecting the file itself.

NFO File

A plain text file bundled with a release, traditionally carrying an ASCII-art header plus details of the source, format, runtime, and any notes. The extension stands for information. Clients sometimes read the NFO for a release name or an archive password. Best viewed in a fixed-width font with codepage 437, since the artwork uses DOS box-drawing characters.

Release

One packaged unit of posted material: the archive volumes, the PAR2 recovery files, an SFV, and usually an NFO, all posted together under a common name. The name follows a strict convention encoding title, year, quality and source. Indexers treat the release as the atomic item they list, and a client grabs the whole set from one NZB.

Dupe

The same release posted more than once, whether by accident, as a repost after decay, or renamed by a different poster. Indexers list each posting separately, so a search can return several entries for one item. Download clients and automation tools keep a history of completed release names and skip anything matching, which stops the same file downloading twice.

Split Archive

An archive written as several fixed-size volumes rather than one large file. Splitting predates Usenet but suits it well: volumes of 50MB to 500MB give the PAR2 set manageable units to check and repair, and let a partly damaged download be fixed volume by volume. Extraction needs every volume present, and unpackers pull the rest in from the first.

Archive Volume

One file of a split archive, such as movie.part07.rar or data.7z.003. Volume numbering tells the unpacker the order to read them in, and each carries its own CRC32 so damage can be localized. PAR2 verification reports results per volume, which is why a repair log names specific volumes as damaged rather than pointing at the archive as a whole.

Article Size

How much data one posted article carries, set by the poster and bounded by server limits. Common choices land between 300KB and 768KB of source data before encoding, which yEnc inflates by one or two percent. Smaller articles mean a longer article list and more protocol overhead per megabyte; larger ones can be rejected outright by servers that enforce a maximum.

File Set

Every file belonging to one posted item, taken together: the archive volumes, the PAR2 files, and any SFV or NFO. PAR2 recovery is computed across the set, so verification treats it as a single unit and repair draws blocks from wherever they are available. A set missing more blocks than recovery covers is reported as an incomplete.

Collection

A group of related posts a newsreader assembles from header data into one downloadable item, matching subject lines and part counters to work out which articles belong together. Header-based readers build collections locally; NZB-driven clients skip the step because the NZB already lists the segments. Obfuscated posts defeat collection building, since the subjects share nothing to match on.

Poster Alias

The name and address in the From header of a binary post, usually invented rather than tied to any real account. Aliases let related posts be grouped and let a poster build a recognizable identity, and some indexers allow searching or filtering by them. Nothing verifies the field, so the same alias can be used by anyone, and obfuscated posts often randomize it.

Binary Attachment

A non-text file carried inside an article, encoded so it survives a protocol that expects printable characters. On the modern binary groups this means yEnc data in the article body; in text groups where attachments are unwelcome, a small MIME or uuencoded attachment occasionally appears. Servers that carry text groups only will often strip or refuse articles above a size threshold.

Encoding Overhead

The extra bytes an encoding adds on top of the original file. uuencode and Base64 both expand data by roughly a third, so a 4GB file consumed over 5GB of transfer. yEnc cuts this to about one or two percent by escaping only problem bytes. Article headers add a little more, which is why downloaded byte counts always exceed the finished file size.

Line Length

How many encoded characters a post puts on each line, declared by the line= value on the =ybegin header and typically 128 for yEnc. The limit exists because NNTP and older news software mishandle very long lines. Decoders read the declared value rather than assuming one, and a mismatch between declared and actual length is one way a corrupted article shows itself.

Article Count

The number of articles making up a post or a whole release. NZB files state it implicitly through their segment lists, and indexers display it next to size. The figure sets how many separate NNTP fetches a download needs, so a large release running to tens of thousands of articles benefits from more concurrent connections. It also indicates how much a set can lose before repair fails.

Deobfuscation

The client-side step of restoring real filenames after an obfuscated download unpacks to random strings. Sources include the release name recorded in the NZB metadata, an NFO inside the archive, or inspection of the media file's own container data. Download clients attempt this during post-processing, and library software downstream may rename again to its own scheme.

Padding File

A junk file added to a release so the archive rounds up to a tidy volume count or a target size. Names run to things like padding.bin or a string of zeroes, and the contents carry no information. PAR2 still computes recovery over them, which wastes a little transfer. Post-processing usually deletes them, though some clients leave them in the completed folder.

PAR2 Block Size

The fixed slice length PAR2 divides source files into, chosen when the recovery set is created and recorded in the .par2 index. Small blocks allow precise repair, since a single damaged article costs less parity, but multiply the block count and slow verification on large releases. Posters commonly aim for a few thousand blocks total, balancing repair granularity against processing time.

See the full Usenet glossary.