2018年12月1日土曜日

ラーメン花月嵐の壺ニラという最強のつまみ

作り方を紹介します
と言っても cookpad さんで紹介されているレシピをパクっただけです
分量とか手順とか材料とか毎回忘れるので備忘録として残しておきます

材料

  • にんにくチューブ (できれば生にんにく)
  • ごま油
  • 一味唐辛子
  • 豆板醤 (チューブじゃなくても OK)
  • ウェイバー (他の中華風調味料でも OK、鶏ガラでも代用できるっぽい)

tsubonira1.jpg

ニラを切る

今回ニラは 3 束ほど使います
後で紹介する各種調味料の量は 3 束を目安に入れているので 1 束の場合は 1/3 してください
ニラは 1/4 で OK です
tsubonira2.jpg

もっと細かくしたい人は細かくしても OK です
揉むと水分が出て小さくなるので 1/4 くらいがオススメです
ちゃんと水洗いしてあげましょう
tsubonira3.jpg

塩もみ

先に塩もみを軽くしましょう
塩はスプーン 1 杯くらいで良いと思います
tsubonira4.jpg

先にやる理由はさっぱりわかりません
面倒くさい人は他の調味料と一緒に混ぜちゃって大丈夫だと思います
また混ぜるときはビニール手袋をすると気持ちよく混ぜられると思います
tsubonira5.jpg

各種調味料を入れていく

以下順番は関係ないです
また写真では毎回混ぜている感じですが先に調味料を全部入れてあとで一気に混ぜ合わせれば OK です

にんにくチューブです
自分はにんにくが好きなので結構多めに入れています
ちなみにあとでこれの倍くらい追加しています
量で言うとチューブの半分くらいは入れていたかもしれません
tsubonira6.jpg

ごま油です
スプーン 3 杯入れたのですが 2 杯くらいで良いと思います
自分はごま油少なめのほうが好きです
tsubonira7.jpg

味覇です
スプーンで適当にすくったのを 2 杯入れました (これも 1 杯でも良いかも)
味覇は固形になっているので混ぜるときにちゃんと崩してあげるようにしましょう
tsubonira8.jpg

一味唐辛子です
全体が見えなくなるくらい入れました
ここで辛さを調整できるので辛いのが好きな人はもっと入れていいと思います
自分はこのあとビン一本分全部入れました
tsubonira9.jpg

豆板醤です
こんくらいかなと
ここでも辛さを調整できます
中華っぽい辛さ?が好みな人は一味を減らして豆板醤多めにすると良いと思います
tsubonira10.jpg

混ぜる

まんべんなく混ざるようにしましょう
固形のやつは残らないように注意してください
tsubonira11.jpg

混ぜ終わったら上からラップを押し蓋的にします
tsubonira12.jpg

一日冷蔵庫で保存

一日おいたほうが味が馴染んでおいしくなると思います
自分は置くのをオススメします
また一日置くと水分がだいぶ出るので吸い取って上げると良いと思います

食す

おいしいです
食べ過ぎると胃もたれするのでほどほどに
tsubonira13.JPG

2018年11月26日月曜日

Podcast 音源の編集方法

概要

配信環境については記事をまとめましたが編集方法についてまとめていなかったのでまとめました
Apple 純正のソフトウェアだけで編集しています

2018/11/26 時点での配信環境についてはこちらに記載しています

環境

  • macOS 10.14.1
  • GarageBand 10.3.1
  • iMovie 10.1.10
  • iTunes 12.9.0.164

GarageBand でノーマライズする

ノーマライズとは「音量正規化」で適切な音量に変更します
毎回そうなのですが自分の声が大きくゲストの方の声が小さいので GarageBand の音量バーを左右に調整して同じような音量になるようにしています
podcast_sound_edit1.png

使っているマイクのせいもあるのですが、これが近距離でないと音をうまく拾ってくれません
自分はそれを意識してかなりマイクを近づけているのですがゲストの方はそうもいかないのでこんな感じなってしまいます
本来であれば LXR マイクなどを使ってハードウェアミキサで調整するのですがケチって USB コンデンサマイクを購入してしまったので、そんな感じになってしまいました

あとは対処法としてソフトウェアミキサを使う方法があるのですが音源がダメダメだと限界があるのでやはりマイクを変えないと何ともかなと思います

とりあえず現状は GarageBand の機能の範囲でノーマライズしています
また GarageBand はデフォルトだと音量バーの設定を無視して自動でノーマライズしてくれるので設定から自動ノーマライズの設定をオフにする必要があります
podcast_sound_edit2.png

GarageBand で mp3 に書き出し

共有 -> 曲をディスクに書き出すで mp3 出力します
podcast_sound_edit6.png

あとは書き出す際のオプションを選択します
音質は「低音質 (64kbps)」を選択します
最終的には AAC にして更に圧縮しますが Podcast の音源は 64kbps で十分です
podcast_sound_edit7.png

iMovie でホワイトノイズを削除する

出力した mp3 を元に次はホワイトノイズを削除します

自分の環境の場合ばっちりホワイトノイズが入ってしまうのでソフトウェアである程度削除しています
ノイズもハードウェアなど環境によってそもそも入らないようにすることもできるのでノイズ削除の作業は必須ではありません

ホワイトノイズの削除は「iMovie」を使います

右上のイコライザタグを選択し「背景ノイズを軽減」にチェックします
あとはパーセンテージを選択するだけです
基本は 50% でやっています
podcast_sound_edit3.png

iMovie で mp3 で書き出し

背景ノイズを削除した版を mp3 で書き出します
右上の共有ボタンから「ファイル」を選択します
podcast_sound_edit4.png

あとはメタ情報を編集して出力します
フォーマットは「オーディオのみ」にしています
podcast_sound_edit5.png

せっかく 64kbps のステレオサイズで出力したのですが iMovie の場合、動画形式して出力されてしまうのでサイズが大きくなるのはあきらめます

iTunes で AAC に圧縮する

大きくなったファイルを iTunes を使って AAC に変換します

まず「環境設定」->「一般」->「読み込み設定」から AAC で書き出す場合のフォーマットを選択します
podcast_sound_edit8.png

iMovie で出力した mp3 を iTunes にドラッグアンドドロップして開いてファイルを選択します
そして「ファイル」から「変換」->「AAC バージョンを作成」で AAC 版が作成されます
podcast_sound_edit9.png

これで iTunes の所定のパスに AAC バージョンのファイルが書き出されるので必要に応じてコピーなどすれば OK です
パスは書き出された AAC 版のファイルを右クリックして「曲の情報」を選択すれば確認できます

ここで出力された AAC ファイルが現在公開している音源ファイルの最終版になります

最後に

かなり面倒くさいやり方ですがこんな感じでやっています
なぜこんな面倒くさい方法になっているかというとホワイトノイズを削除したいためにこうなっています
録音環境が良ければこんなことは不要です
GarageBand でチャネルごとに収録してノーマライズすれば完了です

来年は環境整えてやりたいなーという思いも込めて残しておきます

2018年11月20日火曜日

QBハウスガチャ

QB ハウスという 1000 円カットをご存知だろうか
ぼくは大好きだ




だいたい四半期に一度通うので年 4 回ほど利用させていただいている
年 4 回通っても 4,000 円で済むのである (正確には 4,320 円)
1,000円カットと言いつつ現在は 1,080 円になっている
更に来年の増税で 1,100 円になるとのこと
まぁそれはどうでも良いことなのだが

簡単に QB ハウスの仕組みを説明しておくとカット専門のヘアサロンで約 10 分で注文通りのヘアカットをしてくれる
値段と時間の割にクオリティも高く時間のない現代人にとっては最高のヘアサロンなのではないかと思っている
おそらくターゲット層も帰宅や外出中のサラリーマンを想定しており設置されているのも駅構内などが多く短い時間で気軽に通える感じになっている
料金の精算は券売機システムとなっており場所によっては Suica or Pasmo などの電子マネーでの精算も可能となっている

