MediaElement.NaturalDuration小于音频的实际持续时间
在某些音频文件上，MediaElement.NaturalDuration的值小于音频的实际持续时间。当我在Windows Media Player中打开文件时，持续时间是正确的（当我查看文件的属性时）。虽然NaturalDuration属性的值不正确，但音频完全播放，但在某些时候，Position属性的值变得大于NaturalDuration属性的值，据我所知，该属性不应该发生。MediaElement.NaturalDuration小于音频的实际持续时间
我创建了一个简单的应用程序来重现问题：https://skydrive.live.com/redir?resid=ACF8BFD4384116CE!2908&authkey=!AG-wF6Ae-7EAYk8
应用程序中使用的音频文件的持续时间是0点02分54秒，但NaturalDuration属性的值是00:01:59 。
有谁知道为什么，如果有解决方法吗？
在此先感谢您的帮助。
好的，这不是一个答案，但一些短的调查结果给出了一些线索为什么它的行为和那些数字来自（2:58和1:59）。首先看这个线程：Calculating the length of MP3 Frames in milliseconds，我们将在那里使用 两件事情：
1）帧的长度（毫秒）=（每帧/采样率样品（以Hz））* 1000，和
持续时间在秒=帧长度（毫秒）*帧的数量/ 1000
2）有关于用于不同的MPEG版本的样本数一些标准：每帧 样品：
MPEG版本1
384, // Layer1
1152, // Layer2
1152 // Layer3
MPEG 2版& 2.5
384, // Layer1
1152, // Layer2
576 // Layer3
现在，让我们在Winamp检查是怎么说的文件格式信息：
MPEG-2.5层3
16 kbps的，2482帧
现在，如果您将帧数= 2482和每帧样本数= 576（MPEG-2.5第3层），您将获得持续时间2:58。但是由于某些原因，Silverlight和iTunes使用每帧样本数= 384，这给了我们1:59。下一步可能是检查文件标题的真实值，如果它们是正确的并且可以计算正确的持续时间 - 比你可以做一些hack来单独获得持续时间（例如从服务器）。但我很确定 - 该文件有一些缺陷（不一致的标题和内容），一些球员可以处理它，其他人则不能。
这是非常有用的。谢谢！我将尝试调查那个文件有什么问题。也许确实唯一的解决办法是在服务器上分别获取持续时间。 –
您是否在调用'MediaOpened'事件后检查'NaturalDuration'的值？ – keyboardP
是的。此外，我试图查看音频播放过程中是否发生了变化，但不是。正如我所提到的，Position属性的值变得比它通过00:01:59标记之后的持续时间更长。 –
WMP显示正确的时间2:54。但iTunes显示1:59。实际上，如果我们考虑文件大小，并假设这个文件具有恒定的16kbps，那么它给我们〜3分钟。但是，如果我们使用帧并对帧的帧数或每帧的采样数做出错误的假设，我们可以得到其他的东西。有时甚至可以从一些特殊的头文件中获取持续时间谁知道他们做了什么..如果有人知道 - 请分享:) – Kreol