Audacity を利用して、音声のサーっていう雑音・ノイズを取り除く方法

ポッドキャストの録音などをした際に、後ろでサーッというノイズが入ることがあります。これを綺麗に削除する方法です。Garagebandで見つけられる方法というのは、喋っている時にはすべての音をだすけれども、喋っていない時、つまり一定以上の音量が出ていない時にはすべての音を消すという方法でした。これだと、ザーザー音が出たり消えたりして逆に聞きにくくなります。

今回紹介する方法は、雑音のみをサンプリングして、その雑音を全体から取り除くというものです。そのため、話しているときも話していないときも、一貫してノイズがないという状態にできます。

Audacity というMacでもWindowsでもLinuxでも動く音声編集ソフト

Audacityを利用します。Audacityの概要は、

Audacityプロジェクトは、WindowsやMac OS X、Linux、各種BSDで動作するフリーの音声ファイルエディタを開発するプロジェクトです。AudacityはWAVEやAIFF、MP3、oggといったフォーマットの読み書きに対応しており、音声ファイルのトリミングや音量調整、各種エフェクトの適用といった機能を備えています。

というものです。無料で利用することができます。

Audacity をダウンロードして開いたら、音声ファイルを開きましょう。次のステップは、

  1. ノイズのみのサンプリング
  2. ノイズのみの削除

という2段階になります。「選択」が戸惑うので以下のようにやってください。

1. 人が喋っておらずノイズのみがしている箇所を選択する

この図の上半分の色が濃いところ参照。
この図の上半分の色が濃いところ参照。

選択の仕方は、音の波が表示されているところをドラッグする感じです。

2. エフェクト > ノイズの除去

ノイズのみのエリアが選択されている状態で、エフェクト > ノイズの除去と進みます。

ここです。

3. ノイズプロファイルの取得を押す

そのまま押せば大丈夫。

押してください。押すと、特にメッセージがなくこのウィンドウが閉じますが、できてます。これがステップ1のサンプリングです。

4. 波形エリアを全選択

ここが分かりにくいのですが、ステップ2に進む際に、波形エリアを全選択します。コマンドAやコントロールAでできます。

5. もう一度メニューからエフェクト > ノイズの除去 と進み、OKボタンを押す

波形エリアを全選択した状態で、もう一度ノイズの除去ウィンドウを開きます。すると、右下のOKボタンをクリックできるようになっているので押します。dBや感度などを調整できますが、何もしないで押してだいたい綺麗にとれます。音がおかしくなったら以下を試します。

  • ノイズの除去(dB): おかしくならない範囲で大きくする。どのくらいの音の大きさでノイズを削除するかを指定する。値を大きくすると静かになるが、やりすぎると必要な音も消える。
  • 感度: おかしくならない範囲でできるだけ小さくする。 ノイズとして認識する程度を指定する。値を小さくしすぎるとロボットみたいなキリキリした音が混ざるようになります。
  • 周波数平滑化バンド: キリキリ音が出たときに軽減してくれるが、大きくしすぎると、人間の声がクリアじゃなくなることもある。

というわけで、一回目のノイズのみ選択がサンプリングで、二回目の全選択が除去を実施する範囲なのでした。

以上です。ポッドキャストの配信方法については、手軽なポッドキャスト配信方法。録音編集、iTunes登録、WordPress、リモートについて。 もご覧ください。

ノイズを消す方法の公式のマニュアル(英語)

↓ プラグインを作る方々への本、書きました。 ↓

OmegaT で Google Cloud Translation API を利用する方法(Macで)

OmegaTとは

OmegaT とは自由に使える(GPL)翻訳メモリツールです。

OmegaT の公式ウェブサイト。"自由に使える(GPL)"というタグラインが熱い!
OmegaT の公式ウェブサイト。”自由に使える(GPL)”というタグラインが熱い!

左側に原文と訳文のペア、右側に翻訳メモリからの参考訳文、用語集、各種選べる機械翻訳などが表示されているUIです。見た目は以下のような感じです。

OmegaT のUI。参考訳文が出てなくてすいません。

まだ使い始めたばかりなので勝手がわからないところもあるのですが、今回はこのOmegaTからGoogle翻訳のAPIへ原文を送り翻訳結果を得るための手順をまとめました。バージョンが進んでおり、現在のドキュメントの通りではなかったので、誰か探している人がいたらたどり着いてくれるとうれしいです。現在の環境は以下です。

  • Google Cloud Translation API: Ver. 2
  • OmegaT: Ver. 3.6.0

Google Cloud Translation API を使えるようにする

僕がなれていないからなのか、Google Cloud PlatformというGoogleのクラウドサービスのアカウント、認証、支払い、リソース確認など、利用全体を管理できる画面があるのですがここが難しかったです。

前提として、Googleのアカウントはあるというところから始めます。普段使っているもので大丈夫です。

まずは、IAMと管理のページへ行き、プロジェクトを作成します。

Google Cloud Platformでプロジェクトを作成する

次に、API Managerのダッシュボードに行き、”+APIを有効にする”というリンクをクリックします。

Google Cloud PlatformのAPI Manager。リンクがわかりづらい。
Google Cloud PlatformのAPI Manager。リンクがわかりづらい。

クリックするとAPIのリストが出ます。その中から検索窓を利用してGoogle Cloud Translation APIを選択します。そこで、タイトル(?)の右側にある”有効にする”というリンクをクリックします。

Google Cloud Translation APIを有効にする
Google Cloud Translation APIを有効にする

次に、左側のメニューに表示されている認証情報をクリックして、APIキーを作成します。

Google Cloud PlatformでAPIキーを作成する

はい。そうするとAPIキーが取得できます。

次に、支払情報を入力します。クレジットカードが必要です。翻訳APIの利用料金はここに詳細がありますが、百万文字で20ドルです。ちなみに今、60日間無料かつ3万円分くらいが無料になっています(1,500万文字まで無料!)。

お支払のページに行きます。そこで、先程作成したプロジェクトを選択すると支払いの登録などが可能になります。

OmegaTにAPIキーを登録する

上記の作業で取得してきたAPIキー(39桁くらい)を、OmegaTで使えるようにします。Macでは、OmegaTのアイコンを右クリックして「パッケージの内容を保存」から中身を見れる状態にして、設定ファイルを編集します。このためのGUIはありません。

問題は、ウェブサイトやソフトウェアに同梱されているマニュアルやドキュメントに書かれている情報だとバージョンに追随していないのでうまくいかないということでした。

/Applications/OmegaT.app/Contents/Resources/Configuration.propertiesを編集します。

OmegaTの設定ファイルで、さっきのKeyを登録する

Googleから取得してきたAPIキーは、上記のパスにあるファイルを編集し、上記画像の矢印の部分にコピペします。

すると!

こんな感じで訳文が返ってくる。

Google側もOmegaT側も大変苦労いたしました。みなさん、お楽しみください!

サポートについて

OmegaTについて質問がある方は礼儀正しく、Twitterでジャンさんに日本語か英語かフランス語で聞いてみましょう

ちなみに、男木島でお世話になっているジャンさんと範子さんが貢献者に!
男木島でお世話になっているジャンさんと範子さんが貢献者に!

↓ プラグインを作る方々への本、書きました。 ↓

シングルインストールのWordPressをマルチサイトの子サイトとしてインポート/マイグレーションする。

WordPress のシングルインストール(普通にインストールしてあったサイト)のコンテンツから何からをまとめてマルチサイトの子サイトとしてマイグレーションする方法。

普通のWordPressの移行の方法とほとんど同じで差があるところは、

  1. url が変わる
  2. uploads/ ディレクトリのパスが変わる( uploads/sites/site_id )になる
  3. users と usermeta がマルチサイトの親サイトに統合される

の3点です。

今回は、3点目は手動でなんとかすることにして、1, 2 をぱぱっとやる手順についてまとめます。example.jp というサイトを example.com/ja に移行するとすると以下のようになります。

  1. マルチサイトを用意して、子サイトを作る
  2. 子サイトのIDを把握する。以下、サイトIDは2だったとして進めます
  3. シングル側でDBをダンプする(wp_users, wp_usermeta はしない)
  4. ダンプしたDBに対して、以下の置換を行う
    1. example.jp -> example.com/ja
    2. /wp-content/uploads/ -> /wp-content/uploads/sites/2/
    3. `wp_ -> `wp_2_ (バックティックを含めると事故が少ない)
  5. themes/, plugins/ ディレクトリを移す
  6. uploads ディレクトリを wp-content/uploads/sites/2/ に移す
  7. マルチサイト側にインポートする

これでできます。作業中なので他にも何かあったら更新していきたいと思います。

コマンドで置換する

sed コマンドを使います。

cat ./prod-single-sub.sql \
 | sed -e 's/https:\/\/example.jp/http:\/\/example.com\/ja/g' \
 | sed -e 's/http:\/\/example.jp/http:\/\/example.com\/ja/g' \
 | sed -e 's/example.jp/example.com\/ja/g' \
 | sed -e 's/`wp_/`wp_2_/g' \
 | sed -e 's/\/wp-content\/uploads\//\/wp-content\/uploads\/sites\/2\//g' \
 > ./dev-multi-sub.sql

wp-cli で、特定のテーブルのみをエクスポートする

3の wp_users, wp_usermeta を排除するには、次のようにするとよいです。

wp db export prod-single-sub.sql --tables=wp_commentmeta,wp_comments,wp_links,wp_options,wp_postmeta,wp_posts,wp_term_relationships,wp_term_taxonomy,wp_termmeta,wp_terms

--tablesでどのテーブルを対象にするのかが決められるのですね。

↓ プラグインを作る方々への本、書きました。 ↓

AMPとかInstant Articlesってメディアやブログにとっては結構でかい意味があると思う。

AMP とか Instant Articles って何?それはメディアやウェブサイトを持つ人にどういう意味を持つの?WordPress とこれらの関係は?

最近のことですが、AMP や Instant Articles がちょっと話題になっていますね。

これって、技術的なことよりも、SEOがどうしたということよりも、こういうものが出てきたことは偶然ではなくて、今後のコンテンツパブリッシングの仕方が変わる兆しであって、必然なんじゃないかと思います。

ということで、AMP とか Instant Articles って何か?それがメディアやブロガーやウェブサイトを持つ人にどういう意味を持つのか、WordPress とこれらの関係は?ということについて、ちょっと書いてみました。

AMP とか Instant Articles って何?

そもそも、これってなんなのでしょうか、というところを簡単におさらいします。

AMP とは

まず AMP の字面は、Accelerated Mobile Pages の略で、「高速化されたモバイルページ」の意味ということでよいと思います。

Google とTwitter が立ち上げたオープンソースのプロジェクトだそうです。

ちゃんと見てないのでものすごくザックリですが、具体的には form や iframe などの表示に時間がかかったりブラウザに依存したりするものを排除した、簡易型の HTML を作っておいてください、と。

スタイルシートについても、リンクではなくて<head />内に書いてくださいね、と。HTML について以外にも、AMP JS や AMP CDN などスクリプトや CDN についての規格を決めているようです。詳しくは、amphtml/amp-html-format.md at master · ampproject/amphtml で仕様が読めます。

WordPress のサイトであれば、AMP — WordPress Plugins をインストールして対応することが可能です(が、まだいろいろと調整中のようなので、待つのがいいと思います)。

このサイトでも個別記事のURL の末尾に /amp を追加すると一応 AMP HTML が出力されます。

Instant Articles とは

Instant Articles は日本語では、インスタント記事というそうです。

インスタント記事をすべてのメディア媒体社へ4月より提供開始を発表

こちらは Facebook が作った仕様にのっとって、RSS のような専用 Feed を作ってね、ということのようです。

こちらについてもWordPress のプラグインの開発が進んでいるようで、 Automattic/facebook-instant-articles-wp で確認、インストールなどができます。このサイトでも有効化してみまして、ここをクリックすると、Feed 自体はどんなものなの?というのを確認できます。簡易版RSSみたいなイメージですかね。

AMP や Instant Articles を導入するとどうなるのか。

AMP ではスマートフォンで Google 検索をした際にプリロード(記事コンテンツの先読み)が発生して 、ユーザーがクリックするとコンテンツが即時表示(超速い)されます。また、Twitter ではどうなるのか、まだ確認できていませんが、多分、アプリなどでツイートの中にあるリンクをクリックしたら、サイトに飛ぶのではなくてプリロードされた AMP バージョンがアプリ内で表示されるだとか、Twitter Card の代替のようなことになるのではないかと思われます。

Google 検索で言うと、今までは、

  1. ユーザーが検索する
  2. 検索結果が表示される(タイトルとかディスクリプションとか)
  3. ユーザーがリンクをクリックする
  4. ユーザーは遷移する

