Audio Files vergleichen und Qualität bewerten

[samso]

Zitat von Perlsau:

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 von samso:

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 von samso:

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 von samso:

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 von samso:

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

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?

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

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

[jensw_2000]

Zitat von Medium:

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 von jensw_2000:

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

[Perlsau]

Zitat von jensw_2000:

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

Wow! Das ist heftig

Zitat von jensw_2000:

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

Zitat von jensw_2000:

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

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