UPnPの世界 第二幕 その4(Linux連合軍)


いよいよ本丸、Synphonic MPDをレンダラー化させる方法の解説に入ります。

例によって、本題に入る前のお断りです。
ここから先のSMPDのレンダラー化に関する内容はこのサイトの掲示板で議論されている内容をベースにしています。SMPDのレンダラー化とフロントとバックエンドにタンデム方式で二台構成化する方法についてはご本家、パパリウスさんのコンメント欄で議論されていたことがあるのですが、本来の開発には関係しない議論なので、遠慮してくれという指摘があり、こちらの掲示板で引き受けることにして、パパリウスさんのご了解も頂戴しています。従って、此処から先の内容でご質問か有る場合はみみず工房に掲示板に質問をして、ご本家コメント欄への投稿は避けて下さい。ご理解よろしくお願いします。

本題に戻ります。

Synphonic MPDをレンダラー化させる方法はいろいろありますが、ここでは簡単に出来るタンデム型の二台構成の方法を紹介します。何故、二台の構成にするのかというと、簡単だからです。

一台で構成するためには、upmpdcliをSynphonic MPDに組み込む必要があります。これが結構大変です。apt-get install で簡単に組み込めないかなと試してみましたが、駄目なようですね。
組み込むための情報はここ(Raspbian Stertch Lite に MPD と upmpdcli をインストールして OpenHome のレンダラーを作る)にあります。
その通りやってみましたが、package lists の更新で public keyのエラーになり、

Reading package lists... Done
W: GPG error: http://www.lesbonscomptes.com stretch InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 7808CE96D38B9201
pi@smpd:~ $ sudo apt-get install upmpdcli

そのまま無理矢理インストールしても、ライブラリがインストールできないというエラーになります。

pi@smpd:~ $ sudo apt-get install upmpdcli
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 upmpdcli : Depends: libjsoncpp1 (>= 1.7.4) but it is not installable
            Depends: libmicrohttpd12 (>= 0.9.50) but it is not installable
            Depends: libstdc++6 (>= 6) but 4.9.2-10 is to be installed
            Depends: libupnpp5 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

public keyのエラーになる理由を調べるしかないのが、そんな根性はないので、パスします。いずれにしても

$ sudo apt-get update
$ sudo apt-get upgrade

している部分で、SMPDの掟をやぶっていることになるので、これ以上頑張っても仕方がなさそうです。
ところで、参考にしたサイト(joecool)はlightMPD に関して大変に丁寧な解説をされています。「lightMPD/upnpgw(全部盛り)」なんていう呼び名も秀逸で、素晴らしい。LightMPDの解説をしたサイトとしてはベストだと思います。お勧めします。ここにリンクしておきます。実はこの部分を書きたかったので、長々と失敗の記録を説明したのですよね。

という訳で、SMPDをレンダラーとして二台構成にする方法の説明に入ります。
前回説明したように、Linuxの二台構成にするのはソフトウェアが分割しやすい構成になっていることが理由です。MPD(再生機能)とupmpdcli(dlna対応のアドオン)という形でまま、ハードを分けてしまおうというわけです。
SMPDの場合、音質向上のためこの構成が多少変わります。

aplay(再生機能) + MPD(選曲、データ処理機能) + upmpdcli(dlna対応のアドオン)

通常はMPDが再生、選曲、データ処理の全てを行うわけですが、SMPDは Xenomai を使った高音質化を図るために、さらに再生機能と選曲/データ処理機能を分割しています。従って、二台への分割の仕方は二つの方法が可能になります。
~~~~~~~~~~~~~~~~~~~
普通の発想の分け方
~~~~~~~~~~~~~~~~~~~



~~~~~~~~~~~~~~~~~~~
独創的な発想の分け方
~~~~~~~~~~~~~~~~~~~



ということです。 上が

lightMPD-upnpgw(apu1) + SymphonicMPDレンダラ化(rpi-2b/3b)

での構成。下が

rpi2 upnpgw-usb + smpdplayer(rpi-3b,3b+)

での構成となります。
それぞれの図のタイトルは僕の独断で付けたものです。普通の発想と書いたのはこの時点で普通だったという意味で、最初にここで分けて二台構成にしてみようとという考え方は独創的でした。その独創的な発想者がdigififanさんです。

apuにLAN出力が3個あることに目を付け、MPDとupmpdcliを二台のapuに分離しタンデム構成にする。フロント側は外部(サーバ)と内部(バックエンド)の二回線が必要となるが、LAN出力は3個つあるので、まったく問題なし。さらに「全部盛り」にして、フロントとバックエンドの負荷を低減することも可能という方式を思いつき、lightMPD-upnpgwという形で実現されたということです。
「3年前に此処までやっちゃったから、それ以上やることが無くなった」という理由だと思いますが、upnpgw版の新しいバージョンはいまだに登場していません。

さて、SMPDをDLNA対応させるのにどういう方式をとるか。既にapu版のlightMPD-upnpgwがあるのだから、「普通の発想」はそのままバックエンド部分をSMPDに入れ換えるというものです。この場合、フロントとlightMPDはそのままつかう。バックエンドはSMPDに入れ換え、フロントとのデータの受け渡しの方法だけを考えれば良いということになります。この方法については後述します。
ここで、donuts.shop73さんが独創的な発想をされました。それが二番目のrpi2 upnpgw-usb + smpdplayer という構成です。 MPDとupmpdcliの間ではなく、aplayとMPDの間で分割してしまおうと考えたわけです。donuts.shop73さんが何故このようなやり方をされたのか、説明はされていないようなので、理由は分かりません。ただ、この方式の方が音質的には有利だと思われますので、多分、それが理由でしょう。いずれにしても、素晴らしいアイディアですね。

この方式を採る場合、MPD/upmpdcli分離方法と異なり、aplayer/MPD間は分離することを前提に設計されているわけではないので、データの受け渡し方で工夫が必要となります。rpi2 upnpgw-usb + smpdplayer方式ではncatを使うという形でそのあたりを巧妙に処理されているようです。ncatとはTCPなどを利用してネットワークでデータのやりとりを行うためのツールです。詳細はここ(nttdata)を参照して下さい。

