WiiUにUSB記録メディアとしてSSDを増設する

WiiUでゼルダの伝説 ブレスオブザワイルドをやってみたくなったのですがダウンロードするには記憶容量が10G足りません。

任天堂の公式HPでは保存メモリー容量を拡張する(動作確認済みUSB記録メディア)としてUSB-HDDを増設するように指示してあります。32GBとかのUSBメモリーをつなぐというのが手早そうですが、頻繁にデータを保存するので耐久性に問題があるようです。USB-HDDは古いのが余っていますが、繋いでみると途中でストップしてしまいます。やはり任天堂の指示のとおりY字USBケーブルで繋がないと供給電力不足になるようです。昔持っていたはずですが、まだあったかな・・と押し入れを探してみましたがY字ケーブルは見つかりません。

パーツ屋さんに買いに行きましたが、Y字ケーブルのみは売っていません。そもそも手持ちのHDDはUSB3なのでそんなケーブルはそもそもないだろう・・・セルフパワータイプのHDDをつないでもいいのですが、WiiUの電源を切ったときも回り続けるのはどうも・・・と思っていたところに120GBのSSDが5000円で売っていました。これを古いUSB3-HDDの箱に入れて繋げば、供給電力不足にはならないと思われるので理屈上は動くはずです。

ケースは昔に買った玄人志向の外付けHDDケースです。SSDは本日購入したTranscend SSD220S(120GB)を入れて、繋いでみると・・・無事動きました。すくなくとも2,3時間プレイしたところではセーブなども問題ないようです。

USB2接続なのでなんとももったいない使用法ですが、いまさらY字ケーブルの古いHDDを探すくらいならこういう方法もあるということで、人柱としての報告でした。

 

広告

MDXPlayer高音質化番外編:192KHzのHiDefで出力

MDXPlayerの高音質化を色々やっていたわけですが、62.5KHzのFM音源の出力を48KHzにダウンサンプルすると必ず音質は落ちるはずです(人間の耳ではほとんど違いはないはずですが)。いっぽうで、手元にはMacに繋いでiPhoneの出力を取り込んで分析するために購入したUSB-DACがあります。これをiPhoneに繋いで192KHzで出力することができれば、62.5KHzの約3倍になるので限りなく原音に近い出力が得られるに違いない!と考えました。いわゆるハイレゾ音源です。

iOS 7で実現! iPhoneからハイレゾ出力する方法を徹底ナビ

AppleがDTM正式サポート! Lightning-USB3カメラアダプタを使ってみた

などを参考にして、まずLightning – USB 3カメラアダプタを購入します・・¥4,200か・・・と思ったらヨドバシのポイントカードで買えました。早速繋いでみると、DACの電源ランプがつきません。USBバスパワー駆動なので、電源供給できるUSBハブを経由すると動く可能性があるようですが、むかしそんなのが家にあったような気がするもわざわざ購入するのも・・・動く保証もないし・・・と思いながら数週間が経過。しかしUSB3アダプターまで買ったのだからと一念発起して電源供給できるハブを購入しました。約1300円なり。

繋いでみると・・・ランプが点灯して認識されました!

img_6413

イヤホンをDACに入れてさて聞いてみようとすると・・・音が出ていません。iOS10からサウンドの出力先の設定がわかりやすくなっているので、画面に出してみると・・・・

img_6414

SPDIF出力になっています。私が使っているUSB-DACはMacでは出力先をドライバなどで設定する形になってますが(下の図でOutputを選ぶとUSB-DACのイヤホン端子から音が出る)iOSではどうすればいいのか・・・

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-11-11-16-17-51

しばらく色々やってみましたがだめぽいです。

ただ、192KHzでの出力自体はできているのか確認してみましょう。MDXPlayerをちょっといじってみて、192KHzでの出力を要求するようにして、実際に出力されている周波数も表示するようにしてみます

    AVAudioSession *session = [AVAudioSession sharedInstance];
    [session setPreferredSampleRate:192000.0 error:nil];    // 希望する周波数
    [session setCategory:AVAudioSessionCategoryPlayback error:nil];
    [session setActive:YES error:nil];
    float sr = [session sampleRate];  // この返り値が実際の出力周波数

