最近よく使っている自作ツール（3） select.pl

TL;DR

www.youtube.com

ちょうどひと月ぐらい空いてしまいましたが、以下のシリーズの続きです。

note103.hateblo.jp

note103.hateblo.jp

今回は、複数のファイルを直感的に選択して、それらに同じコマンドを渡すためのツールです。

リポジトリは以下。

GitHub - note103/select

で、いつものようにLICEcapを使ったGIF動画と、文章による説明とを組み合わせつつ記事を作ろうかと思っていましたが、けっこうそれも大変なんだよなあと思い直し、それでこのところ「音声入力による文字起こし」の実験をする過程で泥縄的に身に付けたスクリーンキャスト的手法で紹介してみようか、と思って作ったのが冒頭の動画（YouTube）です。

説明としてわかりやすいかどうかは不明ですが、文章で全部書くよりはずっとラクでした。

で、とはいえ、それだけではいろいろ情報が不足するだろうと思って、その補足ぐらいは文章で補おう・・と思っていましたが、やっぱりそれもまた面倒というか、いや面倒ならやらなければいいのですが、いや説明はしたい、そもそも自作ツールを紹介したいからわざわざこんな記事を書いているのだ、ということで、それならいっそその動画で喋った音声もそのままGoogleドキュメントの音声入力機能でテキスト化しちゃえばいいのでは、と思ってそうしてみました。

で、さらにその際、なんだかメタっぽいですが、せっかくなのでその音声入力による文字起こしの模様も動画に撮ってみたので、記事の最後に貼り付けておきます。興味のある人はご高覧のほど。

ということで、上の動画で喋った内容をGoogleドキュメントの音声入力でテキスト化した上で、簡単に手直ししたもの（それでも40分ぐらいかかったけど）を以下に掲示して本記事を終わりたいと思います。

このシリーズ自体はまだ続きがあるので、また時間ができたら更新したいと思っています。

Transcript

[00:00]

• ええ、はい。今日はですね。これ、プログラミングの、いつも練習をですね、記録しているブログに、動画でですね、ちょっとのせてみようかと思っておりまして。
• `test`っていうディレクトリで、ちょっとやってみようかなという感じですけど。
• 今日紹介したいコードはですね、`select.pl`ってやつで。詳しくはですね、GitHubとかにも上げてるはずなので、ブログの方で紹介したいと思いますけども。
  • https://github.com/note103/select
• 私は今この`e`っていう名前のエイリアスを入れてるんですけども。
• こんな感じですね。複数のファイルをこんなふうに選択して、選択するとこういう`+`マークがつくんですね。
• で、デフォルトでただ`e`って入れるだけだと、echoするよって、選択したファイルを全部echoするよ、みたいな感じになるんですね。
• で、そのままやっていいかなってなった場合は……（実行）はい、ちょっとわかりづらいですけど、フルパスで全部出るんですね。3つファイルがあってですね、全部echoされたと。

[02:00]

• で、それの何が嬉しいのって感じなんですけど、eあるいはそのselect.pl をこれPerlで書いてるんですけど、実行するときの引数にですね、コマンドを何か入れると。たとえば、こんな感じでcatするよと。`e cat`って入れて、 `yes` ってやるとですね。
• この`project1.txt`ってやつの中身がcatされて、`project3.txt`の中身もcatされて、みたいな感じでですね。ようするに、複数のファイルを選択して、それに同じコマンドを渡すみたいなことをやりたいと。
• んで、そんなのべつに普通にやればいいんじゃないの、みたいな感じもするんですけど、なんでこんな、ハッシュ値が入っているような長いファイル名にしているのかっていうことが、これを作った理由を示しているんですけど。
• これをですね、たとえばcatしようって言ってですね。project2なんかを選ぼうと思ってもですね、めちゃくちゃ長いファイル名だと、めんどくさいわけですね。
• たとえばproject2と、なんかを選びたいなと。projecct2とproject4を選びたいなってときにですね、2015……とか書いても、これでタブを押しても駄目なんですね。2016の……05の……とかやってるとですね、いつまでも選択が終わらないぞ、みたいな。
• 2017のこれを選びたいので‥‥とかやってもですね、めんどくさくてしょうがないですね。
• まあ、できますけど、それもこれでやれば、これで選ぶと、楽ですよね。
• ちなみにもう1回選択すると、消えたりとかするんですけど。
• まあ、それだけっちゃそれだけですけど（笑）。

[04:40]

• あとついでにっていうか、`de`っていうエイリアスを仕込んでるんですけど、これ消したいなという時ですね。複数のファイルを消したいと。
• そういう時は、これ私は`trash`っていうコマンドが入ってるんですけど、ない場合は、まあ`rm`とかでもいいんでしょうかね。
• 私はこれを仮のゴミ箱がこういう場所にあるんですが、ここにtrashしたいと。（実行）で、どうなったかっていうとですね。1,2,4のファイルしか、もう残ってないと。
• 複数のファイルをどっかに飛ばしちゃいたいという時にこれはよく使いますね。
• あとまあ、ちなみに、不可視ファイルをですね。捨てたいなっていう時も時々あるんですね。
• そういう場合は、`de.`っていうのでやると、ちゃんとそれも飛んでってくれると。
• 逆にっていうか、そのまま`de`だけだと不可視ファイルは出ないようになってるので、こういうコマンドならこれも消せるよと。
• そういう感じにしてたりします。

[06:30]

• あとは複数じゃなくて、1個だけファイルを選んで何かやりたいっていう時は、また別にこれだけで済ませるコマンドを作ってるんですが、またそれは必要があれば紹介するかもしれないですけども。
• まあどんどん消しちゃって。無くなっちゃいますけど。
• という感じで、そういうselectコマンドを紹介してみました。

余録

www.youtube.com

※音声入力による文字起こしについては以下をご参照。
21世紀の文字起こし - the code to rock
21世紀の文字起こし（2） - the code to rock

補足

動画の中で、エイリアスのことをちらちら言っていました。補足的に以下に示しておきます。

alias e="perl /path/to/select.pl"
alias de="perl /path/to/select.pl 'trash -r'"
alias de.="perl /path/to/select.pl -a 'trash -r'"

alias d="sh /path/to/delete.sh"
alias d.="sh /path/to/delete.sh -a"

