Audio Files vergleichen und Qualität bewerten

[jensw_2000]

Ich habe heute eine Anfrage bekommen bei der ich völlig auf dem Schlauch stehe.

Ein lokaler VoIP Telefonie Carrier möchte neben den Prüfungen die dort amtsseitig ohnehin schon laufen automatisierte Qualitätschecks zu allen seinen Knotenpunkten machen.

Dazu will er einen meiner fertigen ISDN Powerdialer "missbrauchen".
Der Dialer soll ISDN-seitig an eine Fritzbox angeschlossen werden und in gewissen Intervallen über die VoIP Strecke Testanrufe zu definierte Endpunkten (Anrufbeantworter) in den Vermittlungsstellen machen.
Der Audiostream des Anrufbeantworters wird vom Dialer mitgeschnitten und als Audiofile gespeichert.

Soweit ist das fertig und kein Problem...

Jetzt möchte mein Kunde das originale Audiofile des Anrufbeantworters als Referenz nehmen und mit den Audio-Mitschnitten der Testanrufe vergleichen.
Also Qualitätsverlust, Knacken, dumpfer, Verzerrungen, Aussetzer, zu laut, zu leise usw. erkennen und auswerten.

Es geht nicht um die fachliche Bewertung des VoIP Signals (Jitter usw.) sondern im einen reinen Vergleichstest.
Sprich: "Seit einer Woche nimmt die Gesprächsqualität zum Knoten XYZ deutlich ab. Erkannt an folgenden Punkten ..."

Beide Audiofiles (AB und Mitschnitt) sind G729a Audiofiles (8 Bit, 8K Sample-Rate).

Ist so etwas realisierbar?
Wie? Was brauche ich dafür?


Grüße
Jens

[Furtbichler]

Keine Ahnung, aber über eine Frequenzanalyse (FFT) sollte sich das lösen lassen. Irgendwie die Frequenzbereiche vergleichen. Wenn Du prozentuale Angaben machen sollst, muss man vereinbaren, was verglichen wird.

[jensw_2000]

Nachdem ich den Wikipedia Artikel und das hier zum Thema FFT gelesen habe, bin ich mir sicher, dass ich Input auf viel viel niedrigerem Level benötige.
So wenig Infos habe ich schon lange nicht mehr aus einem Text entnehmen können. Jetzt fühle ich mich klein, dumm und deprimiert..:cry: Keine Ahnung wovon die da sprechen...

Gibt es keine APIs oder fertigen DLLs, die zwei Audiofiles miteinander vergleichen können und -keine Ahnung- die Anzahl der "Störungen" bzw. prozentualen Abweichungen ermitteln?
Das Test-Audiofile auf dem AB könnte z.B. einen sauberer Rechteck-Impuls abspielen.
Wenn (übertrieben gesagt) ein unsauberer Sinus mit Interferenzen, Peaks und Aussetzern zurückkommt ist die Verbindung ganz sicher schlecht ...

Ist irgendein Freelancer bei diesem Thema total fit und möchte eine threadsichere detaillierte Delphi "Audio-Vergleichsanalyse API" als Subauftragsnehmer annehmen? Also falls mein Kunde unterschreibt...:)

[Perlsau]

Aus meiner eigenen Erfahrung mit Voice-over-IP kann ich sagen, daß die größte Unannehmlichkeit darin besteht, wenn Pakete verlorengehen, was sich darin niederschlägt, daß Gesprächsteile fehlen. Entsprechende Vergleichsmethoden lassen sich vermutlich relativ leicht in Delphi umsetzen.

Offenbar gibt es zahlreiche Tools, die Audiodateien vergleichen. Vielleicht findest du ja eines, das irgend eine Form des Ergebnis-Exports ermöglicht, den du dann mit deinem Programm auswerten kannst und das du am besten noch via Ole-Automation steuern kannst.

Die Alternative wäre dann natürlich, selber entsprechende Vergleichs-Methoden zu entwickeln. In der Entwickler-Ecke gibt es zwei mir bekannte Beiträge zu Frequenzanalyse im Zusammenhang mit einer Musik-Erkennungs-Software. Vielleicht hilft dir das weiter: Frequenzanalyse und MusicInfoFinder. Und/oder du schreibst mal den Entwickler GTA-Place an, vielleicht hat der ja Interesse, das für dich zu machen.