ここまでが、本丸Synphonic MPDをレンダラー化させる方法への長い長い長い序幕のようなものでした。いよいよ本丸です。
ところが、これがアッと言う間に終わっちゃうのですよね(^^;;;。
以下、とんぼのめがねさんの掲示板への書き込みをベースに説明します。貴重な情報を開示して頂いたとんぼのめがねさんに感謝します。

SMPD側の変更は以下の通りです。

/boot/eth0.networkの変更

sudo nano /boot/eth0.network

DHCP=no
Address=10.0.0.2/30
Gateway=10.0.0.1
DNS=10.0.0.1

/home/pi/configs/mpd.confの変更

sudo nano /home/pi/configs/mpd.conf

# for any other MPD Client
port "6600"
bind_to_address "any"

# Buffer Setting
audio_buffer_size "2048" #default:4096
buffer_before_play "20%" #default:10%

#misc.
#NAS設定パラメーターを全て置換
input {
	plugin "curl"
	proxy "10.0.0.1:8123"
}

これだけです。

eth0.networkはネットワーク接続を対向接続に変更するためのものです。これは/boot内の設定ファイル(eth0.network)の変更ですので、Windowsでも変更可能です。要注意なのは、当たり前ですが、この設定をした後、設定したシステムはフロントと繫いだ状態でしか使えなくなるということです。

何を言っているかというと、次のmpd.confの設定変更はバックエンドとなるSMPDのシステムを立ち上げた状態で行うことになります。このためにはフロントと繫いだ状態で立ち上げる必要があります。そして、フロントと繋がったバックエンドのシステムの操作は、sshを使い、フロントを通してバックエンドと通信することにより可能となります。従って、フロント側に前回説明したフィードフォーワードの設定を行わないと、この変更を行うことが出来ません。
「風が吹けば、桶屋が儲かる」みたいな迂遠な論理ですが、正しい論理なので、従う必要があります。
mpd.confの変更ですが、前半のバッファ値の変更はバックエンド化し、負荷が軽くなったので、高音質化させるために小さくしようということだと思います。必ず必要というわけではありません。次のcurlプラグインの設定はフロントとの通信を行うために必須です。これを行わないとフロントのupmpdcliとのデータのやりとりが出来ません。

SMPDバックエンドのレンダラー化については、行うことはこれだけです。これ以外は通常の音源として認識させるための設定内容だけとなります。簡単でしょ。

それではフロント部分はどうすればいいのか。既にだいたい述べてきたのですが、右に脱線、左に脱線で説明してきたので、「何だかよく分からん」という方が大部分であろうと思います(^^;;;。「そこまで分かっているのなら、最初からちゃんと説明しろ」と怒られそうですが、そんなことが出来る位ならこんな書き方はしません。

「秩序立てて、論理正しく、順番通り解説する」なんてことはAIにまかせて、まっとうな人類なら「思いついたことを、気分のままに、順序を無視してヒラメキで並べる」という書き方をするのが、正しいです。夏目漱石だって長嶋茂雄だってそうやっていた筈です。何故ここで漱石と長島が出で来るか意味不明というところが、AIでなく人間である証明です。

という訳で、次回はフロント部分をどう構成するかというところから再開します。

(PC_Audio)   2019/08/14

コメントする

NewJPLAY騒動顛末の顛末その1(岩橋さんへのお手紙)


岩橋さん

最後にお手紙をやりとりしてから、一週間たちました。お元気にご活躍ですか。
JPLAY日本語サイトの公開ページに更新に右往左往されている状況については興味深く拝見しております。大変ですね。悪事を隠すのは。でも、こちらでこっそり全部保存してありますよ。いざとなれば、関係者にはしっかりお見せすることが出来ます。
アドバイスです。そろそろ、無駄なことは止めた方が宜しいのではないでしょうか。いまさら、まっとうなサイトに見せかけようとしても、時既に遅しです。
こちらも負けずに、毎日変更される内容については、そちらのサイトのページを保存し、コメントしています。コメントをご覧になって頂けているようで、嬉しく存じます。

さて、そちらのフォーラムに出入り禁止にして頂いたもので、様子が分からなくなってしまったのですが、親切な人はいるもので、最新の貴方の書き込みを拝見することが出来ました。この国は独裁国ではないのだから、こういうことはやっても許されます。残念ながら、僕は何も隠すことがないので、ご提供出来る情報はありません。申し訳ないです。
匿名のかたの私信のメールですが、公開の許可は頂いています。また、貴方が内部の方々には公開した情報です。従って、この書き込みの僕に関する記述部分を公開することは差し支えないかと存じます。

(1) Yさん
この方のおかげで今日の日本での知名度があると言えます。恩人中の恩人です。お会いする機会はありませんでしたが、お互い実名で私信を交換していました。JPLAYとは無関係のSingxer社長やSoulnoteの開発者も紹介しました。
旧版の頃は間違った記述を指摘すると直ちに訂正していただけました。
JPLAY FEMTOになってから、当サイトでパスワードをかけているページの内容についてブログに記載がありました。削除をお願いしましたが、削除すると今の話題自体が成り立たないので削除できないとのご返答でした。恩人ですので、今後はパスワードをかけている意味をご配慮くださいと丁寧にお願いしました。
ライセンス失効表示が出た際に私信で連絡をいただき、対処法をご説明し短期間で使用可能に戻りました。しかしその後何回もライセンス失効について話題にされ、ライセンス管理の仕組みそのものがけしからんということをお書きになりました。
ここ2、3か月間は「」で囲った、あたかも当サイトや当方からの私信に含まれていたかのような表現が目立つようになりました。ごく一部は本当に私信の引用ですが、大半は創作なさったものです。
JPLAY開発者と無償配布しているLinuxシステムの作者の人間としての比較をお書きになった際に戦争を例に出され、これは止めていただきたいし削除してくださいとお願いしましたが、誉めているのだから問題無いとの返答をいただきました。
数日前に書かれたブログを読み、私信交換は終了しJPLAYユーザーとサポートの関係に戻していただく時期に来たと感じ、長期間のご支援に感謝すると共にそのようにお願いしました。ご快諾いただき、ついでにTerms of Service遵守をお願いしました。
しかし、規約は尊重はするが個人の表現の自由が優先であるとのご返答でした。
再び、Terms of Serviceは尊重するものではなく遵守していただかなければならないとお伝えしました。
次のご返答も同じで、やはり個人の権利が優先であると仰せられました。
Terms of Serviceを遵守するおつもりが無いことを明言された以上、JPLAY FEMTOを継続して使っていただくわけにはいかず、開発チームと慎重な協議の上、利用をご遠慮いただく旨を伝えました。
ご本人のブログ追記では、当方が除名したとか規約違反を指摘して最終的には破門したとか書かれていますが、そのようなことはお伝えしていません。

「恩人中の恩人」とお認め頂いて、本当にありがとうございます。JPLAY開発者のマーシンさんにも是非そのようにお伝え下さいませ。僕も岩橋さんの情報には何度も助けられました。貴方はとても貴重な情報をお持ちで、特に海外のオーディオ関連の情報の収集力は素晴らしいと思いました。ありがとうございました。
しかし、最近の僕の記述についてはいくつ事実と異なる部分がありますね。

まず、パスワードをかけているページの内容に関する記載内容の変更依頼の部分ですが、正確です。一応書いておくと、最後の「今後はパスワードをかけている意味をご配慮ください」という部分ですが、文面は「変更ありがとうございます。今回はこれで結構です。」とはじまり、その後

私のサイトから情報だけ取って英語サイト 
から買う人たちへの情報遮断が目的です。こちらの場合はコミッションが一切入 
りません。フォーラムをクローズドにすることによりJPLAYの普及には障害と書 
いているものを見かけます。開発チームは世界中どこ経由で売れても利益が上り 
ますが、私の場合はそうでは無いので、JPLAYの普及につながるかもしれないが 
個人的利益増に貢献しないことはやらないと決めています。輸入製品の代理店が 
並行輸入に対して距離を置くのと同じです。

と書かれてました。僕は最初の「今回はこれで結構です。」に多少ムッとし、そしてその後のこの論理に呆れました。まあ、その理屈は分かるけど、この人はまったくJPLAYを愛していない。商売のネタとして使っているだけだなと。本当にそれでいいのかなと思いました。

「今回はこれで結構です。」といわれると、次回があるのね。こんな些細なことで、いちいち人のサイトの記述内容をチェックし、検閲まがいに修正を要求する。「これは付き合うのが大変な人だな、いずれ破局が来るかもしれないな」と考えました。

変更部分はワンフレーズだけで、「administrator資格をもつユーザの登録とリソースモニターを使った設定」を「 femtoServerのアカウントをadministrator資格をもつユーザに登録変更するという方法」に変えただけです。当時、まさかこういう事態になるとは思いませんでしたが、ちゃんと古い部分を残しておいてよかったです。
多分、この時の僕の対応に貴方は納得しなかったのでしょうね。だから、今回の説明でも「削除をお願いしましたが」と強調されているでしょう。
しかし、上のワンフレーズをご覧下さい。これで貴方が自分のサイトで数十行を費やし説明しているやり方を推定することが出来ますか。よほどのWindowsの知識のある人以外は出来ません。書き換えはさらに分かりにくくして、これでいいかと貴方にメールしました。そのご返事が「今回はこれで結構です。」でした。つまり、貴方は一応了解されたわけです。
修正内容の詳細は明かしましたので、これを読んでいる読者皆様にどちらの主張がもっともかの判断はお任せすることにしましょうね。

いずれにしても僕の貴方に対する不信感が明確になったのはこの事件が切っ掛けです。だから

旧版の頃は間違った記述を指摘すると直ちに訂正していただけました。

というのは当たり前です。当時、毎回お礼のメールをしたと思いますが、改めて、間違えを訂正していただいてありがとうございました。
僕が素直に貴方の言うことを聞かなくなったのは、JPLAY v7以降、貴方が検閲まがいのやり方で書き換えを強要もしくは暗示するようになったからです。ご理解下さいませ。

次に、ライセンス失効表示の件があります。書かれている内容はその通りです。しかし、この件に何で、貴方がこんなにこだわるのでしょうか。ちなみに、貴方のサイトの注意事項ページにはいまだに

TurboActivateについての詮索は大変危険

動作原理やアクティベーション履歴の格納場所の推測など、TurboActivateに関することをブログや掲示板に書込むのは大変危険です。匿名掲示板であっても、簡単に発信者が特定されます。同社から巨額の訴訟を起される可能性があります。プロテクション破りに加担したと判断されれば、刑事罰もありえます。
これらに巻込まれた場合、JPLAY開発チームや当デスクは一切責任を負いません。
議論したい方は同社が運営するフォーラムで行うべきと思います。

という記述が残っています。
これは、一見、親切なアドバイスを装った脅しですね。ただ、書かれている内容は正しいので、僕もそのアドバイスに沿って記事を書きました。
しかし、貴方のアドバイスが脅しに近いものであること暗示するため、エラーコードの件を最後に付け加え、TurvoAcrivateのヘッダーファイルが流出していること書き、貴方の上記の説明は脅しに近いものであることを暗示しました。ただ、この暗示は上品すぎて、貴方にはよく分かって貰えなかったようですね。今回の件でもこのことについては一言も触れられていません。その部分はここにあります。アンカーを付け、ダイレクトにリンクできるようにしました。

『ここ2、3か月間は「」で囲った、・・・ごく一部は本当に私信の引用ですが、大半は創作なさったものです。』。

これはどの部分を仰っているのでしょうか。僕は私信のそのままの引用はなるべくしないように注意しています。また、私信の内容をねじ曲げて「創作」するようなことをした記憶はありません。ただ、貴方はレトリックという表現をご存じないかただから、そういう部分を創作と仰るのですかね。

例えば「License Expired ゴジラ」です。これは、当然、レトリックです。挑発ぎみであることは認めます。ただ、挑発は楽しい。皆を笑わせます。漫才というのはそういう芸能ですよね。だから権力者は嫌う。貴方は権力者だ。従って、レトリックは嫌いだ。ちょっと論理が飛躍気味ですが、基本的には正しいかと思います。
どっかの国の首相のように漫才師(お笑い芸人)は大事にした方がいいですよ。「批判は嫌いだ。殺せ」というのは独裁国の王者のみに許される特権です(この表現もレトリックですよ。僕がこの特権を良いと思っているわけではありません)。
もっとも、貴方は既に壁を作り、独裁国の王となられているわけだから、当然この特権は認められるべきだと考えていらっしゃるのかもしれませんね。大きな間違いです。日本は民主国家です。ドイツに住んでいても日本人なのだから日本の法規に従うのは当たり前の話です。このアドバイスは受け入れられた方がいいと思いますよ。はやく壁を無くしましょう。

ところで貴方のトップページにライセンスの処理に関して「制限回数を越えたアクティベーション取消しなどの柔軟な対応」と謳っていらっしゃいます。
僕のケースではマーシンさんとの交渉に関して、一切サポートはなかったですね。
最初、貴方に相談したが、その後は全て僕が自力で、直接、マーシンさんと英語で対応しました。最初、マーシンさんは僕のライセンスが規定の回数を越えていることを問題視されましたが、使い初めの時の再アクティベーションはそちらの不備で発生した問題であり、僕の責任では無い旨、マーシンさんご説明したら、了解をして頂きました。彼は道理の分かる方のようです。この時のメールは貴方に転送したが、まったく音沙汰なしでした。これが「柔軟な対応」の正体なのですね。僕は、この時、貴方ともう付き合う必要なないな。直接、EUから買うんだったなと感じました。

次が、これです。

JPLAY開発者と無償配布しているLinuxシステムの作者の人間としての比較をお書きになった際に戦争を例に出され、これは止めていただきたいし削除してくださいとお願いしましたが、誉めているのだから問題無いとの返答をいただきました。

これは事実と違います。サイト記事の本文はベトナム戦争に言及していますが、これもレトリックです。物量に富んだ Windows と Intel ハードに対し、この面では圧倒的に弱い Linux陣営を分かりやすく比喩するためにベトナム戦争を出したのです。貴方の変更依頼のメールのどこにも戦争という言葉はありません。わざと読者に悪印象を与えるため「戦争を例に出され」と書かれたのでしょうが、これは卑劣やり方ですね。怒りを禁じ得ません。
貴方のメールの一部を引用します。貴方はこう書かれたのです。『JPLAYを企業体として評価し個人のホームページに書かれることは構いませんが、個人名を出して他人と比較するようなことは控えていただけますか。』
それに対する、僕のご返事です。

何がご不満なのかよく分かりませんが、必要なら次回の書き込みで
頂戴したメールの最後の部分を除き全文引用し、その後、僕の意見を
書き込みましょうか。
それとも、それだと一方的になるからとおっしゃるなら、僕の掲示板に
書き込んでいただければ、対応します。
いずれにしても、Marcinさんの高音質の音楽再生にかける情熱は
素晴らしいと思いますし、継続して頂きたいと思っています。
企業を代表するのは社長で、社長の力量でその会社が評価される
というのは当たり前の話で、何の問題もないと思います。

どこにも『誉めているのだから問題無い』などとは書いてありません。記憶だけでの不正確な書き込みは止めていただけますか。
そしてそれに対する、貴方のご返事は『個人の比較を控えていただきたい』というものだった。
だから、僕は

何が問題なのでしょう。「彼の名前が広まることは構いません」
のであれば、彼を代表者として他のソフトウェアの代表者(開発者)と
比較してどこが悪いのでしょうか。もう一度書きますが、
「企業を代表するのは社長で、社長の力量でその会社が評価される
というのは当たり前の話で、何の問題もないと思います」ということ
です。

僕の文を読んでいただければお分かりのように、「JPLAY = マーシンが
一人で作り上げたソフトウェア」などとは一言も書いていません。また、
そうは思っていません。だから、コミュニティだといっているのです。

なお、僕は私信を了解無しに公開するほど非常識ではありません。
誤解されないようお願いします。

最後の部分は貴方が『私信を公開したら、・・・・お察しください』と脅されたから、それに対応したご返事をしただけで、関係はありません。

これに対して貴方は『この件はこれ以上申上げません。』と返信されました。従って、僕はあなたが僕の記事の検閲を諦めたのかなと思った。そうでは無かったのですね。
僕のメールを二つ(この二つはこのやり取りの全てです)、引用しましたが、かなり乱暴な言葉使いをしています。その理由は、それまでの検閲にうんざりしていたからですが、貴方は、この時、いうことを聞かない僕に敵意を抱き、『こいつは何時かやつけてやる』と考えたのではないでしょうか。そうでないと、この次の最後のメールのやり取りでの貴方の突然の爆発は説明がつかないからです。

そして、いよいよ最後の大爆発(大暴走)が来る。浅間山もビックリです。このメールのやり取りは貴方も、僕も公開しています。ここでは僕の方にリンクを張っておきましょう。

この大爆発、今では、貴方は無かったことにしたいようですね。貴方のサイトからは僕の件の記述は消えました。TOSの解釈もかなり穏便(といってもまだ奇怪しいところは満載ですが)なものに変わりました。どうされたのでしょう。
最初はあれだけ意気込んで『この方は当日本語公式ページにとって大恩人なので、当方の裁量内で最大限の例外的対応をして来ました。しかし全世界のJPLAYユーザーに平等に遵守を義務付けているTerms of Serviceについてはこの方だけ遵守を免除するわけにはいかず、譲歩できません。開発チームと慎重な協議を経ての判断です。』と書いたのに、あっさり『規約違反による利用停止措置では無くJPLAY側都合のため、JPLAYからの返金の申し出を受理されました。』 となってしまったのでしょうか。さらに今では記述すら消えてしまいました。

ちなみに、僕は一度もTOSを「遵守しない」などとは言ってません。リンク先に証拠が残っていますので、確認して頂きたいのですが「規約の意識しますが、個人の自由な意見の公開を阻むような規約はあり得ないと思います。常識の範囲で対応いたします。」と言っているのです。そして貴方の(TOSを尊重しろという)踏み絵のメールに

根拠のない中傷は訴訟の対象となるでしょうが、
根拠に基づく批判を押さえつける自由諸国は世界の
どこにもありません。
法というのは常識に基づくものであり、自分の都合よい
ように解釈しているのは独裁国だけです。

とご返事しただけです。どこに尊重しないと書いてありますか。
江戸幕府もビックリ。踏み絵を踏んでいるのに、そんな踏み方じゃ駄目だ。ちゃんと踏めといっているようなものですね。まあ確かに貴方のいうように貴方に全面降伏、踏み絵のど真ん中を踏んでるとは主張しませんが。

「尊重する」の意味が僕と貴方では違っているようです。僕の「規約の意識しますが」というのは日本の常識では十分「尊重する」という意味になります。「尊重はしますが、貴方が勝手に決めたルールは守るつもりはないよ」と申し上げたのです。お分かりになりますか。そして二回目のタンカは、貴方が「踏み絵の真ん中を踏まないと許さないぞ」と脅されるから、踏み絵の端っこを踏んだ理由を説明したのです。

ライセンスを一方的に正当な理由無しに取り上げることは不当な非合法的な措置です。日本の法律では消費者は保護されますから、正当な理由も無しに一方的にライセンスを取り上げるなどという乱暴なことを認めるわけがありません。事情はポーランドでもいっしょでしょう。多分、貴方もこのことに気が付いたのでしょうね。

繰り返しますが、だから貴方は『規約違反による利用停止措置では無くJPLAY側都合のため、JPLAYからの返金の申し出を受理されました。』としたいわけですね。
この件(ライセンスを無効にしたこと)は僕が訴えると、間違いなく貴方は負けます。
また、日本の消費者保護の行政的観点からみても問題となりうるでしょう。

ただ一つ困っているのは、残念ながら今の貴方のサイトの表記では責任者はマーシンさんです。従って、訴える相手はマーシンさんとなります。僕はマーシンさんに好意をもっているので、ことを荒立てる気はありません。返金を返金して僕に再びJPLAYを使える権利を認めていただければ、結構です。

ただし、貴方は許しません。貴方のこれまでの一連の行為はそれ相応のペナルティを受けるべきものと考えています。どういう方法がいいのか思案しています。楽しみにお待ちください。

それでは、ますますのご活躍、楽しみにしております。さらば「JPLAY日本語デスク」。

窪田洋

(PC_Audio)   2019/07/27

コメントする

UPnPの世界 第二幕 その3(JPLAYfemto vs Linux連合軍)


本題に入る前にちょっとだけお断りしておきます。

ここから先の世界は魑魅魍魎の世界です。

何を言っているかというと、Linux DLNAはトラブルだらけの世界です。昨日出来たことが今日出来るという保証は何もない世界です。信じるべきは自分の知識と経験だけ。他に頼りになるものは無いという覚悟で近づく必要があります。
そういう世界は嫌いだという方はパソコンを使った高音質のオーディオ再生の世界とは無縁の方です。こんなヤクザな世界とは縁をきり、ご近所のオーディオショップの言うことを聞いて、電気入れるだけで、良い音の出るハードをそろえ、音楽を楽しまれることをお勧めします。JPLAYはバグだらけだから、嫌いだと言っている方は、もっとバクだらけのLinuxの世界に飛び込んではいけません。JPLAYはサポートが悪いから止めたという方は、頼りになるサポーターは自分だけというLinux世界に向かない人です。さっさと逃げ出しましょう。

ここから先、説明する内容は今日はそうだったということです。当たり前ですが、明日もその通りという保証はありません。今日出来たことは明日は出来なくなるかもしれないという前提で読んで下さい。
一応、最新の状況は掲示板でフォローするような仕組みにしたいと思いますが、それで問題が綺麗に解決されるわけではありません。ご了解よろしくお願いします。
ちょっと過激ですが、以上お断りしておきます。

まず、参考になる画面を紹介しましょう。



これは、僕のWindows10ノートパソコンのネットワーク画面です。ご覧のように共用サーバーとDLNA関連装置が乱立しています。メディア機器の中の Logitech Media Server のアイコンをクリックします。



こんな画面が表示されます。あとはいろいろなやり方がありますが、アルバムを選択し、再生を開始することができます。
従って、この Logitech Media Server アイコンを使って実行させた機能はウェブを使ったコントロールポイントということになります。画面からお分かりのようにレンダラーとしてはJPLAYfemtoを使っています。「Daphileサーバー + LMSコントロールポイント + JPLAYfemtoレンダラー」という連合軍で鳴らしていることになります。

このように、DLNAの特長は構成部分の選択が自由に出来ることです。

続ける前に、ちょっと脱線、このLMSのコントロールポイントを使う方法は、前回書いたDaphileのフォルダービューが効かないというトラブルが発生しません。この方法でフォルダーを一回開いておけば、その後はLMS以外のコントロールポイントでもフォルダービューが使えるようになりますので、重宝しています。理由はよく分からないのですが、同じ系列のソフトだから相性が良いということなのですかね。

本論に戻ります。

順番からすると、コントロールポイントの話になるのですが、とばします。理由はコントロールポイントの選択は環境次第で、決めざる得ないからです。
JPLAYの場合はコントロールポイントを決めて推薦しているというお話は前回しました。Linux連合軍の場合も事情は同じようなもので、構成によりコントロールポイントとの相性が発生します。従って、試してみて決めるという方法しかありません。一般論でいえば、mconnectやBubbleDLNAなどJPLAY推奨のコントロールポイントはLinux連合軍環境でも良い結果が出ることは多いです。しかし、あまり話題にならないKinskyやHiFiCastなども結構使えることがあります。というわけで、いろいろ試してみて決めて下さい。

Linux連合軍レンダラー編

レンダラー部分です。僕が試したことがあるのは以下の四つです。

lightMPD-upnpgw(apu1) + SymphonicMPDレンダラ化(rpi-2b/3b)
rpi2 upnpgw-usb + smpdplayer(rpi-3b,3b+)
lightMPD-upnpgw(apu1) + lightMPD v1.2(apu2)
Daphile Render(j5005)

四つのソフト、それぞれ特徴があります。僕が主に使っているのは二番目のrpi2 upnpgw-usb + smpdplayerです。これは donuts.shop73さんがrpi用のlightMPDをアレンジされた upnpgw-usb(フロント)とSMPDをアレンジされた smpdplayer(backend) で構成されるUPnP対応のシステムです。rpi-2/3bが二台必要で、i2s対応が前提となりますので、かなり制限のある条件でしか使えません。情報はupnpgwについては「Raspberry Pi 2 用の upnpgw を公開しました」に、smpdplayerについては右のリンク先かSMPD(パパリウスさん)のphilewebのコメント欄にあります。

上の二つはrpi-2/3b 二台かrpi-2/3bとapu1/2を組み合わせ二台とした構成となります。また三つ目のlightMPDを使う場合もrpi-2/3bまたはapu1/2、一台でも構成できますが、組み合わせて二台とすることが可能です。二台にした場合は音楽ファイルの読み込みとDACへのデータの送信を分離し、負荷分散となりますので、音質的には有利です。

このあたりの考え方はJPLAYのいわゆるデュアルモードと似ていますね。
相違点はLinux連合軍の方がハードが軽いですから、簡単に二台構成にしやすいという点です。実際にやってみると分かりますが、インテルパソコンを二台電源を入れて、音楽を聴くというのは結構面倒です。しかし、SoC二台なら気軽に立ち上げることが出来ますし、電源の切断なども簡単に出来ます。もちろん、JPLAY側もインテルパソコンは専用になるわけだから、コンパクトなものにするという対策はとれます。ただ、そうしても、ハードの価格は数十K円となりますので、最小10K円程度のSoCハードには負けます。

Linux連合軍が二台構成をとる理由は、ハードの軽さ以外に、ソフトが二台構成の形に分割しやすいということがあります。Linux側の再生用のアプリケーションとしてはMPDというソフトを使うことが多いのですが、MPDはUPnP対応していません。UPnP化するためには、upmpdcliという外付けのアドオンソフトを追加して、対応します。
この時、MPDとupmpdcliを二台のSoCに分けて配置し、さらにpolipoを使って、SoC間の負荷をコントロールするという手法をとります。upmpdcliには最初からこのような分割を意識した作りがされています。



図の作成には donuts.shop73 さんの rpi2 upnpgw-usb にある system-image.txt のデータを利用しました。
ありがとうございました。

この手法は lightMPD-upnpgw の初版が公開された時にとられたものですが、その後、全く変更なく続いています。変える余地が無いということなのでしょう。 もちろん、SoC一台の構成も可能です。こんな感じになります。



また、このようにネットワーク負荷を低減させるため、フロントとバックエンドの間の回線を二回線にするという方法もとれます。



という訳で、ここから先の解説はフロント、バックエンドの話が交じり合い、かなりゴタゴタします。どういう具合に書くかなと考えたのですが、まず一番上の単純なやつからはじめます。

lightMPD-upnpgw(apu1) + SymphonicMPDレンダラ化(rpi-2b/3b)

「単純なやつからはじめます」と書いておいて、いきなりゴタゴタさせるのは、いつもの手口です(^^;;;。
この構成で lightMPD-upnpgw という部分がフロント、SymphonicMPDレンダラ化という部分がバックエンドとなります。lightMPD-upnpgwというのはdigififanさんが公開されているlightMPDのDLNA対応版です。「UPnPの世界 第一幕(JPLAYStreamer vs lightMPD/upnpgw)」はこのlightMPD-upnpgwをフューチャーして解説した記事ですね。JPLAYStreamerはオマケで名前が登場しただけです。

upnpgwというのはdigififanさんの造語でUPnP対応したゲートウェイ(GateWay)という意味です。

ゲートウェイという単語は高輪ゲートウェイ駅で一躍有名になりましたが、出入り口という意味です。高輪ゲートウェイというのは高輪門なり高輪口というのを今風に言い換えただけで、折角、漢字3文字で表記出来るものをわざわざ漢字カタカタにして8文字にするという愚行(^^;;;を意味します。
コンピューターネットワークで使われる場合はあるネットワーク全体(ある企業とか家庭とか)の玄関/門ということになります。

さて、upnpgwですが、こちらは素晴らしい呼び名ですね。「UPnP接続の入り口(gw)」というわけで、まさにフロントエンドの機能をそのまま表しています。
ただ、話を多少ややこしくしているのは、upnpgw版の中にバックエンドのDACと接続する側の機能が入り込んでいることですかね。つまり、lightMPD-upnpgw版はlightmpd.confという設定ファイルを使い、フロント/バックエンドのどちらでも動かすことが出来るという仕組みになっています。ここでは話を明確にするためフロント機能のlightMPDのみを lightMPD-upnpgwもしくはupnpgwと呼ぶことにして、バックエンド機能のlightMPDは lightMPDにバージョン番号やハード機種名をつけて表記することにします。

lightMPD-upnpgwですが、現在のところapu版が3年前に公開されただけです。rpiへの対応としては、最初に述べたdonuts.shop73さんがアレンジされた rpi用の rpi2 upnpgw-usb が lightMPDの掲示板で公開されています。rpi2という名前がついていますが、2/3b(+)で使えるはずです。

lightMPD-upnpgwのインストール方法については lightMPD-upnpgwの解説のページに詳しく説明されていますので、リンク先を参照して下さい。また、lightMPD-upnpgwの設定の仕方についてはUPnPの世界の二回目に説明してありますので、そちらも参照されるといでしょう。今回、レンダラ化したSymphonicMPDと接続しましたが、ipアドレスを変えた以外は全てそのままの設定で使うことが出来ました。
rpi用の rpi2 upnpgw-usb の設定は基本的には apu版のlightMPD-upnpgwと同じです。従って、上記のご本家の解説が参考になると思います。インストール方法は多少違って、fat32フォーマットしたマイクロSDカードに解凍したファイル、フォルダーを丸ごと書き込む方式をとっています。lightMPD-upnpgwよりシンプルですので、難しいところは無いと思います。

Linux連合軍レンダラーのフロント側の設定に関して、忘れてはならないことを。ポートフォワーディングをちゃんと設定しておくことです。ポートフォワーディングって何という方が多いと思います。僕もちゃんと説明出来るわけがないので、ここ(e-Words)を参照して下さい。
要するに、バックエンド側のLinuxマシンとssh/telnetやwebアクセスで通信をしたい。そのための設定です。
やり方は簡単で lightmpd.confの[nat]に使いたいサービスで使うアドレスを設定すればいいだけです。こんな感じです。

[nat]
        masquerade=network:player
        dnsforwarding=yes
        ntpforwarding=yes
        8022=10.0.0.2:22
        8023=10.0.0.2:23
        8080=10.0.0.2:80

dnsforwardingとntpforwardingをyesに設定して、以降、対応するバックエンドシステムのアドレスとサービスを設定します。この例ではssh、telnet、webの三つのサービスが指定されています。
バックエンドにSMPDを使った場合は電源を無条件に落とすことが出来ませんので、ポートフォワーディングを設定し、ブラウザから落とすということになりますので、この設定は必須です。

いよいよ本題のSymphonicMPDレンダラ化の話に入るわけですが、その前にrpi2 upnpgw-usbの設定について。
lightmpd.conf に関しては、ipアドレス以外はほとんど変更する必要はありません。ipアドレスも変更しているのは以下の部分のみです。

[network]
	interface=eth1
	address=192.168.1.60

eth1側にusb接続のLANアダプターが繋がっていますので、そちらを使うことになります。この他では[nat]セクションを弄っています。内容については、直前の部分を参照して下さい。

mpd.confに関しては、DSD再生をする場合はaudio_outputのdop “yes”を指定する必要があります。

audio_output {
	type "pipe"
	name "pipe"
	command "exec /var/lightMPD/bin/pcminfo_ncat.sh"
	dop  "yes"
}

また、audio_output_formatを対応する環境に合わせて設定する必要があります。

# Resampling All Files
#audio_output_format			"176400:24:2"
# Resampling Only DSD Files
#audio_output_format			"d176400:24:2"
audio_output_format			"*:32:*"

通常は“d176400:24:2”、DSD再生(DoP)をする場合は“176400:24:2”、hifi-dac-hatを使う場合は“:32:”。それぞれの意味についてはこのサイトの掲示板を参照して下さい。

長くなったので、SymphonicMPDレンダラ化については次回に。


p.s. 7月1７日 追記

JPLAY日本語デスクなる方から、「長期間のご支援感謝するが、お前は掟破りだから除名する」というメールを頂戴しました。ビックリしましたね。
「そうかい、それならますます自由に書けるようになるから、大変に結構。そちらも頑張ってね」とご返事したら、「掟の意味が分かっているのか、JPLAYの購入者は売買契約に縛られて、『契約締結者へ言論の自由を与えている条 項はありません』だぞ」と慇懃無礼かつ非論理的に脅迫されました。
あきれて、「根拠のない中傷は訴訟の対象となるだろうが、根拠に基づく批判を押さえつける自由国家は世界のどこにもありません。法というのは常識に基づくものであり、自分の都合よいように解釈しているのは独裁国だけです。」と返信したら、半日後に「今後はJPLAY FEMTOの利用をご遠慮いただくことになりました。」と処分が破門にエスカレート。なかなか返事が返ってこないなと思っていたら、マーシンさんを説得するのに時間がかかっていたようです。同じ返信に「マーシンに直接連絡いただいても、判断は変りません。」とありましたので。

通常の売買契約では起こり得ない顧客対応には驚きました。まあ、異議申し立ての訴訟をしても、勝てるとは思いましたが、バカバカしいので、素直に返金を受けることにしました。
JPLAY日本語サイトは自己に都合の悪い批判をする客は返金して追い出すという方針のようです。

このJPLAY日本語サイトは北の独裁国家顔負けの凄い論理でビジネスをやっているサイトですね。
賢治風に書くと、「内に鉄の壁を作って、顧客を囲い込み、言うことをきかない客はたたきつぶし、外に追い出す。外に批判する人あれば、正しい指摘であろうと中傷とみなし、訴訟をするぞと脅し、黙らせる。そんなサイトに私はなりたい。」ということでしょうか。

とりあえず、これ以上書くのはやめますが、本当にあきれ果てました。いくら音の良いソフトでも、これじゃ駄目ですね。


p.p.s. 7月19日 さらに追記

JPLAY日本語サイトがやりとりしたメール(個人の私信)を当方に断りなしに公開しています。
送信原文の内容には間違いはありません。
直前のp.s.に記述した内容と送信原文が対比して並べられており、相手(JPLAY日本語デスク)のメールもそのまま公開されていますので、読者の皆様がどちらの言い分が正しいか判断するのに分かりやすいだろうと思います。
折角ですので、許可は頂いてませんが、こちらからもリンクを貼っておきます。手間が省けたので、感謝します。
JPLAY日本語デスクなる人物はユーモアのセンスの無く、レトリックの分からない人ですね。かねてよりそう思っていましたが.・・・。


p.p.p.s. 7月20日 さらにさらに追記

何と呆れたことに、JPLAY日本語サイトの僕に関する記述が昨日書かかれた内容が全面更新されました。
あんまりだと思いますので、両方の記述を併記しておきます。サイトからのこの程度の引用は当然認められるでしょう。
昨日分

残念ながらJPLAY FEMTO利用停止対象ユーザーを発生させることになりました。
Terms of Service遵守を複数回お願いしたものの、尊重はするが個人の言論の自由が優先との返答があったためです。
Terms of Serviceは尊重や努力の目安では無く、JPLAY FEMTOの試用版ダウンロード時点から発生する義務です。
この方は当日本語公式ページにとって大恩人なので、当方の裁量内で最大限の例外的対応をして来ました。しかし全世界のJPLAYユーザーに平等に遵守を義務付けているTerms of Serviceについてはこの方だけ遵守を免除するわけにはいかず、譲歩できません。開発チームと慎重な協議を経ての判断です。
ご本人がブログで書かれている当方とのやり取りには創作された部分があるので、ここに実際に起きたことを貼っておきます。


本日分

残念ながらJPLAY FEMTO利用停止対象ユーザーを発生させることになりました
​PCオーディオ界のカリスマの方であっても、世界中の他のJPLAYユーザーと同一条件でお使いいただきます。
Terms of Serviceを遵守する意思表示をいただけませんでした。
規約違反による利用停止措置では無くJPLAY側都合のため、JPLAYからの返金の申し出を受理されました。
長期に渡るご支援に対し改めてお礼申上げると共に、今後もPCオーディオ界の牽引者として、JPLAY FEMTOを越えるものをぜひご紹介いただきたいと思います。

いつの間に「PCオーディオ界のカリスマ」になっていたのだろうか。これって、褒められたのだろうか。最後の暖かいお言葉に感謝です。ビックリしましたね。
やはり、一方的な契約解除では拙いから、「相手が返金を受けいれ、納得した上で利用停止した」ということにしたいようですね。
残念でした。まだ、「返金を受けいれ」てはいません。PayPalのJPLAY日本語デスクのメールアドレスを未承認です。従って、返金処理は完了していません。どうするかはこれから考え、対応するつもりで、暫くは放っておくつもりです。

ちなみに、その前に書かれていた「ポーランド法が適用されるなどうんぬん」の出鱈目な記述も消されたようです。これって、「私は間違っていました」と自分で認めているようなものですね。どういうつもりなのだろうか。
というわけで、折角やりとりのメールをリンクしておいたのに、リンクは無効となりました。これも一旦は公開したのに都合が悪くなったら消す。ひどいやり方ですね。こちらに僕の方で保存したものをリンクしておきました。


p.p.p.p.s. 7月23日 追記

またまた、トップページの内容が一部書き換えられたようです。
完全には正確ではない情報ですので、こちらに訂正します。
まず、原文の引用。

規約違反による利用停止措置では無くJPLAY側都合のため、JPLAYからの返金の申し出を受理され、送金先銀行口座情報などのご連絡をいただき直ちに送金を完了しました。


正確には日本の銀行口座番号を連絡したら、「次に日本に帰るまでは、処理できない。PayPalなら直ぐ処理できる」旨の返事がありました。仕方がないので、PayPalのアカウントを連絡したら、早速、送金されました。しかし、PayPal送金では、受け手が先方(送り手)を承認する必要があります。この承認はまだ行っていません。従って、現状はまだ送金は完了していない状態ですので、JPLAYサイトの表現は不正確です。
何で前回の表現(直前のp.p.s.の部分に引用してあります)をわざわざ修正されたのでしょうか。僕は返金の申し出は受理したことは認めているのですが。たまたまPayPalに変更したら、こちらの承認が必要と分かって、ちょうどいいので態度を保留しているだけですよ。
「マーシンに直接連絡いただいても、判断は変りません。」ということですが、判断が変わるのなら、受け取りを拒否してもいいです。まだ時間はありますから、ゆっくりご判断いただければ、よろしいかと思います。


p.p.p.p.p.s. 7月24日 追記

ランチ定食ではないが、ほとんど日替わりですね。一週間に5回。JPLAY日本語サイトのトップページの変更です。
今回は僕に対する一方的ライセンス剥奪の記載に関して、変更ではなく、削除です。全面的に消えました。注意事項の先に移されたのかなとリンク先もチェックしましたが完全に消えていますね。
この件は無かったことにしたいらしい。ちゃんとログはこちらに残してありますよ。無駄なことは止めましょう。
折角だから、ついでにアドバイスすると、どうせ削除するなら「注意」のリンク先の注意事項の「JPLAYユーザーはTerms of Serviceを遵守する義務を負います」という部分も全面的に削除された方がいいですよ。書いてある内容は完全に出鱈目だと判明しています。こんな嘘八百、残しておくと危険です。直ちに削除しましょう。

p.p.p.p.p.p.s. 7月25日 追記

何故、このように、毎日コロコロとサイトの重要な記述を変更するのでしょうか。こちらのアドバイスを受けて、今日は、注意事項のページから、TOSの解釈の部分が大幅に書き換えられました。
昨日、『出鱈目、嘘八百』と、かなり刺激的なワードを並べたのですが、別に抗議してくるでもなく、シラッと書き換えるとは。前の解釈に無理があったと認めているようなものではないでしょうか。
皆様の参考のため、旧新両方をここに残しておきます。

先ず旧です。

JPLAYユーザーはTerms of Serviceを遵守する義務を負います

このような内容をトップ・ページに特記しなければならないのはとても残念です。しかし、昨今のTwitterや匿名掲示板の書込みを見るにつけ、記述せざるを得ません。JPLAYは欧州私企業の商用製品で、多数決民主主義の原則や、いわゆる日本的な顧客至上主義とは無縁です。全てが売買契約に記載されています。

一部の勘違いユーザーの意向を反映した事業展開を受入れることは無く、JPLAYの運営方針や事業戦略についてユーザーから個別に意見を聞く体制にはありません。JPLAYは現時点で株式会社では無く、運営方針は全てJPLAYファウンダーのマーシンが決めます。当デスクはインフルエンサーとしてマーシンに助言できる立場にありますが、ユーザーからの意見や要望は当デスクから明示的に招待制フォーラムなどで依頼した場合を除き、受付けていません。

現状のJPLAYの仕様および運営方針を受入れる方へのみ、製品を提供しています。

運営方針にご自分の意思を反映させたい方は、開発チームに対し相当額を出資の上で行ってください。

当サイト経由あるいはJPLAY英語サイト、その他の販売業者を含め購入経路にかかわらず、全てのユーザーは全項目を遵守しなければなりません。試用版についても同様です。

ポーランド法に基づきポーランドの司法機関が管轄となります。日本の法規や司法機関は関係ありません。

英語だから理解できない、面倒だから読んでいない、翻訳が間違っていた等は免責事由にはなりません。

遵守する意思の無い方、掲載されている内容を理解できない方はJPLAYを使うことができません。他言語に翻訳して読むかどうかはユーザーの自由です。

以下の日本語の説明は便宜的なもので、この日本語文の解釈違いによって生じたトラブルについて、当デスクは責任を負いません。必ず英文原本を参照してください。

特にセクション12「禁止される使用」(f)誤情報や誤解を招く情報の頒布には注意してください。

当デスク未承認の状態で設定方法を個人ブログで解説したりSNSなどで質問に答える行為は全て抵触します。開発チームが記述した英文を他言語に翻訳して掲載した場合も同様に抵触します。原文と完全一致で引用元を明記した場合はOKです。

違反が発覚した場合、販売者はユーザーに対してサービスの提供を終了する権利があります。

セクション14「補償(インデムニフィケーション)」は「JPLAYおよびパートナー」に言及しています。当日本語デスクは「パートナー」として対象に含まれます。当デスクに対する妨害行為や誹謗中傷は、この条項に抵触します。

セクション16「終了」では、サービス提供者がユーザーの規約違反を疑った場合は、ユーザーに通知すること無く独断で契約を解除する権利を有するとの記載があります。一方的に打切りとなり、理由の説明義務はありません。


新です。

JPLAYユーザーはTerms of Serviceを遵守する義務を負います

Terms of Serviceを遵守する意思の無い方は、試用版を含めJPLAY製品の使用はできません。具体的に抵触行為を行ったかどうかとは無関係です。
残念ながらJPLAY FEMTO利用停止対象ユーザーを発生させることになりました。本件は世界中で初のケースとしてJPLAY側都合扱いとし、返金の申出に対し銀行口座情報などの連絡受理後直ちに返金を行い、完結しています。
試用版および製品版JPLAYは、ダウンロード・サイト、購入先にかかわらず、全て本Terms of Serviceの対象です。
​当日本語公式ページには相当の規約はありません。使用許諾契約、売買契約はJPLAY開発チームと直接締結されます。
以前は長々と説明していましたが、そもそもTerms of Service遵守前提で使ってくださいという当り前の単純な話です。上記の利用停止ユーザーについては、遵守の確約意思表示を拒否された結果の措置で、抵触行為があったわけではありません。既存ユーザーへのリマインダーとしてはその役を終えたと判断し、掲載から外しました。閲覧したい方は個別に問合せてください。個人情報提供に同意し、目的が明確であることが前提です。

日本語訳はあくまでも目安と明記してあったにもかかわらず自分で再度英訳し、原文との差異を質問した者がいました。
​原文はポーランドの法律事務所が作成しており、日本のコミュニティで法曹関係者以外が議論するような対象ではありません。
JPLAY FMEMTOの設定に関する質問は、必ず正規のサポート窓口へ送ってください。当日本語公式ページのフォーラム招待メンバーはフォーラムで、未招待者は問合せフォームでお願いします。私設サポートもどきへ質問しても何も解決しません。もし当デスクや開発チームでも解決できない問題の解を知っている人がいる場合は、まずその人を紹介してください。

何度書きますが、まだ「完結して」はいません。僕はまだPayPalのrefundを承認していません。
いまからでも、TOSを遵守しますといえば、認めてくれるのですかね。マーチンさんに聞いてみるかな。

マーチンさんも大変ですね。今のところは彼が責任者なのだから。あっちこっちで証拠の残っている脅しに近いインタネット書き込みへの修正要求はマーチンさんが望んで行われたものなのだろうか。そうでなければ、製品版購入の責任者の表記を、一刻も早く、その人物の表示にした方がいいですよ。これが今日のアドバイスです。

あと、製品版販売ページの契約条件の表記も、asoyajiさんのアドバイスに従って、変更しておいた方がいいですよ。今のままでは、インタネットで何らかの意見を公開したJPLAYユーザは、どんな意見であっても、「当デスクからの削除や修正要求に応じなかった場合、」フォーラムの追放処分を受けることになります。僕がそうでした。それどころか、ユーザであることまで否定されました。円満に別れてはいませんよ。

p7.s 7月27日 追記

音楽記号のp(ピアノ、弱音で)だって6個が最大です。7個目になっちゃったので、デジタルインターフェース技術用語風にp7.s.としてみました。
7回目の変更です。今度もTOSの解釈を巡ってです。ついにあの奇妙奇天烈な解釈が消えてしまいました。折角、毎回眺めては、大笑いしていたのに残念です。まだ鑑賞したい方は直前のp6.s.に残してありますので、こちらで我慢してください。
最新版は以下の通りとなりました。

JPLAYユーザーはTerms of Serviceを遵守する義務を負います

JPLAY FEMTOの設定に関する質問は、必ず正規のサポート窓口へ送ってください。当日本語公式ページのフォーラム招待メンバーはフォーラムで、未招待者は問合せフォームでお願いします。私設サポートもどきへ質問しても何も解決しません。もし当デスクや開発チームでも解決できない問題の解を知っている人がいる場合は、まずその人を紹介してください

これなら消費者庁のチェックでも合格ですね。
まあ、過去に書き換えた内容は証拠として保存してありますので、詳しくチェックされたい方は僕宛にメールをください。メールアドレスはこのページの一番下、右にあります。


(PC_Audio)   2019/07/13

コメントする

UPnPの世界 第二幕 その2(JPLAYfemto vs Linux連合軍)


前回に続き、Windows JPLAYfemtoを使ったUPnP構成について、説明を続けます。次はコントロールポイント。

JPLAYfemtoの構成でコントロールポイントについては、「DLNA対応のものを使ってくれ」という条件だけで、特別な制約はありません。ただし、推奨のソフトはあるようで、android端末についてはBubble UPnP、ipad系端末についてはmconnectということらしいです。
コントロールポイントを使う操作性については、「あんな鈍感なヤツと付き合っていられない」という反対意見も多いですが、マルチメディア、全ての情報を統一的に扱おうとすれば、ある程度ヨタヨタするのは(^^;;;しかたが無いでしょうね。
問題なのは、そのような多様性を切り捨てて JPLAYfemtoは開発されているために、コントロールポイントはかなりえり好みされるし、選ばれたヤツとの相性も必ずしもよくないということです。例えば、Bubble UPnPを使っても、意味不明に曲と曲の間で再生が中断するし、音楽データの在り処を変更すると、まず確実に再インストールするはめになるし、まれに表示されないデータが発生したりします。こういうトラブルに寛容でないと、付き合ってはいられません。まあ、同じようなことはLinuxのサーバやレンダラーでも発生しますが、発生頻度はJPLAYの方が多いという気がします。これは、選ばれし者の受難で、仕方が無いのかもしれませんが。

さてサブタイトルを「JPLAYfemto vs Linux連合軍」としましたが、JPLAYfemtoは単独で戦わないといけないというわけではありません。Linux連合軍からサーバを引っ張ってくるという手はとれます。
JPLAY v7はfemtoサーバーとfemtoレンダラーをペアで使うことにより高音質化しているという観点から言うと、このスカウト作戦は公式にはお勧めではないようですが、十分ありだと思います。

例によって音の良さを目で見て確かめるレスポンスモニタのグラフ。

まず、2.6M dsfファイルの再生。

Daphile NAS 6TB(i7-8700T)+JPLAY v7.0




次に、44.1KHz 圧縮レベル5のflacの再生。

Daphile NAS 6TB(i7-8700T)+JPLAY v7.0




前回のグラフと比較して、ご覧いただければと思います。
やはり、femtoサーバーのコントロールが利かない分、グラフの変動幅は大きくなっていますね。flacの変動幅にビックリされる方がいらっしゃるかもしれません。どっかの国の何とかアショアの候補地を不適と判定した担当者と同じ過ちをされた方々ですね。グラフの基準となる数値をご覧いただければお分かりのように、dsfとflacの変動幅は10M オーバ強で大体一緒です。切り取った部分だけではdsfの変動周期が分かりませんが、だいたいこの周期で定期的に変動しています。dsfの変動周期がflacよりかなり短い理由はよく分かりません。また、flacについては何故変動周期がfemtoサーバのコントロールが利いている時より長くなるのか、その理由もよく分かりません。
分からないことだらけですが、周期幅は大きくなってはいるが、一定間隔に抑えこまれていて、それなりにコントロールは利いているということは言えるかと思います。後は聴いての判断ですね。
聴いての判断については、あくまで参考意見ですが、掲示板でのこのあたりのやり取りをご覧いただければと思います。

さて、JPLAY v7 のUPnP対応についてはこの位にして、いよいよ本論Linux連合軍の内容に入りたいと思います。

Linux連合軍サーバー編

サーバー部分です。僕が試したことがあるのは以下の三つです。

MinimServer
MiniDLNA donuts.shop73さんがDSD対応させた版
Daphile DLNA Server

三つのソフト、それぞれ特徴があります。僕のお勧めはDaphile DLNA Serverです。

MinimServer

MinimServerは開発の歴史が長く、この中では一番実績があると思います。Windows版もあるので、どうしてもWindowsで使いたいという場合はこれしか選択の余地はありません。開発言語がJavaなので、LinuxでもWindowsでのJavaのインストールが必要です。そのあたりは、ご本家サイトに丁寧な解説がありますので、困ることはないでしょう。Javaのインストールがきちんと出来れば、MinimServerを動かすのは簡単です。Linuxのインストールに関しては、僕のサイトでも何度か取り上げたことがあります。こちらを参照して下さい。
Windowsのインストールに関してはご本家のサイトの解説を読めば、問題なく出来ると思います。「俺は英語は嫌いだ」という方は日本語でも紹介しているサイトが一杯ありますので、そちらをご参照されるとよいでしょう。
音は普通だと思います。僕は市販のNASサーバというものを使ったことがないので、比較することは出来ません。後述の二つと比較すれば、音質的には劣りますが、悪いということはないと思います。
この三つの中では一番安定しているので、僕はトラブル時の検証用(切り分け用)に使っています。

MiniDLNA donuts.shop73さんがDSD対応させた版

MiniDLNAはかなり前に開発が停止していますが、このソースをベースにdonuts.shop73さんがビデオ関連機能の削除し、DSD対応させた版があります。情報はここにあります。
音は良いので、お勧めです。当然、動かすにはソースにパッチをあて、ビルドする必要がありますので、誰でも使えるという訳にはいかないのですが。ちゃんとビルド出来れば、安定して動きます。
このサーバを簡単に使う方法があります。後で紹介するdonuts.shop73さんのrpi2-upnpgw-usbを使うというやり方です。
conf で Standalone-UPnPを選択し、lightmpd.confの

[minidlna]
# When db_dir is placed on NFS, minidlna doesn't work properly.
#  yes | no
	enable=no

を yes に変え、以降のminidlnaの設定を行えば、簡単に使うことができます。当然ですが、ハードはrpi-2/3bのみです。minidlnaの設定に関してはMiniDLNA - OpenWrt Wikiに詳しい解説があります。
大部分の設定はディフォルトのままで使えますが、ファイルの設定の部分はご自身のディレクトリに合わせる必要があります。下記のSDカードを使うのであれば、以下の通りとなります。

	db_dir=/var/lightMPD/nas/DBFILE/music

また、nas/MUSICDATAに対応する［nas:MUSICDATA］セクションを有効にしておく必要があります。［nas:MUSICDATA］セクションはsambaだけではなく、sd/usbが使えますので、デモなどで携帯用に持ち出す設定する時には便利でしょう。
例えばsdカードに音楽ファイルを置く場合は以下のセクションをコメントインするだけで、使えます。

## SD
#[nas:MUSICDATA]
#	type=vfat
#	host=
#	remotedir=/dev/mmcblk0p1
#	ro,utf8,codepage=932


Daphile DLNA Server

音はこの三つの中で一番いいです。というか、飛び抜けて良いです。僕の環境では、JPLAYfemtoサーバ以上の音がします。
インストールと DLNA Server の設定も簡単です。詳しくは前回の記事と記事の中にあるasoyajiさんのサイトへのリンクを参照して下さい。Daphileのインストールに関してはご本家の情報にも詳細な説明がありますが、asoyajiさんのサイトの方が分かりやすいと思います(まあ、日本語ですから当たり前ですかね)。

というわけで、「これが無条件にお勧めです」といいたいのですが、ちょっと待った。環境によっては安定性の面で問題があります。具体的には僕の環境で問題ありです。詳しくは掲示板のこのスレッドとこのスレッドを参照して下さい。問題なしとの報告もありますので、環境と使い方次第ということのようです。僕の場合はフォルダービューを中心に使っているので、この最初にフォルダービューを選べないというトラブルが顕在化するということです。

Daphile DLNA Serverに使えるハードはインテル(AMD)マシンだけです。rpiなどは使えませんので注意して下さい。
逆にサーバーに性能は要求されませんので、使わなくなったハードを活用するという方法がとれます。インテルハードを使った場合、ディスク、電源、LANなどを音に良いしっかりしたものに交換することで、効果を上げることができます。しっかり対策すれば、6桁クラスのバカ高い市販の音楽用NASを軽く凌駕する音を出せますので、お勧めします。

Daphile DLNA Server はLinux系のレンダラーと組み合わせて使わないといけないということはありません。僕はJPLAYと組み合わせて使っています。これでfemtoサーバの操作性の制限が解消出来ますし、音も良いので、お勧めです。
当然、JPLAY以外にJRIVERとかfoorbarなどのメイジャーなレンダラーと組み合わせることもできます。このような組み合わせの自由さはDLNA方式の大きな強みだと思います。もちろん、逆に、JPLAYfemtoサーバのようにDLNAの使い方を制限して、専用化し、高音質化を狙うというアプローチはありだとは思いますが。

長くなったので、第二幕主要部分の「SMPDをどうやってレンダラー化するか」については次回に。

(PC_Audio)   2019/07/06

コメントする

UPnPの世界 第二幕(JPLAYfemto vs Linux連合軍)


タイトルを考えていた時に「デジャブだなぁ」と思いました。3年位前に同じようなことを書いています。その時のタイトルが「UPnPの世界(JPLAYStreamer vs lightMPD/upnpgw)」。という訳で、今度は JPLAYfemto vs Linux 連合軍の戦い、第二幕の開幕です。

「前回はどんなタイミングで何を書いたのだっけ」と確認したら、JPLAY v6の使い方を10回連続して書いた直後に、lightMPD/upnpgwを紹介した時です。
この後、暫くはLinux関連の書き込みが続きますから、WindowsからLinuxへの第一回目の大転向ということになります。今回は第二回目。「節操のないやつだ」とお考えの方も多いでしょうが、本人はぜんぜん反省していません。要するに音の良いソフトが欲しいだけであって、素材はなんでもいいわけです。まあ、JPLAYとWindowsの暗い秘密主義にうんざりし、「自由でオープンなLinuxはやっぱりいいなぁ」とは思いますが。

前回は JPLAYStreamer vs lightMPD/upnpgw の戦いだったわけですが、今回は JPLAYfemto vs Linux 連合軍の戦い。この勝負、多勢に無勢、圧倒的にLinux側が有利です。難しいのはLinux側が芸達者のソフトだらけで、どう選択するか選択肢が多すぎることですかね。
また、ハードもLinux側の方が格段に選択出来る幅が広いです。当然、Windowsが動くインテルハードでもOKですし、apuというamd cpuですが、ネットワーク系のハードに最適な素材とか、ご存じ Rapsberry PI という超グローバルの格安ハードもある。他にもBBB/BBGとか、Nano Piとか、Ondroidとか、Tinker Boardとか、Cuboxとかいろいろあって目移りしますね。

あんまり手を広げても訳が分からなくなるので、ここではソフトは日本が世界に誇ることが出来る lightMPD と Symphonic MPD、最近日本で脚光を浴びるようになった Daphileに、ハードはインテルハード、apu1/2、Rapsberry PI 2/3Bに限定します。他にも魅力的なソフト・ハードはありますが、きりがないので。
このブログの愛読者から『「最近掲示板で話題のDaphileとSMPDの組み合わせで高音質化する方法について 」を記事にして欲しいが、「linux素人」にもわかるように、分かりやすく書いてくれ』というご注文がありました。
難問ですね。
僕は分かりやすいことを分かりにくく書くことは得意としますが(^^;;;、分かりにくいことを分かりやすく書くことは出来ません(^^;;;(^^;;;。どうしたものか。本来、Linuxの操作というものは分かりやすいはずですから、普通に説明すれば、お分かりいただけるはずです。とりあえず、その方法をとってみますが、分からなかったら、遠慮なく掲示板に質問して下さい。このサイトはMark Downと呼ばれる書式で書いているのですが、今回からフッターの部分をちょっと変更して「コメント」という部分を押すと、ダイレクトに掲示板に新規メッセージを書き込みに行く画面にジャンプするようにしました。

此処までが長い前置き。オペラでいえば、開幕前のロビーでのザワメキのようなものでした。

「UPnPの世界 第二幕」のはじまりです。といっても素直に初めないのはいつもの手口です(^^;;;。

まず、UPnPの世界は3年前と変わったか。あまり変化はないようです。
UPnPは十数年前に登場した技術だから3年位で変わるわけないだろうということですかね。DLNAというマルチメディア(なんと古い言葉だろう、30年以上経っています)関連の部分に限っても、大きい変化は起きていません。音楽の再生に限定すれば、Direttaという新しいプロトコルがデビュー。その行方やいかん。というところですかね。もっとも、DirettaそのものはDLNAとは無関係の技術で単に対抗馬というだけだから、DLNAの進歩という意味では関係はありません。

3年前と比較すればDLNAの音楽再生に関する技術用語は大分知られるようになりましたかね。
サーバー、コントロールポイント、レンダラーという言葉は今や当たり前です。タヌキでも知っているのではないだろうか。まだ、知らないよという方は、「今からでも、遅くない、こっそり調べる、DLNA」といったようなキーワードでググったらいかがでしょうか・・・・もちろん冗談です。DLNAとUPnPに関しては3年前の記事のリンク先に情報はあります。3年前のリンク先が今でも生きていて、有効ということが、この技術の変化の無さを示しているのかもしれません。


第一幕での構成です。
最初に試した構成は下表の通りです。

　　メディアサーバー　　コントロールポイント　　レンダラー
Atom Linux MinimServerNexus 9 KazoolightMPD/upnpgw(apu2c4)
Atom Linux MinimServerNexus 9 KazooJPLAYStreamer(Core i3-3225)


レンダラーから先の構成は
(usb) -> SHENZHEN社F-1(spdif) -> JOB社DAC96

というものでした。

そのあとタンデム構成を試しました。こちらはメディアサーバー、コントロールポイントの部分は同じで、レンダラーの部分を二台連結した構成にしました。

レンダラーフロント upmpdcli/polipoレンダラーバック MPD
lightmpd-upnpgw-apu2-v1.0.0(apu2c4)lightMPDapu1-v1.0.2-64(apu1d2)
lightmpd-upnpgw-apu2-v1.0.0(apu1d2)lightMPDraspi2-v1.0.2(rpi-2b)


この時、下段の構成はi2s接続でTeraBerry DACと繋いでいます。この当時、i2s構成がようやく一般に認知され、lightMPDもサポートをはじめたころだったと思います(まだSymphonic MPDは登場する前です)。

表をご覧になって感想はいかがですか。僕の感想は「変わっていないなぁ」です。
apu1はディスコンになったようですが、apu2、rpi-2bはオールドモデルとはいえ、まだ販売されていますし、Atom Nexus 9 Kazoo、Linux MinimServerとlightmpd-upnpgwはまだ現役です。唯一、JPLAYStreamer(Core i3-3225)が完全に入れ代わりました。このあたりも、LinuxとWindowsの差を示していますね。

どうせだから、今回も使う予定の apu2+apu1 の写真をそのまま引用することにしましょう。



赤い箱に入ったやつがapu2です。ご覧のようにapu1とは基板のレイアウトが多少異なります。

このハードの特長はLANアダプタが三つあることです。apu2では無線LANにも対応しています。
DLNAをネットワーク構成する時、LAN回線を二本以上必要という場面は結構あり、そういう時に重宝します。性能もそこそこ出て、音も良いです。弱点はUSB周りですかね。基板レイアウト上ノイズに弱いという指摘があります。もっとも、このあたりは他のSICでも同じようなことが言えそうですが。

ところで、第二幕の「構成」の話に入る前に、例よって脱線します。

構成の呼び名について。先程、二台の構成をタンデムと書きました。これが正しい表記だと思います。よくこの縦型に二台のパソコンを連結させる構成はデュアルと呼ばれますが、これは誤りです。僕もJPLAYの二台の構成の時、JPLAYのマニュアルにDualと表記されているので、仕方が無く、デュアルという呼び方をしていましたが、違和感がありました。情報処理用語を調べて頂くとわかりますが、デュアル構成とは

「デュアルシステムとは、情報システムの信頼性を高める手法の一つで、システムを2系統用意して、常に同じ処理を行わせる方式。結果を相互に照合・比較することにより高い信頼性を得ることができ、片方に障害が生じた際も、もう片方で処理を続行しながら復旧にあたることができる。」

という意味です。JPLAYの「デュアル構成」は負荷分散のために処理を二台のパソコンに分ける方式であり、デュアル構成ではありません。Marcinさんが Dual Construction の正しい意味を知らないわけが無いので、一般の人に分かりやすくするため、わざと間違えた使い方をしているでしょう。しかし、情報処理試験受験者を惑わす言葉の使い方はどうかと思いますので、ここでは正しい定義の用語のタンデム構成と呼ぶことにします。

本論に戻ります。

第二幕での「構成」です。まず、JPLAYfemtoから。

Windows JPLAYfemto

JPLAYfemtoサーバー --> コントロールポイント --> JPLAYfemtoレンダラー

JPLAYfemtoはサーバーとレンダラー機能の両方を持っていますので、こういう構成になります。この組み合わせで使い、サーバー機能とレンダラー機能を連携させることにより、高音質化を実現しているわけですね。一方、このために犠牲になっている部分もあります。具体的にはfemtoサーバーは曲の選択に関してDLNAの全ての機能をサポートしているわけではありません。フォルダービューのみサポートします。従って、一部の方からみれば、使い物にならないということになります。
JPLAYfemtoサーバーの音楽ファイルを格納するディスクとしては内蔵DiskかNASを使うことが出来ます。
ただし、NASについてはWindows10(Server2019?)では制限があり、ファイル共用を設定し、「\\」でNAS名を定義しただけでは使えません。これはJPLAYfemtoサーバーの共用ファイルの扱いが、音質優先のために、標準でないやり方をしているように見えます(推定です)。従って、NASを使うには高いハードルがあって、普通のユーザが簡単に使えるというものではありません。NASを登録する方法についは僕のサイトでも取り上げたことがあります。このページを参照して下さい。掲示板にも参考になる記事があります。

問題だと思うのは、このために日本でのJPLAYのプロモーションでは「NASを無理に使うことはない。ディスクでもNASでも音質的には同じだから」という主張が展開されていることです。

この主張に対して反証するデータをお目にかけましょう。 僕の環境でDaphile NAS 6TB(i7-8700T)とハードディスク 6TB(i9-9900T)を使って、レスポンスモニタでネットワークの負荷を測定したグラフです。
まず、2.6M dsfファイルの再生。

Daphile NAS 6TB(i7-8700T)



ハードディスク 6TB(i9-9900T)




次に、44.1KHz 圧縮レベル5のflacの再生。

Daphile NAS 6TB(i7-8700T)



ハードディスク 6TB(i9-9900T)




いかがですか。まるで違うでしょ。これで音質的に同じなわけが無いです。差は聞きとれるはずです。

どちらがいいかは聴いての判断ですが、僕はNASの便利ですから、NASを使っています。
グラフの形で見れば、dsfファイルの再生では、NASが有利に見えます。flacについていえば、ハードディスクが良いとも見えますが、変動が周期的にきちんとコントロールされているのはNASです。いずれにしても、どのケースでも、ネットワーク負荷はかなりのレベルでコントロールされていて、このあたりはJPLAYfemtoの優秀性を示していると言えると思います。

さて、いまだに第二幕の前奏曲の半分が終わったレベル。脱線だらけで、肝心要のLinuxの話に入っていませんが、長くなったので、次回に続くです。

(PC_Audio)   2019/06/29

コメントする

Amazonのおバカ !


本当は「UPnPの世界 第二幕(仁義なき戦い JPLAYfemto vs Linux連合軍)」というタイトルでSMPDのDLNA化の話を書くつもりだったのですが、ググっていたら、あんまりビックリしたので、急遽予定変更。
「Amazonのおバカ !」です。

挑発的なタイトルは大好きです。「License Expired Godzilla の逆襲とDaphileの福音」とか、「Your page is not mobile-friendly.」とか、「怨念のJPLAY-JRIVER対決にfemtoで決着できるかな ?」とか、「NewJPLAY騒動顛末」とか、「サルでも作れる MPD on Arch Linux」とか、いろいろ書いてきましたね。

しかし、この「Amazonのおバカ !」は本当にそうなのです。ビックリマークを遠慮して一つだけにしましたが、本当は10個位付けたかった。まあ、みみず工房の品位があまり落ちるのは拙いだろうと考え、自制しました(^^;;;。

何で「Amazonはおバカ」なのか、以下、証拠をご覧いただきたいと思います。

この画面は僕のAmazon IDでログインした直後に表示される画面です。



こういう具合にジャンル別にお勧めの推薦メニューが表示されます。順番に見てゆきます。



趣味・実用というメニュー項目がありました。「何か様子が変だ」と思い、クリックしてみました。



何で、ラズパイ/Linuxと童話/読み聞かせの本が並ぶのだろうか。不審に思い、画面右の矢印ボタンをクリック。



暫くは、こんな感じで、ラズパイ/Linux関連の商品の紹介が続きました。 ところが，次のページ。



「赤ちゃんスタイとは何じゃ」とビックリ。次のページ。



赤ちゃんの間にラズパイのEnokayとかいうヒートシンクをご推薦。これ、オモチャのようにも見えるのかな。次のページ。



いよいよ、支離滅裂の極み。何で、オーガニックコットンと、アルミニウムヒートシンクと、赤ちゃんまいにちの小物と、ネットオーディオが同居するのだろうか。次のページ。



今度は真空管とまたスタイ。真空管は以前、真空管キットを検索したからですかね。次のページ。



あら、またラズパイとスタイに戻りました。次のページ。



「デジタルオシロスコープ活用ノート」とはよくチェックしているね。立派。ところが、最後のページ。



「あかちゃんのために作るもの」で締めるのでありました。

賢明なる読者皆様は既にお分かりのように、このAmazonのおバカなAI(なのかな?)はIPアドレスは区別するけど、人は区別できないようですね。
実は1台のパソコンを共用しているわけではなくて、Nexus 9(Amdroid端末)を貸し出しているだけなのですが、誰がアクセスしているかなんてことは Amazonのおバカ AIの知ったことではない。どっちも同じ人物だと確信したら、どんな矛盾する趣味趣向だろうと、同じヤツだと決めつけて、最適の商品をご推薦するという仕掛けになっているようです。

まあお勧め商品の推薦位だったら笑っていられるけど、こんな調子で自動運転、園児の隊列に突っ込むなんてならなければいいけど・・・・。

(internet)   2019/06/22

コメントする

License Expired Godzilla の逆襲とDaphileの福音


「何だこのタイトルは、意味不明&支離滅裂だ」といわれそうですが、これから書こうとすることをワンフレーズで表現するとこうなるのですよね(^^;;;。

JPLAYの7.0dリリースから半年、半年間の地下潜伏期間の期限が切れて、JPLAY License Expired Godzilla の逆襲があっちこっちで頻発しているらしいという噂は聞いていたのですが、これは違う話。

しかし、 その前にちょっと脱線。

「半年間の地下潜伏期間の期限」というのは、インタネット接続なしにJPLAYを使い続けられる執行猶予期間のことです。
「オーディオマニアたるもの、インタネットという音を悪くする悪の巣窟にみだりに近づくなかれ」と信じる信者達が、ライセンス認証が終わったら、直ちにLANケーブルを引っこ抜き、地下に潜る。しかし、License Expired ゴジラは甘くない。地下に潜っている輩を半年おきに摘発する仕組みになっているようです。
従って、心がけ良き信者達は半年おきにメッカ詣ではならぬ、地上に出て、インタネットに繋ぎ、聖杯ならぬ認証を受けねばならない。しかし、そんなこと、不信心の輩は忘れるわけですよね。その阿鼻叫喚の叫びのスレッド(文字通り「License expired」というタイトルです)がJPLAYご本家のフォーラムにあります。まあ、こういうスレッドが公開にされ、誰にでも読めるようになっているということは賢い運営方法だと思います。
もっと信仰心の薄いゴンザンモンさんはさらに酷い目にあわれたようで、その詳細はこちらにあります。自身のソフトの世代管理はそっちのけにして、半年たった不信心ものをヤツケるのにやっきになるというのは矛盾だと思いますが、License expired ゴジラの真骨頂ここにありですね(^^;;;。

さて、本題に入ります。
Daphileというインテルハードで動くLinuxの音楽ソフトがあります(amdでも大丈夫なようです。後述のdigififanさんの書き込みではapuで動されています)。このソフト、2013年に登場して6年たちますが、日本ではほとんど知られていなかったと思います。
僕はこのソフトをCDのリッピング専用に使っていました。Daphileは非常にコンパクトに作られいて、USBメモリから起動することかできます。普段nas用に使っているatom機をCDのリッピングする時だけUSBメモリからの起動に切り換えて、使っていました。この方法だとリッピングしたファイルを簡単にnasに持ってくることが出来ます。また、Daphileの場合、ディフォルトでリッピングはCDをセットするだけで自動的に始まるという設定がされていますので、とても便利です。
さて、このソフトですが、asoyaji さんが「Daphile　驚きの高音質」というタイトルで記事にされたので、日本でも一躍名前が知られるようになりました。
みみず工房の掲示板でも話題になり、とんぼのめがねさんが「Daphile & Smpdplayer 実はとても仲良しだった！」というスレッドを起こされました。「DaphileをDLNAサーバとして使うととても高音質です」という内容です。

どちらの書き込みも超絶賛ですので、気になって、「これは確かめてみないといけない」と思いました。高音質の確認なので、「USBメモリ起動のatom機ではまずいだろう」と考え、JPLAY専用に使っているJ5005機を使うことにしました。このマシンは電源をFidelix製のローノイズ電源を使っていますし、箱もしっかりしたものなので、信用できます。しかし、これがゴジラの目を覚まさせたようです(^^;;;。

JPLAY専用マシンをJPLAYとDaphileの共用マシンに変えます。この時、余計なトラブルを避けるため、現在のJPLAY側は一切手を入れずに、新しくDaphile用のハードを追加することで対応しようと考えました。具体的には

<ネットワークトランスポート>
Intel J5005 + GUSTARD U16 
┣OS：Windows JPLAYfemto SSDディスク(60GB)
┣OS：Linux Daphile 2.5インチハードディスク(16GB)
┣データ：3.5インチハードディスク(4TB)
┗電源：Fidelix

という具合にJPLAYとDaphileを完全に分離し、影響の無いようにしようとしました。
更に念を入れて、DaphileのインストールはJPLAYの入っているSSDディスク(60GB)のケーブルをはずして行いました。

Daphileのインストールは簡単ですね。ダウンロードしたイメージをUSBメモリに書き込み(僕はrufusというソフトを使っています)、起動するだけです。繋いだディスプレイにipアドレスが表示されますので、その番号をブラウザから入力すると、こんな感じの初期画面が出てきます。




settings -> System Firmware -> New Installation -> ドライブの選択 -> Install でインストールできます。
再起動後、settingsで音楽用のドライブ(ディレクトリ)を指定すれば、使えるようになります。ちょっと気が付きにくいのは、DACデバイスが複数あった場合の選択は画面右下で行うことですかね。
操作は全てウェブ画面で行えますので、Windowsユーザでもまったく困ることはありません。文字通り、お猿で出来るレベルです。
試しに音を出してみましたが、素晴らしい音ですね。十分使えると思います。

という訳でここまではスイスイと快調に進みました。さて、本命のDLNAサーバの設定に入る前にマルチブートがちゃんと出来るか確認してみようと思いました。なんとなく胸がザワツキ、悪い予感がしたが、やってみました。

SSDディスクを再度繋ぎ、Bios画面で起動ドライブをSSDディスクに変更。起動してみる。問題なくWindowsが立ち上がる。ここまでは、問題が起きる筈がないので、当たり前です。次に、JPLAY Settingを起動する。ジャーン。
「お前の時間は狂っている。正しい時間にあわせろ。(英語ですが、詳細は忘れました)」というメッセージのダイアローグが出現。
「ドシラ・ドシラ・ドシラソラシドシラ」。ゴジラのメロディが頭の中で鳴り響きました(^^;;;。



　　　　ゴジラのテーマはTrioCompact さんのサイトの楽譜を使いました。ありがとうございました

時間を確認しましたが、ちゃんと設定されています。
うーむ、また出てきたようね。OKボタンを押す。例によってゴジラ画面が出現。この画面は過去何回か紹介しているので省略。ただなんとなく様子が違うなという感じがしました。
試しに思い、TurboActivateを起動してみる。こんな画面が出現。



「なんだ ! 」ちゃんと認証されているようです。ということはSetting画面だけが挙動不審ということになる。こういう場合はもう一度クリーンインストールするというのが掟らしいので、(変なルールだけど、抵抗しても時間の無駄なので、)早速やってみました。
しかし、状況は変わらず。Setting画面ではまたゴジラが出現。TurboActivateが「問題ないよ」というのも同じ。

途方にくれる。「どうなっているのだ」とMarcinさんに直接問い合わせようかとも思いましたが、取り敢えず、こういう時はゼロリセット。JPLAYの得意技。OSの再インストールをやってみる。こんなのが得意技とはなんたるソフトと思いますが、仕方が無いです(^^;;;。
OSの再インストールに約1時間。Daphile のインストールは約10分で終わっていますから、Linuxの方がよほど融通が効くねと痛感しましたね。
再インストール後、Settingを起動。再びゴジラが登場。この時、「試用期間は終了しているから正規ライセンスを購入しろ」というメッセージが出ました。
そこで、TurboActivateを起動してみる。今度はライセンスキーの入力が要求され、入力してみました。初期認証時と同じような画面が表示され、認証は正常に終了。
もう一度Settingを起動。ゴジラは出ません。海に帰りました。OS再インストール後の最初のSettingでゴジラが出たのは認証前であったことが原因であったようです。ヤレヤレ。The END。

しかし、このトラブル、「JPLAYのDaphileに対する嫉妬心が License Expired ゴジラの逆襲をまねいた」としか思えませんね。トラブらないようにディスクを完全に分け、biosで起動ディスクを選ぶという方法で試したのですが、それでもゴジラは健在でした。ゴジラはbiosの闇の中に生息し、憎きLinux音楽ソフトを監視しているように見えます(^^;;;。
冗談はさておき、たかが biosによる起動ディスクの変更だけで、動かなくなるとは「なんたる出来の悪いライセンス管理ソフトだ」と悪態をつきたくなります。JPLAYがこの認証ソフトを選んだのは、v7開発の最大の失敗じゃないですかね。

「ハードを変えて、複数台の認証を許す」という認証方式に関していえば、JPLAYのライバルのJRIVERの方が優れていると思います。
こちらは新規インストールが、ハード、OSの条件とは無関係に、年間10回まで出来るという方式をとります。回数だけで管理しますので、JPLAYとは逆に自身やOSの再インストールは回数を増やす事になり、禁じ手となります。しかし、10回という制限はゆるやかですから、数回のやり直しは許容範囲です。実際使っていて、10回を越えてインストールしたことはなく、不便を感じたことはありません。また、こちらの方が認証ソフト/センタが管理するのは回数だけなので、はるかにシンプルに管理することが可能となります。従って、トラブルにあったこともありません。


さて、ゴジラにこだわるのはこの位にして、Daphileについて。
このソフトのベースはSqueezeBoxですね。SqueezeBoxについてはこのサイトで以前取り上げたことがあります。こちらを参照して下さい。
全てブラウザでコントロールし、プラグインで機能拡張というやり方は同じですね。

ベースにしているLinuxディストリビューションはGetoo Linuxのようです。あまり馴染みのないディストリビューションなので、ちょっと戸惑うかもしれませんが、操作はする上では、ブラウザベースですから、関係ないです。
Daphileの構成については、digififanさんが鋭い分析をされていてます。Daphileのイメージの大きさがたったの200MB程度。「このコンパクトさはなあに?」と思っていたので、

beta版でsshできることがわかったので、sshでloginしてみました。
rootfsはbuildrootで間違いないと思いますが、システム全体はなんらかのlive cd システムがベースになっているようです。

と書かれているのを読んで、眼から鱗。「なるほどなぁ」と感心しました。また、

/proc/asound 配下のファイル構成が通常のものとちがうので 、alsa周りは独自の改造が行われているようです。

ということなので、音の良さの秘密もこのあたりにあるのかもしれませんね。

このソフト、よく分からないのは現時点で誰が開発を担っているかということです。ご本家のサイトには問い合わせはできるようになっているが、作者に関する情報はまったくありません。自前のフォーラムのようなものも無いし、このあたり不思議なところです。情報としては、開発開始時点から現在まで、diyAudioのスレッドでいろいろなやり取りがされていて、ここが一番生の情報が集まっているようです。2013年7月このスレッドの開始のメッセージはKipetaさんというフィンランドの方が書いています。多分、この人が最初の開発者だったのではないかと思います。ただ、その後、Kipetaさんは登場しなくなり、現時点では誰が開発しているのか分からなくなっているのですよね。
このあたり、謎です。

Daphileの開発の歴史はご本家のサイトにチェンジログがありますので、これを見れば、どんな具合に開発が進められて来たか分かります。直近の大きいアップデートは昨年の7月で、DSDサポートやSpotty-pluginが大幅に機能強化されています。今年の1月にはカーネルを最新にするなど、開発はきちんと継続されているようですね。

Daphileの音楽ソフトとしての全体構成はJRIVERとの共通点が多いと思います。具体的には旧来のプレーヤベースで音楽ファイルを管理、再生する機能をベースにして、UPnP対応などの最新の機能が後から付加されている点です。レンダラー、サーバの両刀使いで、ディフォルトでsambaが使え、設定すれば、DLNAサーバにもなるというところがとても便利で、凄いです。またCDのリッピング機能やファイル管理機能がディフォルトで有効になっていますので、音楽ファイルの管理という面でも使いやすいです。これらの機能を使った再生音質が水準が高く、素晴らしいです。ストリーミングサービスもAirplay、Spotify、TIDAL、Qobuzなどに対応し、頑張っているようです。
これらのDaphileの機能は全てウェプのSetting機能で設定出来るようになっていますので、丁寧にチェックすれば、設定に困ることはないでしょう。ただUPnP機能は例外で、プラグイン機能を有効にして、レンダラーを立ち上げ認識させる必要があるので、ちょっと設定が面倒です。このあたりがこの記事の最初の方でリンクしたみみず工房の掲示板のやりとりで、謎解きされていますので、ご紹介します。
見事に謎解きされた、とんぼのめがねさんに感謝します。

Setting画面を表示させます。



画面一番下にある「Advanced Media Server Settings」をクリックします。



こんな画面が表示されますので、上、真ん中あたりの「Plugins」タブをクリック。
Inactive Plugins から「UPnP/DLNA Media Interface」という名前のプラグインを捜します(アルファベット順ですので、最後の方に出てきます(下図)。



見つけたら、チェックボックスをマーク(上図)。次に、3rd Party Plugins(真ん中あたりの行)の終わりの方にある上記画面の一番下に見える「UPnP/DLNA Bridge」という名前のプラグインを捜します。



見つけたら、同じくチェックボックスにマーク。画面右下の「Apply」をクリック。この後、Daphileの再起動となりますので、再起動後、登録されていることを確認します。



こんな感じになります。「UPnP/DLNA Bridge」の右にある「Settings」をクリック(advancedタブからUPnP/DLNA Bridgeを選択しても同じ画面を表示させることが出来ます)。



こういう画面が表示されますので、Upnp/DLNA bridge設定を行います。
①レンダラーを動作させて、ネット環境上で立ち上がっている状態にします。
以下、Upnp/DLNA bridge画面（今出ている画面）での設定です。
② Start the Bridge項目にチェックを入れる。
③ Select Binary項目でsqueeze2upnp-x86-64-staticを選択する。
④ 右下のApplyボタンを押すす。
この後、「スキャンしているから待ってね」(英語です)という感じのダイアログが出ます。20～30秒待っていると次の画面が変わります。



これでメデタシメデタシ。完了です。

Daphile DLNAサーバの高音質に関して、先のdigififanさんの分析で興味深い記述があります。

10年ほど前にsqueeze box を使っていたときに日本語のタグが文字化けするので、lmsのソースを見たことがあります。
音楽データを playerに送信する時に一気に送信するのではなく、定期的にちょっとずつ送っていました。

通常のdlnaは一気に送信していてフロー制御はtcpにまかしています。その為、polipoのようなキャッシュをかますと送信は数秒で終了します。

lmsのdlnaのモジュールはsqueeze playerにデータを送るような制御をしているのかもしれません。

JPLAYfemtoのサーバ機能がOpenHomeを捨てて、わざわざ古いDLNAを採用したというのは有名な話です。そして、データの送り方もレンダラー側に負荷を均一にかけるため、データを細切れにして「定期的にちょっとずつ送る」ような方式をとっているのも、リソースモニタで確認できます。これが、JPLAY v7の高音質化の有力な手法といわれていますが、引用したdigififanさんの分析に見事に一致していますね。
どうもこのあたりに音の良さの秘密がありそうですね。

ちなみに、このDaphile DLNAサーバを使い、lightMPD/upnpgw(apu1d フロント)とDLNA化対応させたSMPD 0.8.15(rpi-3b バックエンド)を組み合わせた音は JPLAYfemto を軽く凌駕する音質となります。
また、lightMPDのapu2用最新版(1.2.0試用版)は確実に進歩していますね。これをlightMPD/upnpgw(apu1d フロント)とタンデム方式で組み合わせ、Daphile DLNAサーバを使うことが出来ます。こちらも素晴らしい音質です。SMPDの最先端、カリカリにチューニングされた音とはちょっと異なり、JPLAYのような落ち着いた雰囲気のある音になります。
次回以降はこのあたりのやり方を取りあげていこうかなと考えています。

なお、この記事の一部の画像は不精をして、sugi-さんがアップロードされたものをそのまま使いました。sugi-さんにお礼申し上げます。

(PC_Audio)   2019/06/15

コメントする

Monteverdi Meets Jazz


「モンテヴェルディがジャズに出会った」というタイトルのCDです。横浜のタワーレコードで安売りをしていたので、ついフラフラとget。ラ・ヴェネクシアーナというモンテヴェルディ演奏では定評のある団体のCDですが、ジャケットはまるでジャズのCDですね。




The past must be invented. 
The future must be revised. 
(John Cage)

ライナーノートの最初にヴェネクシアーナの指揮者カヴィーナさんのCDを紹介する文があるのですが、その冒頭に引用されているJohn Cageのフレーズです。ちょっと僕の英語(日本語)力では訳しようがないのですが、まさにこのCDにピッタリですね。モンテヴェルディを音楽を使って、ジャズをやる。「過去を発明して未来を訂正する」という訳です。

ロベルタ・マメリさんはバロックの声楽曲がメインレパートリーのソプラノ歌手のようですが、ジャズシンガーも真っ青という位、上手いです。16世紀をそのまま20世紀にタイムスリップさせた(逆かなぁ?)という感じで聴けます。最初の「ニンファの嘆き」は有名な曲ですから、誰でも知っているわけですが、「なるほど、こうやるか」という感じで、変曲(この変換いいね^^;;;)されます。



この企画をたくらんだのはカヴィーナさんのようですね。写真にある4人のジャズプレーヤを抱き込んで、ラ・ヴェネクシアーナのメンバ達にぶつける。写真では結構普通に指揮をしているように見えますが、どうだったのですかね。



ライナーノートにあるロベルタ・マメリさんの写真です。どうみてもジャズですね、この格好は。この服装で古楽を歌えば、もっと古楽ファンが増えるのじゃないだろか(^^;;;。
曲目はご覧の通りです。Monteverdi meets というが、半分は同時代周辺の作曲家ですね。ジャズ向けに変曲しやすい曲を選んだということだと思います。

カヴィーナさんの解説によると「We have changed nothing of the original vocal lines and bass - not a single comma. 」ということなので、いわゆるジャズ風のアドリブは無しですが、ソプラノとベースの装飾的な動きやサックスとギターによる中声部の即興によって meets Jazz させたということです。これが非常に上手くいっていると思いました。
第1曲目の「ニンファの嘆き」をIMSPLからダウンロードした楽譜を眺めながら、聴きました。確かに女声とバスのパートは楽譜通りですが、装飾的な動きによりモンテヴェルディを20世紀ジャズクラブに連れ込む。そして、サックスとギターが「こういうのもいいでしょ」という感じの即興をして、モンテヴェルディをジャズの世界に変えてしまうのが凄いです。 以下、同じ手口で続きますが、アップテンポの曲はジャズ側の応援団が上手いですね。ノリがとても良くて楽しめました。

(music)   2019/06/09

コメントする

Your page is not mobile-friendly.


いつの頃からか、さだかには覚えていませんが(源氏物語の書き出しみたいね^^;;;)、ググっていて、自分のサイトが表示された時、“Your page is not mobile-friendly.” と表示されるようになりました。



ちょっと前に、Googleから「お前のサイトは mobile-unfriendly だから、何とかしろ」というようなメールが届いていました。「うるせいヤローだ。モバイルなんか知らねーよ」と考え、無視していました。

最近、「Symphonic MPD」というキーワードでググったら、掲示板の書き込みは表示されるが、サイトの記事は表示されないということに気が付きました。Googleのヤローは mobile-unfriendly なページを蔑視し、検索順位を下げるというような操作をしているのですね。「このGoogleヤロー」と思ったが、試しにと考え、手持ちのファーウェイを使い、自分のサイトをアクセスしてみました。





「なるほど。これは酷いね。読めない」と納得。もっともアンドロイド端末ですから、親指と人指し指を使って、拡大することができます。こんな感じ。




「これなら十分読めるじゃないか」とは思ったが、一つ前の縮小表示されている画面の一番下に「簡易表示をする」というバーがあります。これをクリックすると、こんな感じの画面になります。





「問題のある部分を省略して表示させているわけね」と納得。ヘッダー部分かフッター部分が問題を引き起こしているらしいと分かりました。
という訳で、どうやって直せばいいのか知ろうと考え、一番最初のGoogle検索画面の“Your page is not mobile-friendly.”という部分をクリックしてみました。こんな画面が表示されました。





やっぱり画面幅に対して文字を詰め込んでいるので、小さく表示されすぎるということらしいですね。
しかし、このGoogleのページ、恐ろしく不親切ですね。悪いところは指摘するけど、どうやって修正するかについては一切記述なし。「詳細はこちら」などというリンクあるので、クリックしてみましたが、「お前の醜さをクドクドと説明してやるぞ」という感じで、解決には何の役にも立ちません。
「人のサイトを醜いからと蔑視し、ランクを一方的に下げておいて、解決策を何も示さないととは何事だ」とどなりこんでやろうかと思ったが、大人げないので、やめて、ググる(^^;;;。解決策を捜すのにも、憎っきGoogleに頼らざるを得ないとは。高給を出してくれるから、悪徳会社に働かざる得ない社員みたいな気分ですね(^^;;;。

しかし、いくらググっても、あまり有力な情報は見つかりません。自分で考えろということらしい。
僕のサイトはmd(Mark Down)と呼ばれる書式で、内容だけを書いて、ヘッダーやフッターはrubyのスクリプトとテンプレートを使い、自動的に作成するという作成方法をとっています。従って、ヘッダーやフッターの問題であれば、テンプレートの修正で済みますので、多少手間はかかるが簡単です。
htmlのソースを眺めて見ました。どうもヘッダー部分で横幅の指定をテーブルを使って行うという古典的手法をとったのが災いしているのかなという感じです。テンプレレートのこんな行です。 

＜table style="width: 98%; height: 25px; text-align: left; margin-left: auto; margin-right: auto;" border="0" cellpadding="0" cellspacing="0"＞
＜tbody＞
・・・
＜/tbody＞
＜/table＞


この部分を、二行になってもよしとし、テーブルを使わずに指定することにしました。 こんな感じで出力されるようになりました。




これならいいだろうと考え、mobile-friendly をテストするGoogleのサイトに行って、試してみました。結果はNG。またしても一つ上のmobile-friendlyじゃないという画面がでます。
「うーむ。この頑固ヤロー。どこが悪いというのだ。」と怒る。しかし強欲悪徳な検索サイトには勝てません。
画面をよく読むと「ビューポートが設定されていません」とある。「ビューポートって何だ。そんなものを設定した記憶はないぞ。」とまたググる。どんどん悪の泥沼に嵌まっていくという感じですね(^^;;;。
しかし、とうとう、こんなサイト「もう逃げない。HTMLのviewportをちゃんと理解する」を発見しました。
「なるほど。HTMLに画面サイズを指定するviewport句というのがあるのね」と分かる。このサイトの記述とてもよく出来ていて(Googleヤローに見習ってもらいたいものです)、呪文の唱え方も教えてくれるので、その通りにしました。
再度mobile-friendlyテストを通す。結果は



となりました。メデタシメデタシ。
結局、mobile-friendlyという名前の関所には Google という悪徳代官が住んでいて、こいつはこういう免罪符を差し出さないと関所を通してくれないということでした。

＜meta name="viewport" content="width=device-width,initial-scale=1"＞

この呪文の意味は「代官さま。このページの縮小率の初期値は1(縮小しない)でございますが、端末の大きさに合わせてデータを並べていただいて結構でございます。」ということらしいです。
「ヤレヤレ大変だったなぁ。釈然としない部分は残り、腹が立つつなぁ」という感想ですが、これ以上、悪態をついても、こっちの品位が落ちるだけだから(^^;;;、我慢することにしました。

p.s. HTMLを引用している部分の＜＞は大文字ですので、ご注意ください。そのままコピー&ペーストすると悲惨な運命が待ち受けています。

(internet)   2019/06/02

コメントする

top page     previous page     next page

mail