部屋で音楽を聴くとき、みなさんはどうしてますか。僕はiPod touchからAirPlay越しにAVアンプで再生しています。でも僕のiPod touchは第5世代で、iOSのアップデートの度に動作が重くなっていき、また、使おうと思ったら充電が切れていることがあるため、新しいiPod買おうかなと思いました。

しかし、iPodは高い。128GBモデルが5万弱です。一応今持ってるやつも使えるんだし、部屋で聞くためだけに5万は……。

ということで、1/10の価格で買える128GBのUSBメモリ「SanDisk USB3.0 SDCZ43-128G 128GB」をRaspberry Piに接続して、DLNAサーバとして使うことにしました。

スポンサーリンク

とりあえず挿した

ためしにマウントしてみたら、普通に読み書きできそうだったので、Windows機に接続してiTunesの曲フォルダから曲をコピー。

まあまあな速度

ちなみに転送速度はこんな感じ。USB3.0接続なので、もう少し速度出てくれると嬉しかった。今回はiTunesで管理しているm4a(aac)ファイルで、一曲6MBくらいですし、そう何度も転送するものではないですから、別段問題はありません。可逆FLACやハイレゾなんかでやりたい人はもっと高速な(高額な)USBカード買ったほうが気持ちいいでしょう。

一応CrystalDiskMarkの結果も

ゆるい設定でベンチマークしてみましたが、なかなか素晴らしい結果が出ています。じゃあさっきの転送速度はなんだったんだ? という。

マウント

$ mkdir sdcard
$ sudo mount /dev/sda1 sdcard -o codepage=932,iocharset=utf8

無事にマウントできたら、/etc/fstabにも追記しておきます。

/dev/sda1       /home/pi/sdcard vfat    iocharset=utf8,codepage=932     0       1

文字コードを指定しないと、日本語のファイル名が文字化けして「?????」という表記になります。ちなみにうちの環境だと、上記のように、文字コードを指定してマウントしようとすると下記エラーが発生します。

mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
$ dmesg
(中略)
[25653723.379590] FAT-fs (sda1): codepage cp932 not found
[25653864.887177] FAT-fs (sda1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[25653864.897426] FAT-fs (sda1): IO charset utf8 not found

という具合に、文字コードオプションをつけるとマウントに失敗します。ググると、cp932やutf8を使えるように設定してカーネルを再構築すればいいとのこと。そんなのやったことないし、間違いなく面倒くさそうと思って、他の手はないかと試行錯誤してみましたが、ダメでした。仕方ないので泣く泣くやってみたら、たしかにカーネル再構築でうまくいきました。しかし、その方法をここに記すには、余白が狭すぎるので……、もとい、「どうせ上手くいかないだろ。二度と起動しなくなっておしまいに決まってる」と思いながら作業したもので、ログをとっていませんでした。同様の事象で苦しんでいる人も、広いインターネットにはいるかもしれませんので、僕がやったことの概要だけ次に示します。普通にマウントできた方は飛ばしてください。

WindowsのVMware Player上にUbuntu Server 14.04.4 LTSをインストール

クロスコンパイル用。raspberry pi上でビルドすると、すごく時間がかかるそうです(数時間とのこと。今回うちのクロスコンパイル環境では6分くらいで終わりました)。OSイメージは公式サイトからHTTPでも数分でダウンロードできました。仮想マシンでHDDに20GB容量を割り振って、インストーラのおすすめ通りに何も考えずにインストールしたら、後々容量が足りなくなり、追加で20GBを割り当て、パーティションとファイルシステムの拡張をするハメになりました。あらかじめ適切にパーティションを切るか、はじめから40GB割り振るのがおすすめ。

Ubuntu Serverの設定をする

アップデートしようとしたら、そもそもネットワークに繋がっていなかった。仮想マシンのNICをブリッジに設定して、/etc/network/interfacesに追記。

auto eth0
iface eth0 inet static
address 192.168.xx.yy
netmask 255.255.255.0
network 192.168.xx.0
gateway 192.168.xx.zz
dns-nameservers 192.168.11.zz
hostname ubuntu1404

あと/etc/hostsにも追記。

127.0.0.1 localhost ubuntu1404

これでとりあえずクロスコンパイル用OSとして使えるようになりました。

クロスコンパイルする

Raspberry Piのカーネルをクロスコンパイルする」に書いてある通りにやると、できます

ただし、手順の途中(menuconfigのところかな)で、今回のメインの目的である文字コードのオプション設定をします。File systems→DOS/FAT/NT Filesystemsで、 Default codepage for FATを932、iocharsetをcp932にしてみました。設定に関しては良く分かっていないというか、あくまでデフォルトの設定値なら、USBメモリマウント時にcp932が見つからないというエラーとはまったく関係ないのではないかと思いながら変えてみました。

ちなみにlinux素人なので、「ただカーネルの設定を変えたいだけなら、今使ってるカーネルと同じバージョンのソースを持ってきてビルドしないとダメなんじゃないのかな?」と思い、GitHubという右も左も分からないところで、今使っているカーネルバージョンのソースを探してみましたが、結局見つけられませんでした。あきらめて、上記サイトの手順に従って最新のソースでビルドしてみたところ、なんか普通にうまくいきました。

ただ一点、上記サイトの手順の最後で、ビルドしたモジュールをscpでraspberryに転送するのですが、これがめちゃくちゃ時間がかかる。ファイルがやたらとたくさんあるんです。どうにかならんかと思って調べてみたら「これでダメなら諦めた方が良い程度にRasberry Piのカーネルクロスコンパイル手順をまとめてみた。」こちらのサイトでは、転送前にlib/modules/カーネルバージョン/sourceとbuildを削除しています。削除していいものならしたいですよね。ということで削除してから転送したところすぐに転送が終わりました。

そして再起動したら日本語ファイル名が表示できた

手順のままに再起動したら、カーネルが4.1.13-v7+になって(作業前は3.18.7-v7+)、発端のmountコマンドが正常に通るようになり、日本語ファイル名もバッチリ表示されました。僕が途中でいじったカーネルパラメータ設定は、たぶん、今回の事象とは関係なかったんじゃないかな……。という感じはします。再構築することで、おそらくOSが良い状態になったんでしょう。バージョンが変わっても今まで使っていたプログラムも正常に動くし、個人データも消えないしで、何も分からないままに無事成功したようです。

DLNAサーバのインストール

Raspberry pi (b+) で、DLNAサーバを作ろう!」こちらのDLNAサーバ構築の項のようにやればできます。めっちゃ簡単です。これでたとえばPS3、Windows Media Player、テレビといった、DLNAに対応している装置から、いつでもraspberry piに挿したUSBメモリ内の曲が再生できるようになりました。

日本語のファイル名をローマ字表記にする

さて、僕はYAMAHAのRX-V773というAVアンプを使っています。テレビ画面にDLNAのブラウザを表示することもできますが、音楽を聴くためだけにテレビをつけたくありません。装置のフロントディスプレイでもブラウズできますが、日本語表示に対応していません。

そういうわけでUSBメモリの中のファイル名をすべてローマ字表記にします。

kakasiで日本語をローマ字表記に

そのものずばりなソフトがあるようなので、インストールします。

$ sudo apt-get install kakasi

ファイル名を一括で変更するスクリプトを作ります。

#!/bin/bash
#一番上の階層のディレクトリ名を日本語→ローマ字
while read file
do
        newfile="`echo ${file} |kakasi -Ha -Ka -Ja -i utf-8 -o utf-8`"
        if [ "${file}" != "${newfile}" ]; then
                mv "${file}" "${newfile}"
        fi
done < <(find . -maxdepth 1 ! -name \. -type d)
#二番目の階層のディレクトリ名を日本語→ローマ字
while read file
do
        newfile="`echo ${file} |kakasi -Ha -Ka -Ja -i utf-8 -o utf-8`"
        if [ "${file}" != "${newfile}" ]; then
                mv "${file}" "${newfile}"
        fi
done < <(find . -maxdepth 2 ! -name \. -type d)
#すべてのファイル名を日本語→ローマ字
while read file
do
        newfile="`echo ${file} |kakasi -Ha -Ka -Ja -i utf-8 -o utf-8`"
        if [ "${file}" != "${newfile}" ]; then
                mv "${file}" "${newfile}"
        fi
done < <(find . -type f)

曲ファイルのディレクトリ構成は、「アーティスト名/アルバム名/曲ファイル」を想定しています。アーティスト名ディレクトリがあるディレクトリで上記スクリプトを実行すると、日本語ファイル名がすべてローマ字ファイル名になります。

今後の課題

WindowsのiTunes曲フォルダと、RaspberryのUSBメモリを同期させて、iTunesに曲を追加したら、自動でWindows→Raspberryへ曲を転送してくれたら良いなと考えていましたが、ファイル名を変更しちゃっているので一筋縄では行かない気がします。同期ではなく、iTunesのフォルダを監視して、追加があれば追加分を自動で転送して、USBメモリにファイルが追加されたら日本語→ローマ字変換スクリプトを実行するような流れかな。いつかやりたいです。

RX-V773のDLNAで曲を再生すると、レコードのようなノイズが乗る

本編とは関係ないですが、追記です。RX-V773のDLNA再生機能で曲を再生すると、ぷつ、ぷつ、とレコード音源のようなノイズが乗ることに気づきました。同じ曲をWindows Media PlayerのDLNA機能で再生する場合は、正常に再生されます。AVアンプ壊れてるのかなと思ってググってみたら、「最新ファームウェア(Ver.1.85)」がYAMAHA公式ページで配布されていました。更新内容に「DLNA機能の動作安定性向上」とあるので、最新ファームウェアにアップデートしてみたところ、ノイズ無く再生できるようになりました。よかった。

余談ですが、Raspberry PiのDLNAサーバの動作確認のために、一度FTPでWindowsからRaspberryに曲ファイルを転送して、試しにDLNA越しに再生してみたところ、決まった位置で「プツ! プツ!」とノイズ乗ることに気づきました。原因は、FTP転送時に転送モードをバイナリに設定していなかった為でした。ファイル転送時に「お前今これアスキーモードだけど本当にいいんだよな? 100%転送完了」(英語)と、ちゃんとメッセージも出ていたのですが、「100%、OK」と読み飛ばしていた僕は、原因に気づかずに数時間ハマることになりました。つらかった。

Posted in 情報技術

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください