文化庁の自由利用マークというのがあって、ITmediaの記事「文化庁、CCライセンスを支援へ 独自ライセンス構築は断念」によると、2013年の時点で普及はあきらめているらしい。 文化庁のウェブページを見ても、そもそも「コピーOK」「障害者OK」「学校教育OK」という区分も良いとは思えないし、どんな側面でも日本の法律に直結してしまっているのも、利用できる範囲が狭いのも、発展性がないような気がする。 しかし利用されてしまうと、説明のウェブページを維持しないといけないので、こういうのは失敗できない難しいことであるような気がする。
Diary
Android用のWikipedia appを使ってみた
Wikipediaをログインしないで使っていて、WikipediaのAndroid appがあるという通知が表示された。 これまでWikipedia appがあるとは知らなかったので、インストールしてログインしてみた。
これまでの編集や編集後の閲覧数をActivityとして閲覧できるのはおもしろいのだが、Firefox for AndroidでWikipediaのウェブページを開くと、appで開くか聞かれるのは煩雑かつ私には意味がない。
Firefoxでapp単位でこの機能を無効化できたか記憶がない。 また、外部サイトはあくまで外部のウェブブラウザーで開くことになるので、便利でもない。 どんなウェブページも開けるように作るのはセキュリティー的な面も考慮すると避けたいのかもしれないが…。 でもWikipediaほどのウェブサイトを表示できるのであれば、外部サイトをapp内で開いても大差ないような気もする。
いずれにしても、そこまで便利ではないと言うか不便になる方の影響が大きいのでアンインストールすることにした。
YubiKeyを使えないウェブサービスでYubiKeyを無理やり使う
PassKeysは明らかに私にとってのSingle Point Of Failureなので、なぜこんなものが流行しているのか、いまいち分からない。 技術的にはパスワードを入力してやりとりするより安全なのは間違いなさそうだが、もっと良い方法はないのだろうか。 いずれにしてもPassKeysを設定しないといけないサービスにFirefox for NetBSDからログインしたいので、選択肢はない。
Firefox for NetBSDを常用していてPassKeysを使おうとすると、ハードウェアセキュリティーキーを使う以外に方法はない。 私はYubiKey 5 NFCを買って使っている。 古いもの(ファームウェアバージョン5.4.3)はFIDO2の保管上限数が25であり、すぐにいっぱいになってしまう。しかも、脆弱性がある。 新しいもの(ファームウェアバージョン5.7.4)は100まで保存できる。しかし100しかないとも言える。 software FIDO2 authenticatorとでも呼ぶべきプログラムは存在するのだが、それをNetBSDで動くようにするのは、面倒な気がする。 やってみたらそうでもない可能性もあるので、勝手な印象ではあるが。 では、スマートフォンでQRコードを読み取る方式はどうかと言うと、これはBluetoothサポートが必要なので、到底実現できるとは思えない。
同じようなことを考える人はいるもので、Passkey DictatorというFirefox addonを作っている人がいる。 Mozilla Firefoxのaddon storeでも公開されている。 こういうソフトウェアを無条件に信頼してインストールするのは危険であるのは確かなので、良く吟味してから使わないといけない。
これを使うと、READMEに書いてあるようにPixivには問題なくPassKeysの登録もログインもできるようになる。Firefox for NetBSDでもWindowsでも同様に問題ない。user agent stringも変更する必要はない。
私の問題としているもう1つはdアカウントなのだが、これはFirefox for NetBSDでid.smt.docomo.ne.jpへ送るuser agent stringをGoogle Chromeにすると、PassKeysの登録もログインも両方が問題なくできる。 しかしFirefox for Windowsでは、PassKeysの登録はできるのだが、ログインの際にはQRコードのパターンにしかならない。 幸運なことにdアカウントには複数のPassKeysを登録できるので、YubiKeyとAndroidのGoogle Password Managerの2つのPassKeysを登録しておくことにすれば、最終的には問題にはならなかった。 dアカウントでのログインは、PassKeysが必要なサービスとそうでないサービスがあるので、面倒である。
もう少し勉強すれば、Firefox for Windowsでdアカウントにログインできるようにできるのかもしれない。
mixed mode CDのデータトラックをマウントする
以前に「古いmixed mode CDをバックアップする」と題してバックアップ方法を書いたが、実際のmixed mode CDのディスクについてはあまり触らなかった。 気になっていたのは、データトラックがNetBSDでマウントできるかを確認していなかったし、データトラックをマウントした状態ではCDDAのクラックは再生できないだろうが、それも実際には確認していなかった。 そもそも、CDDAの実際のディスクを再生する簡単な方法も分かっていなかった。pkgsrc/multimdia/vlcで/dev/cd0を再生すれば間違いはないのだが、mplayerやmpvではどうすべきか分かっていなかった。
まず、データトラックをマウントしてみる。 これは簡単で、普通にマウントすれば良い。
# mount_cd9660 /dev/cd0 /mnt/cdrom
予想通り、マウントしている最中にはCDDAのトラックは再生できなかった。
後はmixed mode CDを作る方法を調べてやってみれば、mixed mode CDに関する疑問は解消できそうだ。
2週間ごとにリリースされるようになるFirefoxの移植に取り組むべきタイミングを調べる
Firefoxが1カ月ごとではなく、2週間ごとにリリースをするようになるということなので、どの時点でpkgsrc/www/firefoxの更新作業をし始めるべきなのか確認してみた。
これまでは、b6までがbeta版ということになっていて、b6とb7の間ではビルドされるコードが違う。具体的には、#ifdefを使って違いが出るようになっていた。 Firefoix 155.0が2026年9月1日にリリースされるのはhttps://whattrainisitnow.com/calendar/を見ると分かるが、そのRelease dayの項目をクリックするとhttps://whattrainisitnow.com/release/?version=155のページへ移動することができる。 ここで、Beta 5の項目を見ると、Last beta uploftsと書かれていて8月26日にリリースされる予定になっている。
この後がb6になるのか、RCになるのかは分からないが、b5の次になったらpkgsrc/www/firefox-155に取り組み始めるスケジュールが良さそうだ。 ただ、これまでであれば、1週間前にはb9程度までは進んでいて時間はまだ足りないものの、どうにかできなかった訳ではないと思うが、リリースまで1週間を切ってから作業を始めないといけないのは大変かもしれない。
P.S. (2026-09-19)
155と156がリリースされたが、いずれでもb5の次がrc1のようなので、rc1が例えば156.0であればhttps://ftp.mozilla.org/pub/firefox/candidates/156.0-candidates/build1/に現れたら作業を開始するので良さそうだ。 でも、こうなると作業できる時間は短い。
古いmixed mode CDをバックアップする
CD EXTRAができる前にはmixed mode CDというのがあったはずで、私の持っているCDの中にはこのmixed mode CDの仕様に従っているものがある。 例えばWindows 11では、オーディオCDとして再生もできるし、写真の含まれたCD-ROMとしても同時に認識される。 これをNetBSDで再生したいのだが、全てを同時に満足するような方法は見付けられなかった。 だが、結果としてcdrdaoでバックアップしておけば、バックアップしたことになるようだ。
cdrdaoでバックアップする
cdrdaoでバックアップする方法は前回説明した通りで良い。 ただ、第1トラックはオーディオではなくデータが入っている。 cdrdaoコマンドを実行した時の表示で、それを見ることができる。
$ cdrdao read-cd --datafile file.bin --driver generic-mmc:0x20000 --device /dev/cd0 --read-raw file.toc Cdrdao version 1.2.4 - (C) Andreas Mueller <andreas@daneb.de> /dev/cd0: PIONEER BD-RW BDR-XD08 Rev: 1.02 Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x20000) Reading toc and track data... Track Mode Flags Start Length ------------------------------------------------------------ 1 DATA 4 00:00:00( 0) 02:36:34( 11734) 2 AUDIO 0 02:36:34( 11734) 02:42:02( 12152) 3 AUDIO 0 05:18:36( 23886) 04:31:63( 20388) 4 AUDIO 0 09:50:24( 44274) 04:04:02( 18302) 5 AUDIO 0 13:54:26( 62576) 04:38:10( 20860) 6 AUDIO 0 18:32:36( 83436) 06:09:15( 27690) 7 AUDIO 0 24:41:51(111126) 04:32:10( 20410) 8 AUDIO 0 29:13:61(131536) 06:06:04( 27454) 9 AUDIO 0 35:19:65(158990) 03:51:03( 17328) 10 AUDIO 0 39:10:68(176318) 03:56:04( 17704) 11 AUDIO 0 43:06:72(194022) 06:12:16( 27916) 12 AUDIO 0 49:19:13(221938) 00:06:04( 454) Leadout AUDIO 0 49:25:17(222392) PQ sub-channel reading (data track) is supported, data format is BCD. Raw P-W sub-channel reading (data track) is supported. PQ sub-channel reading (audio track) is supported, data format is BCD. Raw P-W sub-channel reading (audio track) is supported. Copying data track 1 (MODE1_RAW): start 00:00:00, length 02:34:34 to "file.bin"...
データトラックを抽出する
これをmplayerで再生すると、第1トラックはホワイトノイズのような内容になってしまう。 それは避けようがないとして、第1トラックを抽出したい。 bchunkコマンドを使えば良いようだ。 まず、以下のようにインストールする。
# /usr/pkgsrc/sysutils/bchunk # make install
これで、各トラックをファイルとして抽出する。 これにより、tracl01.isoと第2トラックからのtrack02.cdrといったファイルが生成される。
$ bchunk file.bin file.cue track
この第1トラックの分のISOファイルは、以下のようにマウントすれば良い。
# vndconfig vnd0 ./track01.iso # mount_cd9660 /dev/vnd0a /mnt/cdrom
一方で、オーディオトラックの分のcdrファイルは以下のように再生できる。
$ mplayer -demuxer rawaudio -rawaudio rate=44100:channels=2:samplesize=2:format=0x10001 track02.cdr
オーディオCDをバックアップして再生する
私は何かをしながら音楽をきくと全く音楽を無視してしまうので、音楽を聞く習慣がなく、オーディオCDもほとんど持っていない。 だが、持っているものはあって、それらは20世紀のものなので、いつ劣化して再生できなってもおかしくない気がする。 と言うことで、バックアップしたいと思う。 全く知識がないのだが、binまたはimgというイメージファイルと、tocまたはcueファイルを組み合わせるのが一般的なようだ。 ウェブを調べても新しい情報はあまりないが、もうオーディオCDを扱いたいという人がいなくなって来ているのかもしれない。
pkgsrc/sysutils/cdrdaoでbin+cueを作る
cdrdaoコマンドを使えばbinファイルとtocファイルを作ることができ、toc2cueコマンドを使えばtocファイルをcueファイルに変換できるようだ。 と言うことで、cdrdaoパッケージをインストールする。
# cd /usr/pkgsrc/sysutils/cdrdao # make install
以下のように実行すれば、binファイルを作ることができる。
ここで、--driver generic-mmc:0x20000を付けたのは、このbinファイルをそのままでmplayerで再生できるようにするためだ。
続けてtocファイルをcueファイルに変換する。
$ cdrdao read-cd --datafile file.bin --driver generic-mmc:0x20000 --device /dev/cd0 --read-raw file.toc $ toc2cue file.toc file.cue
これをmplayerで再生するとする。 まずはmplayerをインストールする。
# cd /usr/pkgsrc/multimedia/mplayer # make install
cueファイルに合わせてmplayerで各トラックを再生するのは、以下のようにすれば良い。 以下では、現在のディレクトリーにあるcueファイルを使ってbinファイルの2トラック目を再生する。
$ mplayer -demuxer rawaudio cue://file.cue:2
トラックに関係なく再生するのであれば、以下のようでも良い。
$ mplayer -demuxer rawaudio file.bin
binファイルを再生するのは、mplayerでは可能なのだが、手元にあるqmmp-1.7.11ではできなかった。 しかし、cueファイル自体はflacファイルに対しても利用できるようなので、以下のようにflacコマンドをインストールしてflacファイルに変換した。
# cd /usr/pkgsrc/audio/flac # make install $ flac --best --force-raw-format --endian=little --channels=2 --bps=16 --sample-rate=44100 --sign=signed --cuesheet=./file.cue --output-name=./file.flac ./file.bin
更に、cueファイル中のファイル名を更新しておく必要がある。
--- file.cue 2026-08-22 19:12:27.532711497 +0900
+++ file-flac.cue 2026-08-22 19:12:38.416281352 +0900
@@ -1,4 +1,4 @@
-FILE "file.bin" BINARY
+FILE "file.flac" BINARY
TRACK 01 MODE1/2352
INDEX 01 00:00:00
TRACK 02 AUDIO
これであれば、qmmpでcueファイルを指定して再生することができる。
文化庁の自由利用マーク
文化庁の自由利用マーク というのがあって、 ITmediaの記事「文化庁、CCライセンスを支援へ 独自ライセンス構築は断念」 によると、2013年の時点で普及はあきらめているらしい。 文化庁のウェブページを見ても、そもそも「コピーOK」「障害者OK」「学校教育OK」とい...
-
Arvel USBシリアルケーブルSRC06-USBをWindows 10 x86_64で使う で、Arvel (現バッファロー) のSRC06-USBというFTDIのチップを使ったUSB to Rs-232CアダプターをWindows 10で使う話を書いたが、同じSRC...
-
※ Windows 11でも使える記事 を書いた。 Arvel SRC06-USB USBシリアルケーブルというUSBシリアル変換器を持っている。 これにはFDTI製のUSBシリアル変換チップをい利用していて、USB VendorID/ProductID=0x...
-
This post will be irrelevant for Google Workspace after 2022-10-04 because OAuth out-of-band (OBB) flow will be deprecated. See my newe...