そんな QB ハウスに通い続けている自分であるが注文の仕方はいつも一緒で

1/3 残して 2/3 切ってください、耳は出して OK で、刈り上げ無しで」

とお願いするようにしている
後半の「耳は出して OK で、刈り上げ無しでお願いします」は決まり文句のようなもので、これを言わないと QB の店員さんに「耳は出しますか?」「刈り上げはしますか?」と聞かれるのであらかじめ答えておく感じである

で問題は前半の「1/3 残して 2/3切ってください」の部分である
ここがタイトルの「ガチャ」要素で人によってだいぶ長さが変わるのである
(QB ハウスは確かカットする人の指定も可能だがその人が出勤しているかまではわからないし指定すると待ちになる可能性が高いのかそのシステムを使っている人はみたことがないし自分も使ったことはない)

まぁ人によって差が出てしまうのは仕方ないことなので良いのだがどんな人が長く残しがちでどんな人が短くしてくれるのか勝手に分析してみた
ちなみに自分の意図としてはバッサリ切ってほしいので短ければ短いほど良いと思っている (それならいっそ坊主やスポーツ刈りにすれば良い話ではあるが)

長く残しがちな店員さん

  • 慎重そうな人
  • 切る前に霧吹き+クシで髪をとかしてから切ってくれる人
  • 女性の店員さんに多いイメージ

短くしてくれる店員さん

  • カットが早い人
  • 迷いがない人
  • 特にクシでとかすこともなくいきなりカットに入る人
  • ベテラン感のある男性店員さんに多いイメージ

といった分析結果だ
完全に独断と偏見なので参考程度に見ていただきたい
これも予想だが長めに切る人は短くしすぎて何か言われる可能性を考慮してとりあえず安牌ラインで少し長く残しているように感じる
QB ハウスの場合最後に鏡で後ろも確認して「こんな感じで良いですか?」と聞かれるのでそこで「あーもう少し短めに」とかお願いすればいいのだが自分は小心者なので言えない

あと正直あの鏡の確認だと本当に良い感じになっているかわからない
帰宅してお風呂で髪を洗ってみて鏡で見て触って初めて「あ、ちょっと長いわー」とか「あ、いい長さだわ」とわかる気がする (と自分は思っているがどうでしょうか?)
なのでガチャ結果はお風呂に入った後でないとわからないのが正直なところだ
(もしかすると見た目ではわからない微妙な誤差を勝手に自分の中でアタリだハズレだとか決めつけているだけで他の人からみればいつも通り髪を切っただけにしか見えないのかもしれないが)

あとは本当にたまに散切り頭になっている場合もある
「あれここだけ切り過ぎじゃー、、」みたいなのがたまにだがある
(が、まぁそんな細かいことはどうでもいいのだ、短くなればそれでいい、あとはワックスで何とかすればいいじゃないかということだ)

結局何が言いたかったのかというと「これからも QB ハウスを使いますのでよろしくお願いします」ということだ
QB ハウス最高です

2018年11月3日土曜日

ホームページを自動デプロイできるようにしてみました

概要

久しぶりのテックネタの投稿です
自分のホームページ https://kakakikikeke.com は Ruby で書かれており docker コンテナとして動作しています
https に対応しているのですが内部で nginx コンテナも動いておりそこで SSL を受け付けています

デプロイは git push 後にホストマシンに SSH ログインして docker-compose build -> up という王道の流れなのですがいちいち SSH ログインするのが面倒でした
まぁコマンドも 2, 3 ほどなのでそこまで面倒な作業でもないのですが今回はそのデプロイ作業を自動化してみました

仕組みとしては bitbucket の webhook 機能を使ってホストマシンで webhook を受け取るアプリを起動します
そして、そのアプリに今まで実行していたデプロイコマンドを実行してもらうという何のひねりもない仕組みです

環境

  • CentOS 7.5
  • docker 18.06.1-ce
  • Ruby 2.5.0p0
  • bitbucket

bitbucket webhook にエンドポイントを追加する