[Namenloser]

Fertige FFT-Implementierungen gibt es zuhauf, unter anderem eine hier in der Codelib. Die FFT schlüsselt dir dein Signal in die einzelnen Frequenzen auf. Das machst du natürlich nicht nur einmal, sondern Abschnittsweise über die ganze Audio-Datei. Damit kriegst du einen Frequenzverlauf.

Das kann man sogar graphisch darstellen wie im Anhang. Die Visualisierung stammt aus dem Musikplayer Foobar2000, auf der X-Achse ist die Zeit und auf der Y-Achse die Frequenzen. Je stärker eine Frequenz zu einem bestimmten Zeitpunkt präsent ist, desto heller das Pixel...

Als Distanzmaß würde sich vielleicht die Earth mover’s distance eignen.

[nahpets]

Hallo,

von dem Thema habe ich keine Ahnung, trotzdem gibt es ein paar unausgegorene Gedanken dazu, eventuell hilfts ja als Denkanstoß.

Es gibt da die BASS.dll, die hier im Forum immer wieder mal Erwähnung findet.

Die BASS.dll kann auch FFT-Daten liefern, die z. B. für die graphische Anzeige genutzt werden können. Ebenfalls kann ein Level geliefert werden, der die Lautstärke repräsentiert.

Da das ja alles nur numerische Werte sind, könnte ich mir folgendes vorstellen:

Das gewünschte Testsignal wiedergeben und mit der BASS.dll die Werte z. B. alle 20 Millisekunden in eine (Datenbank)-Tabelle speichern, als Referenz.

Wenn nun ein Testanruf aufgezeichnet wird, diesen ebenfalls wiedergeben und auch hier per BASS.dll die Werte in einer (Datenbank)-Tabelle speichern. Im Idealfall müssten ja identische Ergebnisse vorliegen.

Nun müsste man "nur noch" die Differenz dieser beiden Tabellen ermitteln, was mit purer Mathematik möglich sein sollte. (Datenbank hätte den Vorteil, es ginge mit SQL und es könnten beliebig viele Testanrufe gespeichert werden.)
Bin jetzt mal naiv und behaupte: Je größer die numerischen Abweichungen, umso schlechter das Ergebnis des Testanrufes.

Wenn man als Test nun halt nacheinander mehrere unterschiedlich hohe und unterschiedlich laute Töne sendet, müsste man eigentlich schon eine Basis für einen (für Deine Anforderung) ausreichenden Vergleich bekommen. Es soll ja kein Qualitätsvergleich von einer Sinfonie, einmal auf Schellack aufgenommen, einmal als CD und einmal als MP3... vorgenommen werden, sondern es sollen Signale verglichen werden, die Du selbst bestimmen kannst.

Schau Dir mal das zur BASS.dll gehörende Beispielprogramm livespec an, das Programm stellt die gerade (von welchem Programm auch immer) am PC wiedergebenen "Geräusche" grafisch dar. Es nutzt dazu die FFT-Daten. Hier sollte eigenlich durch ein Abspeichern der Daten des Originals und der Daten der Testanrufe ein Vergleich möglich sein.

Habe mal drei Bilder mit der Anzeige der FFT-Daten der BASS.dll mit meinem Player angehängt. Bei klar definierten Testsignalen müsste eine derartige Anzeige eigentlich an bestimmten Stellen immer die gleichen, typischen Signale anzeigen.

[Medium]

Was, egal welchen Weg man nachher nimmt, unbedingt allen Beteiligten klar sein muss: Die Bewertung wird objektiv extrem schwierig sein. Gerade da die üblichen Kompressionsverfahren ziemlich adaptiv sind, und unterschiedlich gut auf die Menschliche Stimme zugeschnitten, wird man mit synthetischen Tests auch nur recht synthetische Aussagen treffen können, die zwar böse Patzer aufdecken dürften, jedoch sicherlich keine Nuancen, und kaum eine nachvollziehbare in Zahlen ausgedrückte Bewertung eines subjektiven Höreindrucks.
Die FFT erlaubt prinzipiell Analysen im Frequenzraum, aber gerade bei Stimmen sind auch diese noch ziemlich aufwendig. Da die Stimme eine irre Fülle an Frequenzen beinhaltet, ist es fast schon unmöglich für das gute Verständnis wichtige oder hilfreiche Anteile von bloßem Rauschen zu unterscheiden. Für den Höreindruck macht das Welten aus, in Zahlen wird man kaum signifikante Unterscheidungsmekrmale für manche Fälle finden. Ausser eben die offensichtlichen, die stehen aber wohl am Ende von "auf dieser Leitung wird es mit der Zeit schlechter".

