abk1's scratched blog 3

前回に引き続き、earfluff and eyecandy によるJitterの解説について読んでいる。

Jitter – earfluff and eyecandy
http://www.tonmeister.ca/wordpress/category/jitter/

今回はPart 3から。

Jitter: Part 3 – Classifying Jitter

Jitter: Part 3 – Classifying Jitter
http://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-3/

Part 2では、ジッターを位相ジッターと振幅ジッターという見方で分けた。
ここでは、別のジッターの分類について触れている。
以下、表にする。

Part 4でRandom Jitter、Part 5でDeterministic Jitterについて説明がある。

日本のサイトで用語の解説がある。
random jitter（ランダム・ジッタ）、deterministic jitter（デターミニスティック・ジッタ）
Posted on 2014年12月24日
http://www.de-pro.co.jp/2014/12/24/8209/

Jitter: Part 4 – Random Jitter

Jitter: Part 4 – Random Jitter
https://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-4-random-jitter/

You have a signal (the audio signal that has been encoded as a digital stream of 1’s and 0’s, sent through a device or over a wire as a sequence of alternating voltages) and some random noise is added to it for some reason… (Maybe it’s thermal noise in the resistors, or cosmic radiation left over from the Big Bang bleeding through the shielding of your S-PDIF cable, or something else… )

What we’re really talking about is that the jitter is modulating the signal that carries your audio signal – not the audio signal itself. This is an important distinction, so if that last sentence is a little fuzzy, read it again until it makes sense.

(translated by google)
信号（1と0のデジタルストリームとしてエンコードされ、デバイスを介して、または一連の交流電圧としてワイヤを介して送信されたオーディオ信号）があり、何らかの理由でランダムノイズが追加されています…（多分 それは、抵抗器の熱ノイズ、またはビッグバンから残った宇宙放射がS-PDIFケーブルのシールドを介して出血していることなどです…）

私たちが実際に話しているのは、ジッターがオーディオ信号自体ではなく、オーディオ信号を運ぶ信号を変調しているということです。これは重要な違いなので、最後の文が少し曖昧な場合は、意味がわかるまでもう一度読んでください。

1 Timing errors of the clock events relative to their ideal positions
2 Timing errors of the clock periods relative to their ideal lengths in time

These are very different – although they look very similar.

The first is an absolute measure of the error in the clock event – when did that single event happen relative to when it should have happened? Each event can be measured individually relative to perfection – whatever that is. This is called a Phase Modulation of the carrier. It has a Gaussian characteristic (which I’ll explain below…) and has no “memory” (which is explained first).

The second of these isn’t a measure of the events relative to perfection – it’s a measure of the amount of time that happened between consecutive events. This is called a Frequency Modulation of the carrier. It also has a Gaussian characteristic (which I’ll explain below…) but it does have a “memory” (which is explained using Figure 1).

(translated by google)
1 理想的な位置に関連するクロックイベントのタイミングエラー
2 時間の理想的な長さに対するクロック周期のタイミングエラー

これらは非常に異なりますが、見た目は非常に似ています。

1つ目は、クロックイベントのエラーの絶対的な測定値です。その単一のイベントは、発生するはずだった時期と比較して、いつ発生したのでしょうか。 各イベントは、それが何であれ、完璧に関連して個別に測定できます。これは 、搬送波の位相変調と呼ばれます。ガウス特性（以下で説明します…）があり、「メモリ」（最初に説明します）がありません。

これらの2つ目は、完全性に関連するイベントの測定値ではありません。これは、連続するイベント間で発生した時間の測定値です。これは、搬送波の周波数変調と呼ばれます。また、ガウス特性（以下で説明します…）がありますが、「メモリ」（図1を使用して説明）があります。

ちょっと引用だけではなんだかよく分からない。
元サイト原文のほうに図が掲載されている。しかし、ガウス分布は分かるんだけど、位相変調と周波数変調については、よく分からない。
位相変調は、その瞬間だけに影響するもので、周波数変調はその後の信号にも影響を与える（「記憶」と表現されている）ということらしい。
いろんな原因でランダムに生じるジッターがあり、その瞬間だけ影響するものと、後まで影響するものに分けられる、という理解で、とりあえずいいのかな。

Jitter: Part 5 – Deterministic Jitter

Jitter: Part 5 – Deterministic Jitter
https://www.tonmeister.ca/wordpress/2018/08/09/jitter-part-5-deterministic-jitter/

Deterministic jitter can be broken down into two classifications:

1 Jitter that is correlated with the data.
This can be the carrier, or possibly even the audio signal itself

2 Jitter that is correlated with some other signal
In the second case, where the jitter is correlated with another signal, then its characteristics are usually periodic and usually sinusoidal (which could also include more than one sinusoidal frequency – meaning a multi-tone), although this is entirely dependent on the source of the modulating signal.

(translated by google)
決定論的ジッタは、次の2つの分類に分類できます。

1 データと相関するジッタ。
これは、キャリア、または場合によってはオーディオ信号自体である可能性があります

2 他の信号と相関するジッタ
ジッタが別の信号と相関している2番目のケースでは、その特性は通常 周期的であり、通常は正弦波です（複数の正弦波周波数を含む場合もあります-マルチトーンを意味します）が、これは変調信号のソースに完全に依存します。

まず、決定論的ジッタはデータ依存ジッタと周期ジッタとに分けられるとのこと。
データ依存ジッタには、Intersymbol Interference（符号間干渉：ISI）、Duty Cycle Distortion（デューティ・サイクル歪み：DCD）、Echo Jitter（エコージッター）があるということで、ここではそれらを順番に説明している。

ランダムジッタは予測不能だけど、決定論的ジッタは瞬間毎にどのように動作するかを「予測可能」とのこと。予測可能というのは、僕には意外だった。たぶん僕が考える予測と、サイトオーナーが記載している予測は、どこか意味が違うんだろうと思う。
読んでいて、僕が持っているジッターのイメージに説明内容が近いものは理解しやすかったような気がする。気がするというのは、本当に分かったのかどうかがおぼつかないからだ。
イメージがつかめないものは、分かりにくい。

データ依存のジッター

Data-Dependent Jitter

Data-dependent jitter occurs when the temporal modulation of the carrier wave is somehow correlated to the carrier itself, or the audio signal that it contains. In fact, we’ve already seen an example of this in the first posting in this series – but we’ll go through it again, just in the interest of pedantry.
We can break data-dependent jitter down into three categories, and we’ll look at each of these:

(translated by google)
データ依存のジッタは、搬送波の時間変調が搬送波自体、または搬送波に含まれるオーディオ信号と何らかの形で相関している場合に発生します。実際、このシリーズの最初の投稿でこの例をすでに見てきましたが、衒学者のためだけに、もう一度説明します。
データに依存するジッターを3つのカテゴリに分類でき、それぞれを見ていきます。

データ依存って何だと思うけど、データ信号そのものに乗るジッターで、以下の３つに分類されるということらしい。
しかし、本当に３つだけなのか？と考えてしまう自分がいる、、、たぶん何か分かっていないのだ。

符号間干渉

ケーブルで伝送されるうちに、信号の方形波の波形が崩れていくということらしい。
理想のケーブルは現実には存在しないからとのこと。
参考：
https://en.wikipedia.org/wiki/Intersymbol_interference

デューティサイクル歪み

If your transmission system is a little inaccurate, then it could have an error in controlling the duty cycle of the pulse wave. Basically, this means that it makes the transitions at the wrong times for some reason, thus creating a jittered signal before it’s even transmitted.

(translated by google)
伝送システムが少し不正確な場合は、脈波のデューティサイクルの制御にエラーが発生する可能性があります。基本的に、これは、何らかの理由で間違ったタイミングで遷移を行うことを意味します。したがって、送信される前にジッター信号が作成されます。

これは正直良く分からない。
技術実装の問題なんだろうか。
参考：
https://en.wikipedia.org/wiki/Duty_cycle

思い当たるのは、音源を置くHDDによって音が違うというような事象のことを言っているのかもしれない。違うかもしれないけど。

エコージッター

What many people don’t know is that, if you stand in a long corridor or a tunnel with an open end, you will also hear an echo, bouncing off the open end of the tunnel. It’s not intuitive that this is true, since it looks like there’s nothing there to bounce off of, but it happens. A sound wave is reflected off of any change in the acoustic properties of the medium it’s travelling through. So, if you’re in a tunnel, it’s “hard” for the sound wave to move (because there aren’t many places to go) and when it gets to the end and meets a big, open space, it “sees” this as a change and bounces back into the tunnel.

Basically, the same thing happens to an electrical signal. It gets sent out of a device, runs down a wire (at nearly the speed of light) and “hits” the input of the receiver. If that input has a different electrical impedance than the output of the transmitter and the wire (on other words, if it’s suddenly harder or easier to push current through it – sort of….) then the electrical signal will (partly) be reflected and will “bounce” back down the wire towards the transmitter.

(translated by google)
多くの人が知らないのは、長い廊下や開放端のあるトンネルに立つと、トンネルの開放端で跳ね返るエコーも聞こえるということです。跳ね返る物が何もないように見えるので、これが真実であるというのは直感的ではありませんが、それは起こります。音波は、通過する媒体の音響特性の変化によって反射されます。したがって、トンネル内にいる場合、音波が移動するのは「困難」であり（移動する場所が少ないため）、音波が終わりに到達して大きなオープンスペースに出会うと、音波は「見えます」。これは変更としてトンネルに跳ね返ります。

基本的に、同じことが電気信号にも起こります。それはデバイスから送信され、（ほぼ光速で）ワイヤーを伝わり、レシーバーの入力に「ヒット」します。その入力が送信機とワイヤーの出力とは異なる電気インピーダンスを持っている場合（言い換えると、電流を押し込むのが突然困難または容易になった場合-ある種…。）、電気信号は（部分的に）反射され、送信機に向かってワイヤーを「バウンス」します。

エコージッターはインピーダンスの問題で生じるらしい。
デジタルケーブルのインピーダンスを合わせるのは大事なことらしい。

周期性ジッター

Periodic Jitter

We press play on the CD, and the audio signal, riding on the S-PDIF carrier wave is sent through our cable to the DAC. However, the signal that reaches the DAC is not only the S-PDIF carrier wave, it also contains a sine wave that is radiating from a nearby electrical cable that is powering the fridge…

CDの再生を押すと、S-PDIF搬送波に乗ったオーディオ信号が、ケーブルを介してDACに送信されます。ただし、DACに到達する信号は、S-PDIF搬送波であるだけでなく、冷蔵庫に電力を供給している近くの電気ケーブルから放射されている正弦波も含まれています…

周期性ジッターについて最後に書かれている。
データ信号とは関係がなく、他の信号と相関するジッタで、多くは周期的に変動するということだ。
冷蔵庫のコンセントにノイズ対策したらコンポの音が良くなったというような、世間では都市伝説めいた扱いをされているあれである。うちの冷蔵庫にもノイズフィルターをかませている。
そうした外来ノイズによって生じるジッターや、システム内でも取り切れなかったノイズとか（電源のノイズとかかな、、）、そうしたものということのようだ。

紛らわしいので一応、書いておく。「Periodic Jitter」は、クロックジッターなどで説明される「周期ジッター（Period jitter / Cycle Jitter）」とは、別物？らしい。
ここらはまだよく分からない。
ジッターは切り取り方によって呼び方がころころ変わるようで、そういうのも分かりにくい原因だと思う。

分かりやすい例から何を言ってるのか分からないようなものまで、ジッターの原因には色々ある。
エントリーの最後に、これらの影響がデジタル信号に積み重なったらどんな影響があるかを図にしている。

Part 6以降は、また切り口が変わるので、今回はここまで。

前回、前々回に引き続き、earfluff and eyecandy によるJitterの解説について読んでいる。
今回が最後だ。

Jitter – earfluff and eyecandy
http://www.tonmeister.ca/wordpress/category/jitter/

今回はPart 6から。

Jitter: Part 6 – What is Affected?

Jitter: Part 6 – What is Affected?
http://www.tonmeister.ca/wordpress/2018/08/10/jitter-part-6-what-is-affected/

So far, we’ve looked at what jitter is, and two ways of classifying it (The first way was by looking at whether it’s phase or amplitude jitter. The second way was to find out whether it is random or deterministic.) In this posting, we’ll talk about a different way of classifying jitter and wander – by the system that it’s affecting. Knowing this helps us in diagnosing where the jitter occurs in a system, since different systems exhibit different behaviours as a result of jitter.

これまで、ジッターとは何か、およびそれを分類する2つの方法を見てきました（最初の方法は、位相ジッターか振幅ジッターかを調べることでした。2番目の方法は、ランダムか決定論かを調べることでした）。この投稿では、影響を受けているシステムによって、ジッターとワンダーを分類する別の方法について説明します。これを知ることは、システムのどこでジッターが発生するかを診断するのに役立ちます。これは、システムが異なれば、ジッターの結果として異なる動作を示すためです。

We can put two major headings on the systems affected by jitter in your system:

data jitter
sampling jitter

