コグノスケ

複数の音声ファイルのラウドネスを統一したい

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オプションで出力形式を変更してください。

2パス処理を諦めないで

基本的に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に変換するならこんな感じです。適当スクリプトなので入力と出力を同じファイル名にできません。一度別名を経由して元の名前にリネームするように改造していただければと思います。

SSLに対応

目次: 自宅サーバー

今更感がありますが、このサイトもSSL対応にしました。ブラウザに「安全ではない接続です！」と怒られなくなりました。まあ、それだけですね……。

SSL対応

SSL証明書は年990円のJPRSドメイン認証型SSLにしました。とてもお安いです。購入も簡単で、さくらインターネットからボタン1つで買えました。買った後にLet's Encryptを使えばタダだったのでは？と気づきましたけど、気にしないことにします。

日記システムも直した

サーバー側の設定以外に日記システム側も改修が必要です。一部のリンクや画像のURL出力などでhttpに決め打ちしていた部分があって、http経由/https経由でアクセスするファイルが混在していました。ブラウザはこのようなサイトを表示させると「完全に安全ではない！」と警告してくれます。良く見てます。ありがたい。

さらに面倒なことに自宅に置いているミラーサーバーはSSL非対応なので、手あたり次第httpを全部httpsに置換するとミラーサーバーの表示が崩壊してしまいます。サイトごとにhttp経由/https経由を設定できるように変更しましょう。

自分のドメインとGmailとDNSのDKIM, DMARC

目次: 自宅サーバー

Gmailのメール受信ポリシーが2024年の2月で変更されるというニュース（Gmailユーザへメールが届かなくなる？Googleが発表した「新しいメール送信者のガイドライン」とDMARC対応を解説！ - NRIセキュア ブログ）の対応の続きです。

Gmailに大量にメールを送る人（5000通over）でなければSPFだけでも良いらしいです。が、さくらインターネットがDKIMに対応してくれました（DKIM署名、DMARCを設定したい - さくらのサポート情報）し、せっかくなので使ってみます。

DKIM Keyレコード

DKIM（RFC 5672, RFC 4871, DomainKeys Identified Mail (DKIM) Signatures）はSPFとは異なりメールサーバーの設定が必須です。仕組みとしては、

• 送信側メールサーバー（さくらインターネット）にRSA秘密鍵を登録
• DNSサーバーにRSA公開鍵、ドメイン名を登録（DKIM Keyレコード）
• 送信側メールサーバー（さくらインターネット）はメールヘッダにドメイン名と署名を追加
• 受信側メールサーバー（Gmail）はDKIM Keyレコードから公開鍵を取得、メールヘッダの署名を検証し改ざんがないことを確認

こんな感じみたいです。間違ってたらごめんなさい。メールサーバーの設定はさくらインターネットの説明通りに設定すれば良いです。ログインしてコントロールパネルからDKIM署名を有効にし、秘密鍵を作成するボタンを押します。簡単でありがたいです。

DNSサーバーのTXTレコードにDKIM Keyレコードを追加します（バリュードメインの設定パネル用の書式で書いています）。"p="タグの値には公開鍵を書きますが、長いので省略します。

txt rs20240131._domainkey.katsuster.net v=DKIM1; k=rsa; p=(略)

先頭にあるrs20240131という謎の文字列はセレクタというそうです。RFCだと場所とか時間とか個人を表すものにする例が書かれています。さくらインターネットの場合はDKIM鍵を作成した日になるみたいですね。

DKIMセレクタの確認（さくらインターネットのコントロールパネル）

DKIM署名の確認（メールヘッダの一部から抜粋）

セレクタ文字列自体にあまり意味はなくて、メールサーバーがメールヘッダに追加するDKIM-Signatureの"s="タグの値と一致していることが重要です。

DMARCレコード

最後に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レコードが正しく設定できている必要があります。

Gmailに送って確認

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しました。しばらくこれで運用したいと思います。

Bluetoothドングル

目次: 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は正しく動くので、しばらくこちらを使います。