USB-DAC繋いでいないとき:周波数の欄は2段になっていて、上がアプリ内部の周波数、下が実際の周波数です。48KHzにダウンサンプルされていることが確認できます
img_6416

 

USB-DACを繋いだとき:192KHzで実際に出力されているようです!

聞けないけど。

img_6415

ということで、手持ちのSD-U2DAC-HPLはiPhoneでは出力できないっぽいというレポートでした。どなたかiPhoneで使えるDACをお持ちでしたら試してみてください。ソースはGitHub https://github.com/sinn246/MDXPlayer/tree/HiDef に置いておきます。

 

GAMDX改造:ADPCMアップサンプリングをSpeexで

このシリーズもそろそろ終わりです。

もとのGAMDXではADPCMはもともと15625Hzなのを62500Hzにアップサンプリング(ちょうど4倍なので4回同じデータを読み出す形でアップサンプリングして、ローパスフィルターを2回通している)して、FM音源と合成して、その後ダウンサンプリングしています。ここまでのところで、ダウンサンプラーを入れ替えることで音質向上になることがわかりました。

せっかくリサンプラーをいれたので、ADPCMをアップサンプリングするところもSpeexライブラリでやってみてはどうかと考えました。

1)もとのADPCMアップサンプラー(私が改造したものを使っているのでローパスフィルターを1回しか通っていないです。したがってやや高音のノイズが多い)+Speexダウンサンプラー

defaultupsampler

2)ADPCMにSpeexアップサンプラーを使用+Speexダウンサンプラー

speexupsampler

殆ど変わりません。アップサンプリングが15625->62500とちょうど4倍なので比較的ノイズが乗りにくいようです。そこで、内部44.1KHzにしたときを比較してみましょう

3)もとのアップサンプラーで44.1KHzにアップサンプリングして、44.1KHzのFM音源と合成、そのまま出力したもの

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-19-18-14-18

4)Speexでアップサンプリングして44.1KHzのFM音源と合成、そのまま出力したもの

speex441

4)は1),2)によく似ています。ということはアップサンプリングがうまく行っているということでしょう。非整数倍にアップサンプリングするときにはちゃんとした?リサンプラーを使ったほうが良さそうです。なお、このアップサンプリングはダウンサンプリングに比べてCPU時間が半分くらいですんでいます。

GAMDX改造:リサンプラーのCPU使用率

ここまでの流れで、GAMDX音質向上を図ってみた結果もとのGAMDXのリサンプラーはあまり音質が良くないようなので差し替えてみることとしました。iOSでは比較的性能がよくおそらく最適化されているであろうAppleのリサンプラーが利用できますが、他のプラットフォームでも還元できるように、リサンプラーをfree sourceのSpeexプロジェクトから利用させてもらうようにしました。

当然、CPUに負担がかかると思いますので、使用率を比べてみることとしました。

同じ曲をiPhone5sで再生したときのCPU使用率をプロファイリングしてみました。

1)GAMDX内蔵のダウンサンプラー

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-16-17-11-21

アプリのCPU時間のうち1%も使っていません。

2)Speexリサンプラー Quality=4

%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2016-10-16-12-14-51

Qualityを0-10のうち4にしたときはCPU時間のうち60%程がリサンプラーに使われてしまいます。これはやりすぎか・・・

Qualityを2にするとFM音源エミュレートと同じくらいのCPUパワーがリサンプラーに使われて、0だとエミュレートの半分くらいのCPUパワーが使われるようです。Appleのリサンプラーを使ったときはアプリの外側でリサンプラーが動くので直接比較できません(が、CPUパワーの負担は軽いと思われます)。

AudacityでiPhoneの出力を取り込んで音質を比較してみたところではあまり変わりないようですし、Qualityは0〜2で十分に思われます。

班目春樹氏のマンガと国会質問と国会会議録検索システム

Huffington Postで班目春樹氏、菅直人元首相をマンガでこき下ろすという記事を見ました。実際のページも、つい全部見てしまいました。

このマンガについての意見を公表することは控えますが、「国会質問の不思議1〜4」及び「こんな議員はいいな」というのがありました。国会議員の不思議な質問及び素晴らしい質問について書いてありますが、当の議員の名前は書かれていません。誰なのか気になって検索してみましたが、Google任せではうまく出てきません。

