Audio Files vergleichen und Qualität bewerten

[Perlsau]

Zitat:

Zitat von jensw_2000 (Beitrag 1226703)

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.

Es kann beim Übertragen einer VoIP-Nachricht gar keinen Qualitätsverlust in der Klangdatei selber geben! Entweder das Paket kommt an oder es kommt nicht an. Das, was im Paket drin ist, nämlich der eine oder andere Sprachfetzen, kann beim Übertragen quasi nicht verändert werden. Verändert bzw. unvollständi gangekommene Pakete werden als fehlerhaft und somit als nicht angekommen bewertet. Das mußt du ihm verklickern!

Zitat:

Zitat von jensw_2000 (Beitrag 1226703)

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.

Aber das hat doch absolut gar nichts mit den Übertragungsfehlern zu tun: Nachdem ein Sprachfetzen mit irgend einem Codec codiert wurde, bleibt der Inhalt derselbe. Decodiert wird erst im Modem oder im Rechner. Zwischen Sende- und Empfangsmodem kann es keinen Qualitätsverlust geben, es sei denn, daß Pakete verloren gehen, und dann fehlt eben ein Sprachfetzen.

Zitat:

Zitat von jensw_2000 (Beitrag 1226703)

Das ist ein alt eingesessener Telefonie und 'VoIP' Carrier. Wasser kann ich da entgegenhalten?

Ja, ich hatte auch meine Schwierigkeiten, diese Zusammenhänge zu begreifen, bis Medium mich mit der Nase draufgestoßen hat. Liegt vielleicht auch bei mir am Alter, womöglich aber auch an der Hartnäckigkeit, mit der sich gewohnte Vorstellungen im Gehirn festsetzen und mit der Zeit ihre eigene Argumentations-Dynamik entwickeln ...

Zitat:

Zitat von jensw_2000 (Beitrag 1226703)

Die MOS API ist auch noch kostenpflichtig. Es gibt ein paar preiswertere Klone, die von den Werten nahe an MOS rankommen.

Hab ich gelesen. Schon deswegen wäre es wünschenswert, wenn dein Kunde diese Zusammenhänge ebenfalls erkennt. Die Codier-Qualität (8 Bit, 8K Sample-Rate) wird ja bereits vor der Übertragung zum Ziel-Telefon festgelegt. Ab dann ändert sich der Inhalt des Klang-Pakets nicht mehr.

Ich beneide dich nicht, denn ich kenne das nur zu gut, wenn ein Kunde was völlig Unmögliches oder völlig Unnötiges von einem will ... Vielleicht will der VoIP-Betreiber dieses Prüfprogramm aber auch nur, weil er damit sein Angebot aufhübschen kann: "Wir garantieren die bestmögliche Übertragungsqualität!" oder so ...

[Medium]

PESQ scheint mir ein wirklich irre komplexes Auswertungssystem zu sein. Dafür ein paar Mark auf den Tisch zu legen finde ich voll verständlich, und letztlich muss dein Kunde das ja tragen können wollen, wenn er es verlangt.
Zusätzlich zu Perlsaus Einwänden war ich hier aber auch etwas besorgt, dass dieser Test ebenfalls auf analoge Telefonie zugeschnitten ist. War er wohl auch, jedoch soll er laut Opticom angepasst worden sein. Dennoch frage ich mich, was hierbei, ab Codierungsseite, wirklich noch groß schief gehen soll (ausser eben die Totalabrisse). Eigentlich kann man dann ja fast nur noch messen, was eventuelle analoge Streckenteile versauen, die i.A. aber denke ich doch eher vorm Codierer liegen dürften. (Sie zwischendrin beim Routen zum Empfänger hin und her zu wandeln dürfte ja keiner machen - das wäre ja fast sträflich.)

