ナイティナインの岡村を叩いている人たち

どうもこんにちは。Seevaです。

社会的なことを考えてもあんまり口に出す物じゃないなと思っていたのですが、最近それを話す機会も少ないので、自分の記録の意味でも書いていきます。

ナイティナイン岡村は何をしたんだっけ?

毎週木曜日の深夜にニッポン放送でやっているナイティナイン岡村のオールナイトニッポン内で、

「コロナが明けたら、なかなかのかわいい人が、美人さんがお嬢(風俗嬢)やります」 「短時間でお金を稼がないと苦しいですから」

とか話してたらしいです。自分はこの放送を聞いていなかったのですが(radikoでも聞き逃してしまいました)、結構なニュースになっていて放送局から謝罪声明、本人も番組中に謝罪を下と言う事です。

わかった、けど謝罪はおかしくない?

ニッポン放送から謝罪声明が出たのが翌週月曜。その時に自分は知りました理由は

現在のコロナ禍に対する認識の不足による発言、また、女性の尊厳と職業への配慮に欠ける発言がございました。

とのこと。確かにコロナ禍(そもそもこの言葉めちゃくちゃメディアで使われてるけどどうよ?)の中でこの発言はかなり浮かれてるなぁとは思います。がしかし、謝罪じゃないでしょ、と思った方は少なくないのではないでしょうか?

問題となった発言はそもそも事実

そもそもコロナ禍の中で若い人、特に大多数がアルバイトなどで主に生計を立てているような世代だと、このコロナ禍では生計が立てられていない人がいるのが事実です。メディアや政治はファミリーなどの中堅〜お年寄り世代のことをターゲットにしているので、これらの世代の人たちのことはあまりスポットが当てられません。

たまに、「歌舞伎町の人達が自粛しなくて問題だ」というニュースが流れていたりしますが、彼らにももちろん生活があり、彼らはこの1ヶ月間全く稼ぎはなく支出しかない、余裕が無い人は実家に帰るか、実家も無い人は借金をし、それ以上に絶望した人は自殺してしまう、それが全く明るみに出ないままにハイパー押しつけ自粛が政治家によって行われているという現状を把握できている人はほとんどいないのではないでしょうか。

そんな状況下において、「なかなかのかわいい人が、美人さんがお嬢」をやるのは推測される事実です。

そんな事実を放って岡村叩き

そんな事実があるにもかかわらず、「不適切だ」とか「不快だ」とか言って岡村を叩く人が増えました。後者については、それは人の感想なので勝手にしろとしか言いようがないし、署名でもしとけと勝手に思うのですが、「不適切だ」というのは少し間違っている気がします。そんなの政治家が国会の中でやってるだけで十分です。

事実、お金がなくて苦しむ若い世代が沢山いる現状で、働く気はあってもコロナによってそのチャンスを奪われた、コロナ禍が明けたら増えた借金を返そうと夜の仕事に励む女性は増えるはずです。まして、普段は夜の仕事はしたくないと思っていても、まとまったお金が必要で、自分の魅力は容姿・話術だ、と思う女性が新たに夜の仕事に来るというのも絶対増えます。普段夜の店にお金を払っている大人なら絶対分かるはず。その紛れもない事実(予測)を「不適切だ」なんていう大人が社会にとって不適切だと思う。

日本の良くないところ出まくり

正直、この件は汚い物には蓋をする的な日本文化の悪い点が出まくっていると思います。私は思います、「岡村の発言があって、そんな人たちが世の中にいるならなぜ助けないと思わないのか」と。

普段から夜の仕事をしている人の金銭感覚で、その人の収入を保証するのは結構難しいかも知れませんが、やむなく夜の仕事を始めた、と言う人たちも必ずいるはずで、その人たちを救うことくらいは出来るはずです。それなのに、岡村を「不適切」と言って叩いたり、NHKの顔がCGの女の子が出てくる番組を降板させろと5000名の署名が集まったり、本来動くべき方向とは確実に違う方向に事が動いています。

今必要なのは、岡村を引きずり下ろすのではなく、岡村によって提起された「夜の仕事で今後働くであろう人たち」を助ける事ではないでしょうか。

想像力の欠如から脱却するべき

そもそも夜の世界で働く女性たちがどうやってその世界に入ったのか、想像する力が無いと思います。

