Audio Files vergleichen und Qualität bewerten

[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 ...

[Perlsau]

Zitat von 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.

Du hast vollkommen recht: Dem kann man nicht widersprechen. Für den Kunden geht es um Sprach- bzw. Wiedergabequalität, für den Betreiber muß es um die Qualität seiner Leitungen gehen. Denn eigentlich kann ja die Sprachqualität gar nicht beeinflußt werden bei digitaler Übertragung, es sei denn, daß Pakete verlorengehen, und das ist dann nicht als Rauschen oder Knacken hörbar, sondern vielmehr als zerhackte Sprache.

Die Sprachqualität selber hängt dann tatsächlich ausschließlich davon ab, wie wenig oder stark komprimiert wird.

Da sieht man mal wieder, wie leicht man zu Denkfehlern neigt, wenn an sich von der Sprache verwirren läßt

[UliBru]

Man kann das Thema beliebig komplex machen was die Auswertung angeht.
Ein guter Startpunkt für Sprachübertragung wäre z.B. http://en.wikipedia.org/wiki/Speech_transmission_index

[Namenloser]

Zitat von Perlsau:

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 ...

Problem dabei ist, dass selbst kleine Phasenabweichungen so schon einen riesen Unterschied machen. Deshalb ist es sinnvoller, im Frequenz-Raum (also das was man nach der FFT erhält) zu arbeiten.

[EWeiss]

Meineserachtens ist das schlichtweg unmöglich.
Es sei denn die gegebenheiten Hardware, Software sind auf beiden seiten 100% identisch.
Die anderen Dinge wie Packetverluste usw.. wurden ja schon genannt.

Die AudioDateien wären also immer unterschiedlich.
Sollte eine Datei schlechter sein wie die andere läßt sich dieser zustand der aktuellen Datei
niemals wiederholen ist also nicht reproduzierbar.

Was also soll man dann noch realitätsnah vergleichen?

gruss

[jensw_2000]

Die Bewertung der Audiodaten soll nach dem MOS (PESQ) Standard erfolgen.
Mal schauen ob es dafür fertige APIs gibt oder Open Source Projekte bei denen ich mir Anregungen holen kann.
Infomaterial findet man auf alle Fälle recht viel. Ich mache mich man ans Recherchieren....

[Perlsau]

Zitat von jensw_2000:

Die Bewertung der Audiodaten soll nach dem MOS (PESQ) Standard erfolgen.
Mal schauen ob es dafür fertige APIs gibt oder Open Source Projekte bei denen ich mir Anregungen holen kann.
Infomaterial findet man auf alle Fälle recht viel. Ich mache mich man ans Recherchieren....

Wenn ich Wikipedia richtig verstanden habe, soll es nun also doch eine Prüfung der Klangqualität werden – und das, obwohl wir doch festgestellt haben, daß sich die Qualität der in Pakete aufgeteilten Klänge zwischen Sender und Empfänger gar nicht verändern kann. Das leuchtet mir jetzt nicht ein ... Hast du das deinem Kunden mal vorgetragen? Das wäre doch völlig unnötiger Aufwand! Genau so unnötig wie der Vergleich der Dateigröße vor dem Upload beim Sender und nach dem Download beim Empfänger. Man muß doch lediglich überprüfen, ob alle gesendeten Pakete auch angekommen sind, oder nicht

[jensw_2000]

Zitat von Perlsau:

Hast du das deinem Kunden mal vorgetragen? Das wäre doch völlig unnötiger Aufwand! Genau so unnötig wie der Vergleich der Dateigröße vor dem Upload beim Sender und nach dem Download beim Empfänger. Man muß doch lediglich überprüfen, ob alle gesendeten Pakete auch angekommen sind, oder nicht

Ja. Ich habe ihm auch stundenlange Referate darüber gehalten warum man den prozentualen Verlust zwischen Original und Mitschnitt nicht zuverlässig errechnen kann oder daraus gar Rückschlüsse auf die gehörte Sprachqualität ziehen kann.
Er sagt, dass der MOS Wert eine standardisierte und anerkannte Kennzahl im VoIP Bereich ist und dass alle deren Systeme den MOS Wert als Qualitätsmerkmal nutzen.
Das ist ein alt eingesessener Telefonie und 'VoIP' Carrier. Was kann ich da entgegenhalten?
Die MOS API ist auch noch kostenpflichtig. Es gibt ein paar preiswertere Klone, die von den Werten nahe an MOS rankommen.