Von daher würde ich PESQ als durchaus nettes Tool ansehen, womit man am Codierer einmalig nach seiner Einrichtung (oder Änderungen) ermitteln kann, ob das was da hinten heraus kommt okay ist*. Sobald das passt, führen Fehler in den weiteren Leitungen halt doch wieder nur zu Paketverlusten. Interessant ist es sicherlich dann, wenn der Provider intern umcodiert. Würde ich für "blöd" halten, aber es kann sicherlich technische Gründe für sowas geben, die ich nicht kenne. Dannnnn könnte man einen Nutzen von dem von dir beschriebenen Stichprobenverfahren mit PESQ erwarten. Allerdings wohl eher bzgl. defekter Re-Codierer als physikalischen Leitungsproblemen.

(Mir war vor diesem Thread nicht wirklich bewusst, was für ein komplexes Thema VoIP im großen Maßstab wird. Danke für die interessante Beschäftigung damit :))


*) Die Wikipedia gibt sogar schon MOS-Werte für ein paar Voice-Codecs an :D

Edit: Ein recht interessantes Video. Scheinbar geht es wirklich hauptsächlich um Paketverluste. Ich sehe ein, dass die Anzahl verlorener Pakete nicht zwangsweise linear und immer exakt reproduzierbar mit der Sprachqualität korreliert, doch scheint das bloße protokollieren von Paketverlusten schon eine sehr aussagekräftige Sache zu sein. Je nach dem wie kompliziert das eine oder andere umzusetzen ist, wäre das aber ggf. noch ein weiterer Ansatzpunkt. Man würde quasi die Ursache messen, nicht die Wirkung. Wobei die Wirkung schwankend ausgeprägt ist - ich würde im Allgemeinen aber zumindest für "guck da mal genauer"-Warnungen brauchbare Werte bei der Paketverlustmessung erwarten. Ist die Frage, ob die bestehenden Geräte dies zulassen.

[samso]

Zitat:

Zitat von Perlsau (Beitrag 1226710)

Es kann beim Übertragen einer VoIP-Nachricht gar keinen Qualitätsverlust in der Klangdatei selber geben!

Nun, da möchte ich zu bedenken geben, dass der Decoder ja u.U. durchaus in der Lage ist, mit Packetverlusten umzugehen und diese bis zu einem gewissen Grad zu kompensieren. Je nach dem wie gut er das macht und wie die Packetverluste verteilt sind kann sich das in der Sprachqualität unterschiedlich auswirken. Aus diesem Grund finde ich das Ansinnen des Kunden nicht ganz so idiotisch wie es zunächst den Anschein hat. Natürlich wäre es wünschenswert keine Packetverluste zu haben. Das scheint aber in der Praxis eher unrealistisch zu sein. Folglich muss man bewerten, ob die Packetverluste zu tolerieren sind. Dazu hat sich der Kunde auf ein bestimmtes standardisiertes Messverfahren eingeschossen. Er hätte vielleicht auch eine einfacheren Messwert nehmen können, etwa "Packetverluste pro Sekunde"... Da es aber für den Endnutzer letztendlich darauf ankommt eine akzeptable Sprachqualität zu haben, ist das gewählte Messverfahren vielleicht ganz sinnvoll.

[Perlsau]

Zitat:

Zitat von samso (Beitrag 1226800)

Nun, da möchte ich zu bedenken geben, dass der Decoder ja u.U. durchaus in der Lage ist, mit Packetverlusten umzugehen und diese bis zu einem gewissen Grad zu kompensieren.

Welche Umstände wären das?

