问题标签 [lossless-compression]

他们是android中的任何库或任何其他方法可以（无损压缩）压缩android中的音频文件吗？Ps 请参考具有良好文档的库 bcoz 我找到了 ffmpeg 但无法使用它。

文本压缩的 Lempel-Ziv-Welch ( LZW )的Weissman 分数是多少？

我想 Weissman 分数是 1.0，因为它已经是标准压缩器，还是我错了？

我有一个大小为 500 mb 的大文件，可以在一分钟内以最佳压缩率进行压缩。我发现这些算法适合我的使用。

1. lz4
2. lz4_hc
3. 活泼的
4. 快点
5. 块

有人可以比较这些算法之间的速度和压缩比吗？

我最初在信号处理上问了这个问题，但它离题了。所以，就这样吧！

我尝试从 Audacity 导出录音两次，每次都使用相同的参数和标签。结果文件有不同的校验和。所以我打开了两个文件的差异（作为二进制文件）。

我的第一次尝试是一个包含 32 位浮点 PCM 的 wav 文件。整个文件中只有 3 位不同。

变成了

我的第一个问题是：这三个位是做什么用的？

然后我用 flac 文件尝试了同样的过程。我不会在这里粘贴它，因为它会太长，但发生的情况是，在文件的开头，这里和那里只有一些差异，但是在文件中我得到的越远越明显文件不同。

这是为什么？flac压缩算法不是确定性的吗？

最后，我获取了一个包含 16 位签名 PCM 的 wav 文件并将其转换为 16 位签名的 flac 文件，然后再转换回 wav。我获得的文件与原始文件非常相似，但似乎数据偏移了 33 个字节，从这些文件样本中可以看出：

原始文件：

新文件：

为什么？

我最近在压缩一些文件，我注意到 base64 编码的数据似乎压缩得非常糟糕。这是一个例子：

• 原始文件：429,7 MiB
• 通过压缩xz -9：
  13,2 MiB / 429,7 MiB = 0,031 4,9 MiB/s 1:28
• base64它并通过以下方式压缩xz -9：
  26,7 MiB / 580,4 MiB = 0,046 2,6 MiB/s 3:47
• base64原始压缩 xz 文件：
  17,8 MiB几乎没有时间 = 预期1.33x的大小增加

所以可以观察到的是：

• xz 压缩得真好☺</li>
• base64编码的数据压缩不好，比未编码的压缩文件大2倍
• base64-then-compress比compress-then-base64明显更差和更慢

怎么会这样？Base64是无损、可逆的算法，为什么对压缩影响这么大？（我也尝试使用 gzip，结果相似）。

我知道base64-then-compress一个文件没有意义，但大多数时候人们无法控制输入文件，我会认为因为实际的信息密度（或任何它被称为) 的 base64 编码文件几乎与非编码版本相同，因此同样可压缩。

我正在使用 OpenH264 编解码器。OpenH264 正在使用 Exp-Golomb 编码来获取标头相关信息。我研究了几个网站并收集了一些关于 Exp-Golomb 编码的信息。OpenH264 使用 4 种 Exp-Golomb 编码方法。他们是：

• Ue [当值仅是非负数时]
• Te [当值只有 1 或 0 时]
• Se [当值既是负数又是正数时]
• 我[当值为值定义标准代码映射时]

我已经学会了如何通过 Method Ue构造或解析。

Exp-Golomb(Ue) = [M-Zeros][1][INFO] 的语法格式。

构造：假设我们有一个 Code_Num = 226。
现在，
M = floor(log2(Code_Num)) = floor(log2(226)) = 7
INFO = Code_Num + 1 - pow(2,M) = 226 + 1 - 128 = 99 = (1100011) in Binary
So,
CodeWord = 0000000 1 1100011 [M-zeros, 1 ignoring bit, INFO]

解析： 假设我们有一个 CodeWord = 000000011100011
Code_Num = pow(2,M) + INFO - 1 = 128 + 99 - 1 = 226

