Android Walkman NW-F807

今まで NW-X1050 を使ってたんですが、容量16GBだとロスレスの曲を入れるには厳しかったので10月20日発売の NW-F807 を調達してみました。

2chのNW-F800シリーズスレに書いたことや指摘された問題を以下に書いておきます。

プレイヤーアプリの選択

Google Playストアから色々な音楽プレイヤーアプリをインストールすることができます。

主なプレイヤーの特徴を表にしてみました。

自前デコーダ flac replaygain gapless 歌詞表示 Shift_JISタグ 無料継続利用 アプリ名
y y n 可能だが形式によっては音飛びする ◎ ◎ 標準 W.ミュージック
y y y y n ? 広告あり DeaDBeeF Player
y 可能(※1) 有料 有料 ? ◎ 制限つきで可能 Winamp
y y y y y ○ 試用期間15日 PowerAMP
y Pro 有料 Pro ? ? 制限つきで可能 MyTunes
y y y y LRC file ? 試用期間5日 Neutron Music Player
y y y y n ○ 試用期間14日 GoneMAD Music Player
y y n y y ? 試用期間30日 Astro Player Nova
y y n DSPプラグイン(CPU消費増加) y ? 試用期間7日 PlayerPro
y y n n n ? 広告あり Mixzing
n (Android 3.1+) n n LRCファイル(有料版のみ) 修復ソフト配布 可能 Meridian
n (Android 3.1+) n n ? ? 可能 Zimly
n (Android 3.1+) n n n ? 可能 KENWOOD Music Control
  • ※1: 有料オプションのはずですが、F800では無料版でも再生可能という報告がありました。Android 3.1以降ではシステムデコーダでFLACを再生できるため、制限が緩和されているのかもしれません。

実際にコレを全部買ってF807で試聴してみました。

W.ミュージックは音が悪いと断言していいと思いますｗ 作り物っぽい音で高音が劣化したように感じられます。アンプの傾向が過去のウォークマンと大きく異なるのを、プレイヤーがムリヤリ似せようとして失敗した感じです。FLAC形式以外の再生では曲の境目の前後で音飛びが発生するという報告がありました。

無料で一通りのことができるWinamp や完成度の高いPowerAMP が無難だと思いますが、音質的には GoneMAD Music Player が優れていました。PowerAMPよりクリア感があって、W.ミュージックより自然です。歌詞表示こそありませんが、gapless再生やreplaygain対応も可能。音飛びも他プレイヤーより少ないようです。

mp3のID3タグにShift_JISが使われていた場合、PowerAMPだと一部文字化けするものがあるようです。Winampだと読めたという報告がありました。

不要なアプリの無効化

Android 4.0以降ではプリインストールのアプリを無効化することでメモリやCPUの浪費を避けることができます。今回は音楽再生とWebブラウザ以外のアプリで止められるものは全部止めてみました。無効にしたアプリの一覧はこちら。

W.コントロールは無効化すると本体横のW.ボタンをスクリーンONボタンとして使えるようになります。W.ミュージックを使わないのならW.コントロールも不要です。なお残念ながらW.ミュージック自体は無効化できないようです。

mora や music unlimited は無効化しました。SCEはプレイ履歴や録画履歴の無断公開をやっている(現在進行形)、プライバシー侵害を平気で行う企業です。ソニー系列企業の情報サービスなんて使う気には全くなれません。

付属イアホンの音割れ

付属イアホンと標準プレイヤーで低音を強調した設定にすると付属イアホンが音割れする問題が報告されています。

FLAC データの転送

この製品、FLAC 対応が売りなのに付属ソフトウェアのx-アプリではFLACデータを転送できません。

PCにUSB接続するとUSBストレージとして認識されるので、普通にエクスプローラでDnDしてファイルを転送することができます。

操作性

再生/停止や曲送りを行う物理キーがないため、ポケットの中で手探りで操作することが困難です。

NW-X1050 との音質比較

  • W.ミュージック => 使わない
  • W.コントロール => 使わない
  • 付属イアホン => 使わない
  • x-アプリ => 使わない

という偏った感じになってしまいましたが、この条件で NW-X1050 との音質比較を行なってみました。曲データのファイルフォーマットは NW-X1050 ではATRACロスレス、 NW-F807 ではFLACロスレスです。イアホンはどちらも e-Q7 を使いました。NW-F807 ではプレイヤーアプリに GoneMAD Music Player を使いました。 曲はジャンルの違うものを複数使用しました。

ソースの旨味やアラをストレートに表現するのはFの方です。Xは逆に音の整え方が上手く、ソースが多少荒れてても聴きやすい感じになります。
Fは音のつながりが自然で空間に余白がある感じになります。Xは逆に音にメリハリがあって、このイアホンだと特にキラキラした感じに聞こえます。

Fはイアホンを耳につけた直後は少し物足りない感じです。Xはイアホンを耳につけた直後は少しやかましい感じです。どちらもそのまま聞いてると数分でしっくりきます。

Fの方が低音はちょっとだけ厚いです。これが強調なのか、アンプに余力があるのかは私には分かりませんでした。Xの方がホワイトノイズがちょっとだけ多いです。FとXのどちらが聞き疲れしにくいかはこの二点とソースの相性で決まると思います。

Android端末としての評価

画面が小さいのはいいんですが、タッチパネルの出来がAndroidの中でも悪い方に入るため文字入力などで操作ミスが目立ちました。ソニー製品なのにPOBox Touchを内蔵していないのも微妙です。CPU/GPUのスペックはAndroidの最新からするとかなり古めで、RAMも512MBとゲーム用途にはやや物足りません。DAPではなくAndroid端末が欲しい方は、中古屋でAndroidスマートフォンを購入したほうが幸せだと思います。

まとめ

