Audio Files vergleichen und Qualität bewerten

[Furtbichler]

Wenn Du Zeit hast, könntest Du dich mit der Bass.dll beschäftigen, die kann FFT. Vielleicht kommst Du damit weiter.

Bezüglich der Übertragungsqualität (die 'Bandbreite') sollte FFT ziemlich schnell zu brauchbaren Resultaten führen:
Du bekommst ja pro Zeiteinheit die Verteilung der Frequenzen. Wenn Du nun für Referenz- und Zielsignal eine Durschnittskurve berechnest und dann übereinander legst, verdeckt die Kurve des Zielsignals die des Referenzsignals nur zum Teil, weil ja hohe Frequenzen i.a. verloren gehen. Du kannst z.B. versuchen, die überdeckte Fläche zur Gesamtfläche der Referenzkurve ins Verhältnis zu setzen und dann hättest Du eine Prozentangabe über die Frequenzgüte.

Ich denke, wenn Du dir mal die beiden Kurven aufmalst, wirst Du noch andere Vergleichsmöglichkeiten erkennen.

Bezüglich verlorener Pakete könntest Du auf der Transportebene einfach die Pakete zählen, wenn das geht.

Das wäre mein -sehr hemdsärmeliger- Ansatz.

Ein Proof-Of-Concept sollte in relativ kurzer Zeit (1-2 Wochen) zu machen sein.

[jsp]

Hallo zusammen,

vermutlich ein idiotischer Ansatz.
Die Referenz mit Speech recognition analysieren lassen.
z.B. http://www.chant.net/Products/SpeechKit/
Am besten mit 100% Erkennungsrate.
Danach mit der Erkennungsrate der Testanrufe vergleichen.

Vielleicht bin auch noch nicht wach genug....

Gruss, Jörn

[Medium]

Furti, ein Test auf Bandbreite ist für eine digitale Übertragung nicht mehr ein so geeignetes Instrument wie bei analog. Die Kompression haut allerhand Bänder raus, aber schlechter wird die Verständlichkeit dadurch idR nicht. Danach werden die auszulassenden Frequenzen ja gerade ausgesucht. Für analoge Telefonie / Leitungsmessung mag das ja alles zutreffen, aber für eine Kennzahl die mit einem subjektiven Qualitätsempfinden (bzw. Grad der Verständlichkeit von Sprache) korreliert wird das so simpel einfach nichts.

jsp's Idee finde ich witzig, das müsste man mal prüfen, wie realistisch das am Ende ist

[jensw_2000]

@ jsp

Deine Idee finde ich richtig genial.
SAPI verstehe ich auch
Das wird mein Projekt fürs Wochenende

Am besten baue ich mir ein Voice File mit zusammenhanglosen Wörtern und das ohne Übertragungsfehler (direkt aus dem File) mit knapp unter 100% erkannt werden kann.

Dann lasse ich das File von einem befreundeten ITK Systemhaus über VoIP strecken mit unterschiedlichen Bandbreiten und Codecs schicken und wieder aufzeichnen.
Mal schauen ob sich dann zuverlässige Trends erkennen lassen.

Hast du Erfahrungen mit dem SpeechKit?
Ich würde es sonst mit der Windows eigenen SAPI ausbauen.

[jsp]

Nein, mit SpeechKit habe ich keine Erfahrung.
Vor Jahren hatte ich mal mit SAPI rumgespielt. Das müsste eigentlich reichen.

Bin schon gespannt ob da was brauchbares rauskommt.

Ich hoffe du berichtest...

Gruss, Jörn

[Perlsau]

Im Grunde geht es doch nur darum, erstens Störgeräusche zu erkennen, zweitens die Zunahme von Rauschen und drittens die Abnahme der Signalstärke. Das Erkennen von Störgeräusche stelle ich mir am leichtesten vor: das sind einfach Ausreißer in der Welle. Rauschen könnte man durch das Senden von Stille erkennen, und die Signalstärke läßt sich ebenfalls vergleichen. Mit Hörqualität hat das am Ende erst einmal nichts zu tun, denn es geht darum, Übertragungsfehler festzustellen: Vergleich von Quell- und Zieldatei auf Unterschiede in diesen drei Bereichen.

