TagLib# (C#) 和 TagLib (C++) 的长度差异

Question

我目前正在将我的 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# 上没有任何问题。

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

在赏金结束之前，有人还有更多想法吗？

Answer 1

您好，taglib 有一个补丁可以计算以毫秒为单位的长度，这个人添加了一个方法（lengthMilliseconds()），它返回以毫秒为单位的长度，也许这对您有用：http://web.archiveorange.com/archive/v/sF3Pjr01lSQjsqjrAC7L

Answer 2

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

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

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

Answer 3

截至撰写本文时，TagLib 1.11 BETA 2 本身支持获取以毫秒为单位的音频长度。您可以使用以下代码来执行此操作：

TagLib::FileRef f(path);
int lengthInMillis = f.audioProperties()->lengthInMilliseconds();