お金が欲しくてポジティブに働いている人は、これかもコロナリスクと闘いながら働けば良いと思います。しかし、夜の仕事は高額な収入という性質を持つため、必ずしもそういう人達だけではないという事実に蓋をするのをやめるべきです。中には知らずに勧誘されてそのまま続けざるを得ない状況になってしまったという人もいるはずです。その様な事実から目を背けず、その様な人たちを助けようと思いませんか。

いつか日本社会がそういう風になって欲しいと心から願っています。

在宅勤務で暇なので、音楽制作を始めてみようと思います。

皆さんこんにちは。 Seevaです。

重いムードなこのご時世

さて、最近「例の」ウィルスで街が大変なことになっていますが、自分も例外ではなく、今週から在宅勤務が始まりました。 在宅勤務とはいえ、自分の仕事はお客様に場所と技術を提供するもので、お客様が来なければ基本的には仕事がありません。 この「例のウィルス」騒ぎで仕事が飛びまくってるので、実際には仕事がないのが現状です。 見かねた会社がメンテナンスとしての半日出社を認めてくれ、もう半日は在宅勤務という名の待機をしておけと言うことになりました。 ただ、在宅勤務()を無駄に過ごしても仕方ないので、何か自分の為になる様な事を始めたいなぁと思っていました。

そこで、\\\音楽制作を始めてみようと思いました!///デデーン

なんで?と思っておられる方が大半かと思い増すが、一応普段は音楽に関わる仕事をしており、 出来れば音に関係ある事で勉強できたら良いなと思っておりました。 また、最近ライブコーディングという分野がある事を知り(元々知ってはいたのですが)、それに興味がわいたので今回やってみるという形です。

そろそろ本題です。

今回は、SuperColliderという言語を使って音楽制作をしてみたいと思います。 SuperColliderという「言語」という言葉に引っかかった方も多いかも知れません。 そうです。今回はプログラミングを使って音楽制作をしてみようと思います。 とはいえ、そもそもプログラミングと音楽制作がなかなか結びつかない方も多いかと思います。まずは、下のYouTubeリンクをご参照ください。

www.youtube.com

このYouTubeの動画内は、観客の前で実際にプログラミングをする「ライブコーディング」というものを実際にやっています。 男性がプログラミングをする事で、音や映像が切り替わります。そのリアルタイム性、インタラクティブ性はDJやVJのそれにも似ていますね。

さて、どうする?

プログラミング言語と聞くと、C言語JAVAなど、最近ではPython等思い浮かばれるかも知れません。 確かに、元々ソフトウェアなどを作るために汎用的に設計されているプログラミング言語を使えば実際に音楽制作を行う事が可能なのですが、それらを実際のソフトウェアとして動かすためにはコンパイルという作業が必要となります。 ありがちな説明ですが、プログラム自体はコンピュータの動作を人間が考えるための設計図であるため、実際にコンピュータにその動作を指示するにはその設計図を実際にコンピュータが扱える状態に変換しなければいけません。これがコンパイルです。 先の例の様にリアルタイムにコーディングをし、それを(瞬時に)コンパイルして、実際のソフトウェアとして動かす=音にすると言うことは汎用的なプログラミング言語には想定されていません。 そこで、音楽制作用のプログラミング言語=音響プログラミング言語が存在する訳です。

選択肢

ライブコーディングが可能な音響プログラミング言語は幾つかあります。 その中でも他者と比べ見た目に大きく違う言語がMaxとPureDataです。

cycling74.com

puredata.info

この2つは、音響プログラミング言語でありながら、完全テキストベースではなく、GUIを使ったプログラミング言語となっています。 このプログラミング言語では、それぞれ固有の動きをする関数を、それらが持つ引数を線同士でつなげながらプログラミングを行う、という形をとっているため視覚的でわかりやすいです。 ただ、その取っつきやすさの反面、整理整頓が難しく、他人の作ったプログラムだと解読困難な場合があったりもします。 (それはどのような言語にも言える事ではあるのですが・・・)

さて、それに対して今回使用するSuperColliderは完全にテキストベースです。

supercollider.github.io

SuperCollider自身のIDE(開発環境)は、他のプログラミング言語IDEのようにプログラムを実際に記述するエディター部と、それを実際に実行するコマンドライン部、そしてヘルプなどを表示させる部分の3つに別れています。 普段プログラミング言語を使ってプログラムを書いている人にはかなりなじみの環境なのでは無いかと思います。