If you have data jitter, then the timing errors in the carrier signal caused by the modulator cause the receiver device to make errors when it detects whether the carrier is a “high” or a “low” voltage.
If you have sampling jitter, then you’re measuring or playing the audio signal’s instantaneous level at the wrong time.
These two types of jitter will have different effects if they occur – so let’s look at them in the next two separate postings to keep things neat and tidy.

システム内のジッターの影響を受けているシステムには、次の2つの主な見出しを付けることができます。

データジッター
サンプリングジッター

データジッターがある場合、変調の原因によって引き起こされるキャリア信号のタイミングエラーにより、キャリア信号が「高」または「低」のどちらの電圧であるかを受信デバイスで検出したときに、エラーが発生します。
サンプリングジッターがある場合は、瞬間的なオーディオ信号レベルを、間違った時間のタイミングで測定したり再生している状態になります。
これらの2つのタイプのジッターは、発生した場合に異なる影響を及ぼします。したがって、次の2つの別々の投稿でそれらを見て、物事をきちんと整理してください。

Part 6は短いので、全文引用した。
しかし、googleまかせではちょっと問題かと思ったので、僕が手を入れることにした。どうだろうね。

Jitter: Part 7 – Data Jitter

Jitter: Part 7 – Data Jitter
http://www.tonmeister.ca/wordpress/2018/08/10/jitter-part-7-data-jitter/

ここは、正直良く分からない、、、

Part 6で書いてあったことは、『データジッターがある場合、変調の原因によって引き起こされるキャリア信号のタイミングエラーにより、キャリア信号が「高」または「低」のどちらの電圧であるかを受信デバイスで検出したときに、エラーが発生します。』とのこと。
要はキャリア信号自体に乗っかる形で影響するジッターという理解でいいのだろうか。

Part 7では「Peak-to-Peak error」、「RMS error」という言葉が出てくる。
これらの用語は、デジタルオーディオの本などでクロックジッター、周期ジッター（Period Jitter）というジッターの説明に出てくるようなんだけど（前に書いたけど、Periodic Jitterとperiod Jitterは、別の概念のような？）、それが、ここに出てきている。
データジッターという言葉は、そもそもグーグル検索で殆んど引っかかって来ない。data jitterなら多少はあるのだけど。なんだか、いろいろ謎である。

説明で「ランダムジッター」を想定している。
説明内容にあるような、ランダムジッターが多すぎたら読み取りエラーを生じるようになるのは、理解できる。
しかしデータジッターは、ランダムジッターだけなんだろうか。
ちょっと、そこの辺りがよく分からない。
もっといろんな作用が起こってると考えないと説明しにくいことがあるような気がする。

あと、ジッターでデータエラーを生じるような悪劣な環境でオーディオをやっているという想定は、かなり限定された状況のような気がする。
データエラーまで生じなくても、データジッターは音に影響するはずなのだ。
そこに触れてないようなのが、よく分からないところ。
技術的に説明しにくいのだろうか。まあ、僕が見当違いを言ってる可能性もある。

Jitter: Part 8.1 – Sampling Jitter - Jitter in the Analogue to Digital conversion

Jitter: Part 8.1 – Sampling Jitter
http://www.tonmeister.ca/wordpress/2018/08/28/jitter-part-8-1-sampling-jitter/

ここでは、AD変換について説明している。
個人的には過去に見たことがあるような内容が多いし、あんまり注意して読まなくてもいいかなと思ったら、そうでもないような。

エントリーの下の方に、ジッタの量が一定に保たれている場合に、振幅エラーの量は信号の傾きに応じて変調する、というのを「図6」に示している。「赤い曲線は、サンプルごとの誤差（ジッター信号から元の信号を差し引いたもの）を拡大してプロットしたもの」との、説明がある。

Secondly, if the amount of jitter is kept constant, then the amount of amplitude error will modulate (or vary) with the slope of the signal. This is illustrated in Figure 6, below.

Fig 6. The blue curve is a sine wave to which I have applied excessive amounts of jitter with a Gaussian distribution. The red curve is the sample-by-sample error (the original signal subtracted from the jittered signal) plotted on a magnified scale. As can be seen, the level of the instantaneous error is proportional to the slope of the signal. So, the end result is that the noise generated by the jitter is modulated by the signal. (If you look carefully at the blue curve, you can see the result of the jitter – it’s vertically narrower when the slope is low – at the tops and bottoms of the curve.)

AD変換で、これがデジタル音楽データに乗ったらおおごとだと思うんだけど。
これと同等のことが、DA変換でも起こり得ることじゃないのかと思う。
つまり「図6」の赤い線（線というより塗りつぶされてるが）は、ジッターがアナログ再生音を濁らせる、その様子が可視化されているのではないかと。
ADで起きることなら、DAで起きても不思議はないと思うのだけど、見当違いかもしれないが。

Jitter – Part 8.2 – Sampling Jitter - Jitter in the Digital to Analogue conversion

Jitter – Part 8.2 – Sampling Jitter
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-8-2-sampling-jitter/

part 8.2では、DA変換について説明している。
オーディオ再生だったらこっちがメインだと思ったら、たぶん8.1で説明した内容と多くが被るのだろう、ごく簡単にすませている。
まあ、ジッターの説明でよく見る絵が描いてある。

文末に「I’ve completely omitted the effects of the anti-aliasing filter and the reconstruction filter – just to keep things simple.（単純化するために、アンチエイリアシングフィルターと再構成フィルターの効果を完全に省略しました。）」とある。

Jitter – Part 8.3 – Sampling Rate Conversion

Jitter – Part 8.3 – Sampling Rate Conversion
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-8-3-sampling-rate-conversion/

ここではサンプリングレート変換について書いてある。
しかし、そんなに多くは書かれていない。

Synchronous Sampling Rate Conversion（同期サンプリングレート変換）とAsynchronous Sampling Rate Conversion（非同期サンプリングレート変換）についての説明がある。
うちで行っているのは、非同期のほうだ。

The good news is that, if the clock that is used for ASRC’s output sampling rate is very accurate and stable, and if the filtering that is applied to the incoming signal is well-done, then an ASRC can behave very, very well – and there are lots of examples of this. (Sadly, there are many more examples where an ASRC is implemented poorly. This is why many people think that sampling rate converters are bad – because most sampling rate converters are bad.) in fact, a correctly-made sampling rate converter can be used to reduce jitter in a system (so you would even want to use it in cases where the incoming sampling rate and outgoing sampling rates are the same). This is why some DAC’s include an ASRC at the input – to reduce jitter originating at the signal source.

(trranlated by google)
幸いなことに、ASRCの出力サンプリングレートに使用されるクロックが非常に正確で安定していて、着信信号に適用されるフィルタリングが適切に行われている場合、ASRCは非常に適切に動作できます。この例はたくさんあります。（残念ながら、ASRCの実装が不十分な例は他にもたくさんあります。これが、多くの人がサンプリングレートコンバーターが悪いと考える理由です。ほとんどのサンプリングレートコンバーターが悪いためです。）実際、正しく作成されたサンプリングレートコンバーターを使用できます。システムのジッターを減らすため（したがって、着信サンプリングレートと発信サンプリングレートが同じ場合にも使用する必要があります）。これが、一部のDACの入力にASRCが含まれている理由です。これは、信号ソースで発生するジッターを低減するためです。

サンプリングレート変換でジッターを減らせると、なんと、ここでお墨付きがもらえた！
うまく実装したらという条件付きだけど。

Jitter – Part 9 – When do I care?

Jitter – Part 9 – When do I care?
http://www.tonmeister.ca/wordpress/2018/08/30/jitter-part-9-when-do-i-care/

In order to talk about WHEN we care about jitter, we have to separate jitter into the categories of Data Jitter and Sampling Jitter

ジッタを気にする場合について話すには、ジッタをデータジッタとサンプリングジッタのカテゴリに分類する必要があります。

このPart 9で最後だ。

データジッターに関しては、機械と接続ケーブルをちゃんと使えと書いてある（うーむ、、、）。
サンプリングジッターのほうのまとめも、大したことは書いてないかな。

Can you hear jitter?

The simple answer to this these days is “probably not”. The reason I say this is that, in modern equipment, jitter is very unlikely to be the weakest link in the chain. Heading this list of likely suspects (roughly in the order that I worry about them) are things like

• aliasing artefacts caused by low-quality sampling rate conversion in the signal flow (note that this has nothing to do with jitter)
• amateurish errors coming out the recording studio (like clipped signals, grossly excessive over-compression, and autotuners) (and don’t get me wrong – any of these things can be used intentionally and artistically… I’m talking about artefacts caused by unintentional errors.)
• playback room acoustics, loudspeaker configuration and listener position
• artefacts caused by the use of psychoacoustic CODEC’s used to squeeze too much information through too small a pipe (although bitrates are coming up in some cases…)
• Dynamic range compression used in the playback software or hardware, trying to make everything sound the same (loudness)
• low-quality loudspeakers or headphones (I’m thinking mostly about distortion and temporal response here
• noise – noise from the gear, background noise in your listening room… you name it.

So, if none of these cause you any concern whatsoever, then you can start worrying about jitter.

最近は、昔ながらの「デジタルっぽい」音源は、ほとんど全く無くなった。
それどころか、昔のCDでも最近の機械で鳴らすと、デジタルっぽくない音がすることも多い。
録音も再生機器も良くなったということだろう。

しかし明瞭に聞こえなくても、ジッターが再生音に影響しているのは確かだと思う。
今でもちょっとしたことで、デジタル音源の音が変わるのだから。

今回、ジッターというのはいろんな切り口があるのだというのを改めて確認した。
それにしても、複雑で意味不明で分かりにくい。その一方で疑問が解けたこともあったので、読んでよかったと思う。引き続き、マイペースではあるけど、勉強していこう。

しかし、疲れた、、、今回はここまで。

今回は音源の話。
というか、高音質音源リストについて。

海外に「the absolute sound」というオーディオサイトがある。
そこにオーディオファイル向けの高音質音源がリストされている。

The HP Super LP List
by Harry Pearson Nov 17th, 2014
https://www.theabsolutesound.com/articles/the-hp-super-lp-list

2019 TAS Super LP List
BLOG by TAS Staff Jul 10th, 2019
https://www.theabsolutesound.com/articles/2019-tas-super-lp-list

Harry Pearsonという人がまとめた古い音源中心のアナログディスクのリストがあって、TASスタッフが引き継いだということらしいんだけど、2019年を最後に更新されなくなった。コロナの関係とかもあったのかもしれないが。
2020年以降は、こんな感じ。

2020 Top Ten Lists
BLOG by Jeff Wilson Dec 14th, 2020
https://www.theabsolutesound.com/articles/2020-top-ten-lists

2021 TAS Tapeography
BLOG by Jonathan Valin Jan 17th, 2022
https://www.theabsolutesound.com/articles/2021-tas-tapeography

テープのリストって、すごいわね、、、
そして2022年は、こんな感じ。

TAS Super Download List : Classical
MUSIC by TAS Staff Mar 31st, 2022
https://www.theabsolutesound.com/articles/tas-super-download-list-classical

TAS Super Download List : Jazz
MUSIC by TAS Staff Apr 01st, 2022
https://www.theabsolutesound.com/articles/tas-super-download-list-jazz

TAS Super Download List : Pop, Rock, and Folk
MUSIC by TAS Staff Apr 01st, 2022
https://www.theabsolutesound.com/articles/tas-super-download-list-pop-rock-and-folk

Though HP once attempted to compile a list of recommended digital recordings (then only available on CDs and SACDs), he was unable to make consistent progress and eventually abandoned the effort.
Over the next few years, I will attempt to pick up where Harry left off.
For various reasons, I’m going to begin with media available via the Internet, starting with high-resolution downloads from HDtracks. In time, I will add streamed versions of these same titles (assuming they are recommendable, of course).

（翻訳 by Google）
HPはかつて推奨されるデジタル録音のリストを編集しようとしましたが（当時はCDとSACDでのみ利用可能でした）、一貫した進歩を遂げることができず、最終的にその努力を断念しました。
今後数年間で、ハリーが中断したところから再開しようと思います。
さまざまな理由から、HDtracksからの高解像度のダウンロードから始めて、インターネット経由で利用できるメディアから始めます。そのうちに、これらの同じタイトルのストリーミングバージョンを追加します（もちろん、それらが推奨されると仮定します）。

ダウンロードやストリーミングのリストを作っていく計画とのこと。
最初は20個しかないが、TASのWebサイトで毎月1〜2回、新しいタイトルを追加していく意向らしい。
LPのリストは、どうやら2019年が最新版ということで、しばらくは更新されないかもしれない。実際のところ、難しそうな感じだし、割り切って別のリストを構築するというのは、いい考えではないかと思う。

それにしても、オーディオファイル向けの高音質音源のリストというのは難しい。
リストから漏れている音源がどうしても出てくるし、音が良くても楽しめない内容だったらちょっと辛い。

個人的に思うのは、音が「良くない」ソフトというのは少ない。
割合がどのくらいなのかといわれると困るけど、まあ、3分の2以上は、いいオーディオで鳴らしたほうが音が良くなるし、聴き応えもあるように思う。、、まあ、当たり前か。
何について言ってるのかが問題だね、、、クラシックが特にそんな感じかな、、、
JPopは、あんまり音が良くないのが多いとは思う。特にボーカル。お風呂で歌ってるように聞こえるのが多い印象がある。カラオケマイクを通したように聞こえるのだ。まあ、日本はカラオケの国だから仕方ないのかな。それがポップだということもあるし。それでも、ちゃんと録音してると思う音源も探せばそこそこあるような気がするのだけど。そういうわけで、僕にとってJPopで音質がいいというのは、ボーカルの音がいいというのとほぼ同義だったりする。その程度の聴き方しか出来てないということかもしれないが。

話が逸れた。
話が漠然としすぎていてまとまらない。

たいていの音源は、いい装置で鳴らせばいい音で鳴る。
そんな中で、特別に音質がいい音源を選りすぐってセレクトしないといけない。
当然だけど、再生装置、環境によって、音は変わる。
Harry Pearsonの再生環境で最高の音が鳴るディスクが、他の環境で素晴らしく鳴るとは限らない。
The HP Super LP Listの選から漏れた音源が、他の環境で、Harry Pearsonの装置で鳴らすThe HP Super LP Listの最高の音源以上の音で鳴ることが、絶対に無いとは言い切れない。そういう危うさが、高音質音源のリストには付き纏う。
完全に理想的とは言えないオーディオ機材、人の聴覚と感受性以上のセンサーが存在しない、そんな状況で最善を尽くす以外ないのだろう。

それでも「定番」としてのリストはニーズがあり、現実的に必要だと思う。
新しいリストが有用で充実したものになることを願う。

現在のpiCoreの状況がどうなってるのかと思って、確認したことを記録しておく。

なんで突然、piCoreなのかというと、ハードの違いで音が変わるということを思ううちに、そういえば以前はRaspberry Piで鳴らしていたっけと思い、そこから、今はどうなってるんだろうということになったということだ。
piCoreの最新は13になっている。
http://tinycorelinux.net/13.x/armv6/releases/RPi/

nmap.tczは、piCore9まで用意されていて、10はpiCore自体が欠番。11、12ではnmap.tczがリポジトリに用意されていなかった。
しかし現在、piCore13ではnmap.tczがリポジトリに用意されている。ということは、piCore9以前か13だったら簡単にPPAP Back Endを作れるということだ。
http://tinycorelinux.net/13.x/armv6/tcz/

ちなみに、mpd.tczが用意されているのはpiCore7まで。
libmpdclient.tczはpiCore9までだ。
一方、Tiny Coreはというと、Tiny Core x86（32bit版OS）のリポジトリにはmpd-minimal.tcz、libmpdclient.tczが昔から今までずっと用意されている。つまり、実は手軽にmpdを扱うにはこれが一番簡単だ。nmap.tczもあるが、mpd-minimalでpipeが使えるかは確認していない。
http://tinycorelinux.net/13.x/x86/

64bit OSであるx86_64のリポジトリには、mpdが無い。
ソースをダウンロードしてインストールする必要がある。

一方、alsaはというと、piCore11からversion 1.2.2になって、音源のサンプリング周波数が768kHzまで通るようになっている。
piCore9だと、alsaはversion 1.1.1。音源が198kHzまでで良ければ、piCore9以前のバージョンでよくて、300kHz以上なら11以降が必要ということになる。
参考：
Changelog between 1.1.9 and 1.2.1 releases / Alsa Project News
https://www.alsa-project.org/wiki/Changes_v1.1.9_v1.2.1

現在、うちでは768kHz/32bitでPPAP方式を使っていて、Back Endで使っているのはTiny Core Pure 64 v11.0。ハードはapu2だ。
piCore13ならば、768kHzが使えるPPAP Back Endに出来る筈、、、
しかし問題は、Raspberry PiはUSBとLANが同じチップで処理されているんだったかな。Ras Pi4とか、新しいハードだと改善されたらしい？けど、うちに残っているB+とか2とかだと、大量のデータを送るのは、うまくいかない可能性がある。というか、B+とか2とか非力なハードで、768kHz/32bitなんて重い音声データを扱えるんだろうか。

しかしRaspberry Pi とpiCoreでPPAP Back End、apu2と比較できるならしてみたいかな。

せっかくなので、まずはRaspberry Pi B+で試してみる。
以下、工程と設定のメモ。

download
http://tinycorelinux.net/13.x/armv6/releases/RPi/piCore-13.1.0.zip

cmdline.txt add
host=pC131bp

config.txt rewrite
dtparam=audio=off

login
ssh tc@192.168.1.xxx

sudo fdisk -u /dev/mmcblk0
p
d
2
n
p
2
(write number - /dev/mmcblk0p2 / start)
+100M
w

filetool.sh -b
sudo reboot

login
ssh tc@192.168.1.xxx

sudo resize2fs /dev/mmcblk0p2

tce-load -wi nmap.tcz alsa-modules-5.10.77-piCore.tcz alsa.tcz alsa-utils.tcz

vi /opt/bootlocal.sh
/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=4096 --buffer-size=16384 -t raw -f S32_LE -r768000 -c2"

vi /opt/eth0.sh
#!/bin/sh
pkill udhcpc
ifconfig eth0 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255 up
route add default gw 192.168.10.1
# echo nameserver 192.168.10.1 > /etc/resolv.conf

chmod +x /opt/eth0.sh

sudo vi /opt/bootsync.sh
/opt/eth0.sh &

filetool.sh -b
sudo reboot

工程終了。
PPAP Middle Endにつないで起動。
Middle Endからsshでログインして、下記コマンドにてUSB DACの認識を確認する。

cat /proc/asound/card0/stream0

音を出してみる。
音は出た。しかし、ノイズだらけで、音楽を聴くというわけにはいかなかった。

Ras Pi2ではどうなのか。

download
http://tinycorelinux.net/13.x/armv7/releases/RPi/piCore-13.1.0.zip

cmdline.txt add
host=pC131b2

tce-load -wi nmap.tcz alsa-modules-5.10.77-piCore-v7.tcz alsa.tcz alsa-utils.tcz

上記以外の工程は同じ。
音は出た。やはりノイズだらけだが、音楽は聞き取れる。音程は正しいのに再生速度が遅い。これでは使えない。

PPAP Front Endでのアップサンプリングを止める。
Back Endの設定も合わせる。

/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/aplay -D hw:0,0 -M --period-size=64 --buffer-size=512 -t raw -f cd"

これでどうか。
まともな音が出る、けど、、、操作へのレスポンスが遅い。
こんなに遅かったっけ、そういえば遅かったかな、、と思うぐらい遅い。
普段、Daphileとmpdで768kHzにアップして聴いてるのと比べても、なんだか遅い気がする。普段使っているシステムは、再生開始の操作をして音が出るまで数秒かかるけど、ボリューム調整への反応は遅くない。それが、Ras Piだと両方とも遅く感じる。 apu2よりもRas Piのほうが遅いハードだからだろうか。
しかし、DaphileとpiCorePlayerの組み合わせだと、そんなに遅く感じない。
もしかしたらLMSやUPnPは、ユーザーがレスポンスが遅いと感じないように作られているのかもしれない。

あれこれ弄るうちに、Daphileシステムの方も不調になってきた。原因不明、、、全システムをリブート。
システム全体の不調が影響したせいかどうか分からないが、音質も敢えてRas Piで聴きたいと思わせるものがない。

今回はここらで撤退することにした。
残念だが致し方なし。

半年前と比べて、若干システム上流を中心に変更がある。
聴こえ方も多少変わった。

最近のシステム構成は下図のような感じ。
前よりすっきりしてるかな。

一番大きな変更は、PPAPのMiddle EndとBack Endを直結したこと。
これは実は長年の懸案であり、今更感はあったのだけど、やってみたら改善効果は大きかった。

何故もっと早くしなかったのかというと、たぶん5、6年以上は前のことだが、最初に直結方式の説明をネット上で読んだときに、わけが分からない、手に負えそうにない、と思ったのが大きいかもしれない。
当時の僕はmpdを触り始めて間がなくて、Linuxにも今程には慣れていなかったので、後回しにした。
後回しになって、そのままになったのだ。
他の手法で音質改善は得られていたし、他にやることもあったので。
ネット上で直結による向上が大きいという話をたまたま読んで、そういえば、という感じで手を付けたということだ。
多少の苦手意識があっても、手を付けたらいいこともあるようだ。

上流の配置が変わり音が変わり、結果、ハブが減った。
NETGEARのGS105Eが1つ外れて1個になった。少ない方が良さそう。Planex FXG-05RPも外せるかなと思ったけど、こっちは外さない方が良かった。

そんなこんなで音質向上したということだけど、よりHi-Fiになったという意味合いだ。

これに伴って、2台のDACの聴こえ方に以前よりも差が出てきた。
ADI-2 DACのほうがよりHi-Fiでモニター的、Pegasus R2R DACのほうが絵画的。それが、より明瞭になってきた。
同時に、情報量の差が明瞭になってきた。ADI-2の方が僅かに情報量が多い。

アンプの方も差が出てきて、SM-SX100のほうがHi-Fi。
Brooklyn Ampのほうが情報量は僅かに少なく絵画的。
こうした両者の差が大きくなってきたので、Brooklyn Ampに可変抵抗アッテネーターが使えなくなった。
固定抵抗アッテネーターなら情報量や鮮度の低下が少ないので、まだ使える。使えるというのは、Brooklyn Ampの絵画的な音の美点を、アッテネーターがスポイルしないというような意味合いだ。

DAC2台とアンプ2台で4通りの組み合わせになる。
ADI-2とSX100が最もHi-Fiで情報量が多く、うちのリファレンスということになる。
Pegasusは高音域に美点があり、Brooklyn Ampはボーカル帯域に美点がある。
PegasusとSX100だとPegasusの美点が、ADI-2とBrooklyn AmpだとBrooklyn Ampの美点が表現された音になるようだ。
ところが、じゃあPegasusとBrooklyn Ampだと両者の美点が表現されるのかというと、さにあらず、なんだか曇ったような冴えない音になってしまう。両取りとはいかないようだ。この組み合わせで良く聴こえる音源も探せばある可能性がと思うのだけど、どうなのかな。

M500が此処まで蚊帳の外だ。最近は使うことが少なくなった。
しかし将来的にMQAストリーミングの再生に使えないかと思っている。
Daphileサーバーが２つに増えているが、片方、6730bのほうをテスト運用とYoutube音声などの再生などに使っている。ここからpiCorePlayerに出力しM500に繋いでいる。
piCorePlayerを使った再生は、うちのシステムで唯一、mpdを使わない再生ということになる。

そんなこんなで、この1か月でけっこう変わった。もう手を入れるところは無いかな、、、どうだろう。

コロナだ戦争だとうっとうしい世の中だ。
夏バテしないように気を付けよう。

Brooklyn Ampに使っている「MONITOR1」の実力がどうなのか、ずっとどこかで気になっていた。
MONITOR1 ベリンガー公式
https://www.electori-br.jp/products/625.html
使い始めた当初は、これで充分だと判断した。5000円と安価な製品で、アンプの能力をスポイルしている可能性は否定できない。当時、それも込みで必要十分と判断したのだ。

しかし2年近く経って状況も変わった。
ひとつは、Brooklyn Ampのアップグレードサービスが日本でも受けられるようになったこと。
https://www.mytekdigital.jp/contact/brooklyn-amp-upgrade/
もうひとつは、上流の改善に伴って、相対的にスポイルの度合いが大きくなっているのではないか？という心配。

アッテネーターなので信号劣化が無いということはありえない。
実際にどの程度の影響があるのか、今まではそんなに気にせずに使ってきたけど、今後のためにも確認しておく必要がある。

アップグレードによる音の変化については、stereophileに分かりやすいレビューがある。
ちょっと引用する。

Mytek HiFi Brooklyn AMP+ power amplifier
https://www.stereophile.com/content/mytek-hifi-brooklyn-amp-power-amplifier

"Sometimes, when people listen to the AMP+ version," Jurewicz continued, "they say that the older Brooklyn AMP had this nice midrange, which is essentially a grunge produced by distortions, but it seems to be acceptable in the older model.
The new model is cleaner, with a bigger soundstage and more detail.The AMP+ is more precise.
I would look to achieve that midrange sweetness of the earlier AMP through other means, using other components that are in that direction.

（訳）
「時々、AMP+バージョンを聞いた人の中に、」Jurewicz氏は続けます。「古いBrooklyn AMPのミッドレンジが良かったと言う人がいて、これは本質的に歪みによって生成された汚れですが、古いモデルでは受け入れられるようなのです。
新しいモデルはよりクリーンで、サウンドステージがより大きく、より詳細になっています。AMP+はより正確です。
私なら、そうした傾向がある他のコンポーネントを使用するなど、他の方法で以前のAMPのミッドレンジの心地よさを実現したいと思います。」

なるほど、、、
うちで使っていて、ああ、そういう感じか、、と納得がいく話だ。
要するに、バージョンアップしたら良くも悪くもSM-SX100の音に近付くということらしい。
そしてそうなると、バージョンアップはどうしよう、ということになる。

もともと、Brooklyn AmpはSX100が壊れた時の代替と考えて購入した。
そういう意味では、音が同じでも問題はない。
しかし、なんというんだろうな、、おんなじ傾向のアンプが２台あってもなあ、、という気持ちがあって、バージョンアップに踏みきれないでいる。
まあ、2年前と違ってSX100が修理不能になったときはなったときだという気持ちになっているし（どうやら代替アンプは簡単に見つかりそうなご時世だから）、極端な話、そのときBrooklyn Amp+を買ったっていいのだ。そのときバージョンアップできるならしても良い。ひょっとしたらSX100を越えるかもしれない。

そうなったときに、MONITOR1のクオリティが問題になる。
今は、気が向いたときになんとなく使う感じなので、ゆるい音質で構わない。メインで使うとなったら、ボトルネックになるようでは困る。まあ、そのとき考えればいいっちゃいいんだけど、気になる。

上流の改善は、PPAP Back Endの構成が変わったことによるものだ。Middle、Backへの分割、更に直結化（こっちのほうが大きいかな）によって、どのくらいかな、、アンプをグレードアップするぐらいの改善があった。

直結化したとき、そんなに変わらないな、、と最初は思った。しばらく聴いていて、どうも腑に落ちないと思ううちに、アンプがBrooklyn Ampであることに気が付く。なんとなくSX100で聴いてるような気になっていたのだ。
アンプを切り替えて、改めて改善していることを確認した。
つまり直結化による上流改善の度合いは、Brooklyn AmpからSX100に替えるのと同等だろう、ということだ。

そして、SX100の音の改善が、Brooklyn Ampの改善よりも、かなり大きい感じなのだ。
以前は、Brooklyn Ampは感覚的にSM-SX100の97～99%ぐらいと書いていた。これはブラインドで区別がつくかどうかぐらいで、その後もそれは変わらなかったのだけど、現在は、、90～95%ぐらい？、、多少幅があるけど。
たぶんブラインドで分かる。
そこまで差が付くのは、Brooklyn Ampにはアッテネーターを咬ませていることも影響しているのではないか。

そういうわけで、以下、試聴結果。

其々のアンプについて、MONITOR1使用の有無で音を比べる。
MONITOR1のボリュームは50で固定。普段使っている位置だ。聴感での音量を合わせるためmpd、SM-SX100のボリュームを調整した。
試聴に使った音源は下記。Deezer HiFiのストリーミングを使用した。
Whispering Forest : Walter Tilgner

まず、SM-SX100。

ボリューム : mpd:75/100 SM-SX100:50/128
以前よりも音場、音像の見通しが良くなっている。
隙間が見通せるというのか重なり具合が分かり易くなった。以前の様相をバウムクーヘンとしたら、現在はミルフィーユという感じだ。間に挟まっているのが何なのか見える感じ。それらの質感も違う。より微細なニュアンスが表現されている。
こんなこというとあれなんだが、何か次元が違う感じに良くなった気がする。

ボリューム : mpd:75/100 SM-SX100:90/128 MONITOR1:50/100
MONITOR1をDACとSX100の間に入れてみる。
音量を合わせるためSX100のボリュームを90に上げる。
音は、少しだけ霞んでいる。見通せるという感じが薄れている。
ブラインドでは聴き分けられない、かもしれない、かな？　分かっていて比べたら明らかに違うんだけど。聴き慣れてたら、ブラインドでも分かる違いだと思う。

続いて、Brooklyn Amp。

ボリューム : mpd:85/100 Brooklyn Amp:x MONITOR1:50/100
MONITOR1のボリュームは50で固定。
Brooklyn Ampはボリュームがないのでmpdで音量を調整する必要がある。聴感で音量を合わせると、若干mpdのボリュームが上がった。
これだけ聴いていたら、悪くない。
しかしSX100と比べたら、良く言えばまったりしていて、見通しが良くない。マットすぎる感じ。
Brooklyn Ampの音も以前よりは改善している筈なのだけど、比較してしまうとそんな気がしなくなる。

ボリューム : mpd:50/100 Brooklyn Amp:x
MONITOR1を外すと音量が上がるので、mpdのボリュームを絞る。
音の曇りがなくなった。見通しが良い。
かなりSX100に近付く。しかしSX100で感じられるレベルの音場、定位の明瞭さには届かない。バウムクーヘンからミルフィーユへの途上という感じかな。
それでも直結化以前のSX100よりいいかもしれない。これは記憶との照合でかなり微妙なところだ。直結以前の設定に戻して比べるといいんだろうけど、そこまでするのは色々と面倒だ。
MONITOR1併用のSM-SX100と、同等ぐらいか、いや上回っている？　ケーブル抜き差ししながらの試聴で、これも微妙だ。

今回、試聴してみたら、Brooklyn AmpにMONITOR1を併用することで、SM-SX100との音質の差が開いてきている気がする。
いや、書き方がまずくて誤解を招きそうなので訂正。以前はMONITOR1併用で気にせず聴けたけど、上流の改善に伴ってSX100の音が大きく改善したので、ギャップが気になり始めたということだ。
今のところ運用上の問題になっていないので、当面は様子を見ながら使うつもりだ。

今更だけど、やはりアッテネーターは使わずに済むなら使わないに越したことはないと思った。
問題は、使わないとmpdのボリュームだけで音量調整することになるので、音源によってはmpdのボリュームを10まで下げるとか、そういうレベルの調整が必要になること。
さすがにそうなるとデジタル信号レベルでの劣化が心配、、、
音質を維持するには、より良質なアッテネーターかプリアンプが必要ということになるだろうか。しかしXLRでつなぐ必要があるので、製品から探すとしたら機種選択が厳しい。
なかなかどうにも悩ましいので、気長に考えようかと思う。

LANの直結を今まで試みていなかったのは、利便性が低下することと、色々やりかたを調べるのが面倒だったからだ、、、
しかし、やり残していることなのでやることにした。

さて、、、先立っての試験運用を何を使ってやるか。
LAN端子を2つ以上持っている機械は、うちにはapu2以外にない。メインシステムで試すしかないということだ。
トラブルがあっては面倒なので、apu2のSDカードをバックアップしておく必要があるかな、、、
普段からバックアップを取ってないのかといわれたら、どれがバックアップなのか分からなくなっているのだ。何をやってるのかまったく分からない。

そんなことを考えていたら、そういえば暫く前にBack EndのイメージをGoogleにアップしてたっけ、と思い出した。
あれを落としてきて試せばいいんじゃないの。
tc64-11-1-base1z-2020-04-05-PPAP-BE.img
https://drive.google.com/file/d/1kHhCtR4WCWs3_8i32JrVgGFin-YK9KIZ/view?usp=sharing
そういうわけで、ダウンロード。
カードに焼く。

物理的に遠くに離してあったMIddle EndをBack Endの近くに戻す。
まず状況。

   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)           www.tinycorelinux.net

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:40  
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42922414 errors:0 dropped:2894 overruns:0 frame:0
          TX packets:43024988 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:62288871488 (58.0 GiB)  TX bytes:62314222899 (58.0 GiB)
          Memory:fe600000-fe61ffff 