Kompensation findet nur in gewissem Rahmen statt. Das bedeutet, daß ab einem gewissen Prozentsatz an Paketverlusten nichts mehr sinnvoll kompensiert werden kann. Laut diesem Artikel können Paketverluste bis zu 20 Prozent so kompensiert werden, daß der Zuhörer die Paketverluste nicht bemerkt. Alles, was darüber liegt, wird vom Zuhörer als Stimm-Verfremdung (Roboterstimme) wahrgenommen. Mit PSQM mißt man dann im Ernstfall nicht, was an übertragener Sprachqualität ankommt, sondern was der Decoder fabriziert – und das kann je nach Decoder bei gleicher Fehlerquote unterschiedlich sein (billige und teuere VoIP-Modems). Der eigentliche Verursacher der minderen Sprachqualität ist aber die Leitung bzw. das ungenügende Protokoll oder eine zu schwache Sende- und/oder Empfangsleistung. Man könnte z.B. sicherheitshalber jedes Paket gleich drei- oder viermal versenden, weil das die Chance erhöht, daß zumindest eines davon ankommt. Der VoIP-Empfänger (das Voice-Modem) kann viel schneller prüfen, ob ein Paket bereits empfangen wurde, anstatt mit hochkomplexen und rechenintensiven Algorithmen die entstandenen Signallücken zu interpolieren.

Zitat:

Zitat von samso (Beitrag 1226800)

Je nach dem wie gut er das macht und wie die Packetverluste verteilt sind kann sich das in der Sprachqualität unterschiedlich auswirken.

Je nachdem, wie stark es regnet, kann sich das auf die Feuchtigkeit unterschiedlich auswirken. Klasse :!: (Nein, schlechter Vergleich, mein Satz ist um vieles aussagekräftiger als deiner.)

Zitat:

Zitat von samso (Beitrag 1226800)

Aus diesem Grund finde ich das Ansinnen des Kunden nicht ganz so idiotisch wie es zunächst den Anschein hat.

Aber doch hoffentlich noch immer ausreichend "idiotisch", um den Drang zu verspüren, den Kunden über seine Denkblockade bzw. Unkenntnis aufzuklären? Oder doch besser nach dem Motto: "Egal, was du willst, ich mach dir alles, und wenn's noch so idiotisch ist." :?:

Zitat:

Zitat von samso (Beitrag 1226800)

Natürlich wäre es wünschenswert keine Packetverluste zu haben. Das scheint aber in der Praxis eher unrealistisch zu sein. Folglich muss man bewerten, ob die Packetverluste zu tolerieren sind. Dazu hat sich der Kunde auf ein bestimmtes standardisiertes Messverfahren eingeschossen. Er hätte vielleicht auch eine einfacheren Messwert nehmen können, etwa "Packetverluste pro Sekunde"... Da es aber für den Endnutzer letztendlich darauf ankommt eine akzeptable Sprachqualität zu haben, ist das gewählte Messverfahren vielleicht ganz sinnvoll.

Wenn ich weiß, wie groß die gesendeten Pakete sind, und auch weiß, wie viele gewöhnlich verloren gehen, dann kann ich mir leicht ausrechnen, ab wie vielen hintereinander verlorenen Paketen die Sprachqualität leidet. Leidet sie bereits, wenn jedes zehnte Paket verlorengeht? Oder müssen zwei oder drei Pakete hintereinander fehlen, um für den Zuhörer bemerkbar zu werden? Das sind doch die eigentlichen Fragen, die man stellen müßte. Was soll ein teueres und aufwendiges Meßverfahren wie PSQM am Ende feststellen? Daß sich die Sprachqualität verringert, je mehr Pakete unterwegs verloren gehen? Das kann ich dir auch so sagen. Rauschen und sonstige Störgeräusche messen zu wollen ist auf jeden Fall hirnrissig, wenn es um VoIP geht. Natürlich kannst du die vom jeweiligen Decoder eingestreuten Ersatz-Klänge (bzw. Stille) messen und mit dem gesendeten Original vergleichen, aber was bringt das?

Du bist doch am Ende nicht etwa ein Mitarbeiter der besagten Firma :twisted:

Der oben verlinkte Artikel bietet wichtige Hinweise für alle, die sich mit der Programmierung rund um VoIP befassen (müssen). Auszug (drittletzter Absatz):

