调试NAudio MP3读数差异？

我的代码使用NAudio来读取一个特定的MP3获得不同的结果比其他几个商业应用程序。调试NAudio MP3读数差异？

具体来说：我的基于NAudio的代码发现，在开始播放“可听音频”（鼓拾音器）之前，此MP3的开头会有〜1.4秒的静音，而其他应用程序（Windows Media Player，RealPlayer，WavePad）在同一个鼓拾音器之前的静音秒。

特殊的MP3是“像滚石”从Amazon.com下载。测试了其他几个MP3，没有发现我的代码和其他应用程序有任何类似的区别。大多数MP3不是以这么长时间的沉默开始的，所以我怀疑这是差异的根源。

调试问题：

我不能真正找到一种方法，甚至证明其他应用程序是正确的，n音讯/我是错的，也就是比较块逐块我的代码的结果一个“已知的良好参考实施”;因此我甚至无法精确定义我需要调试的“错误”。由于我的代码在1.4秒内读取了数千个样本，没有明显的错误，所以我无法考虑如何缩小输入流中何处/何时寻找错误。
NAudio代码的核心是对acmStreamConvert（）的P/Invoke调用，这是一个Windows“黑匣子”调用，我无法考虑如何进行错误检查。

任何人都可以想到的任何技巧/技术调试这个？

来源

2010-05-15 Conrad Albrecht

NAudio ACM代码从未用于MP3，而是用于解码恒定比特率电话编解码器。有一天，我尝试设置WaveFormat来指定MP3作为一个实验，结果听起来不错。然而，我一直对使用ACM解码MP3（尤其是VBR）感到有些紧张（例如，如果ID3标签或专辑封面通过了 - 会导致额外的沉默？），我从来没有100％坚信NAudio是对的 - 关于你应该如何使用ACM编解码器的文档很少。令人遗憾的是，没有可以在NAudio中使用许可证的管理MP3解码器，所以ACM仍然是目前唯一的选择。

我不确定其他媒体播放器播放MP3的方式，但我怀疑他们中的很多人都有自己的内置MP3解码器，而不依赖于操作系统。

来源

2010-05-16 13:20:59

谢谢你的背景。所以我不会期望从n音讯MP3解码太多，但它仍然把我远胜从头开始盘算这一切我自己，我还是不知道更好的方式来为低预算的商业应用解码MP3。 – 2010-05-16 15:09:31

我发现我自己的Q某些部分答案：

因为我的问题归结为消耗太多MP3 W/O产生足够的PCM，我用有条件的命中计数断点找到发生的地方，然后钻到那里。
这表明我有些acmStreamConvert（）调用正在返回成功，消耗417个src字节，但产生0个“使用的dest字节”。

接下来，我打算尝试acmStreamSize（）问有多少字节的src是“希望”消费，而不是“告诉”的编解码器就消耗417

编辑（后续）：我修复！

结果还是要通过acmStreamConvert（）足够的SRC字节，使其快乐。给它它的acmStreamSize（）请求的大小解决了一些地方的问题，但随后出现在其他地方;给它所需的大小时间3似乎可以治愈我测试过的所有MP3中的“0 dest bytes used”结果。

通过此修正，acmStreamConvert（）有时会返回更大的转换块（差不多32 KB），所以我还必须修改其他NAudio代码以传递更大的目标缓冲区来保存结果。

来源

2010-05-16 15:00:43

acmStreamSize对CBR很好，但不能为VBR提供有意义的答案。另外，并非MP3文件中的所有内容都是压缩音频。还有其他的东西，比如ID3标签等。我尝试去除它们，但总有一些机会将一些非音频内容传递给ACM编解码器。我还没有看到你应该如何解析MP3文件，以制定出它是什么位的任何正式文件应该被发送到ACM编解码器。 – 2010-05-16 17:05:39

调试NAudio MP3读数差异？

回答

相关问题