Ich bin mal so frei zu behaupten, dass man nicht viel weiter als bis zur Erkennung von kompletten Aussetzern und extremen Abweichungen vom Original damit kommt. Bevor man da allzuviel Arbeit rein steckt, könnte es am Ende gar günstiger kommen, wenn sich wirklich mal einer einen Tag hinsetzt und die Testanrufe mit eigenen Ohren bewertet.

Warum komme ich zu so einer Aussage? Ich habe mich für meine Bachelorarbeit mit dem Thema Bildkompression beschäftigt, wofür ich Mechanismen gesucht habe, diverse Algos in ihren Ergebnissen miteinander bzgl. des wahrgenommenen Bildeindrucks zu vergleichen. Eine einfache mittlere quadratische Abweichung z.B. hatte sowohl im Bild- als auch im Frequenzraum fast die gleiche Signifikanz wie eine Zufallsbewertung. Bei meinen Recherchen bin ich u.a. auch auf eine Seite des JPEG-Kommitees gestoßen (leider finde ich sie nicht mehr, so oft gesucht :(), bei dem sogar die zu dem Ergebnis gekommen sind: In gewissen sehr engen Grenzen, und für Spezialfälle an Bildinhalten lieferten manche Methoden tendenzielle Aussagen, jedoch war keine allgemeingültig für eine subjektiv signifikante Eindrucksbewertung tauglich.
Da Bild und Ton was die reine Signalverarbeitung (und auch die Kompressionsmethoden) angeht gar nicht soooo verschieden voneinander sind, glaube ich hier durchaus Rückschlüsse ziehen zu dürfen.


Was man z.B. denken könnte, was aber dank der Kompression genau 0 Aussagekraft hat ist: Man nehme ein Testsignal, dass einfach nacheinander eine Reihe von Sinuswellen verschiedener Frequenz abspielt. Jetzt könnte man die Aufnahme mit dem Original vergleichen, und so Dinge versuchen wie: "Aha, Frequenz X und Y sind tendenziell leiser als sie sollten." - Trugschluss. Das sog. Psycho-Akustische Modell der meisten modernen Kompressionsverfahren nutzt eben gerade eine Bandfiltermethode, mit der die "vermutlich weniger relevanten" Frequenzbänder aus einem Signal entfernt werden. Oft sogar alle paar Millisekunden auf das konkrete Signal genau zugeschnitten und neu gewichtet. In der Hoffnung, dass deren Fehlen für den Höreindruck kaum einen Unterschied macht. In Zahlen lassen sich zuweilen riesige Abweichungen ausmachen, aber wirklich deutlich hören würde die keiner. Und gerade die Voice-Codecs sind hier ausgeprochen trickreich unterwegs.
Um also ein zumindest näherungsweise relevantes Ergebnis zu bekommen, ist mathematisch echt schon was los. Zudem müsste man exakt wissen mit welchem Codec übertragen wurde, mit welchen Settings, und man müsste im Detail wissen wie er arbeitet. Und selbst dann müsste man sich noch auf den Fall Sprache beschränken. (Manch eine Stimme kommt ganz prima durch eine Kompression, die ein Pop-Lied völlig verhackstücken würde, und umgekehrt. Je nach dem.)

Ich würde den Auftraggeber zumindest mal über die potenzielle Tragweite seiner Anforderung informieren, und ich würde mir - der zumindest ein Basiswissen (wirklich nicht mehr) von Signalverarbeitung hat - nicht zutrauen hier eine (eigene) Lösung anzubieten, die ich guten Gewissens verkaufen kann.

[jensw_2000]

Das sieht alles sehr vielversprechend aus und wird mich die nächsten Stunden und Tage fesseln ...

Parallel habe ich aber trotzdem den Audio-Spezi aus der Entwickler-Ecke angeschrieben.
Mal schauen ob er antwortet und was er kostet.

Zur Bass.dll habe ich noch eine Frage, bevor ich viel Zeit in die Forschung stecke.

Ich übertreibe mal ein bisschen ...
Das Referenzfile ändert sich nicht, aber die Gegenseite kann ich kaum beeinflussen.
Wenn der Anrufbeantworter auf der anderen Seite erstmal die Kassette zurückspult, ein paar mal klackt bis der Tonkopf in der richtigen Position ist und danach erst das Prüf-File abspielt, wird ein rein numerischer Vergleich ab Stream-Beginn nichts bringen.

Kann man die Audiofiles mit der Bass.dll öffnen und dann bis zum einem definierten Erkennungssignal "vorspulen", um den Vergleichs-Startpunkt zu synchronisieren?

[jensw_2000]

PS:
@Medium >> Das hört sich nicht gut an. Gute Argumente.
Hälst Du den Vergleich auch bei einer sehr einfachen Rechteck-Frequenz für nahezu unmöglich?
Wir können vor der eigentlichen Arbeit schon ein paar Testdateien über die VoIP Leitung schicken und schauen, welche Frequenzen durch die Codecs gefiltert werden und somit nicht im fertigen Referenzfile enthalten sein dürfen.

[Medium]

Das ist die Krux: So eine Aussage wird unmöglich sein. Ein paar Bänder werden sicherlich pauschal "abgeschoren", im interessanten Bereich hängt es aber vollständig vom gesamten Rest des Signals (und der Bitrate!) ab, was da wann wo und wie stark ausgelassen wird. 200Hz könnten z.B. isoliert fast 1:1 durchgehen, aber 200Hz in einer Sprachnachricht könnten ggf. komplett entfallen. Das wird i.A. dynamisch entschieden, und kann nicht vorab so einfach ermittelt werden.
Am Rande: Rechtecke sind der Teufel der Signalanalyse. Besonders in einer FFT bereiten einem diese Biester das Maximum an Obertönen, sowohl in Frequenzbreite als auch Amplitude. Sie sind in gewisser Weise fast als das Gegenteil von schönen Sinuswellen anzusehen. (Die einem aus o.g. Gründen aber trotzdem nicht so wirklich weiter helfen.)
Für die sinnvolle Bewertung von Sprache käme man um eine psycho-akustische Analyse nicht wirklich herum fürchte ich, und selbst dabei dürfte es hart werden wirklich aussagekräftige Maßzahlen herauszumodelieren. So einfach wie in der analogen Welt ist es leider nicht :?

[jensw_2000]

OK überzeugt.

Ich bewege mich hier in einem Fachbereich, in dem ich völlig ahnungslos im Dunklen tappe. Das ist keine Basis für ein Kundenprojekt. Mit der Bass.dll werde ich rein interessehalber etwas herumspielen.
Für meinen Kunden finde ich entweder eine stabile und professionelle Lösung von jemandem der voll im Thema steckt, oder ich lehne diesen Teilauftrag ab. Besser als eine angekratzte Reputation.

Ich bin mal gespannt was der "Mann aus der Entwickler-Ecke" so antwortet.
Vergleiche von Audiosignalen scheint sein Lieblingsthema zu sein.
Er hat dort ein Projekt vorgestellt, mit dem er an Hand von "Audio Schnipseln" Musikdateien in Medienbibliotheken findet (ohne Tagging). Dabei passt er für die Vergleiche dynamisch Bitraten usw. an und MP3 Files mit unterschiedlichen Formaten scheinen für ihn auch keine Hürde bei der Suche zu sein.

[nahpets]

Oje, das klingt ja viel komplizierter, als ich mir das vorgestellt habe.

Nichts desto trotz...

Das Referenzfile könnte ja über eine bekannte, intakte Verbindung aufgenommen werden, dann enthält es alles, was "unterwegs" verschlimmbessert und/oder rausgefiltert wurde.

Mit der BASS.dll müsste man auch positionieren können. Die Frage ist nur, wonach soll man dann suchen? Es wird ja eine konkretes Signal "irgendwo" in der Datei gesucht.

Wie funktioniert denn der Testanruf konkret?

Es wird wer angerufen, der geht früher oder später ran und dann kommt irgendwann das zu prüfende Signal.

Das erste Problem wäre also den richtigen "Startzeitpunkt" für die Vergleichsanalyse zu finden.

Könnte man hier hergehen, dass das Testsignal z. B. mit 1 Sekunde 440 Hz anfängt und die Prüfsoftware überließt alles bis zum Ende dieses Tones?
Wobei, wenn das Band zu schnell oder zu langsam läuft, kommen da ja auch keine 440 Hz mehr, bei doppelter Bandgeschwindigkeit 880 Hz, bei Halber nur noch 220 Hz und ansonsten irgendwas so um die 440 Hz herum. Das Problem zieht sich dann natürlich durch die ganze "Aufnahme". Gibt es denn keine Anrufbeantworter für diesen Test, die das "Zeug" digital speichern. Band ist doch langsam Schnee von gestern ;-) Mein Anrufbeantworter hat jedenfalls kein Band mehr ;-)