まずは webhook にエンドポイントを追加します
homepage_autodeploy1.png

各リポジトリごとにエンドポイントを追加できます
今回はホストマシンでデプロイ用のアプリも動かします
Sinatra を使うので 9292 ポートに対して webhook を投げてもらうようにエンドポイントを追加します
/webhook にしていますがここは好きなものに変更してもらって OK です

スクショだと Enable request history collection にチェックがありませんがどんな webhook が飛んだかあとから確認したい場合はここにチェックを入れておくと履歴が確認できます

IP を許可

bitbucket のホワイトリスト IP は以下の通りです
ファイアウォールなどに設定の許可を入れましょう

  • 104.192.136.0/21
  • 34.198.203.127
  • 34.198.178.64
  • 34.198.32.85

今回の場合であれば 9292 ポートへのアクセスだけを許可すれば OK です

ライブラリインストール

ではアプリを作っていきます

  • bundle init
  • vim Gemfile
gem "sinatra"
  • bundle install --path vendor

webhook 用のアプリ

  • vim config.rb
require './app'
run Webhook
  • vim app.rb
require 'sinatra'
require 'json'
require 'open3'

class Webhook < Sinatra::Base
  helpers do
    def deploy
      File.open("./deploy.txt", mode = "r"){ |f|
        f.each_line{ |line|
          o, e, s = Open3.capture3(line)
          halt 500, "missed: #{e}" unless s.success?
        }
      }
    end
  end
  post '/webhook' do
    body = JSON.parse request.body.read
    p body
    body['push']['changes'].each { |push|
      deploy if push.has_key? 'new'
    }
    'deployed'
  end
end
  • vim deploy.txt
cd /root/ruby-homepage && git pull
cd /root/ruby-homepage && docker-compose down
cd /root/ruby-homepage && docker rmi rubyhomepage_web
cd /root/ruby-homepage && docker-compose up -d

少し解説

特に解説は不要かなと思いますが一応

まず POST /webhook が bitbucket から送られてくる webhook を受け取る URI になります
ここは bitbucket に設定したエンドポイントと同じ URI にしてください
ボディに push 時のいろいろな情報が格納されてきます
コミットした人やコミット番号などがあります
詳しくは上記のリンクからサンプルリクエストなどが確認できるます

今回は特に条件はないですが、new という新規のコミットがある場合にデプロイを実行するようにしました
new がないケースとしてはブランチを削除した場合になります
デプロイ時の条件を厳密にしたい場合はここに条件を加えれば OK です

deploy は helpers を使って実現しています
デプロイコマンドを書き連ねた deploy.txt を読み込み open3 で逐一実行してるだけです
open3 であればコマンドの結果 (0 とか 127 とか) をチェックできるので、もし成功じゃない場合は halt でエラーを返却します

クソ簡単です

アプリ起動

  • bundle exec rackup config.ru -o 0.0.0.0 &

外部から受付できるように 0.0.0.0 で LISTEN します
また、バックグラウンドで動作させるようにします
tmux バッファ上でフォアグラウンドで動作させても良いと思います
もっとちゃんとやるならデーモン化させたり systemd 配下で動かすようにしても良いと思います
停止するときはプロセス番号を調べて kill してください

という感じで開発自体は完了です
あとは push して挙動を確認したりしてみてください

デメリット

今回の場合、直接ホストに対してコマンドを実行するのでコンテナで動かすとコンテナ内にコマンドを実行してしまいます
なのでホストマシンに ruby + bundler をインストールしなければいけません
これまですべて docker で動かしていた環境にいきなり謎の勢力のためにバイナリをインストールしなければいけないのは納得いかない点があるかなと思います

また git pull をするときに認証されないことを想定しています
git-credential を使ってホストマシンに認証情報を保存していることが前提になっています (もしくは .git/config に ID/PW が書かれていても OK)

代替策

今回は webhook + コマンドにしましたが他にもいろいろな方法があると思います
例えば Bitbucket Pipeline を使う方法です
ここにコマンドを記載できるので push 後にホストに SSH してコマンドを実行することでデプロイすることも可能です
これであれば web アプリを作る必要もありません