という流れだったのが、今後は、

  1. ユーザーが検索する
  2. 検索結果が表示される(でかいサムネイルとかが出てる)
  3. AMP HTML が先読みされてブラウザでダウンロードされる(クリックする前に終わってる。軽いからできちゃう)
  4. ユーザーがリンク(これはリンクと呼べるのだろうか?)をクリックする
  5. ユーザーはすでにブラウザの中にあるコンテンツに飛ばされる
  6. なんなら、となりにあった検索結果にスワイプで移動できちゃったりする

という流れに変わります。

Instant Articles でも似たような感じで、今までは

  • タイムライン、フィードに流れてきたリンクをクリックしたら遷移してた

のが、

  • Facebook アプリの中に先読みされている記事がその場で表示されるだけ

みたいになる、ということのようです。動きはここの動画で見れます

検索や SNS とメディアの関係が逆転する?

さて、前置きが長くなりましたが、AMP や Instant Articles の概要を把握したところで、だからなんなの?というところについて。

要するに、サイト(メディア・ブログ・サイト)を持つということは各種プラットフォームへのパブリッシングセンターを整備することになりますよ、ということだと思います。

たとえば、メディアサイト。ニュースサイトでもアフィリエイトブログでもオウンドメディアでもなんでもいいんですけど、これまでの基本的な流れというのは、

  1. ウェブサイトを作る
  2. 広告を貼り付けたりお問い合わせフォームを作るだとかアプリのダウンロードリンクなどを設置しておく
  3. SEO 対策だとかバズるタイトルづくりだとかをする
  4. 検索やソーシャル経由でユーザーがやってくるのを待つ
  5. コンバージョンする

ということだったと思いますが、これがうまくいかなくなるんじゃないか、という気がします。今までよりもシンプルにそうはならないというか。

AMP も Instant Articles も、口を悪くしていうと、

こっちのプラットフォームにコンテンツを出しなさいよ、ユーザーは Facebook や Twitter のタイムライン/アプリ、Googleの検索結果からあんまり動きたくないんだから、そっちのほうがいいよね(ユーザーにとっては)オラオラ、こっちのプラットフォーム上でやっておくから、コンテンツだけ(文字だけ)送ってよ、そっちへのトラフィックはあげないけど。

という話なんですよね。

もちろん、AMP のフォーマットの中で広告や外部リンク(関連記事とか)を入れることはできますし、 Instant Articles でも広告が表示されて FB とコンテンツ供給者が広告(規格決まってるっぽい)で上がったお金を山分けというようなことはあるようですけど、メディア側に人が来ないです。

回遊性を高めよう!とか、Facebook の Like をしてもらおう!とか、RSS登録(古いかな・・)してもらおう!とか、今までよりも難しくなります。

この記事では AMP と Instant Articles の話に絞っていますが、Smart News への配信規格とか、Yahoo! News への配信規格とか、まあこれまでもありましたし、これからももっといろんな規格が出てくるのかもしれませんね。

数年単位の話で言えば、モバイルサイト、モバイルアプリだけではなくて、時計やらメガネやら何らかの空中でふわふわしているようなディスプレイやら脳に直送やら、なんでもいいのですけど、そういう各種メディアやデバイス(脳はデバイスじゃないけど)に対して適切な形でコンテンツを送り込むセンターとしてのウェブサイトを持とう、という話に移行していくのかもしれませんね。

この話は、昨年の WordCamp Tokyo 2015Human Made の哲学者 Noel Tock さんがしていた、 “Content Publishing in 2016” というセッションがズバリ言い当てていると思います。

このセッションでは、Instagram における National Geographic 社の取り組みなどを事例に、各プラットフォームで活躍して存在感を示すようなやり方に、パブリッシングの本質が移行していくんじゃないか、という話をしています。

(Noel Tock さんの予言に興味がある人は 2016 年の WordPress — Medium という僕の訳した記事もあるのでこちらも是非どうぞ。)

WordPress どうなる

さて、僕は WordPress が好きで、収入の大部分をこのオープンソース・ソフトウェアに依存しているわけですが、こうしたプラットフォームやデバイスなどにコンテンツを配信するようになる、という流れと、WordPress を使ってブログを書いたりメディアを運営したりすることの関係がどうなるのかについて整理したいです。

