Отладка NAudio MP3 разница чтения?

Question

Мой код, использующий NAudio для чтения одного конкретного MP3, получает результаты, отличающиеся от нескольких других коммерческих приложений.

В частности: мой код на базе NAudio обнаруживает ~ 1,4 сек. Тишины в начале этого MP3 до того, как запускается "слышимый звук" (звук барабана), тогда как другие приложения (Windows Media Player, RealPlayer, WavePad) показывают ~ 2,5 сек тишины перед тем же барабанным захватом.

Конкретный MP3-файл "Like A Rolling Stone" загружен с Amazon.com. Протестировал несколько других MP3-файлов, и ни один из них не показал схожей разницы между моим кодом и другими приложениями. Большинство MP3 не начинаются с такой долгой паузы, поэтому я подозреваю, что в этом причина различий.

Проблемы отладки:

1. На самом деле я не могу найти способ даже доказать, что другие приложения верны, а NAudio / me неправильна, то есть сравнивать результаты моего кода по блокам с "известной хорошей эталонной реализацией"; поэтому я даже не могу точно определить «ошибку», необходимую для отладки.

2. Поскольку мой код считывает тысячи выборок в течение этих 1,4 с без явных ошибок, я не могу думать, как сузить, где / когда во входном потоке искать ошибку.

3. Сердцем кода NAudio является вызов P / Invoke для acmStreamConvert (), который является вызовом «черного ящика» Windows, который я не могу придумать, как проверять ошибки.

Может кто-нибудь придумать какие-нибудь хитрости / приемы для отладки этого?

Answer 1

Я нашел несколько частичных ответов на свой вопрос:

1. Поскольку моя проблема сводится к потреблению слишком большого количества MP3 без производства достаточного количества PCM, я использовал условные контрольные точки при подсчете количества посещений, чтобы определить, где это происходит, а затем углубился в это.

2. Это показало мне, что некоторые вызовы acmStreamConvert () возвращаются успешно, они потребляют 417 байтов src, но выдают 0 «используемых байтов dest».

Далее я планирую попробовать acmStreamSize (), чтобы спросить кодек, сколько байт src он «хочет» использовать, вместо того, чтобы «сказать» ему, что он потребляет 417.

Редактировать (продолжение): Я исправил это!

Все сводилось к передаче acmStreamConvert () достаточного количества src-байтов, чтобы сделать его счастливым. Придание ему запрошенного размера acmStreamSize () решило проблему в некоторых местах, но затем оно появилось в других; присвоение ему запрошенного размера, умноженного на 3, приводит к исцелению результата «0 dest bytes used» во всех протестированных мною MP3.

С этим исправлением acmStreamConvert () иногда возвращал гораздо большие преобразованные фрагменты (почти 32 КБ), поэтому мне также пришлось модифицировать некоторый другой код NAudio для передачи в более крупные целевые буферы для хранения результатов.

Answer 2

Код NAudio ACM изначально не предназначался для MP3, но для декодирования кодеков телефонии с постоянной скоростью передачи битов. Однажды я попытался настроить WaveFormat для указания MP3 в качестве эксперимента, и то, что получилось, звучало достаточно хорошо. Тем не менее, я всегда немного нервничал по поводу декодирования MP3 (особенно VBR) с помощью ACM (например, что получится, если будут переданы теги ID3 или обложки альбомов - может ли это объяснить дополнительное молчание?), И я никогда не был на 100% Убежден, что NAudio делает это правильно - очень мало документации о том, как именно вы должны использовать кодеки ACM. К сожалению, в NAudio нет управляемого MP3-декодера с лицензией, которую я мог бы использовать, поэтому ACM пока остается единственным вариантом.

Я не уверен, какой подход к воспроизведению MP3 используют другие медиапроигрыватели, но я подозреваю, что многие из них имеют свои собственные встроенные декодеры MP3, а не полагаются на операционную систему.