Debugug Naudio MP3 -Lesendifferenz?

Question

Mein Code, der Naudio verwendet, um einen bestimmten MP3 zu lesen, erhält unterschiedliche Ergebnisse als mehrere andere kommerzielle Apps.

Speziell: Mein Naudio-basierter Code findet zu Beginn dieses MP3 vor dem "Audible Audio" ~ 1,4 Sekunden Stille), während andere Apps (Windows Media Player, Realplayer, Wavepad) ~ 2,5 Sekunden vor dem Schweigen zeigen, bevor der gleiche Drum -Pickup.

Der besondere MP3 ist "wie ein Rolling Stone", der von Amazon.com heruntergeladen wurde. Testete mehrere andere MP3s und keiner zeigt einen ähnlichen Unterschied zwischen meinem Code und anderen Apps. Die meisten MP3s beginnen nicht mit einer so langen Stille, daher vermute ich, dass dies die Quelle des Unterschieds ist.

Debugging -Probleme:

1. Ich kann keinen Weg finden, um zu beweisen, dass die anderen Apps richtig sind und Naudio/ich falsch ist. Daher kann ich den "Fehler", den ich debuggen muss, nicht einmal genau definieren.

2. Da mein Code während dieser 1,4 Sekunden ohne offensichtliche Fehler Tausende von Proben liest, kann ich nicht überlegen, wie ich dort eingrenzen kann, wo/wenn im Eingabestream nach einem Fehler suchen kann.

3. Das Herzstück des Naudio-Codes ist ein P/Invoke-Anruf bei ACMStreamConvert (), einem Windows-Anruf "Black Box", den ich nicht überlegen kann, wie man die Fehlerprüfung ist.

Kann jemand an Tricks/Techniken denken, um dies zu debuggen?

Answer 1

Der Naudio ACM -Code war ursprünglich nie für MP3s gedacht, sondern für die Dekodierung konstanter Bitrate -Telefonie -Codecs. Eines Tages habe ich versucht, das Wellenformat einzurichten, um MP3 als Experiment anzugeben, und was herauskam, klang gut genug. Allerdings habe ich mich immer ein bisschen nervös gemacht Überzeugt, dass Naudio es richtig macht - es gibt nur sehr wenig Dokumentation darüber, wie genau Sie die ACM -Codecs verwenden sollen. Leider gibt es keinen verwalteten MP3 -Decoder mit einer Lizenz, die ich in Naudio verwenden kann, daher bleibt ACM vorerst die einzige Option.

Ich bin mir nicht sicher, welche Ansätze andere Mediplayer zum Rückspielen von MP3-Spielen annehmen, aber ich vermute, dass viele von ihnen ihre eigenen integrierten MP3-Decoder haben, anstatt mich auf das Betriebssystem zu verlassen.

Answer 2

Ich habe einige teilweise Antworten auf mein eigenes Q gefunden:

1. Da mein Problem darauf zurückzuführen ist, zu viel MP3 mit genügend PCM zu konsumieren, habe ich bedingal-on-Hit-Count-Haltepunkte verwendet, um genau dort zu finden, wo dies geschah, und dann eingebohrt.

2. Dies zeigte mir, dass einige Acmstreamconvert () -Anrufe erfolgreich sind und 417 SRC -Bytes verbrauchen, aber 0 "Dest Bytes verwendet" produzieren.

Als nächstes plane ich, AcmstreamSize () zu versuchen, den Codec zu fragen, wie viele SRC -Bytes es "konsumieren" wollen, anstatt es zu "sagen", um 417 zu konsumieren.

Bearbeiten (Followup): Ich habe es behoben!

Es kam darauf ab, Acmstreamconvert () genug SRC -Bytes zu übergeben, um es glücklich zu machen. Das Geben seiner AcmStreamSize () forderte die Größe an, das das Problem an einigen Stellen behoben hat, aber dann tauchte es in anderen auf; Das Geben der angeforderten Größenzeiten 3 scheint die "0 verwendeten Dest -Bytes" zu heilen, die zu allen MP3s führen, die ich getestet habe.

Mit diesem Fix kehrte AcmstreamConvert () manchmal viel größere konvertierte Stücke (fast 32 kb) zurück, sodass ich auch einen anderen Naudio -Code ändern musste, um größere Zielpuffer zu übergeben, um die Ergebnisse zu halten.