[jensw_2000]

@Perlsau
Die Audio Codecs werden das Sinus Signal vermutlich schon so "zerhacken", dass man viele Frequenzausreißer hat, die eigentlich gar keine Fehler sind.
Wir haben alle schon mal in irgendwelchen Telefonwarteschlangen gehangen, in denen die Wartemusik völlig zerhackt und gruselig wiedergegeben wurde.
Das Rauschen während der Stille wird nicht messbar sein, den G729A und G711A machen Silence Compression.
Knacken wird man hoffentlich sehen. Das ist ein echter Peak.
Ich teste die Bass.dll in jedem Fall aus. Allein schon um damit Erfahrungen zu sammeln.

Die SAPI Geschichte finde ich aber absolut kreativ und sie ist für mich einfach zu handhaben.

Das System soll später bei der Qualitätssicherung des Carriers laufen.
Die wollen damit Tendenzen erkennen, bevor die Kunden sich beklagen.
Meiner Meinung nach ist es OK wenn die sehen können, dass die Erkennungsrate zum Knoten X im Vergleich zur Vorwoche z.B. um 10% gefallen ist. Das ist ein sicheres Zeichen, dort einen Techniker drauf anzusetzen und eine Langzeitüberwachung für die Leitung in den anderen Systemen anzuschupsen ...

Morgen haben wir mit dem Kunden eine Telko zu dem Thema.
Mal schauen in welcher Richtung es dann weitergeht ...

[Medium]

Perlsau, Rauschen und Signalstärke sind Probleme aus der analogen Tonübertragung. Wenn eine physikalische Leitung mit digitalen Daten zu stark rauscht oder zu schwach ist, dann wird beim Empfänger schlicht überhaupt nichts mehr ankommen, oder nur einzelne (millisekundenlange) Päckchen, die sich wie "Tschirpen" anhören dürften. Das größte Problem bei digitaler Übertragung dürfte die Bitrate werden: Wenn die Leitung zu stark beansprucht ist, muss der Codec umso stärker komprimieren, ggf. bis hin zur Unverständlichkeit. Ich vermute es geht eher um diese Probleme. (Wobei sich die Auslastung auch schon eher und zuverlässiger messen/schätzen ließe, ganz ohne Rücksicht auf den Inhalt der Datenströme.)
Wenn nicht, ist das einfach die falsche Messstelle. Wenn analoge Anlagenteile auf ihre Güte hin bewertet werden sollen, sollten Messungen an eben diesen stattfinden. Da gibt es zumindest für die Leitungsgüte physikalische Kenngrößen (SNR und Co).

Wenn aber nur und ausschließlich die "Sprachqualität" (wie will man die sinnvoll quantifizieren?) das Maß sein soll, ist ein echtes Menschliches Ohr das einzig geeignete Messgerät. Eine Spracherkennung ist dann schon am nächsten dran.
Eventuell sollte im Vorfeld auch schon mal gaaaanz genau abgeklärt werden welche Probleme mit der Übertragung überhaupt auftreten können, und zwar haarklein. "Sprachqualität" ist viel zu weit gefasst für ein konkretes Messverfahren.

[Perlsau]

Hallo Jens,

vielleicht sollte man nicht, wie in deinem Startposting ausgeführt, die Original-Signale mit den bei der Gegenstelle ankommenden vergleichen, da die Audio-Codecs ja nicht als Störung interpretiert werden dürfen: Die stehen ja fest. Daher sollte man, wenn schon, die komprimierten Signale mit den ankommenden vergleichen.

Ich stelle mir, da ich Klangdateien bislang nie mathematisch bearbeitet habe, immer die Wellen vor, die mein uralter Soundeditor (Soundforge) grafisch darstellt: Legt man zwei solche Ausschnitte übereinander, ergeben sich Schnittmengen (gelbe Fläche im Beispiel). Anhand der Größe einer solchen Schnittmengen könnte man die Übertragungsqualität beurteilen. Wie man das in Delphi umsetzt, weiß ich nicht (obwohl ich's sicher rausfinden könnte, wenn ich müßte). Mit anderen Worten: wird eine bestimmte Anweichungstoleranz überschritten, klingeln die Alarmglocken ...