NHKの大河ドラマは、戦国時代か幕末明治期を扱うことが殆どです。その時期の有名人は放送されてしまっているので、主人公を選んでドラマを組み立てるのが大変なんじゃないかと思います。特定の地域では有名な人物はたくさんいると思いますが、全国的な知名度が高くないと視聴率が落ちて「失敗作」とか評価されてしまうでしょう。
同時に、最近の大河ドラマは時代考証が綿密になってきているようです。歴史研究などの新しい知見を取り込んでいたり、当時の風習や言葉遣いなども出来る範囲で再現しようとしているようです。
例えば、斎藤道三の娘で織田信長に嫁いだ女性を、昔は「濃姫」としていましたが、最近は「帰蝶」と呼んでいたりします。名前が本当に帰蝶だったのか確かではないと思いますし、現代ドラマの家族関係のように親子や夫婦の間柄で帰蝶という名前が呼び合っていたのか、怪しいところです。
さらに言えばドラマでは当時の実名（いわゆる諱）を使って会話を繰り広げていますが、ここも純粋に当時の状況を再現しようとすれば怪しいところです。配下の武将が主君の名を呼びかける場合や、同盟している大名同士において、実名が使われる状況は無かったのではないかと思います。諱は忌み名であり、そう容易く口に出せるようなものではなかったはずです。しかしドラマで当時の会話を忠実に再現しすぎると、史学の専門家以外は視ていても何のことはサッパリ分からない会話になってしまって、「ドラマ的」に面白くないでしょう。
同じような状況はNHKの朝ドラにも言えると思います。今は「ひよっこ」が放送されています。この作品は従来と大きく違って、純粋な創作であり、実在するモデルがいません。しかし舞台設定は茨城県北部ということになっているので、茨城県北部を「思わせる」ような方言で会話しているようです。
ここで先程述べた大河ドラマと類似した状況が生じます。つまり、茨城県っぽい方言であっても、本当に茨城県北部で使われていた方言ではないだろうと思われることです。
どういう意味かというと、イントネーションとか方言らしい言葉を使うことで、茨城県「らしさ」を表現することができます。しかし方言というのはイントネーションだけではありません。使われている語彙なども重要です。方言に地域限定性が強いほど、使われている語彙は全国的に馴染みの薄いものになります。それが全国で放送されるドラマに現れれば、視聴者からすると「何を言っているの？」ということになってしまうのではないでしょうか。これではドラマ（娯楽作品）になりません。
そういわけで、大河ドラマにしろ朝ドラにしろ、純粋に歴史的であったり、純粋に地方色を表現したりしているわけではなく、視聴者かイメージできる範囲に抑えてあるのではないかと思います。
2017-07-31
2017-07-18
オーディオデバイスが認識された
dynabook SS SX/15AにインストールしたNetBSD/i386のカーネルを8.99.1にしたら、7.0.1の頃には認識されなかったオーディオデバイスが、認識されていました。
昨年10月頃にNetBSD 7.0.1をインストールした時のブートメッセージは次のようになっていました。
ところがNetBSD 8.99.1にしたところ、うまく認識できているようです。
この問題はkern/51920として2017年1月27日付でPRを送っていて、今でもopenのまま放置されています。しかし最新カーネルでは認識できているので、実質的には解決しました。
昨年10月頃にNetBSD 7.0.1をインストールした時のブートメッセージは次のようになっていました。
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: couldn't map mmio space
ところがNetBSD 8.99.1にしたところ、うまく認識できているようです。
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at msi0 vec 0
hdafg0 at hdaudio0: Realtek Semic ALC262
hdafg0: DAC00 2ch: Speaker [Built-In]
hdafg0: DAC01 2ch: HP Out [Jack]
hdafg0: ADC02 2ch: Mic In [Jack]
hdafg0: ADC03 2ch: Mic In [Built-In]
hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
audio0 at hdafg0: full duplex, playback, capture, mmap, independent
hdafg0: Virtual format configured - Format SLINEAR, precision 16, channels 2, frequency 48000
hdvsmfg at hdaudio0 not configured
この問題はkern/51920として2017年1月27日付でPRを送っていて、今でもopenのまま放置されています。しかし最新カーネルでは認識できているので、実質的には解決しました。
2017-07-15
mono-2.10.9nb20
dynabook SS SX/15Aに入れたNetBSD/i386を実運用していくにあたり、まずは最新版にバージョンアップしておくことにしました。ソースをCVSでカレントの最新版にして、カーネルとユーザーランドを最新化しました。8.99.1になりました。
pkgsrcから入れたアプリケーションも最新版にしておこうと思って、pkg_rolling-replaceを使ってバージョンアップしています。いろいろとトラブルがあって一筋縄ではいかないのですが、少しずつ前進して（いるはず）います。
ところがKeePassで依存しているMonoがビルドできません。次のようなエラーが出てしまいます。
以前ビルドした時（2017年2月11日頃）には問題なかったと思います。この時はmono-2.10.9nb18というバージョンでした。今回はmono-2.10.9nb20と多少バージョンがあがっているようです。
両者の違いをcvswebで確認してみましたが、ビルドエラーの原因となりそうな箇所は見つけられませんでした。
自前でビルド出来ないのであれば、既にビルド済みのバイナリを入手して解決しようと思ったのですが、NetBSDのオフィシャルサイトを見てもmono-2.10.9nb20.tgzが見当たりません。mono-2.10.9nb19なら置いてありました。
どうにも困ってしまいましたが、このままではpkg_rolling-replaceを先に進めることができません。緊急避難的な対処方法ですが、mono-2.10.9nb18をmono-2.10.9nb20に見せかけることにしました。どうやらpkgの管理は/var/db/pkgで行っているようです。ここにmono-2.10.9nb18というディレクトリがあったので、試しにmono-2.10.9nb20に名前を変えてみました。どうやらうまくいったようです。
今回はオリジナルのバージョンがmono-2.10.9で変わっていなかったので、このような小手先の対処でも問題はないと思います。もしオリジナルバージョンから変わっているのであれば、このような対処方法ではかえって傷口を広げることにことなってしまうでしょう。
pkgsrcから入れたアプリケーションも最新版にしておこうと思って、pkg_rolling-replaceを使ってバージョンアップしています。いろいろとトラブルがあって一筋縄ではいかないのですが、少しずつ前進して（いるはず）います。
ところがKeePassで依存しているMonoがビルドできません。次のようなエラーが出てしまいます。
MCS [basic] mcs.exe
cp mcs.exe ./../class/lib/basic/mcs.exe
cp: mcs.exe: No such file or directory
../build/executable.make:105: recipe for target '../class/lib/basic/mcs.exe' failed
gmake[7]: *** [../class/lib/basic/mcs.exe] Error 1
gmake[7]: Leaving directory '/usr/pkgsrc/lang/mono2/work/mono-2.10.9/mcs/mcs'
../build/rules.make:132: recipe for target 'do-all' failed
gmake[6]: *** [do-all] Error 2
以前ビルドした時（2017年2月11日頃）には問題なかったと思います。この時はmono-2.10.9nb18というバージョンでした。今回はmono-2.10.9nb20と多少バージョンがあがっているようです。
両者の違いをcvswebで確認してみましたが、ビルドエラーの原因となりそうな箇所は見つけられませんでした。
自前でビルド出来ないのであれば、既にビルド済みのバイナリを入手して解決しようと思ったのですが、NetBSDのオフィシャルサイトを見てもmono-2.10.9nb20.tgzが見当たりません。mono-2.10.9nb19なら置いてありました。
どうにも困ってしまいましたが、このままではpkg_rolling-replaceを先に進めることができません。緊急避難的な対処方法ですが、mono-2.10.9nb18をmono-2.10.9nb20に見せかけることにしました。どうやらpkgの管理は/var/db/pkgで行っているようです。ここにmono-2.10.9nb18というディレクトリがあったので、試しにmono-2.10.9nb20に名前を変えてみました。どうやらうまくいったようです。
今回はオリジナルのバージョンがmono-2.10.9で変わっていなかったので、このような小手先の対処でも問題はないと思います。もしオリジナルバージョンから変わっているのであれば、このような対処方法ではかえって傷口を広げることにことなってしまうでしょう。
2017-07-12
イギリスの社会階層を判断するために
NHKで放送されている「ラジオ英会話」のテキストにはColin Joyceさんによるの「Japanglophilia」というエッセイが掲載されています。2017年7月号は「The Beginner's Guide to Class Spotting, for Non-Britons」というタイトルでした。
イギリスには社会階層が今日でも厳然としてあるそうですが、どのように定義すれば良いのかは簡単ではないようです。筆者は次のように書いています。
イギリスには社会階層が今日でも厳然としてあるそうですが、どのように定義すれば良いのかは簡単ではないようです。筆者は次のように書いています。
It isn't just about how much money you have; you may still be considered lower class because of your accent even if you have become a millionaire. But also it's not just about family background. Nor is it just about your level of education. It's a confusing mixture of many things.社会階層を示すために何に着目すればよいのか難しそうですが、筆者が思いついたのは次のようなことだそうです。
- Aitch Aspiration
- The Letter Aitch
- Olives
- Tea and Coffee
- Net Curtains
- Wordings
- Appearance
- Education
- Sport
- Supermarket
2017-07-11
Tera termの終焉とRLogin
*BSDやLinuxなどにWindowsからリモート・ログインするためには、昔からTera termを利用していました。オリジナルのTera termは1990年代に登場しました。当時はVT382エミュレーションができて、かつ実用に耐えるフリーの端末ソフトが他には見当たらなかったので、あっという間に広まった記憶があります。
その後オリジナルの開発が止まりましたが、別のチームによってメンテナンスが再開され、それ以来ずっとTera termを利用し続けてきました。
昔はU*IXの文字コードは日本語EUCを使うことが多かったと思いますが、最近ではUTF-8が使われているようです。Tera termでもUTF-8は利用できることになっていますが、僕自身はEUCで環境を整えているのでUTF-8を利用したことはありませんでした。
Linuxを利用する必要が出てきて、UTF-8のロケールで利用しなければならなくなりましたが、何故か文字が化けてしまいます。Webで調べてみた限りでは、端末設定で送受信の文字コードを「UTF-8」にすれば良いだけらしいのですが、上手くいきませんでした。
さらに調べてみると、Tera termではUTF-8の取り扱いに問題があるような情報も散見されました。もし不具合があってUTF-8の使用に耐えられないのであれば、もっと騒ぎになっていそうなものですが、世間ではTera termでもUTF-8で運用できているようです。僕の環境では文字化けしてしまうので、何か設定があるのでしょうが、残念ながら見つけられませんでした。
困ったことになったと思っていたら、偶然RLoginという端末エミュレータを見つけました。試しに使ってみたところ、何の苦もなくUTF-8のロケールの環境で利用できました。
Tera termの大きなアドバンテージはVT382とかVT520などの、それほどメジャーではない端末をサポートしていることです。RLoginではVT100しかサポートしないようですが、実際問題としてはそれで十分でしょう。各種VT端末のエミュレーションを実際に必要とするのはOpenVMSを利用する時ぐらいではないかと思います。
長年に亘りTera termを利用してきましたが、今後はRLoginに移行していくことになりそうです。しかしOpenVMSを利用することがありますから、その時にはTera termを使うことになるでしょう。
その後オリジナルの開発が止まりましたが、別のチームによってメンテナンスが再開され、それ以来ずっとTera termを利用し続けてきました。
昔はU*IXの文字コードは日本語EUCを使うことが多かったと思いますが、最近ではUTF-8が使われているようです。Tera termでもUTF-8は利用できることになっていますが、僕自身はEUCで環境を整えているのでUTF-8を利用したことはありませんでした。
Linuxを利用する必要が出てきて、UTF-8のロケールで利用しなければならなくなりましたが、何故か文字が化けてしまいます。Webで調べてみた限りでは、端末設定で送受信の文字コードを「UTF-8」にすれば良いだけらしいのですが、上手くいきませんでした。
さらに調べてみると、Tera termではUTF-8の取り扱いに問題があるような情報も散見されました。もし不具合があってUTF-8の使用に耐えられないのであれば、もっと騒ぎになっていそうなものですが、世間ではTera termでもUTF-8で運用できているようです。僕の環境では文字化けしてしまうので、何か設定があるのでしょうが、残念ながら見つけられませんでした。
困ったことになったと思っていたら、偶然RLoginという端末エミュレータを見つけました。試しに使ってみたところ、何の苦もなくUTF-8のロケールの環境で利用できました。
Tera termの大きなアドバンテージはVT382とかVT520などの、それほどメジャーではない端末をサポートしていることです。RLoginではVT100しかサポートしないようですが、実際問題としてはそれで十分でしょう。各種VT端末のエミュレーションを実際に必要とするのはOpenVMSを利用する時ぐらいではないかと思います。
長年に亘りTera termを利用してきましたが、今後はRLoginに移行していくことになりそうです。しかしOpenVMSを利用することがありますから、その時にはTera termを使うことになるでしょう。
userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]
dynabook SS SX/15AのOSをNetBSD/i386に入れ換えましたが、作業上の都合によりOSのバージョンが多少旧くなってしまいました。NetBSD-currentでは8.99.1が出ているので、ソースからカーネルとユーザーランドをビルドして総入れ替えをおこないました。
入れ替えが完了した後で、tera termからSSHの鍵認証でログインしようとしたら、何故か撥ねられてしまいます。入れ換え前までは問題なく認証できていたので、いきなり認証できなくなったのは困りました。
調べてみると/var/log/authlogに表題のようなログが吐かれています。これを頼りに情報を探ると「SSH鍵の暗号化方式を強化してみた。」にたどり着きました。どうやらDSA鍵はデフォルトでは使えなくなっているようです。昔はDSA鍵を作っておくのが推奨されていましたが、時代が変わって今ではed25519鍵が最強なのだそうです。
昔DSA鍵を作成した時にはASTEC-Xを利用してWindows側の共有鍵と秘密鍵を作成しました。しかし最近はASTEC-Xの更新がされていないので、鍵を生成するには不適当です。どうしたものかと思って調べてみると、Tera termで鍵を生成できるようなので、これでed25519鍵を作ることにしました。
入れ替えが完了した後で、tera termからSSHの鍵認証でログインしようとしたら、何故か撥ねられてしまいます。入れ換え前までは問題なく認証できていたので、いきなり認証できなくなったのは困りました。
調べてみると/var/log/authlogに表題のようなログが吐かれています。これを頼りに情報を探ると「SSH鍵の暗号化方式を強化してみた。」にたどり着きました。どうやらDSA鍵はデフォルトでは使えなくなっているようです。昔はDSA鍵を作っておくのが推奨されていましたが、時代が変わって今ではed25519鍵が最強なのだそうです。
昔DSA鍵を作成した時にはASTEC-Xを利用してWindows側の共有鍵と秘密鍵を作成しました。しかし最近はASTEC-Xの更新がされていないので、鍵を生成するには不適当です。どうしたものかと思って調べてみると、Tera termで鍵を生成できるようなので、これでed25519鍵を作ることにしました。
2017-07-04
音声合成を使ったニュース
愛媛県松山市に本社を構える南海放送が「ラジオでは全国初！自動音声システムによるニュース放送を実施」というプレスリリースを発表しています。個人的な意見としてはラジオ放送だし「バーチャルアナウンサー」は設定しなくてもいいんじゃないかと思いますが、それは良しとしましょう。
音声合成技術の発達を考えると、遅かれ早かれこういうものが出てくると思っていました。
ニュース（報道番組）というものが、アナウンサーが原稿を読むだけじゃなくて、「コメンテーター」と称する人が何か発言したり、「芸能人」が出てきてみたり、「女子アナ」という女性のアナウンサーという意味ではない傾向があったりして、多様な番組作りがおこなわれています。
しかしラジオの場合は、声で勝負するしかないので、音声合成技術の役割は大きいでしょう。しかも事実を淡々と伝えるような番組（例えばNHKラジオ第2放送の気象通報など） であれば、実際の職員が原稿を読むより、むしろ音声合成の出番なんじゃないかと思います。
これがテレビのニュース番組になってくると、声（音声合成）だけでは済まなくなってくるでしょう。初音ミク（仮想キャラクタならば、ゆるキャラでも、人形浄瑠璃でも何でも良いですが）みたいなイメージキャラクターが出てこないと、画面が不自然でしょう。
音声合成技術がもっと進化すれば、もしかするとアニメーションの声優に影響を与えるかもしれないと考えています。昔からあるアニメ、例えばドラえもん、サザエさん、ルパン三世などは、主演声優が引退した場合、同じような声を持ち、同じような話し方ができる声優を探してくる傾向があるようです。もしこれを音声合成技術で解決できるとしたら、未来永劫に亘って従来からのファンを安心させることができるでしょう。 もっとも進化は止まったとも考えられるので、墨守するだけで面白くない世界になりそうですが。
音声合成技術の発達を考えると、遅かれ早かれこういうものが出てくると思っていました。
ニュース（報道番組）というものが、アナウンサーが原稿を読むだけじゃなくて、「コメンテーター」と称する人が何か発言したり、「芸能人」が出てきてみたり、「女子アナ」という女性のアナウンサーという意味ではない傾向があったりして、多様な番組作りがおこなわれています。
しかしラジオの場合は、声で勝負するしかないので、音声合成技術の役割は大きいでしょう。しかも事実を淡々と伝えるような番組（例えばNHKラジオ第2放送の気象通報など） であれば、実際の職員が原稿を読むより、むしろ音声合成の出番なんじゃないかと思います。
これがテレビのニュース番組になってくると、声（音声合成）だけでは済まなくなってくるでしょう。初音ミク（仮想キャラクタならば、ゆるキャラでも、人形浄瑠璃でも何でも良いですが）みたいなイメージキャラクターが出てこないと、画面が不自然でしょう。
音声合成技術がもっと進化すれば、もしかするとアニメーションの声優に影響を与えるかもしれないと考えています。昔からあるアニメ、例えばドラえもん、サザエさん、ルパン三世などは、主演声優が引退した場合、同じような声を持ち、同じような話し方ができる声優を探してくる傾向があるようです。もしこれを音声合成技術で解決できるとしたら、未来永劫に亘って従来からのファンを安心させることができるでしょう。 もっとも進化は止まったとも考えられるので、墨守するだけで面白くない世界になりそうですが。
登録:
投稿 (Atom)