本ブログエントリは IBM Cloud Advent Calendar 2019 に参加しています。12/03 ぶんのネタです。経緯を紹介する導入部分がちと長めですが、お付き合いください。

あまり公に宣伝したりしてなかったのですが、以前に「空耳アワー・マシーン」を作ったことがありました。「空耳アワー」はテレビ番組「タモリ倶楽部」の人気ミニコーナーのあれです。　「外国語で歌われた歌詞が日本語だとこう言っているように聞こえる・・・」という空耳にフィーチャーした紹介コーナーです。ちょっとググってみただけで多くの傑作作品動画が見つかります：



この空耳は、曲に合わせて歌われる外国語の歌詞の中で、「日本語だとこう聞こえる」という特徴ある部分を見つけることで成立しています。ふと「・・・これって自動化できるんじゃないか？」と閃いたのが「空耳アワー・マシーン」誕生のきっかけでした。いわゆる "Speech to Text"（音声のテキスト化）機能を使い、外国語の歌唱部分を（その言語ではなく）強制的に日本語でテキスト化する、というロジックです。実装にあたっては IBM Cloud から提供されているWatson Speech to Text API を採用しました。ちなみに Watson Speech to Text はライトプランと呼ばれるプランで利用する場合であれば、各種カスタマイズを行うことはできませんが、毎月 500 分ぶんの音声データ変換までは無料で利用することができます（2019年11月現在）。

実装したソースコード（Node.js 用）はこちらで公開しています：
https://github.com/dotnsf/soramimi




ソースコードを git clone するかダウンロードして、settings.js 内で Watson Speech to Text API 用の API キーを指定すると実際にウェブブラウザで動かすことができるようになります。


ウェブブラウザを起動してアプリケーションにアクセスすると、最初にブラウザがマイクの使用許可を求めてくるので「許可」します：



画面を下の方にスクロールすると「どの言語でテキスト化するか」を選択するボックスがあります。「空耳アワー」の場合ここは日本語固定ですが、機能としてはここで指定する別言語でも認識→テキスト化を行うこともできるようになっています：



言語を指定したらマイクを持った人のアイコン部分を１回クリックして、枠が赤になる（録音モードになる）ことを確認します。枠が赤になっている間に英語の歌をマイクから「歌ってください」（笑）。歌い終わったらもう一度人のアイコンをクリックします。枠は水色に戻り、録音モードも解除されます：



録音モードからモードが解除されると同時に、録音された内容が Watson Speech to Text API に渡され、「日本語でどう聞こえたか？」の結果が表示されます：




一応、動くには動いています（よね？）。このアプリではマイクを使ってその場で録音した音データを使って日本語テキスト化を行っていますが、理屈の上ではこの入力を外国曲の MP3 データなどに切り替えればいいはず・・・と考えていました。

・・・が、いざそのように使ってみると、仕組みとしては動くのですが、期待していたほどの精度では認識してくれませんでした。もともと Speech to Text 機能は「喋った内容のテキスト化」に最適化されたものであって、「歌った内容のテキスト化」ではないという違いに加えて、「BGMによるノイズ」の影響が多分にあるように感じられました。要するに曲の中で楽器で演奏される部分が Speech to Text 的にはノイズとなってしまい、思っていたほどの精度でテキスト化できなくなっているようだったのでした。　まあネタとしてはある程度使えるが、正しくテキスト化できる箇所が少なすぎて実用（？）にはほど遠い、というものになってしまったのでした。これも公開を控えていた理由の１つでもあります：



さて、長い導入部分が終わりました。ここまでが「空耳アワー・マシーン」を「作ってみた」という話で、ここからが本エントリのタイトルでもある「改良してみた」部分です。最近、音楽ストリーミング事業を展開している Deezer 社から spleeter というものすっごいライブラリが公開されました：

無料で曲からボーカルが抜ける音楽素材分離エンジン「Spleeter」公開



この spleeter は TensorFlow を用いた機械学習によって音源からボーカルやドラム、ベースといったパーツを抜き出して分離することができるようになる、というオープンソースなライブラリです。音楽ストリーミング事業を展開している Deezer 社の立場を最大限活用し、大量のサンプリングデータを所有している状態で機械学習を行うことができ、その成果をオープンソース化して公開していただいたことになります。ウェブ上のパフォーマンスや精度に関する評判もよいものばかりという印象です。

