【问题标题】:Concatenate mp3 files in Java在 Java 中连接 mp3 文件
【发布时间】:2014-02-18 08:01:31
【问题描述】:

我在连接 mp3 文件时遇到了一些问题。例如,我有 5 个 mp3 文件。我想将它们连接到一个文件中。

我试试这个:

try {
    InputStream in = new FileInputStream("C:/a.mp3");
    byte[] buffer = new byte[1024];
    OutputStream os = new FileOutputStream(new File("C:/output.mp3",
            true));
    int count;
    while ((count = in.read(buffer)) != -1) {
        os.write(buffer, 0, count);
        os.flush();
    }
    in.close();
    in = new FileInputStream("C:/b.mp3");// second mp3
    while ((count = in.read(buffer)) != -1) {
        os.write(buffer, 0, count);
        os.flush();
    }
    in.close();
    os.close();
} catch (FileNotFoundException e) {
    e.printStackTrace();
}

但这不起作用。我在这个过程结束时得到一个 mp3 文件,它包含来自源 mp3 文件的所有音乐数据,但在选项中我只看到来自第一个源 mp3 文件的 fihish mp3 的时间。而且,当我使用 Xuggle 库将此 mp3 音频添加到 mp4 视频时尝试使用这个最终的 mp3 文件时,我得到了错误。

我敢肯定,每个 mp3 源文件的字节数都有问题,其中记录了元信息。也许存在一些用于正确连接 mp3 的库?

【问题讨论】:

标签: java audio mp3 concatenation xuggler


【解决方案1】:

您的方法存在多个问题。

a.) 如果源文件中有任何元数据,则复制元数据。在连接的文件中,这些元数据(Id3v1 和 Id3v2)将出现多次,更糟糕的是,在它们不应该出现的位置(Id3v1 必须位于文件末尾,Id3v2在 IIRC 的开头)。这会使解码器混淆,将文件识别为已损坏(它可能会播放第一部分,然后在第二部分的意外元数据上打嗝)。

b.) 计算 MP3 的长度并不是那么简单,需要计算文件中 MP3 帧的数量。由于没有标明帧数的标头,因此唯一安全 的方法是按顺序扫描文件(如解码)。在引入 MP3 时,这曾经是一项昂贵的操作,因此引入了多种方法来解决这个问题(VBR 标头块和 Id3 元标记)。如果您的播放器依赖这些,它将始终将长度检测为仅第一部分。

c.) 即使您正确剥离元数据,您也只能使用相同的参数(采样率)连接 MP3 流,某些解码器甚至可能对比特率和类型(单声道/MS/Istereo 等)有额外的限制。 )。

你看,它可以做到,但它不是微不足道的。

【讨论】:

  • 在开头的 ID3v2 标签之后,规范实际上允许在文件中的任何位置出现更多的 v2 标签(作为“更新”)。
【解决方案2】:

您不能以这种方式附加音乐文件。你需要的是一个外部库(蹩脚或......),在java中......几乎是不可能的,JMF已经死了。

【讨论】:

  • 实际上您可以附加 MP3 文件,前提是您剥离或正确处理元数据。
  • 此外,JMF 可能已经死了,但它仍然可以读取 mp3 文件,并且有工作插件可以编写它们。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-07-20
  • 2012-05-13
  • 2010-11-30
  • 1970-01-01
  • 2013-10-23
  • 2018-02-20
相关资源
最近更新 更多