調試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讀數差異？

回答

相關問題