この spleeter を使うことで上述の空耳アワー・マシーンの BGM ノイズ問題を解決できるのではないか、と考えました。BGM が Speech to Text のノイズとなっていた問題に対して、spleeter で曲データからボーカルデータだけを抜き出しておいて、そのボーカルデータに対して Speech to Text を実行することでノイズのない音声データからのテキスト化が実現できるのではないか！？　と考え、これも実装してみました：



この機能を実装するためには、あらかじめサーバー上に spleeter を導入しておく必要があります。そして spleeter をインストールする際にはパッケージ管理ツールである conda が必要になります。というわけでまずは conda （今回は簡易版の miniconda）を導入します。このページから自分のシステム環境にあった miniconda のインストーラーを選択してダウンロードし、実行して導入します：

（↑画面は Linux 版 Miniconda のダウンロードリンクを選択する箇所）

miniconda 導入後に spleeter を導入します。コードは github で公開されているので、以下の手順を実行します：

$ git clone https://github.com/deezer/spleeter

$ conda env create -f spleeter/conda/spleeter-cpu.yaml

これで spleeter の導入が完了しました。spleeter を利用するにはまず以下のコマンドで spleeter をアクティベートし、・・： 

$ conda activate spleeter-cpu

続けて spleeter をテスト実行します。spleeter フォルダの中にサンプルの mp3 ファイル（spleeter/audio_example.mp3）があるので、これを使って実行してみます。今回はボーカルとそれ以外（2stems）に分割し、実行結果を output フォルダ以下に作成する、というオプションを指定して実行してみました：

$ spleeter separate -i spleeter/audio_example.mp3 -p spleeter:2stems -o output

成功すると ./output/audio_example/ というフォルダ（フォルダ名はファイル名から生成される）が作成され、その中に vocals.wav と accompaniment.wav という２つのファイルが生成されています。vocals.wav がボーカルだけを抜き出したもの、accompaniment.wav がボーカルを抜き出した残りの音源です：



実際に audio_example.mp3（元の曲）と、vocals.wav（ボーカルのみ） / accompaniment.wav（ボーカル以外）を聴き比べてみるとわかるのですが、信じられないくらいキレイにボーカルが分離されています。これが無料でできるとは驚き！

・audio_example.mp3（元の曲）
・vocals.wav（ボーカルのみ）
・accompaniment.wav（ボーカル以外）



そしてこれを上述の空耳アワー・マシーンに組み込んでブラウザから実行できるように改良してみました。この拡張機能は上述のソースコードにも含まれているので、こちらの機能を試す場合はアプリケーション実行後に /spleeter.html にアクセスすると、mp3 の音楽ファイルを指定して実行することができます（結果は out/ フォルダ内に作成されます）：


そして実行してみましたが・・・　想定外だったのは処理時間でした。例えば５分程度の曲を対象にした場合、これまでは単に Watson Speech to Text を実行するだけで、その処理時間が１分を超えるようなことはなかったのですが、spleeter でのボーカル抜き出し処理だけで５分前後かかるようになりました（ちなみに自分の PC のスペックは i5-8350 の８コアCPUでメモリは 8GB）。これは処理内容を考えるとかなり高速な処理であるとは思いますが、これまでと比べると、１曲単位での処理にかなり長い時間がかかるようになった、という印象です。　またその長い処理の間、CPU やメモリはほぼフル稼働となります。仮にネット上から利用できるサービスとして作ろうとすると、かなり高いスペックのサーバーインスタンスを用意する必要があることに加え、タイムアウトとの戦いも意識して実装する必要がある、という印象を持っています。　といった背景もあって、現時点ではバッチでまとめて処理して後から結果を確認する、という方向での実装が中心です。


