问题标签 [lossless-compression]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票
1 回答
1441 浏览

ffmpeg - 使用 ffmpeg 从 m4a 文件中删除前导和尾随静音

我有一个音频文件,它具有前导和尾随静音,并具有以下细节:

编解码器:MPEG AAC 音频 (mp4a) 通道:立体声 采样率:44100 Hz 比特率:253 kbps

我想消除沉默并保持质量不变。

到目前为止我已经尝试过

这应该删除前导和尾随的沉默。但由于某种原因,它并没有消除尾随的沉默。这似乎是一个反复出现的问题。在另一个论坛上找到以下内容。

http://ffmpeg-users.933282.n4.nabble.com/How-to-delete-digital-silence-tp4667256p4667356.html

此外,ffmpeg 将比特率降低到 128kbps。我可以通过添加-ab 253k并发出命令来解决这个问题:

现在的问题是没有删除尾随的静音,当我想处理一批文件时,我不能对每个文件使用相同的比特率(如 253kbps )。我想知道如何在这种情况下使用 VBR。

我知道我可以使用 sox 并使用静音和反向功能来修剪静音。

http://digitalcardboard.com/blog/2009/08/25/the-sox-of-silence “本文中的示例 3”

但是sox存在以下问题:

  1. 它无法处理 m4a 文件,我必须将所有文件转换为 mp3。
  2. 在 sox 中使用静音过滤器时,它将比特率限制在 128kbps。

    /li>
0 投票
1 回答
1097 浏览

c++ - 使用后缀树匹配 LZ77/LZSS 上的重叠前瞻

背景:我在 C++ 上实现了一个通用 LZSS 后端(可在此处获得。我在这个版本中使用的匹配算法非常简单,因为它最初是为了压缩相对较小的文件(最多 64kB),用于相对古老的硬件(特别是,Mega Drive/Sega Genesis,其中 64kB 是整个主 RAM)。

然而,在我的实现中,一些文件的压缩时间太长了,大约几分钟。原因有两个:天真的匹配算法花费了大部分时间,但这特别是因为我从文件中构造了一个压缩图以实现最佳压缩。查看分析器,大部分时间都花在寻找匹配上,甚至使结果图的二次大小相形见绌。

一段时间以来,我一直在研究几种可能的替代品;引起我注意的是使用多层后缀树的字典符号灵活解析。多层部分很重要,因为我感兴趣的 LZSS 变体之一对(位置、长度)使用可变大小的编码。

我当前的实现允许滑动窗口中的匹配项与前瞻缓冲区重叠,因此该输入:

可以直接编码为

代替

这里,(0,'a') 表示将字符“a”编码为文字,而 (1,n,m) 表示“从位置 n 复制 m 个字符”。

问题:说了这么多,这是我的问题:我在后缀树上找到的每个资源似乎都暗示它们无法处理重叠的情况,而只允许您找到不重叠的匹配项。当涉及到后缀树时,研究论文、书籍甚至一些实现都给出了没有重叠的压缩示例,就好像它们是完美的压缩一样(我会链接到其中的一些,但我的声誉不允许这样做)。他们中的一些人甚至提到在描述基本压缩方案时重叠可能很有用,但在讨论后缀树时却奇怪地沉默了。

由于无论如何都需要扩充后缀树以存储偏移信息,因此这似乎是一个可以在查找匹配项时检查的属性——您将过滤掉从前瞻缓冲区开始的任何匹配项。并且树的构造/更新方式意味着,如果一条边将您带到与从前瞻开始的匹配对应的节点,则您将返回前一个节点,因为任何进一步的后代也将在前瞻中缓冲。

我的方法是错误的还是不正确的?是否有 LZ77/LZSS 的实现或讨论,其后缀树提到匹配与前瞻缓冲区重叠?

0 投票
1 回答
273 浏览

splunk - Splunk 日志数据优化

我是 Splunk 的新手,我希望优化我将添加到 splunk 的日志数据文件(进行无损压缩)。由于数据必须是文本的(不是二进制或任何其他格式),我不能进行霍夫曼编码等,也不知道从哪里开始。

任何帮助/想法都会很棒。

0 投票
5 回答
549 浏览

algorithm - 连续分数项的良好压缩方案?

所以我正在实现一个连分数库来处理二次整数有理数的子集。连分数项由无符号整数表示。在处理连分数时,我注意到以下一般模式:

  1. 大多数术语都是小的个位数,其中 1 是最常见的。
  2. 有些术语可能很大,对于我的应用程序来说最大的可能是 366 位,但这些非常罕见。
  3. 较大的项表示一个特别好的数字近似,这意味着对于大部分而言,总体而言通常较少的项。
  4. 最坏的连分数是黄金比例,366 位精度的有理近似值大约对应于连续 525 个 1。
  5. 随机有理数通常不会有大量相同的数字,但可能有两到四个连续,其中 1 也是最常见的。

所以我对术语的数量和术语的大小都有限制,术语的数量与它们的大小大致成反比。所以将这些术语存储在机器字甚至字节中通常是非常浪费空间的,在最坏的情况下我仍然需要处理多字算术。鉴于术语大小和术语数量之间的大致反比关系(这两者都取决于分数的分子和分母的大小),我一直在尝试找到或提出一个好的压缩方案,这样我就不会浪费存储整数项的空间很大。

我考虑过Huffman encoding,因为编码和解码的速度很好,但我不确定如何得出代码值的概率。我有一种模糊的直觉,即Stern-Brocot 树可能会提供一个提示,因为它们是与连分数有直接关系的二叉树。

有谁知道一种很好的压缩方法来处理大量的小数字和偶尔的大数字,其中相同数字的运行通常很短(但在极少数情况下可能很长)?特别是我需要能够相当快地进行编码和解码(比如 O(n*lg(n)) 是我可以容忍的绝对最差的速度,O(n) 或更好),并且能够达到个别术语的位置,以便我知道我正在操作的术语编号(第四学期,第五学期等)。

另外,我对使用任何第三方实数或连分数库不感兴趣。我已经看过几个,它们要么不足以满足我的需求,要么过于矫枉过正,我想要自己编写代码以供我自己启迪的经验。

更新

我还了解了Gauss-Kuzmin 分布k,它给出了随机数在 0 和 1 之间均匀分布的特定连分数项的概率分布。它是

P(k) = -lg(1.0 - 1.0/((k + 1.0)**2)在 Python 伪代码中,其中 lg 是以 2 为底的对数。这是k接近无穷大的极限,所以我的情况受到更多限制(尽管2**366仍然很大)。Linas Vepstas 的“连分数的熵”给出了 Gauss-Kuzmin 分布的(信息)熵大约为 3.43 位。我的最大分母足够大,以至于我的连分数的信息熵可能接近该限制,尽管链接文章中的图表显示该限制的接近速度非常缓慢,因此对于相对较小的分母来说是不同的。

0 投票
1 回答
37 浏览

lossless-compression - 压缩或加密数据

我有两个字节,我想使用一个密钥将它们压缩成一个字节(密钥长度最多可达 64 位)。此外,我希望能够通过使用压缩字节和相同的密钥来检索这两个字节。有人知道怎么做吗?

谢谢。

0 投票
3 回答
19862 浏览

python - 在 django 上无损压缩图像

我正在做优化,谷歌建议对图像进行无损压缩,寻找一种在 Django 中实现这一点的方法。

这是他们指定的图像,我认为要有效地完成它需要在系统范围内实现,可能使用中间件类想知道是否有人以前做过。这是页面速度的谷歌分析链接https://developers.google.com/speed/pagespeed/insights/?url=www.kenyabuzz.com

优化图像 正确格式化和压缩图像可以节省许多字节的数据。优化以下图像,使其大小减少 627.3KiB(减少 74%)。

0 投票
3 回答
1144 浏览

algorithm - 是否有数学证明霍夫曼编码是最有效的无损压缩算法?

我的朋友告诉我它存在但我永远找不到它,不确定他是否在撒谎,但我对证明的工作原理非常感兴趣。(是的,我是从硅谷电视节目中发现霍夫曼编码的人之一,抱歉)

0 投票
2 回答
1006 浏览

opencv - OpenCL 无损视频压缩

我正在寻找 OpenCL 中的无损视频压缩。它必须是无损的,因为它是项目要求。找到了一些用 OpenCV 和 ffmpeg 编写的无损算法,但它们都不支持 OpenCL 编码/解码。我使用的是 Apple 电脑,它们带有不支持 CUDA 的 ATI 显卡。

非常感激任何的帮助。

0 投票
2 回答
138 浏览

c++ - 边界检查 - 出界

我需要一点调试。代码 100% 可编译。但是,如果给定要压缩的文档的小片段,它会崩溃,并且在解压缩时会出现有关边界检查的错误。我也有点害怕运行它。这并不危险,但这是我目前的杰作。它正好处于压缩技术的最佳位置。这是我编的。它使用微积分推导算法来获取数百万个唯一密钥以供使用。这些都是可以预见的。而且因为它们是独一无二的,所以我不能通过在散列中多次使用密钥来搞砸它。这段代码的目的是生成一个完全可再生且在压缩过程中不会造成损失的散列。谢谢你。

0 投票
1 回答
76 浏览

java - 部分解压并估计实际解压数据报文的大小

我有一个简单的要求,如果消息超过 X 字节的上限,我想丢弃或不处理它。但是,发件人可以压缩消息并发送。如果用户创建一个随机消息,例如全 0 或 1 等,则压缩熵变化很大。然而,假设一个受信任的发件人有办法窥视压缩消息并在解压缩时估计其实际大小。我正在使用使用 java.util.zip 的 Zip 协议,但我对其他库或语言中的任何解决方案持开放态度。