【问题标题】:Strategy for time-indexed audio archive with lossy compression有损压缩的时间索引音频存档策略
【发布时间】:2011-07-05 20:04:37
【问题描述】:

在我的一个项目中,我正在考虑为互联网广播电台开发一个音频档案。该档案将按日期/时间编入索引和寻址。

例如,服务器将连接到流(通常以 MP3 编码),并保存流数据。客户端可以连接到该服务器并从2011-07-05 15:58:30 向2011-07-05 15:59:37 请求音频。服务器会将音频数据返回给客户端进行播放。

我最初的想法是将数据以 1 分钟的原始 MP3 数据块保存到磁盘,并从数据库中引用这些文件。服务器对流/文件格式会很笨,并且不会理解 mpeg 帧。它只是将数据传递给客户端,将数据块线性划分为发送。由客户端同步到流。这与互联网广播服务器的一般运行方式没有什么不同。 SHOUTcast 服务器简单地逐字节地输出从编码器发送给它们的数据。当客户端连接时,无论它是否以 MP3 帧结束,都会发送数据。由客户端来同步。

我想知道是否有更好的方法,最大限度地提高与客户端和音频格式的兼容性。有什么想法可以解决这个问题吗?

我能想到的唯一另一件事是将 MP3 解码为原始 PCM 音频,并在需要时根据需要重新编码。由于所需的磁盘空间以及重新编码时质量的损失,我宁愿不走这条路。

这个问题与语言无关,但如果它有帮助,我可能会在 PHP 中实现一个解决方案,使用 MySQL 作为数据库。

【问题讨论】:

    标签: audio mp3 audio-streaming


    【解决方案1】:

    您不必担心这一点,因为我通过直播访问的所有 mp3 都是恒定比特率。你不必索引它。我有一个 POC 项目,它以 5 分钟的时间块存档,然后使用 PHP 来组合这些文件并通过shoutcast 将其伪流式传输到 winamp。成功了!

    而且由于您使用的是 mp3,您可以假设(并且您会正确假设)捕获文件的密度是线性的,因此要访问 60 秒文件中的 30 秒,您应该在中间寻找。由于 mp3 解码器足够强大,因此您根本不必在此处跟踪帧。

    AACplus,完全不同的故事。它是固有的 VBR。

    【讨论】:

      猜你喜欢
      • 2018-12-05
      • 2019-12-15
      • 1970-01-01
      • 2019-06-26
      • 1970-01-01
      • 1970-01-01
      • 2015-06-30
      • 1970-01-01
      • 2023-03-16
      相关资源
      最近更新 更多