短篇故事：
如果我自己打算接收然后发送由我的应用程序处理的 Shoutcast 兼容的音频流，那么如何使用 mp3（de/en）编码器库正确地做到这一点？伪代码或更好的 - 蹩脚的 mp3 特定代码将不胜感激。
很长的故事：
困扰我的更具体的问题是由一篇关于 mp3的文章引起的，该文章说：
通常，框架是独立的项目。每个帧都有自己的标题和音频信息。没有文件头。因此，您可以剪切 MPEG 文件的任何部分并正确播放（这应该在帧边界上完成，但大多数应用程序会处理不正确的标题）。对于第三层，这不是 100% 正确的。由于 MPEG 版本 1 第 III 层文件中的内部数据组织，帧通常是相互依赖的，不能像那样被切断。
这让我想知道 Shoutcast 服务器和客户端如何处理帧头和帧依赖关系。
如果我想实现与大多数 Shoutcast 播放器的最大兼容性，我是否只需要编码为恒定比特率 (CBR)？
是完全使用 mp3 帧头还是从 Shoutcast 协议特定的 HTTP 头推导出流格式？
Shoutcast 协议是否保证（或者它是常见的良好做法）开始在帧边界上提供 mp3 流并继续响应在帧边界处被剪切的块？但是，用于流式传输实时音频的 mp3 帧的最小或推荐大小是多少？
Shoutcast 如何处理帧依赖关系——它是否对 mp3 编码做了一些特殊的事情，以确保所服务的流没有依赖于先前帧的帧（如果这甚至可能的话）？或者它可能忽略了服务器端/客户端的这些依赖关系，从而降低了音频质量甚至是伪像？