あとはどうしても webhook 用のアプリをコンテナで動かしたい場合はコンテナからホストに SSH ログインしてコマンドを実行するか sidekiq などを使ってコンテナからホストにデプロイの支持を渡してそこからホスト側の worker でデプロイするなどでしょうか
ただ、これもコンポーネントが 1 つ増えるので微妙です

エージェントを配置してエージェントに指示を送る方法でもいいですが、今回の webhook アプリ方式とあまり変わらないかなと思います

そもそもイメージをお腹に抱えてしまっているのでそれもあまりよくない気がします
docker build -> docker push でどこかのレポジトリにアップロードして、ホストマシン側では pull -> up だけする感じのほうが良いかなと思います
ただ、その場合でも結局ホストマシン側でコマンドを実行する仕組みは必要かなと思います 

k8s の Deployment と ReplicaSet を使えばローリングアップデートが使えるのでそれも手かもしれません
ただその場合は k8s 環境の構築から必要になりますが、、

今回の方法はリポジトリからの push 型なのでそうでなくホストマシンからの pull 型で良い感じに簡単にできる仕組みにすると良いのかなと思います
やはりコマンドをホストマシンで直接実行するのは何か微妙なやり方なような気がします

むしろ何か良い代替策があれば教えていただきたいです

参考サイト

2018年10月31日水曜日

NEOGEO mini を持っているなら Mayflash f300 も買おう

実は NEO GEO mini を持っています
公式からずっと出なかったアーケードコントローラですが Mayflash から NEO GEO mini 対応のアーケードコントローラが出ました

早速購入して使ってみたので使い方とか紹介します

購入したもの

まず f300 ですがこれです


Mayflash ジョイスティック F300 PS4/PS3/XBOX ONE/XBOX 360/PC/Android/Nintendo Switch/Neogeo mini対応 [日本正規品]

9,000 円くらいで購入しました
見ての通り NEOGEO mini にも対応しています
現在 Amazon で購入できるものはファームウェアのバージョンが v1.2 となっており、それであれば特に何もせず NEOGEO mini で使えます

もしすでに f300 を持っている場合でもファームウェアのアップデートをするだけで使えるようになるとかならないとか

あとは USB TypeA -> TypeC の変換器も購入しました
NEOGEO mini 側の端子が TypeC で f300 側の端子が TypeA なので変換が必須です

700 円くらいで購入しました
変換器に関しては何でも OK です
ただ一点注意が必要なのは NEOGEO mini 側の TypeC の端子がやや狭い点です
変換器の端子の部分が太いと接続できない可能性があるので注意してください
上記で紹介している自分が購入した変換器はギリギリ入りました

接続した様子

こんな感じです
neogeomini_with_mayflash1.jpg

f300 のケーブルの長さは 3m もあります

設定

f300 の左上にトグルスイッチ的なのがあります
これをいじって NEOGEO mini で動作するようにします
neogeomini_with_mayflash2.jpg

一番左は下の「DINPUT/PS3」にします
その隣は「DPAD」にします

これで OK です

動作確認

あとは接続してプレイするだけです
問題なく動作すると思います

スタート+セレクトでメニューセレクトにもいけます

最後に

NEOGEO mini は公式のパッドもありますがやはりアーケードコントローラでプレイするのがしっくり来ます
しかも NEOGEO mini に収録されているソフトに格闘ゲームが多いのでアーケードコントローラの方がやりやすいと思います

また f300 は NEOGEO mini 以外にも PC や PS4、任天堂スイッチにも対応しているのでそれらのハードでも使いまわしできます

ただ結構出費が痛いです

  • NEOGEO mini 本体・・・約 12,000 円
  • Mayflash f300・・・約 9,000 円
  • TypeA -> TypeC・・・約 700 円

合計 21,700 円なり
2 万円あれば別のハードを購入することもできるかなと、、
自分は KOF がアケコンでやりたかったので後悔してないです

