21世紀の文字起こし(3) 〜 Cloud Speech-to-Text 編 〜
ここまでのあらすじ
少なからぬ人々が直面する文字起こし(音声を文字に変換する作業)について、手動でパチパチやっていくのはけっこうつらいものがあるので、なんとか自動化できないか? というこのシリーズ。
気がつけば最初の記事はちょうど2年前の今頃に書いていて、続編はその半年後。で、それからさらに1年半ぐらい経ったわけですが。
note103.hateblo.jp
note103.hateblo.jp
最初の記事は、たしかiPhoneの音声入力機能を使って、耳から当該音声ファイルを聴きながら自分でそれを追いかけて喋るという、いわばシャドウイング方式でやったらこれ文字起こしになるじゃん! という素朴な発見から始まって。
そのまま連想的に「でも自分で喋らなくても、SoundflowerとGoogleドキュメントの音声入力を組み合わせればなんか自動でできそうじゃね?」と思ってやってみたら「うわ、できるじゃん(笑)」みたいな流れだったかなと。
続編の方は、その最初の記事では憶測で書いていたような各種の条件的な部分をもう少し厳密に検証して、「何ができて、何ができないのか」を自分なりにまとめたものでした。
で、それから2年が経って今はどうかというと、Googleさんの技術の進歩は目覚ましく、最初の記事では「1分もしないうちに止まってしまう」とか言っていたのがほとんど永遠に起こし続けるようになり、内容の精度もだいぶ上がっているように感じられます。
しかしその一方で、じつはGoogleさんはそれとは別の音声認識サービス「Cloud Speech-to-Text(旧称・Cloud Speech API)」も開発・提供していて、とくにここ半年ぐらいはそれを使ったり試したりする人を目にする機会が増えました。
cloud.google.com
cloudplatform-jp.googleblog.com
そして、これは同じGoogleさんのサービスでありながら、上記のGoogleドキュメントを使った音声入力(を使ったハック)と異なる点が少なくありません。
ということで、今回はそのCloud Speech-to-Textを使って文字起こしをする方法と、それを通して出力された結果がどんな感じなのか、記していきたいと思います。
免責事項
本題に入る前に明記しておきますと、ぼくは普段プログラミングやITに関わる仕事をしているわけではなく、以下の内容はどれも100%趣味のレベルで調べたり試したりしたことですので、間違いを含んでいる可能性もありますし、下記の情報を元にトライした誰かがそれによってなんらかの損害を被ったとしても、ぼくがその責任を負うことはできません。その前提でご参照ください。
Cloud Speech-to-Text の使い方
参考資料
通常、参考資料というのはこういった記事の最後に列記するのが大半だと思いますが、この後に紹介する文字起こしの方法は、そのほとんどがこれら参考資料の刷り直しみたいなものにすぎないので、各記事への敬意と感謝を込めて最初に示しておきます。
投稿された時系列に示しますと、以下の記事群がとても参考になりました。
- Google Cloud Speech APIで音声の自動文字起こし
- Google Cloud Speech API を使った音声の文字起こし手順
- 超初心者でもgoogle-cloud-speechを使えるが、つまずいた所はある。
- 【GCP】超超初心者がGoogle speech api を使うところ。(wav形式)
最初の記事では、この手法全体の流れやエッセンスがコンパクトにまとまっています。特徴的なのは、最後に「どういう音声が認識されやすいのか」をまとめてくれているところで、なるほど感がありました。(これについては終盤であらためて言及します)
2番めの記事は手順が非常に詳しく書かれていて、個人的に一番参考になったのはこれだと思います。とくに、認証まわりはけっこうコケやすいというか、めげやすい部分だったのですが、同記事を何度も読み返しながらなんとかクリアできました。
また、最初の記事と2番めの記事には、この後に出てくるPythonのコード例が示されていてとても助かりました。両者のコードは1〜2行を除いてほとんど同じなので、後者が前者を参考にしたのか、あるいは両者が同じ元ネタを参考にしたのかわからないですが、いずれにしてもやりたいことはできたので感謝しています。
※そのコードの元ネタについて、検索し回ったかぎりでは公式ドキュメントのサンプル群から辿りついた以下が一番近そうとは思いましたが、ちゃんとは検証していません。
python-docs-samples/transcribe_async.py at master · GoogleCloudPlatform/python-docs-samples · GitHub
話を戻して、上記3番目の記事はエラー集。じつはこのサービス、一度うまく行った後にもいくつかハマりどころが待っているのですが、そういう「理解したと思ってたのになぜかコケてる・・」みたいなときにこの記事がとても役立ちました。
最後の記事では、WAV形式の音声ファイルを使う場合の方法が説明されています。ネット上の解説記事ではFLACというファイル形式を前提にしたものが大半なので、どうしてもWAVを使いたいという場合にはそちらを参考にするとよいと思います。
音声ファイルを作る
では、ここから具体的な作業について記していきます。
最初に作るのは、今回文字起こしをする音声ファイルです。すぐ上にも書いたとおり、このサービスではmp3やm4aなどではなく、FLACという形式の音声ファイルを使いたいのですが、一般的には、音源をFLAC形式で管理したりはしてないですよね・・少なくともぼくはしてないです。
ということで、ここではmp3などのFLAC以外のファイル形式からFLACに変換し、またその他のいくつか必要な変換操作も一緒にやっておきます。
まず変換前の音声ファイルですが、今回は今年の3月にYAPC::Okinawaで登壇したときの内容の再現動画(Link)から、終盤の数分だけをmp3形式で抜き出しておきました。
次に、このファイルを変換するために、無料の音声編集ソフトウェアであるAudacityを立ち上げます。
Audacityについては以下の記事で利用方法等を解説していますので、よろしければどうぞ。
Audacityを使った操作は、以下の3つです。
- サンプリングレートを44,100から16,000にする。
- ステレオならモノラルにする。
- FLACファイルとして書き出す。
サンプリングレートの変更
まず、サンプリングレートを変えます。と言ってもこれは一瞬で、左下のプルダウンで切り替えるだけです。
ここから・・
こんな感じで。
ステレオをモノラルに
次に、ステレオをモノラルにします。上記の画像を見ると、ひとつのウィンドウに2本の波が並行して走っていますが、これがステレオであることを示しています。
逆に言うと、最初からこれが1本だけならこの作業は不要(すでにモノラル)です。
ではやってみましょう。ステレオ音声をモノラルにするには、まず当該音声の枠内を適当にクリックして、
そうすると上部メニューバーの「トラック」にある「ステレオからモノラルへ」という選択肢がアクティブになるので、そいつをクリック。
すると・・モノラルになります。
Google Cloud Platformにアカウント登録
音源ができたので、次はテキストへの変換作業をするための作業場を用意します。
舞台となるのは、Google Cloud Platform(以下「GCP」)というGoogleさんのサービスです。その中に、今回使用するCloud Speech APIという道具が置いてあり、これを有料で使うことができます。
有料と言っても、GCPに登録した段階で3万円分のクレジット(クーポンみたいなもの)をもらえるので、それを使い切るまでは無料です。(ただし、たしか使い切る前に1年過ぎたら無効になったと思います。記憶だけで書いていますが)
GCPの利用を開始するには、Googleアカウントとクレジットカードの情報が必要です。これは主に身元確認のために必要だそうで、その辺も含めて、登録まわりの方法については、ぼくはすべて以下の書籍を見ながらクリアしていきました。
プログラマのためのGoogle Cloud Platform入門 サービスの全体像からクラウドネイティブアプリケーション構築まで
- 作者: 阿佐志保,中井悦司
- 出版社/メーカー: 翔泳社
- 発売日: 2017/06/02
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
同書はプログラミングの初心者・・よりはちょっと知識のある、しかしおそらくIT企業の新入社員(または学生)ぐらいの技術レベルに合わせて書かれたような感じで、ちょうどぼくのレベルにフィットするわかりやすい本でした。
今回の記事ではそこまで踏み込んで解説しないので(それもやったら1ヶ月ぐらいの連載になりそう)、詳しいアカウント作成方法については同書やネット検索で解消してください。
新規プロジェクトを作成
アカウントを作ったら、新規のプロジェクトを作ります。
ちなみに、ぼくも普段使っているプロジェクトをここでそのまま紹介するのはちょっと気をつかうので、この記事のために新たなプロジェクトを作ります。
まずはダッシュボードに行って、検索窓で「リソースの管理」を探します。*2
「リソースの管理」ページに行ったら、「+プロジェクトを作成」をクリック。
プロジェクト名を入れます。
ここで一点注意ですが、「プロジェクト名」を入力すると、それに応じた「プロジェクトID」も生成されます。しかし、その「プロジェクトID」は世界で1つだけの(一意の)文字列である必要があり、つまり「MyProject」みたいなコテコテのIDは今さら取れるはずもなく、そのようにすでにIDとして取得されている文字列を「プロジェクト名」として入力した場合には、自動的に「MyProject-192876」みたいなID候補が生成されて、「プロジェクトIDはこれでいいよな? 」みたいに言われます。
「プロジェクト名」の方は一意である必要はなく、なんでも好きなもので良いので、もしIDが「MyProject-192876」とかでも良ければ、気にせずプロジェクト名を「MyProject」にしておけばいいのですが、個人的にはこの「プロジェクト名」と「プロジェクトID」がズレると結構混乱するので(とくに使い始めの頃は)、ぼくの場合はプロジェクト名を付ける段階でグローバルに一意の文字列になるようにしています。
ということで、今回は「note103-speech-sample」としました。左下の作成ボタンを押すと・・
はい、できました。当該プロジェクトをクリックして、その中に入りましょう。
(ちなみに、ひとつ上にあるプロジェクト「note103-speech」は普段使っているものなので無視してください)
音声ファイルをアップロードする
では次。先ほど作ったFLACファイルをGCPにアップします。具体的には、GCPのクラウドストレージに専用バケットを作って、その中にアップロードしていきます。
まずは検索窓に「storage」と入れて・・Cloud Storageが見つかるので、そこに飛びます。
「バケットを作成」をクリック。
バケット名を登録します。これも先ほどのプロジェクトIDと同様、一意にする必要があるようです。(今のところカブる名前を試してないので、憶測ですが)
ここではバケット名を「note103-bucket-sample」として、ストレージクラスは「Multi-Regional」、場所は「アジア」にします。(ストレージクラスと場所の設定は上記のGCP本で使用していた設定に合わせています)
作成と同時にバケットの中に移動するので、アップロードボタンから先ほどのFLACファイルをアップします。
速攻で完了しました。バケット内に対象のファイルが入っています。
APIの有効化 & サービスアカウントキーの作成
次に、本サービスで利用するCloud Speech APIの有効化と、サービスアカウントキーの作成という作業を行います。が、これについては前掲のQiita記事に詳しい説明があるので、そちらをご参照ください。
ぼくもそれを見てやったのと、それ以上にうまく説明できるわけでもなさそうなのと、なにより同じことをここでくり返しても人類の損失なので・・。*3
なお、サービスアカウントキーを作る際の「役割」という項目について、そちらの記事ではとくに言及されていませんが、未設定のままだと怒られたので、ぼくの方では「Project/オーナー」としました。
Cloud Shell にJSONファイルをアップロード
上記の手続きどおりにサービスアカウントキーを作成すると、自動的にJSONファイルがローカルにダウンロードされます。
今度は、そのJSONファイルをCloud ShellというGCP上の作業環境にアップロードします。面倒な作業が続いていますが、そろそろ佳境というか、案外ゴールはもうすぐです。
Cloud Shellは、GCPの画面のどこにいても大抵開けるようです。たとえば、ダッシュボードからだとこの辺にボタンがあるので・・
クリックすると、以下のように画面の下半分にシェル(ターミナル)が出てきます。で、このままここで作業してもいいのですが、個人的にはちょっと画面が狭くて、見通しの悪さが疲れを誘発するので、別画面に展開してしまいます。その場合は、右上のポップアップボタンをクリックします。
展開できました。広々〜。
ちなみに、このシェル環境はプロジェクトごとではなく、アカウントごとに割り当てられているようです。つまり、複数プロジェクトをまたいで、同じシェル(というかOSというか)を使えるわけですね。
これは非常にありがたいことで、たとえば、今回は踏み込まないですが、.bashrcや.vimrcのような設定環境を複数プロジェクトで共通して使えるということです。
そういう環境の違いというのはじわじわと作業効率に影響を及ぼすもので、たとえば素のVimを使わざるをえなかったり、それがイヤで毎回プロジェクトを作るたびに.vimrcをアップしたりといった手間がなくなるだけでもとても助かります。
話を戻して、次は先ほどのJSONファイルをアップロードします。といってもこれはポチポチクリックしていくだけで、とくにコマンドを打ち込んだりする必要はありません。
まずシェルの右上にあるプルダウンボタンから、「ファイルをアップロード」を選択。
先ほどダウンロードしたJSONファイルを選択。「開く」で、アップされます。
そのまま、環境変数「GOOGLE_APPLICATION_CREDENTIALS」にJSONファイルのデータを設定します。
$ export GOOGLE_APPLICATION_CREDENTIALS=[ダウンロードしたJSONファイル].json
認証まわりについては以上です。
Pythonファイルの準備
では、いよいよ準備の大詰め、命令を実行するためのPythonのコード&環境を用意します。
まず、今回使用するPythonのコードですが、冒頭で紹介したQiita記事に掲載されていたものをほぼそのまま使います。ぼくは出力用のファイル名に関するところだけ微調整して、具体的には以下のようにしています。(ファイル名は「transcribe.py」)
これを先ほどのJSONと同様の方法でアップロードしてもいいですし、あるいはShell上でVimなどを開いて直接コピペしてもよいと思います。
ちなみに、19行目にコメントアウト行が入っていますが、その行末にある「LINEAR16」というのがWAVファイルを使うときの記述です。もし対象の音声ファイルをWAVにしたい場合には、FLACを指定した18行目をコメントアウトして、19行目の方を使います。
さて、このPythonコードをホームディレクトリに置いて ls を叩くと、こんな感じになります。
先ほどのJSONファイル(左端)と、今アップしたPythonコード(右端)がどちらも入っています。
(ちなみに、ここに見えるtmpというディレクトリは普段ぼくがCloud Shell上で使っているデータ類をこの解説のために一旦仮置きしている場所です。今回の作業とは関係ありませんので見なかったことにしてください)
最後に、Pythonを実行するためのライブラリをインストールします。
$ sudo pip install google-cloud-speech
はい。ということで、長い道のりでしたが、これでひとわたりの準備は完了です。いよいよ実行に移ります。
実行
実行の際には、以下のコマンドをCloud Shellに打ち込みます。
$ python transcribe.py gs://note103-bucket-sample/Sample-for-transcript-Cloud-Speech-API.flac
「gs://」以右の部分は、先ほどFLACファイルをアップしたバケット内の場所を示しています。
ちなみに、今回はわかりやすさを優先して音声ファイルの名前を長〜くしていますが、普段はもっと短いファイル名にして、このコマンドも短く済むようにしています。(「sample-01.flac」とか)
では、動かしてみましょう。処理時間がわかりやすいように、動画で撮っておきました。(大半は止まったままですが)
はい。大体50秒弱ぐらいで終わってますね。元の音声が2分45秒ですから、3分の1ぐらいの時間で完了していることになります。ちなみに、これは元の音声ファイルが長くなってもほぼ同じぐらいの割合で、60分ぐらいの音声なら20分程度で処理が終わります。(2018年7月時点)
では、仕上がったテキストファイルをダウンロードしましょう。今回のPythonコードでは、書き出したファイル名の頭に「output」というキーワードが付くようにしてあります。(上記のGistで30行目)
また、Cloud Shellからファイルをダウンロードするにはdlコマンドを使用するので、以下のようにすれば必要なファイルをローカルに落とすことができます。*4
$ dl output*
すると、このようなダイアログが出てくるので、「ダウンロード」をクリック。
これで、ファイルが手元にダウンロードされます。
結果と講評
では、お待ちかねの出力結果です。この処理はぼくも今回のために初めて動かしたので、どうなっているのかまったく想像がついていません。ドキドキ・・
以下、出力結果をそのままコピペします。改行位置などもそのままです。
ということで前最後のスライドはんですけどもも簡単にまとめますとですねもう色んな活用例をですねご紹介してきたんですけどもないことがあったのかなということちょっと最後にお出しします一つはですねそのまま年表音かあるいはそのエクセルのね作業力で6列いつもより下の階2列ですお金はそういう風に単純作業は行ったとも自分がやんなくてもいいよねっていうことはその機会に行ってもらうみたいな音ことでしょうから単純作業は減るってのはそうとよく言われることだと思うんですけど個人的にはの本質的だなと思っての実はこの2番手ですね自分専用の仕事道具を作る仕事の道具ってのはその専門的になればなるほどそうな自分だけのローカルな道具みたいのが必要になったりあるいはそれがあることによって効率が合体すると思うんですけど
そういうのですねあのプログラミングをすることによってその自分でこうカスタマイズして行けるって言うかその汎用品じゃない山用品誰でも使えるものっていうのはちょっと薄く広くと言うかスネ浅く広くと言うかは誰でも使えるだけに今そこそこしか便利じゃないんだけど自分だけに便利でも他の人は何か便利かどうかも分からんみたいなやつはめちゃくちゃ高効率が上がるみたいなことがあるんでその自分に合わせた道具を作っていくってことがですねできる仲間さっきのとこそそそねえっと IDE の環境そうですけど今ちょっと一瞬またでもに戻りますけどこれとかね
こういうのはその僕が濃いの欲しいなと思って作ってるわけでも誰かが作ってくれたってよりは誰かが作ったのかを組み合わせて声のやってるわけですね
だから他の人にこれが便利かわかんないしもっと便利なのがあるかもしんないですけども僕だけに便利ぐらいのものが作ることによっては非常に効率が上がってるということでその自分のための道具を自分で作るっていうことができるのがま相当いいところなんじゃないかなということですね今これを踏む発表できたのは良かったんじゃないかなと思ってますけど最後にですねまあその楽しみが増えたら楽しくなりたくてもやったことなんでまぁ結果的にそれも多少は多少と言うかかなりという花ですね実現できたかなと思っております
はい。どうでしょうか。マルやテンがないので読みづらいですが、それでも所々に改行が入っているので、一切改行がなかったGoogleドキュメントのときよりは読みやすくなっています。
ちなみに、この改行はどういう法則で生じているのかというと、2分45秒の音声ファイルのうち、ちょうど1分と2分あたり、なおかつ話がふっと途切れたところでちゃんと改行されてるんですね〜。いや、これはすごい。
Googleドキュメントの場合は、ただひたすら1文になってダラダラ起こされていくだけなので、これだけでもかなり使いやすい(編集しやすい)テキストになっていると思います。
それから、上でも少し書いたとおり、この処理にかかった時間は元の音声ファイルの時間の約3分の1です。これについても、Googleドキュメントの音声入力を使った場合はまったく同時間が必要ですから(といってもリアルタイムに入力する前提の機能なので当たり前&そもそも比べる性質のことではないかもしれないですが)、その意味でもより便利になっていると感じます。
さらに、これも非常に重要な点ですが、Googleドキュメントで音声ファイルから文字起こしをする場合は、稼働中に別のアプリケーションを使おうとすると入力が止まってしまいます。
しかし、このCloud Speech-to-Textでは、処理が終わるのを待っている間に別のアプリケーションでどんな作業をしていてもまったく問題ありません。この「別の作業をしながら並行して自動文字起こしができる(勝手にやってくれる)」というのは、考えてみるとぼくが最初にGoogleドキュメントとSoundflowerを組み合わせたときからずっと夢見ていた状況で、もしかするとその夢、ほとんどかなってるのでは・・? と思うほど素晴らしい状況です。
テキストの精度に関しては、こちらをお読みの方それぞれの評価があると思いますが、個人的には「ふえー、ここまで出来るようになったのか、すごいな・・」というのが素朴な感想です。
もちろん、このままではまったく仕上がりとは言えませんし、ここから直していくのもそれなりに大変だとは思いますが、とはいえ、2年前に初めてGoogleドキュメントでこれを試したときに比べたら格段に良くなっていると思いますし、今後もここから悪くなることはないでしょうから、基本的には好印象を持っています。
ハマりどころ
本記事は一応、ある程度全体のフローを理解してからまとめたものですから、それなりにスムーズに、かつ望ましい結果が出ていますが、実際に試しているときはそれはもうエラーの連続でした。
エラーへの対処に関しては、初めの方に参考文献として挙げた記事群がほぼ網羅してくれていますが、個人的にポイントになりそうなところを簡単にまとめておきます。
といっても、大半は次の1点に集約されると思うのですが、それはCloud Shellのセッションが一度切れると、上記で設定した環境変数や、インストールしたライブラリがリセットされてしまうということです。
通常、ローカルの環境でそんなことは起きませんから、当然、一度設定した環境変数やインストールしたライブラリはそのまま維持されるという前提で作業をするわけですが、Cloud Shellはそうではないので、日をおいてログインしたときや、同日中でもしばらく時間が空いてセッションが切れた後だったりすると(たしか1時間未使用とか)、「さっき上手くいったはずのコマンド」がもう効かなくなって、エラーが出てしまいます。
よって、そういうときには落ち着いて、上記の
$ export GOOGLE_APPLICATION_CREDENTIALS=[ダウンロードしたJSONファイル].json
や、
$ sudo pip install google-cloud-speech
を再入力してあげましょう。大抵はそれで直ると思います。
料金
さて、初めの方にも書いたとおり、このツールは基本的に有料です。ただし、アカウント登録時にもらえるクレジットとはべつに、毎月1時間分までは無料です。よって、それほど大量にやるわけではない、という人は無料のままでも長期的に使えるかもしれません。
とはいえ個人的には、現時点での料金もけっして高いものとは思いません。具体的な価格については以下で説明されていますが、
https://cloud.google.com/speech-to-text/pricing
機能 | 0~60 分 | 60 分超、100 万分まで |
音声認識(動画を除くすべてのモデル) | 無料 | $0.006 米ドル / 15 秒 |
前述のとおり60分までは無料で、そこから先は最大100万分まで「$0.006 米ドル / 15 秒」とのこと。1ドル112円として、1分単位で換算すると、「0.024米ドル*112円=2.688円」ということで、1分につき2.688円、1時間なら162円、2時間で323円ほどです。
これがしかも、60分のファイルなら20分の処理時間でこのレベルまで起こされるわけですから、手動で膨大な時間と体力を注ぎながら必死に起こしていくことに比べれば、やはりお手頃かな〜・・と。
録音時の注意点(より正確に起こすために)
一連の手順についてはひとまず以上ですが、ここで一点、大事な知見を共有したいと思います。
上記のサンプルはそこそこ綺麗に起こすことができましたが(と個人的には思っていますが)、音声ファイルによっては、まったく駄目な場合もあります。
そして、その違いが生じる一番の原因は、おそらく録音時に吹き込み用のマイクを使っているかどうかだと思っています。
ここで言う「吹き込み用のマイク」とは、べつに何万円もするような本格的なものである必要はなく、たとえばぼくは3千円ぐらいのヘッドセット(ヘッドホンにマイクが付いてるやつ)を使って録音していますが、そういうのでも充分です。(上のサンプル音声もそれで録りました)
もちろん、仕事で使うようなスタンド付きのマイクでも良いでしょうし、ハンドマイクやピンマイクから採った音でも大丈夫だと思います。
これらに共通するのは、「マイクが口元から音を拾う」ということで、逆に言うと、たとえばICレコーダーをテーブルに置きっぱなしにして録音したインタビューとか、ビデオカメラに付属しているマイクで録った音声とか、そういう「周りの音ごと全部拾った音声」だと、綺麗にテキスト化されないケースが多いと感じます。
この音質については、冒頭に挙げた参考記事のうち、以下でも言及がありました。
曰く、
精度に関係しないもの
- マイクの感度
- 話すスピード
- ノイズ
精度に関係するもの
- 話者の話し方(明瞭かどうか)
- 部屋の反響
とのこと。興味深いですね。ICレコーダーやビデオカメラのマイクが駄目なのは、「部屋の反響」と関係しているのでしょうか。
一応、公式ページにも音質に関する言及があります。
曰く、
ノイズ低減
- 雑音の多い音声も正常に処理できます。ノイズ除去の必要はありません。
とのこと。ただ、これはちょっとわかりづらいですね。「雑音」や「ノイズ」の定義が今ひとつ・・。
いずれにせよ、経験的には、ヘッドセットなどの吹き込み用マイクで録音した音声ファイルであれば、そうではないボワーッとした音声に比べてずっと綺麗にテキスト化されます。
ちなみに、ぼくが使っているヘッドセットは以下です。
サンワサプライ USBヘッドセット/ヘッドホン ホワイト MMZ-HSUSB10W
- 出版社/メーカー: サンワサプライ
- 発売日: 2014/01/29
- メディア: Personal Computers
- この商品を含むブログを見る
この商品を選んだのは、日本のTech系ポッドキャストの草分けとも言える*5 Rebuild の@miyagawa さんのブログで紹介されていたからで、
(今見たら2017年版は日本語だったのでそちらも・・)
それからまる2年使っていますが、今もバリバリ現役で使えていて大変助かっています。
まとめ
ということで、例のごとく長文になりましたが、いかがでしたでしょうか。
Cloud Speech-to-Text、正直、多少のプログラミング知識なりターミナル操作の経験なりがないと実践するのは大変かなとも思いますが、大体こんな感じなのね、という全体像が伝わればひとまずよいかなと思っています。
あらためて要点だけ再掲すると、以前に紹介した、Googleドキュメントを使った場合に比べて挙げられるメリットは以下のような感じだと思います。
- 処理が走っている間に他の仕事をできる。
- 元の音声ファイルより短時間で処理が終わる。(現時点では3分の1ほど)
- 適宜改行が入る。(1分ごとに入る場合が多いが例外もありそう)
デメリットとしては、有料であること、それからくり返しになりますが、ある程度のプログラミングの素養が求められること、といったところでしょうか。
しかしそもそも、以前のGoogleドキュメント&Soundflowerによる文字起こしというのは、本来そのツールが想定している使い方からは少しズレたものだと思いますし*6、それに対してこのCloud Speech-to-Textの方はまさに文字起こしのために開発されているものですから、文字起こしをする用途であれば、こちらを利用する方が自然なのかなとも思います。
また、すでにこの音声認識エンジンを用いたWebサービスなどもあるようですから*7、プログラミングに馴染みがない人はそういったサービスを通してこの機能を利用するのもひとつの方法だと思いますし、逆にプログラマーの人であれば、ぼく以上にこの便利さを実感できるかもしれません。
(了)
*1:ファイルの一部だけを書き出したい場合は、その部分をAudacity内で範囲指定した上で「選択したオーディオの書き出し」にする。
*2:プロジェクトの作成方法はいろいろあると思いますが、ここではその一例を示します。
*3:しかしこういう分担をできるのがWeb記事のいいところですね。書籍でやったら各所から怒られる気がします。
*4:もちろん直接対象のファイル名を指定しても同じですが、手間が減るので自分ではこのようにしています。
*5:実際には「モダシンラジオ」やdrikinさんの一連の番組や長谷川恭久さんの「Automagic Podcast」などの先例もありますが、その後のフォロワーが続発したきっかけは「Rebuild」かな、という意味で。
*6:おそらくGoogleドキュメントの方はリアルタイム入力を前提にデザインされてるので。
*7:自分では試したことがないのでとくに紹介しませんが。