これらの他にも、最近だとSonic Piという初心者向けのものや、Ableton LiveというDAWライクのもの、Common Lisp MusicやFAUSTというニッチな物もありますが(詳しく知りたければList of audio programming languages - Wikipediaを参照してください)、今回はPythonSuperColliderを動かすTidal Cyclesというものを導入していこうと思います。

前置きが長い

ここまで枕が長くなってしまいましたが、これ以降は次回。 実際にTidal Cyclesをインストールをして、音が出せたらなぁと思っています。

それではさようなら。

Mac mini 2018でPro Toolsシステム構築、そしてお金がかかった話。

こんにちは。Seevaです。

久しぶりにこのブログに投稿してみようと思います。 (実は別にWordpressでブログをたまに書いていたのですが、諸事情あって完全プライベートなこちらをもう一度掘り起こしました。) さて、今回は「Mac mini 2018でPro Tools Ultimateを動かそうとしてお金がかかった話」という題です。

もう2年前になりますが、2018年の後半?位にMac miniのニューモデルが出ました。1つ前のMac miniが2014年のモデルだったので、かなり現代版にアップデートされて盛り上がった記憶があります。未だに銀箱Mac(Mac Pro 2012)を使っていたので、それをMac miniに置き換えてみようという企画です。


今回の目的

今回の目的は、Avid社のPro Tools Ultimateという、音を編集したりミキシングするソフトウェアを快適に動作させる事が目標です。Pro Toolsセッションには映像なども貼り付け、録音からポスプロ・ダビングなどを行うので、ただ動くだけでなく、仕事で使えるレベルのスペックにする必要があります。

システム要件

まず、Avid社のシステム要件を確認しました。それによるとMac mini 2018(Mac mini 8,1)の場合、以下のスペックで対応していることが分かりました。

  • MacOS Mojave
  • 6-Core i7 'Coffee Lake' 3.2 GHz(i7-8700B) or 6-Core i5 'Coffee Lake' 3.0 GHz(i5-8500B)
  • Ultimate Only: Thunderbolt 2 - PCIe Gen2 シャーシ: Magma EB3T, Sonnet Echo Express III-R , Sonnet Echo Express III-D / Thunderbolt 3 - PCIe Gen3 シャーシ: Sonnet Echo Express III-R Thunderbolt 3 Edition, Sonnet Echo Express III-D Thunderbolt 3 Edition eGFX Breakaway Box (GPU-350W-TB3Z) , eGFX Breakaway Box 550 (GPU-550W-TB3) , eGFX Breakaway Box 650 (GPU-650W-TB3) ,Sonnet Thunderbolt 2 Upgrade Card及びApple Thunderbolt 3 (USB-C) to Thunderbolt 2 Adapter.を使用したSonnet's Echo Express III-D または III-R 以外のThunderbolt 3 マルチ・スロット・シャーシは、現時点でサポートされません。

MacOSについてはエントリー執筆時の2020年にAppleから購入すると、MacOS Catalinaがプリインストールされています。しかし、Mac mini 2018が発売された時にはMacOS Mojaveがプリインストールされていたはずなので、これは後からダウングレード出来るだろうと予想しました。また、CPUについて、この2つのCPUはソケットだけ異なるデスクトップ向けのCPUですのでどちらでも良いと思いましたが、i7のモデルのベンチマークがゴミ箱Mac(Mac Pro 2013)と同程度という情報を手に入れたので、i7モデルを選択しました。Pro Tools Ultimateの推奨は基本的にi7ですので、無難な選択ですね。

ちなみに、ここに記載されていないスペックですが、メモリーは32GB以上推奨なので32GBにしました。Mac mini 2018は後からメモリー換装が出来るのでとりあえず安いモデルでも良かったのですが、今回はCTOで32GBにアップグレードしました。また、SSDは、ワークを別にすることが決まっていたので必要最低限で256GBにしました。ProToolsとそれまわりのソフトウェア・プラグインだけで良ければこのくらいあれば十分です。もちろん、MIDI音源を大量に入れる場合は大きいモデルを買った方が良いかと思います。

シャーシの選択で罠にはまる

ここで、自分が罠にはまったのがシャーシです。元々銀箱を使っていたので置き換え前のシステムには外部シャーシが存在しません。そのため、PCIeとThunderboltのシャーシが必要になるのですが、Mac mini 2018はUSB-C端子のThunderbolt 3搭載モデルなので、普通に考えてSonnet Echo Express III-Dを選択しました。しかし、これが罠だったのです。実はAvidのページには注釈がついていました。

