「UTAU プラグインを作りたいという気持ちはあるけど、作り方がわからない」という方のための、UTAU プラグイン開発チュートリアルです。詳細は Zenn をどうぞ。
UTAU

ファンクラブ名の五十音順にリストアップ。
ツールなど
- UTALOADER公式ファンクラブ:デルタさんの音楽アップローダー。
- カラオケツール & UTAU 支援ツール:唄詠、すっぴんプラグイン、うたりすなど。
音源、音楽など
- うちとま!ファンクラブ:?
- おふとんPの直売所:薪宮風季
- 倶楽部ちよじ:奏音トモ
- ここではメタルしかやらんぞ:破壊音マイコ
- The Schizanthus:?
- Hearts (心汰(m):右心フルアラ、行方杠など
他にもご存じでしたら教えてください。
pixivFANBOX も今度探してみようかしら。
私 SHINTA が開発している各種ツール(ニコカラメーカーや唄詠など)について、ファンサイトを Fantia 内にオープンしました。
◆登録だけでも是非お願いします◆
Fantia はさまざまなクリエイターを支援するためのサイトです。公式の説明によれば、
ファンティア[Fantia]は、イラストレーター・漫画家・コスプレイヤー・ゲーム製作者・VTuberなど、各方面で活躍するクリエイターが、創作活動に必要な資金を獲得できるサービスです。
誰でも無料で登録でき、あなたを応援したいファンからの支援を受けられます。
とのことです。
今回、私もクリエイターの 1 人として登録しまして、対象となるツールはこれまで私が開発した全てのツールです。主なものとしては、
【カラオケ関連】
- ニコカラメーカー 2……カラオケのワイプ字幕動画を簡単・キレイに作れるツール
- ゆかりすたー METEOR……カラオケ動画をタイアップ別等で整理してリスト化
- 簡易キーチェンジャー……MPC-BE 等のアドオンとして使うキーチェンジャー
【UTAU 関連】
- 唄詠(うたよみ)……セリフ読み上げツールの音声として UTAU 音源を使用可能にするツール
- すっぴんプラグイン……UTAU の調声をすべて削除して初期状態にリセット
- うたりす……WAVE トレース方式 UTAU 自動調声プラグイン
などがあります。
ツールの開発には、機材費用、サーバー費用、参考文献費用など多くの費用がかかっているため、ご支援いただけると助かります。
無料プランもありますので、登録だけでも是非お願いします。
詳細および登録は以下からお願いします。
今年の 2 大キーワードは、カラオケと UTAU。
2016 年よりニコカラメーカーの開発を開始し、今年の抱負として「ユーザーの皆様と交流会したい」と言っていたが、動画持ち込みカラオケ(持ちカラ)にお誘い頂く形でそれが実現。
持ちカラとは、カラオケボックス等に自作やニコ動等にアップされているニコカラを持ち込み、PC で再生しながら歌うカラオケ。JOYSOUND 等で配信されていない曲が歌えたり、PV 付きで歌えるとても楽しいカラオケ。通常であれば歌えない UTAU オリジナル曲なども歌うことができる。
ニコカラを自作する方々も参加するオフなので、ニコカラメーカーの利用者もいて、生の声を聞くことができた。
持ちカラでは、参加者が持ち込んだ動画を検索・リクエストするためのデンモク的なツールとして、「ゆかり」を使用する。
非常に素晴らしいツールを更に発展させるために、以下のツールを開発した。
ニコカラ活動のコアとなるニコカラメーカーの開発も精力的に継続。
タイトル編集機能を導入し、オープニングや継続表示など、さまざまな形でのタイトルをニコカラに入れられるようにした。
字幕ワイプやルビ表示など、字幕エンジンもブラッシュアップし、より自然なニコカラが作れるようになった。
JOYSOUND 等で配信されている曲が少ない UTAU は、持ちカラの本領を発揮できるジャンルなので、UTAU 界隈にも持ちカラを展開。
うどんさんと共同で UTAU 持ちカラを合計 3 回開催。音源の中の人と音源が合唱する「中外合唱」を初め、持ちカラと UTAU が出会って初めて実現できるカラオケを楽しんだ。
また、君 UTA にも参加。持ちカラの広報に努めたほか、普段お会いできない方々に会えて良かった。
第 2 回 UTAU 勉強会を楽しんだ。UTAU の調声にとどまらず、ミックスやさらには広報まで、トータルで UTAU 活動のヒントを与えてくれる素敵な勉強会だった。
また、自動 HANASU ツールの「唄詠」もメンテナンスを行った。
改めて、新たな出会いに恵まれた年だったと思う。原則として引きこもりなので、あまり界隈に顔を出すことはないのだが、今年はいろんなご縁があった。
本当に 1 年間ありがとうございました。
動画持ち込みカラオケとの出会い

持ちカラとは、カラオケボックス等に自作やニコ動等にアップされているニコカラを持ち込み、PC で再生しながら歌うカラオケ。JOYSOUND 等で配信されていない曲が歌えたり、PV 付きで歌えるとても楽しいカラオケ。通常であれば歌えない UTAU オリジナル曲なども歌うことができる。
ニコカラを自作する方々も参加するオフなので、ニコカラメーカーの利用者もいて、生の声を聞くことができた。
持ちカラ周辺ツールの開発と知識の共有

非常に素晴らしいツールを更に発展させるために、以下のツールを開発した。
- 簡易キーチェンジャー……ゆかりでキーチェンジを行えるようにする。
- ゆっこビュー……ゆかりでニコ動のようなコメント遊びを楽しめるようにする。
- ニコカラりすたー……リクエスト可能な動画(曲)を整理して表示する。
- ニコカラ作成講習会を開催……初めてニコカラを作る人を主対象として、実際に 1 曲作りながらノウハウを伝授する講習会を SAI さんと共同で開催した。
- ニコカラ作成方法まとめ記事改訂……ニコカラの作り方を整理した記事を 2016 年に公開していたが、最新の状況を反映して改訂版を公開した。
ニコカラメーカーの開発

タイトル編集機能を導入し、オープニングや継続表示など、さまざまな形でのタイトルをニコカラに入れられるようにした。
字幕ワイプやルビ表示など、字幕エンジンもブラッシュアップし、より自然なニコカラが作れるようになった。
UTAU と持ちカラのマリアージュ

うどんさんと共同で UTAU 持ちカラを合計 3 回開催。音源の中の人と音源が合唱する「中外合唱」を初め、持ちカラと UTAU が出会って初めて実現できるカラオケを楽しんだ。
また、君 UTA にも参加。持ちカラの広報に努めたほか、普段お会いできない方々に会えて良かった。
UTAU 全般

また、自動 HANASU ツールの「唄詠」もメンテナンスを行った。
1 年間ありがとうございました
例年振り返りは行っていないのだが、今年は盛りだくさんすぎて、整理しておかないと来年の抱負が書けなそうだったので、まとめてみた。改めて、新たな出会いに恵まれた年だったと思う。原則として引きこもりなので、あまり界隈に顔を出すことはないのだが、今年はいろんなご縁があった。
本当に 1 年間ありがとうございました。

割と後半の時間に行ったこともあり、フォロワーさんのサークルのところを中心に巡った(タイミングが合わずお邪魔できなかったところもあるが……)。なので、イベント系はよく分からない。
各サークルとも、商品に特徴があるのはもちろん、販売方法も様々。慣れないで行っている身としては、商品の特徴やセールスポイントなどを丁寧に説明してくれるところのほうが嬉しい。
あと、パソコンに CD ドライブが付いている時代が終わりつつあるので、CD を販売しているサークルは、microSD あるいは、ダウンロードカードといった別メディアでの販売もしてくれると嬉しい。
以下、サークル配置順にて。
A-01 はんまふらいふ

CD、4 コマ漫画、アンソロジー(複数作者の原稿を集めたもの)の 3 点セットで 2,000 円。今回購入した中では最も高価格。
CD は、選曲やらボーナストラックのトークやら、あちこちにネタが仕込まれていて楽しい。
アンソロジーは4 コマ漫画から小説まで、いろんな内容があり、総勢 100 ページオーバーの濃い内容。厚さにして 9mm。きりきさんの 4 コマ漫画が楽しかった。
B-09 Bloomoon Garden

お二人のイラスト集を購入。
左がわそぽったんぬさんで、透明感のあるタッチと、少し儚げな雰囲気を醸し出している。
右がてんなさんで、明るくて元気なかわいらしさ溢れるイラスト。
それぞれ違う持ち味が光っていて好き。
B-11 みんと屋(´_ゝ`)

主力商品は CD。
販売方法が面白くて、レーベル面およびジャケットのイラストそれぞれが、数種類の中から選べる。
ジャケットはちょっと RPG っぽいものをセレクト。レーベルはみこみこをセレクト。
C-02 海中電灯

主力商品はシールで、いくつかのセットがあった。
その中から、自音源の餅寝こめが入っているバージョンをセレクト。
他に、重音テト、重音テッド、ルーク、焔音レイ、鳴都、白鐘ヒヨリ、波音リツ、桃音モモ、闇音レンリ、傷音ウサが入っており、全 11 枚。
ちなみにシールは、印刷面、のり面、剥離紙の 3 層構造なので、貼るときは剥離紙を剥がすようにしないと失敗する(印刷面とのり面を分離してしまった……)。
C-03 唯ひとつの月.bak

このサークルは太っ腹で、アルバム「'98」を購入したら、おまけで「はじめまして。」ももらえた。
買うときは気付かなかったが、曲 1 つ 1 つが 1998 年にあった出来事に対応しているようだ。このあたり、深掘りしていくと面白い話が聞けそう。
トラック 2 の「The Space Ship」がお気に入り。
C-08 なないろらむね+

霧島柚衣さんは雨鳥ユウイの中の人なのだが、ちょうどブースの前を通りかかったときに、会場の BGM が雨鳥ユウイという奇跡のタイミングだったこともあり、お声掛けいただいた。
この CD で初めて雨鳥ユウイを知ったが、優しい声質で素敵な音源だと思う。
いーちゃんさんが作曲者なので、音源オリジナルソングもどんどんできて良いサークルだと思う。
C-12 恵方巻きコルネ

商品ラインナップの多彩さにびっくり。大辺璃さん曰く、長い活動の中でだんだん商品が増えてきたとのこと。
日本鬼子は自治体とのコラボレーションも増えてきていて、活躍の幅が広がっているようだ。
一般企業とのコラボレーションについても模索中とのこと。
D-09 イチミリメートル

うろうろしている時にお声掛けいただいた。
CD ラインナップはいくつかあったのだが、tamaGO さんが歌ってみたもやっているとのことだったので、ボカロ&UTAU&歌みたの 3 つが詰まった CD をセレクト。
UTAU SQUARE なので、UTAU がメインなのは当然なのだが、中にはこういうバラエティーに富んだサークルがあるのも面白いと思う。
E-07 はとさぶる

ポストカードを取り扱っているサークル。
みーぼさんの描く閏月ナコは温かみがあって好きなので、それをセレクト。ご本人も、隣に座っていた実月礼詞の中の人も、優しそうで、イラストにもそれが現れているのかもしれない。
ここも太っ腹で、みこみこのカードまで戴いてしまった。
E-10 きゃらめるりぼん

通りがかった時にお声掛けいただいた。
自音源である燈音すずのイラスト集。ではあるのだが、どちらかというとプロモーション冊子の位置づけで、音源そのものを PR するという目的意識を持って制作されたとのこと。
だからこそ、通りすがりにも積極的にお声掛けして周知に努めていたのだろう。ビジョンとアクションがリンクしていて素晴らしい。
ちなみに 1 冊だと分からないが、実は、表表紙と裏表紙は、並べるとつながるように工夫されている。
E-11 Jack.Inthe.Box

いくつかの商品があったが、最新の小説をセレクト。
ここも販売方法が面白くて、小説はメイン冊子とサブ冊子のセットになっているのだが、サブ冊子は、R-18 の有無を選べる。
大崎巧実さんは遠征組で、片付けの様子も拝見させてもらったのだが、てきぱきとスーツケースに棚や商品などを詰め込んでいく手際の良さはすごかった。
E-12 UTAUTAU

商品はいろいろあったが、「UTAU アドベンチャー」というタイトルを見てしまったらそれを買わずにはいられない。
百兎さんは穂歌ソラのイメージがあるが、やはり本書にもソラが登場している。しかし本命はサラらしい。
UTAU とは関係ないが、軌跡シリーズの話で盛り上がった。みっしぃ羨ましい……。
F-06 ほにゃほにゃproject

ほけさんといえばデフォ子。
アンソロジーになっていて、小説やら漫画やらが詰まった 1 冊になっている。
しかしほけさん漫画も描くとは知らなかったので、新しい発見だった。
おわりに

また機会があったら、他の所も巡ってみたい。
最後に、うたすくの主催者には最大の感謝を!
「UTAU プラグインを作ろうと思うんだけど、プログラミング言語は何が良いんだろう?」
このようなお悩みをたまに見かけますので、今回はそれを考えてみます。
ちなみに、UTAU 以外で既に十分なプログラミング経験のある方は、普段お使いの言語で作れば問題ありません。プラグインの仕様や、各言語での実装例(半音上げプラグイン大会のエントリーなど)を見れば、あっという間に作れるでしょう。
ここでは、あまりプログラミング経験のない方のために考えることにします。
言語選びのポイントは以下です。
世間で人気の言語(利用者が多い言語)であれば、入門書や入門サイトも数多く存在しますし、ハウツーやトラブル対策の情報も豊富です。あなたがトラブルに見舞われたとして、人気の言語ならば、他にも多くの人が似たような経験をしているはずなので、すぐに対応策を探せるでしょう。
逆に、マイナー言語の場合、そもそも開発環境自体のバグが残っていたりすることもあり、余計なトラブルに巻き込まれかねません。
人気の言語は、TOIBE が定期的に測定しています。クローズドソースも含め、世界で使われている言語を推定しているランキングです。古めの言語の順位が上がってしまう傾向にありますが、十分参考になります。2016 年 1 月のランキングでは、以下の順位です。
C と C++ は順当に高ランキングを獲得していますね。歴史の長い言語なので、直近の勢いという意味ではそれほどではありませんが、しっかりしたライブラリなどの多くは C/C++ ですし、普段使っているようなパソコンソフトだけではなく、裏方(ドライバ、ライブラリ、ファームウェア等)としても様々な場面で使われています。
4 位の C# はメジャー言語の中では後発組です。短期間でランキング上位にのしあがったのは、マイクロソフトの影響力が大きいです。とはいえマイクロソフトの影響力 があるのはパソコンの世界の話で、スマホではあまり影響力はありません。スマホ全盛の時代に高ランキングを獲得しているのは、C# そのものの良さがあるからでしょう。
5 位の Python は、日本ではそこまでメジャーではありません。プロの求人ランキング(横軸)を見ても、マイナー言語と同等の求人件数しかありません。しかし、世界に目を向ければ、Google 先生が Python 押しであることが大きな追い風となり、ホットな言語と言えます。
6~10 位は、アセンブラを除いてお手軽系の言語が並んでいます。
これら 10 言語をおすすめ言語候補として、以降でさらに絞り込んでいきましょう。
言語ランキング 1 位の Java は初期の頃から GUI に力を入れてきており、GUI は作りやすいと言えるでしょう。私自身は Java での GUI 開発経験はありませんが、例えば Java の統合開発環境として使える Eclipse であれば、RAD ツール(GUI をドラッグアンドドロップで簡単に設計できるツール)の Swing Designer が標準搭載されているようです。
言語ランキング 2 位の C での GUI 開発は地獄です。仕事でやむを得ずというのならともかく、UTAU プラグインの GUI を作るために C を用いるのは正気の沙汰ではありません。
言語ランキング 3 位の C++ での GUI 開発は微妙です。
C++ 開発環境の鉄板である Visual Studio において、GUI 開発は以前よりはマシになりました。RAD ツール付きの Visual Studio が無償で利用できるようになったためです。しかし、付属の C++ ライブラリの使い勝手は悪く、慣れるまでにかなりの時間を要するでしょう。
別の C++ 開発環境として C++Builder が挙げられます。優秀な RAD ツールで、効率的に GUI 開発が行えます。しかし、価格が高いこと、バグが多くサポート力も弱いこと(昔のセキュリティーホールが放置されたままになってたります)、(言語としてではなく)ツールとしてのユーザー数が少ないことから、おすすめはできません。
言語ランキング 4 位の C# および 7 位の Visual Basic .NET(以降 VB.NET)は GUI の開発がやりやすくなっています。開発環境は C++ の時と同じく Visual Studio ですが、使い勝手は大きく異なります。C#・VB.NET の場合は GUI が作りやすいように整備されており、また、付属のライブラリ(.NET)も扱いやすいです。
言語ランキング 5 位の Python は、標準では GUI の開発は大変です。RAD ツールとしては Monkey Studio が利用できるようですが、日本語の情報がほとんどありません。しかし、IronPython という、.NET と組み合わせたバージョンの Python は、GUI を開発しやすくなっています。ただし、日本語の情報はあまり多くないようですので、プログラミングに不慣れな人が挑戦しようとすると困難が待ち受けるでしょう。
言語ランキング 6 位の PHP と 8 位の JavaScript はウェブ専用のプログラミング言語なので、今回は除外します。
言語ランキング 9 位のアセンブラでの GUI の開発は……理論上は可能ですね。しかし現実は無理でしょう。
言語ランキング 10 位の Ruby での GUI 開発は、Python と似たような状況です。標準では GUI は作りづらいものの、.NET と組み合わせた IronRuby があります。ただし、IronRuby の開発は止まっており、Python よりも状況は悪いです。
以上により、人気の言語でかつ、標準で GUI 開発を行いやすいのは、Java、C#、VB.NET であることがわかりました。
まず Java ですが、実行ファイルを生成することはできず、別途、JRE(Java Runtime Environment)と呼ばれる追加ソフトが必要となります。残念。
とはいえ、ウェブブラウザのプラグインをインストールする際に一緒に JRE を入れている利用者もいますので、減点要素はそこまで大きくありません。
C#、VB.NET は実行ファイルを生成できます。別途 .NET Framework という追加ソフトが必要となるのですが、Windows に初めからインストールされていたり、あるいはすでに別のソフトを使う際に利用者が自分でインストールしていたりと、たいていの場合はインストールされていることでしょう。とはいえ、.NET Framework のバージョン違いによってインストールが必要になることもあり、減点要素はゼロではありません。
C# と VB.NET を比較すると、機能としては同等なのですが、C# の方が簡潔にプログラムを記述できます。また、よく言われることとして、VB プログラマーの質が低いというのがあります。VB で開発していると、ネットの「知恵」が実は微妙な情報で、それを信じてドツボにハマる、というリスクがあります。
以上により、UTAU プラグインをこれから開発するなら、最もオススメのプログラミング言語は「C#」という判断にいたします。
懸念事項としては、「プログラミング経験の少ない人が C# にチャレンジするのはハードルが高くないか」という問題です。順当に C やあるいは軽量系スクリプト言語の方が習得しやすいかもしれません。とはいえ、UTAU プラグインを作るのが目的であれば、それらの言語では目的を達成するのが困難というのがこれまでの流れです。
これから C# を勉強しはじめる場合、きちんとした書籍を購入して、体系的に C# を理解するのが結局は一番近道だと思います。C# に限りませんが、プログラミングの概念をきちんと理解するのはなかなか大変で、ウェブの Tips をつまみ食いした程度ではその場しのぎの知識しか手に入りません。
とはいえ、まず少し作ってみたいんだ、という場合は、
はいかがでしょうか。GUI アプリを C# で実際に作ってみることができます。また、
の C# の実例(エントリー 3、15、22、27(GUI))も参考になるかと思います。C# 言語の詳細については、プログラミングの基礎的な知識を前提としていますが、
最初にメジャー言語で絞り込みましたが、情報収集にもっと労力を注ぎ、不足するところは自分で考えることにすれば、マイナー言語でもいいわけです。例えば Lazarus は無料で GUI を簡単に構築できます。Lazarus に限定するとユーザー数は多くありませんが、Lazarus は言語としては Object Pascal でありそこそこの順位にいますから、悪くない選択肢かもしれません。
今回 1 位と 2 位の C# と VB.NET を比較した場合、VB.NET の良いところは一つも無いと言っても過言ではありませんが、C# と 3 位の Java を比較した場合、UTAU プラグイン以外にも目を向ければ、Java のいいところもたくさんあります。将来 Android アプリも作りたい、ということであれば、その準備を兼ねて Java を選択する、ということも考えられます(逆に Android アプリを C# で作る方法もありますが)。
世界の潮流で言えば、Python は「来てる」言語です。Google のクラウドサービスで何かしようとしたら Python は有力でしょう。その意味では、IronPython も挑戦しがいがあるかもしれません。
C# ももちろんですが、他の言語にも是非目を向けてみてください。
このようなお悩みをたまに見かけますので、今回はそれを考えてみます。
ちなみに、UTAU 以外で既に十分なプログラミング経験のある方は、普段お使いの言語で作れば問題ありません。プラグインの仕様や、各言語での実装例(半音上げプラグイン大会のエントリーなど)を見れば、あっという間に作れるでしょう。
ここでは、あまりプログラミング経験のない方のために考えることにします。
言語選びのポイントは以下です。
- 世間で人気の言語であること
- GUI が作りやすいこと
- プラグイン利用者側の追加ソフトインストールが不要であること
世間で人気の言語であること
夢も希望もない話かもしれませんが、初心者であるほど、長いものに巻かれるほうが無難です。世間で人気の言語(利用者が多い言語)であれば、入門書や入門サイトも数多く存在しますし、ハウツーやトラブル対策の情報も豊富です。あなたがトラブルに見舞われたとして、人気の言語ならば、他にも多くの人が似たような経験をしているはずなので、すぐに対応策を探せるでしょう。
逆に、マイナー言語の場合、そもそも開発環境自体のバグが残っていたりすることもあり、余計なトラブルに巻き込まれかねません。

- Java
- C
- C++
- C#
- Python
- PHP
- Visual Basic .NET
- JavaScript
- アセンブラ
- Ruby
C と C++ は順当に高ランキングを獲得していますね。歴史の長い言語なので、直近の勢いという意味ではそれほどではありませんが、しっかりしたライブラリなどの多くは C/C++ ですし、普段使っているようなパソコンソフトだけではなく、裏方(ドライバ、ライブラリ、ファームウェア等)としても様々な場面で使われています。
4 位の C# はメジャー言語の中では後発組です。短期間でランキング上位にのしあがったのは、マイクロソフトの影響力が大きいです。とはいえマイクロソフトの影響力 があるのはパソコンの世界の話で、スマホではあまり影響力はありません。スマホ全盛の時代に高ランキングを獲得しているのは、C# そのものの良さがあるからでしょう。
5 位の Python は、日本ではそこまでメジャーではありません。プロの求人ランキング(横軸)を見ても、マイナー言語と同等の求人件数しかありません。しかし、世界に目を向ければ、Google 先生が Python 押しであることが大きな追い風となり、ホットな言語と言えます。
6~10 位は、アセンブラを除いてお手軽系の言語が並んでいます。
これら 10 言語をおすすめ言語候補として、以降でさらに絞り込んでいきましょう。
GUI が作りやすいこと
ほとんどの UTAU プラグインには GUI(ウィンドウやボタンなどの画面)が必要になってきます。GUI を簡単に作れるかどうかは、生産性に大きく影響します。言語ランキング 1 位の Java は初期の頃から GUI に力を入れてきており、GUI は作りやすいと言えるでしょう。私自身は Java での GUI 開発経験はありませんが、例えば Java の統合開発環境として使える Eclipse であれば、RAD ツール(GUI をドラッグアンドドロップで簡単に設計できるツール)の Swing Designer が標準搭載されているようです。
言語ランキング 2 位の C での GUI 開発は地獄です。仕事でやむを得ずというのならともかく、UTAU プラグインの GUI を作るために C を用いるのは正気の沙汰ではありません。
言語ランキング 3 位の C++ での GUI 開発は微妙です。
C++ 開発環境の鉄板である Visual Studio において、GUI 開発は以前よりはマシになりました。RAD ツール付きの Visual Studio が無償で利用できるようになったためです。しかし、付属の C++ ライブラリの使い勝手は悪く、慣れるまでにかなりの時間を要するでしょう。
別の C++ 開発環境として C++Builder が挙げられます。優秀な RAD ツールで、効率的に GUI 開発が行えます。しかし、価格が高いこと、バグが多くサポート力も弱いこと(昔のセキュリティーホールが放置されたままになってたります)、(言語としてではなく)ツールとしてのユーザー数が少ないことから、おすすめはできません。
言語ランキング 4 位の C# および 7 位の Visual Basic .NET(以降 VB.NET)は GUI の開発がやりやすくなっています。開発環境は C++ の時と同じく Visual Studio ですが、使い勝手は大きく異なります。C#・VB.NET の場合は GUI が作りやすいように整備されており、また、付属のライブラリ(.NET)も扱いやすいです。
言語ランキング 5 位の Python は、標準では GUI の開発は大変です。RAD ツールとしては Monkey Studio が利用できるようですが、日本語の情報がほとんどありません。しかし、IronPython という、.NET と組み合わせたバージョンの Python は、GUI を開発しやすくなっています。ただし、日本語の情報はあまり多くないようですので、プログラミングに不慣れな人が挑戦しようとすると困難が待ち受けるでしょう。
言語ランキング 6 位の PHP と 8 位の JavaScript はウェブ専用のプログラミング言語なので、今回は除外します。
言語ランキング 9 位のアセンブラでの GUI の開発は……理論上は可能ですね。しかし現実は無理でしょう。
言語ランキング 10 位の Ruby での GUI 開発は、Python と似たような状況です。標準では GUI は作りづらいものの、.NET と組み合わせた IronRuby があります。ただし、IronRuby の開発は止まっており、Python よりも状況は悪いです。
以上により、人気の言語でかつ、標準で GUI 開発を行いやすいのは、Java、C#、VB.NET であることがわかりました。
プラグイン利用者側の追加ソフトインストールが不要であること
UTAU プラグインを使うために、プラグイン以外にも別途あれもこれもソフトをインストールしてください、だと、プラグイン利用者としては不便ですし、インストール作業を面倒くさがってプラグインの利用を諦めてしまうことも多いでしょう。まず Java ですが、実行ファイルを生成することはできず、別途、JRE(Java Runtime Environment)と呼ばれる追加ソフトが必要となります。残念。
とはいえ、ウェブブラウザのプラグインをインストールする際に一緒に JRE を入れている利用者もいますので、減点要素はそこまで大きくありません。
C#、VB.NET は実行ファイルを生成できます。別途 .NET Framework という追加ソフトが必要となるのですが、Windows に初めからインストールされていたり、あるいはすでに別のソフトを使う際に利用者が自分でインストールしていたりと、たいていの場合はインストールされていることでしょう。とはいえ、.NET Framework のバージョン違いによってインストールが必要になることもあり、減点要素はゼロではありません。
以上により、これまで絞り込んだ言語の中で、この項目を完璧に満たせる言語はありません。
(2024/06/08 追記)最近の C# は「自己完結型」といって完全に追加インストール不要で配付可能になりました。
総合評価
ここまでで、有力候補は Java、C#、VB.NET の 3 つに絞られました。この 3 つに順位を付ける場合、私は以下のようにします。- C#
- VB.NET
- Java
C# と VB.NET を比較すると、機能としては同等なのですが、C# の方が簡潔にプログラムを記述できます。また、よく言われることとして、VB プログラマーの質が低いというのがあります。VB で開発していると、ネットの「知恵」が実は微妙な情報で、それを信じてドツボにハマる、というリスクがあります。
以上により、UTAU プラグインをこれから開発するなら、最もオススメのプログラミング言語は「C#」という判断にいたします。
懸念事項としては、「プログラミング経験の少ない人が C# にチャレンジするのはハードルが高くないか」という問題です。順当に C やあるいは軽量系スクリプト言語の方が習得しやすいかもしれません。とはいえ、UTAU プラグインを作るのが目的であれば、それらの言語では目的を達成するのが困難というのがこれまでの流れです。
これから C# を勉強しはじめる場合、きちんとした書籍を購入して、体系的に C# を理解するのが結局は一番近道だと思います。C# に限りませんが、プログラミングの概念をきちんと理解するのはなかなか大変で、ウェブの Tips をつまみ食いした程度ではその場しのぎの知識しか手に入りません。
とはいえ、まず少し作ってみたいんだ、という場合は、
はいかがでしょうか。GUI アプリを C# で実際に作ってみることができます。また、
の C# の実例(エントリー 3、15、22、27(GUI))も参考になるかと思います。C# 言語の詳細については、プログラミングの基礎的な知識を前提としていますが、
がオンラインの情報としてはまとまっていると思います。
余談
今回は C# 押しということになりました。確かに C# は素晴らしい言語です。- 他の言語の良いところを取り入れていて使いやすい
- GUI・ネットワーク・同期プログラミングなど周辺のライブラリも充実かつ整理されている
- Visual Studio の支援機能がずば抜けて強力(他の環境を使う気になれないくらい)
最初にメジャー言語で絞り込みましたが、情報収集にもっと労力を注ぎ、不足するところは自分で考えることにすれば、マイナー言語でもいいわけです。例えば Lazarus は無料で GUI を簡単に構築できます。Lazarus に限定するとユーザー数は多くありませんが、Lazarus は言語としては Object Pascal でありそこそこの順位にいますから、悪くない選択肢かもしれません。
今回 1 位と 2 位の C# と VB.NET を比較した場合、VB.NET の良いところは一つも無いと言っても過言ではありませんが、C# と 3 位の Java を比較した場合、UTAU プラグイン以外にも目を向ければ、Java のいいところもたくさんあります。将来 Android アプリも作りたい、ということであれば、その準備を兼ねて Java を選択する、ということも考えられます(逆に Android アプリを C# で作る方法もありますが)。
世界の潮流で言えば、Python は「来てる」言語です。Google のクラウドサービスで何かしようとしたら Python は有力でしょう。その意味では、IronPython も挑戦しがいがあるかもしれません。
C# ももちろんですが、他の言語にも是非目を向けてみてください。

ニッチなイベントなので、そもそも参加してくださる方がいるのか不安でしたが、蓋を開けてみれば大盛況で、なんと 24 件ものエントリーがありました。単に「半音上げる」だけのシンプルなプラグインが、いろいろなプログラミング言語やアルゴリズムで、24 パターンも登場したということです。
本記事では、そんな大会の様子を振り返ってみたいと思います。大会レギュレーションは、以前の記事を参照して下さい。
蛇足ですが、UTAU のメニューに半音上げる処理はありますので、実用上は、半音上げるプラグインは必要ありません。
目次
- エントリー一覧
- 典型的な半音上げプラグインの動作
- 解説:C#
- 解説:C++
- 解説:C
- 解説:Java
- 解説:Python
- 解説:UWSC
- 解説:なでしこ
- 解説:Lazarus
- 解説:HSP
- 解説:Electron
- 解説:バッチファイル
- 解説:JScript
- 解説:ExcelVBA
- 解説:既存プラグインのパラメーター設定方式
- まとめ
- 遅刻組(PowerShell / Python / C# GUI / アセンブラ / C)
- 参考リンク
エントリー一覧
# | エントリー(敬称略) | 言語 | ソースコード |
---|---|---|---|
1 | Haruqa | UWSC | 表示 DL |
2 | 巽 | なでしこ | 表示 DL |
3 | SHINTA | C# | 表示 DL |
4 | bizz | Lazarus | 表示 DL |
5 | masao | C++ | 表示 |
6 | bizz | Lazarus | 表示 DL |
7 | masao | C | 表示 |
8 | Haruqa | UWSC | 表示 DL |
9 | Haruqa | UWSC | 表示 DL |
10 | 大兄P | Java | 表示 |
11 | bizz | HSP | 表示 DL |
12 | 山岸 | Java | 表示 |
13 | masao | C++ | 表示 |
14 | 大兄P(#10 の修正) | Java | 表示 |
15 | ばわめ rwxr--r-- | C# | 表示(メイン クラス) |
16 | あさくら・ふにょし | Electron | 表示(HTML JavaScript) DL |
17 | あさくら・ふにょし | バッチファイル | 表示 |
18 | Haruqa | JScript | 表示 |
19 | とりフラ.ust.vvv | ExcelVBA | 表示 |
20 | masao | C++ | 表示 |
21 | あらいふ | Python | 表示 DL(ソース バイナリ) |
22 | Haruqa | C# | 表示 DL |
23 | 飯香 | 条件設定プラグイン | 表示 |
24 | 飯香 | BF プラグイン | 表示 |
典型的な半音上げプラグインの動作
まず、UTAU プラグインそのものの概要をおさらいしておきましょう。一般的なアプリケーションにおいて「プラグイン」というと DLL 形式のものが多いですが、UTAU の場合はそうではなく、UTAU プラグインは実行ファイル(.exe)などの形式となります。
UTAU プラグインの仕様は公式サイトなどに書かれていますが、UTAU 画面上でユーザーが選択した音符の情報を、UTAU が一時ファイルに書き出します。UTAU プラグインはその一時ファイルを読み込み、音符の情報を変更して、一時ファイルに書き戻します。プラグイン実行後、UTAU が再度一時ファイルを読み込んで変更内容を確認し、UTAU 画面に反映する、という流れです。
一時ファイルは INI ファイルの形式となっており、1 つの音符の情報が 1 つのセクション(UTAU ではセッションと呼んでいます)にまとめられています。例えば、音程が「ド」(C4)で歌詞が「い」の四分音符だと、以下のように出力されます。
[#0001]
Length=480
Lyric=い
NoteNum=60
Intensity=100
Moduration=0
NoteNum が音程を表していて、数字が大きいほど高音になります。60 なら C4、61 なら C#4 というように、1 増える毎に半音上がっていきます。
つまり、「半音上げプラグイン」であれば、NoteNum を読み、NoteNum の値を 1 増やしてから、一時ファイルを上書きすれば、目的を達することができるわけです。
次節以降で、今回エントリーされた内容について、私の分かる範囲で解説していきます。
解説:C#
まずは、エントリー No.3、私が作成した C# 版の半音上げプラグインについて。処理方法は単純で、一時ファイルを全行読み込んでから、NoteNum を探し、値を 1 増やしています。
注意すべきは、[#PREV][#NEXT] という特別なセクションです。UTAU は、ユーザーが選択した音符の「前後の音符」の情報も一時ファイルに出力し、その内容が [#PREV][#NEXT] セクションに記載されます。[#PREV][#NEXT] セクションの内容を書き換えてしまうと、ユーザーが選択してない音符の情報が変わってしまうことになるので、避ける必要があります。
セクション行を解析する際に、選択範囲の音符セクション([#0001][#0002]……)かどうかを判定し、結果をフラグとして保持しておきます。NoteNum が出てきた時にフラグを確認し、フラグが立っている場合のみ、処理を行うことで、[#PREV][#NEXT] セクションを避けています。
メモリ上で NoteNum の変更を終えた後、全行を一気に一時ファイルに書き戻しています。
別の C# エントリーとして、ばわめ rwxr--r-- さんの No.15 があります。
この実装では、一時ファイルへのアクセスを INI ファイル解析クラス(をカスタマイズしたもの)を用いて行っています。これにより、メイン側では処理をセクション単位で遷移させることができるようになり、また、NoteNum の値も簡単に取り出せるようになっています。
音符セクションかどうかの判定には正規表現を用いており、確実な判定が行えます。
C# はもう 1 つ、Haruqa さんの No.22 もあります。
この実装も No.15 と同様、一時ファイルへのアクセスを担当するクラスを用いていますが、こちらはイチから作成したクラスとなっており、音符のプロパティーをそれぞれ専用のメンバー変数で保持する仕様となっています。
解説:C++
C++ は masao さんが 3 エントリーされています。ますは No.5。
本人コメントでは、先ほどの No.3 C# 版を移植しただけとありますが、処理方法はかなり進化しています。
一時ファイルを一行一行読みながら作業するのですが、まず、音符セクションが出てきた場合に、その行を「出力バッファ」に溜めます。また、NoteNum が出てきた場合にも、音程を半音上げてから「出力バッファ」に溜めます。それ以外の場合は、出力バッファに溜めません。
結果として、最小限の変更箇所のみが「出力バッファ」に溜まり、それを一時ファイルに書き戻しています。これにより、書き戻す一時ファイルがコンパクトになります。
[#PREV][#NEXT] を除外するフラグの考え方は No.3 と同様ですが、判定方法が賢くなっています(No.3 はかなり手抜きでした)。
次に No.13。
こちらは、一時ファイルの取り扱いを楽にする Lib UTAU を用いて実装しています。
一時ファイルの解析を Lib UTAU が行ってくれるので、[#PREV][#NEXT] を除外するのも簡単で、プログラムが非常にシンプルになっています。Lib UTAU の SectionNotesNormalBegin()~SectionNotesNormalEnd() の間だけ処理を繰り返すことで、自動的に [#PREV][#NEXT] が除外されます。
最後に No.20。
Lib UTAU と同様の自作ライブラリを用いて実装しているとのことで、No.13 同様、プログラムが非常にシンプルになっています。
自作ライブラリは非公開のため内容は不明ですが、セクションとキーバリューペアの関連性も保持しているようで、使いやすそうです。
解説:C
masao さんは No.7 で C 言語版も作成されています。基本的な考え方は No.5 C++ 版と同様ですが、「出力バッファ」を使わずに、代わりに、逐次「テンポラリファイル」(UTAU の一時ファイルとはまた別のファイル)に書き出しています。C 言語は文字列(に関わるメモリ)の扱いが面倒なので、出力バッファを使わないほうが楽だと判断したのでしょう(違ってたらすみません)。
最後に、UTAU の一時ファイルを削除して、代わりに、プラグインが出力したテンポラリファイルを一時ファイルにリネームして完了です。
C 言語はファイルや文字列の扱いが煩雑なのに、非常にスマートにプログラミングされており、masao さんの技術力の高さがうかがえます(私はこんなにスマートに実装できません)。
解説:Java
Java はお二方がエントリー。No.12 の山岸さんは、処理の流れとしては No.7 の C と近しい感じになっています。
C とは異なり、Java は文字列を手軽に扱えるので、全体的にコードがすっきりしています。また、音符セクションかどうかの判定や、音高行の判定に正規表現を用いており、スマートに判定ができています。
エラー処理が入っている点も見逃せません。本大会はプラグインの実運用が目的ではないので、エラー処理が入っていないエントリーも多いですが、実際にプラグインを開発する際にはエラー処理は必須になってきます。きちんとエラー処理を行う山岸さんの堅実さがうかがえます。
No.14 の大兄 P さんは、一風変わった処理の流れになっています。
最初に一時ファイルを 7 行読み飛ばしているのは、[#VERSION][#SETTING] といったセクションを読み飛ばす意図だと思われます(違っていたらすみません)。
その後、[#PREV][#NEXT] を避けつつ、NoteNum を 1 上げています。
No.14 は修正バージョンで、当初は No.10 でのエントリーでした。自分のソースコードを見直したり、他人のコードを参考にしたりしながら、ブラッシュアップしていくのも、プログラミングの醍醐味ですよね。
解説:Python
No.21 のあらいふさんは Python で作成されています。行毎に処理を進めていくのですが、「セクション開始待ち」なのか「NoteNum エントリー待ち」なのかという「状態」を保持しておき、状態に応じて、解析を実行する関数を切り替えています(関数ポインタ方式)。
「セクション開始待ち」では、セクション名を見て、音符セクションであれば、「NoteNum エントリー待ち」に状態遷移します。
「NoteNum エントリー待ち」では、NoteNum の行が来たら音程を 1 上げて、「セクション開始待ち」に遷移します。
ファイルの存在確認や、音程の上限確認など、エラー対応関連も充実しています。
解説:UWSC
これまでは、プログラミング言語人気トップ 10 に入るような超メジャーな言語の実装を見てきましたが、ここからは、もう少しいろいろな言語を見ていきましょう。UWSC では Haruqa さんが 3 件エントリーしています。
今回の大会である意味一番驚いたのが No.1 の UWSC です。このプラグインは、一時ファイルを一切使いません。UTAU を操作し、UTAU のメニューから「選択部分を上へ移動」を実行することにより、半音上げを実現しています。UTAU 本体を操るプラグインというわけです。
No.8 は一時ファイルを使いますが、一時ファイルの書き換えは、メモ帳を操って行っています。
No.9 は普通に一時ファイルを更新しています。
解説:なでしこ
巽さんが使ったなでしこは、日本語でプログラミングが行える言語です。処理方法としては、いったんすべての NoteNum を 1 上げたあとで(UTAU とは別の)テンポラリファイルに保存し、その後、テンポラリファイルから UTAU の一時ファイルに書き戻す際に、[#PREV][#NEXT] を除外しているようです。
個人的には、「B はそれ」という禅問答みたいは表現が、日本語プログラミングっぽくて好きです。
解説:Lazarus
オープンソース版の Delphi ともいえる Lazarus(言語としては Object Pascal)は、bizz さんが 2 件エントリーされています。No.4 はオーソドックスなバージョンで、処理の流れは No.5 の C++ とほぼ同じです。
変わり種は No.6。
半音上げるという処理を、音程を上げるのではなく、ピッチベンドカーブをいじることによって実現しています。ピッチベンドは PBW や PBY といったパラメータをかなり処理する必要があり、ソースコードの量からもその大変さがうかがえます。
「やり方は 1 つではない」ということがよくわかる実例です。
解説:HSP
bizz さんはもう 1 つ、HSP でもエントリー。HSP は構文が簡単な手続き型スクリプト言語ですが、コンパイルが可能なため、利用者側は HSP のインストールが不要です。小規模なゲーム開発に人気なイメージがあります。
HSP は目的語を省略できるタイプの言語のようで、内容がいまいち読み取りにくいのですが、処理の流れとしては、No.3 C# 版の全行書きだし型に近いのではないかと見受けられます(違っていたらすみません)。
解説:Electron
あさくら・ふにょしさんは Electron でエントリー。私は今回の大会で初めて Electron の存在を知りましたが、HTML + JavaScript で(ローカルで動く普通の)アプリを作れる環境のようです。Web でバリバリコーディングしている人が、ちょっとしたツールを作る場合などに重宝しそうです。実装は、最近の JavaScript らしくラムダ式を用いています(幹となる部分)。
処理内容としては、最初に「セクション名」と「キーバーリューペア」のペアをすべて解析して連想配列に格納します(連想配列の入れ子のようなイメージ)。本記事冒頭の一時ファイルで言えば、{#0001={Length=480, Lyric=い, NoteNum=60}} みたいな感じです。JavaScript の柔軟な型の利用が活きています。
その後、音符セクションについて、NoteNum を 1 上げてから、テンポラリファイルに書き戻します。
解説:バッチファイル
あさくら・ふにょしさんはバッチファイルでもエントリー。いにしえの MS-DOS 時代から省力化ツールとして親しまれているバッチファイルですが、UTAU プラグインとしても使えるのだと思うと、隔世の感があります。
さすがに高度な関数は使えないので、読み飛ばすセクション([#PREV][#NEXT] など)は列挙して対応していますが、バッチファイルだけでも文字列の扱いや音程計算がきちんと行えており、驚きの内容になっています。私は、バッチファイルでこんなにうまく実装できるものとは知りませんでした。
UTAU プラグインとしてだけではなく、日々の作業の省力化のためにバッチファイルを書く際にも非常に参考になる内容になっています。
解説:JScript
UWSC の Haruqa さんは JScript でもエントリー。JScript は JavaScript 互換ですが、JavaScript 単体では通常行えないファイル出力などが可能です。処理の内容としては、一時ファイルを一行ずつ読み込みながら、NoteNum であれば半音上げつつ、バッファに溜めていきます。最後に、一時ファイルに書き出します。
解説:ExcelVBA
とりフラ.ust.vvv さんは ExcelVBA でエントリー。いわゆるエクセルマクロです。処理の流れは、No.12 の Java と近しい感じになっています。VBA は Visual Basic for Applications という名前の通り、BASIC 言語の流れを汲んでいますが、ファイルオープンの構文などはまさに BASIC 感に溢れています。
さすがにエクセルファイル直接は UTAU プラグインとして使えないようで、実際に使う際には、バッチファイルと組み合わせているようです。
解説:既存プラグインのパラメーター設定方式
さまざまなことが行える既存の UTAU プラグインに対して指令を与えることで、半音上げるという作戦もあります。「プラグインを開発する」のではなく、「既存のプラグインでまかなう」というイメージですね。飯香さんの No.23 は、条件設定プラグイン(亜麻)を、すべての音符に対して半音上げるという条件を設定して起動しています。
また、No.24 は、特定の効果を持つ音符の配置を予め BF プラグインに読ませてから、再度 BF プラグインを起動することで、半音上げを実現しています。BF は恐らく Brainfuck のことだと思いますが、難解なパズルです。
まとめ
「半音上げる」。ただそれだけのことなのに、まさに十人十色の実装になりました。行ごとに文字列的な処理をしていく方法が主流でしたが、人や言語によって実装方法はさまざまでした。また、セクションとその値を有機的に捉えたうえで半音上げるプラグインもいくつかありました。
さらには、音程ではなくピッチをいじるプラグインや、UTAU プラグインの概念を根底から覆すプラグインまで登場しました。
他人のプログラムを見ると言うことは非常に勉強になりますが、今回はシンプルで身近な UTAU プラグインを題材としたことで、より一層そのことが実感できたかなと思います。
ご参加くださった皆様、本当にありがとうございました。
遅刻組
締切は過ぎましたが、投稿いただいたものをこちらに掲載させていただきます。- [25] あさくら・ふにょし(PowerShell)
- [26] あらいふ(Python)
- [27] SHINTA(C# GUI(WinForms))
- [28] ・∞・(アセンブラ)
- [29] Tsuro(C)
- [30] まいこ(C# GUI(WPF コードビハインド))
関連リンク
- UTAU プログラマーの祭典「半音上げプラグイン大会」開催中
- #半音上げプラグイン大会 Twitter ハッシュタグ
- togetter まとめ
- UTAU 編集プラグインの仕様
- Lib UTAU UTAU プラグイン開発支援用 C++ クラスライブラリ
- おすすめプログラミング言語を考える(UTAU プログラマー向け)
更新履歴
- 2020/03/28 [28]~[30] 捕捉
いろいろなプログラミング言語でシンプルなプラグインを作り、ソースコードを比較すれば、違いを楽しめて勉強になるのではないか、というつぶやきからスタートした「半音上げプラグイン大会」。
作って楽しむも良し、他の人のを眺めて楽しむも良し。
どなたでも参加できます。会期は 2015/12/31 まで。
半音の上げ方のアルゴリズムも自由です。お好きな方法でどうぞ。
「UTAU プラグインってどうやって作れば良いの?」という方は、UTAU ユーザー互助会 Wiki に詳しい仕様がまとめられています。あるいは、#半音上げプラグイン大会タグ検索で既に投稿されているプラグインのソースコードを見るのが早いかもしれません。
12/19 時点で、UWCS 2 件、なでしこ、C#、Lazarus 2 件、C++、C のエントリーがあります。
作って楽しむも良し、他の人のを眺めて楽しむも良し。
どなたでも参加できます。会期は 2015/12/31 まで。
参加方法
非常に簡単です。- 入力された音符を「半音上げる」だけのシンプルな UTAU プラグインを作成する。
-
次のいずれか(または両方)の方法において、Twitter 上で「#半音上げプラグイン大会」タグ付きで告知する
- ソースコード(バイナリ同梱も歓迎)をアップローダーに上げ、その URL を Twitter でつぶやく
- ソースコードのスクリーンショットを Twitter に上げる
参加お待ちしております
どのプログラミング言語でプラグインを作るかは自由です。普段使っている言語で作るもよし、これを機に新しい言語に挑戦するもよし。すでにエントリーされた言語とかぶっても全く問題ありません。むしろ、同じ言語でも人によって違う作り方になる点を楽しめるので歓迎です。半音の上げ方のアルゴリズムも自由です。お好きな方法でどうぞ。
「UTAU プラグインってどうやって作れば良いの?」という方は、UTAU ユーザー互助会 Wiki に詳しい仕様がまとめられています。あるいは、#半音上げプラグイン大会タグ検索で既に投稿されているプラグインのソースコードを見るのが早いかもしれません。
12/19 時点で、UWCS 2 件、なでしこ、C#、Lazarus 2 件、C++、C のエントリーがあります。
関連リンク
- #半音上げプラグイン大会 Twitter ハッシュタグ
- togetter まとめ
- 大盛況だった半音上げプラグイン大会の振り返り
UTAU キャラクターを主人公にした RPG「ウミネコロン RPG」の DL 販売が始まったので、早速ゲームスタート。
※ネタバレ注意
UTAU 関連 RPG ということで、ストーリーも UTAU にちなんでいる。突然バグに覆われた街の謎を解くべく、UTAU の仲間達と冒険の旅に出る。
ゲームスタート時、家から出られなくてどうにか脱出を試みるのだが、家の中に宝箱があって中にバールが入っているというのが、なんともシュールで良い。
しかも、バールでドアを開けようとすると、バールが壊れて開けられないというオチ。エクスカリバールという強そうなバールなのに……。
序盤の敵は何気に強い。というか自分が弱い。殴られるとすぐに HP が心許なくなる。が、無限使用回復アイテムがあるので大丈夫。戦闘が終わったらすぐに回復すれば、再び戦える。
敵のグラフィックがまた笑ってしまう。背景や自パーティーのキャラはハイクオリティに描きこまれているのに、敵キャラだけ 2 ちゃんねるのアスキーアート風なのだ。
ストーリーを進めていくと、仲間も増えていく。
それぞれ、ステータス的にも、キャラクター的にも個性ある楽しい仲間達だ。
どうやら、最大 4 人パーティーの模様。
まだ序盤のプレイだが、ストーリー展開・グラフィック・BGM ともに、期待できそうな内容になっている。操作性もなかなか(ゲームパッドも使える)。
とはいえ、もうちょっとこうだったら良かったのにな、という点もある。
動作環境は、我が家の Windows 7 マシンで今のところ問題なく動いている。
試しに Windows XP や Windows 10 でも動かしてみたが、少しいじった限りでは、これらの OS でも動作した。
ウミネコロン RPG の他にも、もっといろいろ UTAU ゲームが増えるといいな。
現時点での UTAU ゲーム一覧は、UTAU ユーザー互助会 Wiki にまとめてある。
※ウミネコロン RPG……作者:ウミネコロン
※ネタバレ注意

ゲームスタート時、家から出られなくてどうにか脱出を試みるのだが、家の中に宝箱があって中にバールが入っているというのが、なんともシュールで良い。
しかも、バールでドアを開けようとすると、バールが壊れて開けられないというオチ。エクスカリバールという強そうなバールなのに……。

敵のグラフィックがまた笑ってしまう。背景や自パーティーのキャラはハイクオリティに描きこまれているのに、敵キャラだけ 2 ちゃんねるのアスキーアート風なのだ。

それぞれ、ステータス的にも、キャラクター的にも個性ある楽しい仲間達だ。
どうやら、最大 4 人パーティーの模様。
まだ序盤のプレイだが、ストーリー展開・グラフィック・BGM ともに、期待できそうな内容になっている。操作性もなかなか(ゲームパッドも使える)。
とはいえ、もうちょっとこうだったら良かったのにな、という点もある。
- 音量調整ができない
- セーブデータは現在位置(街の名前等)が表示されると、ロードする時に分かりやすい
- セーブデータが exe フォルダに置かれてしまう(UserData 配下が良い)
- ボタン同時押しで高速移動できるが、逆にデフォルトが高速移動、同時押しで低速微調整の方が楽

試しに Windows XP や Windows 10 でも動かしてみたが、少しいじった限りでは、これらの OS でも動作した。
ウミネコロン RPG の他にも、もっといろいろ UTAU ゲームが増えるといいな。
現時点での UTAU ゲーム一覧は、UTAU ユーザー互助会 Wiki にまとめてある。
※ウミネコロン RPG……作者:ウミネコロン
定期的に UTAU の文字コード周りで問題が出る感があるので、備忘を兼ねて、分かる範囲でまとめておく。
Windows 版の UTAU が読み書きするファイルの文字コードは、すべてが Shift-JIS。
Shift-JIS では、半角文字(半角カナ含む)は 1 バイト、全角文字は 2 バイトで表現される。例えば、「ABあ愛」は 1+1+2+2=6 バイトとなる。
※通常のユーザーはここを読み飛ばして構わない
UTAU のメニューバーやダイアログなどのリソース関連文字列は、UTAU.exe 内に Shift-JIS として埋め込まれているようだ(Ver 0.4.18 zip 版)。
※通常のユーザーはここを読み飛ばして構わない
リソース関連以外については、UTAU.exe 内部コードは Unicode(UTF-16-LE)のようだ(Ver 0.4.18 zip 版)。例えば、「プロジェクトは変更されています。変更を保存しますか?」などのメッセージボックスで表示される文字列。
また、このことから、UTAU 実行中にメモリ上に格納される文字列も UTF-16-LE で格納されているものと思われる。
UTF-16 は、すべての文字を 2 バイトで表現する(ホントはすべてじゃないけど細かいことは気にしない)。半角文字も 2 バイトだ。なので、「ABあ愛」は 2+2+2+2=8 バイトとなる。
UTF-16 にも 2 種類あり、通常「Unicode 表」として表記されているのは UTF-16-BE(ビッグエンディアン)。で、UTF-16-BE の 1 バイト目と 2 バイト目を入れ替えたのが UTF-16-LE(リトルエンディアン)。例えば全角カタカナの「プ」は、ユニコード表(16 進数)では 30 D7 の 2 バイトで表されるが、UTAU.exe 内では逆順となり、D7 30 の 2 バイトで表される。
逆になるのは非常に分かりづらいが、これは UTAU の問題ではなく、Intel CPU の伝統なので受け入れるしかない。
UTF-16-LE は Shift-JIS との互換性は一切なく、両者で同じ文字コードをを使っている文字は無い。
しかし、バイト列レベルで見ると、半角英数については類似性があり、Shift-JIS のコードにゼロを付加した物が UTF-16-LE となる。例えば「ABC」は Shift-JIS だと 16 進数で 41 42 43 の 3 バイトとなるが、UTF-16-LE だと 41 00 42 00 43 00 の 6 バイトとなる。このため、半角英数を UTF-16-LE で保存して、Shift-JIS だと思って開くと、間延びしたように表示される(右の図をクリックして確認してほしい)。
また、プログラミングの視点で見ると、0x00 を文字列の終端と見なす C 言語などでは、何も考えずに UTF-16-LE の文字列を読み込むと、途中に出現する 0x00 のせいで、文字列が途切れてしまうことがあり、注意が必要となる。
oto.ini と prefix.map が用いる UTF-8 では、半角英数は 1 バイト、日本語はたいてい 3 バイトとなる。半角カナも 3 バイト。例えば、「ABあ愛」は 1+1+3+3=8 バイトとなる。
UTF-8 と Shift-JIS は、半角英数は同じコードを使っている。つまり、半角英数だけのファイルなら、UTF-8 として扱う UTAU-Synth でも、Shift-JIS として扱う UTAU でも、問題なく開ける。
oto.ini / prefix.map 以外は UTAU-Synth も Shift-JIS なので、UTAU とファイルを共用できることになる。ただし、Windows の Shift-JIS と Mac の Shift-JIS は方言のようなものが多少異なり、一部の文字に互換性が無い。通常使う範囲ではあまり問題にならないが、記号類は避けた方が良いだろう。
この記事でも混同して使っているが、厳密には、文字コードを考える時には、「キャラクターセット」と「エンコーディング」の 2 つに分けて考える必要がある。
キャラクターセットは、「どんな文字を取り扱うか(文字集合)」で、例えば欧米ならアルファベットだけでいいよ、とか、日本なら漢字も入れたいね、という話になる。
エンコーディングは、キャラクターセットで扱う文字を、具体的にどんなバイト列で表現するかを決める。
Shift-JIS の場合は、キャラクターセットとエンコーディングがセットになっている感じなので、キャラクターセットやエンコーディングを意識しなくて良い。
UTF-16-LE と UTF-8 は両方とも、キャラクターセットとしては世界中の文字を扱う Unicode で同じある。同じ文字を、どのようにバイト列にするかの規則(エンコーディング)が違うにすぎない。
UTF-16-LE は「すべて 2 バイト」という処理しやすい規則になっている。一方 UTF-8 は、半角英数という最もよく使われる文字を 1 バイトにして、容量の節約を図っている。同じキャラクターセットを表現するにしても、用途によって適したエンコーディングが変わる、という話である。
- Windows 版 UTAU
- Windows 版 UTAU の内部コード(メニュー・ダイアログ関連)
- Windows 版 UTAU の内部コード(メニュー・ダイアログ以外)
- Mac 版 UTAU(UTAU-Synth)
- おまけ知識
- 参考リンク
Windows 版 UTAU

- ust
- oto.ini
- prefix.map
- character.txt
- setting.ini
- 音声合成時のバッチファイル
Shift-JIS では、半角文字(半角カナ含む)は 1 バイト、全角文字は 2 バイトで表現される。例えば、「ABあ愛」は 1+1+2+2=6 バイトとなる。
Windows 版 UTAU の内部コード(メニュー・ダイアログ関連)

UTAU のメニューバーやダイアログなどのリソース関連文字列は、UTAU.exe 内に Shift-JIS として埋め込まれているようだ(Ver 0.4.18 zip 版)。
- ファイル→名前をつけて保存
- プロジェクトの設定ダイアログ→プロジェクト名
Windows 版 UTAU の内部コード(メニュー・ダイアログ以外)

リソース関連以外については、UTAU.exe 内部コードは Unicode(UTF-16-LE)のようだ(Ver 0.4.18 zip 版)。例えば、「プロジェクトは変更されています。変更を保存しますか?」などのメッセージボックスで表示される文字列。
また、このことから、UTAU 実行中にメモリ上に格納される文字列も UTF-16-LE で格納されているものと思われる。
UTF-16 は、すべての文字を 2 バイトで表現する(ホントはすべてじゃないけど細かいことは気にしない)。半角文字も 2 バイトだ。なので、「ABあ愛」は 2+2+2+2=8 バイトとなる。
UTF-16 にも 2 種類あり、通常「Unicode 表」として表記されているのは UTF-16-BE(ビッグエンディアン)。で、UTF-16-BE の 1 バイト目と 2 バイト目を入れ替えたのが UTF-16-LE(リトルエンディアン)。例えば全角カタカナの「プ」は、ユニコード表(16 進数)では 30 D7 の 2 バイトで表されるが、UTAU.exe 内では逆順となり、D7 30 の 2 バイトで表される。
逆になるのは非常に分かりづらいが、これは UTAU の問題ではなく、Intel CPU の伝統なので受け入れるしかない。

しかし、バイト列レベルで見ると、半角英数については類似性があり、Shift-JIS のコードにゼロを付加した物が UTF-16-LE となる。例えば「ABC」は Shift-JIS だと 16 進数で 41 42 43 の 3 バイトとなるが、UTF-16-LE だと 41 00 42 00 43 00 の 6 バイトとなる。このため、半角英数を UTF-16-LE で保存して、Shift-JIS だと思って開くと、間延びしたように表示される(右の図をクリックして確認してほしい)。
また、プログラミングの視点で見ると、0x00 を文字列の終端と見なす C 言語などでは、何も考えずに UTF-16-LE の文字列を読み込むと、途中に出現する 0x00 のせいで、文字列が途切れてしまうことがあり、注意が必要となる。
Mac 版 UTAU(UTAU-Synth)
UTAU-Synth はよくわからないが、どうやら、oto.ini と prefix.map は UTF-8、それ以外のファイルは Shift-JIS で出力するようになっている模様。oto.ini と prefix.map が用いる UTF-8 では、半角英数は 1 バイト、日本語はたいてい 3 バイトとなる。半角カナも 3 バイト。例えば、「ABあ愛」は 1+1+3+3=8 バイトとなる。
UTF-8 と Shift-JIS は、半角英数は同じコードを使っている。つまり、半角英数だけのファイルなら、UTF-8 として扱う UTAU-Synth でも、Shift-JIS として扱う UTAU でも、問題なく開ける。
oto.ini / prefix.map 以外は UTAU-Synth も Shift-JIS なので、UTAU とファイルを共用できることになる。ただし、Windows の Shift-JIS と Mac の Shift-JIS は方言のようなものが多少異なり、一部の文字に互換性が無い。通常使う範囲ではあまり問題にならないが、記号類は避けた方が良いだろう。
おまけ知識
※通常のユーザーはここを読み飛ばして構わないこの記事でも混同して使っているが、厳密には、文字コードを考える時には、「キャラクターセット」と「エンコーディング」の 2 つに分けて考える必要がある。
キャラクターセットは、「どんな文字を取り扱うか(文字集合)」で、例えば欧米ならアルファベットだけでいいよ、とか、日本なら漢字も入れたいね、という話になる。
エンコーディングは、キャラクターセットで扱う文字を、具体的にどんなバイト列で表現するかを決める。
Shift-JIS の場合は、キャラクターセットとエンコーディングがセットになっている感じなので、キャラクターセットやエンコーディングを意識しなくて良い。
UTF-16-LE と UTF-8 は両方とも、キャラクターセットとしては世界中の文字を扱う Unicode で同じある。同じ文字を、どのようにバイト列にするかの規則(エンコーディング)が違うにすぎない。
UTF-16-LE は「すべて 2 バイト」という処理しやすい規則になっている。一方 UTF-8 は、半角英数という最もよく使われる文字を 1 バイトにして、容量の節約を図っている。同じキャラクターセットを表現するにしても、用途によって適したエンコーディングが変わる、という話である。
参考リンク
今回の話、自分も全部をきちんと理解しているわけではないので、各自ググっていただきたい。誤りや追加情報があったら教えて下さい。
UTAU ゲーム(UTAU キャラクターや UTAU 音源を使用しているゲーム)の一覧を、UTAU ユーザー互助会 Wiki 内に作成。UTAU に関連したゲームが増えてきたので、一覧があると便利かなと思ったので。
RPG ほか、カテゴリ毎にゲームを整理。ウミネコロン RPG、夜行、甘藍ゲームなど。
関連するニコニコ動画のタグとしては、UTAUゲーム化計画タグが挙げられる。なお、UTAURPG CM 企画は、当初から CM のみの企画で、ゲーム自体は作らないとのことなので、一覧に入れていない。
※現時点で把握しているゲームはすべて入れましたが、私の知らない UTAU ゲームはまだあると思いますし、また、今後どんどん増えていくと思います。UTAU ゲームをご存じの方は、リストに追加して頂ければと思います。テンプレートをページ下部に入れておきましたので、ご活用ください。
RPG ほか、カテゴリ毎にゲームを整理。ウミネコロン RPG、夜行、甘藍ゲームなど。
関連するニコニコ動画のタグとしては、UTAUゲーム化計画タグが挙げられる。なお、UTAURPG CM 企画は、当初から CM のみの企画で、ゲーム自体は作らないとのことなので、一覧に入れていない。
※現時点で把握しているゲームはすべて入れましたが、私の知らない UTAU ゲームはまだあると思いますし、また、今後どんどん増えていくと思います。UTAU ゲームをご存じの方は、リストに追加して頂ければと思います。テンプレートをページ下部に入れておきましたので、ご活用ください。
数ある UTAU 音源を、「声質」(声の雰囲気)で整理・検索できるサイトを開設しました。
声質の中でも、「しゃべったときの声質」に焦点を当てています。
検索フォームで、声質の情報(声質を表すタグや、UTAU 音源声質アンケートの結果など)を入力すると、条件に合う音源を検索することができます。
検索結果からすぐに、「しゃべった時のボイスサンプル」を聞くことができます。
UTAU 音源自動ナレーションツール「唄詠(うたよみ)」を使っていると、「こんな声でしゃべってくれる音源ないかなぁ」と思うことがよくあると思います。本サイトは、そのような時に役立つサイトを目指しています。検索対象となる音源は、唄詠使用支援中の音源です。
登録・編集はどなたでもできますので、是非、情報の充実にご協力をお願いします。現在の登録件数は 81 件です。
声質の中でも、「しゃべったときの声質」に焦点を当てています。
検索フォームで、声質の情報(声質を表すタグや、UTAU 音源声質アンケートの結果など)を入力すると、条件に合う音源を検索することができます。
検索結果からすぐに、「しゃべった時のボイスサンプル」を聞くことができます。
UTAU 音源自動ナレーションツール「唄詠(うたよみ)」を使っていると、「こんな声でしゃべってくれる音源ないかなぁ」と思うことがよくあると思います。本サイトは、そのような時に役立つサイトを目指しています。検索対象となる音源は、唄詠使用支援中の音源です。
登録・編集はどなたでもできますので、是非、情報の充実にご協力をお願いします。現在の登録件数は 81 件です。
UTAU 音源による自動ナレーションツール「唄詠」を 1 から作り直している。
唄詠のこれまでと 2015 年以降の予定に書いたとおり、唄詠の次のバージョンアップはセキュリティーアップデートである。唄詠の開発に使っている C++Builder の影響によるものだが、実のところ、唄詠で画像を扱っているのは、音源設定画面で UTAU 音源の画像を表示するところくらいなので、影響範囲は狭い。とはいえ、やはり安全に越したことは無い。
対応方法はこちらに書いたとおりいくつかあるが、現在は選択肢 4(C# での開発)を試している。
開発言語そのものが C++ から C# に変わるので、すべて 1 から作り直しとなる。
普通のアプリであっても作り直しとなると大変だが、唄詠はさらに大変。COM やら SAPI やら、いろいろ複雑なのだ。特に、SAPI の中でもエンジン側となると、C# との組み合わせ資料がほとんどなく、そもそも実現可能なのかもよく分からなかった。
それでもなんとか、いろいろ実験をして、唄詠エンジンの原始版が C# で動いたので、実現可能性が高まってきた。
次は、GUI 側の原始版を作って、唄詠全体のフレームワークを C# で実現できそうかどうか、確認したい。
道のりは長そうだ。
唄詠のこれまでと 2015 年以降の予定に書いたとおり、唄詠の次のバージョンアップはセキュリティーアップデートである。唄詠の開発に使っている C++Builder の影響によるものだが、実のところ、唄詠で画像を扱っているのは、音源設定画面で UTAU 音源の画像を表示するところくらいなので、影響範囲は狭い。とはいえ、やはり安全に越したことは無い。
対応方法はこちらに書いたとおりいくつかあるが、現在は選択肢 4(C# での開発)を試している。
開発言語そのものが C++ から C# に変わるので、すべて 1 から作り直しとなる。
普通のアプリであっても作り直しとなると大変だが、唄詠はさらに大変。COM やら SAPI やら、いろいろ複雑なのだ。特に、SAPI の中でもエンジン側となると、C# との組み合わせ資料がほとんどなく、そもそも実現可能なのかもよく分からなかった。
それでもなんとか、いろいろ実験をして、唄詠エンジンの原始版が C# で動いたので、実現可能性が高まってきた。
次は、GUI 側の原始版を作って、唄詠全体のフレームワークを C# で実現できそうかどうか、確認したい。
道のりは長そうだ。
UTAU 関連の情報共有を目的に、UTAU 勉強会が神田で開催されたので、参加してきた。
Twitter にも投げたが、改めて概要をここにまとめてみる。
勉強会はリレー講義形式で行われた。6 人の講師役が、それぞれのテーマについて説明を行う。各講師の持ち時間は 30 分という比較的短い時間だったが、資料等を用いながら時間いっぱい語っていた。
以下、各講師の内容と、それに対する感想などを。
ピッチの特徴的な遷移を、ピッチ曲線の形から「V ピッチ」「A ピッチ」などと名付けて分類。それぞれの型の発声上の特徴や、マッチする曲調などを解説。
例えば V ピッチは、音符の先頭(子音部)のピッチが一瞬落ち込み、ピッチ曲線が V 字を描く。声の安定感・迫真度が増すので、カッコイイ歌い方・スピード感のある歌い方に向いている、という具合だ。
ピッチ以外にも、リズム感やニュアンスなどの説明もあった。
調声パターンを分かりやすく分類してもらえるというのは参考になる。例えば、うたりすで肉声のピッチを抽出すると、確かに V ピッチなどの曲線が出てくるが、単に出てきた曲線を眺めるだけなのと、特徴をざっと把握しているのでは、その後の調声のやりやすさに大きな違いが出ると思う。
UTAU 音源を製作するには、声を録音するだけではなく、発音のタイミングを指定する oto.ini を作成する必要がある。oto.ini を作るのは大変なのだが、setParam というツールを使うと、少しやりやすくなる。
setParam の画面の見方や、操作方法などについて、説明していた。
俺自身は原音設定をしたことがないが、それでも、巽さんの口から溢れてくる経験豊富感は感じ取れた。
setParam では、原音がスペクトラム表示されるが、そのスペクトラムは、ア行、カ行といった行毎に特徴がある。それぞれの行で、スペクトラム上のどの位置に各種設定値をセットすればよいか、という実践的な内容。
たいていの場合、スペクトラムの見た目から設定を行えば、ほどほど良い設定が行える。その上で、実際に音を聞きながら細かい調整をする、という 2 段階方式にすることで、大幅に設定時間を短縮できるようだ。
理論で目安、感覚で微調整というのは、効率も良く、かつ、品質もしっかりしたものができそうな印象で、音源ユーザー側としても、嬉しい内容だった。
CVVC 音源は、連続音音源と比べると、録音に要する時間が少ない。時間が少なくて済むから、声質のブレも少ないし、多音階などにもチャレンジしやすいという。
ただ、メリットばかりとはいかない。録音時間が少ないのは、重複している発音を極限まで削っているからなのだが、逆に言えば、1 つのミスが多くの箇所に波及するということでもある。また、きちんと原音設定を理解していないと設定が難しいとのこと。
音源利用者側にとっては、音源製作者のメリットが間接的に享受できるものの、どちらかといえば、ノートが細切れになったりピッチをいじりにくくなったりというデメリットのほうが多い印象だ。
企画を実現していくに当たって大切なのは、目的、スケジュール、ルール(成果物フォーマットなど)の 3 点。これをしっかりと定めてから、思い切ってコンピしたい人にアタックすると良いとのこと。また、金銭関連はトラブルのもとなので、収入をどう扱い、費用負担は誰がするのかをしっかりと明言しておくべきとのこと。
共同開催者との意思疎通は大切で、文字(メール・チャット)よりも音声(通話)、音声よりも対面で、きちんと話し合おう。実際には会うのはなかなか大変だが、せめて通話はしたいと俺も思う(コンピに限らず)。Skype 等タダで通話できる時代になったわけだし。
保健体育 P はとても発表慣れというか、講義慣れしている感じだった。本職なのかと思ったが、どうやら違うとのこと。
UTAU 音源は、単独音から始まり、表情音や連続音、CVVC など、さまざまなバリエーションが出てきた。しかし、連続音が登場したときの感動みたいなものが、最近は無いとのこと。そんな中で、大きな可能性があるものとして、DLL 音源を挙げていた。
DLL 音源というのは、音声再生を音源側が把握&コントロールできる音源。例えば、低い音は野太く、高い音はか細く、というように、音高によって音の細さを変えたりすることも実現できる。
音源のバージョンアップも管理できる。今までの音源は、新バージョンを公開しても、ユーザーがそれを使ってくれるとは限らない。DLL 音源であれば、新バージョンを強制的に使わせることが可能だ。
他にも、音源使用日数によって使える音素を徐々に解放して増やしていったりとか、音源ガチャ(ガチャで引いた音素だけ使える)みたいなゲーム的要素を入れたりすることもできるなど、可能性は無限大だ。
ただ、聞いている中で気をつけなくてはいけないなと思ったのは、ユーザー目線を忘れたら地雷になるということ。音源側がすべてを握っているからこそ、ユーザーに配慮する必要がある。
UTAU 界隈の不思議さも合わせて加味する必要があって、UTAU 界隈ではなぜか、必ずしもクオリティーの高い物が求められるわけではない。例えば、音源をバージョンアップして、良い機材で品質の高い音源を作り直しましたと言っても、昔の古い機材で作った音源の方が好きという人がいる。常に最新の音源を提供するタイプの DLL 音源は、意外と歓迎されないかもしれない。
次回は、音源の中の人の話も聞いてみたい。録音時に苦労するところ、使用している機材を選んだ理由、録音のコツなど。あるいは、キーホルダーみたいなグッズを作っている人もいるので、そういう人の話なども。
プラグイン作者としては、他のプラグイン作者の話も気になるところ。どんな環境で、どのくらい時間掛けてプラグインを作っているのか。大変なところは何か。ユーザーからのフィードバックの扱いをどうしているか、などなど。
Twitter にも投げたが、改めて概要をここにまとめてみる。
勉強会はリレー講義形式で行われた。6 人の講師役が、それぞれのテーマについて説明を行う。各講師の持ち時間は 30 分という比較的短い時間だったが、資料等を用いながら時間いっぱい語っていた。
以下、各講師の内容と、それに対する感想などを。
"調声する"ってなんなんだ!~様々な調声法の考察~
- 講師:きっとかっとさん
- 資料:Twitter より(2014/12/31 までとのこと)
ピッチの特徴的な遷移を、ピッチ曲線の形から「V ピッチ」「A ピッチ」などと名付けて分類。それぞれの型の発声上の特徴や、マッチする曲調などを解説。
例えば V ピッチは、音符の先頭(子音部)のピッチが一瞬落ち込み、ピッチ曲線が V 字を描く。声の安定感・迫真度が増すので、カッコイイ歌い方・スピード感のある歌い方に向いている、という具合だ。
ピッチ以外にも、リズム感やニュアンスなどの説明もあった。
調声パターンを分かりやすく分類してもらえるというのは参考になる。例えば、うたりすで肉声のピッチを抽出すると、確かに V ピッチなどの曲線が出てくるが、単に出てきた曲線を眺めるだけなのと、特徴をざっと把握しているのでは、その後の調声のやりやすさに大きな違いが出ると思う。
setParam を用いた原音設定の解説
- 講師:巽さん
- 資料:slideshare
UTAU 音源を製作するには、声を録音するだけではなく、発音のタイミングを指定する oto.ini を作成する必要がある。oto.ini を作るのは大変なのだが、setParam というツールを使うと、少しやりやすくなる。
setParam の画面の見方や、操作方法などについて、説明していた。
俺自身は原音設定をしたことがないが、それでも、巽さんの口から溢れてくる経験豊富感は感じ取れた。
速く正確に原音設定する方法
- 講師:Caparo Ulula さん
- 資料:席上配布のみ
setParam では、原音がスペクトラム表示されるが、そのスペクトラムは、ア行、カ行といった行毎に特徴がある。それぞれの行で、スペクトラム上のどの位置に各種設定値をセットすればよいか、という実践的な内容。
たいていの場合、スペクトラムの見た目から設定を行えば、ほどほど良い設定が行える。その上で、実際に音を聞きながら細かい調整をする、という 2 段階方式にすることで、大幅に設定時間を短縮できるようだ。
理論で目安、感覚で微調整というのは、効率も良く、かつ、品質もしっかりしたものができそうな印象で、音源ユーザー側としても、嬉しい内容だった。
CVVC のイロハのイ
おふとん P は、CVVC 音源についての基礎。CVVC 音源は、音源製作者側にメリットのある音源であり、そのメリットを整理して紹介していた。CVVC 音源は、連続音音源と比べると、録音に要する時間が少ない。時間が少なくて済むから、声質のブレも少ないし、多音階などにもチャレンジしやすいという。
ただ、メリットばかりとはいかない。録音時間が少ないのは、重複している発音を極限まで削っているからなのだが、逆に言えば、1 つのミスが多くの箇所に波及するということでもある。また、きちんと原音設定を理解していないと設定が難しいとのこと。
音源利用者側にとっては、音源製作者のメリットが間接的に享受できるものの、どちらかといえば、ノートが細切れになったりピッチをいじりにくくなったりというデメリットのほうが多い印象だ。
たのしいコンピや企画を行うためのたこやき式メソッド
保健体育 P(白亜さん)は、コンピ CD などの企画を立てる際の注意点を解説。企画を実現していくに当たって大切なのは、目的、スケジュール、ルール(成果物フォーマットなど)の 3 点。これをしっかりと定めてから、思い切ってコンピしたい人にアタックすると良いとのこと。また、金銭関連はトラブルのもとなので、収入をどう扱い、費用負担は誰がするのかをしっかりと明言しておくべきとのこと。
共同開催者との意思疎通は大切で、文字(メール・チャット)よりも音声(通話)、音声よりも対面で、きちんと話し合おう。実際には会うのはなかなか大変だが、せめて通話はしたいと俺も思う(コンピに限らず)。Skype 等タダで通話できる時代になったわけだし。
保健体育 P はとても発表慣れというか、講義慣れしている感じだった。本職なのかと思ったが、どうやら違うとのこと。
day after tomorrow
- 講師:まるさん
- 資料:Google Drive
UTAU 音源は、単独音から始まり、表情音や連続音、CVVC など、さまざまなバリエーションが出てきた。しかし、連続音が登場したときの感動みたいなものが、最近は無いとのこと。そんな中で、大きな可能性があるものとして、DLL 音源を挙げていた。
DLL 音源というのは、音声再生を音源側が把握&コントロールできる音源。例えば、低い音は野太く、高い音はか細く、というように、音高によって音の細さを変えたりすることも実現できる。
音源のバージョンアップも管理できる。今までの音源は、新バージョンを公開しても、ユーザーがそれを使ってくれるとは限らない。DLL 音源であれば、新バージョンを強制的に使わせることが可能だ。
他にも、音源使用日数によって使える音素を徐々に解放して増やしていったりとか、音源ガチャ(ガチャで引いた音素だけ使える)みたいなゲーム的要素を入れたりすることもできるなど、可能性は無限大だ。
ただ、聞いている中で気をつけなくてはいけないなと思ったのは、ユーザー目線を忘れたら地雷になるということ。音源側がすべてを握っているからこそ、ユーザーに配慮する必要がある。
UTAU 界隈の不思議さも合わせて加味する必要があって、UTAU 界隈ではなぜか、必ずしもクオリティーの高い物が求められるわけではない。例えば、音源をバージョンアップして、良い機材で品質の高い音源を作り直しましたと言っても、昔の古い機材で作った音源の方が好きという人がいる。常に最新の音源を提供するタイプの DLL 音源は、意外と歓迎されないかもしれない。
まとめ
合計 3 時間分、バラエティーに富んだトピックの勉強会は面白かった。説明の雰囲気も講師それぞれ異なり、そこも味がある。運営の皆様、本当にお疲れ様でした。次回は、音源の中の人の話も聞いてみたい。録音時に苦労するところ、使用している機材を選んだ理由、録音のコツなど。あるいは、キーホルダーみたいなグッズを作っている人もいるので、そういう人の話なども。
プラグイン作者としては、他のプラグイン作者の話も気になるところ。どんな環境で、どのくらい時間掛けてプラグインを作っているのか。大変なところは何か。ユーザーからのフィードバックの扱いをどうしているか、などなど。
参考資料
- 第 1 回 UTAU 勉強会 in 神田 告知サイト
- パンフレット(PDF)
- UTAU 勉強会準備会 運営 Twitter
- #utaustudy01 Twitter ハッシュタグ
- 中継タイムシフトコミュニティー
- アンケート


お祭りの参加方法は簡単で、天月りよんや焔音レイを使った動画をニコニコ動画に投稿し、特定のタグをロックするだけ。俺も 8 月に 1 つ動画を投稿した。
俺はいつも、動画を投稿する際は、自分なりのテーマを決めて製作している。
今回のテーマは、クロスジャンルエクステンション(Cross Genre Extension:XGX)。ジャンルの垣根を越えて輪を広げていくという趣旨で命名したのだが、要は、「UTAU 音源に縁もゆかりもない人たちにも、UTAU 音源に触れてもらう」という機会を作る試みだ。
今回投稿した動画のカテゴリは、音楽でも UTAU でも VOCALOID でもなく、「料理」。
内容としては非常にシンプルかつ、本編は 15 秒という短さで、お気に入りのラーメン屋を紹介している。そこのナレーションに UTAU 音源を使用しているという流れだ。ラーメン好きの人や、料理クラスタの人が動画を見た際に、UTAU の声を聴いて、UTAU に興味を持ってくれたら嬉しい。
しかしながら、それぞれのお祭りの指定タグである「天月シリーズ誕生祭 2014」および「焔音レイ生誕祭 2014」で見ると、双方とも、今回の動画が再生数 2 位を戴いている(9/30 時点)。
一般的に誕生祭の動画を閲覧しているのが UTAU クラスタの人であることを考えると、平均再生数を上回っているということは、上乗せ分のいくらかは、料理関係の人が閲覧してくれたと考えて良いだろう。UTAU に縁のない人にも触れてもらうという試みは、多少なりとも奏功したのではないか。
願わくば、UTAU 動画を巡ってくれたり、UTAU での創作を初めてくれたりと、UTAU コミュニティーが広がらんことを。

唄詠は UTAU 音源による自動ナレーションツールで、UTAU 音源によるおしゃべり「HANASU」を手軽に行うことができるようになります。
今回はマイナーバージョンアップで、音源登録画面に音素種別(連続音音源など)が表示されるようになったり、マルチスレッド対応が少しだけ強化されたりしています。
唄詠の設定で「唄詠の最新情報・更新版を自動的に確認する」を有効にしている場合、3 日以内に自動的に今回の最新バージョンにアップデートされます。
すぐにアップデートしたい場合は、「今すぐ最新情報を確認する」ボタンをクリックすれば、アップデートを開始することができます。
手動でアップデートしたい場合や、新規にインストールしたい場合は、下記サイトからどうぞ。
- ダウンロード……唄詠公式サイト

発音関連では、
- モジュレーション(mod)が指定可能になりました。
- 一部の prefix.map に対応できていないバグを修正しました……水音ラルなどが使用可能になりました。
- 連続音音源使用時に、文章の先頭が発声されないことがあるバグを修正しました。
などが改善されています。
それ以外では、
- 音源設定のインポート・エクスポートが可能になりました。
という機能が追加になり、OS 再インストール時などの対応が便利になりました。
唄詠の設定で「唄詠の最新情報・更新版を自動的に確認する」を有効にしている場合、3 日以内に自動的に今回の最新バージョンにアップデートされます。
すぐにアップデートしたい場合は、「今すぐ最新情報を確認する」ボタンをクリックすれば、アップデートを開始することができます。
手動でアップデートしたい場合は、下記サイトからどうぞ。
- ダウンロード……唄詠公式サイト
The Annoying Orange という動画が投稿された。
海外の漫才動画の日本語吹き替え版のようだ。
オレンジがリンゴにちょっかいをだす動画なのだが、海外独特のキャラデザ(?)がなんとも不気味。見た瞬間にかなりのインパクトを受けた。
そんな 2 人(?)がシュールなやりとりを行う。
動画の作りとしては、漫才のタイミングに合わせてそれぞれのセリフのスピードをコントロールしている模様。きちんと手を入れて作ってあるのではないか。
是非一度見てみて欲しい。
この動画は、唄詠(
UTAU 音源で手軽に HANA せるツール)を利用した動画の中で、自分以外が投稿した初めての動画。
唄詠を利用した動画第 1 号かどうかは、唄詠簡易説明書動画のコンテンツツリー子作品で判定している。先頭 4 つが自分の動画なので、今回の動画が第三者初。
海外の漫才動画の日本語吹き替え版のようだ。
オレンジがリンゴにちょっかいをだす動画なのだが、海外独特のキャラデザ(?)がなんとも不気味。見た瞬間にかなりのインパクトを受けた。
そんな 2 人(?)がシュールなやりとりを行う。
動画の作りとしては、漫才のタイミングに合わせてそれぞれのセリフのスピードをコントロールしている模様。きちんと手を入れて作ってあるのではないか。
是非一度見てみて欲しい。
この動画は、唄詠(

唄詠を利用した動画第 1 号かどうかは、唄詠簡易説明書動画のコンテンツツリー子作品で判定している。先頭 4 つが自分の動画なので、今回の動画が第三者初。
UTAU 音源でおしゃべりができるようになる SAPI エンジン「唄詠」(うたよみ)をバージョンアップしました。
今回はバグ修正のための小規模バージョンアップです。音源登録時のバグにより、一部のテキストスピーチソフトで音源名が正しく表示されなくなるバグを修正しました。
唄詠の設定で「唄詠の最新情報・更新版を自動的に確認する」を有効にしている場合、3 日以内に自動的に今回の最新バージョンにアップデートされます。
すぐにアップデートしたい場合は、「今すぐ最新情報を確認する」ボタンをクリックすれば、アップデートを開始することができます。
手動でアップデートしたい場合は、下記サイトからどうぞ。
今回はバグ修正のための小規模バージョンアップです。音源登録時のバグにより、一部のテキストスピーチソフトで音源名が正しく表示されなくなるバグを修正しました。

すぐにアップデートしたい場合は、「今すぐ最新情報を確認する」ボタンをクリックすれば、アップデートを開始することができます。
手動でアップデートしたい場合は、下記サイトからどうぞ。
- ダウンロード……唄詠公式サイト

調声部分をプラグインとして独立させ、プラグインを自由に選べる構造にしました。現時点ではプラグインは実質 1 種類のみですが、今後プラグインが増えてくれば、唄詠の活用場面がさらに広がっていくと思います。
その他、いくつか細かな使い勝手を向上させています。
唄詠の設定で最新情報を確認するにしている場合、3 日以内に自動的に今回の最新バージョンにアップデートされます。ただし、Windows 8 でお使いの場合は、更新確認ダイアログのボタンが表示されない不具合がありますので、お手数ですが手動でダウンロードをお願いします(Windows 8.1 は問題ありません)。
- ダウンロード……唄詠公式サイト
また、開発者の方々向けに、唄詠の調声プラグインを開発するための SDK を公開いたしましたので、こちらも合わせてご参照下さい。
- 開発者向け……唄詠調声プラグイン SDK
5,000 以上あると言われる UTAU 音源を、声質によってカテゴライズしようという試み、UTAU 音源声質アンケート。年齢感や力強さなど、いくつかの指標をアンケートによって数値化しており、「こんな音源欲しいな」と思ったときに探す手がかりとなる。
アンケートはいろいろな音源で実施されるようになってきている(Twitter で探すとたくさん出てくる)ので、それらをワンストップで引き受けるウェブサイトがあるといいなと思う。
アンケートの作成、回答、リアルタイム集計、カテゴライズ、指標別一覧……。これらをまとめてやってくれるサイトがあれば、アンケート実施者も、アンケート利用者も、お互い使いやすいのではないか。
専用サイトであれば、音源名を入力するだけでアンケートが作成できるようになるだろう。
しかし、専用サイトのトップに「未回答音源一覧」などというリンクを設けられていれば、ついでに他の音源に回答することも可能となる。
回答規定数の 10 に達して以降、新たな回答が来る度に、自動的に結果を再集計して表示してくれる。アンケート作成者にとっては、集計結果を手作業でどこかにアップする手間が省けるし、利用者にとっては、常に最新の結果を利用できるメリットがある。
現在の声質アンケートの中には、回答が 10 に達するとアンケートを終えてしまうものがある。10 という数はひとまずの区切りとして現実的だと思うが、もっと多いに越したことはない。専用サイトのリアルタイム集計なら、どんどん回答数を増やしていける。
CGI とデータベースが使えれば、技術的な難易度としてはそこまで高くない気がする。作業としてはある程度の量があるほか、ユーザービリティーを考えないと使いづらくなるので、その辺りが大変そうだが。
ちなみに俺は唄詠で手一杯なので作れないが、作ってくれる人がいるのなら、打ち合わせへの協力などはできると思う。
アンケートはいろいろな音源で実施されるようになってきている(Twitter で探すとたくさん出てくる)ので、それらをワンストップで引き受けるウェブサイトがあるといいなと思う。
アンケートの作成、回答、リアルタイム集計、カテゴライズ、指標別一覧……。これらをまとめてやってくれるサイトがあれば、アンケート実施者も、アンケート利用者も、お互い使いやすいのではないか。
アンケート作成
現在は google docs で行うのが主流。項目はほぼ固定されているので迷うことはないと思うが、ちまちま作る感は否めない。専用サイトであれば、音源名を入力するだけでアンケートが作成できるようになるだろう。
回答
1 つのアンケートに回答する手間としては、google docs でも専用サイトでも変わらない。しかし、専用サイトのトップに「未回答音源一覧」などというリンクを設けられていれば、ついでに他の音源に回答することも可能となる。
リアルタイム集計
専用サイトの大きな利点の 1 つがリアルタイム集計。回答規定数の 10 に達して以降、新たな回答が来る度に、自動的に結果を再集計して表示してくれる。アンケート作成者にとっては、集計結果を手作業でどこかにアップする手間が省けるし、利用者にとっては、常に最新の結果を利用できるメリットがある。
現在の声質アンケートの中には、回答が 10 に達するとアンケートを終えてしまうものがある。10 という数はひとまずの区切りとして現実的だと思うが、もっと多いに越したことはない。専用サイトのリアルタイム集計なら、どんどん回答数を増やしていける。
カテゴライズ
集計結果から音源をカテゴライズして、グループ別、タイプ別(それぞれ、複数の指標をとりまとめたもの)で一覧表示してくれると、利用者としては使いやすい。指標別一覧
集計結果をシンプルに表示して、「声が明るい順」などそれぞれの指標でソートできると、利用者としては使いやすい。というわけで
上記のようなサイトを誰か作ってくれないかな……。CGI とデータベースが使えれば、技術的な難易度としてはそこまで高くない気がする。作業としてはある程度の量があるほか、ユーザービリティーを考えないと使いづらくなるので、その辺りが大変そうだが。
ちなみに俺は唄詠で手一杯なので作れないが、作ってくれる人がいるのなら、打ち合わせへの協力などはできると思う。
テキストスピーチソフト(棒読みちゃんなど)の音声に UTAU 音源を使うためのツール「唄詠」の作り(内部構造)を変えている。
現行の唄詠は、言ってみればオールインワンパッケージ型。システムへの音源登録、テキストスピーチソフトとの連携、文章から音声への変換(調声)、ユーザーインターフェイスなどを、すべて一手に引き受けている。
これはこれでメリットがある。開発工数が比較的少なく済む、試行錯誤に伴う内部構造を変更しやすい、効率の良いコードを書きやすい、UI を作りやすい、などなどだ。
しかし、唄詠は次のステージに入った。
これまでは基礎体力を上げることを中心に開発していた。きちんとシステムと連携すること、任意の文章をとりあえず読めること、応答性が実用の範囲内であること、などなど。
しかし、今後は、調声部分の比重が高まってくる。
そうなってくると、調声部分だけ独立させた構造となる
現行の唄詠は、スーパー棒読み状態だが、今後、多少は自然な読み方をしてくれる調声をしたいと思っている。多くのユーザーは、新しい調声を好むだろうが、例えば既にスーパー棒読みで作品を作り始めてしまっているユーザーは、その作品の完成まではスーパー棒読みを使い続けたいかもしれない。
調声プラグイン方式にしておけば、現行のスーパー棒読みも残しておくことで、ユーザーに好きな調声を選んでもらうことができる。
また、期待したいのは、独自の調声エンジンを開発・公開してくれる人が現れること。
唄詠と同じようなソフトを 1 から開発するのは、それなりに骨が折れる作業で、要求される知識の種類も多い。ユーザーにとっても、複数の似たようなソフトをインストールするのは面倒であろう。
しかし、調声プラグイン方式であれば、開発者は調声の部分だけを開発すれば良いことになる。開発のハードルは格段に下がるし、ユーザー側の負担も少ない。
面白い話し方、流暢な話し方、デスボイス、悲鳴、ワイワイガヤガヤ演出……。いろんな話し方をプラグインとして開発していただければ、もっと HANASU が楽しく便利になると思う。
現行の唄詠は、言ってみればオールインワンパッケージ型。システムへの音源登録、テキストスピーチソフトとの連携、文章から音声への変換(調声)、ユーザーインターフェイスなどを、すべて一手に引き受けている。
これはこれでメリットがある。開発工数が比較的少なく済む、試行錯誤に伴う内部構造を変更しやすい、効率の良いコードを書きやすい、UI を作りやすい、などなどだ。
しかし、唄詠は次のステージに入った。
これまでは基礎体力を上げることを中心に開発していた。きちんとシステムと連携すること、任意の文章をとりあえず読めること、応答性が実用の範囲内であること、などなど。
しかし、今後は、調声部分の比重が高まってくる。

- 調声プラグイン方式
の方がメリットが大きくなってくる。
現行の唄詠は、スーパー棒読み状態だが、今後、多少は自然な読み方をしてくれる調声をしたいと思っている。多くのユーザーは、新しい調声を好むだろうが、例えば既にスーパー棒読みで作品を作り始めてしまっているユーザーは、その作品の完成まではスーパー棒読みを使い続けたいかもしれない。
調声プラグイン方式にしておけば、現行のスーパー棒読みも残しておくことで、ユーザーに好きな調声を選んでもらうことができる。
また、期待したいのは、独自の調声エンジンを開発・公開してくれる人が現れること。
唄詠と同じようなソフトを 1 から開発するのは、それなりに骨が折れる作業で、要求される知識の種類も多い。ユーザーにとっても、複数の似たようなソフトをインストールするのは面倒であろう。
しかし、調声プラグイン方式であれば、開発者は調声の部分だけを開発すれば良いことになる。開発のハードルは格段に下がるし、ユーザー側の負担も少ない。
面白い話し方、流暢な話し方、デスボイス、悲鳴、ワイワイガヤガヤ演出……。いろんな話し方をプラグインとして開発していただければ、もっと HANASU が楽しく便利になると思う。

最新の Lib UTAU を使用することにより、解析能力が向上しました。
その他、細かな使い勝手を向上させています。
今後当面の間、うたりすはバージョンアップできないと思います。どなたさまも、こちらのバージョンをお使い下さい。
- ダウンロード……うたりす公式ページ
UTAU 関連のソフトウェア(プラグインなど)を開発する際に使える C++ クラスライブラリ、「Lib UTAU」をバージョンアップしました。
原音設定の解析能力を向上させ、多音階音源などで用いられる 0 バイトの oto.ini(サブフォルダに実際の原音設定がある)に対応しました。また、プレフィックスマップの解析も行えるようになりました。
原音設定の解析能力を向上させ、多音階音源などで用いられる 0 バイトの oto.ini(サブフォルダに実際の原音設定がある)に対応しました。また、プレフィックスマップの解析も行えるようになりました。
- ダウンロード……Lib UTAU 公式サイト

prefix.map に対応。これにより、緋惺や句音コノ。など、全音階にサフィックスが付いている音源でも再生が可能になりました。
また、自動アップデート機能を搭載。今回のバージョンをインストールしておけば、次回以降、唄詠がバージョンアップされた際は自動的にアップデートが行われるため、便利です。
- ダウンロード……唄詠公式サイト

音源情報登録・修正時に、空の oto.ini を指定すると、読み上げが行えないバグを修正しました。
多音階音源などでは、音源のトップフォルダに空の oto.ini をおくことが多く、そのようなケースに対応しました。
これにより、灯月アカリなどを使用可能になりました。
なお、現時点で prefixmap には対応していませんので、すべての音階にサフィックスが付いている緋惺などの音源はまだ使えません。
その他の改善点として、唄詠の最新情報を表示する機能を付けました。バージョンアップなどがあった場合にその情報が表示されます。
- ダウンロード……唄詠公式ページ

主な改良点は、
- 音声合成速度の高速化(マルチスレッドレンダリングと逐次合成)
- 連続音音源での読み上げでケロることがあるのを改善。
- 音源情報登録・修正時の試聴機能を搭載。
- 音源情報登録・修正時の音域選択で、ピアノ画面による直感的な指定方法を搭載。
目玉は高速化です。
複数の文字を同時に合成するマルチスレッドレンダリングでは、こちらの記事のように、8 スレッド CPU で約 5 倍近い高速化を実現しています。
また、逐次合成モードを搭載したことにより、テキストスピーチソフトとの相性はあるものの、長い文章でも一瞬で発声できるようになりました。どのテキストスピーチソフトで逐次合成が有効かは、ヘルプを参考にして下さい。
地味ながら重要な改善点としては、連続音音源でのケロりを改善しました。連続音音源で、今までよりも自然にしゃべってくれるようになりました。
歌唱合成ツール UTAU に付属する resampler.exe に渡すパラメーター(コマンドライン引数)について、最近のバージョンの情報を網羅的にまとめているサイトが見当たらなかったので、ここでまとめてみた。UTAU 0.4.16 に付属の resampler.exe Ver14.02r について記している。
本稿は公式なものではなく、間違っている情報があるかもしれないことに注意。間違いを見つけた方は教えていただけると助かります。
resampler.exe を起動する際のパラメーターの構文は、
UTAU 音源の原音ファイル。歌唱したい歌詞に対応した原音 WAVE ファイルを指定する。
連続音音源なら「C:\Voice\ぱみゅ\_かかきかく.wav」などとなる。
歌唱合成結果を保存する WAVE ファイル。
歌唱する音程を指定する。
表記は UTAU の GUI(左側のピアノロール)と同じで、音名とオクターブ数字を用いる。オクターブ数字は、大きい方が高い音となる。
子音部(固定範囲)の伸縮率。0~200 の範囲で指定可能で、100 で伸縮なし。
値が大きいほど速度が上がり、時間軸上では縮小される。子音速度 0 で時間軸上 2 倍、200 で半分。
UTAU では、子音速度の比率で STP・先行発声・オーバーラップを伸縮している模様。また、食い込み補正(後述)の計算は伸縮後に行う。
音符のプロパティで指定できるフラグの他、下記が使用できる模様。
原音設定の左ブランクに相当する。単位はミリ秒。
音の長さをミリ秒単位で指定する。
例えば、テンポ 60 において四分音符であれば、音符としての長さは 1,000 ミリ秒となる。UTAU ではこの他に、以下のような要素を加味して length require を算出している模様。
原音設定の子音部に相当する。単位はミリ秒。
原音設定の右ブランクに相当する。単位はミリ秒。
音量を % 単位で指定する。
原音の音の揺らぎをどれだけ残すかを % 単位で指定する。
0 を指定すれば、原音の音程が揺らいでいても、<pitch percent> で指定した音程で安定する。
ピッチ曲線を「!<テンポ> <ピッチ文字列>」で表現する。
ピッチ文字列は、2 文字で 1 つのピッチベンド点を表す。<pitch percent> で指定した音高からのピッチのずれ(セント単位)を 12 ビット符号付き整数(マイナス値の場合は、4096-n で OK)で表した上で、Base 64 エンコードをして ASCII 2 文字にする。
例えば、1 セント高いピッチの場合は、
1(10 進数)→ 000000 000001(12 ビット 2 進数)→ AB(Base64)
となり、逆に、1 セント低いピッチの場合は、
-1(10 進数)→ 4096-1 = 4095(10 進数)→ 111111 111111(12 ビット 2 進数)→ //(Base64)
となる。
ピッチ指定の間隔は四分音符の 96 分の 1 で、その間隔ごとのピッチベンド点を、ASCII 2 文字で連ねていく。
例えば、<pitch percent> が C4 で、ピッチ文字列が AAABAC なら、
ド→ドより 1 セント高い音→ドより 2 セント高い音
のように推移していく。
同じ高さの点が続く場合は、Base64 の直後に「#回数#」を付加する。
例えば、1 セント高い音が 50 回続くなら、
AB#50#
となる。
ピッチ文字列が 2 文字の場合は、末尾に AA を付与するかもしれないが未確認。
ピッチベンドの先頭の位置は、音符の先頭 - 先行発声 - STP。
先行発声が大きく、直前の音符の長さが短い場合、直前の音符よりも先に発声されてしまうという状況が発生する可能性がある。
例えば、テンポ 360 で四分音符の「あ」「い」が続いている場面を考える。テンポ 360 において四分音符は 167 ミリ秒の長さがあるが、「い」の先行発声が 200 ミリ秒だとすると、「い」の方が先に発生されてしまう(ここでは「あ」の先行発声は 0 ミリ秒と仮定する)。
そういうおかしな状況が発生しないよう、UTAU では、直前の音符の半分の長さ以上に先行発声が食い込んでいる場合は、直前の音符が半分生き残るように、先行発声などの長さを調整する。
例の状況では、先行発声を約 83 ミリ秒にして、「あ」が半分発生されるようにする。
この補正のことを、(俺は勝手に)食い込み補正と呼んでいる。食い込み補正の処理は以下。
◆食い込み補正の発動条件
先行発声-オーバーラップ > 直前の音符の長さの半分
であれば発動
◆食い込み補正率
食い込み補正率 = 直前の音符の長さの半分÷(先行発声-オーバーラップ)
◆食い込み補正後の数値
食い込み補正後の先行発声 = 補正前の先行発声×食い込み補正率
食い込み補正後のオーバーラップ = 補正前のオーバーラップ×食い込み補正率
食い込み補正後の STP = 補正前の先行発声-補正後の先行発声
本稿は公式なものではなく、間違っている情報があるかもしれないことに注意。間違いを見つけた方は教えていただけると助かります。
resampler.exe を起動する際のパラメーターの構文は、
resampler.exe <input file> <output file> <pitch percent> <velocity> [<flags> [<offset> <length require> [<fixed length> [<end blank> [<volume> [<modulation> [<pitch bend>...]]]]]]][] で括られたパラメーターは省略可能。<flags>~<pitch bend> までを全部省略することもできるし(一番外側の [] を省略)、<flags> を残して <offset>~<pitch bend> までを省略することもできる(2 番目の [] を省略)。省略できるのは後方のパラメーターのみなので、<flags> を省略して次の <offset> は省略しない、というようなことはできない。
各パラメーターについて
名前 | 型 | 概要 | 例 |
---|---|---|---|
input file | 文字列 | 原音ファイル名 | C:\Voice\春歌ナナ\か.wav |
UTAU 音源の原音ファイル。歌唱したい歌詞に対応した原音 WAVE ファイルを指定する。
連続音音源なら「C:\Voice\ぱみゅ\_かかきかく.wav」などとなる。
名前 | 型 | 概要 | 例 |
---|---|---|---|
output file | 文字列 | 出力ファイル名 | C:\Project\春風ソング.cache\1_か_C4_wNAwRt.wav |
歌唱合成結果を保存する WAVE ファイル。
名前 | 型 | 概要 | 例 |
---|---|---|---|
pitch percent | 文字列 | 音高 | G#4 |

表記は UTAU の GUI(左側のピアノロール)と同じで、音名とオクターブ数字を用いる。オクターブ数字は、大きい方が高い音となる。
名前 | 型 | 概要 | 例 |
---|---|---|---|
velocity | 小数 | 子音速度 | 100 |
子音部(固定範囲)の伸縮率。0~200 の範囲で指定可能で、100 で伸縮なし。
値が大きいほど速度が上がり、時間軸上では縮小される。子音速度 0 で時間軸上 2 倍、200 で半分。
UTAU では、子音速度の比率で STP・先行発声・オーバーラップを伸縮している模様。また、食い込み補正(後述)の計算は伸縮後に行う。
名前 | 型 | 概要 | 例 |
---|---|---|---|
flags | 文字列 | フラグ | g-3Y90 |
音符のプロパティで指定できるフラグの他、下記が使用できる模様。
- N: No formant filter
- G: (Re)Genetate frequency list
- T: Export text frequency list
名前 | 型 | 概要 | 例 |
---|---|---|---|
offset | 小数 | オフセット | 5.0 |
原音設定の左ブランクに相当する。単位はミリ秒。
名前 | 型 | 概要 | 例 |
---|---|---|---|
length require | 整数 | 音長 | 550 |
音の長さをミリ秒単位で指定する。
例えば、テンポ 60 において四分音符であれば、音符としての長さは 1,000 ミリ秒となる。UTAU ではこの他に、以下のような要素を加味して length require を算出している模様。
- 音符としての長さ+先行発声(食い込み補正前)-後続先行発声(食い込み補正後)+後続オーバーラップ(食い込み補正後)+50
- 計算結果が fixed length より小さい場合は fixed length にする
- 50 単位で四捨五入(24 捨 25 入)する
名前 | 型 | 概要 | 例 |
---|---|---|---|
fixed length | 小数 | 子音部 | 115.0 |
原音設定の子音部に相当する。単位はミリ秒。
名前 | 型 | 概要 | 例 |
---|---|---|---|
end blank | 小数 | 右ブランク | 247.0 |
原音設定の右ブランクに相当する。単位はミリ秒。
名前 | 型 | 概要 | 例 |
---|---|---|---|
volume | 小数 | 音量 | 100 |
音量を % 単位で指定する。
名前 | 型 | 概要 | 例 |
---|---|---|---|
modulation | 小数 | モジュレーション | 0 |
原音の音の揺らぎをどれだけ残すかを % 単位で指定する。
0 を指定すれば、原音の音程が揺らいでいても、<pitch percent> で指定した音程で安定する。
名前 | 型 | 概要 | 例 |
---|---|---|---|
pitch bend | 文字列 | ピッチベンド | !120 AA#88#ABAKAbA0BSB2Cc |
ピッチ曲線を「!<テンポ> <ピッチ文字列>」で表現する。
ピッチ文字列は、2 文字で 1 つのピッチベンド点を表す。<pitch percent> で指定した音高からのピッチのずれ(セント単位)を 12 ビット符号付き整数(マイナス値の場合は、4096-n で OK)で表した上で、Base 64 エンコードをして ASCII 2 文字にする。
例えば、1 セント高いピッチの場合は、
1(10 進数)→ 000000 000001(12 ビット 2 進数)→ AB(Base64)
となり、逆に、1 セント低いピッチの場合は、
-1(10 進数)→ 4096-1 = 4095(10 進数)→ 111111 111111(12 ビット 2 進数)→ //(Base64)
となる。
ピッチ指定の間隔は四分音符の 96 分の 1 で、その間隔ごとのピッチベンド点を、ASCII 2 文字で連ねていく。
例えば、<pitch percent> が C4 で、ピッチ文字列が AAABAC なら、
ド→ドより 1 セント高い音→ドより 2 セント高い音
のように推移していく。
同じ高さの点が続く場合は、Base64 の直後に「#回数#」を付加する。
例えば、1 セント高い音が 50 回続くなら、
AB#50#
となる。
ピッチ文字列が 2 文字の場合は、末尾に AA を付与するかもしれないが未確認。
ピッチベンドの先頭の位置は、音符の先頭 - 先行発声 - STP。
食い込み補正について

例えば、テンポ 360 で四分音符の「あ」「い」が続いている場面を考える。テンポ 360 において四分音符は 167 ミリ秒の長さがあるが、「い」の先行発声が 200 ミリ秒だとすると、「い」の方が先に発生されてしまう(ここでは「あ」の先行発声は 0 ミリ秒と仮定する)。
そういうおかしな状況が発生しないよう、UTAU では、直前の音符の半分の長さ以上に先行発声が食い込んでいる場合は、直前の音符が半分生き残るように、先行発声などの長さを調整する。
例の状況では、先行発声を約 83 ミリ秒にして、「あ」が半分発生されるようにする。
この補正のことを、(俺は勝手に)食い込み補正と呼んでいる。食い込み補正の処理は以下。
◆食い込み補正の発動条件
先行発声-オーバーラップ > 直前の音符の長さの半分
であれば発動
◆食い込み補正率
食い込み補正率 = 直前の音符の長さの半分÷(先行発声-オーバーラップ)
◆食い込み補正後の数値
食い込み補正後の先行発声 = 補正前の先行発声×食い込み補正率
食い込み補正後のオーバーラップ = 補正前のオーバーラップ×食い込み補正率
食い込み補正後の STP = 補正前の先行発声-補正後の先行発声
関連記事
参考 URL
更新履歴
- 2014/03/23 デルタさん・masao さんのアドバイスを含め length require について加筆。その他いくつか更新。
自動 HANASU ツール「唄詠」について、高速化すべく作業中。
手法としてはよくある方法で、UTAU のツールを複数同時起動するというもの(いわゆるマルチスレッドレンダリング)。
で、実際のところ、どのくらい速くなるのか。数人のテスターの方に協力して頂いた結果が以下。

表の見方だが、CPU の「コア」は物理コア数、「スレ」はスレッド数。Intel 系はハイパースレッディング(SMT)を実装していることがあり、物理コア数の 2 倍のスレッドを同時に走らせることができる。
「Temp」はテンポラリフォルダがあるデバイスの種類。ここが「HDD」なら、ハードディスク上にテンポラリフォルダがある。
測定結果の「半スレ」「全スレ」はそれぞれ、UTAU ツールを 1 つだけ起動して音声合成した場合と比べて何倍のスピードになったかを記している。「半スレ」であれば、CPU が同時に走らせられるスレッド数の半分の数だけ UTAU ツールを起動している(CPU のスレッドが 8 なら 4 個起動、小数点以下切り捨て)。「全スレ」はスレッド数と同じだけ起動(CPU のスレッドが 8 なら 8 個起動)。
結果を見ると、やはりマルチスレッドレンダリングは速い。例えば、Core i7-2670QM は最大 5 倍近い速度で合成できている。
テンポラリフォルダのアクセスによるボトルネックを心配していたが、結果を見る限り、そこはあまりボトルネックにはなっていないようだ。UTAU ツールは結果をディスクに出力するので、現在の唄詠はそれをテンポラリフォルダに出力させるようにしている。テンポラリフォルダのアクセス速度が遅いとマルチスレッドレンダリングしても効果が無いかと思ったが、遅い HDD でも効果が出ている。
ハイパースレッディングによってスレッド数を倍にしている場合、物理コアと違ってスレッドを処理する能力はあまり上がらない。なので、半コアと全コアを比較すると処理速度はさほど向上していない(逆に下がる場合もある)。デフォルト設定を半コアにするか全コアにするかは悩ましいところだ。
なお、この測定に限らないが、マルチスレッドの効果測定は、他のプロセスも多く動いている中では、不確定要素が多い。あくまでも目安となる。
それでもなるべく妥当な結果になるように、テスターの方には同じ測定を 5 回ずつ行って頂き、20% トリム平均(要は極端な上下を除き、中間 3 回の結果の平均)で結果を算出している。
ご協力頂いた皆様、ありがとうございました。
また、これからテストにご協力いただけるという方がいらっしゃいましたら、SHINTAまでご連絡下さい。
手法としてはよくある方法で、UTAU のツールを複数同時起動するというもの(いわゆるマルチスレッドレンダリング)。
で、実際のところ、どのくらい速くなるのか。数人のテスターの方に協力して頂いた結果が以下。

表の見方だが、CPU の「コア」は物理コア数、「スレ」はスレッド数。Intel 系はハイパースレッディング(SMT)を実装していることがあり、物理コア数の 2 倍のスレッドを同時に走らせることができる。
「Temp」はテンポラリフォルダがあるデバイスの種類。ここが「HDD」なら、ハードディスク上にテンポラリフォルダがある。
測定結果の「半スレ」「全スレ」はそれぞれ、UTAU ツールを 1 つだけ起動して音声合成した場合と比べて何倍のスピードになったかを記している。「半スレ」であれば、CPU が同時に走らせられるスレッド数の半分の数だけ UTAU ツールを起動している(CPU のスレッドが 8 なら 4 個起動、小数点以下切り捨て)。「全スレ」はスレッド数と同じだけ起動(CPU のスレッドが 8 なら 8 個起動)。
結果を見ると、やはりマルチスレッドレンダリングは速い。例えば、Core i7-2670QM は最大 5 倍近い速度で合成できている。
テンポラリフォルダのアクセスによるボトルネックを心配していたが、結果を見る限り、そこはあまりボトルネックにはなっていないようだ。UTAU ツールは結果をディスクに出力するので、現在の唄詠はそれをテンポラリフォルダに出力させるようにしている。テンポラリフォルダのアクセス速度が遅いとマルチスレッドレンダリングしても効果が無いかと思ったが、遅い HDD でも効果が出ている。
ハイパースレッディングによってスレッド数を倍にしている場合、物理コアと違ってスレッドを処理する能力はあまり上がらない。なので、半コアと全コアを比較すると処理速度はさほど向上していない(逆に下がる場合もある)。デフォルト設定を半コアにするか全コアにするかは悩ましいところだ。
なお、この測定に限らないが、マルチスレッドの効果測定は、他のプロセスも多く動いている中では、不確定要素が多い。あくまでも目安となる。
それでもなるべく妥当な結果になるように、テスターの方には同じ測定を 5 回ずつ行って頂き、20% トリム平均(要は極端な上下を除き、中間 3 回の結果の平均)で結果を算出している。
ご協力頂いた皆様、ありがとうございました。
また、これからテストにご協力いただけるという方がいらっしゃいましたら、SHINTAまでご連絡下さい。
唄詠のバージョンがだいぶ上がってきたので、改めてやり方を整理しておく。
唄詠は、棒読みちゃんなどのテキストスピーチソフトの「声」として、UTAU 音源を指定できるようにするためのツール。
これまで、UTAU 音源にしゃべらせる(HANASU)には、UTAU 上で時間をかけて調声する必要があったが、唄詠を使うと、テキストスピーチソフトに文章を入力して再生ボタンを押すだけという、簡単な方法でしゃべらせることができるようになる。
やり方は以下。
唄詠公式サイトから唄詠の zip ファイルをダウンロードし、好きなフォルダに解凍する。
UtaYomi.exe を起動し、新規登録ボタンをクリック。
音源の新規登録ウィンドウが表示されるので、しゃべらせたい音源の情報を入力していく。
詳しい入力方法は唄詠のヘルプに譲るが、重要な項目は、「oto.ini の場所」「wavtool の場所」「resampler の場所」の 3 つだ。
oto.ini の場所には、しゃべらせたい UTAU 音源の oto.ini を指定する。サブフォルダにも oto.ini がある音源の場合は、音源の最上位フォルダの oto.ini を指定すると良い。サブフォルダの oto.ini も含めてすべて利用可能になる。
wavtool の場所と resampler の場所にはそれぞれ、UTAU に付属している wavtool.exe と resampler.exe を指定する。互換ツールでも OK だ。
各ファイルの指定は、参照ボタンからのダイアログで行ってもよいし、ドラッグ&ドロップで行ってもよい。
OK ボタンを押すと、UTAU 音源の情報が登録される。登録時、パソコンの管理者権限が必要なので、画面の指示に従って管理者のアカウント情報を入力する。
音源情報を登録したら、棒読みちゃんを起動する。唄詠との間で漢字を処理できる Ver 0.1.11.0 Beta 15 以降の棒読みちゃんがオススメだ。
声質を選ぶプルダウンメニューで、先ほど登録した UTAU 音源が選択できるようになっているはずなので、それを選ぶ。
後は、いつも棒読みちゃんを使っているのと同じように、読み上げさせたい文章を入力して再生ボタンを押すだけだ。
例として棒読みちゃんを挙げたが、SAPI 5 に対応したテキストスピーチソフトであれば、どんなソフトでも UTAU 音源をしゃべらせられるようになる。SofTalk やゆっくり MovieMaker なども利用可能だ。
【関連サイト】
唄詠は、棒読みちゃんなどのテキストスピーチソフトの「声」として、UTAU 音源を指定できるようにするためのツール。
これまで、UTAU 音源にしゃべらせる(HANASU)には、UTAU 上で時間をかけて調声する必要があったが、唄詠を使うと、テキストスピーチソフトに文章を入力して再生ボタンを押すだけという、簡単な方法でしゃべらせることができるようになる。
やり方は以下。

UtaYomi.exe を起動し、新規登録ボタンをクリック。
音源の新規登録ウィンドウが表示されるので、しゃべらせたい音源の情報を入力していく。

oto.ini の場所には、しゃべらせたい UTAU 音源の oto.ini を指定する。サブフォルダにも oto.ini がある音源の場合は、音源の最上位フォルダの oto.ini を指定すると良い。サブフォルダの oto.ini も含めてすべて利用可能になる。
wavtool の場所と resampler の場所にはそれぞれ、UTAU に付属している wavtool.exe と resampler.exe を指定する。互換ツールでも OK だ。
各ファイルの指定は、参照ボタンからのダイアログで行ってもよいし、ドラッグ&ドロップで行ってもよい。
OK ボタンを押すと、UTAU 音源の情報が登録される。登録時、パソコンの管理者権限が必要なので、画面の指示に従って管理者のアカウント情報を入力する。

声質を選ぶプルダウンメニューで、先ほど登録した UTAU 音源が選択できるようになっているはずなので、それを選ぶ。
後は、いつも棒読みちゃんを使っているのと同じように、読み上げさせたい文章を入力して再生ボタンを押すだけだ。
例として棒読みちゃんを挙げたが、SAPI 5 に対応したテキストスピーチソフトであれば、どんなソフトでも UTAU 音源をしゃべらせられるようになる。SofTalk やゆっくり MovieMaker なども利用可能だ。
【関連サイト】

YMM では、ボイス(ゆっくり霊夢など)を選んでセリフを入力していくことで、タイムラインに簡単にセリフを貼り付けられる。
左下の「+」ボタンで新しいキャラクターを作成でき、声質として唄詠で登録した音源を選択できる。
今回の YMM のバージョンアップにより、漢字かな交じりのセリフも発音できるようになった。
YMM にご対応いただいたことにより、唄詠で漢字を利用できるアプリが 3 つに増えた。
- 棒読みちゃん(Ver0.1.11.0 Beta15 以降)
- SofTalk(Ver 1.93.5 以降)
- ゆっくり MovieMaker(v3.4.3.0 以降)
UTAU に付属する wavtool / resampler は、パラメーター数が多いので、ぱっと見でパラメーターの内容が分かりづらい。そこで、パラメーターの内容を分かりやすく記録するツールを作成。
プラグインなどの作成者には役立つかも。
ソースコード込み。
プラグインなどの作成者には役立つかも。
ソースコード込み。
テキストスピーチソフト(SofTalk や棒読みちゃんなど)の声として UTAU 音源を使えるようにするためのソフト、「唄詠」(うたよみ)をバージョンアップ。
"/" "ぁ" など一部の文字で始まる文章を読み上げたときに動作がおかしくなる現象を修正しました。
また、今回は SofTalk 作者の cncc さんにご協力を頂き、SofTalk での読み上げを唄詠で行う際、漢字かな交じり文を抑揚付きで読めるようになりました。
まもなく公開される予定の SofTalk 最新版(Ver 1.93.5 以降)では、環境設定ダイアログの「声質」タブに、唄詠オプションが表示されます。
唄詠で音源を登録した後、SofTalk の声質設定で唄詠オプションにチェックを入れて下さい。自動的に平仮名と抑揚オプションもチェックが入ります。
注)旧バージョンの唄詠で登録した音源だと、唄詠オプションが有効にならない場合があります。今回のバージョンの唄詠で音源を登録してから SofTalk をご利用下さい。
その後 SofTalk のメインウィンドウで、声メニューから唄詠音源を選択し、文章を読み上げると、漢字かな交じり文も読み上げることができます。
多大なご協力を頂きました cncc さんにはこの場をお借りしてお礼申し上げます。
なお、上記以外の一部のバグ修正は、次回リリースに持ち越しとなっておりますのでご了承下さい。
唄詠リンク
"/" "ぁ" など一部の文字で始まる文章を読み上げたときに動作がおかしくなる現象を修正しました。

まもなく公開される予定の SofTalk 最新版(Ver 1.93.5 以降)では、環境設定ダイアログの「声質」タブに、唄詠オプションが表示されます。
唄詠で音源を登録した後、SofTalk の声質設定で唄詠オプションにチェックを入れて下さい。自動的に平仮名と抑揚オプションもチェックが入ります。
注)旧バージョンの唄詠で登録した音源だと、唄詠オプションが有効にならない場合があります。今回のバージョンの唄詠で音源を登録してから SofTalk をご利用下さい。
その後 SofTalk のメインウィンドウで、声メニューから唄詠音源を選択し、文章を読み上げると、漢字かな交じり文も読み上げることができます。
多大なご協力を頂きました cncc さんにはこの場をお借りしてお礼申し上げます。
なお、上記以外の一部のバグ修正は、次回リリースに持ち越しとなっておりますのでご了承下さい。
唄詠リンク

AquesTalk タグに対応し、AquesTalk 方式の発音記号を読み上げることができるようになりました。

自動漢字読み上げ機能は、今回のバージョンの唄詠での UTAU 音源が必要なのでご注意下さい。旧バージョンの唄詠で登録した音源では漢字は読み上げられません。
漢字かな交じり文の読み上げは、棒読みちゃん作者のみちあきさんの多大なご協力により実現しました。この場を借りてお礼申し上げます。
唄詠のダウンロードは以下からどうぞ。
UTAU 関連のソフトウェア(プラグインなど)を開発する際に使える C++ クラスライブラリ、「Lib UTAU」をバージョンアップ。
原音設定を扱う部分を TOtoIni として独立させたので、原音設定関係の処理だけしたい場合などにも利用できるようになった。
実際、唄詠は原音設定の処理のために Lib UTAU を使用している。
Lib UTAU のダウンロードは以下からどうぞ。
原音設定を扱う部分を TOtoIni として独立させたので、原音設定関係の処理だけしたい場合などにも利用できるようになった。
実際、唄詠は原音設定の処理のために Lib UTAU を使用している。
Lib UTAU のダウンロードは以下からどうぞ。

前回と比べると、以下が改善されています。
- 原音設定を解析して音声合成するようになったため、発音が滑らかになりました。前回は音が(全くまたはほとんど)出なかった音源でも、今回は出るのではと思います。
- スペースを含むフォルダを扱えるようになりました。
- その他、細々とした改良を行っています。
以下の点は、前回から変わっていません。
- 単独音のみの対応です。
- 読み上げできる文章は、ひらがなおよびカタカナのみです。
- XML 形式での発音記号読み上げに対応しています。
下記動画およびヘルプファイルをよく読んでからご利用下さい。
対応 OS や動作確認済み UTAU 音源などもヘルプに記載してあります。
唄詠のダウンロードは以下からどうぞ。
動作した環境、動作しなかった環境を教えていただけると助かります。

UTAU 音源で文章を読み上げるためのソフト、唄詠(うたよみ)をリリース。
Ver 1.80 Developer Release。開発途上のバージョンです。読み上げがたどたどしい他、いろいろと制限があります。
必ず、下記動画およびヘルプファイルをよく読んでからご利用下さい。
対応 OS や動作確認済み UTAU 音源などもヘルプに記載してあります。
唄詠のダウンロードは以下からどうぞ。

テキストスピーチソフト(棒読みちゃんなどの、文章読み上げソフト)の声として、UTAU 音源を使えるようにするためのソフト、「唄詠」(うたよみ)を開発中。
とりあえず、UTAU 音源でごく原始的な読み上げができるところまで到達した。
唄詠は、大きく 2 つの部分から成る。
1 つ目の部分は、UTAU 音源の管理を行う設定画面。
所持している UTAU 音源をこの設定画面で登録することにより、テキストスピーチソフトで利用することが可能になる。

音源に付属している oto.ini ファイルの場所など、必要事項を入力すれば、登録完了だ。

設定画面はまだ、音源の新規登録と登録抹消の機能しか実装していないが、実装したところについては、内部もわりと真面目に作り込んである。
唄詠の 2 つ目の部分は、実際の読み上げ用の音声を合成する(HANASU)部分だ。こちらはユーザーの目には見えない、縁の下の力持ち的な部分になる。
最初に書いたとおり、ごく原始的な読み上げができるようになった段階。
ぱみゅと天月りよんで HANA せることを確認するところまで到達した。
しかしこちらはかなりの突貫工事状態なので、これから作り込んでいく必要がある。
以上が、現時点での唄詠の進捗状況。
文章だと伝わりづらい性質のソフトなので、いずれ動画を作成する予定。
デルタさん主催の UTAU 調声系技術交流会という Skype 上のイベントに参加。
その名の通り、UTAU の調声をどうやっているかのノウハウをみんなで交換する内容だが、それだけにはとどまらない。最近話題の CV-VC のイロハから、普段使っているプラグイン、お薦め音源まで幅広い内容で話ができ、とても楽しかった。
その中で推薦された天月りよんという音源は、可愛いながらも落ち着きのある声質で、気に入った。今度使ってみたい。
交流会は ROM 専でも参加可能な気軽な会なので、興味のある人は、次回開催される際に覗いてみてはどうだろう。
さて、俺はその中で、「手軽な HANASU 調声」ということで、普段の自分の調声方法を紹介させてもらった。そのときの内容を簡単にまとめておくので、よければどうぞ。
動画中で UTAU 音源に HANA してもらうのだが、いろいろ紹介しようと思うと、セリフの数はかなり多くなる。
何十個ものセリフを 1 から調声していたのでは、とても時間がかかってしまう。しかも、やりたいことは調声ではなく紹介なので、HANASU をいじくるのにあまり時間はかけたくない。
スキルのある人ならば、ピッチ曲線を 1 から書いても早いのかもしれないが、そういうスキルがなくても、なるべくちゃちゃっと HANA させる方法ということで実戦しているのが、以下の方法だ。
まずは、UTAU にセリフ(歌詞)を入力するところからスタート。例として、上記の鼻歌採譜プラグイン動画の 0:40 あたりで使っている、ぱみゅの「実際にはこんな感じです」を用いる。
HANASU の場合、テンポは結構早い。上記動画の中では、ぱみゅはのんびりしゃべっているほうだが、それでも、テンポ 220 の 8 分音符を使っている。交流会の中では、テンポを 600 くらいにして、その代わりに音長を長めにしているという情報もあった。
右の写真(クリックで拡大する)にあるように、「実際にはこんな感じです」のセリフ歌詞は「RRじRさいにわこんなかんじですRR」となる。小さい「っ」は休符 1 つ、助詞の「は」は発音通り「わ」。前後の休符は、入れておく方が何かと都合が良いので入れている。余談だが、うちの環境だと、なぜか日本語歌詞が文字化けしてしまう……。
使用する音源が連続音の場合は、歌詞も連続音にする。
次に、同じセリフを自分で話して録音する。リニア PCM(WAVE ファイル)で録音できるオリンパス DS-800 のようなボイスレコーダーを使って録音したあと、パソコンに転送するか、または、パソコンのマイク入力を SoundEngine などで録音すると良いだろう。
録音時のポイントはズバリ、UTAU でのテンポと合わせてセリフをしゃべること。
先頭の休符も含めて、すべてのセリフを数回再生して、イヤホンで聴くと、テンポが体感できる。その後で、UTAU の再生に合わせて自分がセリフをしゃべり、それを録音すると、タイミングが合いやすい。先頭の休符を含めて再生することで、入りのタイミングがさらに合いやすくなるだろう。
うまく録音できたら、パソコンにデータを転送し、SoundEngine などの波形編集ソフトで、先頭の無音部分を切り捨てておく。
再び UTAU に戻り、先頭の休符を除く音符を選択し、プラグインのうたりすを起動する。
さきほど準備した WAVE ファイルをドラッグ&ドロップで指定する。
移調は、自分と音源の性別が同じ場合は 0、自分が男性で音源が女性の場合は 12、自分が女性で音源が男性の場合は -12 が 1 つの目安となる。あとで結果を聴きながらベストな移調量を探ると良いだろう。
スタートボタンをクリックすると、WAVE ファイルの内容が解析され、UTAU の音符にピッチ情報が反映される。
うちの環境だと、一度音符の選択を解除してから、再度音符を選択して、再生すれば、ぱみゅが HANA してくれる。
この状態でもそこそこの HANASU になるが、ピッチが破綻している箇所などを、次で修正する。
目で見て解るように、上の写真だと、ピッチ曲線がはるか上に飛び出ているところがあるので、そういう箇所をひらべったくなるように修正する。また、音量が不自然に小さいところも修正する。
たまに、イメージしているしゃべりと全く異なるしゃべりになることがあるが、その場合は、うたりすの「オフセット」を 50 ミリ秒単位くらいで調整するといいだろう(プラスだけではなくマイナスも指定できる)。
微修正を経た完成図が右だ。
1 から手動で HANASU の調声をしようと思ってもどうピッチを調声したら良いのか分からないが、この方法であれば、手作業は少しなので、だいぶ簡単になる。
セリフが多い場合は、最初に全部録音を済ませておき、パソコン上の作業はその後にすると、作業がまとまってやりやすい。
なお、うたりすの詳しい使い方については、うたりすのヘルプを参照されたい。うたりすからも表示できる。
その名の通り、UTAU の調声をどうやっているかのノウハウをみんなで交換する内容だが、それだけにはとどまらない。最近話題の CV-VC のイロハから、普段使っているプラグイン、お薦め音源まで幅広い内容で話ができ、とても楽しかった。
その中で推薦された天月りよんという音源は、可愛いながらも落ち着きのある声質で、気に入った。今度使ってみたい。
交流会は ROM 専でも参加可能な気軽な会なので、興味のある人は、次回開催される際に覗いてみてはどうだろう。
さて、俺はその中で、「手軽な HANASU 調声」ということで、普段の自分の調声方法を紹介させてもらった。そのときの内容を簡単にまとめておくので、よければどうぞ。
手軽な HANASU 調声が欲しい理由
各種プラグインや bot などを公開する際、その紹介をニコニコ動画に投稿している。例えば、右の鼻歌採譜プラグイン紹介動画などだ。動画中で UTAU 音源に HANA してもらうのだが、いろいろ紹介しようと思うと、セリフの数はかなり多くなる。
何十個ものセリフを 1 から調声していたのでは、とても時間がかかってしまう。しかも、やりたいことは調声ではなく紹介なので、HANASU をいじくるのにあまり時間はかけたくない。
スキルのある人ならば、ピッチ曲線を 1 から書いても早いのかもしれないが、そういうスキルがなくても、なるべくちゃちゃっと HANA させる方法ということで実戦しているのが、以下の方法だ。
STEP 1:セリフの入力

HANASU の場合、テンポは結構早い。上記動画の中では、ぱみゅはのんびりしゃべっているほうだが、それでも、テンポ 220 の 8 分音符を使っている。交流会の中では、テンポを 600 くらいにして、その代わりに音長を長めにしているという情報もあった。
右の写真(クリックで拡大する)にあるように、「実際にはこんな感じです」のセリフ歌詞は「RRじRさいにわこんなかんじですRR」となる。小さい「っ」は休符 1 つ、助詞の「は」は発音通り「わ」。前後の休符は、入れておく方が何かと都合が良いので入れている。余談だが、うちの環境だと、なぜか日本語歌詞が文字化けしてしまう……。
使用する音源が連続音の場合は、歌詞も連続音にする。
STEP 2:セリフの録音

録音時のポイントはズバリ、UTAU でのテンポと合わせてセリフをしゃべること。
先頭の休符も含めて、すべてのセリフを数回再生して、イヤホンで聴くと、テンポが体感できる。その後で、UTAU の再生に合わせて自分がセリフをしゃべり、それを録音すると、タイミングが合いやすい。先頭の休符を含めて再生することで、入りのタイミングがさらに合いやすくなるだろう。
うまく録音できたら、パソコンにデータを転送し、SoundEngine などの波形編集ソフトで、先頭の無音部分を切り捨てておく。
STEP 3:うたりすの利用

さきほど準備した WAVE ファイルをドラッグ&ドロップで指定する。
移調は、自分と音源の性別が同じ場合は 0、自分が男性で音源が女性の場合は 12、自分が女性で音源が男性の場合は -12 が 1 つの目安となる。あとで結果を聴きながらベストな移調量を探ると良いだろう。

うちの環境だと、一度音符の選択を解除してから、再度音符を選択して、再生すれば、ぱみゅが HANA してくれる。
この状態でもそこそこの HANASU になるが、ピッチが破綻している箇所などを、次で修正する。
STEP 4:微修正

たまに、イメージしているしゃべりと全く異なるしゃべりになることがあるが、その場合は、うたりすの「オフセット」を 50 ミリ秒単位くらいで調整するといいだろう(プラスだけではなくマイナスも指定できる)。
微修正を経た完成図が右だ。
1 から手動で HANASU の調声をしようと思ってもどうピッチを調声したら良いのか分からないが、この方法であれば、手作業は少しなので、だいぶ簡単になる。
セリフが多い場合は、最初に全部録音を済ませておき、パソコン上の作業はその後にすると、作業がまとまってやりやすい。
なお、うたりすの詳しい使い方については、うたりすのヘルプを参照されたい。うたりすからも表示できる。
歌声から音符を取得する
UTAU 用のプラグイン「鼻歌採譜プラグイン(Humming to Score Plugin)」をバージョンアップ。Ver 2.13 β をテスト公開。
ドラッグ&ドロップインストールに対応しているので、ダウンロードしたアーカイブを UTAU のウィンドウにドラッグ&ドロップすればインストール可能。
今回はマイナーバージョンアップで、配布サイトの URL の修正を実施。また、ミチコラさんに送って頂いた簡体字中国語の言語ファイルを収録した。謝謝!
引き続き、他の言語の辞書ファイルもお待ちしております。
鼻歌採譜プラグインの使い方などについては、新しく公開した動画をご覧ください。
鼻歌を録音する際は、ノイズの少ない高音質の機材で行う方が良い結果が得られる。自分は、オリンパスのリニア PCM ボイスレコーダー、DS-800 で行っている。

ドラッグ&ドロップインストールに対応しているので、ダウンロードしたアーカイブを UTAU のウィンドウにドラッグ&ドロップすればインストール可能。
今回はマイナーバージョンアップで、配布サイトの URL の修正を実施。また、ミチコラさんに送って頂いた簡体字中国語の言語ファイルを収録した。謝謝!
引き続き、他の言語の辞書ファイルもお待ちしております。
鼻歌採譜プラグインの使い方などについては、新しく公開した動画をご覧ください。
鼻歌を録音する際は、ノイズの少ない高音質の機材で行う方が良い結果が得られる。自分は、オリンパスのリニア PCM ボイスレコーダー、DS-800 で行っている。
歌声から音符を取得する
UTAU 用のプラグイン「鼻歌採譜プラグイン」をバージョンアップ。Ver 2.12 β をテスト公開。
ドラッグ&ドロップインストールに対応しているので、ダウンロードしたアーカイブを UTAU のウィンドウにドラッグ&ドロップすればインストール可能。
今回のバージョンアップ内容は、
引き続き、他の言語の辞書ファイルもお待ちしております。
以下の組み合わせで動作を確認。
なお、Windows 2000 では動作しない。
鼻歌採譜プラグインの使い方などについては、新しく公開した動画をご覧ください。
鼻歌を録音する際は、ノイズの少ない高音質の機材で行う方が良い結果が得られる。自分は、オリンパスのリニア PCM ボイスレコーダー、DS-800 で行っている。

ドラッグ&ドロップインストールに対応しているので、ダウンロードしたアーカイブを UTAU のウィンドウにドラッグ&ドロップすればインストール可能。
今回のバージョンアップ内容は、
- 音長解析のさらなる改善。
- 多言語対応のさらなる改善。
- 細かなバグ修正。
引き続き、他の言語の辞書ファイルもお待ちしております。
以下の組み合わせで動作を確認。
鼻歌採譜プラグイン | OS | UTAU | 音源 | |
---|---|---|---|---|
鼻歌採譜プラグイン Ver 2.12 β | Windows 8 Pro 64 ビット版 | UTAU Ver 0.4.14 | 淡水ウパ | ![]() |
鼻歌採譜プラグイン Ver 2.12 β | Windows 7 Professional 64 ビット版 | UTAU Ver 0.4.16 | 槌音ずも | ![]() |
鼻歌採譜プラグイン Ver 2.12 β | Windows XP Professional SP1 32 ビット版 | UTAU Ver 0.2.75 | 実音とわの(100404) | ![]() |
なお、Windows 2000 では動作しない。
鼻歌採譜プラグインの使い方などについては、新しく公開した動画をご覧ください。
鼻歌を録音する際は、ノイズの少ない高音質の機材で行う方が良い結果が得られる。自分は、オリンパスのリニア PCM ボイスレコーダー、DS-800 で行っている。

ドラッグ&ドロップインストールに対応しているので、ダウンロードしたアーカイブを UTAU のウィンドウにドラッグ&ドロップすればインストール可能。
今回は、細かなバグ修正の他に、多言語対応を行っている。
英語環境で鼻歌採譜プラグインを起動すると自動的に英語表示になるほか、ユーザーが表示言語を指定することも可能。
翻訳データベース(辞書ファイル)は単なるテキストファイルなので、誰でも作成可能だ。
現在は日本語と英語の 2 カ国語しか対応していないが、他の言語の辞書ファイルを作成したら送ってください。次期バージョンに収録させて頂きます。
以下の組み合わせで動作を確認。
鼻歌採譜プラグイン | OS | UTAU | 音源 | |
---|---|---|---|---|
鼻歌採譜プラグイン Ver 2.05 β | Windows 8 Pro 64 ビット版 | UTAU Ver 0.4.14 | 淡水ウパ | ![]() |
鼻歌採譜プラグイン Ver 2.05 β | Windows 7 Professional 64 ビット版 | UTAU Ver 0.4.14 | 春歌ナナ | ![]() |
鼻歌採譜プラグイン Ver 2.05 β | Windows XP Professional SP1 32 ビット版 | UTAU Ver 0.2.75 | 実音とわの(100404) | ![]() |
なお、Windows 2000 では動作しない。
鼻歌採譜プラグインの使い方などについては、旧バージョンなので現在とは少し異なるところもあるが、動画で紹介している。
鼻歌を録音する際は、ノイズの少ない高音質の機材で行う方が良い結果が得られる。自分は、オリンパスのリニア PCM ボイスレコーダー、DS-800 で行っている。
◆更新情報◆
Ver 2.05 β を公開。
UTAU 用の歌声→音符取得プラグイン「鼻歌採譜プラグイン」をバージョンアップ。Ver 1.77 β をテスト公開。
ドラッグ&ドロップインストールに対応しているので、ダウンロードしたアーカイブを UTAU のウィンドウにドラッグ&ドロップすればインストール可能。
今回の大きな変更点は、音長解析(リズム)の精度を向上させたこと。
これまでは、欲しい音長の半分の音長を指定する必要があった(例えば、全部 4 分音符の曲を採譜するなら指定は 8 分音符)が、今回のバージョンアップにより、欲しい音長そのものを指定すれば良いようになった。
ブレス(息継ぎ)への対応が行われ、別の音符として採譜してしまう確率も低くなった。
その他、全体的に音長解析の仕組みを見直しており、音長だけで見れば、そこそこの結果を得られることが多くなった。
これに伴い、Developer Release からベータ版に格上げ。
その他の主な変更点は、
以下の組み合わせで動作を確認。
なお、Windows 2000 では動作しない。
鼻歌採譜プラグインの使い方などについては、旧バージョンなので現在とは少し異なるところもあるが、動画で紹介している。
鼻歌を録音する際は、ノイズの少ない高音質の機材で行う方が良い結果が得られる。自分は、オリンパスのリニア PCM ボイスレコーダー、DS-800 で行っている。
Ver 2.05 β を公開。

ドラッグ&ドロップインストールに対応しているので、ダウンロードしたアーカイブを UTAU のウィンドウにドラッグ&ドロップすればインストール可能。
今回の大きな変更点は、音長解析(リズム)の精度を向上させたこと。
これまでは、欲しい音長の半分の音長を指定する必要があった(例えば、全部 4 分音符の曲を採譜するなら指定は 8 分音符)が、今回のバージョンアップにより、欲しい音長そのものを指定すれば良いようになった。
ブレス(息継ぎ)への対応が行われ、別の音符として採譜してしまう確率も低くなった。
その他、全体的に音長解析の仕組みを見直しており、音長だけで見れば、そこそこの結果を得られることが多くなった。
これに伴い、Developer Release からベータ版に格上げ。
その他の主な変更点は、
- 挿入する歌詞の種類(単独音/連続音)を選べるようにした。
- 参考情報としてピッチ情報を付加できるようにした。
- 歌唱 WAVE を履歴から選べるようにした。
以下の組み合わせで動作を確認。
鼻歌採譜プラグイン | OS | UTAU | 音源 | |
---|---|---|---|---|
鼻歌採譜プラグイン Ver 1.77 β | Windows 8 Pro 64 ビット版 | UTAU Ver 0.4.14 | 淡水ウパ | ![]() |
鼻歌採譜プラグイン Ver 1.77 β | Windows 7 Professional 64 ビット版 | UTAU Ver 0.4.12 | 櫻歌ミコ キレ音源 | ![]() |
鼻歌採譜プラグイン Ver 1.77 β | Windows XP Professional SP1 32 ビット版 | UTAU Ver 0.2.75 | 実音とわの(100404) | ![]() |
なお、Windows 2000 では動作しない。
鼻歌採譜プラグインの使い方などについては、旧バージョンなので現在とは少し異なるところもあるが、動画で紹介している。
鼻歌を録音する際は、ノイズの少ない高音質の機材で行う方が良い結果が得られる。自分は、オリンパスのリニア PCM ボイスレコーダー、DS-800 で行っている。

Ver 1.77 β を公開。
UTAU 用の歌声→音符取得プラグイン「鼻歌採譜プラグイン」をバージョンアップ。Ver 1.31 Developer Release をテスト公開。併せて、スクリーンショット集も公開。
ドラッグ&ドロップインストールに対応しているので、ダウンロードしたアーカイブを UTAU のウィンドウにドラッグ&ドロップすればインストール可能。
主な変更点は、
- マルチスレッド解析による高速化。
- プログレスバー表示の改善。
以下の組み合わせで動作を確認。Windows 2000 では動作しない。
鼻歌採譜プラグイン | OS | UTAU | 音源 | |
---|---|---|---|---|
鼻歌採譜プラグイン Ver 1.31 DR | Windows 7 Professional 64 ビット版 | UTAU Ver 0.4.12 | 鳴都 Sweet (採譜後歌詞を連続音に変更) | ![]() |
鼻歌採譜プラグイン Ver 1.31 DR | Windows XP Professional SP1 32 ビット版 | UTAU Ver 0.2.75 | 実音とわの(100404) | ![]() |
解析速度について、これまでの公開バージョンである Ver 1.17 DR と比較してみた。比較条件は、
- 解析対象 WAVE:312.1 秒(44.1kHz、2ch)
- CPU:Intel Core i5-750s(2.4 GHz、4 コア 4 スレッド)
- 詳細環境:こちら
結果は下記のようになり、実時間の 24 倍速で解析できるようになり、Ver 1.17 DR と比較して 2.4 倍高速に解析できるようになった。
鼻歌採譜プラグイン | 所要時間 | 倍速 |
---|---|---|
鼻歌採譜プラグイン Ver 1.31 DR | 13.0 秒 | 23.9 倍速 |
鼻歌採譜プラグイン Ver 1.17 DR | 31.2 秒 | 10.0 倍速 |
なお、内部的にうたりすとのコンポーネント共有化をさらに推進しており、その影響で、過去のバージョンと解析結果が多少異なることがあるかもしれない。
翔星グループ
月別アーカイブ
記事検索
最新記事
最新コメント
タグクラウド
- ACF
- Android
- AQUOSPAD
- ArtisanTD
- ASPNET
- Blazor
- CBuilder
- CSharp
- csv2resw
- FactoryTown
- Fantia
- GPS
- H264
- H265
- HaikuOS
- HANASU
- HDD
- IIJ
- LTE
- MicrosoftStore
- moto
- MVNO
- MVVM
- NAS
- Nexus7
- PetitKara
- PHP
- RaspberryPi
- SNS
- SQLite
- SSD
- SymphonyOfWar
- TYPINGMANIA
- USB3
- UTAU
- Vegas
- VisualStudio
- Vue
- Wi-Fi
- WiMAX
- Windows
- Windows10
- Windows10Mobile
- Windows11
- WinUI3
- WPF
- うたりす
- お知らせ
- その他無線
- ちょちょいとファイル合併2
- ちょちょいと自動更新
- ちょちょいと自動更新2
- はじまるA列車
- ゆかり
- ゆかりすたー
- ゆかりすたー4
- ゆっこビュー
- ゆっこビュー2
- アニメ
- アンケート
- イベント
- オーディオ
- カラオケ
- カラオケ動画
- ゲーム
- サンプルコード
- サービス
- スピード測定
- セキュリティ
- ソフトウェア
- タブレット
- ニコカラ
- ニコカラりすたー
- ニコカラメーカー
- ニコカラメーカー2
- ニコカラメーカー3
- ネットワーク
- ハードウェア
- プラグイン
- プログラミング
- プログレスバー素材メーカー
- ヘッドセット
- ボーカルカット
- マウス
- マシンスペックまとめ
- マシンベンチマークまとめ
- ラングリッサー
- ルフランの地下迷宮と魔女ノ旅団
- 動画
- 唄詠
- 唄詠2
- 唄詠利用
- 挨拶
- 簡易キーチェンジャー
- 考察
- 連れてってダンジョンへ
- 開発
- 魔想のウィアートル
- 鼻歌採譜プラグイン