Die Sprachströme werden bei VoIP nicht mit dem sicheren TCP-Protokoll übermittelt. RTP nutzt stattdessen das ungesicherte User Datagram Protocol (UDP) für die Übertragung von Sprachpaketen. Der Grund hierfür liegt in dem hohen TCP-Overhead und durch TCP verbundenen hohen Paketverzögerungen. Durch die Nutzung von UDP werden auf der Transportebene keine auf dem Weg zum Empfänger verloren gegangenen Pakete wiederholt. VoIP kann zwar mit geringen Paketverlusten umgehen. Die sich dadurch verändernde Sprachqualität macht sich kaum beim Nutzer bemerkbar. Gehen jedoch größere Mengen an Datenpaketen verloren oder erhöht sich die Verzögerungszeit durch eine Überlast im Netzwerk, hat dies eine signifikante Verschlechterungen der Telefonströme zur Folge.

Und ebenso wichtig (letzter Absatz):

Anmerkung: In der Praxis lässt sich die Qualität der eigentlichen Umkodierung mit Hilfe einer passiven Messung nicht überprüfen. Hierfür muss auf eine VoIP-Simulation, wie sie das Programm TraceSim VoIP zur Verfügung stellt, zurückgegriffen werden.

Und über passive und aktive Messungen:

Aktive/passive Messung (intrusive/non-intrusive) Bei den passiven Messverfahren (non-intrusive) werden vorhandene Daten abgegriffen und es wird nicht ins System eingegriffen. Aktive Verfahren hingegen können z. B. ein größeres zusätzliches Datenaufkommen verursachen, wenn sie zusätzliche Messdaten austauschen müssen. Sie verursachen eine zusätzliche Last und greifen in ein System ein. Die Implementierung ist in der Regel auch mit größerem Aufwand verbunden.

Quelle: Untersuchung und Implementierung von Non-Reference Qualitätsbewertungsverfahren für IPTV Audiostreaming

[Furtbichler]

Willst Du wieder stänkern?:roll:

[jensw_2000]

Das Thema ist für mich höchstwahrscheinlich erledigt.

Mittwoch versuche ich den Kunden auf eine andere Prüfmethode (AQuA) umzustimmen.
Die AQuA Jungs sind preislich mit 700-1000 EUR pro "Prüf-Thread" (Kanal) noch halbwegs auf dem Boden.

Falls mein Kunde auf PSEQ beharrt bin ich raus.
Das PSEQ Basispaket (5 Demolizenzen und 5 Entwicklerlizenzen) kostet 10000 EUR. Damit kann man dann erstmal los programmieren und was zeigen.
Diese Lizenzen sind aber nicht für den Wiederverkauf zugelassen. Der Kunde zahlt nachher bestimmt mehr. Das haben die erstmal gekonnt verschwiegen.
Sollte jemand Interesse haben das Projekt "im PSEQ Fall" in Eigenregie zu übernehmen, dann möge er mir seine Kontaktdaten senden. Ich gebe diese dann gerne weiter.

Ich will auch DLLs für 10000 EUR verkaufen.
Hat jemand Interesse? :coder:

[Medium]

Aber das sind doch letztlich Kosten, die dein Kunde ohne zu murren tragen wird. Ab gewissen Volumina ist eine Abschlagszahlung vorab zwecks Material auch nicht unüblich, bzw. Kurzzeitkredite (ggf. mit Bürgschaft vom Kunden). Warum ist der Preis für dich das ausschlaggebende Problem?

[Perlsau]

Zitat:

Zitat von jensw_2000 (Beitrag 1226890)

Die AQuA Jungs sind preislich mit 700-1000 EUR pro "Prüf-Thread" (Kanal) noch halbwegs auf dem Boden.

Wow! Das ist heftig :!:

Zitat:

Zitat von jensw_2000 (Beitrag 1226890)

Das PSEQ Basispaket (5 Demolizenzen und 5 Entwicklerlizenzen) kostet 10000 EUR. Damit kann man dann erstmal los programmieren und was zeigen.
Diese Lizenzen sind aber nicht für den Wiederverkauf zugelassen. Der Kunde zahlt nachher bestimmt mehr. Das haben die erstmal gekonnt verschwiegen.