Sonnet Thunderbolt 2 Upgrade Card及びApple Thunderbolt 3 (USB-C) to Thunderbolt 2 Adapter . を使用した場合のみ、最大3枚のHDXカードまたは1枚のHD Nativeカードがサポートされます。

この日本語、分かりづらいですよね。単体でゆっくり読んだら自分の読み間違いって分かるのですが、Thunderbolt 3モデルを買うのに「Thuderbolt 2 Update CardとThunderbolt 3 to 2アダプターを使用した場合のみ」サポートされると書いてあります。

つまり、Thunderbolt 3対応シャーシを買う場合、Thunderbolt 2 Upgrade Card(実質ダウングレード)を別に買って付け替え、Apple純正のThunderbolt 3 to 2アダプターを使用する必要があるということです。Thunderbolt 2は20Gbps、対してThunderbolt 3は倍の40Gbpsなので、どこかでボトルネックを作らないと速さに対応し切れてないって事ですかね・・・。この辺はまだまだAvidもSonnetもチューニング出来てないんですね。

恐らく、Pro Toolsなのか、HDXカード - インターフェース間なのか、Thunderbolt 3とPCIe 3.0のスピードにチューニング出来てないのではないかといった所でした。その証拠として、Thunderbolt 3のままProToolsを使用するとAAE error -6001が出て、Macごと再起動が必要になってしまいます。これでは仕事は出来ませんね・・・。

PCIe 3.0は下位規格のPCIe 2.0とPCIe 1.1, 1.0との互換性を持つとされていますが、実際にはチューニングが必要なんですね。AAE error -6001は日本語の資料がほとんど無かったのですが、海外のフォーラムなどを見ているとシャーシが原因ではないかと言われているようです。実際に今回購入した翌週くらいに EchoシャーシのHDXバージョンがアメリカでこっそりと発売されたようです。こちらはUSB-Cのコネクタで出ているのですが、規格はThunderbolt 2で動作するようです。SonnetはThunderbolt 3モデルはHDXカードに「まだ」対応していないよって書いてるのでいずれ対応するのかも知れませんが、Avidブランドでシャーシも出したみたいなので、もしかしたらこのままこの問題は闇に葬られるのではないかと思っています。残念です。

結論として、まだこのAAE Error -6001を解決していないのですが、Thunderbolt 2 Upgrade Cardを買って、Thunderbolt 2にダウングレードする予定です。

シャーシ以外は快適

シャーシのせいでAAE Error -6001が出ますが、それ以外では快適です。シャーシにはカードを1枚と古いBlackmagic designのビデオカード(正しくはビデオプロセスカード)を挿していますが、非常に快適に動いています。映像も快適にコマ送りできるし、劇伴のミキシングセッションも開けます。最高です。

Mac miniって非力じゃないの?

と言うわけでどれくらい実際快適なのか?ベンチマークを取ってみました。 R20からMacにも対応したと言うことで、Cinebenchの結果は以下の様になりました。 今回比べたのは、

  • Mac mini 2018 (i7-8700B 6C/12T モデル)
  • Mac Pro 2013 (Xeon E5-1680 v2 8C/16T モデル)
  • (参考)MacBook Pro Early 2015 (i5-5287U 2C/4T モデル)

Mac miniは8世代のソケットだけモバイル用になっているデスクトップ向けCPUで、動作周波数3.2GHz(ブースト時4.2GHz)です。Mac ProXeonワークステーション向けの上位モデル、3世代(Ivy Bridge)で動作クロック3.0GHz(ブースト時3.9GHz)です。 念のため自前の古いMacBook Proも入れておきました。かなり古いのであんまり参考にはならないかも知れませんが、Core i5の5世代(Broadwell)、低電圧モデルで動作クロック2.9GHz(ブースト時3.3GHz)です。

f:id:beatwave:20200229190440j:plain
Cinebench Release 20 結果
結果、Mac Pro 2013よりもMac mini 2018 i7モデルの方がスコアが良かったです。ただ実際はMac Pro 2013は8コア16スレッドなので、大規模セッションで高負荷ミックスなどを行う場合にはMac Proの方が強いかもしれません。また、シングルコアの性能を比較するとXeonの方が優秀です。DAWは基本的に並列処理よりもシングルコアの性能の方が大事なので、やはり高負荷をかけまくるセッションをよく開くのであれば、一度試してみたほうが良いかも知れません。 Mac miniの方がスコアが良かったのは、ブーストクロックが4.2GHz出るからかも知れませんね。総じて、使い方によってはXeonの方が良い場合もあるかも知れないけど、基本的にはMac miniでも十分と言ったところでしょうか。