結論から言いますと、WordPress 使っててよかったー、という話になるのではないかと思います。WordPress はそもそも Publishing Tool であり、今はたまたまHTML 製造機としての WordPress が前面に押し出されていますが、コンテンツをパブリッシュする(世界に向けて、言いたいことを言う)ということで言えば、別に HTMLじゃなくてもよくて、HTML のサブセットでもちょっと変わったXMLでも json でもなんでもいいわけですね。

WordPress でよかったね、というふうに思うのは、これから、メガネ用の規格、脳みそに直接送信するための規格、スマートウォッチ用の規格、スマートカーで読み上げやすいようにするための規格とかがバンバン出てきたとき(もしかしたらひとつに統合されるのかもだけど)、いちいち対応するのは面倒だけど、プラグインを入れたらそれでいいじゃないか、という話になるのは気が楽です。別に WordPress じゃなくてもいいけど、現状を見ると対応が早いのは WordPress ですよね。

作家でプラグイン作者で破滅派社長の高橋文樹さんの WordCamp Tokyo 2015 でのセッションも同様の話だったかと思います。

キラキラした何か。
「キラキラしたナニか」を通してマルチプラットフォーム・パブリッシング!

WP API どうなる

WordPress のコア機能(プラグインじゃなくて本体の機能)として、今ホットな話題といえば WP JSON REST API なのですが、これも似たような文脈で理解することができます。

WP JSON REST API とはなんなのかというと、WordPress のデータを json で restful に配信できるようになって、コンテンツやデータを色んな所から引っ張ってきたり(サイトに来なくても)、アプリやサービスなどから追加/変更/削除できるようになったりする、という話です(ザックリですみません)。

なので、コンテンツを入れておく場所はWordPressであって、HTMLも表示できるけど json で各種プログラムと仲良く話をすることもできる、というようになる。ということはいろんなデバイスに対してコンテンツをオープンにすることができるようになるわけですね。

今は HTML のサブセットやらちょっと変わったXML を出力するためにプラグインを入れているわけですが、今後は json で配信しておくから各プラットフォームさんは勝手に持って行ってくださいな、ということになるかもしれません。

そう思うと、何が何でもこっちのサイトに人を引っ張ってきてコンバージョンしたい、というのはかなり無理筋になってきて、コンテンツを適した形で読めるように配信する、コンテンツで魅了する、作者やメディアのブランドがちゃんと伝わるようにする、そしてマネタイズは後から考える(←)、という姿勢で取り組まないといけなくなっていくのではないでしょうか。

大変ですね!

↓ プラグインを作る方々への本、書きました。 ↓

WP REST API の OAuth 認証の方法と何が起こっているのかとなぜそんなことをしているのか

ウェブアプリ、スマホアプリなどの外部のアプリケーションから WP REST API を利用して WordPress のデータを更新などするために必要になる OAuth 認証の方法について。何が起こっているのか、なぜそんなことをしているのかを丁寧に調べてみたレポートです。

OAuth認証やってまいります。

WP REST API の OAuth 認証用のプラグインの github レポジトリのドキュメントのフローの通り進めます。また、リクエストの送信には、Paw という Mac アプリを利用します。

この記事自体の中に上記のドキュメントで伝えられていることを逐次翻訳して残しておこうと思います。上記のドキュメントは読まなくても大丈夫になるように頑張ります。間違いがあったら、 @shinichiN へお願いします。

STEP 0: Client Key と Client Secret を作成する

ドキュメントサイトの方には「OAuth のプラグインにUIはありません。そのうち作ります」などと書かれておりましたが、実際にはありました。

WP REST API の OAuth プラグインのアプリケーション作成画面
WP REST API の OAuth プラグインが提供するアプリケーション作成画面

wp-cli を利用して $ wp oauth1 add みたいなことをしないといけない、とドキュメントサイトにはありますが、管理画面でできました。

というわけでさっそく作っていきましょう。

コンシューマを作ってみました。
コンシューマを作ってみました。

NameDescription は管理用のものだと思われますので適当に入れます。Callback URL はよく分からないですが必須なので /success としました。

Client Key と Client Secret をメモしておきましょう。

OAuth フローの概要と、その意義

OAuth1/Auth-Flow.md at master · WP-API/OAuth1 にある OAuth 認証のフローを翻訳します。クライアント側から見ると、3つのフローに分かれています。

“WP REST API の OAuth 認証の方法と何が起こっているのかとなぜそんなことをしているのか”の続きを読む

↓ プラグインを作る方々への本、書きました。 ↓