標準のままで使った場合、単に転送が不便で音が悪くて操作性の悪いDAPです。付属イアホンや付属ソフト、標準プレイヤーアプリが残念な出来であり、その回避にかなり時間を使うので、普通の人には全くオススメできないと思います。

しかし本体ハードそのものは音楽プレイヤーとして高水準だと思います。一通りの手間をかけると、最終的には音のいいFLAC再生機が出来上がります。自由度の高いDAPが欲しい人なら検討の価値はあるでしょう。

Windows Phone の WebException のハンドリング

Windows Phone の WebRequest で リクエストを送った際にネットワークやサーバ由来のエラーがあると WebException 例外が発生するんですが、この例外のStatusプロパティやResponseプロパティにはクセがあって以下のような現象が発生します。

  • 存在するサーバの、存在しないリソースをリクエストすると、例外のStatusはWebExceptionStatus.UnknownErrorだったり WebExceptionStatus.ProtocolError だったりする。例外のResponse にはサーバからの404レスポンスが正しく格納されている。
  • 接続できないサーバの、存在しないリソースをリクエストすると、例外のStatusはWebExceptionStatus.UnknownErrorになる。例外のResponse には適当にでっち上げられた404レスポンスが格納されている。

サーバに接続できてもいないのに適当にレスポンスをでっち上げるという実装ポリシーも関心しませんが、そのレスポンスのステータスが404だというのも関心しません。接続できないという現象は別に永続的なものではないはずです。

実際、このレスポンスをそのまま信用すると、呼び出し側としては接続のリトライを早急に諦めるか、サーバが404を返しているにも関わらずリトライを続けることになってしまいます。

続きを読む

Expression Blend 4 でカスタムコントロールとそのテンプレートを作ってみる

前回はWPFのスタイルやテンプレートについて書いたので、今回は実際に Expression Blend 4 でカスタムコントロールの作成とテンプレートの編集を行なってみます。

続きを読む

リソースとスタイルとテンプレート

Windows Phone

WPF再入門状態なので忘れないように忘れてもいいようにメモ。

(MSDN)スタイルとテンプレート に書いてあることの要約。

具体的に組んでみる例は次回やります

続きを読む

Windows Phone アプリのUIレイアウトXAMLから文字列リソースを参照する

Windows Phone プログラム

普通アプリを書く時は端末の言語設定によってテキストリソースを切り替えられるようにする訳ですが、Windows Phone 7.1 SDK でそれをやるのに多少苦労したのでメモしておきます。

もっといい方法を御存知の方は是非教えて下さい。

続きを読む

SharedPreferences と MODE_MULTI_PROCESS がイマイチよろしくない件

Android プログラム

運悪くAndroidで複数プロセスのアプリを作ったり、アプリ間で SharedPreferences を相互参照するハメになってしまった場合に役に立つ…いや、たぶん立たないメモ。

Context#MODE_MULTI_PROCESS フラグはどのように使われているか

このフラグはContext#getSharedPreferences(String name, int mode) の第二引数に設定するもので、API Level 11で設定された。Context  |  Android Developersではこう説明されている。

SharedPreference loading flag: when set, the file on disk will be checked for modification even if the shared preferences instance is already loaded in this process. This behavior is sometimes desired in cases where the application has multiple processes, all writing to the same SharedPreferences file. Generally there are better forms of communication between processes, though.

This was the legacy (but undocumented) behavior in and before Gingerbread (Android 2.3) and this flag is implied when targetting such releases. For applications targetting SDK versions greater than Android 2.3, this flag must be explicitly set if desired.

実際にこのフラグが参照されているのは ContextImpl#getSharedPreferences(String name, int mode) の中だけだ。他の箇所では一切参照されていない。

  @Override
    public SharedPreferences getSharedPreferences(String name, int mode) {
        SharedPreferencesImpl sp;
        synchronized (sSharedPrefs) {
            sp = sSharedPrefs.get(name);
            if (sp == null) {
                File prefsFile = getSharedPrefsFile(name);
                sp = new SharedPreferencesImpl(prefsFile, mode);
                sSharedPrefs.put(name, sp);
                return sp;
            }
        }
        if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
            getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
            // If somebody else (some other process) changed the prefs
            // file behind our back, we reload it. This has been the
            // historical (if undocumented) behavior.
            sp.startReloadIfChangedUnexpectedly();
        }
        return sp;
    }

SharedPreferencesImpl#startReloadIfChangedUnexpectedly は内部で hasFileChangedUnexpectedly() を呼び出していて、そこでは前回から自分が書き込みを行ったかどうか確認したり、ファイルのmtimeとsize が前回ロードしたものと同じかどうか確認したりしている。

まとめるど、このフラグは「getSharedPreferences を呼び出した時にmtimeとsizeを見て適当にロードし直す」というものだ。他の効果は一切ないし、自プロセスが書き込みを行なっていた場合もロードし直さないし、単に0を1に変えるような変更を前回のロードから1秒未満に行った場合もロードし直さない。端末の時計が補正された場合なんかもきっとうまくないケースがあるだろう。穴だらけとしか思えない実装なのだが、今後改善される可能性もあるのでフラグの存在自体は尊重するべきかもしれない。

ついでに言うと、もしあなたが取得した SharedPreferences をどこかクラス内のフィールドに保存しているのなら、それは再利用の際に別プロセスからのアクセスをチェックしていないまずいコードだということになる。

…困ったことに、PreferenceManager がまさにそういう実装になっている。

嫌な汗が流れてきたが、まだ話は終わらない。

では PreferenceManager を使っていないアプリでは MODE_MULTI_PROCESS をちゃんと設定して、かつ頻繁にgetSharedPreferencesを呼び出していれば問題はないのかというと、そんなことはなかった。

続きを読む