http://kokkai.ndl.go.jp – 国会会議録検索システムというのがあり、そちらを調べてみるとすぐにわかりました。

国会質問の不思議1〜4は、議員の質問を揶揄するものなのでここには示しませんが、検索方法は書いておきます。

トップページから簡単検索→検索語指定に「班目 CAMS」「班目 広島」「班目 テルル」「班目 セシウム 一周」などと指定するとすぐに検索できます。珍しい名前なのがここで役立ちます。

前後の文脈を見ると、班目春樹氏が流れを把握していなかった場面もあるようなので、批判が全て当てはまるわけではないようです。

「こんな議員はいいな」というのは「班目 避難準備区域」で検索すると出てきました。平成23年08月03日衆議院内閣委員会での小泉進次郎議員の質問でした。検索画面で見るよりもPDFで見た方がわかりやすいかもしれませんのでリンクしておきます(PDF)。マンガの似顔絵が割と似ていたので何となく予想はついたのですが。

小泉議員の質問は素晴らしい内容だと思います。・・・他の質問がおかしくなっているのは、「津波の前に地震で炉が破損していたのではないか」ということに持ち込もうとしたり、実は冷却は安定していなくて放射性物質が漏れているのではないかという批判に持ち込もうとして、かみ合わなくなっているように思いました。特に科学的な話になると議員のブレーンとしてついているスタッフの資質が大きいんでしょうが。

 

 

ChromeでGoogleにアクセスすると遅い?

出先ではMacBookAirにiPhoneをつないでテザリングでネットにアクセスしています。Macですがブラウザは慣れの問題もありChromeを使っています。

最近(2015年4月頃から?)ChromeでGmailやGoogleMapなどにアクセスするとひどく待たされることがありました。ほかのサイトでは特に問題ありません。OSを再起動したりしても改善しないので何故かと検索したところ、 Google Services slow in Chrome というのを見つけました。これで無事解決しました。

chrome://flags とアドレスバーに入力して開くと設定画面になります。ここでQUIC(Googleの推進している新たなプロトコル)を無効にすると良いみたい。

今調べたらこんなのもありました ChromeでのGoogleサービスが遅い

テザリングしている時に起こっていたのですがあまり関係なくどこでも起こるのでしょうか?SOFTBANKがUDPの一部のポートをブロックしているのが原因ではないかと睨んでいたのですが。

2015.9.17 追記

いま同じ環境で(iPhone5s経由でのテザリング OSX10.10)QUIC有効にしてみましたが特に問題ないようです。Chromeがアップデートされたからかもしれませんが。

ミッシングリンク?

大学院を終えたあとは、ほぼ普通の生活に戻りました。そもそも大学院の後半に結婚して、その後2003年に娘が生まれました。

コンピュータは趣味のものではなく仕事の道具として使う感じになりました。

プログラムを組むのって、切迫したニーズがないとなかなか出来ないですよね?(自分だけ?)JavaもC#も、理屈は分かるけど日常生活で使うことがないなということで「読めるけど話せない」日本人の英会話みたいな感じになりました。ときに統計ソフトのRのスクリプトを書くのがやっとという時代がありました。

そんな中でも、自分の中ではいろんな言語を理解したいという気持ちがあったのか・・このコラムは結構真面目に読んでいました:

ダイナミックObjective-C : http://journal.mycom.co.jp/column/objc/index.html

 

もともと言語設計・コンパイラ制作に興味を持っていたので、ObjCという変な?言語には興味を持っていました。なんだかんだでObjective-Cのプログラムを組むことになったのは皮肉なものです。

ObjCの構文ではdelegateに違和感を覚えましたが、僕の知っている昔のC++ではそういう概念はなかったのですね。

大学院を卒業したあと、病気になるまではまともなプログラムを組みませんでした・・・

HenPitsuとは関係なく

3月11日は職場も大きく揺れて、津波が来るかもという情報もあり大変不安がありましたがいまは落ち着いています。

今回はコンピュータとは関係の無い話です。

自分はバリバリの理系で、SF小説を読むのが好きです。脳死移植、遺伝子治療、原子力発電などについて言えばどちらかといえば推進派です。

