目次: Arduino
M5Stamp C3で遊んでいるとプログラムが妙に遅くなることがあって気になります。AD端子が関わっているようです。原因を調べてメモしておきます。
まず全力を見るためdigitalWrite()でGPIO出力のHIGH <-> LOWを往復させるだけのスケッチ(Arduinoはボードで動かすプログラムのことをスケッチと呼ぶ)を作成し、出力がHIGH区間の幅(=ループ1回の処理に掛かる時間)をオシロスコープで計測したところ約7.6usでした。
M5Stamp C3のピン配置図(M5Stack社のサイトから転載)
M5Stamp C3のピン配置図を見るとA/D変換に対応した端子は0, 1, 4, 5の4つです。先ほどのスケッチにA/D変換対応端子の読み出し(=処理が遅くなる容疑者)を順に追加して、同様にループ1回の処理に掛かる時間を計測します。
どういう訳かanalogRead(5)だけが異常に遅く、読み出し値も常に0で正常動作していないように見えます。とりあえずこの端子は使わないことにしましょうか……。
もうひとつのA/D変換対応端子の読み出しAPIであるanalogReadMilliVolts()の時間も計測しましょう。読みだした値をmV単位に換算する処理が必要なので、処理時間はanalogRead() < analogReadMilliVolts()になるはずです。
割り算が要るのでそこそこ重い処理だと思いますが、16us(160MHz換算で2560クロック)も掛かるんですね。迂闊に連打しない方が良さそうです。
目次: 自宅サーバー
Gmailのメール受信ポリシーが2024年の2月で変更されるというニュース(Gmailユーザへメールが届かなくなる?Googleが発表した「新しいメール送信者のガイドライン」とDMARC対応を解説! - NRIセキュア ブログ)を思い出しました。
自分のドメインからGmailにメールを送ることはほとんどないですが、全く送れないのも困りそうです。試しにGmailに自分のドメインのメールアドレスからメールを送ったところエラーが返ってきました。もうポリシーが変更されているのでしょうか?
とりあえずDNSの設定を変更してSPF(RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1)レコードを追加します。送信元がメールサーバーのIPと一致しなければ、全部受信拒否してOKという強気の設定にしました(バリュードメインの設定パネル用の書式で書いています)。
txt @ v=spf1 ip4:219.94.129.142 -all
設定後しばらく待って(少なくともDNSのTTLに指定した秒数以上)からGmailにメールを送ったところ正しく届いていました。良かった良かった。
SPFレコードの設定を解説してくれているブログ(送信ドメインを認証するためのSPFレコードに詳しくなろう - SendGridブログ)が参考になりました。
活きた設定例を見たいときはプロバイダ各社のSPFレコードを見ると良いと思います。SPFはTXTレコードの一種なので、TXTレコードをDNSに問い合わせます。
$ dig wakwak.com TXT (略) ;; QUESTION SECTION: ;wakwak.com. IN TXT ;; ANSWER SECTION: wakwak.com. 86400 IN TXT "v=spf1 ip4:211.9.226.0/25 ip4:211.9.226.128/26 ip4:211.9.227.0/25 ip4:211.9.227.160/27 ip4:211.9.230.0/23 ip4:211.132.128.0/23 ip4:211.132.130.160/28 ip4:211.132.130.132/31 ip4:211.132.130.208/31 ip4:219.103.130.0/24 ip4:219.103.131.128/26 ~all" ;; AUTHORITY SECTION: wakwak.com. 73658 IN NS ns2.wakwak.com. wakwak.com. 73658 IN NS ns1.wakwak.com. ;; ADDITIONAL SECTION: ns1.wakwak.com. 37518 IN A 211.9.226.37 ns2.wakwak.com. 37518 IN A 211.9.226.101
理由はわからないですが、プロバイダのSPFレコードを見るとディレクティブ(レコードの最後の部分)に~allを使っていることが多いです。
今回はkatsuster.netのSPFレコードのディレクティブを-all(ルールに合致しなければ全部受信拒否)にしましたが、世の中のプロバイダ同様に~all(ルールに合致しなくても受信拒否しない)でも良いのかもしれません。
USB Type-Cの充電器を3つほど購入しましたので、メモを残しておきます。
Anker Nano IIはLenovo ThinkPad E480のACアダプターを置き換えるために買いました。ThinkPad E480付属のACアダプタはやや大きいため、Nano IIのようなコンパクトな充電器はありがたいです。
Anker PowerPort IIIはスマホやタブレットの充電に長らく使ってきたAUKEY PA-Y12(72W Charging Station、USBポート: Cx1 + Ax2)の置き換えです。出力は負けますがコンパクトでありがたい限りです。時代の進化を感じます。
AUKEY Charging Stationに比べると、Anker PowerPort IIIはType-Aポートが-1でType-Cポートが+1です。以前ならType-Aポートが多い方が嬉しかったのですが、最近は我が家もType-Cでの充電に対応した機器が多くなって、AでもCでもどっちでも問題なくなりました。
ELECOMキューブ充電器は旅行で持っていく用に買いました。3ポートあるのにコンパクトでとても良いです。
ただ1点気になるのは、Type-CポートとType-Aポートの抜き差しを繰り返すとまれに充電制御がおかしくなる?現象です。Type-CポートのUSB-PD出力が5Vに張り付いてしまい、他のポートを空けても戻らなくなることがありました。コンセントから外して再度電源を投入すると直ります。何か条件があるのかな?
最近、家で使っているWindows 10 22H2にてWindows UpdateのKB5034441という更新のインストールにずっと失敗していて、毎回0x80070643というエラーが出ます。しばらく無視していましたが鬱陶しいので対策することにしました。
MicrosoftのサイトにあるKB5028997(KB5028997: WinRE更新プログラムをインストールするためにパーティションのサイズを手動で変更する手順)によると、回復パーティションのサイズを250MB増やしなさいとのこと。
やたら手順が多く面倒なので、より簡単そうなKB5034957(KB5034957: CVE-2024-20666 のセキュリティの脆弱性に対処するために、展開されたデバイスの WinRE パーティションを更新する)を試しました。
KB5034957の説明によれば、
だけで良いはずです。
(※)カタログ(Microsoft Updateカタログ)から2024-01 Dynamic Update for Windows 10 Version 22H2 for x64-based Systems (KB5034232)を探します。
やってみると下記のエラーで怒られますので、設定を変えなければいけないようです。
PS C:\users\katsuhiro\desktop> .\PatchWinREScript_2004plus.ps1 .\PatchWinREScript_2004plus.ps1 : このシステムではスクリプトの実行が無効になっているため、ファイル C:\users\katsuhiro\d esktop\PatchWinREScript_2004plus.ps1 を読み込むことができません。詳細については、「about_Execution_Policies」(https://g o.microsoft.com/fwlink/?LinkID=135170) を参照してください。 発生場所 行:1 文字:1 + .\PatchWinREScript_2004plus.ps1 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : セキュリティ エラー: (: ) []、PSSecurityException + FullyQualifiedErrorId : UnauthorizedAccess
エラーメッセージが示すリンク先(実行ポリシーについて - PowerShell | Microsoft Learn)を見ると、この問題を解決するには管理者権限で実行したPowerShellにて、Set-ExecutionPolicyで設定を変えなされとのこと。なるほど……?とりあえず現在の設定のRestrictedより制限を1つ緩めたRemoteSignedにしました。
PS C:\users\katsuhiro\desktop> Set-ExecutionPolicy RemoteSigned 実行ポリシーの変更 実行ポリシーは、信頼されていないスクリプトからの保護に役立ちます。実行ポリシーを変更すると、about_Execution_Policies のヘルプ トピック (https://go.microsoft.com/fwlink/?LinkID=135170) で説明されているセキュリティ上の危険にさらされる可能性があります。実行ポリシーを変更しますか? [Y] はい(Y) [A] すべて続行(A) [N] いいえ(N) [L] すべて無視(L) [S] 中断(S) [?] ヘルプ (既定値は "N"): y PS C:\users\katsuhiro\desktop> Get-ExecutionPolicy RemoteSigned
スクリプトを実行すると色々ログが出たあとに、Delete mount direcotryと出ました。成功したのかな?ちなみにもう1回実行しようとすると、前にもやっただろ?と言われて動作しません。良くできておりますね。
PS C:\users\katsuhiro\desktop> .\PatchWinREScript_2004plus.ps1 コマンド パイプライン位置 1 のコマンドレット PatchWinREScript_2004plus.ps1 次のパラメーターに値を指定してください: (ヘルプを表示するには、「!?」と入力してください。) packagePath: windows10.0-kb5034232-x86_3f9ddcafa903e4dd499193a851ecacbe79d842b3.cab 01/25/2024 03:36:11 - This script was previously run successfully
これで万事解決と言いたいところですが、更新KB5034441のインストールは未だに成功しません。ええー、だめじゃん……!
同じエラーが出ているということは、まだ回復パーティションのサイズが足りないのでしょうか?とはいえ先程使ったPowerShellスクリプトをもう1回実行しても、2回目は何もしません。
スクリプト改造するのもダルいので、観念して手動で回復パーティションのサイズを拡大したところ、あっさりWindows Updateが成功しました。パーティションサイズの拡大の手順は、先ほども挙げたKB5028997(KB5028997: WinRE更新プログラムをインストールするためにパーティションのサイズを手動で変更する手順)の通りです。
Windows Updateが変なエラーで止まらなくなって、嬉しいは嬉しいですけど、回復パーティションはサイズが増え803MBになってしまいました。1GB近くも何を保存しているんでしょうね??
目次: Arduino
PCとM5Stack/M5StampをBluetooth LEで接続したいと思って、Bluetoothドングルを購入しました。さほど高価ではない&Linuxで動かないドングルがあるかも?と予想して、異なる商品を3つ買いました。Buffalo BSBT5D200(Bluetooth 5.0 + EDR/LE)、Buffalo BSBT4D200(Bluetooth 4.0 + EDR/LE)、Princeton PTM-UBT7X(Bluetooth 4.0 + EDR/LE)です。
一番新しいカーネルが動いているDebian Testing(Linux 6.5.13とBlueZ 5.71)のマシンで試してみましょう。
$ uname -a Linux blackbird 6.5.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29) x86_64 GNU/Linux # bluetoothd --version 5.71
購入した3つのドングルそれぞれで、Bluetooth LEデバイスのスキャン(hcitool lescan)と、LEデバイス情報の取得(hcitool leinfo)を行ったところ、Bluetooth 5.0対応の一番新しいと思われるBSBT5D200だけ動きがおかしいです。悪い予想が当たってしまいました。
# hcitool -i hci0 leinfo (MACアドレス) Requesting information ... Could not create connection: Input/output error
BSBT5D200だけhcitool lescanが凄まじく遅いし、hcitool leinfo (MACアドレス)を実行するとI/Oエラーになります。あらら……。
幸いなことにBSBT4D200とPTM-UBT7Xは正しく動くので、しばらくこちらを使います。
目次: 自宅サーバー
Gmailのメール受信ポリシーが2024年の2月で変更されるというニュース(Gmailユーザへメールが届かなくなる?Googleが発表した「新しいメール送信者のガイドライン」とDMARC対応を解説! - NRIセキュア ブログ)の対応の続きです。
Gmailに大量にメールを送る人(5000通over)でなければSPFだけでも良いらしいです。が、さくらインターネットがDKIMに対応してくれました(DKIM署名、DMARCを設定したい - さくらのサポート情報)し、せっかくなので使ってみます。
DKIM(RFC 5672, RFC 4871, DomainKeys Identified Mail (DKIM) Signatures)はSPFとは異なりメールサーバーの設定が必須です。仕組みとしては、
こんな感じみたいです。間違ってたらごめんなさい。メールサーバーの設定はさくらインターネットの説明通りに設定すれば良いです。ログインしてコントロールパネルからDKIM署名を有効にし、秘密鍵を作成するボタンを押します。簡単でありがたいです。
DNSサーバーのTXTレコードにDKIM Keyレコードを追加します(バリュードメインの設定パネル用の書式で書いています)。"p="タグの値には公開鍵を書きますが、長いので省略します。
txt rs20240131._domainkey.katsuster.net v=DKIM1; k=rsa; p=(略)
先頭にあるrs20240131という謎の文字列はセレクタというそうです。RFCだと場所とか時間とか個人を表すものにする例が書かれています。さくらインターネットの場合はDKIM鍵を作成した日になるみたいですね。
DKIMセレクタの確認(さくらインターネットのコントロールパネル)
セレクタ文字列自体にあまり意味はなくて、メールサーバーがメールヘッダに追加するDKIM-Signatureの"s="タグの値と一致していることが重要です。
最後にDMARC(RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC))レコードを設定します。
txt _dmarc.katsuster.net v=DMARC1; p=quarantine; aspf=r; adkim=r; rua=mailto:(略)
DMARCはメールの送信元の改ざんや詐称を防ぐ仕組みですが、DMARC自体が何かする訳ではなく実際にはSPFとDKIMの合わせ技です。DMARCはポリシー適用の厳密さだったり、違反していたらどうしたら良いか?だったりを宣言しています。なのでSPFレコードとDKIMレコードが正しく設定できている必要があります。
DMARCの設定をしたらGmailにメールを送り、メールヘッダを確認します。
Authentication-Results: mx.google.com; dkim=pass header.i=@katsuster.net header.s=rs20240131 header.b=uzgJOfTY; spf=pass (google.com: domain of (略) designates 219.94.129.142 as permitted sender) smtp.mailfrom=(略); dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=katsuster.net
SPF, DKIM, DMARCともに無事passしました。しばらくこれで運用したいと思います。
目次: 自宅サーバー
今更感がありますが、このサイトもSSL対応にしました。ブラウザに「安全ではない接続です!」と怒られなくなりました。まあ、それだけですね……。
SSL証明書は年990円のJPRSドメイン認証型SSLにしました。とてもお安いです。購入も簡単で、さくらインターネットからボタン1つで買えました。買った後にLet's Encryptを使えばタダだったのでは?と気づきましたけど、気にしないことにします。
サーバー側の設定以外に日記システム側も改修が必要です。一部のリンクや画像のURL出力などでhttpに決め打ちしていた部分があって、http経由/https経由でアクセスするファイルが混在していました。ブラウザはこのようなサイトを表示させると「完全に安全ではない!」と警告してくれます。良く見てます。ありがたい。
さらに面倒なことに自宅に置いているミラーサーバーはSSL非対応なので、手あたり次第httpを全部httpsに置換するとミラーサーバーの表示が崩壊してしまいます。サイトごとにhttp経由/https経由を設定できるように変更しましょう。
PCやデジタル音楽プレーヤーで音楽を聞いていると、曲によって音量の大小が激しく違っていて鬱陶しいです。片や何も聞こえず、片やリスナーの耳を壊す勢いの爆音で同じ音量で聞き続けるのが困難です。
人が感じる音の大きさをラウドネス(Loudness)と呼びますけども、全ての曲のラウドネスを一定レベルに修正すれば、極端な沈黙や爆音を避け同じくらいの音量で楽しめるはずです。ラウドネスの修正を行うツールはffmpeg-normalizeが簡単でわかりやすかったです。Pythonで実装されていて内部ではffmpegのloudnormフィルターを使っているそうです。
インストール方法はpipを実行するだけで簡単です。ローカルのPython環境に影響が及ぶのが嫌な方はvenv(venv - 仮想環境の作成 - Python 3.12 ドキュメント)を作成し、仮想環境にインストールすると良いです。
$ python3 -m venv ./venv $ source ./venv/bin/activate $ pip install ffmpeg-normalize
基本的な使い方はffmpeg-normalize (入力ファイル名) -o (出力ファイル名)ですが、デフォルトパラメータがターゲットレベル-23LUFS、サンプリングレート192kHz、Matroska(拡張子.mkv)形式となっています。サンプリングレートとかは好み次第ですけど、ターゲットレベル-23LUFSはすっっっごい音が小さいです……。最初試したときに、音が消えてしまうぞ?おかしいなあ??と悩みました。
これらの設定を変更するときは、-tオプションでターゲットレベルを、-arオプションでサンプリングレートを、-extオプションで出力形式を変更してください。
基本的にffmpeg-normalizeは2パス(1回目でファイル全体を解析、2回目でノーマライズ処理)でノーマライズを試みますが、曲のラウドネスの幅がターゲットLRA(Loudness Range、曲全体のラウドネスの幅、デフォルトは7.0LUFS)を超えると2パスのノーマライズを諦めてしまいます。
$ ffmpeg-normalize test.mp3 WARNING: Output directory 'normalized' does not exist, will create ★★↑出力ディレクトリを指定しないとnormalizedというディレクトリを自動的に作る WARNING: Input file had loudness range of 7.8. This is larger than the loudness range target (7.0). Normalization will revert to dynamic mode. Choose a higher target loudness range if you want linear normalization. Alternatively, use the --keep-loudness-range-target or --keep-lra-above-loudness-range-target option to keep the target loudness range from the input. ★★↑2パスを諦めたよ、というWARNING WARNING: In dynamic mode, the sample rate will automatically be set to 192 kHz by the loudnorm filter. Specify -ar/--sample-rate to override it. ★★↑2パスを諦めてdynamicモードになると192kHzで再エンコードし始める
WARNINGを見ると、この挙動を回避したければ--keep-lra-above-loudness-range-targetオプションを付けてねと書いてありますが、オプションによる悪影響の有無が良くわかりません。変換後の音楽をいくつか確認した限りでは、破綻やクリッピングが発生している様子はなさそうです、たぶん付けておいて良いのかな……??
複数のファイルを処理する際はシェルスクリプトを組んだほうが良いと思います。ffmpeg-normalizeに複数ファイルを渡すと1つのディレクトリ(デフォルトではnormalizedという名前のディレクトリ)に出力するからです。
例えばアルバムごとにディレクトリを分けて音声ファイルを格納している場合に困ります。ノーマライズ後のファイルが1つのディレクトリにまとめられてしまうと、再度アルバムのディレクトリに分配しなければならず面倒です。
for i in */*.flac; \
do echo $i -----; \
ffmpeg-normalize -t -14 --keep-lra-above-loudness-range-target \
-ar 48000 -ext wav "$i" \
-o "`echo $i | sed -e 's/flac\$/wav/g'`"; \
done
全アルバムディレクトリのflacを、ノーマライズしたwavに変換するならこんな感じです。適当スクリプトなので入力と出力を同じファイル名にできません。一度別名を経由して元の名前にリネームするように改造していただければと思います。
< | 2024 | > | ||||
<< | < | 01 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | 1 | 2 | 3 | 4 | 5 | 6 |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 | - | - | - |
合計:
本日: