它是 Opus,它很棒,现在它是一个音频编解码器标准!

在开放标准取得巨大胜利之际,互联网工程任务组 (IETF) 刚刚将 Opus 标准化为 RFC 6716

Opus 是第一个被标准化的最先进的免费音频编解码器。我们认为这将有助于我们比之前的免版税编解码器(如 Speex 和 Vorbis)获得更广泛的采用。这意味着专有格式的终结,我们现在正致力于对视频做同样的事情

3 年多前,当它首次在 IETF 被提出时,这项工作遭到了怀疑和 outright opposition。然而,结果表明,我们可以通过协作来创建一个更好的编解码器,而不是在专利技术之间竞争。开放标准对开源组织和专有公司都有利,我们已经成功地合作创建了一个开放标准。Opus 是许多组织合作的结果,包括 IETF、Mozilla、微软(通过 Skype)、Xiph.Org、Octasic、博通和谷歌。

一个高度灵活的编解码器

与以前的音频编解码器不同,以前的音频编解码器通常专注于一组狭窄的应用程序(语音或音乐,在狭窄的比特率范围内,用于实时或存储应用程序),Opus 非常灵活。它可以在以下方面自适应切换:

  • 从 6 kb/s 到 512 kb/s 的比特率
  • 语音和音乐
  • 单声道和立体声
  • 窄带 (8 kHz) 到全带 (48 kHz)
  • 从 2.5 ms 到 60 ms 的帧大小

最重要的是,它可以在这些工作点之间无缝地自适应。使用专有编解码器完成所有这些操作将需要至少六种不同的编解码器。Opus 取代了所有这些,并且质量更高。
Illustration of the quality of different codecs
规范在 RFC 6716 中提供,其中包括参考实现。 最新的软件版本 也可用。

一些音频标准定义了规范性编码器,它在标准化后无法改进。其他标准允许编码器灵活,但会发布一个故意受到限制的参考实现,迫使你许可他们的专有编码器。对于 Opus,我们选择允许未来的编码器灵活,但我们也制作了我们所知道的最好的一个,并将其作为参考实现发布,这样每个人都可以使用它。我们将继续改进它,并将这些改进作为开源发布。

用例

Opus 主要设计用于互联网上的交互式应用程序,包括语音 over IP (VoIP)、电话会议、游戏内聊天,甚至现场、分布式音乐表演。IETF 最近以“强烈共识” 决定将 Opus 作为一项必须实现的 (MTI) 编解码器 用于 WebRTC,这是一种即将推出的用于 web 上实时通信的标准。尽管重点是低延迟,但 Opus 在流媒体和存储应用程序方面也表现出色,超过了现有的高延迟编解码器,如 Vorbis 和 HE-AAC。它非常适合互联网广播、自适应流媒体、游戏音效和更多

虽然 Opus 刚刚发布,但它已经在许多应用程序中得到支持,例如 FirefoxGStreamerFFMpegfoobar2000K-Lite 编解码器包lavfilters,即将在 VLCrockboxMumble 中支持。

有关更多信息,请访问 Opus 网站

关于 Jean-Marc Valin

Jean-Marc Valin 拥有谢布鲁克大学的电气工程学士、硕士和博士学位。他是 Speex 编解码器的主要作者,也是 Opus 编解码器的主要作者之一。他的专业领域包括语音和音频编码、语音识别、回声消除和其他与音频相关的主题。他目前受雇于 Mozilla,负责下一代多媒体编解码器。

Jean-Marc Valin 的更多文章……

关于 Timothy B. Terriberry

Timothy B. Terriberry 是 Xiph.Org 基金会的一名长期志愿者,从事 Theora、Vorbis、CELT 和 Opus 等编解码器的开发。自 2008 年以来,他一直为 Mozilla 的媒体支持做出贡献,并自 2010 年以来一直在参与 WebRTC 的开发。

Timothy B. Terriberry 的更多文章……


89 条评论

  1. Ashley

    很有趣!你知道这是否也会成为 HTML5 音频的强制性实现吗?这是另一个迫切需要一种在所有地方都能正常工作的单一格式的领域。

    2012 年 9 月 11 日 下午 11:56

    1. Timothy B. Terriberry

      我们当然希望如此,我们正在努力让所有其他浏览器都支持它。

      2012 年 9 月 11 日 下午 12:02

    2. Shmerl

      我支持这个问题。我们能期待 Opus 成为音频标签支持的强制性标准吗?

      2012 年 9 月 11 日 下午 12:11

      1. Shmerl

        抱歉,错过了回复 :) 谢谢您的回答。

        2012 年 9 月 11 日 下午 12:12

    3. Ryan B.

      HTML5 似乎仍然处于主流的边缘,但不知何故总是难以突破。总有一天我们都会赶上……

      2012 年 9 月 15 日 下午 10:44

  2. 匿名

    是否有计划创建 WebM 的版本,用 Opus 替换 Vorbis 编解码器?

    2012 年 9 月 11 日 下午 12:12

    1. Timothy B. Terriberry

      这是我们仍在与 WebM 社区的其他成员讨论的事情。WebM 的优势之一是,你不必实现大量编解码器来支持它。Opus 的比特率节省在与大多数视频的比特率相比时较小,但它们仍然可能值得放弃这种简单性。

      总有一天,我们希望使用下一代视频编解码器。将它与 Opus 配对肯定会很有意义。

      2012 年 9 月 11 日 下午 12:21

  3. Bruce Perens

    嗨,Jean-Marc 和 Tim,

    祝贺你们将此通过标准化流程。

    但是,不幸的是,一些公司已经根据 RAND 条款声明了其专利,这些条款包含“可能的版税费”,与开源实现不兼容。这些公司是

    Qualcom: https://datatracker.ietf.org/ipr/1520/
    华为: https://datatracker.ietf.org/ipr/1712/

    你们是否正在努力使你们的编解码器免受上述专利的影响?

    2012 年 9 月 11 日 下午 12:30

    1. Monty

      嗨,Bruce,

      QC 和华为都对 Opus 进行了 IPR 声明。我们审查了他们的声明;它们毫无根据。但是,声明流程不需要公司为声明辩护。他们可以仅仅提出声明并一走了之(并且在许多工作组中都有这样做)。

      这是一种毫不费力的策略,可以赚取免费许可费用;可悲的是,这除了“即使是和解也很昂贵,支付两美元”之外毫无意义。这完全是滥用系统,我们对此提出了正式投诉。QC 的回应归结为“我们不在乎,这是合法的”。

      好消息是,他们的声明必须包含专利号,虽然这意味着浪费了法律时间,但我们能够详细审查这些专利。它们不适用。我们不会发布任何非 RF 的代码(或标准),一切如此,没有附加条款。

      2012 年 9 月 11 日 下午 12:56

      1. Bruce Perens

        嗨,Monty,

        好吧,我很生气。因为无论他们的专利是否适用,他们的努力都会营造一种_不存在自由软件_的环境。如果他们说服陪审团他们的主张是有效的,这些 IPR 主张的存在可以用来支持对明知故犯的侵权索赔三倍的赔偿,而不是简单的赔偿。我们刚刚目睹了苹果诉三星案件,我们应该知道,你可以说服陪审团相信很多错误的事情,尤其是专利案件。

        作为社区,我们与标准化组织合作,这些组织很乐意采取 RAND 立场,并促进 RAND 对于开放标准的可接受性(参见 open-stand.org),我们构建了许多软件,这些软件被用于这些公司产品的生产中,而这些公司反过来又试图束缚我们。

        2012 年 9 月 11 日 下午 1:43

    2. Timothy B. Terriberry

      嗨,Bruce,

      请查看我们之前文章中关于 Opus 免版税状态的声明:https://hacks.mozilla.ac.cn/2012/08/opus-support-for-webrtc/
      我相信我们在那里所说的一切都是准确的,并且仍然适用。

      我们很乐意更多地谈谈你提到的 IPR 披露,但我们仍在等待我们法律部门的批准。我相信你理解我们为什么不能在公开场合说太多我们已经说过的内容。

      2012 年 9 月 11 日 下午 1:06

      1. Bruce Perens

        嗨,Tim,

        我写信给 Qualcom 的相关人员,要求他们帮助公司加入进来。我不认识华为的任何人。

        我知道你不会在没有律师的批准的情况下发表任何言论。

        如果那些明显在产品中使用大量开源软件的公司,采取了试图束缚我们工作的立场,我们真的应该对他们施加一些社会压力。无论_我们_是否认为他们的专利实际上适用与否 - 他们正在提出主张,并应该承担相应的成本。当然,我们应该给他们一些时间改变主意,或者让私人接触发挥作用。但是,应该有一个日期,如果这些声明没有改变,我们_会_采取行动。

        我很乐意与任何一方进行保密谈话,如果你想打电话,请拨 +1 510-4PERENS。

        2012 年 9 月 11 日 下午 1:17

  4. 拼写检查器

    好消息!请将 Foobar2000 更改为 foobar2000。

    谢谢。

    2012 年 9 月 11 日 下午 12:37

    1. Robert Nyman

      谢谢!我们已经修正了拼写错误!
      另外:我知道你在这里选择的名字并没有恶意,但它可能会冒犯一些人,因此,我已删除了前半部分。

      2012 年 9 月 11 日 下午 13:36

  5. roger

    如何在 ffmpeg 中使用它?

    2012 年 9 月 11 日 下午 12:51

    1. Timothy B. Terriberry

      使用最新版本的 ffmpeg 运行“ffmpeg -codecs”显示
      D.A… opus Opus (解码器:libopus)

      所以,如果你在构建时启用了 libopus 支持(在配置时使用 –enable-libopus),解码应该“正常工作”。 有一些小问题(例如,用于无缝播放的样本精确结尾修剪未实现),但我相信这些问题将会被解决。

      2012 年 9 月 11 日 下午 13:20

  6. Audy

    相当酷的成就。 有没有计划针对无损编解码器进行类似的标准化工作?也许是 FLAC?

    2012 年 9 月 11 日 下午 12:55

    1. Timothy B. Terriberry

      至少,IETF 似乎对标准化现有格式不感兴趣,除非允许他们进行更改和改进,而我们不得不付出一些努力来让他们相信这不是我们试图对 Opus 做的事情。 为了获得 SDO 的认可而创建一个与 FLAC 这样成熟且部署良好的格式不兼容的新版本可能不值得。 不过,如果在其他地方进行这种操作有意义,我无法想象 Xiph 会反对这个想法。

      2012 年 9 月 11 日 下午 13:27

    2. starwed

      FLAC 不是已经开放且免版税了吗?

      2012 年 9 月 11 日 下午 13:29

      1. Dusk

        FLAC 是一个无损编解码器 - 它通常会生成比 OPUS 等无损编解码器高出几个数量级的比特率的输出,而且无法“降低”。

        2012 年 9 月 11 日 下午 13:40

        1. natermer

          你想使用 Flac 以 100% 的质量存档音频。

          Opus 用于你愿意放弃一些音频质量以换取大幅提高压缩率的情况。 使用低比特率的 Opus 可能会生成一首歌曲的 3MB 文件,而 FLAC 对于相同的音频可能会达到 150MB。

          我对于音频的操作是使用 flac 存储它,但在流式传输或传输到设备时,使用其他编解码器对其进行即时编码。 这样,我总是可以获得最佳的音频质量,并同时获得最佳的压缩率。

          2012 年 9 月 11 日 下午 14:30

        2. Z4ppy

          “[…] 比 *有损* 编解码器(如 OPUS)更高 […]”
          ;-)

          2012 年 9 月 11 日 下午 14:53

      2. Ryan

        是的,但它与 Opus 并不相似,它在大多数 Opus 目标应用场景中也无法使用。 多读少评论。

        2012 年 9 月 15 日 下午 19:11

  7. Reino

    BASS 音频库 (http://www.un4seen.com/bass.html) 也是支持 OPUS 的应用之一。

    2012 年 9 月 11 日 下午 13:27

  8. Audy

    我同意,如果任何 SDO 想要进行会使 FLAC 向后不兼容的更改,那么寻求这种认可就不值得。 但 FLAC 仍然可以从更改中受益,比如支持超过 2GB 的文件大小,以及可能进行一些更改,使其更容易用于音乐制作方面的工作。 所以,我希望 xiph 针对 FLAC 做一些类似的事情,如果可以在向后兼容的方式下获得 SDO 的认可。 由于微软和苹果都有与 FLAC 竞争的无损格式,我认为 FLAC 的普遍采用尚未得到保证,也不可能在长期内得到保证,我认为 SDO 的支持可以帮助确保 FLAC 的成功。 也许不是 SDO,让 DLNA 组织将 FLAC 无缝播放添加到他们的标准中也有帮助。 但不要偏离今天的成就 - 祝贺 Opus 的诞生!

    2012 年 9 月 11 日 下午 14:39

    1. Jessica

      我不认为 FLAC 格式本身限制为 2GB,事实上,用于搜索表的偏移量似乎是完整的 64 位。 就我所知,2GB 限制只是 Windows 上的参考实现中的问题。

      2012 年 9 月 11 日 下午 17:05

      1. Ryan

        那是 Winblow$。

        2012 年 9 月 15 日 下午 19:13

  9. gonewest

    有人有比特率高于 128kbps 的“质量与比特率”图表吗?

    好奇的是,Vorbis、Opus、mp3 和 AAC 是否在该点以上渐近收敛,或者它们是否交叉并在该点以上发散。

    2012 年 9 月 11 日 下午 16:13

    1. Timothy B. Terriberry

      不幸的是,很难获得在如此高的速率下具有统计意义的听力测试结果,因为(除了 MP3 之外),这些格式在 128kbps 时已经基本上透明了。

      2012 年 9 月 11 日 下午 16:52

      1. Gonewest

        我明白了。 我没有意识到这些是基于定性的听力测试。

        谢谢 -

        2012 年 9 月 11 日 下午 19:12

  10. dimitri flores

    谁来处理 5.1、7.1、x.1 音频?

    2012 年 9 月 11 日 下午 17:19

    1. Timothy B. Terriberry

      我不确定你想问什么。 .opus 格式支持多声道音频。 Firefox 不支持多声道输出 (https://bugzilla.mozilla.org/show_bug.cgi?id=521615,目前受阻于 https://bugzilla.mozilla.org/show_bug.cgi?id=782507),但作为临时措施,我们在 https://bugzilla.mozilla.org/show_bug.cgi?id=748144 中添加了对播放多声道 Opus 文件的支持,方法是将它们降混到立体声(目前在 Aurora 频道上可用,并计划在 11 月发布)。

      2012 年 9 月 11 日 下午 17:28

  11. Chun-Kwong Wong

    我们离真正的开放网络又近了一步。 祝贺大家! 还要感谢所有人的辛勤工作。 现在,我们只需要在视频方面也发生同样的情况。

    2012 年 9 月 11 日 下午 17:33

    1. Ryan

      但不幸的是,一些讨厌的东亚人正在对 Opus 发起虚假的专利主张。

      Qualcom: https://datatracker.ietf.org/ipr/1520/
      华为: https://datatracker.ietf.org/ipr/1712/

      (摘自上面的内容)

      2012 年 9 月 15 日 下午 19:15

  12. Jon

    Skype 可能帮助开发了 Opus,现在是微软的一部分,但微软已经明确表示,他们无意让像 Opus 这样的免版税编解码器与 Web 音频和 RTC 等标准挂钩。 毕竟,这将为真正的互操作性和竞争打开大门。 通过参与标准化组织来虚情假意地支持两者,但只支持少数专有且受专利限制的编解码器,并以模糊、无根据的知识产权问题为由,拒绝支持其他所有人都支持的免版税替代方案,才是更好的选择。 如果我们真的看到 IE 提供对 Opus 的支持,我会感到非常惊讶。

    2012 年 9 月 11 日 下午 17:37

    1. Timothy B. Terriberry

      我知道默认假设是微软会阻碍免版税编解码器的进展,但参与微软 WebRTC 标准化工作的人员在邮件列表中公开支持将 Opus 设为强制实施的编解码器。

      http://www.ietf.org/mail-archive/web/rtcweb/current/msg05075.html
      http://www.ietf.org/mail-archive/web/rtcweb/current/msg05080.html
      http://www.ietf.org/mail-archive/web/rtcweb/current/msg05081.html

      2012 年 9 月 11 日 下午 17:46

  13. ferongr

    太可惜了,谷歌在 Chrom* 中实施对它的支持方面行动迟缓,而很明显他们并不缺乏人力来实施他们像 iSAC 和 webP 这样的“不是我发明的症候群”替代方案。 crbug.com/104241 被标记为“不会修复”,根据评论,Opus 支持“不是优先事项”。

    2012 年 9 月 11 日 下午 18:30

    1. Jean-Marc Valin

      谷歌在开发期间(例如在测试中)一直非常支持,并且公开表示他们更喜欢 Opus 而不是 iSAC。 这里没有“不是我发明的症候群”的问题。 Webrtc 中只是有很多事情要做。

      2012 年 9 月 11 日 下午 20:48

  14. user

    没有 Linux 下载。 :-(

    2012 年 9 月 11 日 下午 18:30

    1. Shmerl

      许多发行版已经包含它(例如在 Debian 上搜索 opus-tools 和 libopus)。 当然,你也可以编译源代码。

      2012 年 9 月 11 日 下午 18:43

    2. Timothy B. Terriberry

      有源代码:)。 相比于为所有 Linux 版本提供二进制文件,与他们的维护人员合作,将 libopus 和 opus-tools 打包成任何其他 Linux 软件,是更好的时间利用方式。 即使是 wheezy 中的稍微旧一点的版本 (http://packages.debian.org/wheezy/libopus-dev) 也应该可以正常工作。

      2012 年 9 月 11 日 下午 18:47

  15. David Piepgrass

    这听起来好得令人难以置信。 如何才能创建一个新的编解码器,同时在给定比特率下降低延迟并提高质量,超过所有流行的竞争对手,而且没有侵犯任何专利? 除此之外,它如何在如此广泛的比特率范围内工作? 我期待看到对此的解释(你知道,不是过于深奥的解释,适合我们这些只掌握基本霍夫曼编码和 FFT 的人)。 它是否使用了许多不同的技术,比如 7-zip,或者尽可能简单统一?

    2012 年 9 月 11 日 下午 18:37

    1. Robert O’Callahan

      这是可能的,因为 Opus 开发人员非常棒:-)。 但是的,如果有人能以易于理解的方式描述 Opus 的技术进步,那将很酷。

      2012 年 9 月 11 日 下午 19:24

      1. Timothy B. Terriberry

        我们已经将 Jean-Marc 在 LCA 2012 上的演讲上传到了 http://www.opus-codec.org/presentations/
        希望我们很快就能在该页面上提供我最近关于 Opus 的其他一些演讲。

        还可以参考我 2009 年在 LCA 上关于 CELT 的旧演讲,网址为 http://www.celt-codec.org/presentations/
        虽然该演示文稿中的许多细节不再准确,但总体思路没有改变。

        2012 年 9 月 11 日 下午 19:39

    2. Jean-Marc Valin

      我对“这怎么可能”的非技术性答案是,我们实际上有很多开发者有兴趣 *共同* 创造最好的编解码器。 这不是关于在标准中塞进尽可能多的专利,也不是关于遵循关于应该和不应该做的事情的非常官僚化的要求。 我们有一些要求,但我们也尽力在不发生冲突的情况下超出这些要求。 一旦你摒弃了“这都是关于把你的专利放进去”的想法,你会惊讶于你能取得怎样的成就。 这是我唯一的解释,因为有很多聪明的人在研究 MPEG/ITU 编解码器,看到他们的成果(嗯,这对 Opus 来说是好事)真是太可惜了。

      2012 年 9 月 11 日 下午 20:44

    3. David Piepgrass

      我仔细阅读了 RFC,但技术细节难以理解……例如,关于范围编码的介绍应该解释 fl[k]、fh[k] 和 ft 代表什么(以及 [k] 是什么,数组下标?),他们不应该等到 4.1.3.3 节才介绍概率密度函数的概念,因为它似乎是一个基本的概念……

      ……总之,Opus 基本上是两种编解码器合二为一:一种用于语音的线性预测 (LP) 编解码器(基于名为“SILK”的独立编解码器)和一种用于音乐的基于 MDCT 的编解码器(基于名为“CELT”的独立编解码器)。Opus 编码器可以根据比特率和输入的主要特征在任何时候即时无缝地在两种编解码器之间切换,并且还存在一种混合模式,其中 SILK 用于低频,而 CELT 用于高频。

      CELT 基于与其他现代编解码器(例如 Vorbis)相同的听觉心理声学原理,但添加了创新,可以在不影响整体音频质量的情况下实现低延迟。SILK 专为低带宽和低延迟语音而设计(尽管它背后的原理对我来说仍然完全不透明),而 CELT 更适合高带宽音频(音乐、语音或任何其他内容),但当声音不是语音或类似语音时,仍然可以在非常低的比特率下运行,因此不适合 SILK。

      Opus 的操作模式设计为使两种编解码器“完美融合”,它可以在 10 毫秒边界上在两种编解码器之间切换(采样范围也可以在 8/12/16/24/48 kHz 之间更改,单声道/立体声也是如此)。Opus 还提供其他实时和 VOIP 功能,例如 CBR 和前向纠错以及其他补偿数据包丢失的技巧。

      Opus 的一些最终优点:编码器和解码器可以在独立的采样率下运行(或者一个可以是单声道,另一个可以是立体声),并且(连续可变的)比特率与操作模式无关(例如,想要 48 kHz 立体声,比特率为 8 kbps?这可能不是一个好主意,但没有被完全禁止)。所以基本上 Opus 涵盖了几乎所有场景。确实是所有编解码器的终结者。

      (如果我对任何内容有误,请指正,亲爱的专家们)。

      现在我能不能得到一个编解码器,它可以通过观察长期的音频模式并对过去几秒钟内类似音频进行反向引用来实现非常低的比特率?谢谢你了 :)

      2012 年 9 月 12 日 14:23

      1. Jean-Marc Valin

        现在我能不能得到一个编解码器,它可以通过观察长期的音频模式并对过去几秒钟内类似音频进行反向引用来实现非常低的比特率?

        这仍然是一个研究课题,我最后一次听说的时候,我们还没有接近使用这种方法的实用编解码器。你可能想搜索的主题是稀疏过完备基函数之类的东西。

        2012 年 9 月 15 日 20:21

    4. Ryan

      去看看维基百科文章上的第一张图片。大多数现代编解码器都支持一系列比特率。大多数要么针对归档/下载音频,要么针对实时/流式/VoiP。

      Opus 只是将两种最佳编解码器结合在一起,使它能够支持有损压缩音频的整个有用比特率范围。它通过某种复杂性来实现这一点,但复杂性的优势在于它将所有内容统一到一个单一标准中,该标准适用于大多数用例,并且只有一个名称。

      这不是魔法,只是基于现有的知识和研究,感谢像 xiph.org 这样的人(以及不感谢像高通和华为这样的巨魔)。

      2012 年 9 月 15 日 19:35

  16. Dave Haynie

    这是 2012 年还是 1992 年?一个全新的音频 CODEC 规范,它构建在 48kHz 的限制之上?现在廉价的袖珍录音机支持 96kHz 的 24 位音频,更高质量的音频标准(如蓝光)正在扩展到 192kHz,这似乎非常复古。即使 AAC 也支持高达 96kHz 的采样率。

    对低延迟和从语音到“CD 质量”的扩展表示赞赏。但并非适合所有情况。

    2012 年 9 月 12 日 05:00

    1. Monty

      > 48kHz 采样本身就是一个过时的过时事物。Opus 不支持 > 48kHz 采样的原因是因为这不是 1982 年。96kHz 在 1992 年就已经没有必要了。

      问题在于,消费者(以及许多专业用户)没有意识到高采样率是为了克服早期 DAC 的技术局限性而产生的。在这种情况下,越大并不意味着越好。

      请查看
      http://people.xiph.org/~xiphmont/demo/neil-young.html

      2012 年 9 月 12 日 05:11

    2. Leon

      不要被音频发烧友愚弄…… :)
      人类无法听到 20Khz(48Khz 采样率)以上频率。我亲自测试过,我只能勉强分辨出监听耳机上的 19Khz 测试音,而我今年 27 岁了。
      因此,在有限的比特率上浪费比特到更高的频率只会降低音频质量,因为这些比特本来可以分配到我们真正能听到的频率上。
      48Khz/16bit 是我们播放音频所需要的全部。

      2012 年 9 月 13 日 07:07

      1. David Piepgrass

        人类可能无法听到 21 kHz,但为什么我不能录制和播放狗哨?或者,音频遥控器呢?

        我听说 Opus *总是* 会切断 20kHz 以上的所有内容。但由于 128kbps 以上的所有内容可能与 FLAC(对于人类来说)无法区分,因此似乎非常高的比特率流(400kbps?!)应该真正编码到 24kHz(48kHz 输入的基本限制)。

        2012 年 9 月 13 日 08:53

        1. Bob H

          我记得的采样理论说,不滤除低于一半采样率的信号会引入一些失真,我不知道选择数字 20 的原因,但我认为应该有一个低于 24kHz 的滤波器,并且应该应用一个关于采样率与低通滤波器的公式。

          2012 年 9 月 13 日 09:18

          1. David Piepgrass

            你的记忆不正确。不滤除 *超过* 一半采样率的信号会引入一些失真;例如,我认为以 48kHz 采样的 32kHz 信号会输出为 16kHz 音调。假设设备良好,22kHz 音调在 48kHz 下播放时不会失真。Opus 只在 20kHz 处截止,因为人类听不到 20kHz 以上的声音。

            2012 年 9 月 13 日 10:57

        2. Ryan

          就像软件中的所有事情一样,每个额外的功能都会带来额外的复杂性,而复杂性会使事情最不济更难优化,最坏的情况下无法优化。

          Opus 针对现实世界进行了优化(在现实世界中,使用有损编解码器录制狗哨非常罕见)。我相信你可以使用 FLAC 来处理几秒钟的狗哨录音。或者你打算和你的狗进行实时聊天吗?或者你可能打算录制一张针对狗类市场的民谣专辑,并且会因为强迫他们选择大文件大小或听不见的狗哨而惹恼狗狗顾客?

          2012 年 9 月 15 日 19:55

    3. Bernd

      每个利用听觉心理声学的有损音频格式背后的基本理念是通过仅保存可听声音特征并“省略”我们听不到的东西来降低比特率。实际上使用的每种有损编解码器都是为人类设计的。保存 20 kHz 以上的频率违背了这一基本理念。迄今为止,还没有科学证据证明存在能听到 22 kHz 以上声音的人类。使用 FLAC 或开发一种特殊的狗类编解码器来服务你的狗狗。

      2012 年 9 月 14 日 07:43

  17. Anthony “Airon” Oetzmann

    Valve Software 的游戏 DOTA 2 使用 CELT,它是 Opus 的一个子集,用于其语音通信系统。

    该游戏处于测试阶段,但已经举办了两次国际锦标赛,并且拥有超过一百万玩家。

    2012 年 9 月 12 日 05:05

  18. Anthony “Airon” Oetzmann

    关于 48kHz 限制的说明,来自一位音响工程师的观点。

    96kHz 有损媒体没有必要。

    没有人会录制有损的 96kHz 媒体,也没有任何专业的音响师会想用它来进行那些使用 96kHz 甚至 192kHz 采样的应用,通常是效果现场录音和管弦乐录音。

    以 96kHz 无损压缩格式录制已经成为现实。我的 Sound Devices 722 可以录制 FLAC 格式,例如。它也可以录制 MP3 文件,但除了语音之外,没有人会用它来进行现场录音,当然也不会在 96kHz 的素材上浪费带宽,即使这有可能。

    没有人会用超过 48Khz 的有损压缩。根本没有这样的应用。

    2012 年 9 月 12 日 05:13

  19. Bob H

    和所有新的编解码器一样,我看到:有人检查过硬件支持的可能性吗?它能很好地优化音频 DSP 吗?或者它只是一个 x86 小众市场?

    2012 年 9 月 12 日 05:23

    1. Timothy B. Terriberry

      它的许多操作专门用 DSP 上速度快的东西来编写(例如带符号的 16×16 定点乘法),并且大量的定点宏可以用单个 ARM 指令替换。我们积极减少内存使用量,包括暂存缓冲区和 ROM,使其能够在极度有限的设备上运行。最昂贵的部件是 MDCT 之类的东西,我们专门将其隔离,以便可以轻松地用针对特定 DSP 的自定义实现进行替换(我知道至少有一人利用了这一点,在移植到 TI C55x DSP 时)。我们关心的事情远不止 x86。

      2012 年 9 月 12 日 05:31

      1. Bob H

        太棒了!

        2012 年 9 月 12 日 06:39

  20. Derrick Coetzee

    我对这项进展感到非常兴奋 - 一种可以跨比特率平滑缩放质量的编解码器的理念开辟了各种新颖的应用(例如,将一组给定的音频文件压缩到刚好适合固定存储空间,或根据可用带宽和参与者数量实时调整质量的音频会议)。

    我有一个关于测量的疑问:许多窄带/宽带编解码器专门针对语音进行了优化,因此对于音乐、动物声音、噪音等,它们的质量会大幅下降。Opus 在这个范围内对非语音音频的质量是否也会下降?或者它在非语音音频上的表现比语音编解码器更出色?

    2012 年 9 月 12 日 06:03

    1. Jean-Marc Valin

      当你达到低比特率(<32 kb/s 单声道,<48 kb/s 立体声)时,音乐质量开始下降,这是不可避免的。话虽如此,我认为 Opus 在处理低比特率音乐时仍然比其他语音编解码器好。但在这一点上,这已经没有那么重要了,因为(至少在我看来)质量已经不是人们认为可以接受的水平了(所以“糟糕”和“非常糟糕”没有区别)。

      2012 年 9 月 12 日 07:17

      1. Ryan

        蜂窝通信仍然受到带宽限制,许多服务提供商直接根据带宽消耗量来收取费用。许多人,甚至整个国家,常常没有足够的带宽(人均)来可靠地以 48kb/s 的速度进行流式传输。

        举个例子,当我用 Skype 打电话给东南亚时,动态比特率协商使通话流畅且可用,而 Google Voice 几乎毫无用处。

        性能特征改变了技术如何(或不能)使用的整个游戏。 细微的低质量音频比不可用的产品更“可接受”。 20 人可以同时通话的网吧比 2-3 人占用所有带宽的网吧更“可接受”。

        你的陈述可以改述为

        “我是一个受保护的西方消费者,拥有千兆宽带连接和 8 核 CPU - 那些关于嵌入式 CPU 和第三世界互联网的噪音都去死吧。”

        2012 年 9 月 15 日 下午 8:19

        1. Jean-Marc Valin

          不,我的意思是,如果我只有 20 kb/s(在任何西方国家拥挤的网络中都会发生这种情况),那么我宁愿不听音乐,也不愿听到被严重破坏的声音听起来像噪音的音乐。 与语音(无论如何可以用更低的比特率编码)不同,音乐很少是必需品。

          2012 年 9 月 15 日 下午 8:44

          1. 有没有可能为 Opus 解码器开发一个去抖滤波器? 我确实觉得即使是 20 kbit/s 也可以接受。

            2012 年 9 月 16 日 上午 1:27

          2. Jean-Marc Valin

            你能告诉我们如何实现一个去抖滤波器吗? 看起来它应该也能以 1 kbit/s 达到良好的质量。

            2012 年 9 月 16 日 上午 10:22

          3. 有人忘记关闭这篇文章的评论功能了。:) 所以我回复一下。

            > 你能告诉我们如何实现一个去抖滤波器吗?
            不行 - 这就是我问的原因。
            > 看起来它应该也能以 1 kbit/s 达到良好的质量。
            呃,等等,你刚刚使用时间机器来更改 Opus 规范了吗? 无论如何,在那个比特率下,这种滤波器可能会将信号变成白噪声。 不过,仍然比颤音更令人愉悦!

            2012 年 9 月 16 日 上午 11:32

  21. Jonadab

    > 使用低比特率 Opus 可能产生 3 MB 的文件
    > 对于一首歌,而 FLAC 可能最终会成为
    > 同样音频的 150 MB。

    是的,让我们澄清一下

    使用极低的比特率(没有人会在现实世界中使用),Opus 可能为一首歌产生 3 MB 的文件,但它听起来像是锅碗瓢盆在烘干机里转来转去。 使用稍微合理的比特率,它可能会产生一个 40 MB 的文件,如果你不挑剔,你可能还能忍受听。 如果你正在听本来就嘈杂的音乐(例如金属乐),你可能甚至听不到压缩伪像。 如果这里的说法属实,它听起来会比等效的 40 MB MP3 或 Vorbis 文件好一些。

    FLAC 对于同一首 30 分钟的交响曲(我不太愿意把这么大的东西称为“歌曲”)可能最终会达到 150 MB,但它听起来会 *完全* 像你从 CD 中翻录的版本一样(假设你的播放器有足够的处理器周期来实时解码它,这在现代系统上应该不是问题,除非你在后台尝试编译一半的 CPAN,同时还用大量反射表面和大气效果对电影海报大小的图像进行光线追踪)。

    Opus 不是 FLAC 的合适替代品。 它 *可能* 是 MP3 和 Vorbis 的合适替代品,但坦率地说,我不使用这两种编解码器,因为有损音频是不可取的。 存储空间的成本大约是每 GB 十美分。 在九十年代,我可以想象可能有一些使用有损压缩的场景。 今天,我做不到。

    对我来说,任何新的有损音频编解码器本身就是一种寻找问题的解决方案。 即使是现在的基于 Flash 的便携式音乐播放器也可以存储比它们电池寿命允许你实际播放的更多无损内容,然后再插电充电。 那么,有损格式有什么用呢?

    2012 年 9 月 12 日 下午 1:39

    1. Derrick Coetzee

      除了涉及音频传输(如流媒体、电话会议等)的用例之外,我认为有损音频编码在音乐播放方面仍然有一席之地——很多人喜欢将他们的整个收藏保存在他们的设备上,以便他们可以按需选择任何歌曲。 对于有损格式,该收藏可以大 5 倍,而不会造成任何明显的音质损失。 诚然,你可以在 64 GB 的 SD 卡(而且便宜的慢速卡就足够了,因为有缓冲)上放置一个相当大的 FLAC 收藏,但越大越好。

      2012 年 9 月 12 日 下午 2:26

    2. David Piepgrass

      一首 150 MB 的 FLAC 歌曲可能大约 30 分钟长,未压缩时略高于 300 MB,假设 48KHz 立体声。 所以是的,要达到 3 MB,你需要 100KB/分钟或 13kbps 的比特率,这不可能是 48kbps 或立体声的。 但如果你使用 130kpbs(30 MB,10:1 压缩),大多数人听不出它与 150 MB FLAC 的区别。 而且,如果听力测试有任何指示,对于典型的糟糕硬件,我预计许多人无法区分 65kbps(15 MB,20:1)和 FLAC。

      2012 年 9 月 12 日 下午 2:46

    3. Ryan

      实时通信,当带宽受限时至少 *可用*,而带宽充足时质量良好。

      降低移动数据费用(对于单个消费者和服务提供商的总量而言)。 有些人没有高速互联网的奢侈品,有些人甚至在家里也依赖于“移动”互联网。 有些提供商在某些地区的利润率很低或带宽有限。

      电话、采访、语音分析语料库等的档案存储,这些数据可能达到 TB 级甚至更多(如果镜像和备份,可能还会增加很多倍)。 1TB 和 10,000TB 之间的区别在于你可以拿起并携带的东西和有固定地址的东西之间的区别。

      因为成本很重要,维护很重要,带宽很重要,而需要镜像和冗余的应用程序会放大所有这些因素。

      所以你有一个音乐收藏,并享受高质量的音频。 这对你来说绝对很棒。 但是,你真的 *那么* 受保护和目光短浅,以至于你看不到其他许多用例,在这些用例中,质量只是次要问题吗?

      2012 年 9 月 15 日 下午 8:46

  22. roger

    由于它被宣传为“Speex 替代品”http://code.google.com/p/chromium/issues/detail?id=104241 这是否意味着……它也将内置 AGC/AEC/降噪? :) 只是想知道……

    2012 年 9 月 12 日 下午 2:40

    1. Timothy B. Terriberry

      AGC/AEC/抖动缓冲区等是 libspeexdsp 的一部分,与 Speex 编解码器本身没有直接关系。 它们仍然可以与 Opus 一起使用。 libopus 编码器确实包含一个高通滤波器(在针对 VoiP 应用程序时启用),这有助于消除呼吸噪音,因为它在该级别包含它是合理的,但我们预计大多数人会提供他们自己对这些工具的其余部分的实现(即使他们只使用 libspeexdsp 中的工具)。 对于 WebRTC,我们正在使用来自 http://www.webrtc.org/ 的代码。

      2012 年 9 月 13 日 上午 4:40

  23. Bill

    怎么说呢?
    感谢,感谢所有使这一切成为可能的人。
    这是一个好消息。

    2012 年 9 月 13 日 下午 12:49

  24. Teg

    有人提到 Opus 在 Debian 仓库中,但它也将在即将发布的 Ubuntu 12.10 (Quantal) 版本中,即使它是一个旧版本

    http://packages.ubuntu.com/search?keywords=opus&searchon=names&suite=quantal&section=all

    2012 年 9 月 13 日 下午 5:32

    1. Jean-Marc Valin

      据我所知,他们正在发布 0.9.14,这与 RFC 中的代码完全相同。

      2012 年 9 月 13 日 下午 9:32

  25. Omega X

    比特率有错别字

    比特率为 6 kb/s 到 510 kb/s

    不是 512。

    2012 年 9 月 14 日 下午 4:02

    1. Gonewest

      如果如上面所述,压缩伪像在 128kb/s 时是“透明”的,为什么还要支持 510kbps?

      2012 年 9 月 14 日 下午 5:15

      1. 可能是留有余地。 在那个阶段,人们还不知道 128kbps 在大多数样本中将是透明的。

        2012 年 9 月 14 日 下午 10:52

      2. Jean-Marc Valin

        好吧,首先要记住的是,为了以 *平均* 128 kb/s 的速度实现“近似透明”,Opus 需要能够以高达 256 kb/s 的速度对一些短段(例如瞬态)进行编码。 从那里到 512 kb/s,当你真正想要确保实现透明度时,它只是一点点余地。

        2012 年 9 月 15 日 上午 0:16

        1. 拼写检查器

          实际上是 510 而不是 512。 请修改文章。

          2012 年 9 月 15 日 上午 10:52

          1. Greg Maxwell

            从技术上讲,较小的帧持续时间可以产生远大于 512kbit/sec 的速度。 它不会有效地使用比这更高的速率,但你可以在任何持续时间内产生 1275 字节的帧。 说 512 对比 510 的人并不准确。 有效最大值取决于内容,并且非常接近这两个数字中的一个。

            2012 年 9 月 15 日 下午 8:07

          2. 拼写检查器

            我不能回复 Greg,没有回复按钮。

            我理解你们的意思,从“客户/用户”的角度来说,我并不关心。 http://www.opus-codec.org/http://tools.ietf.org/html/rfc6716 显示了从 6kbps 到 510kbps,在其他任何地方输入任何不同的内容都是不正确、不准确或不连贯的。 我和其他许多人希望看到,尤其是从你这里,因为你做出了重大贡献,一篇好的、精确的文章,就像这两个“标准”网站一样。

            谢谢。

            2012 年 9 月 18 日 下午 8:03

  26. Richard M Stallman

    为 Opus 欢呼三声!

    要成为一个自由标准,它不仅需要开放——人们
    必须有权自由实现它。 我很高兴听到 Opus 似乎
    不受专利的影响。

    谈到专利时,我敦促人们避开过于宽泛的术语
    “IP”。 这个词将专利法与十几个
    不相关的法律(包括版权、设计专利、商业秘密、
    商标、地理产品名称、宣传权、IC 掩模
    垄断、植物品种垄断和药物实验数据
    排他性)。 为什么随意含糊其辞,当你可以说“专利”
    并且准确、清晰?

    参见 https://gnu.ac.cn/philosophy/not-ipr.html.

    2012 年 9 月 16 日 上午 11:50

  27. Manu

    好的,看起来你开发了一个很棒的编解码器,但请澄清:对于音乐编码(特别是艺术音乐,包括现代音乐,如克塞纳基斯的、贝里奥的、斯凯尔西的等等,包含了所有电子乐部分、微音程、音簇等等)来说,Opus 比使用 Aotuv 的 OGG 更好吗?特别是高比特率(我通常以 256kbps,q 8 编码)。

    我所阅读的关于 Opus 的所有内容都集中在其在互联网和低比特率下的应用,但它可以替代 OGG 吗?

    谢谢并致意

    2012 年 11 月 29 日 下午 08:07

  28. Derrick Coetzee

    @Manu:根据质量曲线,在广泛的比特率范围内,Opus 在听力测试中似乎优于 Ogg Vorbis,但在 256kbps 等高比特率下,差异可能非常小,甚至完全无法察觉(当然不会更差)。我的建议是下载编码器,在您最常听的一些音乐上尝试一下,看看您是否能在最好的设备上听到差异。虽然可能没有可感知的质量差异,但可能存在可观的压缩率差异,尤其是在您使用 VBR(Opus 的压缩效果往往更好)时。

    当前软件支持:最新版本的 VLC (2.0.4) 和 Firefox 已经支持播放。如果您在 Windows 上安装 DC-Bass Source Mod(参见 http://forum.doom9.org/showthread.php?t=164200),您将获得一个 Opus DirectShow 滤镜,可以在 Windows Media Player 中播放。iTunes 不太可能支持,但 Banshee 和 Songbird 等开源播放器可能会很快获得支持。

    2012 年 11 月 29 日 下午 15:12

  29. Derrick Coetzee

    补充上面的一点:foobar2000 也支持 Opus,并且目前是唯一一个我可以找到的用于添加标签的应用程序。在 foobar2000 中,将标签从一组 FLAC 文件转移到一组 Opus 文件非常简单(参见 http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:How_to_transfer_tags_between_two_sets_of_tracks)。

    2012 年 11 月 29 日 下午 15:37

  30. Mick

    很棒的工作。我喜欢 Opus 那样将功能统一起来。提出这个建议可能不受欢迎,但对我来说,一个完美的音频编解码器应该是可以处理所有事情的:像 Opus 一样的有损压缩,像 FLAC 一样的无损压缩,以及未压缩音频。一个音频编解码器统治所有...

    2013 年 3 月 12 日 上午 04:35

这篇文章的评论已关闭。