mirror of
https://github.com/Dictionarry-Hub/database.git
synced 2025-12-10 15:57:00 +00:00
75 lines
38 KiB
JSON
75 lines
38 KiB
JSON
[
|
|
{
|
|
"_id": "EEi",
|
|
"content": "This metric is aimed at identifying and ranking release groups based on their propensity to release **encodes that meet certain compression ratios**, with particular focus on **HEVC** releases where optimal efficiency occurs in specific bitrate ranges. By ranking these groups, we effectively prioritize releases that maximize HEVC's compression capabilities while maintaining quality at minimal file sizes.\n\n## What is a Compression Ratio?\n\nA compression ratio is a (made up) metric that evaluates encodes against their sources. We express this as the **encoded file size as a percentage of its source size** (typically a **remux** or **WEB-DL**).\n\nFor example:\n\n| Movie | Source (Remux) | Encode | Compression Ratio |\n| ------- | -------------- | ------ | ----------------- |\n| Movie A | 40 GB | 10 GB | 25% |\n| Movie B | 30 GB | 6 GB | 20% |\n| Movie C | 50 GB | 15 GB | 30% |\n\n## Why Is This Important?\n\nUnderstanding compression ratios helps balance two competing needs: **maintaining high video quality while minimizing file size**. Modern codecs like **HEVC** have a **\"sweet spot\"** where they deliver excellent quality with significant size savings. Finding this optimal point is crucial because:\n\n- Storage and bandwidth are always **limited resources**\n- Going beyond certain bitrates provides **diminishing quality returns**\n- Different codecs have different **efficiency curves**\n- Release groups need clear standards for **quality vs. size trade-offs**\n\n## What Ratio is Best?\n\nThere's no one-size-fits-all answer when it comes to choosing the perfect compression ratio. The \"best\" ratio **depends entirely on your specific needs**. At 1080p:\n\n- Space-conscious users might prefer **smaller files (5-10% of source)** with quality trade-offs\n- Quality-focused users might push towards **higher quality (30-40% of source)** for transparency\n- Most users find a sweet spot in the middle\n\nHowever, there are technical limits - files larger than **40% for 1080p** and **60% for 2160p** provide no meaningful benefits.\n\n## Why Set Maximum Ratios of 40% and 60%?\n\nThe compression ratio ceilings are set based on different factors for 1080p and 2160p content:\n\n### 1080p (40% Maximum)\n\nThe 40% ceiling for 1080p exists because we can roughly measure where **HEVC stops being efficient compared to AVC**. We do this using two key video quality metrics:\n\n- **VMAF** - analyzes how humans perceive video quality and scores it from 0-100\n- **BD-Rate** - tells us how much smaller one encode is compared to another while maintaining the same quality level\n\nUsing these tools together shows us that:\n\n- HEVC achieves **20-40% smaller files** in the mid-bitrate range (~2-10 Mbps for 1080p)\n- These space savings are consistent across different quality levels\n- Beyond this point, both codecs achieve **near identical quality**\n- At ratios above 40%, **AVC becomes preferred** due to better tooling and quality control\n\n### 2160p (60% Maximum)\n\nThe 60% ceiling for 2160p content is based on different considerations:\n\n- This is approximately where **visual transparency** becomes achievable\n- Higher ratios provide **diminishing returns**\n- At this compression level, content achieves **VMAF scores above 95**\n- **Storage efficiency** becomes critical due to larger base file sizes\n- Quality improvements become **increasingly subtle** beyond this point\n\nRead these articles to better understand how VMAF and BD-Rate tell us how efficient a codec is[^1][^2]:\n\n## How Do We Apply This Index?\n\nThe ranking system works by calculating how close each Release Group / Streaming Service comes to achieving a user's desired compression ratio. This is done through a few key steps:\n\n1. **Delta Calculation**: We calculate the absolute difference (delta) between a group's average compression ratio and the target ratio. For example, if a group averages 25% compression and our target is 20%, their delta would be |25 - 20| = 5 percentage points.\n\n2. **K-means Clustering**: We use k-means clustering to automatically group release groups into tiers based on their deltas. K-means works by:\n - Starting with k random cluster centers\n - Assigning each group to its nearest center\n - Recalculating centers based on group assignments\n - Repeating until stable\n\n# Example Rankings\n\n## 1080p Examples\n\n### Example 1: Users prioritizing storage efficiency (10% target)\n\nUsers might choose this very aggressive compression target when:\n\n- Managing large libraries on limited storage\n- Collecting complete series where total size is a major concern\n- Primarily viewing on mobile devices or smaller screens\n- Dealing with bandwidth caps or slow internet connections\n\n| Tier | Group | Efficiency | Delta |\n| ---- | ----------------------- | ---------- | ----- |\n| 1 | iVy | 9.37% | 0.63 |\n| 1 | PSA | 7.89% | 2.11 |\n| 2 | Vyndros | 16.08% | 6.08 |\n| 2 | Chivaman | 16.80% | 6.80 |\n| 2 | Amazon Prime (H.265) | 16.15% | 6.15 |\n| 3 | Disney+ (H.265) | 20.32% | 10.32 |\n| 3 | TAoE | 22.78% | 12.78 |\n| 3 | QxR | 23.25% | 13.25 |\n| 3 | BRiAN | 25.16% | 15.16 |\n| 3 | Movies Anywhere (H.265) | 26.05% | 16.05 |\n| 4 | MainFrame | 37.63% | 27.63 |\n| 4 | NAN0 | 37.71% | 27.71 |\n\n### Example 2: Users seeking balanced quality and size (25% target)\n\nThis moderate compression target appeals to users who:\n\n- Have reasonable storage capacity but still want efficiency\n- Watch on mid to large screens where quality becomes more noticeable\n- Want a good balance between visual quality and practical file sizes\n\n| Tier | Group | Efficiency | Delta |\n| ---- | ----------------------- | ---------- | ----- |\n| 1 | BRiAN | 25.16% | 0.16 |\n| 1 | Movies Anywhere (H.265) | 26.05% | 1.05 |\n| 1 | QxR | 23.25% | 1.75 |\n| 1 | TAoE | 22.78% | 2.22 |\n| 2 | Disney+ (H.265) | 20.32% | 4.68 |\n| 3 | Amazon Prime (H.265) | 16.15% | 8.85 |\n| 3 | Chivaman | 16.80% | 8.20 |\n| 3 | Vyndros | 16.08% | 8.92 |\n| 3 | MainFrame | 37.63% | 12.63 |\n| 3 | NAN0 | 37.71% | 12.71 |\n| 4 | iVy | 9.37% | 15.63 |\n| 4 | PSA | 7.89% | 17.11 |\n\n## 2160p Examples\n\n### Example 3: Extreme Space Saving (20% target)\n\nThis aggressive 2160p compression appeals to users who:\n\n- Want to maintain a 4K library on limited storage\n- Primarily view content at typical viewing distances where subtle quality differences are less noticeable\n- Need to conserve bandwidth while still enjoying 4K resolution\n- Have a large collection of 4K content and need to balance quality with practical storage constraints\n\nTODO: EXAMPLES\n\n### Example 4: Balanced 4K (40% target)\n\nThis middle-ground approach is ideal for users who:\n\n- Have decent storage capacity but still want reasonable efficiency\n- Watch on larger screens where quality differences become more apparent\n- Want to maintain high quality while still keeping files manageable\n- Need reliable HDR performance without excessive file sizes\n\nTODO: EXAMPLES\n\n### Example 5: Near Transparent Quality (60% target)\n\nThis higher bitrate target is chosen by users who:\n\n- Have ample storage and prioritize maximum quality consciously\n- Watch on high-end displays where subtle quality differences are noticeable\n- Want to maintain archive-quality collections\n- Focus on difficult-to-encode content where compression artifacts are more visible\n\nTODO: EXAMPLES\n\nThese examples demonstrate how different groups excel at different target ratios, and how streaming services tend to maintain consistent compression approaches regardless of user preferences. The rankings help users quickly identify which releases will best match their specific quality and size requirements.\n\n## Frequently Asked Questions\n\n| Question | Answer |\n| -------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Why not just detect h265/x265 releases? Isn't that simpler? | This is a common misconception that \"HEVC = smaller = better\". While it's true that HEVC/x265 _can_ achieve better compression than AVC/x264, simply detecting the codec tells us nothing about the actual efficiency of the specific encode. A poorly encoded HEVC release can be larger and lower quality than a well-tuned x264 encode. By focusing on compression ratio instead of codec detection, we measure what actually matters - how efficiently the release uses storage space while maintaining quality. This approach has several advantages:<br><br>- It rewards efficient encodes regardless of codec choice<br>- It catches inefficient HEVC encodes that waste space<br>- It avoids the complexity of parsing inconsistent HEVC labeling (h265/x265)<br>- It future-proofs the system for newer codecs like AV1, where we can simply adjust our codec ranking priorities (AV1 > HEVC > AVC) while still maintaining the core efficiency metric<br><br>Think of it this way: users don't actually care what codec is used - they care about getting high quality video at reasonable file sizes. Our metric measures this directly instead of using codec choice as an unreliable proxy. |\n| But doesn't this ignore quality? | The current encoding landscape places tremendous emphasis on maximizing absolute quality, often treating file size as a secondary concern. This metric aims to challenge that, or at least find a middle ground - we care about quality (hence why we use proper sources as our baseline and consider VMAF scores), but we acknowledge that most users only care about getting file sizes they actually want, and not the marginal quality improvements you get from encoding from a remux, compared to a web-dl. Rather than taking either extreme position - \"quality above all\" or \"smaller is always better\" - we focus on _efficiency_: getting the best practical quality for any given file size target. This approach **will not** satisfy quality enthusiasts, but it better serves the needs of most users. |\n| What if the source is not a 1080p remux? How do you tell? | This metric, like any data-driven system, will never achieve 100% accuracy. However, we can parse various indicators beyond just the release group or streaming service to identify non-remux sources. For example, we can identify when a non-DS4K WEB-DL or non-webrip from a reputable group is likely sourced from another lossy encode rather than a remux. We also maintain a manual tagging system to downrank certain release groups known for reencoding from non-high-quality sources. Groups like PSA and MeGusta will be ranked lower in the system, regardless of their efficiency scores, due to their known practices. |\n| How do you prefer HEVC? | We actually approach this from the opposite direction - instead of preferring HEVC, we downrank AVC. This is because HEVC naming conventions are inconsistent (groups use x265 and h265 interchangeably), making them difficult to parse reliably. In contrast, AVC is almost always labeled consistently as either x264 or h264, making it much easier to identify and downrank these releases. |\n| Why not consider releases above 40% efficiency? | For standard 1080p non-HDR content, above 40% compression ratio, x264 and x265 perform nearly identically in terms of VMAF scores, eliminating HEVC's key advantages. At this point, x264 becomes the preferred choice across all metrics - the encodes are easier to produce, far more common, and typically undergo more rigorous quality control. There's simply no compelling reason to use HEVC at these higher bitrates for standard 1080p content. |\n| What about animated content? | Animated content typically has different compression characteristics than live action - it often achieves excellent quality at much lower bitrates due to its unique properties (flat colors, sharp edges, less grain). Ideally, we would use higher target ratios for live action and lower ones for animation. However, reliably detecting animated content programmatically is extremely challenging. While we can sometimes identify anime by certain keywords or release group patterns, western animation, partial animation, and CGI-heavy content create too many edge cases for reliable detection. For now, we treat all content with the same metric, acknowledging this as a known limitation of the system. Users seeking optimal results for animated content may want to target lower compression ratios than they would for live action material, perhaps via a duplicate profile at a different compression target. |\n| Why does transparency require 60% at 2160p compared to 40% at 1080p? | The higher ratio requirement for 2160p content stems from several technical factors that compound to demand more data for achieving transparency:<br><br>1. **Increased Color Depth**: Most 2160p content uses 10-bit color depth compared to 8-bit for standard 1080p content. This 25% increase in bit depth requires more data to maintain precision in color gradients and prevent banding.<br><br>2. **HDR Requirements**: 2160p content often includes HDR metadata, which demands more precise encoding of brightness levels and color information. The expanded dynamic range means we need to preserve more subtle variations in both very bright and very dark scenes.<br><br>3. **Resolution Scaling**: While 2160p has 4x the pixels of 1080p, compression efficiency doesn't scale linearly. Higher resolution reveals more subtle details and film grain, which require more data to preserve accurately.<br><br>These factors combine multiplicatively rather than additively, which is why we need a 50% increase in the compression ratio ceiling (from 40% to 60%) to achieve similar perceptual transparency. |\n| Do all 2160p releases need 60% for transparency? | No, the actual requirements vary significantly based on several factors:<br><br>1. **Content Type**:<br>- Animation might achieve transparency at 30-40%<br>- Digital source material (like CGI-heavy films) often requires less<br>- Film-based content with heavy grain needs the full 60%<br><br>2. **HDR Implementation**:<br>- SDR 2160p content can often achieve transparency at lower ratios<br>- Dolby Vision adds additional overhead compared to HDR10<br>- Some HDR grades are more demanding than others<br><br>3. **Source Quality**:<br>- Digital intermediate resolution (2K vs 4K)<br>- Film scan quality and grain structure<br>- Original master's bit depth and color space<br><br>4. **Scene Complexity**:<br>- High motion scenes need more data<br>- Complex textures and patterns require higher bitrates<br>- Dark scenes with subtle gradients are particularly demanding |\n\n[^1]: Shen, Y. (2020). \"Bjontegaard Delta Rate Metric\". Medium Innovation Labs Blog. https://medium.com/innovation-labs-blog/bjontegaard-delta-rate-metric-c8c82c1bc42c\n[^2]: Ling, N.; Antier, M.; Liu, Y.; Yang, X.; Li, Z. (2024). \"Video Quality Assessment: From FR to NR\". Electronics, 13(5), 953. https://www.mdpi.com/2079-9292/13/5/953",
|
|
"last_modified": "2025-02-11T02:08:16.288046+00:00",
|
|
"title": "Encode Efficiency Index",
|
|
"slug": "EEi",
|
|
"author": "santiagosayshey",
|
|
"created": "2024-12-28",
|
|
"tags": [
|
|
"wiki",
|
|
"efficiency",
|
|
"encode"
|
|
],
|
|
"blurb": "A data-driven metric that measures how well release groups balance file size and quality in their encodes, helping users find releases that match their storage and quality preferences."
|
|
},
|
|
{
|
|
"_id": "FAQ",
|
|
"content": "This entry is dedicated to providing answers to the most frequently asked questions about Dictionarry / Profilarr.\n\n| Question | Answer |\n| ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Why isn't the highest scored release being grabbed? | You may have prefer propers and repacks on. This option forces releases with a proper / repack flag to be grabbed, even if it's Custom Format score is not the highest. To turn it off, navigate to Settings > Media Management > File Management and set Prefer Propers / Repacks to Do Not Prefer. |\n| What's the difference between h264, x264, AVC, h265, x265 and HEVC? | **H.264 (AVC)**: A video compression standard.<br>**x264**: An open source encoder that produces H.264 videos.<br>**H.265 (HEVC)**: A more advanced video compression standard than H.264, offering better compression and quality for 4K and higher resolutions.<br>**x265**: An open source encoder that produces H.265 videos.<br><br>**Key Points**:<br>- HEVC/AVC refers to the codec in general<br>- H.264/5 refers to a lossless rip (WEB-DL or remux)<br>- x264/5 refers to encoded content (WEBRip or Blu-ray encode)<br><br>_Note: Many HEVC files are mislabeled, making it challenging to distinguish between lossless and lossy releases based on release names alone._ |\n| What quality settings should I use? | It's suggested that you should set everything to min / max since Profilarr uses custom formats to do the major selections. However you might run into the occasional sample download if you use lots of usenet indexers. If you do find that these are being grabbed, then you can set the minimum to be 1-2gb per hour for whatever quality you need it in. |\n| What does \"Transparency\" mean? | Audiovisual transparency refers to the degree to which an encoded audio or video signal is indistinguishable from the original source signal. The term \"transparency\" stems from the idea that the encoding and decoding processes are imperceptible, as if the system were _transparent_.<br><br>- An audio codec with high transparency will produce an encoded signal that, when decoded, is identical to the original audio source, without any discernible differences in frequency response, dynamic range, or noise floor.<br><br>- A video codec exhibiting transparency will generate an encoded signal that, upon decoding, results in a picture that is visually indistinguishable from the source video in terms of resolution, color space, and pixel-level detail.<br><br>Objective metrics, such as [VMAF (Video Multi-Method Assessment Fusion)](https://en.wikipedia.org/wiki/Video_Multimethod_Assessment_Fusion), are sometimes used to measure transparency by comparing the encoded signal to the original source and calculating a numerical score that quantifies the perceptual similarity between the two, with higher scores indicating greater transparency. |",
|
|
"last_modified": "2025-02-11T02:08:16.288046+00:00",
|
|
"title": "FAQ",
|
|
"slug": "faq",
|
|
"author": "santiagosayshey",
|
|
"created": "2025-02-02",
|
|
"tags": [
|
|
"wiki",
|
|
"faq"
|
|
],
|
|
"blurb": "Frequently asked questions pertaining to Dictionarry / Profillar and all of its tooling."
|
|
},
|
|
{
|
|
"_id": "GPPi",
|
|
"content": "## What are Golden Popcorns?\n\n**_Golden Popcorns_** are _very high quality encodes_, marked as such by one of the best private torrent trackers. These releases are manually reviewed by a dedicated, experienced team of _Golden Popcorn_ checkers. Golden Popcorns are the simplest way to quantify a subjective _best_ encode.\n\n## The Decision Engine\n\nThe Golden Popcorn Performance Index, or GPPI, is a calculated metric, pivotal to the [Transparent](../Profiles/1080p%20Transparent.md) profile's decision-making process. It's engineered to rank release groups based on their propensity to release a Golden Popcorn encode at any given resolution $r$.\n\n## Formula\n\nOn first glance, it seems the most obvious way to determine which release groups are most likely to release golden popcorns is to find their Golden Popcorn Ratio, i.e. The number of Golden Popcorns divided by the total number of encodes for any given resolution _r_.\n\nHowever, If we were to take Golden Popcorn ratio at face value, we might incorrectly prioritise a release group who has a high GP ratio, but a low number of encodes. On the opposite spectrum, if we take the raw number of Golden Popcorns for any group, we might incorrectly prioritise a group with a low GP ratio.\n\nSo instead, we multiply the number of Golden Popcorns at resolution $r$ for a given release group, by a factor of said release group's Golden Popcorn Ratio. This essentially limits both metrics as a factor of each other.\n\nFor any given resolution _r_, the GPPI is defined as:\n\n$$\n\\begin{aligned}\n\\text{GPPI}_r &= GPE_r \\cdot \\left( \\frac{GPE_r}{E_r} \\right) \\\\\n &= \\frac{GPE_r^2}{E_r}\n\\end{aligned}\n$$\n\nWhere:\n\n- $\\text{GPPI}_r$ is the Golden Popcorn Performance Index at resolution $r$\n- $GPE_r$ is the number of Golden Popcorns at resolution $r$\n- $E_r$ is the total number of encodes at resolution $r$",
|
|
"last_modified": "2025-02-11T02:08:16.288046+00:00",
|
|
"title": "Golden Popcorn Performance Index",
|
|
"slug": "GPPi",
|
|
"author": "santiagosayshey",
|
|
"created": "2023-04-20",
|
|
"tags": [
|
|
"wiki",
|
|
"quality",
|
|
"encode"
|
|
],
|
|
"blurb": "A data-driven metric that identifies high-quality release groups by analyzing their Golden Popcorn track record."
|
|
},
|
|
{
|
|
"_id": "RGP",
|
|
"content": "## So, how does Dictionarry _actually simplify media automation?_\n\nWell, first we need to understand that we're trying to **automate the subjective analysis of how \"good\" a release is**. To do that, we need to first define **what \"good\" even means**. To some people, it could mean how well something looks on their screen, or sounds through speakers; we define this as _quality_. To others, it means how many releases they can download while still maintaining some kind of quality standard; we define this as _efficiency_.\n\nSo, that leads us to a new question - _how do we measure quality and efficiency_? You might think we'd want to parse releases and find their technical properties; resolution, bitrate, video / audio codecs, hdr, etc.\n\n```\nRelease 1 (25.2 GiB): Blockbuster Movie A 2022 Hybrid 1080p WEBRip DDPA5.1 x264-group A\n\nRelease 2 (27.3 GiB): Blockbuster Movie A.1080p.WEBRip.DD+7.1.x264-group B\n```\n\nLooking at these two releases, you'll notice that they both have the EXACT same technical specification and would rank equally. But they're different sizes... so which is better? Using audio / video properties to measure quality / efficiency can be effective, but is largely **limited by the information that they convey**. You can't adequately answer which is better just by looking at these releases in isolation. So how do we not look at these releases in isolation? Or rather, how do we _extrapolate information that isn't already there?_\n\n### Group Tags\n\nOur answer lies in the little bit of information at the end of every release - it's **group tag**. Dictionarry tracks historic release group data in order to **rank groups based on their propensity to reach quantifiable levels of quality and efficiency**. We do this using two metrics:\n\n1. Golden Popcorn Performance Index (GPPi): How many golden popcorns a release group has, as a ratio of their total number of releases\n2. Encode Efficiency Index (EEi): The average size of a release group's encode compared to it's likely source.\n\nThese metrics are **evidence based, data driven and objective**.\n\n### TL;DR\n\nTL;DR: Dictionarry **simplifies media automation by prioritizing release groups that achieve quantifiable levels of quality and efficiency through objective measurement**. These release group rankings are built and maintained as custom formats to be scored in their respective quality profiles. You can review these group rankings below.",
|
|
"last_modified": "2025-02-11T02:08:16.288046+00:00",
|
|
"title": "Release Group Philosophy",
|
|
"slug": "RGP",
|
|
"author": "santiagosayshey",
|
|
"created": "2025-01-26",
|
|
"tags": [
|
|
"home",
|
|
"wiki",
|
|
"release_group",
|
|
"philosophy"
|
|
],
|
|
"blurb": "Explore Dictionarry's release group abstraction philosophy and what it actually means to simplify media automation."
|
|
},
|
|
{
|
|
"_id": "home",
|
|
"content": "# \ud83d\udc4b Hey!\n\nWelcome to Dictionarry! This project aims to wiki-fy and **simplify media automation** in Radarr / Sonarr through extensive, data driven documentation, custom formats and quality profiles.\n\n---\n\n## \ud83d\udca1 Motivation\n\nNavigating the world of media automation and coming across quality terms like \"Remux\", or \"HEVC\" or \"Dolby Vision\" can be quite daunting when all you want to do is setup a media server to watch some content. It often **feels like you need a masters in audio / video just to grab the latest blockbuster.** Dictionarry aims not to explain these concepts in detail, but **abstract them into more approachable ideas** that don't require extensive knowledge or experience.\n\nDictionarry leverages two key features of Radarr and Sonarr to simplify media automation:\n\n1. Custom Formats - Think of these as smart filters that scan release titles for specific patterns. They help **identify important characteristics** of your media, such as:\n\n - Video quality (4K, HDR, Dolby Vision)\n - Audio formats (Atmos, DTS, TrueHD)\n - Source types (Remux, Web-DL, Blu-ray)\n - Potential issues (upscaled content, poor encodes)\n\n2. Quality Profiles - These act like a scoring system that **ranks releases** based on their Custom Format matches. You can:\n - Prioritize what matters most to you\n - Automatically upgrade to better versions\n - Avoid problematic releases\n\nThink of Dictionarry as your personal car-buying expert: Instead of researching every technical specification and test-driving dozens of vehicles, you get access to a curated showroom of pre-vetted options that match what you're looking for. Whether you want:\n\n- 2160p Remux - **Maximum Quality** 4K HDR remuxes with lossless audio and Dolby Vision\n- 2160p Quality - **Transparent 4K** HDR encodes selected using the Encode Efficiency Index\n- 1080p Quality - **Transparent 1080p** encodes optimized using the Golden Popcorn Performance Index\n- 1080p Efficient - **Efficient x265 1080p** Encodes optimized to save space using the Encode Efficiency Index\n\n\n\nDictionarry's database of tested profiles and formats handles the technical decisions for you.\n\n---\n\n## \u2699\ufe0f Profilarr\n\nThe database by itself does nothing. Custom Formats and Quality Profiles **need to be imported** and configured in your individual arr installations. Rather than leaving you to manually create everything yourself based on our guides, we've created **Profilarr** to automate this process.\n\nProfilarr is a **configuration management tool** for Radarr and Sonarr that can interface with **ANY remote configuration database** (not just Dictionarry's!). It automatically:\n\n- **Pulls** new updates from your chosen database\n- **Compiles** the database format into specific arr formats\n- **Imports** them to your arr installations\n- Manages version control of your configurations\n\nBuilt on top of git, Profilarr treats your configurations like code, allowing you to:\n\n- Track changes over time\n- Maintain your own customizations while still receiving database updates\n- Resolve conflicts between local / remote changes when they arise\n\nThe architecture was specifically built like this to **put user choice first**. We believe that:\n\n- **Your media setup should reflect your needs, not our opinions**\n- Updates should enhance your configuration, not override it\n- Different users have different requirements (storage constraints, hardware capabilities, quality preferences)\n- The ability to customize should never be sacrificed for convenience\n\nProfilarr empowers you to use Dictionarry's database (or anyone elses!) as a foundation while maintaining the freedom to adapt it to your specific needs.\n\n## \ud83d\udd28 Development Notice\n\nCustom Formats / Quality profiles on this site reflect the contents of the [Dictionarry Database](https://github.com/Dictionarry-Hub/database) and what the upcoming Profilarr GUI will clone / import. The old profilarr scripts still use outdated profiles / custom formats! We're currently in a bit of an inbetween state at the moment, so please bare with us as we get the new Profilarr version out!",
|
|
"last_modified": "2025-02-11T02:08:16.289047+00:00",
|
|
"title": "home",
|
|
"slug": "home",
|
|
"author": "santiagosayshey",
|
|
"created": "2025-01-21",
|
|
"tags": [
|
|
"home",
|
|
"wiki"
|
|
]
|
|
}
|
|
] |