JPLAYでCPU Affinityとプロセス優先度を設定する(4)


まさか、このタイトルで4回も書き込みをするとは思いませんでした。
まあ、半分はPowerShellの話なのですが、このシェルスクリプトは実に強力ですね。特に今回のように秘密のヴェールをかぶっているJPLAYの中身を探るには最適です。丸裸とはいかないが、水着姿位には出来ますので(^^;;;、チューニングに便利ですね。

本題に入る前に、ここから先の話はスレッドとプロセスの違いが分かっていることが前提になります。「スレッドってなあに?」という方はここらあたり(＠IT Windows OS入門の第3回　プロセスとスレッド)を読んでから、先に進んで下さい。
以降のPowerShellスクリプトはここ(Getting the CPU time and status of threads in a process with PowerShell)の情報をベースにしています。残念ながらこういう情報は英語しかないですね。

折角なので(?)、PowerShellスクリプト作成講座です。
やりたいことは、「プロセスの内部のスレッドの構成を確かめ、それぞれのスレッドがどういう具合に動いているか確認する」です。このミッショッンを達成するには、①プロセスはどんなスレッドから構成されているか、②それぞれのスレッドはどのように動いているか、ということを知る必要があります。
上記リンク先の真ん中あたりにある

$Properties = 'Id','TotalProcessorTime','UserProcessorTime','PrivilegedProcessorTime','ThreadState','WaitReason'
(Get-Process -Id 10080).Threads | Format-Table $Properties

というスクリプトの実行結果をご覧ください。
①、②に必要な情報が綺麗に出力されていることがお分かりかと思います。これを見つけた時の僕の感想は「あら、しめた。これで出来そう」でした。 この二行、二行目の「-Id 10080」という部分を「-Name JPLAYfemto」と書き換え、二行全体をコピーしてみて下さい。PowerShellを起動、画面上で右クリック(ペースト)してみて下さい。

PS C:\Windows\system32> $Properties = 'Id','TotalProcessorTime','UserProcessorTime','PrivilegedProcessorTime','ThreadSta
te','WaitReason'
PS C:\Windows\system32> (Get-Process -Name JPLAYfemto).Threads | Format-Table $Properties
  Id TotalProcessorTime UserProcessorTime PrivilegedProcessorTime ThreadState   WaitReason
  -- ------------------ ----------------- ----------------------- -----------   ----------
1252 00:00:00           00:00:00          00:00:00                       Wait  UserRequest
1424 00:00:00.0468750   00:00:00.0468750  00:00:00                       Wait  UserRequest
1436 00:00:00           00:00:00          00:00:00                       Wait  UserRequest
4556 00:00:00           00:00:00          00:00:00                       Wait EventPairLow
6044 00:00:00           00:00:00          00:00:00                       Wait  UserRequest
6048 00:00:00           00:00:00          00:00:00                       Wait  UserRequest
6052 00:00:00           00:00:00          00:00:00                       Wait  UserRequest
6056 00:00:00.1718750   00:00:00.0781250  00:00:00.0937500               Wait  UserRequest
6060 00:00:00           00:00:00          00:00:00                       Wait  UserRequest
6064 00:00:00           00:00:00          00:00:00                       Wait  UserRequest
6068 00:00:00.0312500   00:00:00.0312500  00:00:00                       Wait  UserRequest
4536 00:00:00           00:00:00          00:00:00                       Wait EventPairLow
2468 00:00:00           00:00:00          00:00:00                       Wait EventPairLow
2464 00:00:00           00:00:00          00:00:00                       Wait EventPairLow
5372 00:00:00           00:00:00          00:00:00                       Wait  UserRequest
5368 00:00:00           00:00:00          00:00:00                       Wait  UserRequest
8276 00:00:00           00:00:00          00:00:00                       Wait  UserRequest

こんな出力が表示されると思います。見事に水着姿の JPLAYfemtoが出現しました(^^;;;。
ここまで来れば、あとは簡単。実際に音楽を再生しながらスクリプトを動かし、それぞれのスレッドがどのように動いているか確認します。そのためのスクリプトです。

$p_name = "jplayfemto"
$mon_intval = 1
$lsw = 0
$oldtime = 0
$elasped_time = 0
$loop = 500
$Properties =  'Id',  'TotalProcessorTime', 'UserProcessorTime', 'PrivilegedProcessorTime', 'ThreadState', 'WaitReason'
DATE
while($lsw -ne $loop) {
	$instances = (Get-Process -name $p_name).Threads
	if ( $oldtime -eq 0 ) {
		get-process -name $p_name | % { $oldtime = $_.TotalProcessorTime.TotalMilliSeconds}
		$initime = $oldtime
		foreach ($i in $instances) { $int_t_ttime +=  $i.TotalProcessorTime.TotalMilliSeconds }
		Write $oldtime
		$instances | Format-Table $Properties
	} else {
		get-process -name $p_name | % { $curtime = $_.TotalProcessorTime.TotalMilliSeconds}
		if ( $oldtime -ne $curtime ) {
			DATE
			$t_ttime = 0
			Write $curtime
			$instances | Format-Table $Properties
			foreach ($i in $instances) { $t_ttime +=  $i.TotalProcessorTime.TotalMilliSeconds }
			Write $t_ttime
			$oldtime = $curtime
		}
	}
	$elasped_time += $mon_intval
	$lsw += 1
	Start-Sleep -Seconds $mon_intval
}
DATE
$t_ttime = $t_ttime - $int_t_ttime
Write $t_ttime

ちょっと長いですが、ベースになっているのは先の二行です。 while($lsw -ne $loop)で所定回数になるまで監視を継続します(この例では10秒間隔、50回)。 監視中、何をやっているかというと、プロセスの合計実行時間に変化が有った時に、プロセスの合計実行時間とスレッドの状態を出力しています。
大きいif文が一回目かどうかをチェックし、一回目なら、プロセスの合計実行時間とスレッドの状態を出力しています。後半の小さいif文が取得した現在のプロセスの合計実行時間とその前に取得しておいたプロセスの合計実行時間をチェックして差があれば、プロセスの合計実行時間とスレッドの状態を出力しています。
while文やif文があって、ゴチャゴチャしていますが、やっていることは単純で、上に解説したような所定の条件が成立した時、先の二行を実行しているだけですね。
以上サルでも出来る(^^;;;パワーシェル講座でした。

このスクリプトを使って、jplayfemto、iplay、ffmpegの動きを観察しました。

結果の説明に入る前に、実験をした僕の環境について。

  • CPUはi5-3470(4CPU-4コア/4スレッド) 3.2GHz、
    CPUは5世代位前の製品です。性能的には最新のものにしてもたいして差はないので、レベルアップするか思案しています。
  • JPLAYシングルモード、
    デュアルモードはたいして音が良くなるわけでもないので、使っていません。
  • Windows10Home 201809版
    license expiredゴジラが怖いので(^^;;;、いまのところ特別なチューニングは無し。
  • femtoサーバは自作NASと接続(4TB)、
    femtoサーバは自作NASを繋いでいます。僕の環境(LAN環境は音楽専用で独立)ではこの方法が一番音が良いと思いますので。
  • SoulNote D-2 内蔵DDC JPLAYモード接続、
    D-2は外部クロック(GPSDO)と接続しています。
  • flac(圧縮レベル5) 44.1KHz、
    「flac圧縮で聴いているとは何事だ」と呆れられそうですが、CD数が多く、圧縮しないとNASに入りきらないので、こうしています。音は、よほどのオーディオマニアでなければ、wavと比較し、たいして変わらないレベルだと思います。
  • タブレットは話題(^^;;;の HAUWEI Android、
    タブレットは話題のHAUWEI製です。ハッキングは怖いですが(^^;;;、噂通りの高性能、低価格なので、使っています。
  • コントロールポイントはBubble DLNA です。


それでは結果をご紹介します。まず、jplayfemtoです。

  Id TotalProcessorTime UserProcessorTime PrivilegedProcessorTime ThreadState  WaitReason
  -- ------------------ ----------------- ----------------------- -----------  ----------
1252 00:00:00           00:00:00          00:00:00                       Wait UserRequest
1424 00:00:00.0468750   00:00:00.0468750  00:00:00                       Wait UserRequest
1436 00:00:00           00:00:00          00:00:00                       Wait UserRequest
6044 00:00:00           00:00:00          00:00:00                       Wait UserRequest
6048 00:00:00           00:00:00          00:00:00                       Wait UserRequest
6052 00:00:00           00:00:00          00:00:00                       Wait UserRequest
6056 00:00:00.5468750   00:00:00.2968750  00:00:00.2500000               Wait UserRequest
6060 00:00:00           00:00:00          00:00:00                       Wait UserRequest
6064 00:00:00           00:00:00          00:00:00                       Wait UserRequest
6068 00:00:00.1875000   00:00:00.1718750  00:00:00.0156250               Wait UserRequest
5372 00:00:00.0156250   00:00:00          00:00:00.0156250               Wait UserRequest
5368 00:00:00           00:00:00          00:00:00                       Wait UserRequest
8632 00:00:00           00:00:00          00:00:00                       Wait UserRequest

これが先程ワンライナー「(Get-Process -Name JPLAYfemto).Threads」で再生開始直後の状態を表示したJPLAYfemtoの500秒後の最終結果です。両方を見比べるといいわけですが、大変なので、表に纏めます。

threads14241252 1436 以下略(6p)4556 4536 2468 以下略(3p)6056606853728632
一回目0.0468750000.1718750.031250-
最終回0.04687500-0.5468750.187500.0156250

Windowsのプロセスの時間管理の最小単位は0.015625であるようです。例えば上表でスレッド番号5372の最終回の合計処理時間が0.015625となっていますが、これは500秒間で最小単位一回分だけしか動かなかったこと意味します。尚、0.015625が最小単位であるという推定は監視していてこれより小さい数字が現れないこと、これより大きい数字は全て0.015625の倍数であることより明らかだと思います。これは1秒を6ビット(64、2の6乗)で表現しているということです。もちろん、実際のOS内部での時間管理はもっと細かい数で行われているはずですが，この数字で繰り上げられて処理されいるようです。
表から読み取れることは明快ですね。主に動いているのは6056と6068の二つだけです。5372が一単位(15.62ms)だけ動いていますが、6056と6068から見れば、1/10以下と小さめの値です。5372のCPU処理時間は全てPrivileged Processor Timeであり、何からのOS関連の処理が取り出されスレッド化されているようです。6056は55%がUserProcessorTime、6068は90%以上がUserProcessorTimeです。これが何を意味するか不明ですが、この極端な差は興味深いですね。この二つは片方がストリーミング処理、もう片方はサーバ処理を行っているとみてよいでしょう。
1424は最初に動いて、その後、動いていないということなので、初期処理を行うスレッドだと思います。その他のまったく動きのない(処理時間 0)スレッドは何らかの意味はあるはずですが、アフィニティと優先度の設定という観点では無視出来そうです。

同じ要領でjplayを分析します。
実行結果の一回目。

  Id TotalProcessorTime UserProcessorTime PrivilegedProcessorTime ThreadState   WaitReason
  -- ------------------ ----------------- ----------------------- -----------   ----------
1244 00:00:00.0156250   00:00:00.0156250  00:00:00                       Wait  UserRequest
1468 00:00:05.5625000   00:00:00.5000000  00:00:05.0625000               Wait  UserRequest
5192 00:00:00.1718750   00:00:00.0625000  00:00:00.1093750               Wait  UserRequest
5128 00:00:00           00:00:00          00:00:00                       Wait EventPairLow
3516 00:00:00           00:00:00          00:00:00                       Wait  UserRequest

実行結果の最終回。

  Id TotalProcessorTime UserProcessorTime PrivilegedProcessorTime ThreadState   WaitReason
  -- ------------------ ----------------- ----------------------- -----------   ----------
1244 00:00:00.0156250   00:00:00.0156250  00:00:00                       Wait  UserRequest
1468 00:00:05.7343750   00:00:00.5000000  00:00:05.2343750               Wait  UserRequest
5192 00:00:00.1875000   00:00:00.0781250  00:00:00.1093750               Wait  UserRequest
5128 00:00:00           00:00:00          00:00:00                       Wait EventPairLow
9740 00:00:00           00:00:00          00:00:00                       Wait  UserRequest
threads124414685192512835169740
一回目0.0156255.5625000.17187500-
最終回0.0156255.7343750.1875000-0

1468の一回目と最終回の差分の172msは全てPrivilegedProcessorTimeです。5192の一回目と最終回の差分の15.6msは全てUserProcessorTimeです。面白いですね。かなり特徴的なスレッドの分け方をしているようです。アフィニティのディフォルトを2としている理由はこのあたりにありそうです。
1244は初期設定処理をしているだけのスレッドのようです。
最後にffmpegの解析。
これは他の二つと異なり常時プロセスが動いているわけではありません。従って、スクリプトも殆どの回は「プロセスが存在しない」というエラーとなります。
動いた時の状態は以下の通りです。このような記録が二回あります。

  Id TotalProcessorTime UserProcessorTime PrivilegedProcessorTime ThreadState     WaitReason
  -- ------------------ ----------------- ----------------------- -----------     ----------
7872 00:00:00           00:00:00          00:00:00                       Wait ExecutionDelay
5436 00:00:00           00:00:00          00:00:00                       Wait   EventPairLow
6580 00:00:00           00:00:00          00:00:00                       Wait   EventPairLow
3212 00:00:00.0156250   00:00:00.0156250  00:00:00                       Wait        Unknown
6544 00:00:00           00:00:00          00:00:00                       Wait        Unknown

当然IDや何番目のIDが動くかという状況も毎回異なります。
この必要な時にプロセスを起動している、処理は全てUserProcessorTimeというのがCPUアフィニティ4を指定している理由だと思います。

さて、以上の結果に基づきアフィニティと優先レベルをどのように設定するか。長くなったので、次回に。

(PC_Audio)   2019/02/16

コメントする

JPLAYでCPU Affinityとプロセス優先度を設定する(3)


前回紹介したスクリプトをどういう具合に自分の環境に合わせてカスタマイズするかを解説します。
まず、スクリプトをJPLAY 7対応させ、もう一度掲載します。

$instances = Get-Process
foreach ($i in $instances) { 
	$i.ProcessorAffinity=13
	$i.PriorityClass='idle'
}
(Get-Process -name jplay).ProcessorAffinity = 2
(Get-Process -name jplay).PriorityClass = 'Realtime'
(Get-Process -name JPLAYfemto).ProcessorAffinity = 15
(Get-Process -name JPLAYfemto).PriorityClass = 'Realtime'

赤で表示した部分が環境に合わせて設定する部分です。アフィニティのCPU指定の部分です。

このスクリプトはJPLAY7でjplay/JPLAYfemtoを決め打ちして、アフィニティとプライオリティを設定するためのものです。NASやコントロールポイントをどこに置くかによって、他のプロセスでもアフィニティとプライオリティを設定したほうが良い場合があると思いますが、無視します。自力で修正してお使い下さい。ただ、それだけでは不親切なので、ヒントだけ書いておきます。

まず、jplay/JPLAYfemto以外で再生中に動くプログラム(プロセス)をどうするかという問題があります。
jplay/JPLAYfemto以外のJPLAY関連の機能で再生中に動くプログラムはffmpegだけです。調べると、このプログラムのディフォルトでの設定は 4 Idle です。これは後で記述する DedicatedCore を0に設定した時でも、このようになるので、そのままでいいのではないかと思います。詳しくは後述します。

次に、例えばサーバのMinimServerやコントロールポイントのUpplayなどをjplay/JPLAYfemtoと同じパソコンで動かしている場合、これらのプログラムの優先度、アフィニティをどうするかという問題があります。
こちらは回答は一つ。聴いてきめるです。様々なケースにもあてはまる一般的な解はなさそうです。
修正方法はここまでの解説でお分かりでしょから、後は自力でなんとかして下さい。

本題に戻って、jplay/JPLAYfemtoのプライオリティの設定ですが、最高レベルのrealtimeになっているので、環境によって変更する必要はないと思います。
デュアルモードのアダプター側パソコンの場合、JPLAYfemtoの設定は不要ですが、残しておいても、悪さはしないと思いますので、このまま使えるはずです(未確認)。

という訳で、結局、アフィニティの設定だけが残ります。
アフィニティCPUの設定方法はマルチコアのCPUの台数とマルチスレッドを使っているかどうかで異なります。 この設定にはマルチコアとマルチスレッドの正しい理解が必要です。ご存じない方はこちら(【CPUの基本】図解でよくわかる「マルチコア / スレッド」の意味)を参照して下さい。リンク先の解説は分かりやすく、よく書けていると思います。

マルチスレッドはプロセスがマルチスレッド対応していないと意味はありません。JPLAYは対応しているようですので、効果はあるはずです。ffmpegについてはこのスレッド(CPU core(s) usage)で最大4スレッドで動くと回答されています。

一般論でいえば、コア(CPU)の数は多ければ多いほど、良好な再生には有利です。

2コア、4スレッド < 4コア、4スレッド < 4コア、8スレッド < 6コア、6スレッド < 6コア、12スレッド 
< 8コア、8スレッド < 8コア、16スレッド

となります。
2コア-4スレッドは4コア-4スレッドに対してスレッド数は一緒ですが、使えるCPU(コア)数は半分です。従って、4スレッド対応により、ある程度(上記リンク先の情報では 15～25%)上がりますが、効果は限定的です。スレッド化はIOアクセスなどCPUを使わない処理時間が長い場合は効果的ですが、CPU処理がメインの処理では余り効果はありません。またスレッド対応していないアプリの場合、CPU数以上の多重度では動きません。

CPU数は倍にすれば、倍の効果はあります。以下は理屈からいうとという比較です。2コア-4スレッドと4コア-4スレッドを比較します。
音楽再生という観点ではプロセス処理のぶつかり合いをいかに回避するかが、マルチコア化の目的です。音楽再生中に複数のプロセスが同時に動いているわけですが、これらが待たされることなくスムーズに動ければ、一番よろしい。4スレッドということは最大4個のプロセスが同時に動けます。今、最大と書きましたが、これはいつも4個のスレッドが同時に動いていることを意味するわけではないからです。例えば、2コア-4スレッドのシステムは同時に使えるCPUの数は2ですので、CPUを使う二つ以上のプロセスが同時に動くことはありません。これに対して、4コア-4スレッドは4つのCPUを同時に使えますので、四つのプロセスが同時に動くことができます。 ただし、2コア-4スレッドであっても、上記の通り15～25%はプロセスの4多重動作が可能です。従って、同じ4スレッでも、2コア-4スレッドと4コア-4スレッドの性能比(という言葉が的確かどうか分かりませんが)は62.5%～67.5%対100%ということになります。スレッド数が同じでもコア(CPU)数が半分だと、2/3位の性能しか期待出来ないということです。

JPLAY7の場合、再生中リアルタイムに動いているプロセスは jplay, JPLAYfemto, ffmpegの三つです。これはタスクスケジューラでも確認できますが、僕は下記のスクリプトで確認しました。

$instances = Get-Process | Sort-Object NAME
foreach ($i in $instances) {
	Write-Host ( $i.ID,"`t",$i.CPU,"`t",$i.ProcessName,"`t",$i.processoraffinity,"`t",$i.PriorityClass )
}

実行結果をJPLAY関連の部分を中心に編集して、表示します。

5784     5.1875          explorer      13      Idle
5808     0.03125        ffmpeg          4      Idle
1308     0.125            jplay              2      RealTime
1300     0.15625        JPLAYfemto       15      RealTime
1944     0.109375      JPLAYSettings   13      Idle
720       0.859375      lsass           13      Idle

項目の並びはプロセスID、累計実行時間、プロセス名、アフィニティ、プライオリティです。

最初に結論を書いておくと、このディフォルトのJPLAYの設定は4cpu以下の環境では最善で、特に変更する必要は無いと思います(上にある僕のスクリプトも同じにしてあります)。6CPU以上の場合はCPUの数に余裕がありますので、JPLAYfemto専用にCPUを二台以上指定するのが面白いと思います。

以下、そのように判断する理由です。
ディフォルトの状態でJPLAY関連のプロセスとそれ以外の一般のプロセスにどのようにCPUが割り当てられているかを下表に示します。

　　　Core0Core1Core2Core3
JPLAYfemto○○○○
jplay×○××
ffmepg××○×
一般プロセス○×○○

JPLAYfemtoはJPLAY6のストリーミング機能とJPLAY7開発されたサーバ機能を合体したプロセスです。合体化はJPLAY7の高音質化を狙ってとられた対策だと思います。またこのプロセスはマルチスレッド対応させ、複数のスレッドとして同時動作を可能にしているようです。このため、アフィニティの指定も15と全てのCoreを使うように指定されていますね。このJPLAYfemtoがマルチスレッド対応させている点がJPLAY6とJPLAY7の一番大きな違いです。
jplayは、JPLAY6と同じく、Core1番に専用化されています。同時に一つ以上のプロセスが動かないということなのですかね。
ffmepgは逆にアフィニティの4に固定されています。これはフォーマット変換というCPUを多用する処理なので、jplayとぶつからないようにしたということだと思います。
一般プロセスもjplayとぶつからないようアフィニティ13が指定されています。
表をご覧になれば、各Coreがどのように使われているか一目瞭然かと思います。
さて、JPLAY 6/7 は、ディフォルトの状態では、CPU Affinityとプロセス優先度を曲(ファイル)の再生開始時に自動的に設定しています。この自動設定を行うかどうかはレジストリ(DedicatedCore)で指定出来るようになっています。従って、冒頭のスクリプトを使うには、JPLAY 7のレジストリを変更する必要があります。

JPLAY 7 のレジストリ操作については英語版のJPLAYのマニュアルのAdvanced settingsに記述があります。以下その内容に基づきます。

「ファイル名を指定して実行」(Windowsキー+R か画面右下のWindowsタブを左クリック)でコマンド入力画面が表示されるので、regedit.mscを入力。レジストリ編集プログラムを起動して、

Computer > HKEY_CURRENT_USER > Software > JPLAY7

と選択します。



DedicatedCoreを操作するわけですが、英文での説明は以下の通りです。

DedicatedCore: [0,1] default and recommended value is 1. Optimizes CPU affinity & priority settings for best sound quality.

となります。このフレーズ、1にするのがお勧めだよと言っているだけで、1や0にしたらどうなるかの説明がありません。これじゃ意味は分からないですね。
ちなみに、JPLAYのEU掲示板でaffinityで検索すると一発で関連する情報のスレッドが出てきます。ここでのMarcinさんの説明は

Correct, there are only 2 values: 0 is disabled and 1 enabled. 1 puts jplay.exe on 2nd core (CPU1) and all other processes on remaining cores (i.e. CPU0, CPU2 and CPU3 for quad core)

となります(JPLAY 6の情報)。これなら分かります。説明はありませんが、0だったら、何もしないということでしょうね。

以上でスクリプトの紹介はお終いなのですが、最後にディフォルト以外で面白そうな設定をご紹介します。

JPLAYfemto.ProcessorAffinity=9
jplay.ProcessorAffinity=2
ffmepg.ProcessorAffinity=4
一般プロセス.ProcessorAffinity=4
　　　Core0Core1Core2Core3
JPLAYfemto○××○
jplay×○××
ffmepg××○×
一般プロセス××○× 



JPLAYfemto.ProcessorAffinity=11
jplay.ProcessorAffinity=2
ffmepg.ProcessorAffinity=4
一般プロセス.ProcessorAffinity=4

ほとんど同じなので、表は省略します。
さて、「この設定を試してみてどうか」という話に移るのですが、その際、前提となるのはJPLAYのスレッドの構成方法とそれがどういう動きになっているかです。当然情報はありませんので、何らかの方法で調べるということになります。例によって、PowerShellスクリプトの登場となります。

以降は次回のお楽しみです。

(PC_Audio)   2019/02/09

コメントする

WinDVD・JRiver&JPLAYでピレシュのBD録画を見る


去年の最後に書き込んだ『ピレシュ 室内楽演奏全集と電子化楽譜を見ながら聴く』という記事の最後に

日本の生ではベートヴェンもやったみたいですが、今のところCD化されていませんね。NHKには録音(録画?)があるはずですが。残念。

と書いたのですが、お正月のプレゼント。BDが届きました。持つべきものはネット仲間ですね。



OPPOのBDPを持っているのですが、白状すると、BDを再生したことはありません。OPPOはパソコン部屋のサブシステムで使っていて、30インチ位のモニターと繋いでいるのですが、BDで見てみたいなという程のコンテンツが無かったもので、DVDとSACD再生専用でした。

このOPPOに送ってもらったBDをセット。内容確認のため、再生してみました。当たり前ですが、初のBD再生は成功して、綺麗な画像と音でピレシュとメネセスのベートーヴェンを楽しめました。

こうなると、これをメインのオーディオシステムで、音楽専用パソコンを使って、再生したらどうなのだろうかという邪念が芽生えます。

やってみました。結構、悪戦苦闘しましたが、結果は very good。以下、その顛末です。

使うパソコンですが、JPLAY 7をインストールしてある音楽専用のものを使うとして、3台あるので、どれにするかと考えました。BD再生がどの位CPUを使うかよく分からないのですが、下限の要求性能はi3クラスらしいので、i5マシン(3470)にしました。OSはWindows 10 Homeの201809版です。

まず、BDの再生ソフトに何を選ぶか。どうせ元が2K画像、AAC音声なので、画質、音質にこだわらず、ちゃんと再生できるかを優先して選択しました。
参考にしたサイトはこちら(Windows10でブルーレイ再生ソフトTOP6)です。VLC、MPC-BE x64、Leawo Blu-ray Player、Macgo Windows Blu-ray Player、PowerDVDを試しました。
結果は悲惨なもので、全滅。必要十分なレベルで再生できたソフトはありませんでした。

VLC、MPC-BE x64はBDを読み取ることができず。Leawo Blu-ray Player、Macgo Windows Blu-ray Playerはチャプター機能が上手く動かない。PowerDVDはスライドバーを使ったシーク機能が使えない。という結果でした。PowerDVDはあと一息という感じですが、僕が使ったのはかなり古い版なので、最新版では直っているかもしれません。
ということで、お勧めソフトは全滅。何かないかなとあさってみたら、バイオニア製のBDRWに付いてきたcorel社のWinDVDのおまけ版CDを発見。試してみました。
正解でしたね。シーク機能も問題なく動きます。ほぼパーフェト。使えそうです。
ということで、再生ソフトはこれで決まり。WinDVD以外のソフトは全て削除。ここまで2時間。結構手間取りました。

さて、再生ソフトを決めたあとは、どういう具合にテレビに写すかです。メインのオーディオシステムがある部屋には、40インチテレビがスピーカーの間に置かれています。これで見ることになります。
問題は音楽専用のバソコンは15インチの液晶ディスプレイを繋いで、モニターしていることです。バソコンを音楽を聴く時とBDを見る時で、いちいち繋ぎ変えるというのは大変です。
という訳で、OSのマルチディスプレイ機能を使ってみるかと考えました。この接続方式は最新のOSを使えば、簡単に出来るようだという知識はあったのですが、実際に試すのは初めて。
「どうすりゃいいの」とググる。EIZOのサイトを発見。さすがにディスプレイメーカー、しっかり解説するサイト(Windows 10をもっと便利にする「マルチディスプレイ」活用テク)がありますね。
要するに「2台繋いで、適当に設定するだけでいいみたい」と分かりました。

「設定」で システム→ ディスプレイ でこんな具合の2台のディスプレイが表示されます。この二台をどう使うか設定します。



設定のポイントは二つ。

  • 二台のディスプレイの関係の設定
  • それぞれのディスプレイの設定の適正化

上の画面の下にこんな画面があります。



ここで設定します。
「二台のディスプレイの関係の設定」は選択肢の中から「拡張する」を選びます。
「それぞれのディスプレイの設定の適正化」は最初の画面のディスプレイの画面をクリックすると該当のディスプレの設定内容が表示されます。そこからテキストのサイズ、解像度などを選択します。

これで、テレビに画像を、液晶モニターにWindowsをコントロールする画面を写す環境が出来ました。ここまで二時間半。「結構、手強いなぁ」という感想です。
しかし、まだまだ、難関は続きます。

マルチディスプレイ「拡張する」の場合、設定した直後の状態では、第一ディスプレイにWindowsをコントロールする画面が表示されます。ディスプレイ画面はディフォルトの状態ではテレビが第一ディスプレイになります。従って、テレビ画面を写していないと、音楽再生関連のコントロールが出来ないことになり、不便ですね。
起動用のアイコンは第二ディスプレイに移すという形での対応は可能ですが、第一ディスプレイ優先に処理しているアプリが多いので、やはり使いづらいです。「何とかならんのかいな」と調べたら、インテル(内蔵チップ)のディスプレイドライバに第一ディスプレイと第二ディスプレイを切り換える機能がありました。



ありがたく使うことにします。
これで、普段は液晶ディスプレイを第一ディスプレイに出来るようになりました。ところが、もう一つ問題が残っていました。WinDVDが第一ディスプレイ優先のアプリなのですね。起動直後の画面は第一ディスプレイに表示され、変更できません。毎回、ヘッダー部分を持って、第二ディスプレイにドラッグしないといけない。面倒です。
再び、ググる。ググり方が悪いのか、起動画面を第二ディスプレイに変更する方法が見つかりませんね。変えられないなら仕方がない。簡単に画面間を動かす方法はないのかなと調べました。

ありました。WindowTeleportというアプリ。マルチディスプレイ環境で画面移動が出来るショートカットプログラムです。このソフトは日本製ですね。案外、こういう機能のプログラムが無いので、貴重です。
CTRL+CTRL で実行権を付与し、ALT+→で画面移動が出来ます。

これで完了です。綺麗にWinDVDを使い、簡単に再生、音を聞くことが出来るようになりました。かかった時間は三時間。悪戦苦闘でしたね。
JPLAYを使えないかなと、WinDVDの設定をさぐってみましたが、残念ながらASIOドライバが使えないので、無理のようですね。

ということでメデタシメデタシなのですが、これで終わっては、地雷源ギリギリを歩きながら、ハラハラさせる書き込みが信条の「みみず工房」の名がすたります(^^;;;。タイトルのJRiver&JPLAYの部分に移ります。

やっぱりオーディオの再生はJPLAYを使ってやってみたいと考えました。「そういえば、JRiverってビデオの再生機能があるのだよね」と思い出しました。BD再生も出来るのじゃなかろうかと考え、試してみました。単純にBDRWから読み込ませてみましたが、駄目ですね。最初の方に書いた VLC、MPC-BEなどの再生アプリと同じ結果です。
「素直にBDディスクとして処理しようとするから、駄目なのじゃないか」と考えました。「素直ではなく処理する」には、どうすればいいか。「ディスクの中を観察。ストリームデータを直接再生すればいいかな」と考えました。
参考にしたサイトはこちら(BDMV(BD-Video)とBDAVの違い【ブルーレイ】)。「送って貰ったBDはBDAVというフォーマットで録画されていて、bdav/streamというフォルダーにm2ts形式でデータがあるわけね」ということが分かりました。ということは、「このm2tsフォーマットのストリームデータを直接再生させることができそうね」となる。試してみました。大成功です。



この時、オーディオの設定はディフォルトのまま。SoulNote D-2、BulkPetドライバという構成で音を出していました。これでも十分良い音ですが、禁断の試み(^^;;;、オーディオ部分はJPLAYを使えないかなといろいろ試してみました。

当たり前ですが、Media Network の指定で JPLAYfemtoをDLNAレンダラーとして動かす(Advaced-> DLNAControllerとConfigure DLNA->Audio->Mode:Originalを指定)というのは失敗。DLNAなのに映像と音声をJRiverとJPLAYで分離して再生しようなんて、神をも恐れぬ(^^;;;、無謀な試みですよね。
この方法はオーディオだけなら有効です。JPLAYをJRiverの操作性で使うことが出来ますので、JPLAYfemtoサーバの操作性の悪さに我慢ならない方にはお勧めです。詳しくはゴンザエモンさんのサイトに情報があります。
それじゃ、ドライバとして動かすかと考え、6.0の時には動いたレジストリのドライバ名を変える方法をトライしてみました。上手くいきませんね。6.0ではOKの方法も7.0では駄目になっているということらしいです。多分、Windowsが賢くなって、こんないい加減な方法では通らなくなったということでしょう。マイクロソフトもなかなかやりますね。調べたら、対応する 7.0用のパッチが欧州JPLAYの掲示板に紹介されていますが、残念ながらダウンロードは出来なくなっています。という訳で、この方法もアウト。
「何とかならんもんかいな」と思案していたら、6.0の時、「ASIO対応していないハードのドライバをASIOで動かす方法として、ASIO Bridgeというソフトがあるよ」という情報があったことを思い出しました。

ASIO Bridgeの使い方は簡単で、VB-Audio Hi-Fi Cableのリンク先からソフトをダウンロード( HIFI-CABLE & ASIO-Bridgeというやつです。VB-CABLE Driverというソフトも同じページからダウンロードできますので、間違えないようにご注意) 。インストール後、起動。こんな画面が表示されます。



latencyを最短の512に変更。画面真ん中下のブラックパネルの上段。ASIO DeviceでJPLAY Driverを選択。再起動します。次にJRiverのTools->Options->Audio->Audio Device でHifi Cable Inputを選択。これだけです。簡単でしょ。
後で調べて分かったのですが、この方法はMarcinさんもご承認の方法ですね。ここ(Using JPlay, AO, and ASIO virtual bridge for a dedicated Bluray PC player?)にそのやりとりがあります。もちろん、決して(^^;;;「JRiverでお勧め」といっているわけではなくて、「BDプレーヤアプリなら、どれでも出来るよ」ということです。
というわけで、この方法はWinDVDでも、Windowsのディフォルトのサウンド出力を 「HiFi Cable Output」にすれば、JPLAY 7 を使って再生できることになります。本当にメデタシメデタシでした。
なお、ASIO-Bridgeは動いていないと、「HiFi Cable Output」ドライバは認識されませんので、BDを見る前に毎回起動するか、file->Sytem Tray を指定する必要があります。

ところで、冒頭のスナップショット、格好いいでしょ。PodPlayerというソフトで作成(というかスナプショットボタンを押しただけ)しました。当然このソフトでも、ASIO Bridgeを使い、BDのフォルダーを指定すれば、JPLAYで再生する音を聴きながら、BDを見れます。細かいチャプター内の操作なども完璧に出来ますので、お勧めします。

(PC_Audio)   2019/01/26

コメントする

JPLAYでCPU Affinityとプロセス優先度を設定する(2)


PowerShellを使って、JPLAY用にプロセス優先度とCPU Affinityを設定するスクリプトを紹介します。

承前です。前回最後に引用した二行のスクリプトをもう一度掲載します。説明の都合で前回二行で書いたものを五行に書き直してあります。

$instances = Get-Process
foreach ($i in $instances) { 
	$i.ProcessorAffinity=12
	$i.PriorityClass='idle'
}

最初の行はGet-Processという関数(コマンドレット)を使い、全てのプロセスを$instancesという名前の配列にセットしています。
次の行のforeachという命令は、バッチ処理にも同じ命令がありますが、$instancesにセットされた全てのプロセスを一つずつ順番に取り出し、{}内の処理をさせます。次の二行の $i.ProcessorAffinity や $i.PriorityClass というのがオブジェク指向言語の書き方です。こういう具合に取り出したプロセスのアフィニティとプライオリティを簡単に書き表し、操作出来ます。
この二行普通の日本語に読みくだすと

$instancesに全ての生きているプロセスを取り出し Get-Process
foreach 取り出した一つ一つ $i in  のプロセスに対し $instances {
	そのプロセスのアフィニティ $i.ProcessorAffinity を12にセットします
	そのプロセスのプライオリティ $i.PriorityClass をidleにセットします
}

となります。 いかがですか。プログラムの各行が綺麗に日本語の各行に対応し、日本語に読み下した内容がそのままプログラムとして書かれていることに気が付かれると思います。この部分を同じGet-Process関数を使って、普通のC言語で書いたとすると、foreach (A in B) や $i.xxx という部分が数行になりますので、 最低でも10行以上になるはずです。

次に jplay と jplayfemto のAffinityを変更する方法を同じように解説します。

Get-Process jplay,JPLAYfemto | ForEach-Object { 
	$_.ProcessorAffinity=1
	$_.PriorityClass='Realtime'
}

これは、冒頭のスクリプトで生きているプロセス全てを取り出していた部分を 、jplay と jplayfemto だけ取り出すように変更しただけです。
「Get-Process jplay,jplayfemto | ForEach-Object」というのが個別のオブジェクトを取り出すための表現です。 この部分は

$instances = Get-Process  jplay,JPLAYfemto
foreach ($i in $instances) { 
	$i.ProcessorAffinity=1
	$i.PriorityClass='Realtime'
}

と書いても同じです。これだと同じということがよく分かっていただけると思います。プログラマーという人種は一行でもプログラムを短くすることに命を懸けていますので、「 | ForEach-Object」と書きたがるのですよね。「 | 」はパイプと呼ばれる機能で、バッチ処理でも使える記述方法です。Get-Process jplay,jplayfemtoで得られた内容(標準出力)をそのまま「 | 」以降のコマンドに受け渡しているわけです。
次の「$_」で受け渡された個別のオブジェクトを指定しています。

このやり方は「CHANGE A PROCESS PRIORITY AND AFFINITY WITH POWERSHELL」に情報があります。
こういう具合に「やりたいことをどうするとPowerShellでプログラミング出来るか」ということを知るには、インタネット検索能力さえあれば、解決出来ますので、プログラミング能力は不要ですね(^^)。

ただし、このスクリプトは指定したプロセス全てが同じ設定になってしまうので、プヤセス毎に個別に指定するのであれば、

get-process jplay | % { $_.ProcessorAffinity=1 }

か

(Get-Process -name jplay).ProcessorAffinity = 1

と一行で書いた方がいいかもしれません。いい加減ですが^^;;;、-name は有っても無くてもよいようです。 上のスクリプト行の%と下のスクリプト行の(Get-Process -name jplay)は同じことで、get-process jplayで取り込んだ内容を意味します。
まあシンプルさでいうと僕の好みは最後の行です。

以上纏めると、JPLAY 6 で jplaystreamer, jplay のCPUアフィニティとプロセス優先度を設定するためのスクリプトはこうなります。

$instances = Get-Process
foreach ($i in $instances) { 
	$i.ProcessorAffinity=12
	$i.PriorityClass='idle'
}
(Get-Process -name jplay).ProcessorAffinity = 2
(Get-Process -name jplay).PriorityClass = 'Realtime'
(Get-Process -name jplaystreamer).ProcessorAffinity = 1
(Get-Process -name jplaystreamer).PriorityClass = 'Realtime'

このスクリプトはJPLAY6用です。
実行すると、ディフォルト値をとらず、最初からコアが設定されている一部のプロセスでは “Access is denied”とか“Cannot process request because the process (2000) has exited.”というエラーになります。
ここまで、かなり丁寧にクリプトの内容を説明してきました。その理由はこのスクリプトはお使いの方のCPUやJPLAYの動作環境に合わせて修正しないと意味がないからです。
ここから修正するためには何を知らないといけないかの話に移ります。

関係する要素は

JPLAYの動作モード(シングル、デュアルコントロール、デュアルアダプター)、
コア数、
スレッド数

です。これ以外に、例えばMinimServer、コントロールポイントを動かしているかどうかなどの要素も影響します。

どういう具合にこれらの要素を判定し、プライオリティとアフィニティを設定すればよいのかの説明に入る前に、例によって脱線します。

PowerShellの使い方について

PowerShellはWindowsの機能を使って何でも出来ますので、クラッカーにとっては格好のツールとなります。ネットに怖いスクリプトをばらまいておいて、パソコンを乗っ取るとか、パスワードを盗むとか、システムを動かなくするとか、何でも出来る筈です。
従って、簡単にスクリプトが動くようにするわけにいきません。ディフォルトではスクリプトは実行出来ないようになっています。
コマンドコンソールからスクリプトを実行するには

@echo off
echo Set Priority and Affinity to Process
powershell -NoProfile -ExecutionPolicy Unrestricted .\SetPrioAff.ps1
echo finished
pause > nul
exit

という内容のバッチ処理を用意しておいて、起動すればいいです。PSスクリプトの名前はSetPrioAff.ps1で、上記の内容で事前に作成しておく必要があります。
PowerShellのコンソールからであれば

Set-ExecutionPolicy RemoteSigned -Force

となります。 毎回、PowerShellのコンソールからコマンド入力するのが面倒ということであれば、グループポリシーエディター(gpedit.msc)でスクリプトの実行を禁止している運用を変えることも出来ます。
やり方は簡単で、「ファイル名を指定して実行」(Windowsキー+R か Windowsタブを左クリック)でコマンド入力画面が表示されるので、gpedit.mscを入力。 



ユーザーの構成 > 管理用テンプレート > Windowsコンポーネント




を選択。 「Windows PowerShell」を選択。



「スクリプトの実行を有効にする」を選択。



「有効」と顔面右真ん中の実行ポリシーで「ローカルスクリプト及びリモート署名済のスクリプトを許可する」を選択。



一つ前の画面で、必要なら「モジュールログを有効にする」も選択して下さい。
以上でグループボリシーの選択はお終いです。以降は次回に。

(PC_Audio)   2019/01/19

コメントする

JPLAYでCPU Affinityとプロセス優先度を設定する


JPLAY 7 は専用DLNAサーバを内蔵する構成をとり、サーバ機能とストリーミング機能を一本のプログラムに合体させ、処理を効率化させることにより、音質向上を図っています。この結果、JPLAY 7のCPU Affinityとプロセス優先度の設定方法はJPLAY 6とは多少異なります。この件について、日本語でも、英語でも、あまり情報はないようですね(僕が見つけたのは 英語の掲示板でのこの情報(CPU core(s) usage)だけでした)。
JPLAY 6 では再生中に動作するJPLAY関連のプロセスは jplaystreamer と jplay の二つのプロセスだけだったのですが、JPLAY 7 では jplaystreamer が jplayfemto に変わり、さらに ffmpeg が追加され、動作するプロセスは三つとなりました。 jplayfemto はサーバとストリーミング処理を合体したプロセスなので、マルチスレッドで同時に動く確率が高いと予想されるので、アフィニティの設定は難しいです。ffmpegはフォーマットコンバージョンというCPUアクセスが中心の処理なので、優先度の設定が悩ましいです。当然、このあたりはJPLAY 7 設計時点で分かっていたわけで、JPLAY 7 の現在のディフォルトの設定は様々な要素を考慮し決定されたものと思われます。
ただし、CPU Affinityを自由に設定するためのレジストリの設定機能(DedicatedCore)はJPLAY 7でも残されていますので、CPU Affinityとプロセス優先度の設定をユーザーが行うことが否定されているわけでは無さそうです。
実際に試してみて、コア数とスレッド数が4以下の場合はディフォルトの設定をいじる必要は無さそうだと思いますが、CPU数が6台以上の構成であれば、JPLAY関連のプロセスを特定のCPUに貼り付け、専用化させる効果はありそうです。
というわけで、いろいろ試してみて分かったことを書いてみたいと思います。

例によって長い前置きからスタートします。

まだ、JPLAY 7 が登場する前、日本語JPLAY掲示板で「Windowsのプロセス優先度とCPU Affinityを設定すると音にいいかもしれない」という提案がありました。
タスクマネージャのプロセス表示から設定したいプロセスを選び、右クリック、「詳細を表示」させて、また右クリック、「優先度の設定」と「関係の設定」を選べば、それぞれプロセス優先度とCPU Affinityを設定することが出来るというわけです。

この方法はWindowsではよく知られた話らしいです。確かに、「Windows プロセス優先度 CPU Affinity 設定」あたりをキーワードにしてググると、解説するページがゴロゴロと出てきますね。日本語だけでも、こんな感じです。

以前から、「タスク優先度とCPU AffinityはLinuxを使う音楽愛好家にとっては常識なのに、Windowsでは何故話題にならないのだろうか」と疑問に思っていながら、それ以上、疑問を追求しなかった不明に忸怩たる思いです(^^;;;。
早速、試しにやってみましたが、なかなか効果がありますね。かなり透明感が上がるという感じです。
特に CPU Affinity とタスク優先度を組み合わせるというアイディアは秀逸です。音楽再生に関連するプロセスにCPUを独占させるという形に出来ますので、強力です。

しかし、音楽プロセスだけ優先度とCPU Affinityの設定を行っても、音楽再生に関係のない一般のプロセスは 0-n までのCPUを自由に使えることになるので、環境によっては、意図とは逆に、かえってCPUの奪い合いを発生させる可能性があります。簡単な解決策は一般プロセスが使えるCPUを制限し、音楽プロセスに割り当てたCPUを使用させないことです。

問題は操作がWindowsのGUIであること。僕の環境で一般プロセスは130以上あります。数が多いので、全てプロセスのCPU Affinityの設定を毎回行うことは不可能ですね。
もう一つ、設定は再起動すると引き継がれません。従って、起動の度に毎回、プロセス優先度とCPU Affinityの設定を行うことになりますが、面倒です。というか、操作が多すぎて、現実的ではありません。毎回、数百のクリックをするというのは不可能でしょうから。
というわけで、何らかの方法でGUIをCUI化し、自動的に実行しないとやっていられないと分かりました。

さて、ここまでが本題に入る前の背景の説明でした。ここからスクリプトの紹介に入るわけですが、その前に、再び、長い前段。優先度とCPU Affinityを設定するコマンドを紹介します。

とりあえず、バッチ処理ならコーディングは簡単です。何とかならないかと調べてみました。

startコマンドで優先度とCPU Affinityの設定をまとめて行えると分かりました。情報はこちら。これなら簡単そうですね。

start /abovenormal /affinity 0x01 notepad.exe

という感じで、起動時のオプションを使って、優先レベル、Affinityを設定できます。上の例は通常より上の優先レベル、CPU0番でメモ帳を起動しています。
オプションの指定方法ですが、優先レベルは単純で

/Low		優先度をIDLEクラスとしてアプリケーションを起動する。
/BelowNormal	優先度を通常より低いクラスとしてアプリケーションを起動する。
/Norma		優先度を通常クラスとしてアプリケーションを起動する。
/AboveNormal	優先度を通常より高いクラスとしてアプリケーションを起動する。
/High		優先度を高レベルクラスとしてアプリケーションを起動する。
/RealTime	優先度をリアルタイムクラス(一番優先度が高い)としてアプリケーションを起動する。

/affinityによるcpu番号の指定方法はプログラミング経験のある人には単純なのですが、16進数で表現されるビット位置のオンオフでその機番のCPUを使うかどうかを指定します。具体的には(CPUが4個ある場合)

0x1	CPU0番を使用(一番右のビットがCPU0番という意味です)
0x2	CPU1番を使用(右から2番目のビットがCPU1番という意味です)
0x4	CPU2番を使用(右から3番目のビットがCPU2番という意味です)
0x8	CPU3番を使用(一番左のビットがCPU3番という意味です)

となります。複数のCPUを指定する場合は両方のCPU機番に対応するビットをオンにすれば良い。例えば

0x3	CPU0番とCPU1番を使用(0x1+0x2=0x3)(1+2=3)
0x9	CPU0番とCPU3番を使用(0x1+0x8=0x9)(1+8=9)
0x6	CPU1番とCPU2番を使用(0x2+0x4=0x6)(2+4=6)
0xC	CPU2番とCPU3番を使用(0x4+0x8=0xC)(4+8=12=0xC)
0x7	CPU0番とCPU1番とCPU2番を使用(0x1+0x2+0x4=0x7)
0xF	全部を使用(0x1+0x2+0x4+0x8=0xF)(1+2+4+8=15=0xF)

となります。二つ以上の値は足し算になります。 10進の10以上の数の16進表現ですが10=A,11=B,12=C,13=D,14=D,15=Fとなります。 以上の解説はCPU数4の時の設定方法です。最近のi5/i7では、CPU数が6とか8という魅力的なスペックがとれます。この場合は6/8ビット必要になるので、0xFFという具合に16進二桁で表現することになります。もちろん10進にこだわって、255までの数字を使って表すことも可能ですが、ちょっとした頭の体操になりそうですね。要領は4個の場合と同じです。
CPU一個の指定です。

0x10	CPU4番を使用(十進で16)
0x20	CPU5番を使用(十進で32)
0x40	CPU6番を使用(十進で64)
0x80	CPU7番を使用(十進で128)

十進の値は、それぞれ、2の4乗、2の5乗、2の6乗、2の7乗となります。
ゴルフ場で貴重品ロッカーを選ぶ時、思い出しやすいよう10進のきりのいい番号を選ぶ人がいます。皆同じこと考えると見えて、0とか5で割れる数はすぐ埋まってしまうのですね。そこで、僕のように16進中毒となった人間(^^;;;はこの16のきりのいい番号を選ぶことになります。これだと、そんな選び方をする人は少ないですから、空きロッカーを決めやすいです。まれに、この方式できりのいい番号が埋まっているゴルフ場があります。そんな時の僕の感想は「変なヤツの多いゴルフ場だなぁ」ですね(^^;;;。
どんどん脱線するので、脱線レベル1に戻します。

0x11	CPU0番とCPU4番を使用(0x1+0x10=0x11)(1+16=17)
0x92	CPU1番とCPU4番とCPU7番を使用(0x1+0x10+0x80=0x11)(1+8=9)
0x6C	CPU2番とCPU3番とCPU5番とCPU6番を使用(0x2+0x4+0x40+0x80=0x6C)(2+4+64+128=218)
0x7D	CPU0番/CPU2番/CPU3番/CPU4番/CPU5番/CPU6番を使用(0x1+0x4+0x8+0x10+0x20+0x40=0x7D)(1+4+8+16+32+64=124)
0xFF	全部を使用(0x1+0x2+0x4+0x8+0x10+0x20+0x40+0x80=0xFF)(1+2+4+8+16+32+64+128=255)

Affinityの設定の詳細については以下のサイトにも情報があります。
How to launch a process with CPU affinity set

さて、ここで卓袱台返し(^^;;;。
これだけstartコマンドのオプションを詳しく解説したのだから、「このコマンドを使ってバッチスクリプトを作るのね」と思われた方、残念でした。
startコマンドは新規にプロセス起動するために使われるので、起動済のプロセスの優先レベルやAffinity を変更するためには使えません。優先レベルだけなら、wmicでOKで出来るようです(記事最初の部分の2番目のリンク「Windows10でプロセスの優先度を指定する方法」を参照)が、Affinity の変更が出来なければ不十分です。また、現在、動いているプロセスが何かを把握し、操作するということもバッチ機能だけで行うことは困難です。従って、動いている一般プロセス全てのAffinityと優先レベルをバッチ処理で変更することは難しそうです。

しょうがないので、再びググります。「Windows process change affinity script」というようなキーワード検索すると出てくるのは英語のサイトばかり。そしてPowerShellを使っているサイトが多いですね。まったく知らない言語なので、ウームどうしたものか。ただ、このシェル言語はオブジェクト対応しているようなので、なんとかなるかなという感じでした。

PowerShellの紹介です。
PowerShellを知らない言語と書きましたが、.NET Frameworkをベースとして使っているのですね。コンマンドレットと呼ばれるオブジェクト関数の多くが .NET Frameworkのオブジェクトを使っていることで、気が付きました。.NET Frameworkはマイクロソフトが開発したアプリケーションの開発・実行環境です。.NET Frameworkの重要な目的は共通言語基盤(CLI)とよばれる言語に依存しない開発環境および実行環境を提供することです。PowerShellはこの基盤を活用して、Windowsバッチ処理と比べれば、比較にならないレベルで強力な処理を可能としているわけですね。これがスクリプト言語として使えるわけだから、素晴らしい。

Windows用のシェルコマンド(スクリプト)としてはいわゆるバッチコマンドがあるわけですが、これは非力で、それなりのシェル環境があるLinuxユーザからみると、論外でした。猿でも出来るGUIより、人間だけが使えるCUIが好きなLinux信者からいうと、Windowsのシェル環境というのは、現代から江戸時代に逆戻りしたようなもので、「とても、やっていられない」となります。
ところが、PowerShellを使ってみて、驚きました。江戸時代から、突然、現代にワープ。凄いです。スクリプト言語は .NET Frameworkをベースにしているので、当然強力です。シェル機能もなかなかもので、LinuxのBashに匹敵するレベルで、十分使えます。ちょっと弱いのはSEDとかAWKといっかコマンドラインから呼び出せる便利なコマンド機能がないことですが、これはLinuxソースから移植したWindows版を捜せば、補えますので、それらを使えば、こと足ります。

「PowerShellって何 ?」という方も多いでしょうから、解説しているサイトをいくつか紹介します。

PowerShellの何がいいかというと、オブジェクト指向型のスクリプトであることです。もちろん、Perl、Ruby、Pythonなど今どきのスクリプト言語でオブジェクト指向対応していないものはありません。しかし、シェルスクリプトでオブジェク指向対応というのはPowerShellだけでないでしょうか。

シェルスクリプト言語がオブジェクト対応すると、何が便利かという説明をします。
例えば、今回のテーマのプロセス優先度やCPUアフィニティを操作するためには、今、生きているプロセスの情報が必要です。PowerShell の場合、これをオブジェクトとして操作できます。
例を挙げます。生きている全てのプロセスにプロセス優先度=idle、CPUアフィニティ12をセットするスクリプトです。

$instances = Get-Process
foreach ($i in $instances) { $i.ProcessorAffinity=12 ; $i.PriorityClass='idle' }

たったの二行。これで処理できます。簡単でしょ。
この二行のスクリプトの出所元はここSet default processor affinity for all applicationsです。

さて、この二行の解説に入るのですが、長くなったので、次回に。

(PC_Audio)   2019/01/12

コメントする

ピレシュ 室内楽演奏全集と電子化楽譜を見ながら聴く


以前に post script で書いたCDですが、全12枚聴いて、とても感心したので、改めてご紹介します。
マリア・ジョアン・ピレシュがエラートで録音した室内楽のレコードを全て集めたCDボックスです。

この人の名前はピリスと表記される場合もあるようですが、どちらが正しいのですかね。
僕には、10年位前にNHK Eテレ(だったかな?)がスーバーピアノレッスンという番組をやっていたのですが、その時の表記がピレシュだったので、ピレシュでインプットされています。この番組、他のピアニストのシリーズも有ったと思いますが、圧倒的に彼女のレッスンが印象に残っています。アドバイスはテクニカルに「ああしろこうしろ」という部分がほとんどなくて、抽象的な助言が大部分でしたが、生徒(プロの演奏家の卵というレベル)が優秀なのか、彼女の指導をハッシハッシと受け止め、ちょっとした助言で、演奏の印象がまるで変わるのが面白かったです。なるほど、さすがプロは凄いという感じでした。

ピレシュのCDに興味を持ち出したのも、この時からです。従って、彼女の活動のピークは過ぎていた時期なので、興味のある演奏家だけど、あまりCDを聴いていない演奏家です。
彼女は今年で引退したようですね。指揮者と並んでピアニストは高齢まで演奏活動を続けることができるみたいですから、随分早い身の引き方だなぁと思いました。聡明な人だから、ホロヴィッツみたいにひび割れた骨董(@吉田秀和)となっても頑張るというスタイルは、彼女には合わないということなのですかね。

このCDボックスは選曲と共演者が魅力的です。選曲はモーツアルトからラベルまでのピアノを含む室内楽の傑作が網羅されています。ベートーベェンとブラームスのチェロソナタが抜けているのと、シューベルトとメンデルスゾーンが多少冷遇されているかなと思いますが、それ以外はほとんどパーフェクト。これを聴けば、ピアノ+弦楽器(1CDだけオーボエ)の編成の古典派、ロマン派、近代のクラシック室内楽曲を必要十分に聴けると言って、差し支えないでしょう。

共演者はヴァイオリンのデュメイとチェロのジャン・ワンがメインです。どちらの演奏家も、なるほどピリシュさんらしい選択だなぁと思わせます。センスがよくて、出しゃばらないけど、芯はしっかりしていて、丁々発止という感じだから。
あと、ピアノ五重奏曲、チェロのメネセスとオーボエのボイドとの共演のCDが一枚づつありますが、これらも素晴らしい録音です。

ここで例によってちょっと脱線します。パソコンで楽譜を見ながら音楽を聴く方法について。

こういうCDボックスの魅力は普段あまり聴いたことのない曲を聴けるという面があります。

僕は普段は現代とバッハ以前の音楽を主に聴いているので、古典派、ロマン派の主要曲でも知らないという曲は山ほどあります(^^;;;。今回のアルバムでいうと、グリーグのバイオリンソナタは初めて、ブラームスのピアノトリオも多分聴いたことはあるけど、よく知らない、「シューマンのオーボエ曲なんてあったの?」というところです。
というわけで、こういう知らない曲を聴くときは楽譜をみながら、CDを(正確にいうと、CDをリッピングして)聴いています。
今回楽譜をみながら、聴いたのはグリーグ、プラームスのピアノトリオ、モーツアルのピアノトリオ、シューマンのオーボエ曲、ラベルとドビュシーといったところ。
最近のインタネットはこういう特殊(なのは僕だけですかね^^;;;)な曲の楽譜でも簡単にダウンロード出来ますので、タブレットやノートパソコンが手元にあれば、手軽に楽譜を見ながら、試聴することが出来るようになっています。
僕が愛用しているのは次の二つのサイトです。

musopenはmusic openを略でしょうね。
IMSLPの方が楽譜の数が豊富です。ただし、IMSLPは会員制で、非会員の場合はダウンロードの制限があります。たまにちょっとだけダウンロードという使い方なら、問題にならないレベルです。
従って、僕はmusopenで捜して、無ければ、IMSLPをチェックというやり方をしています。

特殊な楽譜を捜すときに使うのは

です。それぞれリンク先から民族音楽(フォーク)、バロック以前の音楽など特殊なジャンルの音楽を捜せます。

楽譜を見るだけの専用端末というハード(+ソフト)という製品があります。

詳細はリンク先をご覧いただくといいかと思いますが、凄い製品ですね。「欲しいなぁ」とは思いますが、ipad12インチと比較して、「どちらが良い」のか論じたサイトがあります。

なかなか参考になります。

というわけで、実はこの部分が書きたくて(^^;;;、書き始めたのですが、本題にもどります。
CDの内容を順番にご紹介します。

CD1～3 ベートーヴェン：ヴァイオリン・ソナタ集 全10曲


1997年～2002年。共演者はデュメイ。ベートーベェンのヴァイオリン・ソナタは比較的若いころに作曲されているので、どの曲も重たっるくはないけど、勢いがあって、楽しめます。
このボックスの録音時期は大部分が1990年代前半ですが、このCDとショパンとシューマンの組み合わせたCD と最後のライブ録音だけが、ちょっと時期が遅くなります。このCDは90年代後半から21世紀初めにずれ込んでいます。やっぱりベートーヴェン初期の曲だから、慎重になったという部分があるのですかね。
ピリシュとデュメイの演奏は曲の勢いが自然に表現されているので、楽しめます。1番、2番、4番、3番という順番で入っている一枚目がとてもいいです。しかし何故この順番なのだろうか。この順番だと、調性の並びが D major -> A major -> A minor -> E flat major となり、最後が短調で終わらないようにしたということですかね。

CD4 ブラームス：ヴァイオリン・ソナタ 全3曲


1992年。共演者はデュメイ。この演奏は初めて聴きました。25年以上前の演奏ですが、新鮮な感じがします。デュメイのヴァイオリンがとてもいいですね。この曲のベストスリーに入る演奏だと思います。まあ、僕のベストワンは高橋悠治+ズコフスキーの共演という人の判断なので、あてにはなりませんが(^^;;;。

CD5 ブラームス：ピアノ三重奏曲 第一番、第二番


1994年～1995年。白状すると、全曲聴くのは初めてです。こういうのが全集版の楽しみですね。3番が入っていないのは残念。時間がなかったのですかね。第2番ってこんな曲だったのですね。第2楽章が面白いです。

CD6 グリーグ：ヴァイオリン・ソナタ 全3曲


1993年。これも白状すると、初めて聴く曲ばかりです。
ピリシュってポルトガルの人なのですが、ヨーロッパの辺境(^^;;;出身という意識がどの位あったのですかね。同じ辺境どうし、グリーグの音楽に共感したのかなぁ。そういう雰囲気なのですが、真相はわかりませんです。これもデュメイのヴァイオリンの音色が曲にぴったりです。曲もいい曲ですね。辺境の音楽という感じが満載のところがいいです。

CD7 モーツァルト：ピアノ三重奏曲 第一番、第二番、第三番


1994年～1995年。何故、4番から6番は録音されなかったのか謎ですね。曲も四番以降の方が面白いと思うのですが、何故1番～3番で止めてしまったのでしょうか。

CD8 モーツァルト：ヴァイオリン・ソナタ ト長調K.301、ホ短調K.304、変ロ長調K.378、ト長調K.379


1990年～1991年。これは最初から選集でこの4曲に絞り込んだということですかね。演奏は文句無し、素晴らしいです。曲もモーツアルトのヴァイオリン・ソナタから4曲選ぶなら、僕も同じ選択をします。ピレシュさんと意見が一致したので、嬉しいです(^^)。

CD9 シューマン：ピアノ五重奏曲 変ホ長調 Op.44、ショパン：チェロ・ソナタ ト短調 Op.65


1999年(シューマン)、2008年(ショパン)収録。このCDだけジャケットに曲目の表示がなく変です。多分、それぞれの曲は別のソロの演奏とのカップリングで発売され、このボックスで初めて一緒に組み合わせたということだと思います。
シューマンの共演者はデュメイとジャン・ワン以外にルノー・カピュソン（ヴァイオリン）とジェラール・コセ（ヴィオラ）という豪華メンバー。この曲、僕のディフォルトはグールドとジュリアードの共演なのですが、まるで違う演奏でした。まあ、こっちの方が正統派なのでしょうね。悪くないです。
ショパンはあまりピンとこない曲なのでコメントは省略。共演者はパヴェル・ゴムツィアコフ（チェロ）です。

CD10 シューマン：3つのロマンス Op.94、アダージョとアレグロ 変イ長調 Op.70、幻想小曲集 Op.73、民謡風の5つの小品 Op.102～第2,3,4曲、子供のための4手用曲集 Op.85～夕べの歌（ヨアヒム編）


1992年。初めて聴く曲がほとんどですが、楽しめました。ボイドというオーボリストは初めて聴きましたが、素晴らしい演奏ですね。

CD11 フランク：ヴァイオリン・ソナタ イ長調、ドビュッシー：ヴァイオリン・ソナタ ト短調、ラヴェル：フォーレの名による子守歌、ラヴェル：ハバネラ形式の小品、ラヴェル：ツィガーヌ


1993年。今回の12枚の中でベストワン。デュメイとのアンサンブルが素晴らしいです。ピリシュのドビュッシーやラヴェルを初めて聴きました。いいですね。ソロの曲も捜して聴いてみるかなと思いました。

CD12 シューベルト：アルペジョーネ・ソナタ イ短調 D.821、ブラームス：3つの間奏曲 Op.117、メンデルスゾーン：無言歌 ニ長調 Op.109、ブラームス：チェロ・ソナタ第1番 ホ短調 Op.38、J.S.バッハ：パストラーレ ヘ長調 BWV.590


2012年1月にロンドンのウィグモア・ホールでのライヴ録音。ブラームスだけメネセスとの共演です。
他の11枚は1990年代前半の演奏なのに、これだけ比較的最近の2012年の録音、しかもライブ。メネセスとは日本にも来ているから、気が合って共演を続けたということなのでしょう。このシューベルトとブラームスの共演は貴重です。日本の生ではベートヴェンもやったみたいですが、今のところCD化されていませんね。NHKには録音(録画?)があるはずですが。残念。

(PC_Audio)   2018/12/29

コメントする

NewJPLAY騒動顛末(5)–License Expired の再逆襲


承前です。ゴーンさんではなく(^^;;;、TurboActivateゴジラさんの逆襲です。

メインシステムでのPrimeSeatのDSD再生確認は問題なく出来たのですが、事件はそのあと発生しました。
PrimeSeatは基本的には再生を開始する前に現在の回線速度で指定された速度のストリームを再生出来るかどうかチェックする仕組みになっています。例えば、僕の環境ではDSD 5.6は、通常、JPLAY経由で再生できませんので、「アンタの貧弱な回線環境じゃ、再生できないよ(もうちょっと上品なメッセージでしたが)」というエラーとなり、冷酷に現実を教えてくれるようになっています。
ところが、まれにギリギリで再生可能な回線状況にだと、「よっしゃ、やってみるか」という感じで再生しに行きます。これで、良好な回線状況が続けば、問題はないのですが、再生しようとすると、エラーになってしまうことがあります。この時、ちゃんと終了できればいいのですが、たまにハングすることがあります。こうなってしまうと、悲劇の始まりです。

PrimeSeatはよく出来たソフトだと思いますが、このハング状態をどうやっても解消できなくなるという問題点があります。
ハングそのものはよくある話なので、タスクマネジャを使って終了させればいいのですが、問題はその後。
PrimeSeatを再起動すると、またハングしてしまうのですよね。
何度やっても同じことの繰り返し。「ニッチモサッチモ、どうしようもない」状態となります。
再生しにいこうとしてエラーになり、ハングしているわけですから、この状態からの回避方法は、「DACを切り離す」です。ところが、何故かJPLAYと繋いでいる時はこの手が効かないのですよね。困ったものです。
仕方がないので、JPLAYをアンインストールすることにしました。PrimeSeatを再起動し、問題がクリアされたことを確認。JPLAYを再インストールしました。インストールは特にエラーは無く終了。Setting画面を表示しようと、JPLAYSettingを起動しました。

いよいよ License Expired の逆襲、第三幕。どういうわけか、こういうダイアローグが登場。



「ライセンスは無効です。エラーコードをヨーロッバに連絡て下さい」。ビックリ。エラーコードなんて無いし、「何だこのメッセージは」と思いながら、OKボタンを押したら、



という画面が出てきました。なるほど、エラーコードがありますね。今までのパターンとは違うようです。 多分、最初のメッセージは、インストール直後のライセンス確認のために、TurboActivate.exeが出しているもののようですね。OKを押すと、その情報がJPLAYSetting.exeに引き渡されて、画面に表示されるという仕組みのようです。
TurboActivateを起動したらどうなるのだろうと考え、動かしてみました。ごく普通に認証を促す画面が出で、認証できます。プログラムの名前の通り、アクティベーションするということになります。画面は前回の書き込みのものとまったくいっしょなので省略します。
この状態で認証は正しくされたが、実際に使おうとすると、エラーコード付きの認証エラーという悲惨な状態となり、何も出来なくなります。

何度か起動を繰り返してみましたが、同じ状況。当然、再生もできません。まあPremoSeatの確認はだいたい終わっていたので、バタバタしないことにして、日本のサポートにメールしました。
その後、PremoSeatで直結の確認など行ったあと、試しにと、もう一度 JPLAYSetting を起動してみました。

驚いたことに、「License Expired」ゴジラは消えていました。DACの選択など処理もちゃんとできます。自然復旧したみたいです。JPLAY 7.0、不思議なことは次々と起きますね。

とりあえず、「自然に直ってしまいました。不思議ですね。」というメールをサポートに送っておいて、理由を考えました。
しかし、何もしないで直ったのだから、何か思いつくわけがない。最初の警告メッセージの変化から考えてみました。
前二回はLicense Expiredだったけど、その後のメッセージは「試用期間3週間がたったので、購入するか、インタネットに繋いでre-activateしてくれ」というものだったのですが、今回は「ライセンスが無効になっているから、エラーコードをヨーロッパに連絡しろ」です。
ということは、今回のエラーは「 TurboActivate.exe がセンタに登録されているアクティベーション情報と立ち上げたハードの情報を比較し、異常を検出したので、それをエラーコードとして出力するので、ヨーロッパに伝えろ」と言ってきたと解釈できます。異常というのはハードの不一致位しか思いつきません。

では、どうしてハードの不一致になったか。思い当たるふしが一つだけあります。前回書いた内容で、デュアルモードにするとき、i3マシンのインタネット側回線のネットワークアダプタを変更したのですよね。多分、これがゴジラ来襲の原因かなと思いました。
しかし、何故、何もしないのに自然に直ったか。これは謎のままですね。まあ、「とりあえず、動くからいいや」ということで放置することにしました。再び、ゴジラは海に。

しかし、敵はそんなに甘くない。第四幕。「License Expired」ゴジラの再々来襲です(^^;;;。

その後、暫くして、パソコン部屋のオーディオ装置用にライセンスを追加購入。そちらで使っている i5-3470マシンにインストールしました。
問題なく、パソコン部屋のオーディオ装置もJPLAY 7.0で再生出来るようになりました。これで終われば、メデタシメデタシなのですが、「License Expired」ゴジラはひそかに逆襲のチャンスを狙っていたのですね。
このi5マシン、特に電源対策をしていないのですが、7.0で鳴らしてみて、案外音が良かったです。電源は「80PLUS認証 PLATINUM」という高効率タイプのものなので、結構、これでも使えるなと思いました。折角だから(?)、試しにと、i5マシンをオーディオ部屋に持ち込み、繋いでみました。これが、再々々来襲のきっかけなるとは夢にも思いませんでしたね。

システムを立ち上げ、SoulNote D-2用のドライバをインストール。正常終了。早速、JPLAYSettimgを立ち上げました。
またしても、「ライセンスは無効です。エラーコードをヨーロッバに連絡て下さい」が登場。これは駄目だなと覚悟。エラーコードを見るため、OKを押しました。「あれエラーコードが変わった。どうなっているのかな」という感想。
前回のトラブルで、「こういう場合はJPLAYのインストールをし直してくれ」という案内を受けていたので、やってみました。問題なくインストールは完了。

今回は自動的にアクティヴェートされるようになるということはなさそうなので、TurboActivateを起動してみました。
認証は通常の手順で完了。正常に完了しました。
次に、JPLAYSettingを起動。今回はノーエラーで上手く起動されました。
「うーむ、何がなんだか分からない」。まあ、問題はなく使えるようになったので、これでお終いということになりますが、釈然とはしませんね。

初回の登場、逆襲、再逆襲、再々逆襲と一月に4回の執拗さ。何でこうも連続するのか。ゴジラでもこんなに頻繁には襲来しません。
それで気がついたのが、第三幕以降はネットワークの構成が弄ったことが関連していそうなことです。この認証システムは有線ルータ、無線ルータ、スイッチなど複数のネットワーク機器が混在する環境に弱いのではないですかね。線を繋ぎ変えたり、パソコンを動かしたすると、いちころに、「License Expired」ゴジラが登場するという仕組みになっているようです。まあ、今のところはインストールし直せば、何とかゴジラ退治は出来るようなので、救われていますが。

問題はJPLAYのインストールをすると、伊福部さん作曲のゴジラのテーマと自衛隊のマーチが僕の頭で鳴り響くようになったことですね(^^;;;。



ところで、ここから先は、こういうゴジラとの付き合いを経て、サボートの方とやりとりした後日談です。

JPLAYのディレクトリ内にTurboActivateという名前のプログラムがあります。このプログラムはwyDayという米国 New Hampshire にあるベンチャ(でしょうね?)会社が開発、販売している認証システムの一部です。従って、JPLAY用に特別に開発されたものではありません。

wyDay社のサイトは、グーグルでTurboActivateというキーで検索すれば、一発で出てきます。
顧客には三菱自動車、富士フィルムなど日本の企業もあり、グローバルに展開している企業のようです。JPLAYはこの会社が開発した LimeLMというパッケージを組み込み、使っているようです。TurboActivateはエンドユーザ環境で動作するプログラムということになります。

なんだ、丸投げしているのかという反応があるかもしれませんが、これ(丸投げ)は当然でしょうね。MarcinさんやJosefさんのような才能は音楽再生に集中して貰って、ライセンス処理などという特殊な機能は専門の会社に任せるのが当たり前だと思います。

という訳なので、ライセンス認証に関するJPLAY関係者の立場はJPLAYに対する我々ユーザの立場を平行移動したものとなります。何を言っているかとというと、JPLAY関係者はライセンス認証システムに対して「中身はブラックボックス。サポートを受けながら対応するだけ」という立場に変わるというです。
これはサポートする方からするとかなり辛い立場ですね。自社製品のように中身が分かって答えることが出来ません。結局、対応できる範囲は限定され、割り切って、「所定のパターン」に合わせて対応することにしているようです。しかし、顧客からの無理難題(^^;;;をスイスイとかわすというわけにはいかず、イライラが募るということになるかもしれませんね。

この対応策として、wyDay社のサイトには、自社製品に関するフォーラム(掲示板)が公開されていて、ここには誰でも参加(質疑応答)すること出来るようです。
誰でも参加出来るわけだから、質問者は直接のユーザである必要は無いようです。エンドユーザ(JPLAYユーザもエンドユーザです)が、直接、「この出来の悪い認証システムは何だ。こういう具合に変えられないのか」と質問できるのかもしれません。腕と英語力に自信があれば、wyDay社のライセンス認証システムにご不満のある方は是非ご参加をということらしいです。
ちなみに、「Using TurboActivate with C, C++, and Objective-C」というページがwyDay社のサイトに公開されています。これを読むとTurboActivateの使い方の概要を知ることができます。ヘッダーファイルも見つけることが出来ました。フォーラムに参加して議論するには、このあたりの情報を理解していることは必要最低限でしょうね。

顧客が発注先に使っているソフトの苦情をいくらいっても無駄で、発注先が開発を丸投げしている二次外注会社と直接掛け合った方が話は早いというのはよくある話だから(カケ問題で首相官邸に愛媛県が説明に行った時、カケ関係者が同席していたのと同じことですね)、こういう仕組みになっているのですかね。なかなか面白いシステムですね。

さて、エンドユーザにとって、上記した対応の「所定のパターン」を知っておくことは有意義だと思いますので、サポートの方から教えていただいた内容をご紹介します。

その前に例によってちょっと脱線。エンドユーザに関するライセンス処理には(ライセンスの)アクティベーション機能とライセンス認証機能があることを説明します。以下の説明で、分かりやすくするため、図を使いますが、以前の書き込みで使ったものです。

アクティベーション機能とは、TurboActivateを実行した時に動く、ライセンスを有効にするための機能のことです。正しいライセンスキーが入力されたことを確認し、インストールされたソフトを認証サーバに登録OKかチェックし、OKなら、登録されます。
従って、アクティベーション機能が正常終了したかどうかはTurboActivateを実行した時の画面の推移で確認できます。
まずアクティベーションするかどうか確認する画面が表示され、



アクティベートキーを入力し



正常終了すれば、こんな画面が表示されます。



異常終了時の画面は例えばこんな具合になります。



次に、ライセンス認証機能とは、毎回システムを立ち上げた時に動く、ライセンスが正しく登録されているかどうかチェック(判定)するための機能です。「License Expired」ゴジラを登場させているのは、こちらの機能です。ゴジラを出しているのはJPLAYSettingの画面ですが、JPLAYSettingは通知された内容をそのまま出しているだけで、ライセンス認証機能とは関係ないはずです。従って、ライセンス認証機能もTurboActivateの機能で、JPLAY起動時に実行されるということになります(推定です)。

こちらはライセンス認証の判定結果が正常であれば、何も画面は表示されません。正常なJPLAYSettingの画面が表示されるということになります。
異常を検出した場合は、TurboActivateによってこんな画面が表示されます。



この書き込みの前半部分の License Expired の逆襲、第三幕に引用した画面もライセンス認証で異常を検出した時の画面となります。
さて、以上で前置きの脱線は終わりです。本題の「License Expired」ゴジラが登場した時の対応の「所定のパターン」のご紹介に入ります。

ここまで脱線して、アクティベーション機能とライセンス認証機能の違いを説明してきた理由はこの「所定のパターン」がどちらの機能でエラーになっているか知ることが肝要だからです。「現在の試用版では、設定手順を守っている限りLICENSE EXPIREDは出ません」ということなので、「所定のパターン」を理解して、サポートと掛け合うことが障害対応の基本となります。

アクティベーション機能で問題が発生している場合はやれることは限定されます。
「もう一度現時点での試用版をダウンロードしてインストール、それでも問題が解決しない場合はサポートへ問合せ」となります。
今、問題が発生していると書きましたが、これはアクティベーション機能が正常に終了しているようにみえる場合を含むからです。つまり、TurboActivateで「This PC was activated successfuly.」と出ているにもかかわらずJPLAYSettingsで「License Expired」ゴジラが登場する場合を含みます。

次に、ライセンス認証がエラーになった場合です。こちらはJPLAYSettingを立ち上げた時、ゴジラが登場しますからすぐ分かります。
この場合は日本語JPLAYサイトの問い合わせ事例の最初の方にある「JPLAY FEMTOのJPLAY SettingsでLICENCE EXPIRED(ライセンス失効)と表示される」の項目が該当しないかチェックします。
該当するようであれば、それを修正し、再確認します。
どれにも該当しないのにエラーになっている場合は「もう一度現時点で最新の試用版をダウンロードしてインストール、それでも問題が解決しない場合はサポートへ問合せ」となります。この場合エラーコードが出ているようであれば、後の問い合わせのために控えておいた方が賢明でしょう。エラーコードの説明はされないと思いますが。

後、アクティベーション機能はエラーになるが、「License Expired」ゴジラが登場しているというケースがあります。これは僕の第二幕の後半のケースといっしょですが、通常は試用期間中にライセンスなしで認証すると、そうなるのではないかと思います(不正なライセンスキーを使ったということになるので、未確認)。このケースはライセンスが有りなら、サポートに文句をいえばいいし、無しなら、PayPalに行きましょう。

フローチャートにするとこんな感じになります。



このフローチャートのポイントは「問い合わせ事例をチェック」→「思い当たるふしあり」→「②最新の試用版をダウンロード、JPLAYをインストール」→「ゴジラは出たかJPLAYSettingを起動」のループです。つまり、問い合わせ事例を全部チェックしないで、サポートに駆け込んでも、突き返される可能性があるということです。

日本サイトの「問い合わせ事例」は欧州サイトのMarcinさんの書き込みをベースにしたもののようですが、最後の2項目が省略されています。
日本のオーディオマニアはそんなところは弄らないだろうというで削除されたのでしょう。しかし、僕の環境ではVmwareを使っていたので、どちらも引っ掛かったのですが、ゴジラ映画の見過ぎですかね(^^;;;。参考までに英文を引用しておきます。

If hyper-v is enabled it will not activate. Disable it in Control Panel under "Turn Windows Features on or off". If Virtualization in BIOS is enabled, activation may fail too, so please check that too.

　

今回のゴジラ画面はエラーコード付きですが、このエラーコードでどの事例か切り分けているのだろうと思います。

システム設計の一般論でいうと、エラーコード(異常処理)の設計は、システム全体の整合性確保のために、非常に重要な検討事項のひとつで、システム開発の初期段階できっちりルール作りします。またそのルールはシステムの内容を暗示しますので、商用ソフトでは全てをオープンにすることはありません。
例えば、マイクロソフトのOS認証のエラーコードというものが公開されることはありません。同じように、 TurvoAcrivate & error codeで検索しても、エラーコード表が出てくるということはありません。従って、問い合わせ事例やフォーラムへの書き込みという形でこれだけの情報がインターネットに出てきたというのはかなり異例な事態ではないかと思います。
このあたりは、JPLAYユーザの体質が透けて見える部分だと思います。つまり、音質優先でギリギリなことをやっているので、どうしても、普通のユーザなら引っかからないエラーが表面化してしまいます。従って、公開して、注意喚起せざる得ないということだと思います。

上記したヘッダーファイルを眺めると(僕の場合、プログラムは読むでなく、眺めるです^^;;;)、Marcinさんのフォーラムへの書き込みに書かれているような事象に対応する関数の解説だらけです。ここまで、おおっぴらに情報が表に出ているわけだから、JPLAYのサイトであの程度露出しても、たいした問題ではないのかもしれませんね。

(PC_Audio)   2018/12/22

コメントする

NewJPLAY騒動顛末(4)–License Expired の逆襲とPrimeSeat


二回延ばしの「License Expired の逆襲」です。「帰って来たゴジラ」ですね(^^;;;。

シングル構成でのJPLAYの素晴らしさは十分分かったので、デュアル構成に挑戦することにしました。
デュアル構成の確認のため二台目のパソコン(asusマザーのi3-3225)をWin10をクリーンインストール。これで文句はなかろうと、JPLAY 7.0をインストール。問題なくインストールは完了。ところが、ここからが悪夢の再開でしたね。

セッティング画面を出して、音源の設定をしようとしたら、再び『ライセンスが消えた(期限切れ)。インタネットに繋ぐか、PCを再起動しろ』というメッセージ。その後、真っ赤な「License Expired」も再登場。トラブル発生です。
「あれ、変だなぁ」と思い、試しに認証プログラム(TurboActivate)を起動してみました。
ライセンス認証を促す画面が出力されます。



Activate JPLAYfemto Now をクリック。
ライセンスキーを入力する画面が表示されます。



入力して、OK。ところが、『The product key you typed is already in use』といういうエラーに。



何回やっても同じ結果。前回とはちょっと様子が違います。
しかし、駄目なものは駄目。何度か再インストールなど試してみましたが、事態は変わらず。
「ウーム。OSはクリーンインストールしているのに、今度は何だ。さっぱり分からん」という状態です。お手上げなので、サポートにメール連絡。その日は諦めて、オヤスミナサイ。

翌朝、サポートからメールにご返事がありました。「Biosを弄ってないか」とのご質問あり。大いに有りなのですが、問題はどこをどう弄ったか覚えていないこと(^^;;;。
内蔵音源のオフなど記憶にある部分は元に戻してみましたが、状況は変わらず。どうしようもないので、最後の手段、「Bios Defautの設定」をやってみました。結果は大成功。見事に真っ赤な「License Expired」は消え、設定も完了。音も出せるようになりました。
しかし、「何でBios情報なんかチェックしているのかいな」と思いましたが、考えてみると当たり前ですね。だって、ハードを特定するたには一番良い場所ですから。

それでは認証してみようかとTurboActivateを再び起動。ところが、敵はしぶとい。再び『The product key you typed is already in use』「既に2台登録されているからこれ以上は登録できない」というエラーになります。昨日と同じ結果。

ちゃんと使えるけど、認証エラーになる。「困ったものだ」という状態。
考えてみたら、これは既に2台分登録されていて、エラーメッセージ通り、認証エラーになっているように見えます。どうも最後にインストールしたSurfaceノートの認証情報がアンインストール後も残っているようです。
早速、サポートに「Bbios defaults状態で、JPLAYfemtoServer+NASを使った音楽の再生もできました。ちゃんと使えますが、認証してくれません」とメールしました。この状態、かなり変な状態のようで、サポートにも事態を理解して頂けない。
「ちゃんと動いているが、認証しようとすると、こういう画面が出て、認証できません」という内容を説明し、「こちらは1台分しかインストールしていないよ」ということも理解してもらいました。
何らかの複合トラブルが発生した時、ライセンスの二重登録は避けられないようですね。
あとは簡単。欧州側のサポートに連絡して頂き、ライセンスをクリア。対応は出来ました。対応時間も数時間と短かったです。
こうして、ゴジラ(^^;;;は再び海に帰っていきました。

気になるのは、何でアンインストールしたSurfaceノートの認証情報が残ったのかです。まあ、使い始めのトラブルでバタバタしていた状況なので、今となっては全ては忘却の彼方。これ以上の原因追求は不可能です。
あと、LAN情報で台数の管理を行っているようですが、これはマザーボードを交換した時、問題を起こさないのですかね。まあ、最悪、今回のように、サポートに連絡という手段は使えそうですが、あまりスマートではないですね。

デュアル構成は問題なく動きました。音は素晴らしいと思いますが、シングル構成が良くなりすぎているから、シングル構成との差は少なくなったような気がしますね。
ここまでが逆襲の一回目です。ここから二回目の逆襲、つまり再逆襲。ゴジラ(^^;;;並の執念ですね。

本題に入る前に、いつもの通り、脱線します。
JPLAY日本語掲示板に管理人さんから「JPLAYfemtoを使ってPrimeSeatをストリーム再生できますよ」という案内がありました。「PrimeSeatってレコード芸術に書いてあったベルリンフィルのライブをストリーム再生するサイトだよな」と思い出し、早速、試してみました。
サイトのトップ画面です。ここからストリーム再生用のソフトをダウンロードします。



ソフトはKorg製ですね。従って、推奨ハードのトップがKORG DS-DAC-10Rです。
これがダウンロードしたソフトの初画面です。ストリームミングするサイトの運営はIHIが行っているようですね。画面左上にオーディオ環境を設定するための設定ボタンがあります(カーソルが表示されているところ)。そこをクリック。



こんな画面になりますので、画面左上(カーソルが表示されていますね)のオーディオ設定をクリック。



設定用のダイアログ画面が表示されますのでここでオーディオインターフェースを選択します。この時、asioを選べば、JPLAYもドライバとして選択リストに表示されます。



これはベルリンフィルライブの抜粋サンプルを聴けるページです。只今、ユジャ・ワンのバルトークピアノ協奏曲2番の抜粋があります。



フリーで聴ける配信番組は

  • ベルリン・フィルハーモニー管弦楽団 ＜2018/19年シーズン＞ ライブ・ストリーミング配信
  • TheGLEE Live 東京・神楽坂のライブホール「TheGLEE」
  • 第5回 ヴィルタス・クヮルテット ベートーヴェン・ツィクルス
  • マレック・シュパキエヴィッチ チェロ・リサイタル
  • 間宮慎太郎「No East,No West」＜ハイレゾ試聴＞
  • dream window inc ハイレゾ・アルバムシリーズ
  • 2018年6月感動のライブ！ ラトル＆ベルリン・フィルによる「マーラー交響曲第6番」
  • 藝大ミュージックアーカイブ オーケストラ・室内楽・ピアノ・オルガン・吹奏楽・声楽・古楽・邦楽など、多彩なプログラム
  • 国立音楽大学オーケストラ
  • 東京音楽大学シンフォニーオーケストラ
  • OTTAVA Aria, Salone and more

というところです。藝大ミュージックアーカイブなど、抜粋ではなく、全曲聴けて、選曲も、結構、面白いものがあります。
それで、これが今週行われたベルリンフィルライブの聴き逃し配信。ゲルギエフの「火の鳥」をやっていました。配信はDSDがメインです。DSDの音は好みもあると思いますが、ライブ配信ということでの選択でしょうね。DSD 5.6Mで再生中です。



再生に必要な環境ですが、結構シビアです。以下サイトからの引用です。

Windowsを利用する場合

OS
・Microsoft Windows 7 Service Pack 1(32bit/64bit)
・Microsoft Windows 8.1 Update(32bit/64bit)
・Microsoft Windows 10(32bit/64bit)
CPU Core 2 Duo 2.66GHz以上推奨。
RAM 2GB以上。

オーディオ
・デバイス WASAPIまたはASIOに対応したオーディオ・デバイス
※DSDネイティブ再生には、ASIO DSDモードに対応したオーディオ・デバイスが必要です。

ネットワーク
・12Mbps以上の安定した通信速度でインターネット接続が可能なこと。
・有線LAN接続を推奨。

僕の環境ですがCPU、オーディオは条件をクリアしているのですが、ネットワークは12MBPSなので、ギリギリの状況ですね。

僕の環境は
直結用 : Surfaceノート OS Win10pro 64Bit、CPU i7-5500u、メモリ 8GB
JPLAY接続用 : 音楽専用PC(コントロール用) OS Win10pro 64Bit、CPU i3-3225、メモリ 16GB
以下は直結、JPLAY接続で共通。
オーディオ KORG DS-DAC-10R これは推奨機器でしたね。
ネットワーク 12Mbps、ノートの無線LANで接続、IEEE802.11a
というところなので、ハード、オーディオはクリア。ネットワークはギリギリクリアです。
という訳で、実際に再生出来た状況は環境通りですね。表にしてみます。

　　　JPLAYで再生直結で再生
PCM192KHz×△
PCM96KHz△○
PCM48KHz○○
DSD11.2M××
DSD5.6M×△
DSD2.8M△○

○が問題なく再生できる。△が環境条件による。×が再生できない。

JPLAYを使うと、ドライバとして二段構成になるので、確実に再生できるのは PCM 48KHzだけです。
JPLAYを使うにはネットワーク環境を最低限でも20Mbps以上にする必要がありそうです。

直結では、PCM 96KHz、DSD 5.6Mまでは再生可能になります。DSD 11.2M はたまにコンディションの良い時、再生できることはありますが、通常は厳しいです。
僕の貧弱なネットワーク環境でも、こっちは一応使えるというレベルですね。

音はJPLAYを使った場合と使わない場合で大差はないです。「ぼーっと」聴いている分には同じですね。
というけで、JPLAYをインストールしていない普段常用しているSurfaceノートにPrimeSeatを入れて聴くことにしました。KORG DS-DAC-10RもLPレコードの録音用に使っているものなので、もともとこのノートPCに繋がっています。

さて、このPrimeSeatの動作確認はパソコン部屋にあるサブシステムを使って確認していました。しかし、メインシステムでのDSDライブの音がどんなものか試したく、上記のデュアル構成の確認で使ったコントロールPC用のi3マシンとSoulNote D-2で聴いてみました。
これが、License Expiredゴジラの再逆襲を招くと、夢にも思いませんでしたね(^^;;;。

長くなったので、またまた次回に続くです。ゴジラの逆襲はいつまで続くか。お楽しみに。

(PC_Audio)   2018/12/15

コメントする

NewJPLAY騒動顛末(3)–JPLAYfemtoServerのNAS接続


「License Expired の逆襲」というトラブルをご紹介するつもりですが、例によって、その前に脱線します。
JPLAYfemtoServer でのNAS接続について。これは、結構、ハードルが高いようですね。吉田苑さんのブログ「大後悔日誌」には

JPLAYの日本サイトに解決方法が掲載されているが、相当努力しても出来なかった。今のJPLAY7.0を使った場合、標準的なPC知識では、NASから音を出す事は難しいと思う。結局、NASを使用しないという解決方法が最も確実で、精神衛生上好ましい選択だろうと思う。

という主旨の記述があります。
JPLAYの日本サイトの解決方法というのは femtoServerのアカウントをadministrator資格をもつユーザに登録変更するという方法なのですが、解説の仕方がシンプルな記述なので、確かに「標準的なPC知識ではNASから音を出す事は難しい」かもしれません。
しかし、ここであっさり諦めしまうのは、JPLAYfemtoServerのNAS接続での音の良さを知ると、オーディオマニアとしてはもったいないですね。

JPLAYの英語版マニュアルには「Using JPLAY femtoServer with a NAS」という項があり、ここで JPLAYfemtoServerのNAS接続の解説がされています。この方法はMarcinさんも「It is the only method that is proven to work regardless of OS」と認めているので、トライしてみる値打ちはあると思います。
日本語サイトの方法と比較すると、英文マニュアルにある方法はJPLAYfemtoの動作モードを変えていないので安心して使うことができます。
前々回の引用を再掲しますが、この対応方法の主旨は

Because JPLAY FEMTO service runs under SYSTEM account, it is required to map a network drive using SYSTEM account. This procedure is needed only for JPLAY femtoServer in combination with a NAS. You can skip this step if you want to use MinimServer on a NAS together with JPLAY FEMTO UPnP Renderer.

です。「JPLAYfemtoサービスはシステムアカウトで動いているので、システムアカウントでネットワークドライブを使えるようにするマップが必要となる」ということです。
これは、マイクロソフトのサイトから PsExec64.exe というユーティリティをダウンロードし

c:\PsExec64.exe -s net use Z: \\fileserver\music /u:username password

という形で実行すればいいだけのことなので、コマンドを実行するだけですから、そんなに難しい話ではありません。
問題はその後の立ち上げ時に自動起動させる部分で、マニュアルの記述だけでは、出来ないという点です。僕はタスクスケジューラを使って登録しました。

これら方法について JPLAY と関連させて、解説しているサイトがないようなので、ご紹介します。

コマンドの内容について簡単に補足しておきます。
PsExec64.exe というユーティリティはネットワークで繋がっているパソコンでcmdを簡単に実行するためのものです。telnetやsshをいちいち立ち上げずに、簡単に実行できるのが特長です。
JPLAY NAS接続では、このユーティリティを「-s」というオプションを指定して使い、「Run the remote process in the System account、リモートプロセスをシステムアカウントで実行する」という使い方をしています。リモート接続ではなく、自分自身ののためにシステムアカウントを設定しているというところがユニークですね。ただちょっと一般的な使い方ではないので、面食らうということになります。

英文マニュアルの記述は4項目からなります。これに対応する形で解説します。

PsExecをダウンロードし、Cドライブのルートディレクトリに解凍する

これは解説不要でしょう。
リンク先はここですが、IT開発者のためにマイクロソフトが用意したサイトで、開発用のユーティリティが紹介されています。
PsExecには32ビット版と64ビット版がありますが、JPLAYは64ビット専用ですので、PsExec64を使います。
Cドライブのルートディレクトリに置くというのはちょっと乱暴だと思いますが、音楽専用であれば、問題はないということなのでしょう。

マップを作成するためのAutostart_MapDrive.batのCドライブのルートディレクトリに作成する

この項も適切に解説されていますので、追加の説明は不要でしょう。
バッチファイルの作成には、Windowsをインストールしただけの状態であれば、メモ帳を使えばいいです。
解説では代表的なNASのQNAPの例をあげています。

c:\PsExec64.exe -s net use Z: \\QNAP\music /u:admin admin 
pause

バッチスクリプトにするのであれば、二行目の「puase」文を補った方がいいです。
これで右クリックで管理者として実行を選択実行させる時、正常に終わったかどうか確認することができるようになります。
QNAPというのがホスト名ですね。ホスト名がどう設定されているかはお使いのNAS次第です。NASのマニュアルを読みましょう。ログイン名とパスワードについても同じですね。
ホスト名が設定されていないorどうやってわからないということであれば、IPアドレスを使うこともできます

c:\PsExec64.exe -s net use Z: \\192.168.2.32\music /u:admin admin
pause

但し、DHCPを使っている時はこの値は変動する可能性がありますので、要注意です。

作成したAutostart_MapDrive.batをシステム立ち上げ時に自動的に起動されるようにする

ここからが難所となります。難所に入る前にひとつ書いておくと直前の項のバッチスクリプトが完成していれば、それを実行することで、femtoServerにNASを認識させることは出来ます。従って、デスクトップにスクリプト実行用ショートカットを作っておけば、ショトカットのダブルクリックでNASを使えるようになります。難所を避けて楽をするなら、この方法もあります。

英文マニュアルのこの項の説明は

Place the Autostart_MapDrive.bat script in the startup (autostart) folder under Administrator user.
The startup folder in Windows 10/8 is located at:
C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
To directly access this folder, open Run, type shell:startup and hit Enter.

となっていますが、これはAdministrator環境であれば、その通りやればよいという内容で、一般的にはこの通りは出来ません。この記述で参考になるのはバッチスクリプトの実行はAdministrator資格で行う必要があるという部分だけです。その他の部分は無視し、タスクスケジューラーで起動する方法をとります。

以下、タスクスケジューラーを使い、Autostart_MapDrive.batをシステム起動時に自動実行する方法を説明します。参考にしたサイトはこちら(タスクスケジューラの基本的な使い方)です。

コントロールパネルから起動します。パネルの画面左上「表示方法」を「カテゴリ」にしておきます。

コントロールパネル=>システムとセキュリティ

を選びます。こんな画面が出てきます。



画面下の方にある、管理ツールをクリック。



画面真ん中あたりのタスクスケジューラをクリック。これでタスクスケジューラーが起動されました。
起動すると初期画面が表示されます。



画面左側のペインで「タスクスケジュールライブラリ」を選び、右側操作のペインで「基本タスクの生成」を選びます。以下ウィザード形式で案内画面が順次表示されるので、答える形でAutostart_MapDrive.batをシステム起動時に自動実行するスケジュールを作成します。



名前を入力します。Autostart_MapDriveでいいでしょう。「次へ」をクリック。



タスクトリガーを指定します。「コンピュータの起動時」です。「次へ」をクリック。



操作です。「プログラムの開始」です。「次へ」をクリック。



最後に指定した内容の確認が求められますので「完了」をクリック。



もとのタスクスケジューラの画面に戻りますが、中央のペインに今作成したスケジュールが登録されています。



もう少し設定の変更が必要ですので、編集するため、作成したスケジュールをダブルクリックします。



「ユーザのログインしているかどうかにかかわらず実行する」、「最上位の特権で実行する」、「構成 : Windpws10」に変更します。以上はAutostart_MapDrive.batを正しく実行させるのに非常に重要です。 次に、「設定」のタブを選択します。 「タスクを停止するまでの時間」は指定不要ですので、クリックを外します。



最後に「OK」ボタンを押します。 ログインしたユーザ名のパスワードを聞いてきますので、正しく入力しましょう。



やっていることは単純なのですが、GUIで説明すると長くなりますね。これでお終いです。

再起動と起動後の動作確認

特にマニュアルの内容に追加で説明することはありません。

Z:ドライブが赤のバッテン表示される件は、この方式の提案者のFujakさんが、「ADMINISTRATORでなく、SYSTEMユーザ(アカウント)で mapped/mounted されているからだろう」という推測をしています。以下、引用します。

Z:\ is mapped/mounted under SYSTEM and not under ADMINISTRATOR. So you could open the Z:\ only if you are logged in as SYSTEM (which is normally impossible). But regularly you are logged in as ADMINISTRATOR. So you have no permissions to access Z:\ although it is shown in Explorer. If you see the Z:\ with red sign, you can be shure it is mounted/mapped under SYSTEM correctly - and of course you will see the respective folders of your libraries in your controlpoint (e.g. BubbleUPnP).

Windpws10の場合、バッテン表示のZを開くことが出来ないという点が僕の環境とは違いますが、推測は当たっていると思います。


さて、ようやく本題に入ります。「License Expired の逆襲」と書きましたが、随分長くなったのと、きりがいいので、後は次回に。

(PC_Audio)   2018/12/08

コメントする

水着姿でベルリン・リサイタル


そそっかしいものだから、タイトル通り勘違い。CDを手にとって、よく見たら水着姿のように見える演奏会用ドレス(?)なのですね。この人(ユジャ・ワン)、服装の趣味が過激なのはよく良く知っていましたが、まさか水着で演奏するわけは無いだろうと判断するべきでした(^^;;;。



これが後ろ姿と演奏曲目。曲目も相当に過激です。



  • ラフマニノフのエチュードとプレリュード
  • スクリュアビンのピアノソナタ10番
  • リゲティのエチュード3番、9番、1番
  • プロコフィエフのピアノソナタ8番

ドレスといっしょ。凄い組み合わせでしょ。リゲティ以外はあまりよく知らない曲ばかりだったのですが、ジャケットと曲目選択の凄さに圧倒され、getしました。
しかし、不思議なのはジャケット内側の写真です。こんな感じです。



一体、演奏会はどちらの服装で演奏したのですかね。CDのクレジットは2018年6月1日のライブレコーディングとあるだけで、服装がどうだったかの解説がないのですよね。まあ、当たり前だけど。
もう一枚、CD解説のブックレットにはこんな写真が。



これも演奏中ですから、前半と後半でお色直しをしたということだろうか。だとすると、CDの曲の順番は演奏会と順番と同じとして、どっちが水着ドレスでどっちが黄色いドレスだったのだろうか。どんどん謎は深まるばかり。どうだったのかによって、演奏の印象も大きく変わるだろうから(^^;;;、そのあたりちゃんと解説してもらいたいものです。

このCD、レコード芸術の今月号でも取り扱われているのですが、演奏会のドレスがどうだったのかに関しての記述はありません。聴けば分かる、テンボがどうの、フレージングがどうだのというどうでもよい情報はいいから、肝心のドレスの情報を調べて、書くのがジャーナリストというものではないだろうか。困ったものです。

そうか。音楽評論家はジャーナリストじゃないのですね。

一応付け加えておくと、演奏はアルゲリッチも真っ青というレベルの凄さ。リゲティの難曲がまるでチェルニーの練習曲のように軽々と演奏されているのは痛快です。


p.s. いっしょに購入したCDリストです。

  • 高橋悠治の「余韻と手移り」
  • ルクレンツィス マーラー交響曲第6番
  • ピレシュ 室内楽演奏全集(エラート) 12枚組 このCDボックスは選曲がいいですよ。ベートーヴェンVnソナタ全曲、ブラームスVnソナタ全曲、Pnトリオ、グリークVnソナタ全曲、モーツアルトVnソナタ曲集、Pnトリオ、シューマンPn四重奏、ショパンVcソナタ、シューマンOb曲集、フランクVnソナタ、ドビュッシーVnソナタ、ラベルVn曲集などという内容。古典派、ロマン派、近代のPn/Vn/Vcを組み合わせた傑作をまとめて聴けます。まっとうな(?)のクラシックファンにはユジャ・ワンよりこちらの方がお勧めかも。

上の二つは新譜が出れば、無条件にgetすることにしている演奏家のCDです。
我ながら支離滅裂なCD選びだなぁと深く反省(^^;;;。

(music)   2018/12/02

コメントする

top page     previous page     next page

mail