まとめ

と言うわけで、Mac mini 2018に合うシャーシを普通に買ったら動かなくてお金が余計にかかってしまったという話でした。SonnetのEcho expressのページには「Avidと密になって作っているのでProToolsとMedia Composerにちゃんと対応してるよ!」って書いてるのに、こんな罠があるなんてホント予想外でした。注釈の組み合わせだと、結局スピードはThunderbolt 2のスピードになるので、Thunderbolt 3にしか対応していないビデオカードを同時使用する人は注意が必要です。HDX EditionはThunderbolt 3接続が可能のようですが、PCIeのバージョンは2.0のx8スロットが3つのようです。PCIe 3.0 + Thunderbolt 2の組み合わせでも動作するということは、どこかしらのチューニングが上手くいけばいずれは対応するのかもって感じかも知れませんね。ひとまず、今からMac mini 2018とシャーシを使ってPro Tools Ultimateを動かそうとしている人は、注意した方が良さそうです。以上です。

f:id:beatwave:20200223021953p:plain
対応してる感出している英語のウェブサイトと、日本語のウェブサイトに存在しないHDX Edition

カーネルパニックが頻発した話

久しぶりの投稿ですが。

実は、ここ2、3日、自分のMacカーネルパニックを頻発していて、運悪く毎回TimeMachineに5時間費やしていました。昨日とて、前回のカーネルパニックのせいで失った今日発表予定のプレゼンの資料を作っていたのですが、夜の7時半になってカーネルパニック発生、Macは起動しなくなってしまいました。
実際に起きていた症状としては、カーネルパニックが発生すると勝手にMacがリスタートし(ここまでは普通)、そこから起動するときの「くるくる」が回ると同時に、セーフブート時に出てくるようなプログレスバーみたいなものが、出てきますが、途中で消えてそのままMacの電源が落ちてしまいます。
幸いにも今回は、別の起動ディスクを使ってデータを回収することができたのですが、このようなことが頻発しては困るので、(すでにこの時プレゼン当日になっていましたが、)原因を究明することにしました。

今回の起動しなくなった直接の原因は、データの読み書き中にMacが強制終了したため、ハードディスク内の格納するデータの目次の部分と実際にデータが保存される場所の大きさが合わなくなって読めなくなったようです。その証拠に、起動しない状態の起動ディスクをディスクユーティリティにかけるとノード長が違うため修復できない旨が出てきます。
また、カーネルパニック自体はどうやって発生するかというと、カーネルと呼ばれるMacの基本ソフトウェアの根幹のソフトウェアが、他のソフトウェア(周辺機器のドライバやアプリなど)と競合してしまい、Mac自身が正常な状態に戻すことが出来ないと判断した時に、安全の為に強制的にリスタートすることを指します。これは、Macの基本ソフトウェアがきちんと動くための安全策なのですが、強制的にリスタートを行うため、その途中でデータの読み書きが行われていた場合は、その読み書きが完了せず、ハードディスク上には書き損じのまま不明のデータが残ってしまったり、目次の部分が間違ったっ状態のままになってしまう可能性があります。