最後にオマケ的に紹介していた`d`, `d.`などは、すでに前回紹介していたdelete.shのエイリアスでした。
最近よく使っている自作ツール（2） delete.sh - the code to rock

プログラミングを学ぶ理由

ひさしぶりに彼女とお茶を飲んで、まったり雑談していたら、不意に

あなたがそんなに好きなプログラミングっていうの、私に教えてみてよ

と煽ってきたので、彼女のMacBook AirのシステムPerlで、ターミナルから「Hello」が出力されるだけのコードを目の前で書いてみた。

print 'Hello';

これをhello.plで保存する。
shebangさえ付けない。改行も入れない。ほんとに最小限。

実行。

$ perl hello.pl
Hello

この「Hello」って書いてある部分を書き換えると、出力される内容もどんどん変わっていくんだよ、と言ってそこをいろんな数字や言葉に置き換えていく。

print 'Hi';

実行。

Hi

print 1234;

実行。

1234

ほらね、という感じで様子を見ると、「これの何が面白いのか、まったくわからない」と言う。

なんで「Hello」って出さなきゃいけないの？　「1234」ってなに？　何か意味あるの？　と言う。

あなたもPerl入学式で、人に教えたりするの？　それはすごいね。私みたいな人だったら大変じゃない？　だって本当に、何もわからないんだから。と言う。

いや、そうじゃない。とぼくは言う。

問題は、プログラミングをやりたいと思っているかどうかなんだよ。「わからない」なんて当たり前なんだよ。だって、最初は誰だって何も知らないんだから。

でも、「プログラミングをやりたい」って思う人は、わからなくてもわからないままやるんだよ。わからなくても、わかるまでやる人が「プログラミングをやりたい人」なんだ。

だから、そういう人に教えるのは何も難しくない。その人がわかるまで付き合ってあげればいい。「わからない」なんて前提なんだ。わからなくても、それはつまずきでもなければ間違いでもない。息を吸ったり水を飲んだりするのと同じだ。それは必要なことですらある。だから困ったりしない。

難しいのは、「プログラミングをやりたくない」という人に教える場合だと思う。そういう人にとっては、「わからない」ということが致命的な問題になる。「何のためにやるのか」ということが問題になる人に教えることは、だから難しい。

「プログラミングをやりたい」という人は、すでに「何のために」がはっきりしているか、そんな目的すらなくてただ何となく「やりたい」という人だから、ぼくらがわざわざ「プログラミングが何の役に立つのか」とか、「どこが面白いのか」なんて教えてあげる必要はない。その人たちはすでに学ぶこと自体を楽しんでいるし、「わからないから」という理由でやめたりはしない。

でも自分以外の意志によってやらされている人は、何かそれを「やる理由」がほしいと思うだろうね。「楽しみ」や「目的」を外部から提供してもらう必要がある。それが悪いってことじゃない。自然なことだ。ぼくだってプログラミング以外の何かに関してはそうだと思う。

そのうち小学校とかでもプログラミング教育をやるらしいけど、それはまた別の話で、基礎的な教養として教えるものだろうから、算数や漢字や英語に馴染ませるようにプログラミングに馴染ませるのはいいことだと思うけど、そういうことじゃないなら、まあ、やりたい人がやればいいことで、ということは「プログラミングの何が面白いのか」を他人が教えてあげたり、他人から教えてもらったりする必要はどこにもないってことになるだろうね。

MacVimで簡単にウィンドウを切り替える

なぜ今まで気づかなかったのか……？　たまたまキーを打ち間違えたら実現した。

コマンドを押しつつ「 [ 」か「 ] 」を押すとどんどんウィンドウが切り替わる。
これ、今まで一番欲しかったやつや！！

Excelで複数のファイルを開いているとき、コントロール＋TABを押すとどんどんウィンドウが切り替わるので、それのMacVim版が欲しい〜……でもそういう機能はなさそう〜って、ずっと思っていた。

で、今あらためてメニューを見直したら……

ちゃんと書いてありましたね……こういうの、結構チェックしている自覚だったけど全然見てなかった。

最近よく使っている自作ツール（2） delete.sh

前回に続き、掲題の件。
前回の内容は、以下。

note103.hateblo.jp

今回紹介するのは、以下。

github.com

と言っても、シェルスクリプト1本ですが。

このツールには前段があって、以前にこのブログでも紹介した「trash」というソフトウェアがあるのだけど、

note103.hateblo.jp

github.com

今回のツールはそれを自分なりにアレンジしたもの。

DEMO trash

先に、その元ネタになったtrashの方を簡単に紹介すると、使い方としてはこんな感じ。

trashというコマンドの引数にファイル名を入れると、そのファイルを任意のフォルダへ移動してくれる。
（ディレクトリを扱う場合はオプション「-r」を付ける）

その移動先が「仮のゴミ箱」みたいな役割を果たすので、いきなりrm -rfとかするより安全でいいよね、しかもコマンドラインからの簡単な操作で不要なデータを捨てられるのでいい感じだよね、みたいな話。

ただこれの場合、ちょっと面倒なのは、いちいち対象のファイル名を自分の手で打ち込まなければいけないところ。

上のデモのようなシンプルなファイル名なら指定しやすいけど、たとえばこんなファイル名がうごめくカレントディレクトリだったりすると、

2016-04-22-project1.txt
2016-05-14-project1.pdf
2016-05-24-project2.txt
2016-05-25-project3.md
2017-05-26-project4.txt
2017-06-26-project5.md

何回タブで補完しても他のファイル名と共通する文字列でいちいち詰まってしまって、目当てのファイルを指定しきるまでになかなか厳しい思いをすることになる。

そこで、こういうファイル群からプルダウン的に（ファイル名を打ち込まなくても）対象を選択できるようにしたいなあ、と思って、例のごとくpecoとchoをこれに結びつけたのが今回のスクリプト。

DEMO delete.sh

「d」を叩くとカレントディレクトリ内のファイルやディレクトリがバラララッと出てくるので、あとは画面を見ながら対象を選択。すると、それが任意のゴミ箱へ飛んでいく。

（「d.」を叩くと不可視ファイルも候補に含まれる。いずれも後述のエイリアスで設定する）

