Anatomy of a release¶
A Scene release is more than its main media file. The directory name, payload, metadata, checksums and supporting material form a category-specific package that can be distributed and verified automatically.
There is no single layout shared by every category. A WEB video, a GAMEiSO release and a WEB-FLAC album use different payloads and packaging rules.
1. Release directory name¶
The top-level directory identifies the release before any file is opened. A common video pattern is:
| Component | Purpose |
|---|---|
| Title | Identifies the movie, show, game, software, book, artist or album. |
| Year / season / version | Distinguishes a particular release, episode, edition or software build. |
| Status and edition tags | Describes states such as PROPER, REPACK, REMASTERED or EXTENDED. |
| Language | Identifies dubbed, subtitled or multilingual content when required. |
| Source and format | Describes WEB, Blu-ray, HDTV, FLAC, GAMEiSO or another category-specific format. |
| Group suffix | The final -GROUP identifies the releasing group. |
The exact order and allowed characters are defined separately by each ruleset.
2. Release payload¶
| Category | Typical payload |
|---|---|
| WEB or retail video | A single .mkv file stored inside a RAR set. |
| GAMEiSO | An .iso disc image stored inside a RAR set. |
| MP3 | Individual .mp3 tracks and category-specific support files. |
| WEB-FLAC | Individual .flac tracks, normally stored directly rather than inside a RAR set. |
| eBook | Document or archive formats permitted by the current eBook rules. |
| Software | Installers, program files, patches or cracks packaged according to the software category. |
The payload is the actual content. Packaging files such as the NFO and SFV describe or verify it, but are not the payload itself.
3. Metadata and verification files¶
| Item | Purpose |
|---|---|
.nfo |
Human-readable release documentation containing required source, technical and group information. |
.sfv |
CRC32 checksums used to verify RAR volumes or individual release files. |
.rar, .r00, .r01… |
Old-style split RAR volumes used by categories such as WEB video and GAMEiSO. |
.m3u |
Playlist and track ordering for music releases. |
.jpg / .png |
Cover art or proof images where the applicable rules permit or require them. |
.diz |
Short description file used by some publishing and legacy categories. |
An SFV can detect a damaged or missing file, but it does not repair the data. The affected file or RAR volume must normally be transferred again.
4. Supporting directories¶
Sample¶
Video rules commonly require a short excerpt in a directory named Sample. It allows the release quality to be inspected without extracting or downloading the entire feature.
A sample is not universal. Audio, publishing and software categories have their own requirements.
Proof¶
Retail material can require proof of the physical source or other source-specific evidence. Current video rules place proof images in an unarchived Proof directory. Physical music releases can also require JPG proof.
Proof requirements depend on the category and source. A web-sourced release and a retail-disc release do not necessarily need the same evidence.
Subtitles¶
Subtitle packaging is ruleset-specific. Current WEB video rules require subtitle tracks to be muxed into the video container and do not allow a separate external Subs directory. Older categories and releases may use different layouts.
5. Why split archives?¶
Split archives became central to automated Scene distribution because they:
- allow multiple volumes to be transferred and verified independently;
- limit retransmission to a missing or corrupt volume;
- provide predictable file sizes for site scripts and race distribution;
- keep the payload in a consistent package across sites.
RAR versions, volume sizes, compression settings and naming schemes remain category-specific. For example, current GAMEiSO rules allow RAR4 or RAR5, while the current WEB video rules retain older RAR3/RAR4-compatible archives.
Example: WEB video¶
Feature.Title.2025.1080p.WEB.H264-GROUP/
|-- group-feature.nfo
|-- group-feature.sfv
|-- group-feature.rar
|-- group-feature.r00
|-- group-feature.r01
|-- Sample/
| `-- group-feature-sample.mkv
`-- Proof/ (when required)
`-- group-feature-proof.jpg
The RAR set contains the main MKV payload. The NFO documents the release, while the SFV verifies the archive volumes.
Example: GAMEiSO¶
Game.Title-GROUP/
|-- grp-gametitle.nfo
|-- grp-gametitle.sfv
|-- grp-gametitle.rar
|-- grp-gametitle.r00
`-- grp-gametitle.r01
Extracting the RAR set produces the ISO payload. GAMEiSO also defines separate layouts and tags for updates, DLC, cracks, fixes and internal releases.
Example: WEB-FLAC¶
Artist-Title-16BIT-WEB-FLAC-2025-GROUP/
|-- 01-artist-title.flac
|-- 02-artist-title.flac
|-- artist-title.m3u
|-- artist-title.jpg
|-- group-release.nfo
`-- group-release.sfv
WEB-FLAC demonstrates why RAR files and video samples cannot be described as universal parts of every release.
The NFO¶
NFO files combine documentation with group presentation. ASCII or CP437 artwork may form the visual identity, but the required content is functional and category-specific. Depending on the release it can include:
- source and technical media information;
- title, version, language and release date;
- encoding, ripping or packaging details;
- installation and crack instructions;
- proof or retailer URLs;
- reasons for a proper, repack, rerip or fix;
- notes about mixed sources, subtitles or known limitations.
The applicable ruleset always takes precedence over a generic directory example. Consult the local current rules library for exact requirements, or visit the examples archive for preserved layouts.