eth1      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:41  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe700000-fe71ffff 

eth2      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:42  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe800000-fe81ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$ 

現在、IP固定の設定はしていない。DHCPサーバーからeth0にアドレスを取得している。
今回はeth1のIPを固定してみる。

ところで、どれが0でどれが2だったかいつも分からなくなるので写真を貼っておく。
シリアルケーブル端子に近い方が0である。

IP固定は昔、piCoreを使っていた頃はよく設定していた。
だけど、最近はしていないのですっかり忘れている。というか、Tiny CoreでのIP固定はしたことがない。
複数のイーサネットポートを扱うのも初めてだ。
どうなんだろ、piCoreみたく/optにeth1.shを作って置いといたらいいのかな、、、

Middle End の電源を落として、ケースの蓋を開ける。
SDカードを入れ替えて、起動する。
以下、sshでログインしてからの経過。

vi /opt/eth1.sh

#!/bin/sh
pkill udhcpc
ifconfig eth1 192.168.10.2 netmask 255.255.255.0 broadcast 192.168.10.255 up
route add default gw 192.168.10.1
# echo nameserver 192.168.10.1 > /etc/resolv.conf

chmod +x /opt/eth1.sh

sudo vi /opt/bootsync.sh

#!/bin/sh
# put other system startup commands here, the boot process will wait until they complete.
# Use bootlocal.sh for system startup commands that can run in the background
# and therefore not slow down the boot process.
/usr/bin/sethostname box
/opt/bootlocal.sh &
/opt/eth1.sh &

filetool.sh -b
sudo reboot

viでeth1の設定ファイル「eth1.sh」を作成。IPを192.168.10.2で固定する。nameserverの記述は要らないのではないかと思ったのでコメント化した。
chmodで実行権限を与える。
bootsync.shファイルに「/opt/eth1.sh &」を書き加える。
filetool.sh -bで保存し、リブート。

リブート後、sshでログイン。

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:40  
          inet addr:192.168.1.33  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:562 errors:0 dropped:28 overruns:0 frame:0
          TX packets:246 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:52631 (51.3 KiB)  TX bytes:35785 (34.9 KiB)
          Memory:fe600000-fe61ffff 

eth1      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:41  
          inet addr:192.168.10.2  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe700000-fe71ffff 

eth2      Link encap:Ethernet  HWaddr 00:0D:B9:47:8A:42  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe800000-fe81ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$ 

eth1に「192.168.10.2」が振られている。
次はこれをMiddle Endにしていく。
過去エントリーを参考。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20210824a.htm
PPAP Back-Endをタンデム化

sudo vi /opt/bootlocal.sh

/usr/local/bin/ncat -kl 4400 -e "/usr/local/bin/ncat 192.168.10.10 4400"

filetool.sh -b
sudo reboot

bootlocal.shファイルに上記のようにコマンド記載。Back EndのIPを「192.168.10.10」とする。
これで動くのかな、、、
合わせて、Back Endのほうも設定し直していくということになる。

Back Endのほうは、イメージを焼くのは飛ばしてsshにログインして設定した。
Middle Endでの試行でIP固定の設定ぐらいまでは出来そうな目星は付いたので。
（6月8日、下記の書き間違いを修正した）

vi /opt/eth1.sh

#!/bin/sh
pkill udhcpc
ifconfig eth1 192.168.10.10 netmask 255.255.255.0 broadcast 192.168.10.255 up
route add default gw 192.168.10.1
# echo nameserver 192.168.10.1 > /etc/resolv.conf

chmod +x /opt/eth1.sh

sudo vi /opt/bootsync.sh

#!/bin/sh
# put other system startup commands here, the boot process will wait until they complete.
# Use bootlocal.sh for system startup commands that can run in the background
# and therefore not slow down the boot process.
/usr/bin/sethostname box
/opt/bootlocal.sh &
/opt/eth1.sh &

filetool.sh -b
sudo reboot

Middle Endと同じ手法で、eth1の設定を行っていく。
filetool.sh -bで保存し、リブート。

リブート後、sshでログイン。

tc@box:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0D:B9:50:86:58  
          inet addr:192.168.1.89  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:44 errors:0 dropped:0 overruns:0 frame:0
          TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6283 (6.1 KiB)  TX bytes:5919 (5.7 KiB)
          Memory:fe600000-fe61ffff 

eth1      Link encap:Ethernet  HWaddr 00:0D:B9:50:86:59  
          inet addr:192.168.10.10  Bcast:192.168.10.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe700000-fe71ffff 

eth2      Link encap:Ethernet  HWaddr 00:0D:B9:50:86:5A  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:fe800000-fe81ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$ 

eth1に「192.168.10.10」が振られている。

さて、直結で機能するかどうか。
Back Endのeth0からLANケーブルを抜く。
MiddleとBackのeth1端子をLANケーブルでつなぎ、Midlle EndからsshでBack Endにログインしてみる。