一方、この処理によって得られた結果は spleeter で分離する前とは比較にならないほど良質でした。Watson Speech to Text API は日本語としてある程度の確信度をもって認識出来なかった部分は結果に含まれない（つまり正しく認識できた部分のみが結果として得られる）のですが、分離前は「あー」とか「うー」とかいうコーラス部分を除くとほんの数箇所だけが識別できていたのですが、分離後の結果のサイズは数倍になりました。つまりボーカルだけを対象とすることで識別可能な音声が数倍になった、ということになります。なお上述の vocals.wav （ボーカルのみ抜き出したオーディオデータ）を Speech to Text で変換した結果は以下になりました：

{
  "status": true,
  "results": [
    {
      "alternatives": [
        {
          "timestamps": [
            [
              "令和",
              2.37,
              2.77
            ],
            [
              "ＯＳＳ",
              2.77,
              3.77
            ],
            [
              "は",
              3.77,
              3.88
            ],
            [
              "萌え",
              5.96,
              6.25
            ]
          ],
          "confidence": 0.38,
          "transcript": "令和 ＯＳＳ は 萌え "
        },
        {
          "transcript": "令和 ＯＳＳ は 親 "
        },
        {
          "transcript": "映画 を ＳＮＳ は 萌え "
        }
      ],
      "final": true
    }
  ]
}

↑確信度は 0.38 とあまり高くありませんが、データの 2.37 秒から 6.25 秒部分が赤字のように聞こえた、という結果です。


「本当に空耳アワーでそのまま即採用されるレベルの空耳が検出できるか？」という観点においては残念ながら難しそうな印象を持っています。特に Watson はエロネタは不得意っぽい（？）のか、結果にエロなワードは皆無でした。まあこのあたりは有料版の Watson Speech to Text でカスタマイズすると変わってくるのかもしれませんが・・・　ただそのまま採用されるようなレベルでの検出はできなかったとはいえ、ここで検出された結果をヒントにそれっぽいワードを混ぜて改良すればもしや・・・　という期待は充分に持てる結果になりました。一ヶ月に 500 分、１曲５分とすれば一ヶ月で約 100 曲ほど無料で空耳を調査できることになります。あのTシャツを狙って・・・はまだ遠い夢かもしれませんが、（個人的に欲しい）耳かきあたりは狙えるんじゃないか・・・と期待が膨らむ結果となりました。

タグ ：

#speechtotext

#ibm

#watson

#spleeter

#soramimi

#cloud

#tensorflow

先日、IBM Watson のサービスが IAM （Identification & Access Management）およびリソースグループに対応した、というニュースがありました：
IBM Watson AI のサービスについて、IAM およびリソースグループが有効に


この対応により、IBM Watson API を使うサービスの認証方式が変更になります。現行の（この変更前に作ったものの）方式は 2019/10/31 まで有効ですが、それ以降は認証エラーになってしまいます。また 2018/11/01 以降に作成した Watson サービスインスタンスは新しい認証方式でないと接続できなくなっています。

要は Watson サービスを使って今動いているアプリケーションは１年以内にこの新しい認証／認可の方式に対応させる必要があり、また新しく作るアプリケーションに関しては新しい認証／認可方式を使って作成する必要がある、ということになります。この「Watson の新しい認証／認可方式を使ってアプリを作成」するための手順を紹介します。

【新しい認証／認可方式に対応した Watson サービスのインスタンス化】
まず、新しい認証／認可方式に対応した Watson サービスを用意する必要があります。今回は比較的多く使われていると思われる画像認識機能 Visual Recognition API を使って紹介しますが、基本的には全てのサービスで同様の方法を実装することになります。

2018/11/07 時点で、IBM Cloud 内で新しく Visual Recognition サービスを作成すると、新しい認証／認可方式に対応したインスタンスとなります。というわけで IBM Cloud にログインし、リソースの作成にて「AI」カテゴリの Visual Recognition を選択します：



インスタンスの属性を選択します。以前はここで「ロケーション」に加え「組織」や「スペース」を選択していたのですが、新しいインスタンスではロケーションとリソースグループ（default のままで大丈夫です）を選択します：



下にスクロールしてサービスのプランを選択します（下図では無料版の Lite を選択しています）。最後に右下の「作成」ボタンでインスタンスを作成します：



作成したインスタンスの画面がこちらです。この画面で API Key と URL が確認できます（API Key は当初マスキング処理されています）：



