使用NAudio读取一个特定MP3的代码与其他几个商业应用程序的结果不同。
具体来说：我的基于NAudio的代码在“可听音频”（鼓声拾音）开始之前在此MP3开头发现~1.4秒的静音，而其他应用程序（Windows Media Player，RealPlayer，WavePad）显示~2.5秒在同一个鼓拾取之前的沉默。
特定的MP3是从Amazon.com下载的“Like A Rolling Stone”。测试了其他几个MP3，没有显示我的代码和其他应用程序之间的任何类似差异。大多数MP3并没有以如此长的沉默开始，所以我怀疑这是差异的根源。
调试问题：
我实际上找不到一种方法来证明其他应用程序是正确的并且NAudio /我是错误的，即将我的代码的结果逐块地比较为“已知的良好参考实现”;因此我甚至无法准确定义我需要调试的“错误”。
由于我的代码在1.4秒内读取了数千个样本且没有明显错误，我无法想到如何缩小输入流中的位置/时间以查找错误。
NAudio代码的核心是对acmStreamConvert（）的P / Invoke调用，这是一个Windows“黑匣子”调用，我无法想到如何进行错误检查。
有人能想到调试这个的技巧/技巧吗？
答案 0 :(得分：0)
NAudio ACM代码原本不是用于MP3，而是用于解码恒定比特率电话编解码器。有一天，我尝试设置WaveFormat来指定MP3作为实验，而且听起来很好听。然而，我总是对使用ACM解码MP3（尤其是VBR）感到有些紧张（例如，如果ID3标签或专辑封面传入后会出现什么 - 这会导致额外的沉默吗？），而且我从来没有100％确信NAudio做得对 - 关于你应该如何使用ACM编解码器的文档很少。遗憾的是，没有管理型MP3解码器可以在NAudio中使用许可证，因此ACM仍然是目前唯一的选择。
我不确定其他媒体播放器采用什么方法来播放MP3，但我怀疑其中很多都有自己的内置MP3解码器，而不是依赖于操作系统。
答案 1 :(得分：0)
我找到了一些我自己的问题的部分答案：
由于我的问题归结为消耗过多的MP3而不产生足够的PCM，我使用条件点击计数断点来找到发生这种情况的地方，然后钻进去。
这向我展示了一些acmStreamConvert（）调用返回成功，消耗了417个src字节，但产生了0“使用的dest字节”。
接下来我打算尝试使用acmStreamSize（）来询问编解码器“想要”消耗多少src字节，而不是“告诉”它消耗417。
编辑（后续）：我修好了！
归结为传递acmStreamConvert（）足够的src字节以使其满意。给它的acmStreamSize（）请求的大小在某些地方修复了问题，但随后它出现在其他地方;给它所要求的大小时间3似乎可以治愈我测试的所有MP3中的“使用的0个字节”。
通过此修复，acmStreamConvert（）有时会返回更大的转换块（大约32 KB），因此我还必须修改一些其他NAudio代码以传递更大的目标缓冲区来保存结果。