2018年10月20日土曜日

エピソードの検索機能をレベルアップしました

これまでのエピソード検索機能は画面に見ている情報だけを使って検索していました
https://kakakikikeke.com/podcast
podcast_new_search1.png

仕組みとしては jQuery の filter を使っているだけなので DOM 内で情報を絞り込みしている感じです

さすがにこれだと検索対象の情報量が少ないので検索機能をレベルアップしてみました

新しい検索機能

https://kakakikikeke.com/mypage/search
で新しい検索機能なのですが「サポータ専用の機能」として提供しています
「おい!使えんのかい」という感じですが、まだ何もサポータ専用コンテンツがなかったのでちょうどいいかなと思いサポータ専用にしてみました

上記 URL にアクセスすると Patreon のログイン画面になるのでログインします
podcast_new_search2.png

そして OAuth のアクセス許可の画面になるので「Allow」を選択します
(画像は開発用の画面なので実際の文言とは多少異なります)
podcast_new_search3.png

すると検索画面になるのでここで好きなキーワードを入力して検索しましょう
podcast_new_search4.png

検索対象

これまでは DOM に表示されている情報だけでしたが今回の新しい検索機能は以下の情報を検索対象にしています

  • タイトル
  • 概要
  • Show note
  • 文字起こししたテキスト情報

先頭 3 つはもともと情報としては持っていたものですが今回は新たに文字起こしの情報を作成しました
具体的には Google Cloud Speech API を使って各エピソードの音声情報を文字に起こしています
それを検索対象とすることで Show note にも書かれれていない内容を検索することができます

やってみた所感

正直 Google Cloud Speech API の精度があまり良くないです
原因は不明ですが音質などが影響しているかもしれません
また検索方法も表記ゆれや AND/OR 検索などには対応しておらず単純な match による検索になります
なので正直微妙です

検索の仕組みとしては Google Cloud Speech API で得られるテキストファイルをただ検索しているだけなのでテキストファイルをブラッシュアップすれば精度はあがります
まだエピソードも少ないので今後エピソードが増えてから使ってみると便利な機能に化けている可能性はありそうです

文字起こしするタイミングもどうするか悩んでいます
いつも収録後に編集する作業があるのですが、今回の検索機能を入れたせいで文字起こしの作業も必要になってしまいました
これを編集作業にプラスして毎回やるとなると結構辛いです
(しかも Google Cloud Speech API も有料というものあります、、)
ちなみに今回の作業でかかった料金は $24.86 でした
podcast_new_search5.png

もしかするとエピソードを公開するタイミングと同時に文字起こしはせず、ある程度溜めてから文字起こしするかもしれません
まぁその辺りは気分でやりたいと思います

最後に

検索機能をレベルアップしてみたのでサポータの方は使ってみてください
サポータになっても良いですよという方は以下からよろしくお願いします
https://kakakikikeke.com/supporter

まだ検索機能しか専用コンテンツがないので今後も何か増やしていこうかなと思います

2018年10月19日金曜日

Podcast の音源を Google Speech API で文字起こししてみた

概要

現在 Podcast の検索はこのページ内の単語だけを対象に検索することができます
さすがにそれだと検索性が悪すぎるかなーと思い音声情報を文字起こししてそこからエピソードを検索できたらいいなと思いました
ということで Google Speech API を使って文字起こししてみました
なお今回の作業内容はお金が発生するので同じことをするのであれば承知の上作業してください (と行っても数円もかからないですが)

環境

  • macOS 10.14
  • gcloud 220.0.0

flac への変換

自分の podcast は m4a で配信しているのでそれを一旦 flac に変換します
変換してくれる便利なサイトがあるので今回はこれを使わせていただきます
https://online-audio-converter.com/ja/

今回はエピソード14 (Youtube Superchat Ads) の音源を使って文字起こししています

P.S ffmpeg でもできます

  • ffmpeg -i ep14.m4a -f flac ep14.flac

gcloud コマンドのインストール

  • brew cask install google-cloud-sdk