クレデンシャル情報を表示させることで一時的に API Key を確認することができます。新しい認証／認可方式ではこの API Key を使ってサービス API を利用することになります：




【新しい認証／認可方式に対応したアプリケーション】
次に、アプリケーション側をこの新しいサービスインスタンスに対応した形で作り直します。今回は Node.js と Watson Developer Cloud SDK を使う前提でアプリケーションを作る想定で以下を記述します。

新しい認証方式の Visual Recognition では以下のようなコードで認証し、インスタンスオブジェクトを作成します：

//. test01.js
var fs = require( 'fs' );

//. https://www.npmjs.com/package/watson-developer-cloud
var vr_v3 = require( 'watson-developer-cloud/visual-recognition/v3' );

var vr = new vr_v3({
  url: "https://gateway.watsonplatform.net/visual-recognition/api",
  version: '2018-03-19',
  iam_apikey: "（上記で取得した API Key）"
});

var filename = 'sample.png';
if( process.argv.length >= 3 ){
  filename = process.argv[2];
}

var params = {
  images_file: fs.createReadStream( filename )
};

vr.classify( params, function( err, result ){
  if( err ){
    console.log( err );
  }else{
    console.log( JSON.stringify( result, null, 2 ) );
  }
});

青字部分は API Key を取得した時に同時に表示されていた URL の値を url に指定しています。また赤字部分は取得した API Key 文字列を iam_apikey に指定しています。この形でインスタンスオブジェクト（上記コードだと vr 変数）を作成する必要がある、という点がこれまでと異なります。

なお、上記コードで作っているコマンドアプリ（test01.js）は

$ node test01 （画像ファイル名）

という形で指定して実行することを想定しています。（画像ファイル名）部分に画像認識を実行する画像のファイルパスを指定します（無指定の場合は同じフォルダにある sample.png に対して実行します）。

今回はいらすとや様の、この画像を sample.png として用意しました：



この画像に対して実行してみます。まず Watson Developer Cloud SDK を導入します：

$ npm install watson-developer-cloud

そして実行（実行結果は緑字）：

$ node test01

{
  "images": [
    {
      "classifiers": [
        {
          "classifier_id": "default",
          "name": "default",
          "classes": [
            {
              "class": "first-aid kit",
              "score": 0.879,
              "type_hierarchy": "/kit of things/first-aid kit"
            },
            {
              "class": "kit of things",
              "score": 0.879
            },
            {
              "class": "dado (dice)",
              "score": 0.5
            },
            {
              "class": "figure",
              "score": 0.79
            },
            {
              "class": "jade green color",
              "score": 0.77
            },
            {
              "class": "emerald color",
              "score": 0.511
            }
          ]
        }
      ],
      "image": "sample.png"
    }
  ],
  "images_processed": 1,
  "custom_classes": 0
}

（結果はともかく）新しい認証／認可方式のコードで実行できました！

タグ ：

#ibm

#cloud

#watson

#iam

#apikey

IBM ワトソン対応の CMS である BlueCMS を公開しました。IBM Cloud を使ったセットアップ手順はこちらをご覧ください：
ワトソン対応の IBM Cloud 向き CMS "BlueCMS" を公開しました（セットアップ手順）


今回は初期セットアップ後の、実際の使い方を紹介します。


コンテンツタイトル等

初期セットアップの中で管理者権限を持った最初のユーザーを作っているので、このユーザーの ID とパスワードでログインします：



管理コンソール画面が表示されます。管理コンソールにはコンテンツタイトルなどコンテンツ全体に関係する設定項目に続き、現在までに登録されている文書の一覧テーブルと、添付ファイルの一覧テーブルが表示されますが、ログインユーザーが管理者権限を持っている場合はコンテンツの設定項目の下にユーザー一覧テーブルも表示されます：

（↑上からコンテンツ設定、ユーザー一覧）


（↑上から文書一覧、添付ファイル一覧）

コンテンツ設定は以下のようになっています：



これらは OGP(Open Graph Protocol) と言われる設定項目になっており、有名どころでは facebook で BlueCMS のトップページや各記事を共有した場合に表示される内容を定義します。