tc@box:~$ ssh tc@192.168.10.10
The authenticity of host '192.168.10.10 (192.168.10.10)' can't be established.
ECDSA key fingerprint is SHA256:eICMkwr/u6JIomP1WNI9YocJTnDxmI8M7ICHoj/oeEY.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.10.10' (ECDSA) to the list of known hosts.
tc@192.168.10.10's password: 
   ( '>')
  /) TC (\   Core is distributed with ABSOLUTELY NO WARRANTY.
 (/-_--_-\)           www.tinycorelinux.net

tc@box:~$ 

いけました、、、
次、ncmpcppからFrontのmpdに音楽再生の指示を出してみる、、、音は出ました！

はあ、、やってみたら簡単なものである。
もとのつなぎ方と直結、両者の違いを図にしてみた。

音質はどうか。
例えばベールが1枚はがれたようなとか、、薄皮1枚のベール？、、
前とあんまり変わらないような。
正直、違いが分からない、、、どうなんだろう。
まあ、耳が悪いということなのかもしれない、、、

まあ、でも、せっかく設定したのだし、暫くはこれで使っていこうと思う。
暫く使った後で戻したら、こんなに違うんだっけ！ということもあるかもしれないし。

pkill udhcpc
sudo ifconfig eth0 down

pkill udhcpc
sudo ifconfig eth2 down

今回はちょっとした小ネタというか。
DaphileでMQAを再生できるかという話、なんだけど、Daphileサーバー本体からの出力（USBとか）は試していない。
LAN経由でpiCorePlayerに送ったらできましたよという話だ。

システムの構成図。

うちではDaphileにNASをマウントして使っている。NASにMQA CDからリッピングしたMQAファイルを置いている。
下図が再生時のDaphileの画面。
というか、ウェブブラウザでの操作画面のスクリーンショットだ。

左上に、マウントされたNASの共有音楽フォルダが、階層化されている状況を含めて表示されている。
その下にフォルダに含まれているflac-mqaのファイル表示。
右のプレイリストに登録された曲が表示されている、、、のだけど、曲名はリッピング時にタグを入れるときに僕がサボったので、ちゃんとしていない。ちゃんと入れたらちゃんとした表示になる。

piCorePlayerのUSB出力からM500に音声データが伝送されて、表示された様子。
MQA　352.8kHzと表示されている。MQAの音がする。

たぶんだけど、Daphileサーバー本体からUSB出力してもMQAを鳴らせるのではないかな。試してないから明言はできないけど。

うちには無線機能がない古いRaspberry Piが幾つか、使わないままになっている。
以前のエントリーで、これらにUSB無線アダプターを付けて、piCoreで使えるようにしようという話を書いた。
Raspberry Pi + USB WiFiアダプターで piCore 起動時に自動的に無線LANに接続させる
http://blown-lei.net/endive/blosxom.cgi/pc/20211109a.htm

その後、考えた。
piCoreに拘らなくてもいいのではないか。
そういうわけで、今回はRaspberry Pi OSで、あらかじめIPアドレス固定だ。
ただ、ネット上の他のサイトを読んでいたら、今回うちでやった手法は古いやり方であるらしい。とりあえず動いてるからいいのかな、という感じだ。

今年の4月にRaspberry Pi OSは以前よりもセキュリティが厳しくなって、初期設定のpiユーザーがなくなった。
An update to Raspberry Pi OS Bullseye
https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/
いろいろやり方が変わって面倒なので、使っているのは最新のBullseyeではなくてBusterだ。

以下、忘れるので備忘録。処置を列記。

まずraspberrypi.comで、「Raspberry Pi OS Lite (Legacy)」と書いてある処からBuster Liteをダウンロードする。うちではモニターを使うのは想定していないのでLiteを使う。
https://www.raspberrypi.com/software/operating-systems/#raspberry-pi-os-legacy

マイクロSDに焼く。
sshが使えるようにbootパーティションにsshファイルを作って、Raspberry Pi（B+と初期型の2）に刺す。
LANケーブル、USB無線アダプターも刺して、電源に繋いで起動。
IPを確認しsshでログイン（ユーザー：pi、パス：raspberry）。

sudo raspi-config で設定した項目は以下の通り。他は触らない。下手に触ると上手くいかなくなるようだ。うちだけか？、、。

1 System Options / Hostname
5 Localisation Options / L2 Timezone
6 Advanced Options / A1 Expand Filesystem 

書き忘れていたが、どこかで sudo apt-get update、sudo apt-get upgrade している。

lsusb でUSB無線アダプターをラズパイがどう認識しているかを確認。
下記のように認識している内容が表示される。

pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

1番目の行に「Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter」と詳細が表示されている。どうやら使えそう。

次に、無線LANルーター認証の設定ファイルを記述する。
まずPSKの生成。下記コマンド使用。
SSID（ネットワーク名）とPassphrase（パス/暗号化キー）は、ローカルの無線LANネットワークで決まっている筈である。

wpa_passphrase SSID Passphrase

network={
ssid="Your_SSID"
#psk="Your_Passphrase"
psk=bca18993a64219d23b7b4cf1214d999d812b5... ＊snip＊
}

こんな設定の文面が表示される。
pskとは事前共有鍵（Pre-Shared Key）というもので、暗号鍵を事前に設定しておくということらしい。
これを「wpa_supplicant.conf」に追記記載する。

sudo vi /etc/wpa_supplicant/wpa_supplicant.conf

network={
ssid="Your_SSID"
#psk="Your_Passphrase"
psk=bca18993a64219d23b7b4cf1214d999d812b5... ＊snip＊
key_mgmt=WPA-PSK
proto=RSN
pairwise=CCMP
group=CCMP
}

更にkey_mgmt、proto、pairwise、groupも追加。これらは認証方式と暗号方式によって記載内容が変わる。
うちの無線LANルーターで設定を見たら「WPA2-PSKとAES(AES)」と書いてある。
これは、認証方式がWPA2-PSK、暗号方式がAES、という意味らしい。
記載をこれに合わせる。

次に下記ファイルに固定するIPアドレスなど設定を記載。

sudo vi /etc/network/interfaces


auto wlan0
allow-hotplug wlan0
#iface wlan0 inet manual
iface wlan0 inet static
address 192.168.1.xxx
netmask 255.255.255.0
gateway 192.168.1.1

# wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

sudo reboot　で再起動、設定したIPアドレスで無線LANにつながるはず。

しかし有線LANのほうはつながらなくなる。
USB無線アダプターを外して有線LANをつないでも、つながらない。考えてみたら上記設定は無線しかしていない。
有線も使いたかったら、wpa-confの行をコメント化してwpa-roamで設定する方法もあるようだが、よく分かっていない。

前回の日記から1ヶ月が過ぎた。
オミクロン（たぶん）は収束した！！！

長かった、、、
一時はどうなるかと思ったが、対応方法の改善をあれやこれや行って、特に3月に入ってからは新たな発症は全くなくなった。逆に言えば、それまでにうつる人には2月中に全部うつった、ということ。最終的に、うつらなかった患者さんは2割程だ。
それでも経過を見ないといけないので、収束宣言が直ぐには出ない。
医療スタッフはみんな防護服のままで、ゾーニングの解除も出来ないまま、対応継続していた。

最後の患者さんの病状が安定して経過しコロナ対応解除になったのが3月10日。最初の患者さんが出たのが2月11日だったので、きっちり4週間だ。
新たな患者さんが本当に出ないのかを確かめるのに、さらに数日。
その上で、未発症者（病棟の患者さんと職員両方）のPCR。
これで陽性が出なければ、収束宣言、となる。

いや長いよこれは。繰り返しになるけど。
オミクロン株というのは、発症者を2日だったか、動かさずにいたらフロア全体に広まるのは必発ということらしい。
そんな対応は、いつも簡単にできることではない。
うちでも最初の患者さんを検査陽性となったその日のうちに個室対応にしたが、結局は病棟全体に広まってしまった。
一旦広まったら次々に発症者が出るに合わせて治療対応していくしかない。
2月はそれで手いっぱいだった。

しかし、そういう最初の失敗があったので、他の病棟でたまたま新たなコロナ患者さんが出たとき、早急に広範に検査して陽性の患者さんをコロナ対応中の病棟に移動して、おかげでその病棟にはそれ以上には広がらなかった。つまり、経験を生かすことはできたということだ。

最初のうちは、感染対策の専門家から見て問題ないというレベルの感染対策は、やはり出来てなかった。実践がなかったところで机上で勉強したことだけでは、なんやかんやで追い付かないということを痛感した。
例えば防護服を着ての看護で、フェイスガードが凄く曇りやすい、患者さんに点滴するのに手元が見えなくなるので、ついつい無意識に手で触ってしまう。こうなると何のためにガードを付けているのか分からない。こうしたことを防ぐにはどうしたらいいのか。
やってみないと分からないことが、実際にやらないといけなくなってからどんどん出てくる。他にもぽろぽろと盲点があった。

そういう意味で、2月半ば過ぎに自治体の感染対策チームの助言が得られたのは大きかった。ゾーニングの見直しや防護服等の使い方の徹底など、大事なアドバイスを得ることが出来た。このチームのスピード感は凄かった。これは良しこれはダメと、こっちの背骨を叩きなおされた感じがする。
チームはとても忙しくて、休む間がないそうだ。

イレギュラーだったのは、コロナが完治した患者さんを他の病棟に移そうとしたところ、発熱した。移る先の病棟がコロナの再発を心配するので抗原検査をしたところ、陽性が出たので移れなくなってしまった。
発熱は褥瘡の可能性が高いと考えられ、褥瘡治療のために病棟移動を考えていたのだけど。看護師が防護服を着たまま処置を行うのでは、普段は簡単なことが簡単ではないこともあるからだ。

こういうことは、コロナが始まった頃にネットで読んだことがあった。
しかし知識としては曖昧で、今更自分のところで問題になるとは思ってなかった。
保健所に問い合わせたところ、完治して感染性が無くなっていても陽性が出ることはよくあることだそうだ。どの程度の頻度でそうなるのかのデータはないようだ。
だから最近は、完治の確認のためのPCRや抗原検査はしない。いつ陰性になるのかもはっきりしないということらしい。抗原は残ってるけど、ウイルスとしての増殖力や感染性は無くなっていて、再発したり他人にうつすことはない、ということだ。
どうも、こういうのは偽陽性とは言わないようだ。検査自体が間違えているわけではないからかな、、、

いずれにしても、まぎらわしくて困る。
いくら理屈では感染しない、心配ないと言っても、それでも不安になる人はいる。
そんなこんなで、ほとぼりが冷めるまで、その患者さんは病棟を移動できなくなってしまった。幸い、病棟を移らなくても治療ができているので、大事には至ってないのだけど。

しかし、こういうことについて「感染性がない」と保健所が言えるのも、多くのケースがあって知見の蓄積があってのことだと思う。
こうなるまでには、沢山の戸惑いや混乱があって、それを越えてきての現在があるのだ。
コロナが始まって2年になる。
その間にわかったこと、まだわからないことがあって、ウイルスは形を変えていくから、また分からないことも出てくるが、それでも人間側も知識や対抗する技術を蓄積して、そうしていくうちに、コロナが日常の病気として定着していくのだろう。いわゆるウィズコロナとかいうやつだ。

そのあたりを、とても丁寧に書いた記事があったので、下に揚げておく。コロナがない生活には戻れない。コロナとの戦いがどのようにして日常になるのか、ということだ。
BuzzFeed
「新型コロナの方がインフルエンザより致死率は高そう」　そもそも比べられない2つの感染症を無理やり比べる理由
https://www.buzzfeed.com/jp/naokoiwanaga/covid-19-influenza-suzuki

そんなこんなで、なんとか収束に漕ぎ着けた。
とりあえず、よかった、、、

そういうわけで、自宅での子供部屋への隔離生活は終了となる。

変化があったら何か書くつもりだったが、始めたときから大きな変化はない。
いちいち石けんで手洗いは面倒なので、アルコール消毒に置き換えたことと、3月に入ってからはN95マスクを止めて不織布マスクにしたぐらいだ。

マスクを替えたのは、2月末の無症状の人全員のPCRで僕が陰性になったからというのと、病棟で新たな陽性者が出なくなったのが大きいかな。病棟での運用で、リスクが大きい処置の時以外は不織布マスクでいいということになったので、それに準じたという形。但しマスクは間違った使い方をしないことが大事だ。N95は正しく装着したらかなり息苦しいので、感染リスクが少ない状況なら不織布マスクの方が仕事しやすくて負担や疲労が少ない。
実際、替えてからの方がうちでも過ごしやすくなっている。

なんのかんので気を紛らわせてはいたけど、家族と顔を合わせない生活は、やっぱり何となく味気ない。つまらない。
僕なんかは1か月ぐらいのもんだけど、コロナ治療専門の病棟では、こういうのがずっと続く人もいるのだ。ストレスが溜まってというのは分かる気がした。

オーディオは結局、ヘッドホンでは飽き足らず、アンプと小さなスピーカーを持ち込んで鳴らしていた。
アンプはTU-870、スピーカーはステレオ誌企画のフルレンジで型番は不明だ。
アンプの上流は以前と変わらず、Daphileをストリーミングオーディオサーバーにして、Raspberry pi 3b+、piCorePlayerからUSB出力、USB DACにRal-24192ut1を充てている。
音源はDeezer、Spotify、あとYoutubeなど。半分以上はポップミュージックを聞くようになった。クラシックもそんなに悪くはないのだけど。あと、ウクライナの戦争関連でYoutube動画の音声を鳴らしたりしている。

以前、音質が悪かったら僕は何を聴くんだろうかと書いたことがあるんだけど、こういう状況で試すことになった。
僕にはスピーカーから音が出る環境が必要だと分かった。
オーディオ的に十分にハイファイでなくても、ないよりはあるほうがいいようなのである。
無論、より良い音質で聴きたいというのはあるのだが、ないならないで、なんとかしようとするようなのだ。

そして音源は、以前に聴いたことがあるものよりも、新しい音源を選ぶ。
聴いたことがあって気に入っている音源を聴くということもあるのだけど、圧倒的に新しい音源を漁っていることが多い。そして気に入った音源は、プレイリストに入れたりお気に入りに登録したりしている。買えるだけCDを買っていた昔と同じである。結局、そういう聴き方が性に合っているのだろう。

聴くジャンルは、音質に合わせるようだ、、、
合わない音源は聴かなくなる。うちのフルレンジで特に合わないと思ったのは、バロック時代の管弦楽だ。とてもうるさい。意外に古典派以降の交響曲は違和感なく聞ける。細かい音の情報はつぶれてしまって、うるさい音として耳に届くことがないのだ。
あとはポップミュージック、ジャズなど。
何しろ、鳴らしてみて気持ち良くないと思ったら次の音源に行く、そういう聴き方だ。

昔、ロックにばっかり聴いていたのは、むしろそういう音質のコンポだったからというのも、あったのかもしれない。
小学生の頃はむしろクラシックの交響曲が好きだったのだ。それも考えてみたら、自宅で聞くより小学校の音楽室で聴くのが好きだった。当時にしては音響に配慮した作りの音楽室で、相応のオーディオコンポーネントが用意されていた。
家のラジカセでは、むしろ軽音楽、そこからニューミュージック、ロックに移行した。当時から音質に合わせて嗜好が変化していたというのは理屈に合っている、、、

しかし、そういうのもとりあえず終わりだ。
またコロナがうちの職場に入ってこないことを祈るけど、ないとは限らない。コロナだから。
でも、本当に入って来ないで欲しいと思っている。

そういうわけで、コロナ日記はここまで。

さて、どこから書いたものか。
まず最初に、この記録は事象の終息後に書かれているものではない。
いま現在までに起きたこと、起きていることについて、忘れないうちに記録しておくために書いている。
人のためではなく、自分のためである。
何処に書くか迷っていたのだけど、取り敢えず、ここに書くことにした。
公開しなくてもいいんじゃないかと思ったんだけど、なんというかな、長年ブログなんて書いてきていると公開するのが自然ということがある。そういうのを隠すとなるとモチベーションが下がるようなのだ。病気である。

兆しは時々あった。
僕の職場の職員が、部署は違うけどコロナ陽性になったという知らせ。家族が陽性になって休んでるという知らせ。
そのまま、職場の中には侵入されることなく、時が過ぎる。
かなり心配したこともあったけど、ギリギリで持ちこたえていた。それが今回は違った。

今月上旬、職員が１人、職場で発熱し早退。その後、陽性の知らせ。
数日、何事も無く過ぎる。
11日、入院患者さんが1人、発熱。抗原検査で陽性。侵入された。

緊急会議招集。
感染拡大防止のため対応策を検討、病棟内のゾーニングを行っていく。
もともと、そういうことをするような作りに、うちの職場は出来ていない。建物の構造からして、そういうことには不向きにできている。そこを何とか区切りを入れて、危険区域と清潔区域を分けて、動線を作る。
1日目にやったことは、ほとんどそういうことだ。

一度ことが起きたら、総力戦になるというのが実感される。
最初の日は、いつかはあるかもと予想していたこと、覚悟していたこととはいえ、慌て焦る気持ちを押さえながら皆が動く。
前線兵士として動く看護師、指揮官たる医師、兵站を担う医療事務、ワーカー、薬剤師など。
各々が状況を伝達、共有し、知恵を出し合い、整理しながら、なんとか態勢をを確保する。
この時点で、どのように戦況が拡大していくかは予想が付かない。

ここまで書いてきて、思い出す。
僕はもともと、職場の状況を書くつもりでは、ないのだった。
個人情報だとか色々と最近は難しい。何でも書いていいことばかりじゃない。

僕は、自宅で起きていること、したことについて、書いておこうと思ったのだ。
そう最初に思ったのは、それこそ最初の患者さんが出た時だ。
日にちが開いたのは、多少の逡巡があったからだ。でもまあ、書いておくことにした。
後になったら書けない。忘れてしまうからだ。

最初の緊急招集は11日祝日。
そこから帰ってくるなり、女房が言った。

「あなたには、これからはＹちゃん（長男）の部屋を使ってもらうから。Ｙちゃんとも相談して決めたから。」

なんとスピーディーなことか。
実は以前から、職場でコロナが拡大したらどうするか、女房と相談することはあった。うちは1人で籠れる空間は実質的に子供部屋しかない。ホテル住まいするかどうするか、などと話していたのだ。
帰ったら相談しなくてはと思っていたら、帰ったら既に結論が出ていた。すごい。

まず、以前からうちで行っていた感染対策について書いておく。
基本的に、家族全員で行っていたことだ。

外出を極力控える（外食は禁止、買い物の回数を減らし通販の有効活用、ストック食品利用など）。
必要な外出時には不織布マスク2重。
帰宅時には石ケンで手を洗うこと。
子供の登下校は、バス通学の感染リスクを避けるため、僕の出退勤に使う自家用車で送迎（出来ない日もある）。

ざっとこんな感じか。
以前は最も注意すべきリスクは中学に通う長男が他所からもらってくることだった。学校でもらうかバスでもらうか。実際、大事にはならなかったが学校のクラブで広まったことがあった。
その次のリスクは僕。
それが11日を境に逆転したということだ。
感染源に入って仕事しないといけないのだ。自宅に持ち帰る危険がある。

うちの11日からの新体制について書いておく。

生活空間のゾーニング。
子供部屋から必要な物品（教材やマンガ等々）を出して寝室に移動し積み上げる。寝室と言っても居住空間の中心に設えた畳空間で、リビングとそのまま空間を共有している。子供は其処やリビング、ダイニングで勉強するということだ。
子供部屋を僕の主な生活空間として借りる。
だから寝室空間にあった僕の布団を移動する。子供部屋のフローリングの床に敷いている。

移動ラインも出来る限り別にする。
僕は玄関から西側の子供部屋に至る廊下を移動。女房子供は東側からDK、リビングへの廊下を移動。

風呂は共有せざるを得ないので女房、子供の入浴後に僕が入る。
トイレも共有するので、全員使用前後に石ケンで手洗い。僕は手洗い等の後はペーパータオルを使うこと。

僕は自宅では、子供部屋以外ではN95マスクを使用。
子供の通学送迎に際しても、車内でN95マスクを使用し、換気する。
食事は子供部屋に運んで行う（食事は女房子供とは別ということ）。飲み水は、水筒に入れて子供部屋にもっていく。

子供部屋は、出勤する前に換気を行うこと。

僕が担当していた洗濯物干しを女房がすることになった。衣類を通じての感染を防ぐためだ。
他にも、みだりに家の中のものを触らない、ということになっている。

そんなこんなで、11日からこういう生活なのだ。

趣味のオーディオは我慢だ。
リビングに置いてあるスピーカーを鳴らす機会は殆どなくなった。
仕方がないので、Raspberry pi 3B+、piCorePlayer、USB DAC、ヘッドホンで組んだシステムを子供部屋に持ち込んで音楽を聴いている。
phile-webで日記にした奴だ。
こんなところで役に立つとは思わなかった。
https://community.phileweb.com/mypage/5010/

日記ではVolumioだけど、コンセント抜きだけで電源オフしたいのでpiCorePlayerになった。
24192UT1の電源からRaspberry Piの電源も取れるようにしたいと書いているが、日記をアップして暫くしてから工作して、出来るようになったのでコンセントは１つでよくなった。
Wi-FiでDaphileとつないでDeezerも自宅NASの音源も聴ける。
おかげで思ったほど不自由しない。

いや、不自由だけどさ。
当たり前のことしてるだけなんだよね。仕方ない。

そういうわけで、何か新しいことがあったら記録していこうと思う。
今は現状以上に感染拡大しないように願うのみ、なのだけど、オミクロンの感染力は桁外れだ、、、それを実感しつつある今日である。

さて、このエントリーは、適宜追記、修正していくつもり。
読み易いものには出来てないので、気付いたときに直していく。
小さい修正の場合は、いちいち断りを入れないか、入れても時間が経ったら断り書きを消すかもしれない。読みやすさを優先したほうがいいだろうからというのが単純な理由だ。

Daphile – Digital Music Convenience for Audiophiles
https://daphile.com/

DaphileはGentoo Linuxベースの音楽用ディストリビューションで、音声データ処理にはLMS（Lyrion Music Server）が使われている。
非常によくできたディストリビューションだと思うのだけど、困るのは使い方が難しいことだ。
一見、感覚的に使えるように見えるのだけど、気付かないと使い方が分からないことが、ままある。Volumioより難しい。そして使い方のマニュアルがない。

https://daphile.com/download/FAQ.txt
FAQを読んでいて得心した。

Q5.
Hardware. Is Daphile compatible with ... DAC, wifi adapter,　motherboard or any device?

A5.
In general I can't answer these questions.
I have also decided that I will not collect and maintain any hardware compatibility information.
I don't want to take responsibility for possibly providing wrong information for anyone's purchase decisions.

割り切ったものである。
あれこれ説明がないのは、自己責任でも喰い付いてくるユーザーだけが使ってくれりゃあいい、ということなのだろう。

このFAQ.txtに書かれている内容は、興味深いと思うところもあるけど、実際の使用に関してはあんまり助けにならない。Daphileの使い方については、あちこちのサイトで書かれているので、ここで繰り返して書いても意味があまりないかも。だけど説明が面倒なことも多くて、書かれていないことも多いように思う。
そして、自分で過去にやったことを再インストールの際には忘れている、、、そういうわけで、覚え書きを作ることにした。

インストールに際しての注意

Daphileは、ダウンロードしたインストール用Daphileを使って、起動に使うメディア（HDD、USBメモリなど）にインストールして使う。
インストールについての基本的な手順は、下記アドレスのpdfに書いてある。
Daphile Installation
https://daphile.com/download/DaphileInstallation.pdf

単純すぎて嵌りそうなことで、DaphileはLAN経由でウェブブラウザからアクセスするんだけど、https:// IPアドレスだとつながらない。http:// IPアドレスでつながる。

動きさえすればどんなメディアにインストールしても構わないと思うけど（上記マニュアルによると最低2GB）、小さすぎるメディアは避けた方が良い。
というのは、使っていくうちにライブラリ（登録してある音源とか、お気に入りとか、プレイリストとか）が大きくなって来ると、運用上、メディアの容量が足りなくなるようなのだ。
そうなるとDaphileの挙動自体が危なっかしくなってくる。プラグインのアップデートや変更などの操作を受付けなくなる。そういう時には、再生音が途切れるようになったり、不具合も出てくるような印象がある。
うちでは2GBのUSBメモリにインストールして使おうとしたのだけど、あれこれやるうちにデータ収納スペースが足りないと表示され（スクショは撮り忘れた）動かなくなった。そこで4GBのを使っていたんだけど、再び挙動がおかしいので、32GBのに変更して様子をみていた。
ちなみに、うちではNAS音源をマウントして使っていたのだけど、うちのNASには8000枚以上のCDリッピングファイル音源が入っており、其々にcue sheetがある。音源データを読み込むとそこそこ結構なデータ量になる。
Daphileよりもmpdのほうがデータベースを作る速さはずっと速いのだけど、mpdはcue sheetの中に書かれたデータまでは、データベースに読み込まない。
しかしDaphileは、それも読み込んでいる。そのぶん、データベースとしてはずっと大きくなる。ハードのスペックにもよるだろうけど、数10分かかっていた。さらにストリーミングサービスのデータもこれに加わることになる。
しかしそれでも実際のところ、使っているUSBメモリの使用量は2GBより小さい。
だから、どうして容量が足りないと表示されたり不具合が出るのか、分からなかったのだけど。

次に気になるのは、マイクロSDカードとかで運用するのはリスクが高いかもしれないということだ。
基本的にシャットダウンする時はメディアへのデータ書き込みが行われるようで、使う音源の数が多いほど扱うライブラリのデータ量も増えて、シャットダウンに時間がかかっている。
うちでは基本、起動しっ放しなので大きな問題にはなりにくいけど、プラグインのアップデータの際には再起動が必要になり、ライブラリの再読み込みも行ったりしているようだ。
そういうわけで、書き込みの繰り返しに強いメディアを選ぶ方がいいだろうと思う。
使ってないときは電源を切るということなら尚のことだ。

インストール後の設定について

ウェブブラウザからDaphileにアクセスすると、操作画面が表示される。
左にボタンが並んでいて、上から4番目「Settings」をクリックしたら、設定画面が表示される。

うちで「Settings」で設定している項目について、ここでメモしていく。
操作画面で上から並んでいる順番に記載する。
ここに記載がない項目は、デフォルトのままで使っているか、記載する根気が無い項目ということだ。
前述した Daphile Installation のpdfファイルに、General、Audio Device、Storage の項目に付いては、基本的なことについての記載がある。

General

うちで設定しているのは「System name」と「Time zone」。
System nameはネットワーク上で使われる名前なので、好きに付けてやればいい。複数のDaphileを使う場合は違う名前にしておけば区別が付く。
Time zoneは「Japan」。
他はデフォルトのまま。

Audio Device

うちではBIOSで音声出力を止めてUPnPサーバーとして使っているので「No compatible audio devices」と表示されている。
USB DACなどつないだ場合は、ここに表示される筈。

Key Bindings、CD Ripping

うちでは触っていない。
リッピングマシンとして使うと便利という話を聞いたことがある。

Networking

デフォルトのままだと有線接続で、Automatic (DHCP)になっている。DHCPサーバーからipアドレスが自動で割り振られる。
WiFiでつなぐなら有線の状態でアクセスしてから無線の設定をする。IPアドレスは同じままで無線接続になる。

Power

ここではCPUやクロックの設定が出来る。
うちでは CPU frequencyを高めに設定している（2026.09.15.現在、2.4Ghz）。処理能力優先だ。これが低いとDeezerとか、パワーが要るプラグインの動きが悪くなるようなのだ。
デフォルトでは低めに設定されているから調整が必要。
よく解らないというのもあって他はデフォルトのまま。

Storage

ここではストレージ音源の設定を行う。うちでは「Local drives」は無し。「Network drives」でNASの共有ディレクトリをマウントする。
NASのマウント方法については以下エントリーを参照。
http://blown-lei.net/endive/blosxom.cgi/audio_diary/20210413a.htm
DaphileにNASをマウントしてみる（cue sheetが使える！）

Backup

ここは触っていない。
Backupは、Daphileのローカルに音源を保存する場合にバックアップできるみたい？
設定のバックアップも出来るようだ
しかし、使ったことがないので、よくわからない。

System Firmware

Daphileのアップデートがあると、ここに表示される。
接続したメディアにDaphileの新規インストールができたりもするようだ。

Advanced Media Server Settings

ちょうど上の画像を見てもらったらいいけど、「Settings」の表示画面、最下部左側に、暗灰色に白抜き文字のボタンが２つある。
「Save & Restart」と「Advanced Media Server Settings」だ。
後者のボタンをクリックすると、更なる設定用画面が表示される。
横に並んだタブについて、左から順番に記載していく。

Player

DACなど音声出力先のボタンと、設定のボタン（Basic Settings）が表示される。
上の画像では、テスト用システムで運用しているpiCorePlayerが表示されているのだけど、複数の出力先があるようなら、左上のプレーヤー名が表示されているプルダウンボタンから選択して、他のプレーヤーの設定もできるようになっている。

Basic Settingと表示されているボタンからプルダウンで、更に細かな設定を選べるのだけど、設定項目は非常に多い。
うちでは「Alarm Clock」をOFFに。
mp3の音質設定「LAME Quality Level」。これがデフォルトでは最低音質になっているようなので調整した方が良い。

うちではUPnP関連プラグインを使ってmpdサーバーに音声信号を送っていて、ボリューム調整はmpdでする。
そこで「audio」の、Volume Controlの項目は「Output level is fix at 100%」にしている。別に「volume controls adjust outputs」でも動くのだけど、無駄な信号を増やす必要はないので、そういう設定にしている。
合わせて、UPnPプラグインでは、LMS volume changesを「ignore all changes」に、Feedback to LMSを「No」に設定。これは後述する。

My Music

ここはデフォルトのままで弄っていない。

（mysqueezebox.com）

このタグは、DaphileがLogitech社のサポートから抜けたことで、無くなったようだ。

Interface

ここではDaphileの表示を設定。「Show Artist with Albums」「Show Year with Albums」を「Enabled」にしている。
Title Format を書き変えることで、再生曲のリストの表示を変えられる。
その他、各種表示の設定が出来る。

アルバム一覧を表示したときにアーティスト名などが表示されるということだが、ストレージで設定された音源（つまり自宅ローカルの音源）では機能するけど、ストリーミング音源の表示には適用されない。
その他、一度に表示される音源数とか、サムネイルサイズとか、設定できる。

Manage Plugins（Plugins）

過去にはPluginsだったが、現在はManage Pluginsという表記に変わっている。

Daphileでは多数のプラグインが動作している。
ここではリストが表示され、上から「Active plugins」、「Inactive plugins」、「3rd party plagins」と、ずらりとプラグインが並んでいる。
デフォルトで要らないものは外したいし、追加したいプラグインもある。

「Active plugins」にリストされているのが、有効化されているプラグインだ。
うちでデフォルトから外したのは、ネットラジオ関係をいくつか。プレイリストの曲が終わったら何か他の曲を鳴らしてくれるプラグインとか、アマゾンのCDストアにつながるプラグインとか、TIDALのプラグインなどだ。「Active plugins」のリストから外したいプラグインを選んでチェックボックスのチェックを外して、表示右下の「Apply」、「close」。
プラグインによっては、DaphileのOS再起動が必要になる。必要ないものもあるようだ。使いながら個別で確認していくしかないかと思う。

追加したプラグインはUPnP関係、Spotifyなど。
未使用のプラグインリスト（「Inactive plugins」と「3rd party plagins」）で該当するプラグインのチェックボックスにチェックを入れ、「Apply」「close」「Save & Restart」で、Daphileを再起動したら使用可能になるけど、ちょっと複雑。
以下、表にする。

UPnP	UPnP関係では、「UPnP/DLNA Media interface」と「UPnP/DLNA bridge」を有効化する。 まず「inactive plagins」のリストにある「UPnP/DLNA Media interface」を、他のプラグイン同様の手順で有効化。 続いて「3rd party plagins」のリストにある「UPnP/DLNA bridge」を有効化する。チェックボックスにチェックして「Apply」をクリック。 ここで暫く待つと、メディアサーバーを再起動していいかという表示が出るので、再起動。更にもうひとつ、再起動してるので待てと表示が出るので、OK。 そうして待つと、UPnP/DLNA bridgeプラグインの最新版がプラグインリストの最上部に表示される。 ここでチェックボックスにチェックして「Apply」（、、、ということなんだけど、この操作は要らないかもしれない。確認できていない）。 この時点でプラグインが有効化され「Active plugins」に表示される（「Audio Player」の画面表示にすると、右下の灰色のボタンにUPnPレンダラーが表示されていて、Daphileからレンダラーに音声データを送ることが可能になっていることが分かる）。 リスト表示されたUPnP/DLNA bridgeプラグインの「settings」から細かい設定が出来るようになっている。 「UPnP player audio capabilities」の項目で、Max sample rateを一応、768000にしている。うちには一応、768kHzのハイレゾ音源があるからだ。 他、うちではSelect binary はx86_64-static。 Send LMS metadata to player は、cover artをNoにしている。 うちではUPnPでDaphileからmpdサーバーに音声信号を送るが、ボリューム調整はmpdでncmpcppを使って行うようにしている。 その方が微調整がしやすくて便利だからだ。 なので、Player volume managementの項目で、LMS volume changesを「ignore all changes」に、Feedback to LMSを「No」に設定している。おそらく「transparent forward」と「Yes」とかの設定でも問題ないんだろうと思うが、無駄なデータの伝送が無い方が良いのではないかと思うので。 前述したが、Playerタブのaudio設定、Volume Controlの項目は「Output level is fix at 100%」に設定している。 Maximum volumeは出力先の許容量ということなので「100」にしている。
Spotify	Spotifyは「3rd party plagins」の「Spotify for Squeezebox, Still Spotty」を有効化する。 Spotify関連のプラグインは複数あるのだけど、どういうときにどれを使うのか詳細はよく分からない。 有効になると「Spotty」にプラグイン名の表示が変わる。 リスト表示されたプラグイン右端の「settings」をクリックし、設定画面から「Username（ユーザー名）」とSpotifyのパスワードを登録する必要がある。 登録したら各種設定の画面が表示されるので、必要に応じて設定。これで使えるようになる。 SpotifyはWebプレーヤーではギャップレス再生ができない。androidスマートフォンのアプリを使った場合は可能。 Daphileを使って聞く場合、ギャップレス再生可能である。 2025年9月に、Spotifyもロスレスデータのストリーミングが始まっているが、データの送信対象は限定的であり、Daphileのプラグインは含まれていない。320kbpsのデータを受信できる。
Deezer	下の方、2024年1月末の追記で、DeezerはDaphileで使えなくなると書いて、実際、使えなくなったが、同年春には使えるようになった。 Logitech Media ServerがLyrion Music Serverになり、Logitech社から離れてコミュニティで管理されるようになったのに伴い、新しいプラグインが導入された。 但しDeezer Premiumは対応しているが、Deezer Duo、Deezer Familyには対応しない。 表示は極めてシンプルなものになった。 新しいプラグインの使い方は、下記urlを参照。 lms-deezer/README · GitHub https://github.com/philippe44/lms-deezer/blob/main/README.md こまごまとここで説明しなくても、書いてあるとおりにしたらそんなに難しくないと思う。 ハードルは「arl」のコピーだと思うけど、多分ブラウザによって手技も違うし、ここで説明するのは手に余る。各自で対処されたし。 注意点として、Daphileではデフォルトがmp3音質になっている？らしく、確認してCD音質に直したほうが良いかもしれない。ちがってたらごめん。 あと、Spotifyよりも処理にパワーが要るようだ。上の方で記載したPowerの項目で、CPU frequencyを奢ってやること。 2024.01.29.追記。 ２月から、Deezerは、Daphileで使えなくなる。 詳細は下記のアドレス。 https://forums.slimdevices.com/forum/user-forums/general-discussion/1668327-uesmartradio-com-and-mysqueezebox-com-servers#post1668327 logitech FORUMS UESmartRadio.com and MySqueezebox.com Servers 要は、MySqueezebox.comのサーバー保守が終了になるのが原因、ということだ。 セキュリティなど将来的に水準を保って対応していくのが困難と判断したと。 Deezer以外にも、Tidal、Pandoraが使えなくなる。 下記の説明は意味がないものとなるが、記録として残しておく。 （2022.02.記載） DeezerプラグインはLogitechから提供されていて、デフォルトで有効に登録されているが、そのままでは使えない。 上記「mysqueezebox.com」の項目にも記載したが、Logitech Squeezeboxでアカウントを作り、アカウント情報をDaphileに登録しておく必要がある。 https://www.mysqueezebox.com/index/Home 下の画像は、そのLogitech Squeezeboxサイトのスクリーンショット。 Logitech Squeezeboxのサイトに行き、ユーザー登録しアカウントを作る。 ログインした状態で「App Gallery」のタグをクリック。 リストの中に「Deezer」が表示されている。これをクリックし選択したら、説明の記載と「Install App」のボタンが表示されるので、ボタンををクリック。 インストールしたら「My Apps」に「Deezer」が登録される。 Deezerのユーザーアカウント情報（メールアドレスとパスワード）を登録するようになっているので、登録。 これでLMSでDeezerプラグインが使えるようになるようだ。 DaphileはLMSで動いているので、これでDeezerプラグインを使えるようになる。 Logitech Squeezebox、Daphile、Deezerが、アカウントデータを共有？して連携して動くということだ。 DaphileでDeezerを使うメリットは、何よりギャップレス再生が出来るようになることだ。 加えて、容易にUPnPでデータを送れるので既存のオーディオシステムに組み込みやすい。 うちではmpdを使ったPPAP方式で鳴らすのだけど、UPnP経由でmpd-PPAPフロントサーバーにデータを送れるので、非常にありがたい。 下の画像はDeezerの使用画面をキャプチャしたもの。 Spotifyに比べたら素っ気ないが、使い方には大きな差異はない。
Youtube	（2022.02.記載） Youtubeの音をDaphileで鳴らすことができる。 プラグインは「3rd party plagins」、リストの一番下に載っている。 チェックボックスをチェック、「apply」で有効にしたらアプリ再起動しろの表示、再起動したら暫く待ての表示が出る。じきにアップデートとしてリストのトップに上がるのだけど、放置していて問題無し。 そのうちAudio Playerの「My Apps」にYoutubeが表示される。 しかしこの時点では使えない。Youtubeの管理をしているGoogleで「API Key」というのをもらってこないといけない。 DaphileでYoutubeのアイコンをクリックしたら、音が出るようにする手順が表示される。 訳してみた。 YouTube APIキーがありません：キーを取得するには： https://console.cloud.google.com/apis/dashboard に移動します クリック：プロジェクトの作成 プロジェクトに名前を付けます。 例 ： - （略） - 組織はなしのまま [作成]をクリックします プロジェクトダッシュボードで、[API]ボックスの中の「APIの概要に移動」をクリックします。 APIとサービスのダッシュボードで、[APIとサービスを有効にする]をクリックします APIライブラリで、Youtubeを検索し、Youtube DAta APIv3をクリックします。 Youtube DAta APIv3の画面で、[有効にする]をクリックします Youtube DAta APIv3の概要で、[クレデンシャルの作成]をクリックします どのAPIで使用していますか？ との問いに、Youtube DAta APIv3を選択。 どこからAPIを呼び出しますか？との問いに、Webブラウザ（java script）を選択。 どのデータの下でアクセスしますか？の問いに、 共有データを選択。 次に、クレデンシャルが必要ですか？で、 ボタンをクリック。 これで、APIキーが表示されます。 それをコピー。 キーの制限をクリックします APIの制限の下で[キーを制限]を選択し、[Youtube Data APIv3]をクリックします [保存]をクリックします Youtubeプラグインに戻り、キーを貼り付けます （以下略） 正直、これを読んだだけではなんのことかさっぱりわからない。 実際に、Googleのサイトに行って操作したら、多少は分かる。当然だけど、Googleアカウントが必要。 原文が英語で、Googleは日本語表示なのでやりにくいし、何だか少し説明と実際が違うような気もするんだけど、まあ、なんとかなる。 無事にキーを取得し、プラグインに書き込めたら、DaphileでYoutube動画の音を聞くことが出きるようになる。最近は48kHz/16bitとかCDと同等以上の音質のものもあるようで、思っていた以上に楽しめる。

Advanced

Advancedは弄っていない。
各プラグインへのショートカットがある。

Information

各種情報が見れる。
過去には「Logitech Media Server Status」の表示があったが、現在は「Lyrion Music Server Status」に変わっている。
うちではDeezer、Spotifyといった項目もあって、プレイリストに登録された音源データの数などをリストしている。

更に下にはLog Fileへのリンクがある。

Theme

右下、「Theme」という記載の後に２つ、グレーのボタンがある。これでブラウザ画面の表示を変更できる。
左側は「Default」の黒、「Light」の白を選択。 右側は「Wallpaper Toggle」と書いてあって、壁紙の使用、不使用を切り替える。

今のところ、設定についてはこんな感じか。
かなり読み辛いけど、読み易くする余裕はないので、仕方ないかな。

気が付いたら新年だ。今年は特に年越しの実感がなくて、お餅を食べても正月だという気がしなかった。
もうすぐ北京オリンピックだそうだ。
どうにもこうにも実感がないのは新型コロナの所為かもしれないけど、まあ、それでも新年だ。おめでとう。今年もがんばろう。

ブログ更新はちょっと滞っていたが、それというのもアップする話がなかったからだ。

以前にエントリーでアップしたRaspberry Piのアクセスポイント化については、能力が無く中断、寝かすことにした。僕のようなにわかlinux使いには難しい。
Pegasus DACに1.5MHzにアップサンプリングして入力出来ないかもやってはみていたが、alsa、aplayの対応上限が768kHzらしいということで、将来的な対応を待つほうが良さそうだと判明。
最近は、Daphileが不調になりサーバー機種を替えたけど、１つのエントリーにするほどの話でもなし。
システム構成説明のアップデートでもしとこうか、ということだ。

最近のシステム構成は下図のような感じ。

ほとんど変化がない。
まず、有線LANのハブがひとつ減った。
FX-08miniをもしかして外した方がいいかもしれない？と思って外している。取り敢えず、外して害は無いようだ。ここらは電源やGNDの状況で変わるかもしれない。

あと、さっき書いたけど、Daphileサーバーが変わった。
以前はCompaq 6730bという骨董品？といっていいか、そんなノートPCを使っていたんだけど、1月に入ってぶちぶち音が飛ぶようになった。
NAS音源やSpotifyだと問題ない。Deezerでおかしくなる。
DeezerをWebブラウザで聴いたら問題ないので、やっぱりDaphileとDeezerプラグインが不調なのだ。

原因として思い当たったのは、ひとつはRadio Paradiseを鳴らそうとしたこと。
MQAを鳴らすことが出来るかどうか試してみようと思ったんだけど、なんだかおかしなことになって、ついでにクライアントとして使っているノートPCのWebブラウザまでおかしくなり、DaphileからはRadio Paradiseのプラグインを削除、ノートPCのWebブラウザを再インストールということに。
その頃から、Deezerも不調になった。

Daphileを動かすサーバーを替えてみる。
OSが入ったUSBメモリを、HP Elitebook 2570pに刺して起動。スペックは上がった筈だが、状況は変わらず。OSが壊れている？
仕方ないので、Compaq 6730bでDaphile新規インストールし動かしてみるが、何故か変わらず。
そこで、新規インストールしたUSBメモリを2570pに刺して動かしたら、どうやら問題なく動いている。現在、そういう状況だ。古いOSとサーバーと、両方に問題があったのだろうか。
ネット上の掲示板でDaphileについて書かれたのを読むと、apu2だと重いという記述がある。6730bのスペックはapu2よりも下なので、そこそこ重い状態で使っていたということかも。Deezerを使うに当たって、ライブラリ構築するためにプレイリストやお気に入りを多用しているんだけど、登録数が増えてくるのに従い重くなってきたのかもしれない。

新しいDaphileサーバーにしたElitebook 2570pは、以前はmpdアップサンプリングサーバーとして使っていた機械だ。820 G2と2570p、どちらも其々の趣きがあったんだけど、820 G2のほうがモニター的でHi-Fiに鳴る。2570pは揺らぎが出る。Daphileサーバーの不調があって、2570pを転用することにした。

そんなこんなで、今はあれこれ弄らずオーディオを聴いている。ある意味、平和だが退屈でもある。
また何かあったら手を入れていくつもり。

あ、Brooklyn Ampをどうするかが残ってるな、、、

今回はLinuxの話になる。

前回のエントリーは、Raspberry Pi2をAP化、オーディオプレーヤー化しようとしたところ、なんだかよく分からないことになったという話だったんだけど、未だにどうなってるのか分からない。
とりあえずAP化の詳細は置いといて、初歩的なとこから、家庭内LANに無線でつなぐとこから始めよう、と思ったら、意外に嵌ったので備忘録化しておく。

まず使ったpiCoreは、piCore13.0.3 /armv7。つまりRaspberry Pi B2用の最新版。
うちで余っているRas Piは、B+、B2が多く、無線を使うならUSB WiFiアダプターを使うのが前提となる。入手しやすいのは最近の製品となるので、新しいOSじゃないと対応できないんじゃないかと思ったので、piCore7に拘るのは止めたということだ。

今回、それでもUSB WiFiアダプターはLinuxで使えないことが少なくないことを初めて知った。機材自体をpiCoreで認識できなかったり、Linux対応と書いてあってもドライバーをCDからインストールしないといけないのとかあって、ちょっと手間が掛かりすぎる。
何種類か試したけど、今のところ使えているのは、前回エントリーのBUFFALO WLI-UC-GNM、TP-LinkのTL-WN725N、エレコムのWDC-150SU2MBKだ。
Aigital AC600、Rich AC1200M、BUFFALO WI-U2-433DMSは、現在のところ使えていない。

環境構築のインストールに使ったコマンドは以下のとおり。
hostapd、dnsmasqはまだ使わないけど、今後の使用を考えて入れてある。関連があるtczも同時にインストールされる。

tce-load -wi ntp.tcz
tce-load -wi wifi.tcz firmware-brcmwifi.tcz firmware-ralinkwifi.tcz firmware-rpi-wifi.tcz firmware-rtlwifi.tcz
tce-load -wi wireless-5.10.16-piCore-v7.tcz wireless_tools.tcz
tce-load -wi usbutils.tcz usbutils-doc.tcz libusb-dev.tcz libusb.tcz usb-ids.tcz
tce-load -wi hostapd.tcz dnsmasq-doc.tcz dnsmasq.tcz

あれこれネット上で迷ったが灯台下暗しで、最終的に参考にしたのはtceコマンドで見ることができるwifi.tczの説明書き。

Comments: A console based tiny wifi scan access point tool.
 Select from menu or type sudo wifi.sh
 Creates wifi.db in HOME directory.
 Can auto connect to first db entry with use of -a flag, e.g.,
 /usr/local/bin/wifi.sh -a 2>&1 > /tmp/wifi.log
 Add above to bootlocal or bootsync for quick auto connect.
 When mobile, use menu for select list of APs.
 wpa_supplicant driver is defined by /etc/sysconfig/wifi-wpadrv
 default is wext. Add it to backup if changed.
 Available drivers wext,nl80211

加えて「/usr/local/bin/wifi.sh」に書かれているwifi.shのヘルプ。
これはコマンド「sudo wifi.sh -?」でも見ることができる。

Usage:
 Default select AP from menu and request IP via DHCP.
 -a Auto connect to first wifi.db entry via DHCP.
 -p Select AP from menu and prompt for IP configuration type.
 -w Wait indefinitely until lease is obtained
 -? Displays this help message.

これらを参考にして実際に行った手順を、以下に記録しておく。

まず「/opt/bootlocal.sh」に無線LAN有効化のコマンドを書き込む。これで電源を入れたときに、無線LANが有効になる。

tc@box:~$ vi /opt/bootlocal.sh

ifconfig wlan0 up

設定ファイルを書き換えたので保存のコマンド「filetool.sh -b」を打って保存。
sudo reboot で、再起動。

USB WiFi アダプター（今回はTP-Link TL-WN725N）を刺し、ハード認識確認のコマンドを打つ。

tc@box:~$ lsusb
Protocol spec without prior Class and Subclass spec at line 23179
Bus 001 Device 004: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
Bus 001 Device 003: ID 0424:ec00 Microchip Technology, Inc. (formerly SMSC) SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Microchip Technology, Inc. (formerly SMSC) SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
tc@box:~$


tc@box:~$ iwconfig
lo  no wireless extensions.

eth0  no wireless extensions.

wlan0 unassociated  ESSID:""  Nickname:""
  Mode:Auto  Frequency=2.412 GHz  Access Point: Not-Associated 
  Sensitivity:0/0  
  Retry:off RTS thr:off Fragment thr:off
  Power Management:off
  Link Quality:0  Signal level:0  Noise level:0
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:0 Missed beacon:0

tc@box:~$ 
tc@box:~$ ifconfig
eth0  Link encap:Ethernet  HWaddr B8:27:EB:39:F8:15  

      ＊snip＊

lo    Link encap:Local Loopback  

      ＊snip＊

wlan0 Link encap:Ethernet  HWaddr 7C:C2:C6:1B:53:D2  
      UP BROADCAST MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tc@box:~$

こんな感じ。機材は認識されているけど、wifi (wlan0)は機能していない。

wifi.tczの説明書きに沿って設定していく。
sudo wifi.sh を打って、WiFiでローカルのLANに接続する。以下、流れを記載。

tc@box:~$ sudo wifi.sh

Select Wifi Network

    ESSID           Enc	Qual	Channel Type		
 1. ssssssssssss    on	  0	  2	WPA
 2. oooooooooooo    on	  0	  5	WPA
 3. AAAAAAAAAAAA    on	  0	 12	WPA

Enter selection ( 1 - 3 ) or (q)uit: 3

Enter password for AAAAAAAAAAAA (8 to 63 characters): zzzzzzzzzzzz
Sending credentials to requested access point AAAAAAAAAAAA..
deleting routers
adding dns 192.168.1.1
tc@box:~$ 

tc@box:~$ ifconfig
eth0  Link encap:Ethernet  HWaddr B8:27:EB:39:F8:15  

      ＊snip＊

lo    Link encap:Local Loopback  

      ＊snip＊

wlan0 Link encap:Ethernet  HWaddr 7C:C2:C6:1B:53:D2  
      inet addr:192.168.1.42  Bcast:192.168.1.255  Mask:255.255.255.0
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:19 errors:0 dropped:82 overruns:0 frame:0
      TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:89869 (87.7 KiB)  TX bytes:3824 (3.7 KiB)

tc@box:~$ 

こんな感じでLANのアクセスポイントにWiFiで接続できた。
アクセスポイントをセレクトし（上の例だとAAAAAAAAAAAA）、パスワードを入力（上の例だとzzzzzzzzzzzz）、「ifconfig」でIPアドレスを確認すると、wlan0に「192.168.1.42」が振られている。

こうして1回接続することで、接続設定ファイル「wifi.db」が、ホームディレクトリに作られる。このファイルにはアクセスポイントとパスワード、暗号化について記述されている。これを「filetool.sh -b」を打って保存。

wifi.tczの説明書きには、
/usr/local/bin/wifi.sh -a 2>&1 > /tmp/wifi.log
Add above to bootlocal or bootsync for quick auto connect.
とあるのだけど、、、
このコマンドをそのまま使うと、理由は分からないが上手くいかなかった。LANに接続できないままコマンドが指示を出し続け、ログが積み重なるような状況に至る。
そういうわけで、うちではbootlocal.shに下記のようにコマンドを書き込んだ。

tc@box:~$ vi /opt/bootlocal.sh

/usr/local/bin/wifi.sh -a

保存のコマンド「filetool.sh -b」を打って、sudo reboot で、再起動。
これで、Ras Pi電源オン、piCore起動と同時に、wifi.dbに記載されたアクセスポイントに自動的に無線でつながる。

これで、OS起動と同時に自動的に無線LANにつながるpiCore13ができた。といっても、アクセスポイントは予め設定されていて変更するには再設定する必要があるので、いつでも何処でも使えるというのではないけど。あと、USB WiFiアダプターを替えたら設定し直ししないといけないようだ。

ともあれ、これでうちで余っているRaspberry Piを無線でつないで、オーディオ以外でも活用することができるかもしれない。