获取当前播放歌曲的开始和结束时间答案

【问题标题】：Get start and end time of current playing song获取当前播放歌曲的开始和结束时间
【发布时间】：2012-04-20 11:18:54
【问题描述】：

我正在尝试在 android 中实现无线电流切换器。我想做的事情，按照想要的顺序，是这样的：

开始播放广播电台
从该电台获取当前播放歌曲的结束时间
在 endTime - Delta 时，我想扫描一个电台列表，我想返回一个在区间 [endTime, endTime + Delta'] 内有新歌开始的电台列表
从 [3] 中的结果集切换到流，然后重复

所以，我可以播放广播电台（没问题）。我可以在歌曲更改时收到通知（使用streamscraper 获取元数据并在元数据更改时生成通知）。但是，我无法找到的是是否可以执行以下操作：

获取当前播放歌曲的结束时间
扫描电台列表，并获取大约在同一时间开始的歌曲（因此获取歌曲的 startTime）或可能即将开始的歌曲（如果这些流中当前歌曲的 endTime 接近或者我实际上可以获得提前播放流节目）。

如果有人能告诉我这是否可能，我将不胜感激。

【问题讨论】：

标签： shoutcast internet-radio

【解决方案1】：

我能够用 SHOUTcast 做类似于您所说的事情。我不确定 Icecast 的日志文件是如何格式化的，但我可以使用 PHP 来查看“Song Change”事件的日志。

一旦您能够这样做，您就可以根据需要执行代码。如果您想知道标题播放的时长，您可以在歌曲更新时启动计时器，并在歌曲再次更改时停止。

这有点棘手，但确实有效.. www.soundcheck.xyz - 自动将当前播放的歌曲实时发布到 Twitter。

【讨论】：

【解决方案2】：

流由 mp3 的无缝流组成这就是流的作用……它将单独的 mp3 拼接到一个大流中。

但是流中有跟踪 ID 标记...如果您能找到结束并从它们开始，则不 shure 或者如果它们恰好在轨道起点或其他固定位置开始。

大多数电台不会提前发送有关下一首曲目的信息只是因为他们不知道，大多数使用服务器必须决定的自动 dj 播放列表在新旧曲目之间的短暂休息中，新曲目将是什么即：它不会在播放旧曲目时做出决定。

有些电台确实会发送信息（PHP 到他们的网页）下一首曲目将是什么但大多数人不...如果他们这样做，那么这些信息肯定不在流本身中。

也许一个技巧可能是为您的听众添加延迟
即：听众当前听到的内容
是旧的（最多几分钟或 1 个完整的曲目）

不知道如何创建这样的延迟...也许您需要记录（缓冲）它
并延迟播放（在您的应用中或通过其他服务器）

您的（未延迟的）应用程序将（希望）在当前歌曲结束时通知
因为一个新的以新的 ID2/3 标签开始...当他当前但延迟的歌曲结束时，它会将您的听众切换到新的流。

说不同...在您的应用程序向前看的表面之下（相对于侦听器）

您需要学习 Shoutcast 和 ID-tag 协议。额外的静音检测也可能有所帮助（不是万无一失的）。

可能并不总是有效..有些电台不发送 ID 标签其他人淡入淡出他们的曲目（没有沉默）......正是为了避免这些技巧。

或者类似的东西......祝我好运，我不会编写任何代码......这只是理论我怀疑一些广播开膛手会使用这个技巧……我想他们会使用这个扫描多个流（并行）以查找某些预设的艺术家曲目。也许您可以通过对这些裂土器进行逆向工程来获得一些想法。因为我自己有一台收音机，所以我不喜欢这些把戏，因为他们偷了我当我为版权付费时....许多开膛手会扼杀在线广播。

最后我不认为你的想法（如果我很好地理解它的目的）有用
每下一首曲目从一个流切换到另一个流似乎不是一种享受的体验。
好的广播电台将有一个精心制作（订购）的播放列表
如果你搞砸了，你的听众会在很短的时间内得到很多情绪/风格的变化。

这样做的唯一有用的目的可能是构建一个自动开膛手可以分散预设曲目/艺术家对平行观察的众多流的注意力并在播放想要的曲目时记录它们...对于许多在线电台来说，这些开膛手已经是一个大问题，还有 10 个以上的开膛手和在线广播已经死了...结果高质量和独立的音乐将不再可用...我们将只能使用 Youtube 和其他金钱出没的企业集团..我不期待那个..好奇你是否还有其他有用的目的。

【讨论】：

通过 HTTP 的连续 MP3 流不包含 ID3 标签。如果他们这样做了，音频就会损坏。自动 DJ 应用程序和脚本不会盲目地将 MP3 文件连接在一起……它们必须将流拼接在一起。有些人甚至重新编码音频（因为这比处理比特库问题要容易得多）。
@Brad: Mp3 不包含 iD3 标签……如果他们这样做了，音频会损坏……当然那不是真的……他们确实包含 iD3 标签……只是作为 mp3 流也包含 iD3 标签。
你误引我了。我说，“通过 HTTP 的连续 MP3 流不包含 ID3 标签。”我向你保证，这是真的。如果你不这么认为，我建议提供证据。为了澄清我的意思，我不是在谈论通过 HTTP 简单地加载 MP3 文件。我说的是类似广播的流。
是的布拉德 ...我自己有一个 MP3 格式的广播电台流，这是迄今为止最常用的..它包含 iD3 标签和其他东西/信息...如果我们谈论电台流，我们通常指这种流。这是一对一的副本：“SHOUTcast 软件使用客户端-服务器模型，每个组件通过网络协议进行通信，该协议将音频或视频数据与元数据（如歌曲标题和电台名称）混合在一起。它使用 HTTP 作为传输协议。”来自这个 wiki 页面：en.wikipedia.org/wiki/SHOUTcast 这是否符合您的证明标准？
SHOUTcast/Icecast 流正是我所说的，我向你保证它们不包含 ID3 标签。查看此类流的任何数据包跟踪，您将找不到 ID3 标记。 SHOUTcast/Icecast 流可以包含的唯一元数据是 SHOUTcast 元数据本身，它会定期插入流中。其他任何内容都直接发送到不理解 ID3 的 MPEG 解码器。

【解决方案3】：

这是不可能的。在停止播放之前，您无法知道正在播放的内容的结束时间。数据不存在，甚至不适用于所有流。（想想现场节目、DJ 混合节目、交叉淡入淡出的起点/终点等）

【讨论】：

谢谢你。我现在有另一个理由来进一步解释我无法实现此功能。干杯。