また title と desc は BlueCMS トップ画面の jumbotron の中で表示される内容でもあります。自分のブログのタイトルとその説明を記述するようにしてください。url はブログの URL、image_url は OGP イメージ画像の URL を指定します（指定していない場合は無視します）。

なお、現時点（2018/Jul/12）では個別ページの OGP を設定する機能がなく、個別ページをシェアするとトップページと同じ OGP が表示されます（リンク先の URL だけは個別ページになります）。この辺りは今後の機能拡張で対応したいと思っています。


ユーザー追加／管理

管理者権限を持ったユーザーはユーザー一覧テーブルで登録済みユーザーの一覧を確認したり、編集したり、削除したり、新規にユーザーを追加することができます：



新規作成は一番下の編集行の各フィールドに入力して "update"、既存ユーザーの変更は右にある "edit" をクリックすると編集行に値がコピーされるので、ここで変更して "update"、ユーザーの削除は右にある "delete" をクリックします。

なおユーザー編集時には role の値に注意してください。この値が 0 のユーザーは管理者、1 のユーザーは編集者として扱われます。name は画面表示用の名称で、email はメールアドレスですが、これらは現時点では特に利用していません。


文書追加／管理

管理コンソールには現在までに登録されている文書の一覧も表示されます：



新規作成は一番下の編集行の各フィールドに入力して "update"、既存文書の変更は右にある "edit" をクリックすると編集行に値がコピーされるので、ここで変更して "update"、文書の削除は右にある "delete" をクリックします。

なお文書の status は 1 のものが公開、0 のものは非公開（ドラフト）となります。body は nicEdit を使ったリッチテキスト編集が可能です。category はカテゴリー文字列を直接指定して入力します（category と body の値は IBM ワトソン連携時に利用する値となります）。

body の入力が狭い nicEdit を使っている点が不便であると理解しています。この辺りも今後も機能拡張の対象と考えています。


添付ファイル追加／管理

管理コンソールには現在までに登録されている添付の一覧も表示されます：



添付ファイルの新規作成はファイルを選択後、一番下の編集行の name フィールドに入力して "update"、添付ファイルの削除は右にある "delete" をクリックします。添付ファイルには編集機能はありません。


ワトソン連携

セットアップ時に IBM ワトソンの NLC(Natural Language Classifier) 連携も含めて行っている場合は、BlueCMS 内のコンテンツを NLC に学習させたり、学習結果を使って問い合わせを行うことができます：



文書一覧の下に NLC 関連のボタンが３つあります。それぞれ以下のように使います：

- "update NLC" : 現在までに BlueCMS に格納された全文書を NLC のトレーニングデータとして学習を初期化＆再学習します。学習時には各文書の body 値と category 値だけを取り出して、body 値の内容を category 値として学習します。これを全ての文書に対して行います。

- "NLC status" : 上記学習命令を発生した後の、ワトソンのトレーニングステータスを確認します。この実行結果が "Available" となれば学習準備は完了していて、後述の "classify" で問い合わせが可能になります。一方、実行結果が "Training" であればまだ学習中なので、いましばらくお待ち下さい。

- "classify" : 学習が済んだ後に問い合わせを実行します。具体的には編集行の body に何か文章を入力した後にこのボタンをクリックすると、上述で学習させたコーパスに対してこの body 内容を問い合わせ、「今までの学習データから、どのカテゴリーがふさわしいか」の結果を取得し、category フィールドを更新します。いわば「ワトソンがその内容に相応しいカテゴリーを自動的に決めてくれる」機能です。


現時点での制限事項等

このブログエントリを編集している 2018/Jul/12 時点での BlueCMS の機能と使い方を紹介しました。上述のように CMS として足りない機能や使いにくい部分も多くあり、ワードプレスなどと比較するとまだまだだと思っています。

一方で新しくスクラッチで開発したからこそできた挑戦的な機能もあります。特に標準で IBM ワトソンと連動する機能については BlueCMS の特徴の１つだと思っています。

自分でも少しずつ使っていきながら感じた機能を拡張させていく予定ですが、もしお試し程度でも使ってみていただける場合は、感想や希望を伝えていただければと思っています。

タグ ：

#ibm

#cloud

#cloudant

#bluecms

#cms

#watson

#nlc

#node.js

#nodejs