现在我可以计算 Exp-Golomb(Ue)。但我想学习所有与 Se、Te 和 Me 相关的理论。但我找不到其他方法的任何资源。请帮我。

哪种无损压缩算法（LZW 或 JBIG 之间）更适合压缩由图像（彩色和单色）组成的数据集？

我已经实现了这两者并在较小的数据集上进行了测试 [每个包含 100 张图像] 并发现了不确定的结果。

请注意:: 我不能使用像 Jpeg 这样的有损压缩，因为解压缩后的数据必须与源的数据相同。我也不能使用其他无损算法，例如 PNG，因为负责解压缩的固件不支持它们。

所以我一直在努力使用 LZW 压缩来压缩不同的文件。我的压缩功能似乎工作正常，因为我能够将 5000kb pdf 压缩成大约 2200kb。但是我的解压算法无法解压 pdf。生成的文件仍然与压缩文件大小相同，并且 pdf 已损坏。我正在遵循一些伪代码：

谁能引导我朝着正确的方向前进，为什么我的减压功能是错误的？

我正在为我的课堂作业创建 Huffman 压缩程序。我知道如何实现它，但是由于解码器必须使用编码器存储的转换表或从头开始创建霍夫曼树，我想通过编码器存储完整的霍夫曼树，因此解码器不需要重建它。我开始知道用指针保存东西是不一样的，所以我看到序列化可能会有所帮助。我的主要问题是：

1-序列化是否能够按原样存储树？2-存储树是否会占用更多空间然后存储转换表并重建它？

我想最小化要存储在编码文件中的树数据。我在这里说的是纯文本压缩。- 谢谢

我的主要项目之一是微控制器的显示库。作为其中的一部分，我有一组字体（位图）和图标（alpha 通道）。

由于微控制器中的资源（闪存和 RAM）有限，我正在寻找更好的方法来存储这些字体和图标的数据。

我倾向于对数据使用分离平面排列（如使用的 Amiga 上的 ILBM） - 也就是说，不是将每个像素的所有位存储在一起，而是将整个图像的所有第一位存储在一起，然后是第二位等。这对于处理不是二次幂的图像深度变得更有效（您是否尝试将 3 位数据打包成 8 位数据流？）。

然后我还想压缩每个位平面。RLE 似乎是最明智的。但是，由于我现在使用的是比特流，而不是整数，我想知道实现 RLE 的最佳方式是什么。

我可以坚持传统的方法来处理 8 个块中的位并查找重复的字节（2 个或更多相同，替换为 2 相同，然后计算运行中的数量），但我看不到当涉及到将包含一个位平面的按位数据时，那就太好了。（顺便说一下，ILBM 使用了多种这种逐字节的方法——将数据纯粹作为字节处理，并根据需要重复它们，并使用定义如何处理下一个字节的“标题”字节）。

另一种方法是使用交替位计数方法。即，开始假设该位为 0，并记录运行中该位的编号。然后切换到 1 并记录运行中 1 的位数。然后再次切换回0并记录位数。等等。

同样，如果您长时间运行相同的位，那就太好了，但是一旦您获得快速的位交替，您最终会占用大量空间（例如 8 位01010101可能最终成为 8 个字节[1,1,1,1,1,1,1,1]）。

这里任何事情的主要警告是它必须是高效的 - 在 CPU 中解压缩它，并在内存中保存任何工作缓冲区，同时它解压缩。这就是为什么我在考虑 RLE 而不是其他任何方法。

所以我想我正在寻找我错过的想法。压缩单个比特流并在以字节为中心的系统中表示压缩数据的最佳实现是什么？

一个示例字形（十进制）：

因此，位平面 0-3 将是

但是，这种大小的字形我什至不太可能尝试压缩。它小到毫无意义。但是，它说明了位平面的分层以及位流相对于原始数据的外观。