title: Fast Computation of SSIMULACRA2 on GPUs: A Performance Evaluation

description: Turbo-metrics offers GPU acceleration for popular video quality metrics. Let's put it to the test!

title: Original Codec Wiki article

text: Introduction

text: Basics

anchor: basics

text: In-depth: SSIMULACRA2 computation

text: SSIMULACRA2 subsampling

text: TurboMetrics

anchor: turbometrics

text: Performance evaluation

anchor: performance-evaluation

text: Setup

anchor: setup

text: Results and discussion

anchor: results-and-discussion

text: Conclusions

anchor: conclusions

text: Short discussion on scoring error

anchor: short-discussion-on-scoring-error

text: Overall conclusions and final thoughts

anchor: overall-conclusions-and-final-thoughts

text: Future

text: Special thanks

anchor: special-thanks

markdown:
# Introduction

In this blog entry, we will evaluate the performance of [TurboMetrics](https://github.com/Gui-Yom/turbo-metrics), a software which provides a GPU-accelerated implementation of SSIMULACRA2, and promises to save a lot of time in its computation.

Video encoding is a time-consuming task by itself. When it comes to assessing the resulting encodes, objective quality metrics are often used, providing advantages over subjective measurements, e.g., faster evaluation processes. Nevertheless, the computation of some of these metrics is still somewhat slow. This is the case for [SSIMULACRA2](/reference/metrics/ssimulacra2/), one of the most popular objective metrics for image and video assessment.

## Basics

Before we start with the evaluation, we will first cover some fundamental (and not-so-fundamental) concepts.

### SSIMULACRA2

SSIMULACRA2, which is sometimes abbreviated as "ssimu2", is a perceptual metric for images, based on the concept of the multi-scale structural similarity index measure ([MS-SSIM](https://en.wikipedia.org/wiki/Structural_similarity_index_measure)). In the words of its developer, it is "[based on MS-SSIM], computed in a perceptually relevant color space, adding two other (asymmetric) error maps, and aggregating using two different norms". A total of 54 error maps are computed over multiple downscalings (from 1:1 to 1:32) of the image to assess (_distorted_) and its source image (_reference_). These error maps are then added using a weighted sum to produce the final SSIMULACRA2 score. The weight of each error map is tuned based on a large set of subjective scores from different image benchmarks.

SSIMULACRA2 scores are in the range [-inf, 100]. They are reported to correlate to subjective visual quality scores as follows:
* 30 = low quality
* 50 = medium quality
* 70 = high quality
* 90 = very high quality; likely impossible to distinguish from the original when viewed at 1:1 from a normal viewing distance

One special consideration when using SSIMULACRA2 to assess video quality is that, even though the developers state that a score of 90 corresponds to a "visually lossless" image, for videos, this threshold is considered to be lower, around 80. This is because it is harder to notice artifacts on individual frames, given the short period of time the viewer perceives them (usually, between 1/24 and 1/60 of a second, 0.04167 and 0.0167 seconds, respectively).

The reference implementation for SSIMULACRA2 can be found [here](https://github.com/cloudinary/ssimulacra2). Other popular implementations include [the Rust implementation](https://docs.rs/crate/ssimulacra2_rs/latest), and [the Zig implementation](https://github.com/dnjulek/vapoursynth-zip).

Although technically speaking SSIMULACRA2 is an image-focused metric, it has gained popularity as a video assessment metric due to its reliability in correlating to subjective measurements. It is considered to provide better results than other historically more popular metrics, such as [PSNR](https://en.wikipedia.org/wiki/Peak_signal-to-noise_ratio), [(MS-)SSIM](https://en.wikipedia.org/wiki/Structural_similarity_index_measure), and even [VMAF](https://github.com/Netflix/vmaf). In that context, each video frame is treated as a separate image. SSIMULACRA2 scores are computed for each of the video's frames independently, and the average is taken as the video's score. Other useful statistics include the standard deviation (which correlates to the consistency of the quality of the video), the median, the 5th percentile, and the 95th percentile. Although SSIMULACRA2 is considered to be quite reliable for video assessment, it is worth noting that, being a purely image-based metric, it disregards any temporal information present in videos, which might be seen as a disadvantage. Other metrics, such as [XPSNR](https://github.com/fraunhoferhhi/xpsnr), were developed with video assessment as their main objective, and do consider temporal information.

As stated previously, SSIMULACRA2 computes 54 error maps per image assessed. This entails a high amount of computation, especially for videos, which usually contain tens of thousands of frames (images). That explains its rather slow execution time. Speeding up these computations would be very much desired, if possible.

---
#### In-depth: SSIMULACRA2 computation

The summary of the algorithm for SSIMULACRA2 is the following, as [reported here](https://github.com/Gui-Yom/turbo-metrics/blob/master/crates/ssimulacra2-cuda/README.md#computing-ssimulacra2):
1. Get the frame pair (reference and distorted).
2. Convert the frames to linear RGB (using 32-bit floating-point).
3. For each scale (1:1 to 1:32, downsampling by 2 every step: 6 different scales):
    1. Downscale by the scale number (if needed).
    2. Convert the frames to XYB color space.
    3. Blur the following pictures, using a recursive Gaussian blur: (reference * reference), (distorted * distorted), (reference * distorted), (reference), (distorted).
    4. Compute 1-SSIM, artifact and detail\_loss error scores from the 5 blurred images and the original frame pair; this yields 3 error maps.
    5. The error maps are reduced to a single number using the 1-norm and 4-norm.
4. From this, we get 6 scores for each scale (6) and color component (3), totaling 108 scores.
5. The scores are added using a weighted sum.
6. The final value is processed through a non-linear function and clipped to render a score between 100 and -infinite.

#### SSIMULACRA2 subsampling

Given that the metric is quite slow to compute, it is often computed over a subset (subsample) of the video frames, instead of over all of them. For example, a _stride_ of 3 could be used, to compute SSIMULACRA2 scores for 1 frame out of every 3 in the video, skipping the computation for the other 2 frames. This is expected to speedup the computation by a factor of ×3.

However, this evidently induces an _error_ in the score, as the average of the scores of a subsample of the video frames is not guaranteed to be equal to the average of the scores of all the frames. The smaller the subsample (i.e., the higher the computation stride), the higher this error will be. Nevertheless, it has been reported that small strides usually produce averages significantly close to the real average of all the frames. Thus, it is pretty safe to do this. To minimize the error of this sampling method, it has been stated that "as long as you don't sample in a power of two ([i.e., every] 2, 4, 8... [frames]), you'll be fine, as you want to pick frames from every temporal layer [of the video]". Other sources further recommend picking strides that are prime numbers (e.g., 1 every 3, 5, 7, 11... frames), since "prime numbers reduce the likelihood of sampling bias due to constant frame rate".

### TurboMetrics

[TurboMetrics](https://github.com/Gui-Yom/turbo-metrics) is a WIP software suite developed by the very talented [Gui-Yom/LimelioN](https://github.com/Gui-Yom). It is "a collection of video related libraries and tools oriented at performance and hardware acceleration". It comes as a collection of Rust libraries/crates, and some include command-line applications to interact with them. There are currently no public releases of the suite in the dedicated "Releases" page of its GitHub repository, but you can download the code and compile it yourself. The latest tagged version of the software, at the moment of writing, is v0.2.2.

TurboMetrics focuses mainly on **NVIDIA GPUs** using CUDA. However, the developer is actively working on adding support for other hardware (e.g., AMD and Intel GPUs). Nevertheless, I only have experience with NVIDIA GPUs, so I cannot tell how the progress is going on that front.

Among the tools, there is a working SSIMULACRA2 implementation that uses CUDA to leverage GPU acceleration, ssimulacra2-cuda. We will focus exclusively on it from now on. We will use this tool to compute SSIMULACRA2 scores for certain video samples. However, it is worth noting that the tool is also able to compute other metrics, such as SSIM and PSNR. It can even compute multiple metrics on the same rum.

ssimulacra2-cuda is [stated to be](https://github.com/Gui-Yom/turbo-metrics/tree/master/crates/ssimulacra2-cuda) "close to the original implementation, and with close results". Also, the developer has said that "[r]ight now, [it] can compute SSIMULACRA2 orders of magnitude faster than the ssimulacra2\_rs implementation". Therefore, we can expect the tool to compute SSIMULACRA2 scores for videos much faster than any CPU implementation out there, but provide scores that are not quite the same as the ones those CPU implementations would give, including the reference one. In this blog entry, we will test that second claim, concerning the speed of TurboMetrics in computing SSIMULACRA2.

---
#### In-depth: Implementation differences from the reference

As [reported here](https://github.com/Gui-Yom/turbo-metrics/blob/master/crates/ssimulacra2-cuda/README.md#differences-from-the-reference-implementation), the GPU implementation of SSIMULACRA2 provided in TurboMetrics differs from the reference implementation in the following ways that can affect the accuracy of the reported scores:
* The conversion from YUV to linear RGB might not be yielding the same results as other tools.
* Explicit Fused Multiply-Add (FMA) operations are used when possible, as the GPU can leverage them for higher performance.
* The order of operations might not be the same, as some calculations have been rearranged.
* Floating-point operations might not yield the same results, especially with the approximated math functions used in the GPU (like `powf`).

Additionally, the differences in scores are amplified by the following features of the SSIMULACRA2 computation:
* The original weights were computed by fitting the error scores to Mean Opinion Score (MOS), and deviation in the error scores is amplified by them.
* The final non-linear function is rather steep (it is a cubic function, x³), and, thus, score variations are amplified again.

## Performance evaluation

### Setup

In this experiment, we will evaluate TurboMetrics in terms of performance; that is, the amount of ssimu2 scores computed per unit of time. For that, an episode of an animated series (~25 minutes), encoded with H.264, has been chosen as sample video. However, the kind of video content used, and most of its technical characteristics (e.g., codec, encoding parameters, etc.) except for resolution, should be irrelevant, as the same computations are performed for every video of specific frame dimensions. In this case, the video has a resolution of 1080p (1920×1080 pixels per frame), with 8 bits per pixel, and YUV color space with 4:2:0 chroma subsampling.

The video source and example distorted encode have been compared using **ssimulacra2\_rs**, **vszip**, and **TurboMetrics**. ssimulacra2\_rs and vszip are both CPU implementations of SSIMULACRA2, the former written in Rust and the latter in Zig (but invoked from VapourSynth/Python scripts). It has been reported that the Zig implementation is considerably faster than the Rust one, and we can check that out as well!

The CPU implementations have been executed on an Intel i5-11400 CPU (base frequency of 2.60 GHz, turbo frequency of 4.40 GHz), using 6 CPU cores (`-f 6` parameter in ssimulacra2\_rs, `-t 6` parameter in ssimulacravszip.py). TurboMetrics has been executed both on an NVIDIA GTX 1060 GPU and an NVIDIA RTX 4060 GPU. The three programs have been executed for the same video pair with **varying frame strides: 1, 3, 5, 7, 11, 13, 17, 19, and 23** (not skipping frames, plus every prime number lower than 24 frames / 1 second, excluding 2).

For the CPU and RTX 4060 executions, the distorted video was a custom AV1 encode of the reference video. For the GTX 1060, as it does not have AV1 decoding hardware support, the H.264 reference video was compared to itself (the computations being performed should be equivalent anyway).

### Results and discussion

The exact results of this experiment are shown in the following table:

| Stride | ssimulacra2\_rs FPS | vszip FPS | GTX 1060 GPU FPS | RTX 4060 GPU FPS |
|:-:|:-:|:-:|:-:|:-:|
| 1 | 3.37 | 14.63 | 46.70 | 85.64 |
| 3 | 9.55 | 37.67 | 133.86 | 245.73 |
| 5 | 15.15 | 49.34 | 164.34 | 350.01 |
| 7 | 20.45 | 56.37 | 197.17 | 400.94 |
| 11 | 30.23 | 64.46 | 222.98 | 458.61 |
| 13 | 34.54 | 66.65 | 239.17 | 488.83 |
| 17 | 40.51 | 69.23 | 249.58 | 520.30 |
| 19 | 42.82 | 69.99 | 258.71 | 525.44 |
| 23 | 45.43 | 88.60 | 264.85 | 546.14 |

Here they are in graph form, for better visualization:

![CPU vs GPUs decoded FPS](/img/blog_turbo-metrics_11-2024/ssimu2_cpu-gpu_dec.svg)

On a superficial level, we can already make some observations:
* SSIMULACRA2 computation with ssimulacra2\_rs is quite slow: 3.37 frames per second (without skipping frames) when using 6 threads. That is like 0.56 frames per second per thread. I know the CPU used is no beast by any measure, but beast CPUs are quite expensive and not that common (that is something to keep in mind). Those processing speeds are comparable to some of the slower-ish presets of SVT-AV1.
  - vszip is, in fact, considerably faster: Between ×4.34 (full video computation) and ×1.63 (stride of 19) with the same amount of threads. However, it seems that vszip does not scale as well as the other implementations (except for that weird performance boost with a stride of 23).
* GPU computation of SSIMULACRA2 scores is impressive, considering the CPU performances:
  - Compared to ssimulacra2\_rs: Speedups for the GTX 1060 (an 8-year-old GPU) are between ×14.01 (stride of 3) and ×5.83 (stride of 23). Speedups for the RTX 4060 are between ×25.73 (stride of 3) and ×12.02 (stride of 23).
  - Compared to vszip: Speedups for the GTX 1060 are between ×3.70 (stride of 19) and ×2.99 (stride of 23). Speedups for the RTX 4060 are between ×7.51 (stride of 17) and ×5.85 (stride of 1 / full video computation).
  - It is amazing seeing how GPUs not only achieve real-time SSIMULACRA2 computation of entire videos, but more than ×1.94 and ×3.56 real-time processing, even (GTX and RTX, respectively).

Nevertheless, the most interesting observation is made when we use computation strides bigger than 1: The performance does _not_ scale linearly with the stride, as it would be expected. This happens with both the CPU and GPUs, although it is more noticeable in the case of the GPUs due to their higher performance.

Why is that? Well, there is actually a good explanation: The reported FPS are _decoded_ FPS. That is, the speed in which the software is decoding and processing all the video frames. All the frames in the video bitstream are decoded and reconstructed as images, but the SSIMULACRA2 score is only computed for some of them. SSIMULACRA2 computation affects decoding speed in that the decoding of each frame only starts after the processing of the previous has finished (kind of, this is not be entirely true for multithreaded CPU implementations, but we can ignore that). The faster the SSIMULACRA2 processing is done, the sooner the next frame starts decoding. And there is no faster processing than not doing any processing at all, that is, skipping the frame! However, **the decoding itself is a process that has to be done regardless**, and the time it takes should not be disregarded. Although decoding as a process is considerably faster than SSIMULACRA2 computation, it starts becoming the bottleneck when you both compute SSIMULACRA2 so fast, and skip computing frames.

### Considerations about video decoding performance

[NVIDIA's Video Codec SDK 13.0 application note](https://docs.nvidia.com/video-technologies/video-codec-sdk/13.0/nvdec-application-note/index.html#nvdec-performance) gives these indicative per-NVDEC figures for 1080p YUV 4:2:0 decoding:
* Pascal architecture decodes H.264 at up to 694 frames per second.
* Ada architecture decodes H.264 at up to 903 frames per second.
* Ada architecture decodes AV1 at up to 1,018 frames per second.

Being proprietary NVIDIA technology, served as a black box through their API, we cannot be sure how the NVDEC engines are implemented and what exactly are their limitations under scenarios such as these (i.e., concurrent decoding of multiple video streams of same or different codecs). We can only trust the information NVIDIA provides. NVIDIA states that all GeForce products consist of a single NVDEC; however, we cannot be certain how its resources are managed or shared when working with multiple simultaneous decoding contexts.
In our case, considering two videos are being decoded at the same time:
* The GTX 1060 decodes up to 529.7 H.264 (2×264.85) frames per second when using a stride of 23 frames, which corresponds to 75% of its reported peak decoding performance for H.264.
* The RTX 4060 decodes up to 546.14 H.264 + 546.14 AV1 (1092.28 total) frames per second when using a stride of 23 frames, which corresponds to 61.85% and 54.34% of its reported peak decoding performance for H.264 and AV1 respectively. Notice how, even though the NVDEC hardware resources are reportedly being shared between the two decodes, both are able to reach more than 50% peak performance **at the same time**.

We can just focus on _processed_ FPS, that is, only not-skipped frames processed per second, or SSIMULACRA2 scores computed per second, to see how the processing performance degrades with increasing strides.

| Stride | ssimulacra2\_rs FPS | vszip FPS | GTX 1060 GPU FPS | RTX 4060 GPU FPS |
|:-:|:-:|:-:|:-:|:-:|
| 1 | 3.37 | 14.63 | 46.70 | 85.64 |
| 3 | 3.18 | 12.56 | 44.62 | 81.91 |
| 5 | 3.03 | 9.87 | 32.87 | 70.00 |
| 7 | 2.92 | 8.05 | 28.17 | 57.28 |
| 11 | 2.75 | 5.86 | 20.27 | 41.69 |
| 13 | 2.66 | 5.13 | 18.40 | 37.60 |
| 17 | 2.38 | 4.07 | 14.68 | 30.61 |
| 19 | 2.25 | 3.68 | 13.62 | 27.65 |
| 23 | 1.98 | 3.85 | 11.52 | 23.75 |

Here they are in graph form, for better visualization:

![CPU vs GPUs processed FPS](/img/blog_turbo-metrics_11-2024/ssimu2_cpu-gpu_comp.svg)

It can be seen how the actual SSIMULACRA2 processing performance quickly decreases, as more and more relative time gets dedicated to decoding the videos.

One should also note that the NVDEC hardware is the same for all GPUs in the same generation (e.g., all the RTX 40 GPUs). Therefore, even if the computation of the SSIMULACRA2 scores of a video could still be accelerated further by using more powerful GPUs, e.g., RTX 4070/4080/4090, that would only be significant when using small strides. As the stride increases, the video decoding will become the bottleneck for all those GPUs sooner or later, and all of them would perform similarly to the RTX 4060. In other words: **rather than spending more money on a more powerful GPU to compute SSIMULACRA2 faster, it is much more worthwhile to just increase the stride**; especially since the error incurred from using a stride greater than 1 usually is statistically almost insignificant.

### Conclusions

As a quick summary of the experiment, we can highlight:
* **GPU processing greatly accelerates SSIMULACRA2 computation**, with modern GPUs enabling speeds **faster than real-time** for most 1080p content (~85 fps), including gaming; and old GPUs still providing speeds faster than real-time (~46 fps) for popular, lower-fps 1080p video, such as movies and series.
* As SSIMULACRA2 computations accelerate, **video decoding speed becomes a relevant factor, to the point of being the main bottleneck when the computation stride is large enough**. It is not worthwhile to increase the computation stride too much, as you will quickly get diminishing returns in performance.

---

### Further discussion: Possible improvements

One may think that a possible solution to the decoding speed bottleneck, which does not require waiting until the next-generation GPUs implement faster decoding hardware, would be to **make the software decode only the frames that are going to be processed**. Nevertheless, that approach comes with significant caveats: In modern video coding, frames cannot be decoded independently of each other, and a full group-of-pictures (GOP) would need to be decoded to reconstruct any of its frames. Usually, GOPs are from 1 to 10 seconds long (24 to 240 frames in our test case), depending on the encoding settings. Using any computation stride smaller than the GOP size would not see any benefit from this technique; and greater computation strides **would only see limited benefits**. (Aside from the possible accuracy/representativeness concerns associated to using such big strides.) Additionally, when leveraging GPU programming, the actual hardware is often treated like a black box, and the available APIs may limit considerably the control the user has over it.

Another, more useful approach one may think of, would be to exploit **computation overlapping**: To keep decoding frames while the SSIMULACRA2 scores are being computed, storing the decoded frames that are to be processed in a buffer. This seems to be partially implemented in TurboMetrics already, but only to some extent.

Without any modification to the SSIMULACRA2 computations, the overlap in computation and decoding would still have limited effect for low strides (where SSIMULACRA2 computation is still the bottleneck), as every time the decoded frame buffer fills completely, the decoder would have to wait for it to have free space again. In theory, the SSIMULACRA2 computations could be sped up further (maybe requiring faster but more imprecise approximations). And, ideally, TurboMetrics should aim to approach the theoretical decode FPS limit in the computation of the SSIMULACRA2 scores, thus perfectly overlapping computing and decoding. In such scenario, skipping the computation of any frames would not make sense anymore, as no speed advantage would be obtained from it. However, this is still far from being a reality, as a speedup of at least ×10.31 is needed for an RTX 4060 to match its decoding speeds with a computation stride of 1.

## Short discussion on scoring error

My original idea for this blog entry was to evaluate TurboMetrics both in terms of performance and scoring error. By "scoring error" I mean "the difference between the scores a CPU reference provides, and the ones TurboMetrics provides". However, once the first draft for that original version of this blog entry was completed, I realized I was not satisfied with the methodology followed and conclusions extracted from that second experiment. Therefore, I am putting off that evaluation for a second blog entry, that I will write once I make a new, bigger, and better, evaluation of the error.

The main concern about the error the GPU computation incurs on SSIMULACRA2 scores is that SSIMULACRA2 scores have been tuned mathematically to correlate with visual quality, while the GPU implementation's scores _try to mimic_ those scores, but have not undergone any kind of mathematical tuning or assessment themselves. The GPU scores could be seen as "SSIMULACRA2 + random error", and that "random error" might break the desired correlation, thus reducing the reliability of the metric.

Nevertheless, it is worth noting that SSIMULACRA2 is not by any means a kind of "perfect metric" or "absolute truth" about video quality assessment. **SSIMULACRA2 still is unreliable in some situations, and it does not always present a perfect correlation with visual observations**. You may find here and there specific examples of SSIMULACRA2 scores that do not accurately reflect the (perceived) quality of a compressed image or video. Besides, we should keep in mind that quality is a subjective matter. In that regard, and as an example, people who do not care much about film grain might give denoised videos higher quality scores than those that SSIMULACRA2 gives. (Other metrics, such as VMAF, are more tolerant to denoising.) With all this in mind, the results provided by TurboMetrics are not necessarily "incorrect", but rather provide a kind of "**alternative metric**".

Just to give a preview on the error evaluation thus far, I will share the following: The preliminary results I obtained from that now-scraped evaluation seem to indicate that:
* The scores provided by the GPU implementation of SSIMULACRA2 are **statistically different** to the real scores (provided by the CPU implementations).
* **No linear correlation** between the real scores and the GPU scores has been found.
* TurboMetrics **might tend to under-score**, compared to the real scores (i.e., the results for the frames tend to be lower than those a CPU implementation gives). This has yet to be assessed over a larger sample size to prove if it is really true, though.

I am looking for help with the error evaluation for the follow-up blog entry. Mainly, I need a considerably larger sample of SSIMULACRA2 scores for videos, computed both in CPU and GPU. I myself do not have enough material (encoded videos and/or the SSIMULACRA2 scores for all their frames) yet to do a sufficiently good evaluation, and it would take me quite some time to get it. Thus, I am looking for anyone who has saved the SSIMULACRA2 scores for all the frames of any video they had assessed, and is able to re-assess those same videos using TurboMetrics. If you think you can help, and are willing to, please contact me through the [AV1 for Dummies Discord server](https://discord.gg/bbQD5MjDr3).

## Overall conclusions and final thoughts

In this blog entry, we have tested the GPU implementation of SSIMULACRA2 available through TurboMetrics, in terms of performance (i.e., scores computed per unit of time). The main conclusions are the following:
* All in all, TurboMetrics provides **impressive acceleration** of the SSIMULACRA2 computation.
* **The performance of TurboMetrics does not scale linearly with the computational stride/frame skipping**. When increasing the stride, a point of diminishing returns is reached rather soon.
  - This is caused by the time taken to decode the video frames, which is non-negligible, and becomes the bottleneck when computing SSIMULACRA2 so fast and only for some of the frames.

Hardware acceleration of computationally-intensive tasks is an important topic nowadays in several fields, especially considering how powerful current-day GPUs are; and I would hope for the teams developing these quality assessment metrics to consider it as an existing option. So far, only [XPSNR](https://github.com/fraunhoferhhi/xpsnr) has seemed to be concerned about computational complexity from the beginning, and the developers' response was not to consider hardware acceleration, but rather to simplify the design of their metric.

After developing this blog entry, **my own recommendation** for assessing videos using SSIMULACRA2 would be to **use TurboMetrics, with a stride of 3 or 5 frames**. If you are willing to tolerate the error incurred by the GPU implementation, you should tolerate the error incurred by skipping frames, which probably is an order of magnitude lower. Of course, you should not take my recommendations blindly, and you should try it out yourself to see what works for you, and what you can tolerate.

## Future

TurboMetrics' development is still ongoing, and I know Gui-Yom has tons of ideas for it. To begin with, I know the following ideas are being worked on:
* Support for GPUs of other vendors (AMD, Intel).
* Support for FFmpeg piping, to enable working with videos of any codec.
* GPU acceleration of XPSNR.

All these features would improve TurboMetrics significantly, while also opening the door for more tests to be performed. Additionally, as it has been mentioned in this blog entry, the SSIMULACRA2 computation can still be optimized further, including overlapping computation and decoding. Gui-Yom knows this, and plans to tackle that issue eventually.

A list of features to improve TurboMetrics' computation of SSIMULACRA2, written by the main developer, can be found [here](https://github.com/Gui-Yom/turbo-metrics/blob/master/crates/ssimulacra2-cuda/README.md#how-to-do-better-).

As I said earlier, I also plan to write a follow-up blog entry evaluating the scoring error incurred in the GPU implementation, to test the reliability of the scores provided by TurboMetrics. Additionally, it may be insightful to evaluate the error for GPU implementations of other video metrics, such as [VMAF CUDA](https://github.com/Netflix/vmaf/blob/master/libvmaf/README.md), and see if we find any similarities. I do not recall reading any analysis on the matter for other metrics, either. Nevertheless, I cannot give a date yet for when that follow-up blog entry might come out. I reckon it will take quite some time to perform the required experimentation, as well as processing and analyzing the results.

Also, this blog entry is heavily missing information on 4K video, which I believe to be of high interest. The main reason for it is that most 4K content is served using HEVC, and TurboMetrics still does not support that codec. When support for it gets added, experiments with 4K video should be conducted.

If you like TurboMetrics and have knowledge about programming, please consider [contributing to it](https://github.com/Gui-Yom/turbo-metrics) to the best of your ability. Together, we can make it even more awesome than it already is!

And, lastly, thank you very much for reading!

#### Special thanks

* **Gui-Yom**, for developing TurboMetrics, and also for proofreading and green-lighting this blog entry.
* **Trix**, for linking me to the Python script to easily compute SSIMULACRA2 using vszip (ssimulacravszip.py), and for helping me to get it to work the way I needed.

{}


collection: articles

title: Welcome to Encode Wiki

description: Why this project exists and how the initial Codec Wiki material will evolve here.

status: current

license: CC BY-SA 4.0

contentFormat: markdown

markdown:
Encode Wiki is a community-maintained home for practical information about codecs and encoding
tools. It combines durable reference documentation with reproducible guides, experiments, and
benchmark articles.

The initial corpus comes from the AV1 Community Contributors'
[Codec Wiki](https://github.com/av1-community-contributors/codec-wiki). Its pages will be migrated
with source provenance and modification notices under CC BY-SA 4.0. The application and deployment
code written for Encode Wiki is separately licensed under MIT.

The public site is designed to remain useful without accounts, analytics, or an AI service. Clean
machine-readable editions will also make the reviewed corpus easier to use from other tools.


collection: docs

title: Codecs

description: Reference material for video, audio, image, subtitle, and data compression formats.

markdown:
Codec pages describe how formats work, where implementations differ, and what interoperability or
quality constraints matter in practice. The migrated collection will cover video, audio, image,
subtitle, and general-purpose compression.


title: AAC

description: Explore the AAC audio codec, including its various profiles, encoders, & use cases.

text: Format Breakdown

anchor: format-breakdown

text: AAC-LC

anchor: aac-lc

text: AAC-LD & AAC-ELD

anchor: aac-ld-aac-eld

text: HE-AAC

anchor: he-aac

text: xHE-AAC

anchor: xhe-aac

text: Encoders

anchor: encoders

text: Fraunhofer FDK AAC

anchor: fraunhofer-fdk-aac

text: Core Audio

anchor: core-audio

text: FFmpeg AAC

anchor: ffmpeg-aac

text: FAAC

anchor: faac

text: Nero AAC

anchor: nero-aac

text: Exhale

anchor: exhale

text: Conclusion

anchor: conclusion

markdown:
AAC, or Advanced Audio Coding, is an umbrella for a number of different codecs. When people refer to AAC, they are often referring to the commonly used AAC-LC profile developed as part of the original AAC standard in 1997 (although there is a distinction between this version of AAC-LC, called MPEG-2 AAC, & MPEG-4 AAC which is newer). However, there are a number of other variants that have been created over time. These include:
- AAC-LC (low-complexity AAC)
- AAC-LD (low delay AAC)
- AAC-ELD (enhanced low delay AAC)
- HE-AAC (high efficiency AAC, uses Spectral Band Replication)
- HE-AACv2 (high efficiency AAC v2, uses Spectral Band Replication + Parametric Stereo)
- xHE-AAC (extended high efficiency AAC (kinda), uses USAC (Unified Speech & Audio Coding))

AAC is even used as a Bluetooth audio codec for encoding audio streams & sending them to a Bluetooth audio device. Encoding & even decoding some of the above formats can prove to be difficult, so it is worth exploring each codec individually.

## Format Breakdown

Let's explore each codec individually.

### AAC-LC

While AAC-LC was introduced alongside two higher complexity profiles (AAC Main & AAC-SSR), AAC-LC has seen much more widespread adoption through various distribution mediums for video (often paired with AVC video) & audio alike. AAC-LC is ubiquitous within the Apple ecosystem & was (& still is) used on YouTube before their switch to primarily using Opus. Encoding AAC-LC can be done with relative ease, accessible through nearly every encoder in the "Encoders" section.

### AAC-LD & AAC-ELD

AAC-LD & AAC-ELD are both designed to transmit audio in instances where latency is very important. Both are far more efficient than previous low-latency audio coding offerings. Over AAC-LD, AAC-ELD offers better audio quality through Spectral Band Replication, lower latency, & a greater quality range with a lower bitrate minimum & higher maximum.

### HE-AAC

High Efficiency AAC introduces Spectral Band Replication (SBR) to the AAC specification for the purpose of higher quality audio at lower bitrates. SBR is an encoding technique that allows the decoder to reconstruct higher frequencies from an audio signal given lower frequencies & data that informs the decoder about information in the higher frequencies, allowing them to be effectively restored from this helper data. In short, lower frequencies are encoded with extra detail incorporated to allow the reconstruction of higher frequency information in an audio signal. This feature alone allows HE-AAC to be much more efficient than AAC-LC at lower bitrates; the gap closes substantially at higher bitrates, however.

### HE-AACv2

High Efficiency AAC v2 introduces Parametric Stereo (PS), which further increases audio quality with an emphasis on lower bitrates. PS uses a mono signal downmixed from a multichannel stereo input alongside information about the spatial properties of the stereo input to allow the decoder to reconstruct a left & right channel using salient spatial data from the mono signal. HE-AACv2 combine PS with SBR for greater efficiency gains over HE-AAC & AAC-LC, although again the gap closes at higher bitrates.

### xHE-AAC

Extended High Efficiency AAC is actually slightly different from xHE-AAC. While Extended High Efficiency AAC specifically includes all of HE-AACv2's coding techniques as well as compression techniques from the USAC specification, the Extended High Efficiency AAC profile was designed in such a manner that building an encoder for the format would allow it to be perfectly backwards compatible with past variations of AAC. xHE-AAC is a codec that combines the Extended High Efficiency AAC profile with further USAC coding techniques, specifically within the *MPEG-D DRC Loudness Control Profile*. For all intents and purposes, when someone refers to "USAC audio," they probably mean xHE-AAC. xHE-AAC further extends performance at lower bitrates compared to past variants of AAC. USAC's specialty & purpose was to create an audio codec that didn't compromise music performance for speech & vice versa, but rather automatically tuned its coding technique selection to perform the best on any given source.

xHE-AAC is not widely supported. On a Mac, playback is only possible through QuickTime Player & other utilities which use CoreAudio for decoding. Windows 11 & Android support xHE-AAC natively, but Windows 10 & Linux will not allow you to play it back without some grief. The most effective way currently is to use an AAC plugin with foobar2000, although this plugin is 32-bit only, so you'll need 32-bit foobar2000. This works on Linux under WINE.

## Encoders
There are a number of ways to encode each format, which I'll outline below.

### Fraunhofer FDK AAC
Fraunhofer FDK AAC is a high quality, open-source AAC encoder by [Fraunhofer IIS](https://en.wikipedia.org/wiki/Fraunhofer_Society). It was introduced with the release of Android 4.1 and has since been forked to a [seperate repository](https://github.com/mstorsjo/fdk-aac). Issues regarding the legality of its distribution have arisen since the Free Software Foundation declared the license incompatible with the GPL. The license does not grant the user rights to the patented technologies used in the source code, and therefore restricts its use. However, this topic is still debated as Debian does not consider FDK AAC free software while Red Hat does.

Another similar tool, FhG-AAC, performs similarly to FDK-AAC but with greater precision as it performs floating point operations. It can be used through the proprietary Windows media player Winamp.

FDK-AAC can encode the following formats:
`AAC-LC AAC-LD AAC-ELD HE-AAC HE-AACv2`

### Core Audio
Apple's proprietary Core Audio Toolbox encoder is a popular, high-quality choice for encoding AAC. This encoder can be used in macOS via Apple's own `afconvert` utility, or in FFmpeg by specifying `aac_at` as the audio encoder. Windows users can also take advantage of Core Audio by using the free [qaac](https://github.com/nu774/qaac) command-line utility, but users will need to either have [iTunes](https://support.apple.com/en-ca/HT210384) installed, or extract the libraries from said installer, using the [makeportable](https://github.com/nu774/makeportable) script.

Core Audio can encode the following formats: `AAC-LC, HE-AAC, HE-AACv2`*

*`HE-AACv2` encoding is only supported on macOS.

### FFmpeg AAC
FFmpeg's native AAC encoder is known for being completely free & open source, licensed under the GNU General Public License (or LGPL, depending on how FFmpeg is configured). If you want a completely FOSS solution for encoding AAC, FFmpeg AAC is one of the only places you'll find this. It is not known for being particularly feature rich or high quality & doesn't support the entire profile of the AAC variants it can encode, but it gets the job done in most scenarios.

FFmpeg's AAC encoder can be called with a simple `-c:a aac` parameter, but there are more granular options available. By default, the profile is `aac_low` which encodes MPEG-4 AAC-LC. The `mpeg2_aac_low` profile encodes simpler, lower-quality MPEG-2 AAC from 1997, while `aac_main` encodes the more obscure main AAC profile from the 1997 MPEG-2 specification. Finally, `aac-ltp` encodes AAC long-term prediction introduced in MPEG-4.

Using FFmpeg AAC, we can encode the following formats:
`AAC-LC`

### FAAC
FAAC is an old AAC encoder, name meaning Freeware Advanced Audio Coder. It is one of the lower quality options, & isn't recommended for general use. It only supports `AAC-LC`.

### Nero AAC
The discontinued Nero AAC audio coder had its last release in 2010. The developer of FAAC worked on Nero AAC, & the Nero AAC encoder & decoder are proprietary. Nero AAC was known to produce decent quality output while it was maintained, although development has since stalled.

Nero AAC can encode the following formats:
`AAC-LC, HE-AAC, HE-AACv2`

### Exhale

Exhale is the only encoder on this list capable of encoding xHE-AAC audio. While it does not excel at this task compared to proprietary competition, there isn't really a straightforward way to encode xHE-AAC outside of using exhale on most platforms right now. Given that fact, it is the only xHE-AAC encoder many can consider using due to the lack of real competition. It can encode Extended HE-AAC audio with or without eSBR, although encoding using eSBR produces higher quality results.

`exhale` can encode the following formats:
`xHE-AAC`

## Conclusion

Alternatives to AAC include Opus, Vorbis, MP3, & FLAC, among others.
- Vorbis & MP3 are considered to be worse, although Vorbis has its moments & is entirely royalty-free unlike AAC.
- FLAC is a lossless audio codec with an entirely different use case. It is important to reinforce that lossy audio codecs are not replacements for lossless, as good as they might get.
- Opus is competitive with HE-AACv2 & xHE-AAC moreso than the older, worse variants, & is widely supported as well as royalty free. The open source reference encoder `opusenc` is an excellent implementation of the format & the tooling is much easier to use compared to AAC's frankly nightmarish assortment of various options with numerous individual downsides. xHE-AAC is generally better than Opus, especially at lower bitrates, which is a fact that merits consideration.


title: ALAC

description: Codec Wiki reference material about ALAC.

status: needs-review

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!


title: Dolby Digital

text: Format Overview

anchor: format-overview

text: Dolby Digital Surround EX

anchor: dolby-digital-surround-ex

text: TrueHD

anchor: truehd

text: Atmos

anchor: atmos

markdown:
> **Note — Under Maintenance.**
>
> The content in this entry is incomplete & is in the process of being completed.
Dolby Digital is a family of both lossless and lossy audio compression algorithms and technologies.

## Format Overview

### AC-3
Originally known as Dolby Digital, AC-3 was first released in 1991 to provide digital 5.1 sound in cinemas from 35mm film reels. AC-3 is notable for being the first audio codec to make use of the “Modified Discrete Cosine Transform” algorithm. The codec has seen widespread use an adoption, due to its prevalence in DVDs, TV, and Blu-rays as a surround codec.

#### Dolby Digital Surround EX
Like Dolby’s earlier Pro Logic technology, Dolby Digital Surround EX matrixes a sixth, centre back surround channel into the left and right surround channels of a 5.1 stream, allowing for a 6.1 mix to be unfolded when played on a 6.1 or 7.1 system with EX decoding. This technology is fully backwards compatible with existing AC-3 decoders, producing the standard 5.1 stream. Surround EX was first introduced in 1999 with the release of “Star Wars: Episode I – The Phantom Menace”.

### E-AC-3
Often referred to as “Dolby Digital Plus”, E-AC-3 is the successor to Dolby’s earlier AC-3 codec, featuring support for higher bitrates (6,144kbps vs 640kbps), more channels (15 vs 5), and additional coding tools allowing for more efficient encoding. E-AC-3 can be found in the short-lived HD-DVD format, Blu-ray discs, and as the main surround codec for most streaming services, particularly if Dolby Atmos is used. Contrary to popular belief, E-AC-3 is not backwards compatible with AC-3, rather Dolby mandates that all E-AC-3 decoders can also decode standard AC-3 content. As E-AC-3 is an optional codec on Blu-ray, all discs encoded with E-AC-3 encode the first 5.1 channels as AC-3, with the additional rear channels/Atmos content being encoded as E-AC-3.

### TrueHD
Dolby’s TrueHD is a lossless multi-channel audio codec based on Meridian’s Lossless Packing (MLP) codec, although the two aren’t compatible with each other. TrueHD is mainly used on Blu-ray and supports Dolby Atmos’s spatial audio data. The TrueHD specification supports up to 16 audio channels (although the Blu-ray specification limits this to 7.1) with a sample rate of 192KHz and a bit depth of 24 bits. As TrueHD is an optional codec on Blu-ray, each TrueHD steam includes a backup AC-3 stream encoded alongside it for compatibility purposes. Since 2010, Dolby TrueHD has seen a decline in usage in favour of DTS-HD Master Audio on Blu-ray discs, but has seen a slight resurgence as the codec used for Dolby Atmos audio, but DTS-HD MA is still more common on non-Atmos titles.

### AC-4
To be added.

### Atmos
To be added.


title: FLAC

description: FLAC is an open-source lossless audio codec with widespread support & compatibility released in 2001. It represents the most efficent lossless audio format in common use today.

text: Software support

anchor: software-support

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
FLAC (Free Lossless Audio Coding) is an open-source lossless audio codec with widespread support & compatibility released in 2001. It represents the most efficent lossless audio format in common use today.

FLAC is commonly contained in a ogg container with either a `.flac` or `.ogg` extension. It can less commonly be used within a matroska container (`.mkv` or `.mka`) for mixing with a video stream.

> **Caution — It is not recommended to transcode a lossily encoded file to FLAC as the file size will grow tremendously while any quality loss from lossy encoding will remain. FLAC is best if you need to preserve existing lossless audio..**
>
>
## Software support
FLAC is supported by the majority of web browsers and media players in common use as of 2024.

### WAV to FLAC using [FFmpeg](/tools/utilities/ffmpeg/):

```bash
ffmpeg -i example.wav -c:a flac example.flac
```

### WAV to FLAC using FLAC command-line tool:
You can include an argument of a number 0-8 to specify the compression effort, 0 being fastest and 8 having the highest compression.
```bash
flac example.wav -8 -o example.flac
```


title: Intro

description: What is lossless audio? What is lossy audio? What is an audio codec? This entry serves as an intro to digital audio processing.

text: Sampling & the Nyquist Frequency

anchor: sampling-the-nyquist-frequency

text: Lossless Audio Compression

anchor: lossless-audio-compression

text: Lossy Audio Compression

anchor: lossy-audio-compression

text: Conclusion

markdown:
# Introduction to Lossy & Lossless Audio Compression

> **Note — Under Maintenance.**
>
> The content in this entry is incomplete & is in the process of being completed.
Digital audio is the representation of sound recorded in, or converted into, digital form. To understand digital audio, it's crucial to grasp some fundamental concepts, including **sampling**, **Nyquist Frequency**, and the **Nyquist-Shannon Sampling Theorem**.

## Sampling & the Nyquist Frequency

**Sampling** is the process of converting a continuous, analog audio signal into a discrete digital signal by measuring the amplitude of the audio signal at uniform intervals. The frequency of this measurement is known as the *sampling rate*, typically measured in samples per second, or Hertz (Hz). For example, audio CDs use a sampling rate of 44,100 Hz, which means the audio signal is sampled 44,100 times every second.

To accurately represent a wave, you need at least two measurements per cycle; one to capture the peak of the wave, and one to capture the trough. If you sample less than twice per cycle, you can't distinguish between different frequencies; this is where the **Nyquist frequency** comes from. Named after Harry Nyquist, the **Nyquist frequency** is *half of the sampling rate of a discrete signal processing system*. For a given sampling rate, the Nyquist frequency represents the highest frequency that can be accurately sampled without introducing errors such as aliasing. For example, with a sampling rate of 48,000 Hz, the Nyquist frequency is 24,000 Hz. Capturing frequencies above the Nyquist frequency for a given system can bring about **aliasing** artifacts. Aliasing occurs where high-frequency components appear as lower frequencies in the sampled signal, distorting the information.

The **Nyquist-Shannon sampling theorem** states that to avoid aliasing, the sampling rate must be at least twice the highest frequency present in the signal. This theorem is crucial for ensuring that the digital representation of the audio signal retains all the information from the original analog signal without distortion.

## Lossless Audio Compression

The main benefit of lossless compression is the preservation of audio quality, making it ideal for professional audio production, archiving, and situations where high fidelity is required. However, lossless files are significantly larger than their lossy counterparts, which can be a drawback for storage and (especially) streaming.

> **Note — Lossless Compression.**
>
> If you would like to dive more deeply into the topic of lossless compression, you can check out the [Lossless Compression](/start-here/lossless/) entry in the Introduction section of the wiki.
[FLAC](/codecs/audio/flac/), [WavPack](/codecs/audio/wavpack/), & [ALAC](/codecs/audio/alac/) are examples of popular lossless audio codecs that you are likely to encounter in the wild.

## Lossy Audio Compression

The primary advantage of lossy compression is the significant reduction in file size, making it ideal for streaming, portable devices, and situations where storage space is limited. However, the trade-off is a potential loss in audio quality, which may be noticeable in critical listening environments.

> **Note — Lossy Compression.**
>
> If you would like to dive more deeply into the topic of lossy compression, you can check out the [Lossy Compression](/start-here/lossy/) entry in the Introduction section of the wiki.
[MP3](/codecs/audio/mp3/), [AAC](/codecs/audio/aac/), [Vorbis](/codecs/audio/vorbis/), & [Opus](/codecs/audio/opus/) are some examples of popular lossy audio codecs that you are likely to encounter in the wild.

## Conclusion

Understanding these baseline principles of digital audio processing is essential for informed reading when it comes to the rest of the Audio section of this wiki. We hope this page helped you grasp some of the fundamental concepts that underpin digital audio processing.


title: MP3

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
MP3, formally known as MPEG-1 Audio Layer III or MPEG-2 Audio Layer III, is a coding format for digital audio. It was developed largely by the Fraunhofer Society in Germany under the lead of Karlheinz Brandenburg, with support from other digital scientists in other countries.

MP3 is defined in two ISO/IEC specification families: MPEG-1: 11172-3 and MPEG-2: 13818-32. It uses lossy compression, which often allows for large reductions in file size compared to uncompressed audio.

Lossy MP3 compression works by attempting to reduce (or approximate) the accuracy of certain components of sound that could be considered (by some [psychoacoustic](/start-here/terminology/#perceputal--psychovisual--psychoacoustic) analysis) to be beyond the hearing capabilities of most humans and storing the coefficients corresponding to these more salient frequency bands.

Compared to CD-quality digital audio, MP3 compression can commonly achieve a 75 to 95% reduction in size. For example, an MP3 encoded at a constant bit rate of 128 kbit/s would result in a file approximately 9% of the size of the original CD audio. MP3 audio is considered transparent at 320kb/s.

It is still very common to see MP3 files in the wild today, despite the fact that the format was finalized in 1993 (with modifications in 1995 to support lower sample rates and bit rates). This is due to the fact that MP3 could be considered the first widely adopted audio format that allowed for high quality audio to be compressed to a relatively small file size. Compared to more modern formats like [Opus](/codecs/audio/opus/) and [AAC](/codecs/audio/aac/), MP3 may not seem as impressive, but it is still widely supported by many devices and pieces software and has certainly left a powerful legacy to live up to for modern codecs.


title: Opus

description: Opus is an open-source audio codec that has largely replaced Vorbis as the standard open audio codec. It is the recommended codec for usage in WebM video containers in tandem with the VP9 or AV1 video codecs.

text: Format Breakdown

anchor: format-breakdown

text: SILK

anchor: silk

text: CELT

anchor: celt

text: Encoders

text: Opusenc

anchor: opusenc

text: FFopus

anchor: ffopus

text: vac-enc

anchor: vac-enc

markdown:
> **Note — Under Maintenance.**
>
> The content in this entry is incomplete & is in the process of being completed.
Opus is an open-source audio codec that has largely replaced [Vorbis](/codecs/audio/vorbis/) as the standard open audio codec. It is the recommended codec for usage in WebM video containers in tandem with the [VP9](/codecs/video/vp9/) or [AV1](/codecs/video/av1/) video codecs.

Opus is known for its incredible coding efficiency and unique multi-channel optimizations. Stereo Opus audio reaches [transparency](https://en.wikipedia.org/wiki/Transparency_(data_compression)) (psychoacoustically lossless audio quality) at 128kb/s, compared to [AAC](/codecs/audio/aac/)'s generally agreed upon 256kb/s and [MP3](/codecs/audio/mp3/)'s 320kb/s. Transparency varies based on the type of content & the encoding implementation used, especially for codecs other than Opus, and the values provided above may be debated to a degree.

Opus is described on [opus-codec.org](https://opus-codec.org/) as a "totally open, royalty-free, highly versatile audio codec. Opus is unmatched for interactive speech and music transmission over the Internet, but is also intended for storage and streaming applications. It is standardized by the Internet Engineering Task Force (IETF) as [RFC 6716](https://datatracker.ietf.org/doc/html/rfc6716) which incorporated technology from Skype’s SILK codec and Xiph.Org’s CELT codec."

Opus supports the following features:

- Bitrates from 6 kb/s to 510 kb/s (with a maximum of around 255 kb/s per channel on non stereo layouts)
- Sampling rates from 8 kHz (narrowband) to 48 kHz (fullband)
- Frame sizes from 2.5 ms to 60 ms
- Support for both constant bitrate (CBR) and variable bitrate (VBR)
- Audio bandwidth from narrowband to fullband
- Support for speech and music
- Support for mono and stereo
- Support for up to 255 channels (multistream frames)
- Dynamically adjustable bitrate, audio bandwidth, and frame size
- Good loss robustness and packet loss concealment (PLC)
- Floating point and fixed-point implementation

*via opus-codec.org and wiki.hydrogenaud.io*.

## Format Breakdown

Opus is a hybrid audio codec, composed of two codecs as mentioned above. These are Skype's SILK codec for voice & Xiph.Org's CELT codec. Opus's initial name, Harmony, may have been because of the "harmony" of these two codecs and the musical connotation of harmony.

### SILK

SILK, initially from Skype, was designed to be used for voice calls on Microsoft products like Skype. The first stable release of the codec was in 2009, and since then it has been freely licensed under the BSD 2-Clause license which has allowed for its adoption into Opus. The version of SILK used in Opus is substantially modified from - and not compatible with - the standalone SILK codec previously described here.

SILK is optimized for speech, and so has limited sample rates as follows:
> Narrowband: 3-4000hz
> Mediumband: 3-6000hz
> Wideband: 3-8000hz

SILK's latency is 10 to 60ms based on the desired framesize + 5ms lookahead to estimate noise shaping + (potentially) 1.5ms sampling rate conversion overhead if the input audio needs to be resampled.

### CELT

Much like SILK, CELT is under the BSD 2-Clause license. The preview release came out in 2011. CELT stands for "Code-Excited Lapped Transform" and was designed to be the true successor to Vorbis, even being dubbed as "Vorbis II" during its initial development as part og Xiph.Org's "Ghost" project in 2005.

CELT was designed to be a full-band general purpose codec without a particular specialization for a certain kind of audio, making it distinctly different from Xiph's [Speex](/codecs/audio/speex/) codec & more similar to Vorbis. It is computationally simple relative to competing codec technologies like [AAC](/codecs/audio/aac/) & even Vorbis, enabling extremely low latency that is competitive with [AAC-LD](/codecs/audio/aac/#aac-ld--aac-eld).

CELT can work with the following sample rates:
> Narrowband: 3-4000hz
> Mediumband: 3-6000hz
> Wideband: 3-8000hz
> SuperWideband: 3-12000hz
> Fullband: 3-20000hz

## Encoders

### Opusenc

Opus's reference encoder is [opusenc](https://github.com/xiph/opus), which is known for its fantastic performance and versatility. It is licensed under the BSD 3-clause license as part of the reference libopus library. There are a myriad of options that may be used to encode with opusenc, but the utility is considered to have sane encoding defaults for local storage & playback. The best options will be outlined below.

Usage: `opusenc [options] input_file output_file.opus`

- `--bitrate #.###` Sets the overall target bitrate in kbit/s. Most encoders use *bits* per second, meaning you have to specify "128K" for 128kbit/s for example. Opus doesn't follow this, so you'd just have to type "128" though keep in mind using efficient VBR encoding means the final bitrate may be different than the target. Opus supports bitrates from 6 kb/s to 510 kb/s.

- `--vbr` Tells the encoder to encode using a variable bit rate, allocating more or less bits when necessary to preserve overall fidelity per bit. This is the best option for local storage & playback, and is *enabled by default.*

- `--cvbr` Tells the encoder that it is allowed to vary the bitrate like with VBR, but it must constrain the maximum bitrate at any given moment to the value provided.

- `--hard-cbr` Tells the encoder to use a constant bitrate the whole time.

- `--music` & `--speech` Forces the AI content-detector built into opusenc to treat the input as either speech or music. The bitrate range where this is relevant is around 12-40kb/s.

- `--comp #` Sets the encoder complexity to a value from 0 to 10, 0 being the least complex & 10 being the most. *The default is 10.*

- `--framesize #` Sets the maximum encoder frame size in milliseconds. Lowering this is useful for improving latency at the expense of audio quality per bit. It is worth noting that 40 & 60ms framesizes are just multiple 20ms frames stitched together via opusenc's default behavior, and are not considered useful as they just lower the encoder's adaptability which can worsen both latency & coding efficiency. *The default value is 20.*

- `--expect-loss #` Percentage value for expected packet loss. Not useful for local encoding & playback, but useful for real-time applications. *Default value is 0.*

- `--downmix-mono` Downmixes multiple channels into a single channel.

- `--downmix-stereo` Downmixes multiple channels into two channels, left & right, given more than two channels are provided to the encoder.

- `--no-phase-inv` Disables phase inversion. Helpful when downmixing stereo to mono, although this is the default behavior in that scenario since libopus 1.3. Slightly decreases stereo audio quality.

- `--max-delay #` Sets maximum container delay in milliseconds, from 0-1000. *Default is 1000.*

Looking at the default values for the encoder flags, opusenc almost always follows the best practices for every default value. This makes it very easy to use, and it is as simple as plugging in a source of some kind and using only the most basic commands to encode with opus.

An example opusenc command:
```bash
opusenc "input.wav" "output.opus" --bitrate 96
```

[FFmpeg](/tools/utilities/ffmpeg/) using libopus:
```bash
ffmpeg -i "input.flac" -c:a libopus -b:a 128K "output.ogg"
```

If you'd like to learn more about opusenc & its recommended default behavior, read this article on [Opus Recommended Settings](https://wiki.xiph.org/Opus_Recommended_Settings#Bandwidth_Transition_Thresholds).

> **Info — Existing bug in ffmpeg.**
>
> Due to a bug in ffmpeg [(#5718)](https://trac.ffmpeg.org/ticket/5718), ffmpeg won't automatically remap `5.1(side)` to `5.1` when using libopus.
> To remap the channel layout explicitly, try this:
> ```bash
> ffmpeg -i "input.flac" -c:a libopus -af aformat=channel_layouts=5.1 "output.ogg"
> ```
>
> > **Tip — You can handle arbitrary audio stream mappings with this:.**
> >
> > ```bash
> > -af aformat=channel_layouts=7.1|5.1|stereo -mapping_family 1
> > ```
### FFopus

FFopus is an experimental native opus encoder from FFmpeg. It is not widely regarded as providing any decent uplift in coding efficiency compared to libopus, and is usually considered worse; its only merit is being able to handle 5.1(side) streams while libopus in FFmpeg cannot. It only implements the CELT part of the Opus codec.

FFopus usage:
```bash
ffmpeg -i "input.wma" -c:a opus -b:a 128K -strict -2  "output.opus"
```

### vac-enc

[VAC](https://github.com/gianni-rosato/vac-enc), or Value Added Codec, is a libopus encoder that uses SoX to resample inputs & supports output to `.ogg` rather than exclusively `.opus`. Better resampling theoretically leads to better coding efficiency, but vac-enc hasn't been thoroughly tested.

Encoding a 16-bit signed little endian `pcm_s16le` WAV to 128kbit/s Opus in an OGG container:
```bash
vac-enc input.wav output.ogg 128
```


title: Speex

description: Speex is an open-source audio codec designed for speech. It has largely been replaced by Opus.

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
Speex is an open-source audio codec designed for speech. It has largely been replaced by [Opus](/codecs/audio/opus/).


title: Vorbis

text: Usage

anchor: usage

text: Encoder

anchor: encoder

text: Decoder

anchor: decoder

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
Vorbis is an open-source audio codec first released in 2000, maintainted by the Xiph.org Foundation. It has seen great success in its usage by Spotify, among others. It is the default audio codec for Minecraft's sounds & music. It has largely been replaced by [Opus](/codecs/audio/opus/).

## Usage
Vorbis is supported in [ffmpeg](/tools/utilities/ffmpeg/).
### Encoder
```bash
ffmpeg -i input.wav -c:a libvorbis output.ogg
```
### Decoder
```bash
ffmpeg -i input.ogg output.wav
```
See [ffmpeg](/tools/utilities/ffmpeg/) for more options.


title: WavPack

text: Features

anchor: features

text: Hybrid Mode

anchor: hybrid-mode

text: Format Breakdown

text: Encoders

anchor: encoders

text: wavpack

anchor: wavpack

text: FFmpeg

anchor: ffmpeg

text: Adoption issues

anchor: adoption-issues

text: Notes

anchor: notes

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
WavPack is an open-source lossless audio codec with support for lossless & lossy compression with a unique hybrid compression mode for compressing a lossy audio stream alongside a lossless reference. Created by David Bryant in 1998, it gained a lot of software support, although not as much as [FLAC](/codecs/audio/flac/).

Compressed file size is somewhat between [FLAC](/codecs/audio/flac/) and heavier state-of-art lossless audio compressors like TAK, OptimFrog or SAC. Compared to [FLAC](/codecs/audio/flac/), WavPack usually gives a lower bitrate at the expense of slightly more resource usage.

## Features

WavPack is one of the most robust and feature-rich lossless audio codecs. Some notable features include:

- [Hybrid mode](#hybrid-mode)
- Support for 1-32 bit integer/floating point audio streams
- Muxable into Matroska `.mkv` container
- Multichannel with up to 4096 channels
- APEv2/ID3v1 tagging format
- RIFF chunks support
- Multithreaded encoding/decoding
- Error detection using CRC32 checksums and optionally also MD5 hash of original audio data

## Hybrid Mode

Hybrid Mode is not to be confused with hybrid codecs like [Opus](/codecs/audio/opus/). WavPack uses the same algorithm for both lossy and lossless mode. When using lossy mode, the encoder transmits only the unary magnitude and the sign bit of Recursive Golomb encoded residuals. During decoding, those data points can be further enhanced if the correction file is provided.

WavPack can produce 2 output files when using Hybrid Mode. The main `.wv` file with truncated (lossy) residuals and a `.wvc` correction file containing the enhancement layer. When both files are provided to the decoder, it should be able to recreate original audio data. Otherwise, if only the `.wv` file is available, the decoder will decode lossy audio stream.

## Format Breakdown

Like in many lossless audio codecs, WavPack only encodes the prediction error value. In the default `fast` mode, prediction is just extrapolation of the previous two samples. More sophisticated predictors are used with higher encoding modes.
Due to poor performance, unpredictability, and other problems with floating-point arithmetic in CPUs of its time, WavPack only uses integer arithmetic even when operating on IEEE float data. Nowadays, many of those issues were addressed, however it could still make porting WavPack to chips with no FPU support much easier.

The encoding process consists of 3 main steps:

- Joint stereo processing - Converts the stereo channels to the standard difference and average, removing inter-channel correlations.

- Multipass decorrelation - Includes multiple prediction passes where the number of passes and predictor type depend on the selected encoding mode, removing intra-channel correlations between neighboring audio samples.

- Entropy coding the residuals with Recursive Golomb Coding - Instead of Rice Coding, the author proposed a new technique that combines Golomb and Elias gamma code to better address the nature of audio data.

## Encoders

### wavpack

```bash title="Default options"
wavpack input.wav -o out.wv
```

```bash title="Fast, lowest compression, md5 hash"
wavpack input.wav -f -m -o out.wv
```

```bash title="Very slow, highest compression, 8 threads"
wavpack input.wav -hh -x6 --threads=8 -o out.wv
```

```bash title="Lossy, slow, 240kbps"
wavpack input.wav -b240 -h -x3 -o out.lsy.wv
```

```bash title="Highest hybrid compression, very slow, 4bps"
wavpack input.wav -b4 -cc -hh -x6 -o out.hyb.wv
```

`wvunpack` can be used to decode resulting `.wv` files, however most major [media players](/tools/video-players/) like MPV or VLC already have (limited) WavPack support.

Options:

- `-f` Faster encode/decode at the expense of larger file size
- `-h` Slower encode/decode with higher compression
- `-hh` Slowest encode/decode with highest compression

- `-x0` Disable extra filters
- `-x3` Try all predefined filters, slow, higher compression
- `-x6` Generate custom filters, very slow, best compression

- `-b240` Enable lossy mode, set bitrate to `240kbps` (acceptable range is `24`-`9600` but it won't get lower than `2 bits per sample`)
- `-b4` Enable lossy mode, set `bits per sample` to `4` (acceptable range is `2`-`23.9`)

- `-c` Enable hybrid mode (will produce `.wv` and `.wvc` file)
- `-cc` Enable and optimize for hybrid mode, might lower decoding speed and hurt quality

- `-m` Include MD5 hash of original audio data in the output file
- `--threads=8` Use `8` threads (acceptable range is `1`-`12`)

For more detailed description of all available options, see the [manual](https://www.wavpack.com/wavpack_doc.html).

### FFmpeg

[FFmpeg](/tools/utilities/ffmpeg/) has its own native WavPack encoder and decoder. It used to also support `libwavpack` with `--enable-libwavpack`, however it was [removed](https://hydrogenaud.io/index.php/topic,120038.0.html) due to interface incompleteness.

The native encoder is single-threaded and doesn't support neither Lossy or [Hybrid](#hybrid-mode) Mode. It uses the `-compression_level` parameter to control speed to compression ratio.

```bash title="Fastest, lowest compression"
ffmpeg -i input.wav -compression_level 0 out.wv
```

```bash title="Slowest, highest compression"
ffmpeg -i input.wav -compression_level 8 out.wv
```

For all possible parameters, consult the [FFmpeg documentation](https://www.ffmpeg.org/ffmpeg-codecs.html#wavpack).

## Adoption issues

As of 2024, WavPack has been largely superseded by [FLAC](/codecs/audio/flac/), which became the de facto standard for lossless audio on the Web and in Hardware.

The implementation of WavPack in media software is often incomplete. FFmpeg doesn't support [Hybrid Mode](#hybrid-mode), and other media players usually don't support it either. There are also [issues](https://www.reddit.com/r/ffmpeg/comments/tpptoi/using_hybrid_wavpack_in_video/) with its support in the `.mkv` container.

Without this feature, WavPack doesn't provide much benefit over already widespread [FLAC](/codecs/audio/flac/). The compressed file might be slightly smaller, however music streaming companies tend to choose well-standardized FLAC which also has the benefit of `DRM` support in the `.mp4` container (apparently very important thing on the modern web).

Even if [Hybrid Mode](#hybrid-mode) had better software support, the minimum lossy setting is `2 bits per sample`. That translates to around `200kbps` with stereo audio track which is quite high. The quality of WavPack lossy mode is also somewhat lacking compared to modern lossy codecs such as [Opus](/codecs/audio/opus/) or [AAC](/codecs/audio/aac/) because it doesn't utilize any psychoacoustic model.

## Notes
- WavPack was one of the first compressed lossless audio codecs preceding Monkey's Audio (2000), [FLAC](/codecs/audio/flac/) (2001), OptimFROG (2002) and [ALAC](/codecs/audio/alac/) (2004).
- OptimFROG Dualstream is a feature of OptimFROG codec serving a similar purpose to WavPack Hybrid, however it was introduced much later.
- Apparently there are some devices with WavPack [Hardware Support](https://hydrogenaud.io/index.php/topic,119143.0.html).

**References:**
- [WavPack Compression Techniques](https://www.wavpack.com/WavPack.pdf)
- [WavPack Technical Document](https://www.wavpack.com/technical.htm)
- [Old WavPack File Format Specification](https://web.archive.org/web/20160705230053/http://www.wavpack.com/file_format.txt)
- [Hydrogenaudio Wiki](https://wiki.hydrogenaud.io/index.php?title=WavPack)
- [Multimedia.cx Wiki](https://wiki.multimedia.cx/index.php/WavPack)
- [Wikipedia](https://en.wikipedia.org/wiki/WavPack)
- [FFmpeg WavPack Source](https://ffmpeg.org/doxygen/3.3/wavpackenc_8c_source.html)


title: 7z

description: 7-zip is a file format that supports several different data compression, encryption, & pre-processing algorithms. It was introduced by the 7-Zip archiver, which is free and open-source software for dealing with various d

text: 7-zip (7z)

markdown:
# 7-zip (7z)

> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
7-zip (7z) is a file format that supports several different data compression, encryption, & pre-processing algorithms. It was introduced by the 7-Zip archiver, which is free and open-source software for dealing with various data compression formats including formats similar to 7z like [XZ](/codecs/data/xz/).

The 7-zip format has some noteworthy advantages over the popular [ZIP](/codecs/data/zip/) format.
- The 7-zip utility can compress files to the 7z format "30-70% better" than to ZIP format despite having a highly efficient ZIP encoder. It mainly uses the LZMA & LZMA2 algorithms, which are more modern than DEFLATE and usually compress better.
- 7-zip can encrypt files with AES-256 using a user provided password. AES-256 is more secure than the ZipCrypto encryption often used by ZIP.
- 7-zip can support files up to 16 exabytes in size, while traditional ZIP has a 4 GB limit (ZIP64, which is commonly used, does not suffer from this 4 GB limitation so this is less relevant now). 7-zip also supports various pre-processing filters, which can improve compression for certain types of data like executables and binaries.

However, 7-zip also has some drawbacks and limitations.
- 7-zip is not as widely supported as ZIP by other software and platforms. Some users may need to install additional programs or plugins to open or extract 7z files.
- Slower speed: 7-zip archives may take longer to compress or decompress compared to ZIP. This is somewhat mitigated by the 7-zip utility's effective parallelization when decoding, but this only affects real time as opposed to user time meaning it is still likely going to be more expensive to decompress than ZIP.
- 7-zip does not have any built-in mechanism to repair corrupted or damaged archives. Users may need to use third-party tools or backup copies to recover their data1

7z archives are supported natively by macOS & many Linux distributions.


title: brotli

description: Brotli was released by Google in late 2013, & it is commonly used on the Web for content delivery. It is a core part of the .woff2 Web Open Font Format, allowing web fonts to be smaller when sent to users as part of a we

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
Brotli was released by Google in late 2013, & it is commonly used on the Web for content delivery. It is a core part of the `.woff2` Web Open Font Format, allowing web fonts to be smaller when sent to users as part of a website. It is not very common to pass around `.tar.br` Brotli archives like you would with [gzip](/codecs/data/gzip/) or [xz](/codecs/data/xz/), so it is perfectly acceptable that such files aren't really compatible anywhere. Brotli is almost universally compatible across the Web, supported by as much as 96% of the World Wide Web's users.

Brotli is based on LZ77 & Huffman coding, much like ZIP. It also uses context modeling to allow the use of multiple Huffman trees for the same alphabet in the same block; this essentially means that based on the context of the data being compressed, it can be compressed more efficiently especially if it contains multiple different kinds of data.

Brotli was co-authored & partially developed by Jyrki Alakuijala, who also worked on [JPEG-XL](/codecs/images/jxl/) & the efficient [JPEG](/codecs/images/jpeg/) encoder jpegli. JPEG-XL's metadata information is usually Brotli-compressed.


title: bzip2

description: bzip2 is a open source file compression format and utility. It's efficency is slightly better than zip, but worse than lzma based formats like xz and 7z. bzip2 cannot be used to compress mutliple files at once, you shoul

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
bzip2 is a open source file compression format and utility. It's efficency is slightly better than [zip](/codecs/data/zip/), but worse than lzma based formats like [xz](/codecs/data/xz/) and [7z](/codecs/data/7z/). bzip2 cannot be used to compress mutliple files at once, you should collate files together into a [tarball](/codecs/data/tar/) to compress mutliple files using bzip2.


title: gzip

description: Gzip is a DEFLATE implementation for use with individual files. It is popular on Unix-like systems such as Linux & macOS, and is often seen paired with tar to create .tar.gz archives. Formats like ZIP & PNG also use Defl

text: Format Breakdown

text: History

anchor: history

text: Encoding

anchor: encoding

text: Linux & macOS

anchor: linux-macos

text: Windows

anchor: windows

markdown:
Gzip is a DEFLATE implementation for use with individual files. It is popular on Unix-like systems such as Linux & macOS, and is often seen paired with [`tar`](/codecs/data/tar/) to create `.tar.gz` archives. Formats like [ZIP](/codecs/data/zip/) & [PNG](/codecs/images/png/) also use Deflate to different effects.

## Format Breakdown

While ZIP is a multi-file archiving format that can compress multiple files into a single compressed file, Gzip is a single-file format that compresses a single file into a single compressed file. Both use DEFLATE for compression. ZIP supports encryption, while Gzip does not. ZIP also stores more extensive header information.

## History

In order to properly understand the gzip format, we must first talk about ZIP. A lot of similar or identical information is covered in our ZIP entry.

The ZIP format was developed by Phil Katz as an open format with an open specification, where his implementation PKZIP was shareware.

A [restricted ZIP format](http://www.digitalpreservation.gov/formats/fdd/fdd000361.shtml) exists and is used in other filetypes such as Java .jar archives, a slew of Microsoft Office file formats, Office Document Format files (.odt, .ods, .odp), and EPUB files for e-readers.

In around 1990, Info-ZIP came onto the scene. "Info-ZIP's purpose is to provide free, portable, high-quality versions of the Zip and UnZip compressor-archiver utilities that are compatible with the DOS-based PKZIP by PKWARE, Inc." (https://infozip.sourceforge.net/). They did this successfully, leading to increased adoption of the ZIP format.

In the early 1990s the [gzip](/codecs/data/gzip/) format was developed, derived from the Deflate code in the Info-ZIP utilities. It was designed to replace the Unix `compress` utility, which used the (at the time) patented LZW compression algorithm which threatened its free use. Though some specific implementations of Deflate were patented by Phil Katz, the format was not, so a Deflate implementation that did not infringe on any patents was written.

As a `compress` replacement, the Unix gzip utility can decompress data that was compressed using `compress`. Gzip compresses quite a bit better than Unix compress due to its use of DEFLATE, and it has very fast decompression. It also adds a CRC-32 checksum as an integrity check for the archived data. The header format permits the storage of more information than the compress format allowed, such as the original file name & the file modification time.

The popular [`tar`](/codecs/data/tar/) utility, which creates an archive of files, has an option to compress directly to the `.tar.gz` format and is a very popular use caze for gzip. Since the compression of a `.tar` can take advantage of redundancy across files, ZIP often compresses less effectively than the marriage of tar & gz. `.tar.gz` is the most common archive format in use on Unix due to its very high portability, but there are better compression methods available. Some of these include [XZ](/codecs/data/xz/), [bzip2](/codecs/data/bzip2/), [brotli](/codecs/data/brotli/), [7-zip](/codecs/data/7z/), & [Zstandard](/codecs/data/zstd/).

## Encoding

### Linux & macOS

Chances are, you have gzip already available on your system. You can encode gzip archives using the `gzip` command.

1. Open a terminal window.

2. Navigate to the directory where you want to create the gzip archive.

3. Use the `gzip` command followed by the name of the file you want to compress. For example:
```bash
gzip -7 myfile.txt
```
This will create a compressed file called `myfile.txt.gz` in the current directory using compression level 7. Compression levels span from 1 through 9 (`-1 .. -9`; shortcuts are `--fast` for `-1`, `--best` for `-9`).

4. If you want to compress multiple files at once, you can use the `-a` option followed by the names of the files you want to compress. For example:
```bash
gzip -a myfile1.txt myfile2.txt
```
This will create compressed files called `myfile1.txt.gz` & `myfile2.txt.gz` in the current directory.

5. If you want to compress a directory and all its contents, you can use the `-r` option followed by the name of the directory. For example:
```bash
gzip -r mydirectory/
```
This will create compressed versions of each file in the specified directory.

6. If you want to encode the gzip archive with a different extension, you can use the `-S` option followed by the suffix `.suf`. For example:
```bash
gzip -S .suf myfile.txt
```
This will create a gzip-compressed file called `myfile.txt.suf` in the current directory.

Also, you can use other options like `-v` for verbose mode, `-f` to force overwriting & compress links, `-l` for listing the files and `-d` for decompressing the files.

You can find more information about the `gzip` command & its options by running `man gzip` in a terminal.

### Windows

To be filled.

*References: Mark Adler is an American software engineer best known for his work in the field of data compression as the author of the Adler-32 checksum function, and a co-author of the zlib compression library and gzip. He has contributed to Info-ZIP, and has participated in developing the Portable Network Graphics (PNG) image format. Much of this post is based on his writing in [this StackOverflow answer](https://stackoverflow.com/questions/20762094/how-are-zlib-gzip-and-zip-related-what-do-they-have-in-common-and-how-are-they)*


title: tar

description: tar, or Tape ARchive, is a archiving format and utility first developed for Version 7 Unix in 1977. It's original purpose was to collate files into one that can be stored on tape. Similarly, today it is used to bring man

text: Usage

text: Create a tar archive

anchor: create-a-tar-archive

text: Extract a tar archive

anchor: extract-a-tar-archive

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
`tar`, or Tape ARchive, is a archiving format and utility first developed for Version 7 Unix in 1977. It's original purpose was to collate files into one that can be stored on tape. Similarly, today it is used to bring many files together into a "tarball", which can be compressed with any general data compression algorithm.

## Usage
> **Note — This guide has been written for GNU tar on linux, however it should be applicable to BSD tar, macOS tar, and the tar command in powershell on Windows..**
>
>
### Create a tar archive
```bash
tar -cf {archive name} {files listed here}
```
You can use `tar` to compress your archive, for example into a `.tar.gz` or `.tar.xz` archive. To do this, you either can either use a flag such as `-z`, `-j`, or `-J` ([gzip](/codecs/data/gzip/), [bzip2](/codecs/data/bzip2/), [xz](/codecs/data/xz/)), or you can use `-a` ('automatic'), which allows it to intuit what algorithm you want from the file extension, such as `archive.tar.xz` for an xz compressed tarball.

GNU tar can use these compression algorithms
* gzip (.gz)
* bzip2 (.bz)
* xz (.xz)
* lzip (.lz)
* lzma (.lzma)
* lzop (.lzo)
* zstd (.zstd)
### Extract a tar archive
```bash
tar -xf {tarball}.tar -C {directory to extract to}
```
tar can extract from it's supported compressed formats, such as `archive.tar.xz` automatically, with no extra flags.


title: xz

description: XZ is a data compression format and utility based on the Lempel-Ziv-Markov Chain Algorithm . The XZ format itself is an improvement on LZMA, allowing for preprocessing filters similar to 7-zip to increase the resulting a

text: Usage

text: Compression

anchor: compression

text: Decompression

anchor: decompression

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
XZ is a data compression format and utility based on the Lempel-Ziv-Markov Chain Algorithm (LZMA). The XZ format itself is an improvement on LZMA, allowing for preprocessing filters similar to [7-zip](/codecs/data/7z/) to increase the resulting archive's compression ratio.

XZ can only compress one file at a time, so making a [tar](/codecs/data/tar/) archive of the files you'd like to compress (if there are multiple) is necessary when using XZ.

XZ is more widely supported when compared to other data compression formats, seeing support across iOS, macOS, and many Linux distributions by default. To decompress & compress XZ on Windows, you will likely need the 7-Zip archive utility.

## Usage
This usage is for the `xz` utility on linux, but is applicable to other platforms where xz can be used. It should be noted that `xz`'s default behavior is to delete the original file after it has completed the relevant compression or decompression operation, but this can be stopped with the flag below. An arbitary number of files may be passed to xz and it will individually complete the specified operation on each given file.

### Compression
```bash
xz {file}
```
This will result in a file named `{file}.xz` being created in the current working directory.

A more advanced variant is listed here:
```bash
xz -# --extreme -M 800Mib -T 2 -k {file}
```

- `-#` is a number between 0 and 9 specifying speed presets, 0 being the fastest and 9 slowest.
- `--extreme` is an option allowing xz to use more time than the standard preset level.
- `-M {size}` is an option restricting the memory usage of `xz` either as a percentage of system memory or an absolute amount.
- `-T {threads}` is an option restricting the number of threads used by `xz`.
- `-k` prevents xz from deleting the input file.

### Decompression
```bash
xz -d {file}.xz
```
This decompresses the xz archive to it's original file.

- `-M {size}` is an option restricting the memory usage of `xz` either as a percentage of system memory or an absolute amount.
- `-T {threads}` is an option restricting the number of threads used by `xz`.
- `-k` prevents xz from deleting the input file.


title: ZIP

text: Format Breakdown

anchor: format-breakdown

text: History

text: Encoding

text: Linux & macOS

text: Windows

text: Conclusion

anchor: conclusion

markdown:
> **Caution — Pending Review.**
>
> The content in this entry may not be entirely accurate, & is pending further review to assess the quality of the information.
ZIP is an archive file format that supports lossless data compression. A ZIP file may contain one or more files or directories that may have been compressed using any one of a number of different algorithms present in the ZIP specification. The most common algorithm used in ZIP is DEFLATE, which is also used in [gzip](/codecs/data/gzip/) & [PNG](/codecs/images/png/).

Deflate acts as a combination of LZ77 lossless coding & Huffman coding, where it can first use LZ77 to find patterns in the data & reduce redundancy. This is followed by using Huffman coding to assign smaller bit values to patterns found more frequently by LZ77.

Additionally, files in a ZIP archive are compressed individually so it is possible to extract existing files or add new ones without applying compression or decompression to the entire archive.

ZIP is noteworthy for its nearly universal compatibility. "Traditional ZIP" (compression method 8 in the ZIP specification) limits the size of compressed archives to 4 GB, though most ZIP compressors use Deflate64(tm) (compression level 9 in the ZIP specification) to bypass this limitation. ZIP is competitive with [gzip](/codecs/data/gzip/) and has been succeeded many times by formats & algorithms such as [bzip2](/codecs/data/bzip2/), [XZ](/codecs/data/xz/), [7-zip](/codecs/data/7z/), [brotli](/codecs/data/brotli/) (to a degree), and [Zstandard](/codecs/data/zstd/).

## Format Breakdown

DEFLATE is an LZ77-based compressor that finds repeated sequences of bytes in the input data and replaces them with shorter references to previous occurrences. It also uses Huffman coding to encode the symbols with variable-length codes based on how frequently they occur. DEFLATE has two modes for each block of compressed data: These are specified as either "static" or "dynamic" Huffman compressed blocks. In static mode, the Huffman codes are fixed and predefined. In dynamic mode, the Huffman codes are generated dynamically & transmitted along with the compressed data.

ZIP files have a specific structure that consists of four main file header components: local file headers, central directory file headers, end of central directory record, and data descriptors. The local file headers store information about each compressed file, such as its name, size, CRC-32 checksum, compression method, and optional extra fields. The central directory file headers store similar information as the local file headers, but also include the offset of each local file header in the ZIP file. The end of central directory record marks the end of the ZIP file and contains information about the number and size of the central directory file headers. The data descriptors are optional and store additional information about the compressed data, such as its CRC-32 checksum, uncompressed size, & compressed size.

ZIP files can also support other compression methods, such as Deflate64(tm), BZIP2, LZMA, & [Zstandard](/codecs/data/zstd/). These methods are not widely supported by most ZIP utilities and may cause compatibility issues. ZIP files can also contain uncompressed data. The format also supports encryption to protect the data from unauthorized access. There are two types of encryption supported by ZIP: traditional ZipCrypto encryption and strong encryption. ZipCrypto encryption is considered insecure, while stronger encryption in ZIP uses more resilient algorithms albiet spread across a number of standards. Because of this, strong encryption is not standardized and may cause compatibility issues.

ZIP files can reduce the size of files and folders by more efficiently representing redundant data. They can also combine multiple files and folders into a single archive that can be easily transferred or stored. You will not find a more popular implementation than ZIP for general data compression purposes like these. ZIP files can also preserve the metadata of the original files, such as their names, paths, dates, and attributes. However, ZIP files also have some limitations and concerns. For example, traditional ZIP files (that aren't ZIP64) have a maximum size of 4 gigabytes for each compressed file and 65,535 entries for each archive. Most ZIP implementations do not support symbolic links or hard links within the archive.

Additionally, ZIP can be encoded in a number of different ways. Apple has a default "Compress" option in Finder that compresses selected files into a ZIP file, and many Linux desktops offer GUI functionality for creating ZIP files easily as well. It is common to compress to ZIP on Windows using the 7-zip data compression & decompression utility (not to be confused with the [7-zip compression format](/codecs/data/7z/), though the two are related).

## History

The ZIP format was developed by Phil Katz as an open format with an open specification, where his implementation, PKZIP, was shareware.

A [restricted ZIP format](http://www.digitalpreservation.gov/formats/fdd/fdd000361.shtml) exists and is used in other filetypes such as Java .jar archives, a slew of Microsoft Office file formats, Office Document Format files (.odt, .ods, .odp), and EPUB files for e-readers.

In around 1990, Info-ZIP came onto the scene. "Info-ZIP's purpose is to provide free, portable, high-quality versions of the Zip and UnZip compressor-archiver utilities that are compatible with the DOS-based PKZIP by PKWARE, Inc." (https://infozip.sourceforge.net/). They did this successfully, leading to increased adoption of the ZIP format.

In the early 1990s the [gzip](/codecs/data/gzip/) format was developed, derived from the Deflate code in the Info-ZIP utilities. It was designed to replace the Unix `compress` utility, which used the (at the time) patented LZW compression algorithm which threatened its free use. Though some specific implementations of Deflate were patented by Phil Katz, the format was not, so a Deflate implementation that did not infringe on any patents was written.

Unlike `.tar`, `.zip` has a central directory at the end, which provides a list of the contents. That and the separate compression provides random access to the individual entries in a `.zip` file. A `.tar` file would have to be decompressed and scanned from start to end in order to build a directory.

The popular `tar` utility, which creates an archive of files, has an option to compress directly to the `.tar.gz` format and is a very popular use caze for gzip. Since the compression of a `.tar` can take advantage of redundancy across files, ZIP often compresses less effectively than the marriage of tar & gz. `.tar.gz` is the most common archive format in use on Unix due to its very high portability, but there are better compression methods available. Some of these include [XZ](/codecs/data/xz/), [bzip2](/codecs/data/bzip2/), [brotli](/codecs/data/brotli/), [7-zip](/codecs/data/7z/), & [Zstandard](/codecs/data/zstd/).

In this case, the benefit of ZIP is that because it compresses files separately and builds a central directory at the end of the archive which provides a list of the contents, ZIP provides random access to the individual entries in a `.zip` file. A `.tar` file would have to be decompressed and scanned from start to end in order to build a directory.

## Encoding

#### Linux & macOS

To encode to a ZIP file most efficiently on Linux or macOS, it is worth using the 7-zip implementation of DEFLATE for ZIP compression. The 7zip website's homepage claims: "For ZIP and GZIP formats, 7-Zip provides a compression ratio that is 2-10 % better than the ratio provided by PKZip and WinZip." You can use the highly flexible 7-zip CLI utility through binaries available on [7-zip's Download page](https://www.7-zip.org/download.html). Here are some direct download links: [Linux x86_64](https://www.7-zip.org/a/7z2301-linux-x64.tar.xz) | [macOS Universal](https://www.7-zip.org/a/7z2301-mac.tar.xz)

Once you've downloaded the utility, remember whether you are choosing to use the `7zz` binary or the static `7zzs` binary. Commands run using `7zz` should run using `7zzs` as well, so please replace `7zz` in our examples as appropriate if you choose not to use it. Additionally, please copy your choice of binary to your `/usr/local/bin` if you want to be able to use it everywhere.

- To encode a ZIP file at the lowest effort setting using one thread:
```bash
7zz a -bso0 -tzip -mmt1 -mx1 "Output.zip" "Input"
```

- To encode a ZIP file at the highest effort setting using eight threads:
```bash
7zz a -bso0 -tzip -mmt8 -mx9 "Output.zip" "Input"
```

#### Windows

To be filled.

## Conclusion

The only real benefit of using ZIP over more modern formats currently is compatibility. It may be viable when compared to 7z & XZ due to a reduction in complexity that improves encode & decode speed, but Zstandard is incredibly performant in both of these areas and generally outperforms ZIP. When it comes to content delivery on the Web, Brotli has been adopted across all modern web browsers and offers a better alternative to older compression technologies used on the Web that resemble ZIP.


title: zpaq

markdown:
> **Danger — Help Wanted.**
>
> This section is in need of contributions. If you believe you can help, please see our [Contribution Guide](/reference/legacy/contribution-guide/) to get started as a contributor!
ZPAQ is a lossless data compression algorithm that combines several techniques to achieve high compression ratios. It was developed by Matt Mahoney.

ZPAQ uses a multitude of different compression algorithms to try to achieve the best size-to-compression-time ratio possible while producing the smallest possible archives without much concern given to decompression performance. On the official ZPAQ website, it looks like it is designed for "realistic backups that have a lot of duplicate files and a lot of already compressed files."

ZPAQ is also considered an "incremental journaling archiver" meaning you can add files to an existing archive based on if they were changed or not. This reduces the time needed to wait for a new backup to finish, if that is your use case. Since ZPAQ is so focused on compression ratio, this kind of feature may reduce the burden imposed by long compression times in practical use cases where it makes sense. Windows & macOS do not handle ZPAQ archives properly by default, and it is unlikely many Linux distros do either.