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

嗨，标签库有一个补丁，用来计算长度(毫秒)，这个家伙添加了一个返回长度的方法(lengthMilliseconds())，以毫秒为单位，也许这对你有用：http://web.archiveorange.com/archive/v/sF3Pjr01lSQjsqjrAC7L

Answer 2

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

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

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

Answer 3

在撰写本文时，TagLib 1.11beta 2本机支持以毫秒为单位获取音频长度。您可以使用以下代码来完成此操作：

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