Deinen Schluss, da einen Profi ranzulassen oder die Finger davon, finde ich absolut in Ordnung. Bei dieser Aufgabenstellung käme ich auch nicht über das Spielniveau hinaus. Für einen professionell auszuführenden Auftrag reicht es da sicherlich bei mir nicht aus.

Eine Beschäftigung mit der BASS.dll lohnt aber trotzdem, man kann damit nette Spielereien machen, sein eigenes Internetradio, 'nen MP3...-Player...

[jensw_2000]

Mit dem "Band" und dem "Anrufbeantworter" auf der Gegenstelle wollte ich -stark übertrieben- ausdrücken, dass ich keinen Einfluss auf den Abspiel-Beginn usw. habe. Die haben da natürlich schon ein "bisschen" Technik rumstehen.. :wink: Ich kenne aber noch Anrufbeantworter mit Kassetten und Telefone mit Wählscheiben. Damit kann die Jugend von heute nicht mehr umgehen. :)

Aber grundsätzlich funktioniert es so, dass mein Dialer über seine ISDN Karte rauswählt und amtsseitig über VoIP zu einem -ich sag mal Anrufbeantworter- in der Vermittlungsstelle geroutet wird.
Der AB nimmt das Gespräch an, mein Dialer erkennt das Connect im ISDN D-Kanal und startet die Aufnahme des Mitschnittes. Nach dem Disconnect werden Referenzfile und Mitschnitt miteinander verglichen.