ここ2、3日で何度もカーネルパニックが起きたと述べましたが、その中には正常に起動できた時がありました。普通はカーネルパニックが起きても起動できるはずなので、基本ソフトウェアがレポートを作ってその内容をAppleに送信しなさいと言ってきます。
その内容が確認できたので確認してみると、
「Possible memory corruption: pmap_pv_remove(......」
と表示されていました。これは、RAM(メモリー)がおかしいのではないかと考え、RAMに異常がないか調べる方法をネット上で探しました。すると、Apple Hardware Test(AHT)というプログラムを見つけました。
f:id:beatwave:20160315213324j:image
このAHTMacに標準で備わっているソフトウェアで、ハードウェアの異常を調べることができる画期的なツールのようです。2013年より新しい時期に買ったMacだと、名前と見た目が変わっててApple Diagnosticsというものになっているらしいです。

AHTMacを立ち上げる時にキーボードのDを押しながら起動するとAHTを起動することができるようです。Macを買った時にインストールディスクが付いてきたMacの場合は、それらを挿入した状態で、購入時にLion以降でインストールディスクがないMacはインターネット経由でAHTを起動せねばならないようです。因みに、インターネット経由で起動するときにはOpt+Dだそうです。

AHTを起動してみました。(起動まで時間がかかります。)
すごく時代錯誤感のあるUIが出てきました。そこで、テストを押してみると、ご名答、
「警告:Apple Hardware Testがエラーを検出しました。
4MEM/9/40000000: 0x82e....」
と表示されて、おそらくメモリが壊れているであろうことが分かりました。
f:id:beatwave:20160315213340j:image

Macbook Proにはメモリスロットが2つありますので、この時はどちらが壊れているのかわかりませんでしたが、AHTの「ハードウェアプロファイル」タブのメモリの詳細を表示させると、明らかに表示が不自然なものがありましたので犯人特定。換装したところエラーが出なかったので解決です!
f:id:beatwave:20160315213406j:image

今回異常があったメモリは増設したメモリだったため純正よりも新しいはずなのですが、さすが純正メモリの方が長持ちでしたね。マシン自体は6年目に突入しようとしていて、そろそろ替え時かなぁなんて思ってます。リカバリーの意味を込めて自宅にスティックPCを買ってVPNサーバーを立てているところだったので、そちらを早く完成させねばと改めて思いました。そちらの方も近々記事としてかければ・・・。





はてブロ3記事目にして、MATLABに手を出してしまった筆者について。

おはこんばんちは。
筆者は1記事目で取り上げたとおり、GNUのRを使っていつも統計処理等を行っていました。
大学の学部向けの授業でもこれを利用していることもあって修士の間はRのみでがんばっていくつもりでした・・・。

しかし、大学の教授や他の学生等はMATLABを使っており、他の人からもらうスクリプトMATLAB用のものばかりでした。
筆者も、学部時代はRではなくMATLABと互換の高いGNUoctaveという言語を利用していたので敷居も低く、今回導入しました。
(本当は無料のソフトウェアだけで研究をすることを目標にしていましたが、断念。)




さて、音を扱う研究を行っているので、オーディオ用の関数をよく使っています。
オーディオ用の関数で一番最初に使う関数として、wavread/wavwriteと言うものがあります。
これらはoctaveでも使える関数なのですが、MATLABでは色々な形式のオーディオファイルに対応するためにこの関数のサポートが終了し、新しい関数に置き換わっています。
(既に私が使っているR2015b版ではこれらの関数が入ったプログラムは動きません。)
と言うわけで、今回はaudioread/audioinfo/audiowriteについて解説します。

続きを読む

統計初心者が復習ついでに電車の要約統計量を考えてみる。

こんにちは。

大学に通っている私は、今後、音と人が感じる感覚についてをテーマに研究を進めていく予定です。
その中で必ず必要になってくるのが心理統計ですが、実は私は統計学という分野に触れたことはないし、そもそも高校の文系数学以来、数学はほとんどやっていないので、完全にこのような分野に関しては初心者です。

そこで今回は、最近読んだネットニュースを参考に、要約統計量を復習してみたいと思います。

まず、そもそも要約統計量についてですが、統計で使うデータはすごく膨大だったり、すごく複雑だったりします。
それらに傾向を見ていく為に統計手法を用いて検定を行うのですが、その前段階として、簡単な手法を使ってそれらのデータのおおよその特徴を1つの値にすることを数値要約、それによって出てきた値を要約統計量です。

それでは今回見つけたデータを紹介します。
データは(株)レスキューナウ様(以下、レスキューナウ)の記事です。
人身事故による運転見合わせ状況一覧(6/8~6/14) http://www.rescuenow.net/%e5%8d%b1%e6%a9%9f%e7%ae%a1%e7%90%86%e3%83%88%e3%83%94%e3%83%83%e3%82%af%e3%82%b9/1701

  • 検索条件:「事象:人身事故」「当該パターン:当該路線支障のみ」「発生位置未指定」
  • データ期間:2015年6月8日~2015年6月14日
  • 対象件数:15件
  • 最短最長(最大値・最小値):12~152分
  • 平均時間(平均値):74分
  • 中央値 :65分
  • 最頻値 :50分
  • 第1四分位数:56分
  • 第2四分位数:65分
  • 第3四分位数:77分
  • 標準偏差:±36分(38~110分)
  • 変動係数:0.49

(※本文中「検索条件・傾向」項より抜粋。)

各要約統計量について少しだけ説明します。(最大値・最小値は割愛します)
・平均値
各データをそれぞれ加算し、その個数で割った値です。
・中央値
各データを大小に関して並べた時に一番中央にくるデータです。但しデータが偶数個の時は、中央にくる値が2つになるので、その2つを平均して中央値とします。
・最頻値
各データの中で一番多く出た値です。
・四分位数
各データを大小に関して並べ、4分割したところにくるデータです。小さい順に第一四分位数、第二四分位数、第三四分位数と呼び、第二四分位数は中央値と同じ値になります。また、第一四分位数から第三四分位数までの間を四分位範囲と言います。

また、要約統計量と呼ぶのか分かりませんが、以下のものも説明します。
標準偏差
各データと平均値の差(偏差)を2乗して平均を取った値(分散)の平方根をとった値です。分散は、t-testやANOVAなどの分析手法の基礎的な考え方として統計学上重要な値ですが、今回のような予備的な比較をする際には、分散の平方根をとった標準偏差が便利です。
・変動係数
標準偏差を更に平均値で割った物です。これによって母集団が異なる代表値同士が、一定の条件下で比較できるようになります。


それでは、今回のデータをみていきましょう。
今回の最大値・最小値は12〜152分で、データの範囲は140分です。また、平均値は74分、中央値は65分ですので、平均値以上のデータ個数は、平均値未満の個数よりも少ない事が推測されます。また、最頻値は50分であるので、全体的に鉄道路線が1時間程度で運転再開が出来ていると言えます。

また、四分位値が10〜12分の間に収まっているので、中央値付近には値が密集しており、また最頻値は50分なので第一四分位値より外にも、1時間程度の値が密集していることが分かります。このことは標準偏差の値からも分かりますが、μを平均値、ρを標準偏差としたときに、μ±ρが38分なので、38分から110分の間に約2/3のデータが集まっていることが分かります。対象件数が15本であるから、その内約12回は110分までの間に運転再開しており、そのうち大半は1時間程度であったことがいえます。

以上のことから、データの個数をヒストグラム等で当てはめたとき、山は平均値よりもやや時間が短い方に出来、時間が短い方が裾野が緩やかで、反対に時間が長くかかった方は裾野が急になるような図が出来るかと思います。
今回の記事からは実際にどの路線がいつどれくらい遅延したか、という時間は掲載されていませんでしたが、各要約統計量をみるだけで全体の傾向が明らかになるというわけです。

仮に値を当てはめてみて、ヒストグラム化するとこういう図になりました。
f:id:beatwave:20150621173555p:plain
ちなみに、赤い線は平均値、青い線がそれぞれの四分位値を表しています。

この図を見ると150の所にある2と言う数値は、この分布が正規分布していると仮定すると外れ値として考えられますので、それを外してみてみると、確かに0方向に向かってなだらか、∞方向に向かって急峻な裾野を作っています。



余談ですが、今回の様なデータをRで観る場合は、summary(x)という関数を使います。
試しに、Rにデフォルトで入っているirisというデータを使ってsumary(iris)をみてみるとこのように返ってきました。

 Sepal.Length    Sepal.Width     Petal.Length    Petal.Width          Species  
 Min.   :4.300   Min.   :2.000   Min.   :1.000   Min.   :0.100   setosa    :50  
 1st Qu.:5.100   1st Qu.:2.800   1st Qu.:1.600   1st Qu.:0.300   versicolor:50  
 Median :5.800   Median :3.000   Median :4.350   Median :1.300   virginica :50  
 Mean   :5.843   Mean   :3.057   Mean   :3.758   Mean   :1.199                  
 3rd Qu.:6.400   3rd Qu.:3.300   3rd Qu.:5.100   3rd Qu.:1.800                  
 Max.   :7.900   Max.   :4.400   Max.   :6.900   Max.   :2.500

irisは菖蒲の事を指しますが、このデータの中にはそれぞれSepal、Petalという種類のLengthとWidthという種類のデータが入っています。
Min.が最小値、1st Qu.が第一四分位値、Medianが中央値、Meanが平均値、3rd Qu.が第三四分位値、Max.が最大値です。

興味があれば、これらのデータから分布を読み解いてみる、というのもおもしろいかも知れませんね。

R初心者がRMSをプロットする。

初投稿です。投稿テーマは「GNU RRMSをプロットする」です。

初投稿がこんな一部の人向けの様な投稿になっていいのか?という感じですね。筆者はどこにでもいる芸術大学の大学生で、Rはこの4月に始めた本当の初心者です。

以前は同じGNUプロジェクトの中のOctaveと呼ばれる言語を音響処理用として少しだけ学んでいました。しかし、この春から統計心理にも少し足を踏み入れることになり、同じソフトウェア上で統計と音響処理が出来ればと思い、Rに挑戦することにしました。

さて、そもそもRって何?って方も多いと思います。

RというのはGNUという、Unix向けの自由ソフトウェア運動の名の下にソフトウェアを配布している団体によるソフトウェアの1つです。GNUは、自由に使用・改変・再配布等ができるフリーウェアを作り、日頃使うすべてのソフトウェアをそれらでまかなうのを目標としている団体です。

そして、肝心のRですが、そんな彼らが作るフリーウェアの一つで統計処理などに多く用いられています。Rで使用できるR言語というのは、AT&Tベル研究所で作られたS言語、そしてプログラム言語Lispの方言に当たる言語で、MITの学生が作ったSchemeという言語などを参考に作られたものです。

統計処理に向いた言語ですが、パッケージと呼ばれるR言語で書かれたプログラムのライブラリを入れることで音響処理や画像処理なども行う事が出来ます。また、パッケージはCRANと呼ばれるネットワークによって共有されており、インターネットに接続できる環境があれば、世界中で書かれたあらゆるパッケージを読み込むことが出来ます。

今回はRで音の信号処理をしていきますが、Rでそのまま音を読み込むことは出来ないので、tuneRと呼ばれるパッケージを使用します。

source("tuneR")

(tuneRをお持ちでない方は、GNU Rソフトウェアのパッケージインストーラー等からインストールしておいてください。)
今回は音の入力などを行っていなかったので、これは必要無いですね・・・^^;


というわけで本題です。

RMSはRootMeanSquareのそのままの意味で、二乗して平均を取ったものの平方根を取ることです。
当然、時間軸方向にある程度の範囲が必要なので、今回は100msの窓を10分の1の大きさで移動させながら計算値を出していきます。FFTなどで用いられる窓がけの様な感じです。

プログラムの大まかな流れとしては、
1. 窓の大きさを計算する。
2. 窓に合う長さに音の長さを調節する。(ゼロ詰め)
3. 計算回数を設定する。
4. RMSを計算する。
5. 計算したRMS値を、最大値を0dBとした対数の値に変換する。
6. 計算された物をプロットする。
という流れになります。

plot.rms <- function(x,fs,nbits){
  
  #buffer time(ms)
  buffer <- 100
  buffer.samp <- ((buffer/1000) * fs)
  
  #add zero to fit 
  x.length1 <- length(x)
  x.length2 <- buffer.samp - (x.length1 %% buffer.samp)
  if(x.length2 == buffer.samp){
    x.length <- x.length1
  }else{
    x[x.length1 : (x.length1 + x.length2)] <- 0
    x.length <- x.length1 + x.length2 
  }
  
  
  #number of trials
  x.end <- (x.length / (buffer.samp / 10)) - ( 2 * buffer / 10 ) 
  
  x.rms <- c(1:x.end)
  x.rms[1:x.end] <- 0 
  
  
  k <- 1
  l <- 0
  while(k < x.end){
    
    x.rms[k] <-sqrt( sum( x[ ( l + 1 ) : l + buffer.samp ] ^ 2 )  / buffer.samp)
    
    k <- k + 1
    l <- l + buffer.samp / 10
    
  }
  
  #x.rms change to dB
  x.rms <- x.rms / max(x.rms)
  x.rms <- 20 * log10(x.rms)
    
  time.length <- c(1:x.end)
  time.length <- time.length / x.end * x.length / fs
  
  plot(time.length,x.rms,type="l",xlim=c(0,max(time.length)),ylim=c(-80,1),xlab="Time(sec)",ylab="PowerSpectrum(dB)",col="blue")
  par(new=T)
  abline(h=c(-20,-40,-60,-80),v=c(0:max(time.length)),lty="dotted")
  
  
}

ゼロ詰めの必要性ですが、もしゼロ詰めをせずに進めてしまうと、最後の方の試行で計算結果がNAになってしまい、プロット出来なくなってしまいます。
また、time.lengthが出てくる直前までは、xの値などはLarge numericとして扱われています。つまりサンプル値として扱われているので、冒頭のbufferをサンプル値に変換したり、最後のプロット時には、分かりやすいように秒に直すなどの手間が必要です。

というわけで、これを使えばあなたもRMSがグラフにプロット出来るはずです。