移動先のゴミ箱は初期設定だと「$HOME/.Trash」（Macのゴミ箱）になっているけど、.bash_profileからTMPTRASH変数に設定すれば自由に置き換えられる。

# ホームディレクトリ直下の tmp_trash/ をゴミ箱にする場合
export TMPTRASH=$HOME/tmp_trash

なお、前述のとおりchoとpecoを使っているので、それらも要インストール。

• GitHub - mattn/cho
• GitHub - peco/peco: Simplistic interactive filtering tool

前回紹介したchoco同様、オプションで-aを指定すると不可視ファイルも扱えるようになり、-pを指定すると選択ツールがchoからpecoになる。

よって、それらを組み合わせたエイリアスを設定するならこんな感じ。

alias d="sh /path/to/delete.sh"
alias d.="sh /path/to/delete.sh -a"
alias dj="sh /path/to/delete.sh -p"
alias dj.="sh /path/to/delete.sh -ap"

ちなみに、このエイリアス例にある「d」はdeleteのdだけど、「j」にはとくにそういう意味はない。

jは単に打ちやすいから使っているのと、僕の場合は「pecoを使う時のエイリアスはjにする」という暗黙のルールみたいのがあるのでそうしている。

なんにせよ、これらのツール＆設定により、「このファイルちょっと作業の邪魔だな〜。ゴミ箱に移動しとこ」と思ったらポンと「d」を叩くだけでサクサク選択＆ポイできる。

一方、このツールだと1回のアクションで捨てられるデータが1個だけなので、複数の対象を選択してポイできるようにしたいなあ、と思って作ったツールもあって、次回はそれを紹介したい。

最近よく使っている自作ツール（1） choco

プログラミングの学習にともない作った自分用のコマンドラインツールというものがあって、折りに触れこのブログでも記録＆紹介しているのだけど、それでも以前に紹介した後に手元でどんどんアップデートしつつも外には出せていないものや、新たに作ったけど自分しか知らないツールというのもあって、少しずつでもそういうのをあらためて紹介していきたいと思ったのでそうする。

リストアップしてみたら結構な数になったので、何回かに分けるかもしれない。（いま書きながらどうするか考えている。書き終える頃にはどうなるか決まっているはず）

choco

まずはこれまでも何度か紹介している以下の最新版。

github.com

mattnさんによるchoと、lestrratさんによるpecoを使って、ディレクトリをスイスイ移動したり、移動した先で選択したファイルをオープンしたりする。

• GitHub - mattn/cho
• GitHub - peco/peco: Simplistic interactive filtering tool

choで移動しているところ

pecoで移動して最後に選択したファイルを開いているところ

オープンするやつはmacOSのopenコマンドを使用しているので、他の環境でどうなるかはわからない。

たぶんコンピュータを開いて作業している日のうち、これを使わない日はないと思う。
我ながらすごく便利だし、俺グッジョブという感じ。

（いやもちろん、mattnさんやlestrratさんのおかげなわけですが）

名前

以前はこのツール、 "dirmove" という名前にしていたけど、それだとファイルやディレクトリ自体を移動させる意味が含まれてしまいそうなのと、移動先のファイルを開く、という目的も大きくなってきたので名前を変えたいと思い、choとpecoを使っているので合わせて "choco" にした。

これ自体は作業のメインに使うものではなく、単にちょこちょこ動きたいだけ、というグルー（のり）的な道具なので、意味を限定しすぎず、なおかつちょっと可愛い感じで良いネーミングではないかと自分では思っている。

懸案

メインのコードはPerlで書いているが、コマンドラインから居場所をどんどん移動して、なおかつ移動先に着地しなければならない都合上、bashrcにも少なからず記述が必要になる。

詳しくはREADME.mdを参照してほしいが、現時点ではこんな感じ。

# .bashrc