Hört sich leicht an. Zum Glück habe ich denen gesagt, dass ich mir zu dem Thema erstmal etwas Input holen will, bevor ich was amtliches sage ..:wink:

[Medium]

Musiksuche in kurz: Die Titeldatenbank wird ganz grob sowas beinhalten, was NamenLozer vorhin geposted hat. Jedoch so weit nachbearbeitet, dass nur wesentliche Frequenzen als Marker dienen. Das gleiche wird mit den Schnipseln gemacht, und diese dann mit der Datenbank mittels einer Autokorrelationsfunktion abgeglichen. Der beste Treffer wird ausgegeben.

Der wichtige Unterschied hierbei ist, dass eine Melodie in einem Frequenzspektrum sehr deutlich hervor sticht, egal mit welchem Instrument sie gespielt ist, und egal in welcher Qualität. Die Marker sind da recht deutlich (je nach Genre), und die Autokorrelation erledigt das Finden einer passenden Untermenge in einem Titel. Du könntest mit dieser Methode also gut herausfinden, ob zwei Sprecher in der selben Melodie sprechen, oder gar die selbe Person sind (Stichwort: Formanten), aber wenn es um eine qualitative Bewertung geht, wirft die Methode praktisch nichts ab. (Ausser, dass man erkennen könnte, dass die Gegenstelle stets zu schnell/langsam abspielt, was aber durchaus in hervorragend gut verständlicher Weise sein könnte.)
Die Zielsetzungen sind hier völlig unterschiedlich. Was nicht heissen soll, dass derjenige nicht dennoch ein paar gute Ideen parat haben kann!

[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 :thumb:

[jensw_2000]

@ jsp

Deine Idee finde ich richtig genial.
SAPI verstehe ich auch :wink:
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 ...

[Perlsau]

Zitat:

Zitat von Medium (Beitrag 1226606)

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 :wink:

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

Zitat von Perlsau (Beitrag 1226607)

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:

Zitat von jensw_2000 (Beitrag 1226683)

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

Zitat von Perlsau (Beitrag 1226699)

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.

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