今回の原子炉の事件、直下型地震で直接の破壊があったのならともかく、これだけ時間がたってからいろいろ問題が出てくることについて。原子力発電については一般人以上の知識を持っていたつもりでしたが・・・予想していませんでした。一旦臨界でなくなった原子炉とか、使用済燃料の「冷却」がこれだけ問題のあるものだとは。

ソースはwikipediaなどが主ですが、今回の事故の状況を理解したくていろんな情報を見ていたところ、新型原子炉の改良点を紹介したページを見つけました。

http://www.gepower.com/prod_serv/products/nuclear_energy/en/passive_safety_system.htm

原子炉メーカー(GE)の、新型原子炉の性能を紹介したページです。トラブルがあっても最低数日は炉心の冷却を継続できること、その後も水の補給を続けることで持ちこたえることができることなどが紹介されていると思いますがどうでしょうか(ちゃんと英語が分かる人が観ると違うかもしれません)。

これを見て思うことがひとつあります。緊急時に、制御棒を挿入して炉心を停止する必要があることは私も理解していました。しかし勉強不足にも、継続して冷却する(パッシブではなくアクティブに)必要があることは私は知りませんでした。この新型原子炉の改良点を見ると、この点(停止時の冷却)が以前から(専門家のあいだでの?)問題だったことがよくわかります。

原発反対派ではありませんし、古い原発をどんどん新型に変えていったほうがいいと思う派ですが、緊急時の冷却については、今の報道を見る限り外からの電力供給に頼りすぎていますし、非常時電源についての見通しは甘かったなと思います。余熱で、安全な範囲の電源を確保するような、簡便で安全なシステムがあれば余熱処理と電源確保できるのでしょうが・・ただこういうシステム面での批判は、災害が起こってしまってでは後出しジャンケンのようなもので意味がありません。遺伝子治療などの別分野でも、同様の現実化しかねない危惧はないでしょうか?

長期的には新型の安全な原子炉を導入する方向で考えてくれるといいなと思います。今起こっている状況はまた別で、現場はほんとうに大変だと思います。文字通り命をすり減らしているような状況、その現場でがんばっている方々には敬意を表します・・・

iADのバグ?

アプリにiADを入れてから、スリープからの復帰時に固まって落ちてしまうことが時に起こるようになりました。特に、10分くらいおいておくとそうなります。Crash logでは

0   libSystem.B.dylib                 0x00000c98 mach_msg_trap + 20
1   libSystem.B.dylib                 0x00002d64 mach_msg + 44
2   AppSupport                        0x0001009e CPDMMessage + 158
3   AppSupport                        0x0000f3e4 -[CPDistributedMessagingCenter _sendMessage:userInfoData:oolKey:oolData:makeServer:receiveReply:nonBlocking:error:] + 848
4   AppSupport                        0x0000ed76 -[CPDistributedMessagingCenter _sendMessage:userInfo:receiveReply:error:toTarget:selector:context:nonBlocking:] + 618
5   AppSupport                        0x0000deba -[CPDistributedMessagingCenter _sendMessage:userInfo:receiveReply:error:toTarget:selector:context:] + 58
6   AppSupport                        0x0000e08e -[CPDistributedMessagingCenter sendMessageName:userInfo:] + 34
7   iAd                               0x00012bcc -[ADSession sendMessageName:userInfo:] + 100
8   iAd                               0x00013cfe -[ADSession open] + 22
9   iAd                               0x000065c2 -[ADBannerView sessionDidBecomeAvailable:] + 38
10  iAd                               0x00014d60 -[ADSessionManager considerCreatingSessions] + 416

となっていました。調べてみるとほかでも同様のことが起こっているようです。

http://stackoverflow.com/questions/3713067/app-crashes-because-iad-fails-to-resume-in-time

iADを入れる前にはハングすることはなかったので(特に、時間経過で何かするものではないので)まあiADのせいなのでしょうか。iOS4.2では直るかもしれませんが・・・

HenPitsuではスリープに入る前に画像を保存するので、作業結果が完全に失われることはないはずです。ただし、Undoはできなくなります。

今日始めた理由

iPhoneでの開発が進んで実機で動かせそうになってきました。
¥10800するのですが開発者として登録してみました。

サポートの役に立つかわかりませんし誰の得になるのかもわかりませんが練習がてらブログを作ってみることにしました。
何を書こう・・・