(テサ2)という訳で、今月はちょっと忙しくて、他のことに手が回らない。
2007年4月25日水曜日
2007年3月29日木曜日
2007年3月15日木曜日
galatea talk (その6)
Segmentation Faultの原因がわかった。
リンクしている libxsltのバージョンが、gentoo デフォールトの、1.1.17 ではだめで、1.1.20を使わないといけない、ということらしい。
とりあえず、動くようにはなった :-)
リンクしている libxsltのバージョンが、gentoo デフォールトの、1.1.17 ではだめで、1.1.20を使わないといけない、ということらしい。
とりあえず、動くようにはなった :-)
galatea talk (その5)
メモリが足りないのかと思って、K6 160MB のPCから、Celeron 512MB のPCに変更して、再度 chaone を試してみるが、やはり同じところで segmentation fault が発生する。つまり、Memory不足じゃなかった、ということ。
じゃ、何が悪いんだよ、ってことで、mach=i586 のオプションを mach=i686に替えて build world の実行中。
てっきり、linuxで開発しているものだとばかり思っていたけれど、本当の開発機は、SolarisやWindowsなのかも。
う〜ん。gentoo の雰囲気は、そう悪くない(というか、BSDよりだね)のだけれど、他のディストリビューションで動くアプリケーションが簡単に動かないとなると、やっぱり乗り換えられないなぁ。
じゃ、何が悪いんだよ、ってことで、mach=i586 のオプションを mach=i686に替えて build world の実行中。
てっきり、linuxで開発しているものだとばかり思っていたけれど、本当の開発機は、SolarisやWindowsなのかも。
う〜ん。gentoo の雰囲気は、そう悪くない(というか、BSDよりだね)のだけれど、他のディストリビューションで動くアプリケーションが簡単に動かないとなると、やっぱり乗り換えられないなぁ。
2007年3月14日水曜日
unidic-1.2
galatea talk で、振り仮名のついたテキストを入力することができるのだが、これの出来があまりよくない。いろいろ試行錯誤をしてみると、どうも前段階の chasen が使っている unidic にその原因があるようだ。(註:chasenの標準の辞書は ipadic だが、galatea talk では、専用の辞書 unidic を使う)
動詞の語幹に振り仮名をつけると(!これは、ごく普通の振り仮名のつけ方だと思う)活用語尾が活用語尾として認識してくれない。つまり、「食べる」にルビを振るとき、「食(た)べる」ではだめで、「食べ(たべ)る」と振らないと、「べ」が未定義語となってしまう。しかも、『ひらかなの標準の読みが定義されていない』。結局辞書に定義されていない言葉が無音扱いとなって「食(た)べる」とルビを振ると、「タ(pause)ル」となてしまう。
文語の辞書もあまりよくない。「給ふ」が辞書になくて、「給う」で登録されている。他のハ行四段活用動詞が登録されていない訳ではなく、なぜか「給ふ」だけが、ア行に登録されている。
まあ、オープンソースだから、いやなら自分で直せ、ということか。。。
動詞の語幹に振り仮名をつけると(!これは、ごく普通の振り仮名のつけ方だと思う)活用語尾が活用語尾として認識してくれない。つまり、「食べる」にルビを振るとき、「食(た)べる」ではだめで、「食べ(たべ)る」と振らないと、「べ」が未定義語となってしまう。しかも、『ひらかなの標準の読みが定義されていない』。結局辞書に定義されていない言葉が無音扱いとなって「食(た)べる」とルビを振ると、「タ(pause)ル」となてしまう。
文語の辞書もあまりよくない。「給ふ」が辞書になくて、「給う」で登録されている。他のハ行四段活用動詞が登録されていない訳ではなく、なぜか「給ふ」だけが、ア行に登録されている。
まあ、オープンソースだから、いやなら自分で直せ、ということか。。。
2007年2月25日日曜日
galatea talk (その4)
gtalkは、chasenとchaoneというプログラムを補助に呼び出しているのだが、どうも、このchaoneというプログラムが、メモリ食いのようで、Segmentation faultを引き起こす。
160MBのメモリでは処理しきらないようだ。(一応 swapとして 256MBは用意してあるのだが、swapは使っていないみたいだ )
結局、動作優先で用意した gentoo linux(メモリ160MB)では動作せず、実稼働用のFreeBSD(メモリ384MB)上の方が、安定動作という皮肉な結果に。
(もちろん、FreeBSD上で動かすには、何箇所か修正を加える必要がある)
chaoneの処理部分だけ、別の機械上で処理した結果を、上のgentoo linuxにもってきて処理を続行させれば、発音するので、gtalkそのもの問題ではないのだろう。たぶん、chaoneが使用している xsltあたりがメモリ食いなのだと思う。
でも、せいぜい 1MB程度しかない音声データで、これだけの品質の音声が合成できるというのは、すごい。
160MBのメモリでは処理しきらないようだ。(一応 swapとして 256MBは用意してあるのだが、swapは使っていないみたいだ )
結局、動作優先で用意した gentoo linux(メモリ160MB)では動作せず、実稼働用のFreeBSD(メモリ384MB)上の方が、安定動作という皮肉な結果に。
(もちろん、FreeBSD上で動かすには、何箇所か修正を加える必要がある)
chaoneの処理部分だけ、別の機械上で処理した結果を、上のgentoo linuxにもってきて処理を続行させれば、発音するので、gtalkそのもの問題ではないのだろう。たぶん、chaoneが使用している xsltあたりがメモリ食いなのだと思う。
でも、せいぜい 1MB程度しかない音声データで、これだけの品質の音声が合成できるというのは、すごい。
2007年2月24日土曜日
galatea talk (その3)
gtalk (galatea talk の音声合成部分)を、比較的新しい、2006/10/23版に取り替えてみた。
sil[10] h[70] a[65] j[75] i[60] m[60] e[65] n[45] i[75] k[85] o[60] t[65] o[65] b[50] a[70] g[50] a[100] a[75] cl[90] t[110] a[90] sil[480] sil[475] k[125] o[70] t[65] o[65] b[50] a[85] w[60] a[75] k[85] a[65] m[60] i[65] t[90] o[75] t[80] o[65] m[60] o[65] n[45] i[85] a[75] cl[90] t[110] a[90] sil[480] sil[475] k[125] o[70] t[65] o[65] b[50] a[85] w[60] a[170] k[85] a[65] m[60] i[65] d[50] e[80] a[85] cl[90] t[110] a[90] sil[10]
だいぶ、聞きやすくなっている。カミの部分は、最初のが、
k[85] a[65] m[60] i[65]
後のも、
k[85] a[65] m[60] i[65]。
賢くなったのかどうかは、他のサンプルも聞いてみないとわからないけれど。
sil[10] h[70] a[65] j[75] i[60] m[60] e[65] n[45] i[75] k[85] o[60] t[65] o[65] b[50] a[70] g[50] a[100] a[75] cl[90] t[110] a[90] sil[480] sil[475] k[125] o[70] t[65] o[65] b[50] a[85] w[60] a[75] k[85] a[65] m[60] i[65] t[90] o[75] t[80] o[65] m[60] o[65] n[45] i[85] a[75] cl[90] t[110] a[90] sil[480] sil[475] k[125] o[70] t[65] o[65] b[50] a[85] w[60] a[170] k[85] a[65] m[60] i[65] d[50] e[80] a[85] cl[90] t[110] a[90] sil[10]
だいぶ、聞きやすくなっている。カミの部分は、最初のが、
k[85] a[65] m[60] i[65]
後のも、
k[85] a[65] m[60] i[65]。
賢くなったのかどうかは、他のサンプルも聞いてみないとわからないけれど。
登録:
投稿 (Atom)