Mir fehlen die Worte :shock:

Zitat:

Zitat von jensw_2000 (Beitrag 1226890)

Ich will auch DLLs für 10000 EUR verkaufen. Hat jemand Interesse? :coder:

Ja, wenn du eine FillKonto-Dll hast, die könnte ich ganz gut gebrauchen. Ich würd dann erst mal die Trial nehmen, und wenn die funktioniert, sofort die Vollversion bei dir einkaufen :-D

[jensw_2000]

Zitat:

Zitat von Medium (Beitrag 1226899)

Warum ist der Preis für dich das ausschlaggebende Problem?

Es ist weniger der Preis, sondern eher mein Problem mit Abzocke und unverschämter Gier.

Klar müssen Know-how, Forschung usw. kostendeckend entlohnt werden, damit das Niveau erhalten bleibt.
Aber das Geld muss doch primär der zahlen, der auch den Profit damit macht. Das ist eindeutig der Kunde.

Wenn ich als kleiner Entwickler ein Programm schreibe, das voraussetzt, dass der Kunde zusätzlich deren Lizenzen kaufen muss, dann erwarte ich eine entgegenkommende und leicht gebeugte Haltung von denen. Nicht umgekehrt. Schließlich schreibe ich für den Lieferanten "kostenlos" ein Programm, dass ihm automatisch Lizenzgebühren in die Kasse bringt.

Was soll dieses Basispaket mit 5x5 Lizenzen? Einzellizenzen zum stark vergünstigtem NFR Preis pro Entwickler wären aus meiner Sicht fair. Ich muss mit meiner Arbeit auch noch ein paar Euro verdienen und kann nicht mehr Geld ins Werkzeug stecken als unter dem Strich übrig bleibt.
Zusätzlich sind die auch nicht bereit ihre Lizenzen direkt mit dem Kunden abzurechen und zwingen mir so auch noch die Händer Rolle auf. Das passt nicht in mein "Geschäftsmodell".

Die Finnen die AQuA entwickelt haben sind da etwas bodenständiger.
Der Preis pro Lizenz ist dort zwar nur geringfügig günstiger, aber ich kann mit 700 EUR "Werkzeugkosten" starten anstatt mit 10000. Ergo muss ich dem Kunden auch nur 700 Materialkosten weiterberechnen.

Sicher wollen beide Library Lieferanten auch jährliche Wartungsgebühren haben.
Spätestens da wird PSEQ völlig uninteressant für mich.

[Namenloser]

Zitat:

Zitat von jensw_2000 (Beitrag 1226911)

Wenn ich als kleiner Entwickler ein Programm schreibe, das voraussetzt, dass der Kunde zusätzlich deren Lizenzen kaufen muss, dann erwarte ich eine entgegenkommende und leicht gebeugte Haltung von denen. Nicht umgekehrt. Schließlich schreibe ich für den Lieferanten "kostenlos" ein Programm, dass ihm automatisch Lizenzgebühren in die Kasse bringt.

Was soll dieses Basispaket mit 5x5 Lizenzen? Einzellizenzen zum stark vergünstigtem NFR Preis pro Entwickler wären aus meiner Sicht fair. Ich muss mit meiner Arbeit auch noch ein paar Euro verdienen und kann nicht mehr Geld ins Werkzeug stecken als unter dem Strich übrig bleibt.
Zusätzlich sind die auch nicht bereit ihre Lizenzen direkt mit dem Kunden abzurechen und zwingen mir so auch noch die Händer Rolle auf. Das passt nicht in mein "Geschäftsmodell".

Aber die Kosten gibst du doch an den Kunden weiter? Wieso interessiert es dich da, ob das Tool jetzt 1 000 € oder 10 000 € kostet? Ist doch Sache des Kunden, wie viel er bezahlen möchte...