bq, docker-credential-gcloud, gcloud, git-credential-gcloud.sh, gsutil がインストールされます

  • gcloud init

で初期化します
ブラウザが立ち上がり OAuth の認証画面になるので自分の Google アカウントでログインしましょう
あとは使用するプロジェクトやデフォルトリージョンなどを設定します

  • gcloud info

でいろいろと情報を確認できます
詳しい手順はこちらが参考になると思います

文字起こししてみる

  • gcloud ml speech recognize-long-running 'gs://podcast-episodes/ep14.flac' --language-code=ja-JP --async

これで OK です
文章が 1 分以上を越える場合は非同期音声認識を使ったほうが良いみたいです

また音声が何語で話されているのか --language-code で指定する必要があります
日本語も普通に対応していました
サポートしている言語はかなり多いようです

リクエストすると OPERATION_ID が取得できるのでそれを使って進捗を確認することができます

{
  "name": "4268235842997122372"
}
  • gcloud ml speech operations describe 4268235842997122372
{
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.speech.v1.LongRunningRecognizeMetadata",
    "lastUpdateTime": "2018-10-16T03:31:31.157254Z",
    "progressPercent": 5,
    "startTime": "2018-10-16T03:30:28.318655Z"
  },
  "name": "4268235842997122372"
}

progressPercent が 100 になれば完了です

INVALID_ARGUMENT: Request payload size exceeds the limit: 10485760 bytes. 対策

ローカルからファイルをアップロードしてファイルを解析する場合は 10MB 以内でないとダメなようです
その場合はファイルをクラウドストレージに事前にアップロードしてそれを解析するように指定します

今回のファイルサイズは 385329211 bytes あったので全然オーバーしていました
なので Google Cloud Storage にバケットを作成してそこに音声データをアップロードしておきました
バケットは Nearline あたりでいいかなと思います

ちなみに Regionalus-west1 を選択すれば Always free の範囲であれば無料で使えます

INVALID_ARGUMENT: Invalid audio channel count

残念なことに Cloud Speech API はモノラル音源にしか対応していません
kakakikikeke's Podcast はステレオ音源なのでモノラルに変換しました

自分の場合は iTunes で行いました

  • 環境設定 -> 一般 -> 読み込み設定

で設定からカスタムを選択しチャネルを「モノラル」にすれば OK です
podcast_transcript1.png

あとは mp3 音源を選択し AAC で書き出せばモノラルになっています

結果を確認する

  • gcloud ml speech operations describe 4268235842997122372

でテキストが返ってきます
今回のように 60 分を越える音声の場合レスポンスの JSON もかなり長いです

一部抜粋ですが結果は unicode で送られてきます

{
  "alternatives": [
    {
      "confidence": 0.94057757,
      "transcript": "\u3061\u3087\u3063\u3068\u98a8\u90aa\u6c17\u5473\u306a\u3093\u3060\u3093\u307e\u58f0\u304c\u51fa\u306a\u3044\u304b\u3082\u3057\u3093\u306a\u3044\u3042\u306e\u6885\u539f\u5927\u543e\u3063\u3066\u77e5\u3063\u3066\u307e\u3059\u6885\u539f\u5927\u543e\u3055\u3093\u3066\u8ab0\u3067\u3059\u304b\u77e5\u3089\u306a\u3044\u3067\u3059\u304b\u3042\u306e\u30d7\u30ed\u30b2\u30fc\u30de\u30fc\u30d7\u30ed\u683c\u95d8\u5bb6\u30b2\u30fc\u30e0\u30b9\u30c8\u30ea\u30fc\u30c8\u30d5\u30a1\u30a4\u30bf\u30fc\u3068\u304b\u8a00\u3063\u3066\u308b\u3051\u3069\u77e5\u3089\u306a\u3044\u304b\u805e\u3044\u305f\u3053\u3068\u306a\u3044\u3088\u3046\u306a\u81ea\u5206\u7d50\u69cb\u597d\u304d\u3067\u306a\u3093\u304b\u5148\u306b\u30b9\u30dd\u30fc\u30c4\u3068\u304b\u3084\u3063\u3066\u308b\u3088\u306d\u306f\u3044\u306a\u3093\u304b\u3042\u306e\u95a2\u4fc2\u3067\u3042\u306e\u95a2\u4fc2\u3067\u306e\u304a\u83d3\u5b50\u3067\u3059\u672c\u5f53\u306b\u305d\u306e\u30d1\u30a4\u30aa\u30cb\u30a2\u7684\u5b58\u5728\u306e\u4eba\u3067\u30b2\u30fc\u30e0\u3067\u672c\u5f53\u306b\u304a\u91d1\u7a3c\u3044\u3067\u8cde\u91d1\u307f\u305f\u3044\u3067\u3059\u304b\u9577\u3044\u3067\u6709\u540d\u306a\u3084\u3064\u3060\u3068"
    }
  ]
}