function dirmove {
    local result="$1"
    local basename=""
    local dirname=""

    if [ -e "$result" ]; then
        basename=${result##*/}
        if [ -f "$result" ]; then
            dirname="${result%%$basename}"
        elif [ -d "$result" ]; then
            dirname="$result"
        fi
    fi
    cd "$dirname"
}

function choco {
    local command="${@:$#}"
    local result=$(perl ~/path/to/choco/choco.pl "$@")

    if  [ $# = 0 ] ; then
        command=echo
    elif [[ "$command" =~ - ]] ; then
        if [[ "$command" =~ p ]] || [[ "$command" =~ a ]]; then
            command=echo
        fi
    fi

    if  [ -e "$result" ]; then
        dirmove "$result"
    fi
    $command $result
}

alias s=choco
alias s.="choco -a"  # 不可視ファイルを対象に含める
alias j="choco -p open"  # pecoを使う
alias j.="choco -ap open"  # pecoを使って不可視ファイルも対象に含める

zshだとどうなるか、とかはわからない。

上では関数を二つ書いていて、chocoというメインの関数の他にdirmoveという関数を分けて作っているのだけど、これは後日紹介予定の別ツールでもそのdirmove関数を使うから。
逆に言うと、chocoしか使わないならこれらを一つの関数に合わせてしまってもよい。

いずれにせよ、けっこう行数があるので、シェルスクリプトのファイルに切り出した方が良いのではないかと思って何度か試したのだけど、前述のとおりディレクトリを移動するためにはbashrcへの記述が必須のようで*1、仕方なくbashrcにいろいろ書くことになってしまっている。

最後にエイリアスをいくつか設定しているが、ようはデフォルトだとchoを使うようになっていて、オプションとして -p を指定するとpecoを使うようになり、また -a を指定すると不可視ファイルが対象に含まれ、さらに引数の最後にopenコマンドを入れると最終的に選択したファイルがオープンされる、という感じ。

次回予告

似たようなツールを少なくとももう一つ紹介するつもりだったが、結構長くなったのでここまで。

ブログ記事1本あたりの負担を軽減してコンスタントにパブリッシュできるようにしたいところだけど、どうなるか……。

*1:たとえば「start/path/to/end」というディレクトリ構造で、「startから移動してendのディレクトリに出たい」というときに、それらの関数をbashrcではなくシェルスクリプトなどに書くと、操作中はあちこちに移動できるのだけど、操作を終えるとstartに戻ってしまう。

21世紀の文字起こし（2）

以前に書いた記事からだいぶ間が空いてしまったけど、
note103.hateblo.jp

今回はその続編というか、スピンオフ的な経過報告。

ちなみに、一つ前の記事でも本件の環境設定に関することを書いているので、よろしければどうぞ。
note103.hateblo.jp

目次

今回の課題

前回の記事の主眼というのは、

1. 録音した音声ファイルを聴きながら、Googleドキュメントの音声入力にシャドウイング*1で言葉を吹き込んでいくと、普通に文字起こしをするよりずっとラクにテキスト化できるじゃん！
2. ……とか思ってたら、さらにSoundflowerというのを使えば自分でしゃべらなくても音声ファイルからダイレクトで文字起こしできるじゃん！！

みたいな話だったと思うのだけど*2、その後にいろいろな音声データでトライしてみたところ、綺麗に拾える場合と、誤認識が多くてカオスな状態になる場合とでバラバラというか、綺麗に拾える条件・法則がちょっとわかりづらかったので、今回は以下の観点から、その辺を整理してみたい。

1. 再録音の有効性
   1. 再録音（元音声を聴きながらシャドウイングで新たな録音すること）は必要か？
   2. もし元の録音データのままでも使えるとすれば、どの程度の録音状態なら許容範囲か？
   3. 悪音質のデータを再録音したら、どの程度仕上がりが改善されるのか？
   4. 再録音した音声ファイルから音声入力をするのと、直接マイクに向かってしゃべりながら音声入力をするのとでは、どちらの方が精度が高いか？
2. 音声入力時の再生速度の最適化
   1. 音声ファイルをGoogleドキュメントで音声入力させる際、再生速度は仕上がりテキストに影響を与えるか？　もし与えるなら、最も綺麗にテキスト化されるスピードは？
   2. Googleドキュメントは最大で何分程度読み込み続けるのか？

1. 再録音の有効性

1-1. 再録音（元音声を聴きながらシャドウイングで新たな録音すること）は必要か？

結論から言うと、そこそこ綺麗に録音されているデータなら、再録音せずともある程度は正確に拾えるし、環境が整っているところで録音された音声ならば、なお良好な結果を得られると思う。

また、前回の記事でも示したように、英語の音声であれば日本語以上に綺麗にテキスト化されやすいようなので、たとえば英語のPodcastをテキスト化したい、といった場合にも再録音は不要かもしれない。

逆に、講演や会議、あるいは周りの音が一緒に入ってしまう場所でのインタビューなど、録音以外のことがメインになっている環境で録った音の場合、そのまま使うことはあまりお勧めできない。

実際には、そういったデータからでもテキスト化は成されるが、本来の内容との乖離が激しくなる可能性が高く、最初のテキスト化のコストを軽減できたとしても、そこから修正するコストが通常以上に高くなってしまい、かえって非効率になりかねない。

よって、そういった悪コンディションのデータを使う場合には、再録音、または後に示すように、直接しゃべり直しながら音声入力してしまった方が、トータルのコストを下げられるとは思う。

1-2. もし元の録音データのままでも使えるとすれば、どの程度の録音状態なら許容範囲か？

2種類のサンプルを用意してみた。

一つは、昨年のちょうど今頃にプログラミングの勉強会で発表をしたときの録音*3から、1分間だけ切り取ったもの。
2016-01-15_kichijojipm_sample by note103 | Free Listening on SoundCloud

もう一つは、自分のメインブログで時々公開している日記調のモノローグというか、Podcast風に淡々としゃべっている音声から、同じく1分間切り取ったもの。
2016-12-29_sample by note103 | Free Listening on SoundCloud

前者は広めの会議室のようなところで、自分の発表時にスライドを操作するPCの脇にICレコーダーを置いて録音している。
聴講席から他人の発表を録音するよりはクリアだが、それでもあまり良い音質とは言えない。

後者はAudacityというフリーのソフトウェアを使用して、ヘッドセットマイクから直接録音している。

http://www.audacityteam.org/

よって、文字起こしを行うための録音としては良質な部類に入ると思う。

そして今回は、それぞれの音声を用いて音声入力をさせているところを、リアルタイムで動画に撮ってみた。
元の音声と仕上がりのテキストだけを提示するより、直感的に違いがわかるかもしれないと思ったので。

ちなみに、この動画撮影に際しては、音声ファイルの再生にExpressScribe*4、その音声を機械に聴かせるためにSoundflower、音声入力にはGoogleドキュメント（ブラウザはGoogle Chrome）、動画の録画にはQuickTime Playerを使用している。

以下では、まず動画だけ2パターン並べて示し、その後に仕上がりテキストを掲示する。
動画内で流れている音声は、そのときにGoogleドキュメントが聴いているのと同じものである。

動画比較

• 勉強会発表（会議室・ICレコーダーで）
  • 20秒を過ぎてからは変化しなくなるのでそっ閉じ推奨。

youtu.be

• モノローグ（ヘッドセットマイクで）
  • 上より少し音量が大きいので注意。

youtu.be

テキスト比較

• 勉強会発表（会議室・ICレコーダーで）

ちょっと待って勇気出してんですけどそれはただ死んだけど
(27文字)

• モノローグ（ヘッドセットマイクで）

後ね今回でスト掲示板に二つにページしかないんですがさっき言った400局から31局を経て最後の22曲になったって話があるんですけど31よりもちょっと多い70曲ぐらいですかねちょっと今正確に合わせていましたけど迷わ準決勝戦ぐらいの決勝戦が31から22に搾られる家庭だとした場合70キロから30局になる31分解中途半端ですけどね言いながら思いましたけどまたまた勝ったんですけどその70から31になるまでは準決勝みたいな感じが自分では下手ですねそのね70ぐらいまでをあの掲載してますので今回は
(242文字)

ということで、比べるまでもないほど前者はまったく拾えていない。
「メッセージはここで途切れている」みたいになっている。

後者の方はそれに比べるとだいぶ良い。というか、かなり違う。
それでふと気になったので、音声の波形も見てみた。

波形比較

上述のAudacityで、双方前半30秒分を切り出してみる。

なお、勉強会発表の方はICレコーダーのステレオ録音、モノローグはヘッドセットの1マイクなので、見比べやすいように前者はLだけを切り取った。

もしかすると音質以前の問題として、「ステレオはテキスト化されづらい。モノラルだとテキスト化されやすい」などの違いがあるのかな？　とも思ったので、別途でICレコーダーのステレオ録音でモノローグを録ってみたが（マイクの近くで発声する）、これは綺麗にテキスト化されたので、ステレオとモノラルの違いはこの際とくに考慮しなくて良いと思う。

ではあらためて、波形の比較。

• 勉強会発表（会議室・ICレコーダーで）

• モノローグ（ヘッドセットマイクで）

別の話をしているので、山の場所が異なるのは当然のこととしても、それ以上に何より起伏の差がかなり違う。
だからどう、ということまでは言えないのだけど、まあ、「起伏の差が激しいとテキスト化されづらく、おとなしいとされやすい」ということなのかな、ぐらいの印象は持った。

で、このような結果を見ると、今度は以下のようなことが気になってくる。

1-3. 悪音質のデータを再録音したら、どの程度仕上がりが改善されるのか？

ということで、次はそれについて検証したい。

まずは先ほど惨憺たる結果をはじき出した、勉強会での発表内容を再録音する。

方法としては、ヘッドセットのヘッドホンからスロー再生で発表を聴きながら、同じヘッドセットのマイクからその内容を吹き込み直す。

ツールとしては、上記同様にヘッドホンへの出力にはExpressScribeを使用し、マイクからの録音にはAudacityを使う。

これが上でも何度か言っている「シャドウイング」というもので、とはいえ今回は元音声でぼくがかなり早口でしゃべってしまっているので、スロー再生を前提にセッティングしているが、シャドウイング自体は「音を聴きながら同じ言葉を発声する」ことができればよいので、このような環境がなければ「iPhoneからイヤホンで音を聴きながら口元で別のレコーダーに録音する」とかでも実現自体は可能である。

で、そのように再録音したものをGoogleドキュメントに読み込ませると、このようになる。

• 勉強会発表音声（再録音版）

youtu.be

• 仕上がりテキスト（再録音版）

でもう1個はまあよくあるこれもちょっとミスマッチがちかなっていう気がしているんですけどまあとりあえず4エラーお嫁様と出てるじゃんみたいなそれは正しいんだけどで後はまぁ確かにね英語はちょっとなじまないだろうけどとか言うんだけど英語が問題じゃないたぶんそれは多分エラーを読む人はそもそも何を読んでいるのかって言うと自分の頭で仮設がある程度できていてここでこけるって言うことはこれかこれかこれかそれかそれ以外かっていうのがあるわけですよねですそれと出てきたエラーをその前提と比べていると思うんですよだけど初心者っていうのはそれがもとの仮説がないから出てきたやつをもう最初から読んでいくしかないとだからたぶん日本語で出ても初心者にはわからないと思う日本語で言われても引数がどうだとかサブルーチンが不正な呼び出しをされていますとかしかもそれはちょっと違ったりとかするんで
（380文字）

ということで、元音声では30文字にも満たなかったのが嘘のように、大量かつ高い精度でテキスト化されている。*5

これだけ違いが出ると、ここでもまた波形を見たくなってくる。
で、取ってみた。

波形比較

まずは先ほどの、全然拾えなかったやつ。

• 勉強会発表（会議室・ICレコーダーで）

次に、再録音したらだいぶ拾えるようになったやつ。

• 勉強会発表（再録音版）

だいぶスリムになっている。
ついでに、先ほど綺麗に拾えたモノローグ音声も並べてみよう。

• モノローグ（ヘッドセットマイクで）

はい。まあ、とくにこれを分析できる知識はないのだけど、とはいえやはり、波形が激しいやつだと拾いづらいのかな、という感じはする。

ところで、先ほどの元音声と、再録音版とを聴き比べると、そのスピードが違うことが気になってくる。

どういうことかと言うと、再録音版がゆっくりしているのは、上記のようにシャドウイングする際の都合によるわけだけど、もしかすると元音声の方も再生速度を落としたらけっこう拾えるのでは？　みたいな疑問が湧いたということ。

なので、念のために元音声の速度を落とした場合も試してみた。

• 勉強会発表音声（元音声・再生速度70%）

youtu.be

まったく反応ナシ……（なので途中で止めた）。

1-4. 再録音した音声ファイルから音声入力をするのと、直接マイクに向かってしゃべりながら音声入力をするのとでは、どちらの方が精度が高いか？

上記の検証により、音質の悪い音声ファイルでも、シャドウイングで再録音すれば音声入力によるテキスト化が可能になることがわかった。

しかしここで新たに気になるのが、一度別ファイルに再録音するのではなく、直接シャドウイングしながら音声入力ツールに吹き込んだらどうなるのか？　ということだ。

というのも、別ファイルに再録音した場合、その後にGoogleドキュメントに読み込ませるときにもほぼ同じ時間をかけて読み込ませなければならないので、少なくとも元データの2回分（スロー再生で再録音するならばそれ以上）の時間がかかる。

翻って、再録音の工程を省いて直接音声入力してしまえば、その時間が半分で済む。

ということで、同じ勉強会の元音声を聴きながら、直接音声入力してみたのが以下。

• 勉強会発表音声（直接音声入力版）*6

youtu.be

• 仕上がりテキスト（直接音声入力版）

もう1個はまあよくあるこれもちょっとミスマッチがちかなっていう気がしているんですけどまあとりあえずエラー読めよと出てるじゃんみたいなそれは正しいんだけどで後はまぁ確かにね英語はちょっとなじまないだろうけどとか言うんだけど英語は問題じゃないたぶんそれは多分エラーを読む人がじゃあそもそも何を読んでいるのかって言うと自分の頭でも仮説がある程度できていてここでこけるって言うことはこれかこれかこれかそれかそれ以外かっていうのがあるわけですよねでそれと出てきたエラーをその前提と比べていると思うんですよねだけど初心者っていうのはそれがもとの仮説がないから出てきたやつをもう最初から読んでいくしかないとだからたぶん日本語で出ても初心者は分からない日本語で言われても引数がどうだとかサブルーチンが不正な呼び出しをされてますとかでしかもそれがちょっと違ったりとかまーするんで
（380文字）

ふむ。若干ながら、上の再録音版より精度が上がっているように見える。
拾った語数もほぼ同じ。

つまり、少なくともこの直接入力の方法が再録音版より劣るということはなさそうなので、もし最初からこの方法を採れるなら、その方が効率は良いかもしれない。

また、先に再録音だけを行う場合というのは、地味に「この発声でちゃんとテキスト化されるのか？」という不安が生じたり、かつ実際にその再録音したものを読み込ませてみたら上手くテキスト化されなかった、なんていうことも何度かあったりしたので、そのように結果が出るまで不安を抱えてしまうぐらいなら、最初から直接入力でフィードバックを確認しながらやったほうが精神的にラク、というメリットもあるかもしれない。

一方、これはあくまで個人的な実感だけど、この直接入力というのはなかなか疲れる。
上記のように、基本的には目の前で起こされていく状況を確認しながら進めることになるので、そうなると「音を聴きながら発声する」という作業に加え、「目視で仕上がりを確認する」という作業をマルチタスク的に抱えることになり、そのぶん肉体的な負担が増すのかもしれない。

また、直接音声入力をする際には、Googleドキュメントで文書を作成しながら録音を行える環境を整えなければならないので（マイクのセッティングなどはもちろん、他人の迷惑にならない場所へ移動するなど）、そうした「ちょうどよい環境」を作るコストが低くない。

その点、先に再録音を行ってから、別の機会に音声入力をするのであれば、トータルの作業時間は多くなるとしても、それぞれの特化的な作業に集中できるので、並行して一気にすべてを進めることに比べて負荷が低く、継続的な作業を見込める面もあると思う。

よって、この「再録音」と「直接入力」の選択に関しては、上記のようなメリット／デメリットを踏まえつつ、作業者それぞれの目的や、環境に応じて適した方法を選ぶのが良いように思える。

2. 音声入力時の再生速度の最適化

2-1. 音声ファイルをGoogleドキュメントで音声入力させる際、再生速度は仕上がりテキストに影響を与えるか？　もし与えるなら、最も綺麗にテキスト化されるスピードは？

これについては、上記の再録音版データを「150%（速い）」「標準速度」「50%（遅い）」の3種類で読み込ませてみた。
（「標準速度」は前出のもの）

先に動画を3点並べ、その後に仕上がりテキストを並べて掲示する。

動画比較

• 再生速度150%

youtu.be

• 再生速度100%（再掲）

youtu.be

• 再生速度50%

youtu.be

テキスト比較

• 再生速度150%

もう1個はまあよくあるこれもちょっとミスマッチがちかなっていう気がしているんですけどまあとりあえず予定はお嫁様と寝てるじゃんみたいなそれは正しいんだけどで後はまぁ確かにね英語はちょっとなじまないだろうけどとか言うんだけど英語が問題じゃないもんたぶんそれは多分エラーを読む人がそもそも何を読んでいるのかって言うと自分の頭で稼ぐがある程度できていてここでこけるって言うことがこれかこれかこれかこれかそれ以外かっていうのがあるわけですよねでそれと出てきたエラーをその前提と比べていると思うんですよだけど初心者っていうのはそれがもとの仮説がないから出てきたやつをもう退職から読んでいくしかないとだからたぶん日本語でても初心者にはわからないと思う日本語で言われても引数がどうだとかサブルーチン学生の呼び出しをされていますがしかもそれはちょっと違ったりとかするんで
(376文字)

• 再生速度100%（再掲）

でもう1個はまあよくあるこれもちょっとミスマッチがちかなっていう気がしているんですけどまあとりあえず4エラーお嫁様と出てるじゃんみたいなそれは正しいんだけどで後はまぁ確かにね英語はちょっとなじまないだろうけどとか言うんだけど英語が問題じゃないたぶんそれは多分エラーを読む人はそもそも何を読んでいるのかって言うと自分の頭で仮設がある程度できていてここでこけるって言うことはこれかこれかこれかそれかそれ以外かっていうのがあるわけですよねですそれと出てきたエラーをその前提と比べていると思うんですよだけど初心者っていうのはそれがもとの仮説がないから出てきたやつをもう最初から読んでいくしかないとだからたぶん日本語で出ても初心者にはわからないと思う日本語で言われても引数がどうだとかサブルーチンが不正な呼び出しをされていますとかしかもそれはちょっと違ったりとかするんで
(380文字)

• 再生速度50%

でもう1個はまあよくあるこれもちょっとミスマッチがちかなっていう気がしているんですけどまあとりあえずよヘラを読めよと出てるじゃんみたいなそれは正しいんだけどで後はまぁ確かにね英語はちょっと馴染まないだろうけどとか言うんだけど英語が問題じゃないたぶんそれは多分エラーを読む人はそもそも何を読んでいるのかって言うと自分の頭でか説がある程度できていてここでこけるっていうことはこれかこれかこれかそれかそれ以外かっていうのがあるわけですよねですそれと出てきたエラーをその前提と比べていると思うんですよだけど初心者っていうのはそれがもとの仮説がないから出てきたやつをもう最初から読んでいくしかないとだからたぶん日本語で出ても送信者には分からないと思う日本語で言われても引数がどうだとかサブルーチンが不正な呼び出しをされていますとかしかもそれはちょっと違ったりとかするんで
(380文字)

ということで、目視でこれらの違いを判別するのはけっこう大変なのだけど、ざっと読み取れるのは以下のようなこと。

• 拾える文字数はほぼ変わらない。
• 再生速度が速くても遅くても、それぞれ100%の場合に比べて誤認識が増えている。
  • 150%: 「仮説」→「稼ぐ」、「最初」→「退職」
  • 50%: 「エラー」→「ヘラ」、「初心者」→「送信者」

じつは事前の仮説としては、「スピードが遅いほど綺麗に起こされるのでは」と思っていたのだけど、実際には遅くすれば綺麗になるということはなく、むしろ読み込ませるのに余計時間がかかる分、デメリットの方が多いと思えた。

逆に、再生速度を速くしてもこのぐらいの誤認識で済むのであれば、それによって読み込む時間を短縮できるメリットを取った方が良いと考えることもできるが、とはいえこの段階でミスが多くなると、その後に行うテキスト編集（修正）の段階で手間や集中力といった負荷が増えるので、やはり誤認識は少なければ少ないほどよいとも思える。

よって、その辺りも含めて総合的に考えれば、標準速度（再生速度100%）にするのが無難かなと思うが、よくよく考えてみれば、再生速度が速すぎても遅すぎても、本来の人間がしゃべる言葉から離れていくことになるわけで、ようは「最も一般的な人間のしゃべり方に近い速度」を設定するのが良いということかもしれない。

また、そもそも人がしゃべる速度というのも人によって様々なわけで、ゆっくりしゃべっている音声ならやや速めに、逆に早口な人なら速度を落とすように、といった調整を行った方が綺麗に検知することもあるかもしれない。

2-2. Googleドキュメントは最大で何分程度読み込み続けるのか？

ところで、上記の動画群を見て気づいた人もいるかもしれないのだけど、前回の記事でぼくはこのようなことを書いていて、

4. 音声ファイルが終わるまで再読み込みなどのケア
前述のように、入力は音声ファイルが止まるまで続くわけではなく、途中で止まる。いわばフリーズしたような状態になる。
調子が良ければ1分以上入力され続けることもあるが、平均的には40秒程度かもしれない。
（略）
よって2秒程度入力が止まったら、もうフリーズしたとみなして再起動する。
具体的には、マイクボタンを押して一度入力機能をストップし、もう一度押して再開させる。すると、また入力が始まる。

しかし上の動画においては、そのような再起動は不要だった。

もしかすると、Googleの音声入力機能が向上したということだろうか？
よくわからないが、とりあえず現時点ではどの程度、再起動せずに動き続けるのか気になったので、これも試してみた。

といっても、そのためにわざわざ長尺の再録音をするのも面倒なので、上で元音声のままでもそこそこの精度でテキスト化された、モノローグ音声のフル尺版（約11分半）を読み込ませてみた。

結果はこのような感じ。*7

youtu.be

なんと音声ファイルが終わるまでの11分半、すべて再起動なしで読み込んでしまった。

じつはブラウザの拡張機能でiMacrosというツールを使うと、一定時間ごとに任意の処理をさせることができて、それを設定すれば数分ごとに音声の読み込みを再起動させることができるので、いずれその方法も紹介しようと思っていたのだけど、これならもはや不要かもしれない。

経験上、この音声入力機能は音を読み込めない時間がしばらく続くとストップしてしまうようなので、切れ目なく読み込める程度に音質が良いファイルなら、再起動の必要性が低くなったということなのかもしれないが。

まとめ

例によって長くなってしまったけど、最初に掲げた課題については触れ終えたので、ひとまずここまでのまとめ。

1. 再録音の有効性
   1. Q1: 再録音（元音声を聴きながらシャドウイングで新たな録音すること）は必要か？
      • A1: 録音状態が良ければ不要な場合もある。ただし誤認識が多ければそのぶん後の作業に負債を抱え込むことになるので、後のことまで考えて判断すべし。録音状態が悪ければ再録音一択。
   2. Q2: もし元の録音データのままでも使えるとすれば、どの程度の録音状態なら許容範囲か？
      • A2: 講演会場や会議室など広い空間におけるICレコーダー等での録音は、そのままでは使えない可能性が高い。一方、マイクと発声源が近い録音ならば良好な結果を得られる可能性が高い。
   3. Q3: 悪音質のデータを再録音したら、どの程度仕上がりが改善されるのか？
      • A3: まったくテキスト化されなかったものが、かなりテキスト化されるようになる。
   4. Q4: 再録音した音声ファイルから音声入力をするのと、直接マイクに向かってしゃべりながら音声入力をするのとでは、どちらの方が精度が高いか？
      • A4: 直接しゃべりながら音声入力を行った方が、精度が高くなると思われる。この場合、再録音の工程をスキップできるので、作業時間の短縮というメリットもある。ただし、工程を分ければ環境を準備しやすくなったり、作業負荷を軽減できたりするメリットもあるので、状況に応じて判断すべし。
2. 音声入力時の再生速度の最適化
   1. Q5: 音声ファイルをGoogleドキュメントで音声入力させる際、再生速度は仕上がりテキストに影響を与えるか？　もし与えるなら、最も綺麗にテキスト化されるスピードは？
      • A5: 1分のサンプルデータで確認したかぎり、再生速度による大きな違いはないが、その中では標準速度の仕上がりが一番良いように見える。ただし、元音声の発話速度によって、チューニングの余地があるかもしれない。要検証。
   2. Q6: Googleドキュメントは最大で何分程度読み込み続けるのか？
      • A6: 以前に試した際は40秒〜1分程度ごとの再起動が必要だと感じたが、今回試したところでは10分以上にわたるノンストップの入力が実現した。ただし、音質が良好であるという条件が必要かもしれず、その他にも長時間入力を実現させるための条件があるかもしれない。要検証。

免責事項

今回行った各種の実験は、限られたサンプルと機会を通じて、それぞれ1〜2度ずつ試してみたものに過ぎないので、普遍的な正解ではまったくない。

再現性の高い結論を出すためには、より厳密に条件を揃えた上で、同じ実験をくり返し行うべきだが、さすがにそこまではできないし、そもそもこのツール自体どんどんアップデートされていくだろうし、あるいは突然使えなくなってしまう可能性だってある。

あくまで一人のユーザーが、個人的・自主的にいろいろ遊んでみた結果として見てもらえたらありがたい。

次回予告

前回の最後で、textlintの導入について予告したのだけど、それ以前の音声入力関連の情報をまとめるだけで力尽きてしまった。
textlintの使用を含む、「テキスト整形」に関わる作業については、次回以降にあらためてまとめてみたい。
（いつになるかは無保証だが……）

続編

note103.hateblo.jp

*1:耳から入った音声を追いかけるように発声すること。語学の学習などでよく行われるらしい。

*2:もう半年前の記事で自分でも忘れかけていたので、この部分を書きながら少しずつ思い出した。

*3:元資料などはここで読める。→ 吉祥寺.pm6に参加しました（トーク音声公開＆スライド作成方法） - the code to rock

*4:音声の再生はiTunesなど他の汎用音楽ソフトでも可能だが、ここでは細かいショートカットキーの設定が便利なのでExpressScribeを使った。

*5:不思議なことに、というか、皮肉なことに、というか、この再録音版は、人間の耳で聞くと、元の音声よりぎこちない調子で、けっして聞き心地が良いとは言えないのだけど、機械にとってはこちらの方が聞きやすいようである。これが人間にとって聞きづらく感じられる理由は、この音声がシャドウイングという、「発声し直すこと」を目的に録音されているからであって、言い換えれば、「人間に話の内容を理解してもらうこと」を目的にはしていないからだと考えられる。つまり、想定リスナーは「人間ではない何か」である。そのような音声が人間からは親しみを持たれづらく、しかし機械からは理解（というか解釈）されやすい、という状況が面白い。

*6:メインの発話の後ろで薄く聞こえている声があるが、これはヘッドホンから漏れている元音声。シャドウイングは耳から入る音に集中して、自分の発声はあまり聞こえないようにした方がやりやすい、という話を時々聞くけど、まさにそんな感じがしたのでヘッドホンの音量を大きめにしていた。

*7:実験の目的上、仕上がりテキストは不要なので動画のみ掲示するが、通読できる程度まで整形したテキストはここで読める。→ 音声入力を用いた文字起こしでブログ（3） 〜schola16巻のつくり方〜 - 103

AudacityとSoundflowerをセットするまで

昨年11月に長期プロジェクトがひと段落して、軽いマシンがほしかったので（重量的な意味で）、MacBookを購入した。

以前のマシンから環境をそのまま引き継ぐか、少し迷ったが、把握していない不要データごと引っ越すのもいやだな、と思ってイチからいろいろ入れていくことにした。

心配していたのはMicrosoft Office系、それからAdobe系の移行だったが、いずれも気が抜けるほどすんなりライセンスが通った。

それでほぼ環境は整ったと思っていたが、その長期プロジェクトの切り替えにともない、若干ながら＆一時的ながら、自分の時間が増えたので、以前にやや中途半端なまま止まってしまった、音声入力を使った文字起こしのトライを再開しはじめたところ、
note103.hateblo.jp

音声ファイルをエディットするために使うAudacityと、Googleドキュメントの音声入力ツールに音を読み込ませるためのSoundflowerが入っていないことに気づいた。

で、これらは今までの経験上、何気に導入コストが高いというか、面倒という印象があったので（とくにSoundflower）、びくびくしながらコトを進めたが、存外これもすんなり完了し、しかしそれでも後から思い出すのはやはり面倒そうだなと思ったので、ここにメモしておくことにした。

contents:

Audacity

まずAudacityの導入から。
公式サイトは以下。

Audacity®

そのトップページからソフトをダウンロードして、

それをダブルクリックしたら、あとは案内に従ってインストールすればOK。

え、それだけ？　という感じだけど、そう、普通に使うだけならそれで充分。

なのだけど、面倒なのはエディット後のファイルをmp3に書き出すときで、wavやaiffならそのまま書き出せるけど（たしか）、mp3に書き出そうとすると、Lameというのが足りないよ、と言われる。

具体的には、以下のリンクを示されて、とりあえずちょっとこれ見とけ、みたいなアラートが出る。

http://manual.audacityteam.org/man/faq_installation_and_plug_ins.html#lame

なので、そのリンク先にあるMacの項目の、最初にあるリンクをクリックして、

http://lame.buanzo.org/#lameosxdl

飛んだ先で一番それっぽい、「For Audacity 1.3.3 or later on Mac OS X 10.4 and greater (Intel or PPC),and Audacity 1.2.5 on OS X 10.4 and later (Intel)」というところからdmgファイルをダウンロード＆インストール。

これでmp3に書き出せるようになる。

しかし以前はもっと大変だった気がするんだけどなあ〜……だいぶラクになっているような。

なお、Audacityについては以下の記事でも少し触れている。

note103.hateblo.jp

Soundflower

次、Soundflower。

Soundflowerについても、以前に書いた以下の記事でちらちら紹介している。

• 自作英単語学習ツール: "Carvo2" の最近の様子 - the code to rock
• 21世紀の文字起こし - the code to rock

とくに後者、というか冒頭でも示した文字起こしの記事は比較的最近なので、基本的にはそのくり返しになるのだけど、以下のGitHub上のリリースページから、

Releases · mattingalls/Soundflower · GitHub

現時点の最新版（2.02b）をダウンロード＆インストールした。

Soundflowerの場合はとくにOSのバージョンや導入時期などによって、ソフトはもちろん、配布場所や開発者も違ったりする印象があるので、この機会にきちんとメモしておきたかった。

そういえば、つい最近どこかで見たブログ記事でも、「元のソフトは新しいOSでは動かないから」といって上記のfork版を紹介していたなあ、と思ったらはてなの開発者ブログだった。
developer.hatenastaff.com

なお、上の文字起こし記事でも触れているように、マシン内で音声ファイルを再生＆録音させる際には、サウンド設定を入出力ともに「Soundflower(2h)」にする必要があるので、注意。

マシンの環境設定＞サウンドからでも設定できるが、Optionを押しながらメニューバーのスピーカーマークを押せば簡単に選択できる。

さらに、それを再びマシンから普通に鳴らしたい場合には同様の方法で「出力」の方を「内蔵スピーカー」などに戻す必要があるので、再注意。

と思いつつ、今回このメモをまとめるために念のためあちこち検索してみたところ、以下のまとめがわかりやすく*1、
rnkv.hatenadiary.jp

その中で紹介されていた「LadioCast」というツールがその辺をより便利にしてくれそうだった。

http://blog.kawauso.com/ladiocast

上に書いた設定でSoundflowerで録音すると、その間はマシン内で流している音を聴けないのだけど、これを使うと自分でもモニターを聴けるみたい。
今度録音するときから試してみたい。

また、そのLadioCastを使って録音する手順などについて、以下のQiitaの記事がスクリーンショット付きかつコンパクトな説明でわかりやすそうだった。（まだ精読していないけど）

qiita.com

そして作業へ

ということで、準備系のそれらについては以上。

本来の目的である文字起こしなどについては、また別の記事にまとめたい。

なお、当然のことながら上記の情報は本日（2017-01-01）時点のものにすぎないので、時間が経過すればするほどあくまで参考までに、という感じでお考えください。

*1:なんと昨日の更新だったみたい。シンクロニシティ……。