Beiträge von mastermind

    Für Serendipity gibt es leider noch keinen Importer. Du könntest aber zumindest den RSS-Importer benutzen für die Beiträge.

    Dass Du was zerschießt musst Du nicht befürchten, wenn Du den Import erstmal auf einer Testinstallation laufen lässt.

    Eine "OpenSource-Variante", wie Du sie nennst (ich gehe mal davon aus, dass Du damit die zugrundeliegende TTS-Engine meinst, die "frei" sein muss) stricke ich Dir in einer Stunde hinter das Plugin. Tipp: Mach Dir nicht die Mühe mit Festival, nimm z.B. MBROLA (ist zwar kein unit-selection system sondern diphone-basiert, liefert aber auch audio-content). Das hast Du in 15 Minuten am laufen. Danach schreibst Du dir ein Skript mit nen paar LTS-rules, die die grapheme2phoneme Konvertierung zur PHO-file Generierung übernehmen und legst danach eine übliche Intonationskurve über die Phonemsequenz. Schon hast Du ein "freies" TTS-Plugin.

    Nun ja, ich würde es mir insofern noch einfacher machen, als ich mich mit dem Backend gar nicht beschäftigen würde, sondern nur einen Wrapper für eine fertige TTS-Engine schreiben. MBROLA kenne ich und finde ich auch ganz nett, aber zum einen steht es nicht unter einer freien Lizenz, zum anderen wüsste ich nicht, warum ich MBROLA Festival vorziehen sollte. (Das liegt aber daran, dass ich MBROLA zu wenig kenne.) Letztendlich kann man MBROLA-Stimmen ja auch mit Festival nutzen.

    ABER: Darum geht es nicht. Ich weiß nicht, inwieweit Du Dich linguistisch mit dem ganzen Thema auskennst, aber Evaluationskriterien für solche Systeme sind unter Anderem Verständlichkeit und Natürlichkeit der Sprache - hast Du Dir schonmal überlegt, warum TTS noch lange nicht im Alltagsleben angekommen ist? Eben weil die Systeme noch lange nicht "natürlich" klingen. Und genau dort liegt der Hase im Pfeffer: Zeig mir ein frei verfügbares System, welches annähernd die Qualität von kommerziellen Systemen (wie dem von Cepstral) bietet. Du wirst immer einen gewissen, bei MBROLA abhängig von Deinem Preprocessing-Skript sogar recht hohen Grad an Monotonie in den freien synthetischen Stimmen finden - und das will der eifrige Endkunde (in unserem Fall die vielen Blogger da draußen) nicht. Willst Du Dein Blog von einem "Roboter" vorgelesen bekommen? Also dann würde ich es lieber ganz sein lassen.

    Ich kenne mich mit den Basics aus; kann also mit Begriffen wie Phonem, Formant(-ansatz), etc. durchaus was anfangen. (Hatte in der Uni mal ein Hauptseminar zum Thema Sprache.) Aber ich bin natürlich kein Fachmann. Dass die Qualität von Festival und MBROLA mit den TTS-Anwendungen jüngeren Datums nicht konkurrieren können, ist mir natürlich auch klar -- ich würde nie behaupten, dass Festival eine Konkurrenz zu Cepstral darstellen könnte. Ich hatte auch schon das Vergnügen, JAWS und Blindows zu erleben, und ich bin wirklich beeindruckt von der verhältnismäßig natürlichen Sprachwiedergabe. Wie auch immer -- ich glaube, dass eine eher simple, dafür aber kostenlose TTS-Engine bei Bloggern (zahlenmäßig) auf mehr Interesse stoßen würde als eine bessere und kommerzielle.

    Ich denke, die Diskussion führt gerade etwas am Thema hier vorbei, denn eigentlich sollen in diesem Forum ja neue Plugins und deren Entwicklung vorgestellt werden ...

    Nö, wieso... ich denke, wir sind mitten drin im Thema. ;)

    Falls Du aber wirklich ein System mit einer "freien" TTS-Engine zusammenstrickst bin ich sehr an den Ergebnissen interessiert!

    Naja, meine Ankündigung war nicht so ganz ernst gemeint. Aber vielleicht habe ich demnächst ja ein paar müßige Stunden und mache mich mal dran. :)


    Allen anderen Lesern wünsche ich weiterhin viel Spaß mit dem original talkinGBlogs-Plugin ... ;)

    lol, keine Sorge... ich werde Dir weder Namen noch Inhalt Deiner Lösung streitig machen. ;)

    Ich glaube, Du hast nicht ganz verstanden, worauf ich hinaus wollte. Vielleicht habe ich es auch nicht klar genug ausgedrückt.

    Klar, 30 USD sind sicher ein angemessener Preis für eine solche Software. Allerdings würden die meisten Leute es nicht mal kaufen, wenn es nur einen Dollar kosten würde: Es ist für die meisten nicht mehr als ein lustiges Gimmick, und die ganze Abwicklung des Kaufs wäre schon zu viel des Aufwands.

    Ich denke natürlich auch nicht, dass Cepstral ins Blog-Geschäft einsteigen will. Wäre ja auch Quark. Aber genau deshalb meine ich, dass man dennoch eine Symbiose mit der Blogosphäre eingehen könnte: Den Leute, die als Kunden ohnehin nicht in Frage kommen, kann man eine kostenlose, am besten nicht technisch eingeschränkte Version zu bestimmten Konditionen (Backlink o.ä.) geben. Der Gewinn ist der PR-Faktor, der je nach Herangehensweise sicher beachtlich wäre und garantiert auch Auswirkungen auf die primären Geschäftsfelder hätte. Das klappt bei anderen Produkten wie etwa VMware ja auch.

    Aber ich kann natürlich auch verstehen, wenn man als eher konservatives Unternehmen diesen Schritt scheut. Aber man soll sich lieber keine Illusionen machen, dass man im Massenmarkt ernsthaft was verkaufen kann -- auch nicht mit durchaus angemessenen Preisen.

    Im Endeffekt ist es nur ein kleiner Denkanstoß von mir, ich selbst würde das ohnehin nicht nutzen. Zum einen passt es zu keiner meiner Webseiten, zum anderen nutze ich aus Prinzip nur OpenSource-Software.

    Wobei mich das wieder auf eine Idee bringt... vielleicht sollte ich doch noch ein wenig mit Festival rumspielen und eine OpenSource-Variante von talkingBlogs schaffen. ;)

    Man kann von Stefan Esser halten, was man will ;) -- aber ich bin ebenfalls der Meinung, dass der e-Modifikator ein potentielles Sicherheitsrisiko ist und vermieden werden sollte. Schnell ist hier ein Programmierfehler gemacht, der Code in den regulären Ausdruck einschleust. Insofern ist die Meldung berechtigt.

    In diesem speziellen Fall würde ich aber den e-Modifikator lieber zulassen. Aus folgenden Gründen: KSES ist eine externe Bibliothek und wird aktiv gepflegt; auch die WordPress-Implementierung von KSES darf als erprobt gelten. Außerdem ist es nicht empfehlenswert, in den Kern-Dateien von WordPress rumzufummeln, denn beim nächsten Update sind sie sonst weg.

    Ich empfehle daher, die Konfiguration von Suhosin anzupassen, so dass es den e-Modifikator zulässt, oder aber statt Suhosin das klassische HardenedPHP einzusetzen (das hab ich im Einsatz, und es läuft sehr gut).

    Außerdem solltest Du evtl. einen Bugreport im WordPress-Trac bzgl. Suhosin eingeben. Vielleicht kann man es ja doch besser machen.

    Man sollte zusätzlich erwähnen, dass
    (a) dies ein ziemlich konstruiertes Sicherheitsproblem ist, da der "Angreifer" das Recht haben muss, Theme-Dateien zu bearbeiten (was normalerweise nur der Admin darf), und
    (b) dieser Fehler in den aktuellen RCs und damit auch in den bald erscheinenden Versionen bereits behoben ist.

    Im Übrigen bin ich auch der Meinung, dass man Sicherheitsprobleme ruhig posten soll. Wenn Leute wissen, dass es ein Problem gibt, können sie darauf reagieren. Und wem das Ganze nichts sagt, darf es ignorieren.

    In meinem Unternehmen will man MySQL nicht hosten. Sind halt vorschriften die ich einzuhalten habe.

    Alleine das würde mich ja schon zum Kotzen bringen. Was sind denn das für Ignoranten? Man könnte es ja zumindest in einer VM laufen lassen, wenn es doch gar so schlimm ist. :roll:

    Aber mal anders gefragt: Könnt Ihr nicht im Web hosten? Oder soll es nur ein Intranet-Blog sein?

    Ein OpenSource-Blog-System, dass Oracle unterstützt, wirst Du wohl kaum finden. Du könntest höchstens eine eigene Anwendung auf Basis eines geeigneten Frameworks bauen, aber das ist ja auch nicht das Wahre.

    Zitat

    Gibt es eine konkrete Sache an der ich abmachen könnte welche Plugins unterstütz werden und welche nicht? Es wäre für mich nur wichtig das alle Anforderungen abgedeckt sind.

    Nö, kann man nicht sagen. Die meisten Plugins benutzen zwar kein SQL, aber manche tun es doch und benutzen dabei auch MySQL-spezifische SQL-Erweiterungen (wie WP selbst übrigens auch). Und manche Plugins benutzen zwar kein SQL, erwarten aber ein bestimmtes Verhalten, dass auf MySQL-optimierten Querys basiert.

    Es gibt in der Tat einige Ansätze, WordPress auf andere DB-Backends zu portieren. Allerdings wäre Oracle mir neu. Man könnte aber mit relativ wenig Aufwand die Datei wp-includes/db.php umschreiben. In Datei bzw. der Klasse $wpdb sind die meisten Datenbankzugriffe definiert. Es gibt zwar auch an anderen Stellen noch DB-Zugriffe, aber die Syntax ist dann soweit ich weiß ANSI-SQL. Zwei Nachteile hätte ein Oracle-WordPress allerdings: Man müsste schauen, wie es sich bei Upgrades verhält, und man könnte eine Menge an Plugins nicht verwenden.

    Interessant könnte auch eine aktuellere Diskussion um einen PostgreSQL-Port sein.

    Darf man fragen, warum es partout Oracle sein muss?