Web 上でコンバートしてくれるサービスなどがあるのでそれに投げちゃうのが早いと思います
ちなみに上記の unicode を変換すると以下のようになりました

{
  "alternatives": [
    {
      "confidence": 0.94057757,
      "transcript": "ちょっと風邪気味なんだんま声が出ないかもしんないあの梅原大吾って知ってます梅原大吾さんて誰ですか知らなかあのプロゲーマープロ格闘家ゲームストリートファイターとか言ってるけど知らないか聞いたことないような自分結構好きでなんか先にツとかやってるよねはいなんかあの関係であの関係でのお菓子です本当にそのパイオニア的存在の人でゲームで本当にお金稼いで賞金みたか長いで有名なやつだと"
    }
  ]
}

うーん、何とも絶妙な感じですね、、、
感覚的には confidence が 1.0 から 0.9 の間で更に分解能がある感じで 097 くらいいかないと精度は高くないなーといった印象です

どうやってエピソードを検索するか

やり方はいろいろとあると思います

  • 形態素解析などをして単語に分割し単語検索させる
  • 文章を結合して MySQL などに突っ込んで LIKE 検索させる
  • 検索エンジン (Solr) などを使う

検索機能をどこまで提供するかかなと思います
AND 検索や OR 検索までやりたいのであればデータベースに使うのは必然ですし高速な全文検索をするのであれば検索エンジンを使うでしょう

自分の場合とりあえずある単語を含むエピソードを検索できればいいかなーと思ったのでそのままファイルをメモリ上に展開し正規表現で検索しようかなと思います

require 'json'

def check(keyword)
  json_data = open('./log_jp') do |io|
    JSON.load(io)
  end
  json_data['response']['results'].each { |ret|
    ret['alternatives'].each { |alt|
      return true unless alt['transcript'].match(/#{keyword}/i).nil?
    }
  }
  return false
end

1 エピソード分でしか試してないですが速度も申し分なかったです
これの主なデメリットとしては複雑な検索ができない点ですが、まぁ十分かなと思います
エピソードが増えるとファイルが増えるので検索速度は落ちますが、そこは問題になったら別の仕組みを検討しようと思います

とりあえずこの方法でエピソードを検索できるようにしてみようと思います

おまけ: 今回の作業でおいくらかかったか

今回お金が発生するのは Google Cloud Storage のデータ料金と 60 分以上の音声データを解析した分の料金になります
後日請求が確定したのでコンソール画面で確認したら $0.4 でした
podcast_transcript2.png

podcast_transcript3.png

これまでの全 14 エピソードを文字起こしすると $0.4 * 14 = $5.6 なので激安ですね、、、
それでもお金掛けたくない場合は 60 分未満は無料なので無理やり分割すれば無料でいけるかと思います (Cloud Storage 代はかかると思いますが)

最後に

Podcast の音源を文字起こししてみました
Google Speech API は料金もかなりお安いのでこれで全話文字起こししてみようかなと思います
あとはこのテキスト情報を元に検索できる機能でも実装してみようかなと思います
もしかしたらサポータ限定プログラムにしちゃうかもしれませんが、、
https://kakakikikeke.com/supporter