4

我目前正在将我的 C# 应用程序转移到 Qt/C++。我遇到了来自 TagLib 的长度问题。我觉得奇怪的是 TagLib# 以毫秒为单位返回音频持续时间,而 TagLib 以秒为单位返回其(不正确的)持续时间。TagLib 只为长度值返回,而 TagLib# 保持正确。

这是我在 C#/TagLib# 中的源代码...

TagLib.File tagfile = TagLib.File.Create(path);
uint milliseconds = (uint)tagfile.Properties.Duration.TotalMilliseconds;

这就是 C++/TagLib 中应该几乎等价的内容。我什至强迫它准确地阅读。没有成功。

TagLib::FileName fn(path);
TagLib::FileRef fr(fn, true, TagLib::AudioProperties::Accurate);
uint length = fr.audioProperties()->length();

它对我的大部分媒体文件都按预期工作。但是,少数音频文件无法返回任何音频属性(标签信息的其余部分可以正常读取!)。在 TagLib# 上返回完全相同的音频属性,没有问题。

任何想法表示赞赏。谢谢。

在赏金结束之前,有人还有什么想法吗?

4

3 回答 3

6

嗨,taglib 有一个以毫秒为单位计算长度的补丁,这个人添加了一个以毫秒为单位返回长度的方法 (lengthMilliseconds()),也许这对你有用:http: //web.archiveorange.com/archive /v/sF3Pjr01lSQjsqjrAC7L

于 2010-12-02T20:18:24.493 回答
3

自最初移植以来,TagLib# 对音频文件的解析发生了很大变化,因此很难说具体会发生在哪里。您可以检查您的 C++ 程序是否有调试消息。

我的猜测是这两个库对无效标题的反应方式不同。看来,如果它找到的第一个帧头无效,TagLib 将不会计算任何音频属性值。另一方面,TagLib# 在文件的音频部分的前 16KiB 中查找第一个有效标头。如果它遇到的第一个标头已损坏,它将扫描下一个标头。如果我没记错的话,错误保存的 ID3v2 标签可能会导致 0xFF FF FF FF 出现在文件的音频部分的开头。这将触发上述故障类型。

问题出在 taglib/mpeg/mpegproperties.cpp 的第 166 行。这可以使用与第 171 到 191 行相同的方法来解决,但您可能需要更新代码以在某个点后放弃,以防它真的不是 MP3 文件。

于 2011-07-24T16:13:59.807 回答
1

在撰写本文时,TagLib 1.11 BETA 2 原生支持以毫秒为单位获取音频长度。您可以使用以下代码执行此操作:

TagLib::FileRef f(path);
int lengthInMillis = f.audioProperties()->lengthInMilliseconds();
于 2016-11-16T02:59:27.767 回答