kindle本の読みあげで試行錯誤したメモ

結論

試行錯誤中だけどユーザ体験としていちばんいいのはFireタブレット

はじめに、Fire HD10でkindle読みあげ

2020年元旦に投稿された以下の記事に触発され、その時やっていたkindle本のセールで10冊くらいNHK 100分de名著シリーズのテキストを買いました。 anond.hatelabo.jp

そのちょっと前に購入していた Fire HD10のkindleアプリでは、Android版やiOS版にはない自動読みあげ機能がついていて、音声の品質はいまいち(ゆっくり音声よりいいけどAlexaよりはだいぶダメ)ながら読みあげをしてくれる。

オンラインでもオフラインでも読みあげてくれて、ページも自動でめくってくれるので良いです。私が黙読する速度は2倍速よりやや速いくらいですが、聞きとりづらくなるのと間違った読みを確認する時間の余裕もほしいので、ややゆっくり目の1.5倍速で聞いています。 文体や言葉づかいにもよりますがときどき間違えるのでその時には画面をチラッと確認して使っています。

その他のkindle本を読みあげる方法

さて、日常的にAlexaやGoogle Assistantとかを使っているのでもうちょっといい声で再生したいです。同じことを考える人は多く、既にいくつかの方法があります。

Alexaのkindle本の読みあげ機能を使う

Alexa(echo端末でもAndroidやiOSのアプリでもよい)に対して「アレクサ、○○を読んで」と言うとその本の最後に読んでいたあたりから読みあげてくれます。登場当初は速度変更ができませんでしたが現在は「アレクサ、早く(遅く)読んで」のように言うと1.25倍や1.5倍などの速度で読みあげてくれます。

• 良いところ: 読みあげ音声品質。
• 悪いところ: 操作の粒度があらい。具体的には脚注などを大量に読みはじめたときにスキップさせたり、「ちょっとだけ戻して」みたいな操作がみあたらない。 (1/21追記:「1分早送り」「30秒巻き戻し」のように言うと飛ばしてくれます。AndroidのAlexaアプリでは30秒早送りおよび巻き戻しボタンがあります。)

Androidのアクセシビリティ機能(TalkBack)、iOSのアクセシビリティ機能(VoiceOver)を使う

AndroidまたはiOSのKindleアプリを実行して、OSの画面読みあげ機能を使います。

• 良いところ: 読みあげ音声品質。電話は普段持ちあるいているので物が増えない。
• TalkBackの悪いところ: 動かない端末がある。具体的には私が電話として使っている Huawei P20 lite ではKindle本のコンテンツは読みあげられませんでした。Talkbackのほとんどは動作しているようなのですが謎です……。
• VoiceOverの悪いところ: 画面表示上のページの区切れ目と、読みあげの区切れ目がことなる。おそらく段落ごとに読みあげ開始するのですが、あるページが段落の途中からはじまっていると次の段落から読みはじめたりします。当然ページめくりも同期しません。

まとめ

読み上げ品質

どれも聞きとれるんで実用上大きな違いはないのですがおおむね以下くらいの印象。Fire HDの音声がAlexaと同じくらいになってほしい……。

Google TalkBack = Alexa > Siri(VoiceOver) >> Fire HD

画面との同期

現状の日本語音声読み上げはあたりまえに間違いが入るので、私は画面をチラ見したいです。そういう点では以下のようになります。

Fire HDのKindleアプリ > Google TalkBack >> Siri(VoiceOver) >>> Alexa(画面がないのでしょうがない)

利用の簡単さ

標準機能であるKindleアプリとAlexaはさすがに利用はスムーズです。

VoiceOverは前述のページ区切りとのズレさえ飲みこめれば利用そのものは簡単です。専用のフローティングアイコンが常に表示されるのでゲームなどをする人には邪魔かもしれません。

Google TalkBackは視覚障害者むけのアクセシビリティ機能ということで、画面をみなくても使えるよう工夫されています。今回のように「Kindleの読みあげだけさせたい」というユースケースでは普段のAndroid利用とかなり異なる独特の手順を覚えることになるので面倒です。

Fire HDのKindleアプリ > Alexa > Siri(VoiceOver) >>> Google TalkBack

画面表示がいらない人むけtips

多少間違いがあってもオーディオブックみたいな使い方をしたい場合は、以下の記事が参考になります。

katsumakazuyo.hatenablog.com

Kindle以外について

Google Play BooksのAndroidアプリではごく普通に読みあげしてくれました。「100分de名著」のテキストは売ってないので今回使えませんが青空文庫を読ませたい人にはいいかもしれません。

自分の現状

もろもろ踏まえて、以下のようにおちつきました

• 移動先ではiOSのVoiceOver (普段遣いはAndroidなので、TalkBackが動けばそちらがよかった)
• 家ではFire HD10のKindleアプリの利用

MusicBrainz Picardで音楽ライブラリのタグ付けしたメモ

正月やすみにMusicBrainz Picardを使って音楽ライブラリのタグ付けをみなおしました。

MusicBrainz Picardとは

MusicBrainz Picardは、mp3やogg vorbisなどのファイルに「半自動で」タグをつけるソフトウェアです。名前から予想されるとおり MusicBrainzのデータをつかってタグが存在しない楽曲でもそれなりに推定してくれます。

picard.musicbrainz.org

なんでやったの?

再生に不備はないので放置していたんですが、自分の音楽ライブラリのタグがカオスでした。

• 昔のmp3には文字エンコードがSJISでタグついてたり
• そもそも自分がローマ字でタグやファイル名つけてたり
• それをoggに変換したときに使ったツールがUTF8前提にしていて文字化けしたり
• さらに自作スクリプトのバグでArtistタグが設定されていないファイルを変換したときに関係ないArtistタグが入ってしまったり……

最近Spotifyを使いはじめたら自分のライブラリをお気に入り楽曲として登録する機能があるんですね。登録するとライブラリの中身を反映していい感じのプレイリストを作ってくれるわけです。この機能には当然タグが使われるわけで、急遽「タグづけちゃんとしないとな……」という機運が高まりました。

おおまかな作業の流れ

1. Add Folderからフォルダを適当に選択
2. Unclustered Filesに曲がはいるのでClusterを押すと既存のタグ情報でアルバムごとに分類してくれる
3. アルバムを選択したScanを押すとAcoustIDを計算し、別のペインに「マッチしそうなMusicBrainzのアルバムとその楽曲、マッチしそうな度合い(タグやAcoustIDのマッチ度から計算)
4. その後検出情報を修正する。典型的には「ベストアルバムをスキャンする→複数のシングルとアルバムとして検出される→どれか1つの楽曲で検索して目当てのアルバムを指定→誤分類された楽曲を移動(アルバムからアルバムにまとめてできる)→トラックの誤割り当てがないか確認」
5. Saveボタンを押してタグ書き込み

全部やるのに2日くらいかかりました。ずっとやってたわけじゃないけど7-8時間くらいかかった気がします。

誤検出は?

• AcoustIDによる曲の誤検出はほぼ無い。5000曲くらいのアーカイブで作業して2,3曲くらい。むしろ厳しすぎて該当してるのにマッチしてくれない(false negative)のは300-400曲くらいあった。
• アルバムを検出したあとアルバム内の楽曲にフィットするときにはタグ情報を加味して適当にあてはめてくれる。これはもとのタグ品質にもよるので間違い多数。もとのタグやファイル名を見て人間(=僕)ががんばってなおした。
• そしてそれよりはるかに多いのは同じ楽曲が複数のアルバムやシングルに存在していて、想定と違うアルバムに分類されてしまうこと。あと限定版とかバージョン違いとか外国版とかもある(これはOther versionsというメニューで切り替えできる)。

MusicBrainzのDBも完全ではないのでもとのCDのデータがないケースではタグづけてきないことがあります。false negativeの可能性もあるのでここの確認をどれだけするかは悩ましいところ。アルバム10曲あれば1-2曲はヒットしてくれるので全くないときは『たぶんMusicBrainzに無い』ということにしてスルーしました。

MusicBrainz Picardのえらいところ

タグつけなおしのために考え抜かれて作られていることがわかる非常にいいソフトです。

• もとのタグを利用したクラスタリング機能があるおかげで作業が大幅にはかどる。
• アルバムで全曲フィットするとディスクのアイコンが金色表示されたり、マッチ率によりtrackのアイコンや背景色がかわる、変更される可能性があるタグを色づけするなど、人間が見るべきところを見つけやすくする工夫が随所にみられる。
• 誤検出を前提にして 「Search for similar tracks...」というメタデータで探すメニューや、MusicBrainzのWebを参照する機能がある。
• MusicBrainzで推定したアルバムが複数ある場合、アルバムからアルバムにドラッグ&ドロップすると適当に推定してtrackを割りあてなおしてくれる。自動割りあてできなかったtrackはUnmatched tracksのような分類で表示される。
• 基本的にSaveしなければ他の操作でタグが変わることがない。探索的に使いやすい。
• ステータスバーにtrackのファイル名が出るしダブルクリックで詳細がでる。タグをちゃんとつけてなくてファイルの場所から推定するしかないときにとても便利。

オチ

デジタルでしか音楽買わない世代うらやま。

Nature Remoを買ったメモ

導入のきっかけ

このQiita記事を読んで「あ、ぼくもやりたい」と思ったので年末にポチってNature Remoを導入した。モニタリング好きなんですよね。

qiita.com

12月31日に注文して1月1日に到着しました。たしかにヨドバシのサイトには1月1日って書いてたけど、持ってきてくれた郵便局の人に申し訳ない感。"いそがなくていい便"がほしいすな……。

赤外線操作の家電を登録

Nature Remoを買ったからにはウリの赤外線リモコン操作したいんで設定しました。2個だけですけど。

• エアコン (富士通ゼネラル ASE2205T (2005年製))

エアコンはすんなり認識、基本機能はカバーされているのでまあOK。 よく使う「ダッシュ」ボタンがなかったけど、リモコンから学習させてボタンを追加することはできないみたい。別のデバイスとして見せればなんとかはなるかもしれない。

• 扇風機 (ZEPEAL ゼピール DFT-A3409 )

扇風機はその他の機器扱い。電源on/offがトグルスイッチなので「offにする」と言ってもonになったりする。自動化に不向きだけどon/off明示的に分かれてたり状態管理してそうな扇風機のリモコンって見たことないなあ……。

注意点としては、電源ボタンを登録するときにアイコンを「Google Assistant対応のアイコン」から選ぶこと。「全てのアイコン」から選ぶとGoogle homeなどからデバイスの存在は見えるけど操作できない。

副作用

我が家ではTP-Linkのスイッチを1つ使ってディスプレイや机の電灯、電気ポットがつながっているテーブルタップの電源on/offをしている。今まで「OK Google、電源をいれて」「OK Google、電源を切って」と言って操作していたのですが、上記の設定をしたら扇風機もつくようになってしまった。

これからは「OK Google、机をオン」とかで生きていこう……。

設置場所

環境モニタリングが主な目的なので自分の体感に近いものを測定したい。ちょっと考慮して机の横においてあるカラーボックスに貼りつけることにした。普段座っている位置からも近いしリモコンもちゃんと届く。

ダッシュボード

冒頭の記事にあったリビング環境監視ダッシュボードは詳細な手順のおかげであっけないほど簡単にできました。

GASの時間ベースのトリガー、1時間ごとが一番短い単位みたい。15分おきとかがよかったけどEnterprise版だとあったりするのかしら。(1/10修正: 「時間ベースのトリガー」とは別に「分ベースのトリガー」などがありごく普通に15分おきの設定できました。

Googleデータポータルのグラフ、カスタマイズの範囲がめちゃくちゃ狭いのでExcelみたいなのを期待して作り込みしたい人にはきびしいかも。でもちゃっちゃとダッシュボード作るという点では良いバランスな気がする。

「Linuxデスクトップ元年」から20年経った

僕にとってはLinuxデスクトップ元年は学部4回生だった1999年あたりにきて、一瞬(研究室でMacbookを買ってもらって結局firefox+emacs+端末しか触らなくなったという)浮気した時期があったものの20年ほど主なデスクトップ環境としてはLinuxだけを使う生活をしています。

たまにバグレポートをするくらいで積極的に開発に参加しているわけではない身ですが、いろいろなものが順当に進化しているなと思っています。

あとこれは僕がたまたまそうなだけで一般的には言えない話なのですが、仕事でLinuxに詳しくなったのがそのまま日常生活に有益だし、その反対もあるのでLinuxデスクトップすごくいいです。日常でちょっとハマッた時に仕事の知見がつかえるのはかなりお得感があります。

ちょうど2019年も今日で終わりですので、僕の記憶からここ20年くらいのLinuxデスクトップについての思い出や感想をつらつら書いていきます。裏をとらずに記憶や気分で書くので間違いも多いかと思います。気になることがあればコメントください。

• デスクトップ環境の大幅な進化

  • 20年前だとまだSolarisはCDEがデフォルトだった気がします。僕もfvwm2とか愛用してました。友人がビルドしたKDE 1を見て「すげーwindowsの真似すげー」って叫んだ日を覚えています。
  • GNOMEがRHELやSLES, Solarisの標準的なデスクトップ環境になって(人的に)強化され、3.x初期には機能劣化があったものの順当に成長して日常的に使って困ることはほとんどない環境になっています。
  • KDEは何回かトライしたのですが最近は触っていません。カスタマイズ沼は好きなんですがね……。

• 綺麗なフォント

  • 良い日本語アウトラインフォントがなかったのが昔話になったの、本当にありがたいです。
  • IPAフォント関係者の皆様ありがとうございます。本当に助かりました。
  • Notoフォント関係者の皆様ありがとうございます。ウェイトもたくさんあって素晴らしいです。

• StarOffice → OpenOffice → LibreOffice

  • 学生や前職のあいだはオフィススイートを使うことはほぼなくて、Red Hatに入社してから使うようになりました。StarOffice(日本では商標の関係でStarSuite)は機能はともかくクラッシュ頻度がやばかったですね。LibreOfficeになる前後あたりから本当にすごく良くなった気がします。
  • 直接関係ないですがRed Hat社内にはlibreoffice-list というメーリングリストがあって「このファイルがバグった。たすけてー」って投げられるの最強の福利厚生だと思ってます。

• ブラウザ上で動くもの、ブラウザをベースとしたアプリケーションの進化と普及

  • これはLinuxデスクトップが良くなったという話ではないのですが、日常的に「ドキュメント書くのもメールもチャットもカレンダーもビデオ会議も他社サービスのコンソールも社内システムもみんなブラウザで1日ブラウザばっかり使ってた……」というような日が増えてきました。
  • LinuxにはFirefoxもChromiumもChromeもあるので「Safari/Edgeでの見た目を確認したい」というケースでなければ日常ほとんど困ることはありません。環境チェックが厳しいサイトはひっかかることがあるのですが、できればe-taxみたいに「警告はわかったけど強行する」みたいな選択肢がほしいです。
  • 2015〜17年ごろは Adobe flashのバージョン差異のため動作しないサイトを見ることがたまにありました。flashそのものが2020年に終わるということで現在ではこの問題も事実上なくなりつつあります。

• systemdやNetworkManagerによる足回りの整備

  • systemdによる世界征服が順調に進んできた結果デスクトップ環境にも各種の恩恵があります。
  • サスペンド/ハイバネート/電源管理 の標準化
  • オンデマンドなサービス起動(systemd+udevでハードウェア挿抜によるサービス起動、systemdのsocket activationでサービス呼び出し時にはじめてサービス起動、など)
  • systemd-logindによるmulti-head環境対応
  • 多数の無線基地局の接続情報を管理しつつダイナミックに実際の設定を変更するNetworkManager

• ソフトウェア開発環境としてのLinux地位向上

  • (Red Hatがリードできなかったのはくやしいですが、) Ubuntuが精力的にデスクトップ環境としての地位を固めていったおかげで「IaaS上ではLinux上で動作させるソフトウェアを開発するのに手元がWindows/Macじゃなくていいよね」という風にかわってきたように感じます。
  • 特にREST API叩きながらアレコレする時に、API提供する側のサンプルがsh+curlだったり、各種Public CloudサービスのドキュメントにLinux/Windows/Macの手順が併記されているのを見るとそのように思います。
  • JetBrainsのIDE群がLinuxに対応してるのも大きいですね。

• Waylandがついにきそう

  • 長い、本当に長い開発期間を経て各種ディストリビューションでWaylandがデフォルトになっています。
  • まだスクリーンキャプチャあたりに過渡期感がありますが、既に一般的なデスクトップ用途ならWaylandの方がいいんじゃないかと思うようになっています。

• かな漢字変換、入力メソッド

  • 僕自身は1996年くらいからずっとSKKを使っているのであまり何も困ってはいないのですが、mozcのメンテナンスが止まってしまい、日本語かな漢字変換が潤沢に提供されているとは言いにくい状態です。辞書のメンテナンスひとつとっても膨大な開発者の労力が必要なので、AndroidやChromiumOSなどの開発努力にのっかれるような工夫があるといいのかもと思ったりはします。

• Steamによるゲーム

  • さすがにWindowsに勝てる気はしませんが、20年前には思いもしなかったほど状況がよくなりました。
  • ValveのSteamがLinux対応したことと、ゲームエンジンのLinux対応も進んでいるおかげでかなり大量のゲームが存在します。昨日もOxygen Not IncludedやFaster than lightで遊びました。

• flatpak, snapdなどによる配布

  • Linuxにはさまざまなディストリビューションがあり、間違いなくLinux利用者にはよいことなのですが、デスクトップアプリケーションを開発する側からみると「それぞれのパッケージング技術、ポリシー、リリースタイミング、現在のライブラリバージョンなどがバラバラなのに対応するのは大変しんどい」という点が大きな問題です。
  • ArchのAURや、Gentooなどのようにユーザが自前でビルドするのだと割りきってしまえればいいのですが個人的には選んでダウンロードしてすぐ使いたいです。
  • flatpak, snapdなどコンテナ技術を参考にした配布方式が登場したことで、ディストリビューションのパッケージや、新旧バージョンの競合を心配せずに複数ディストリビューションへ対応したバイナリを配る基盤がととのいつつあります。
  • 間にディストリビューションが介在しないこのモデルは、ユーザがサポート窓口などを必要とする場合にはうまくマッチしませんが、upstream開発者とエンドユーザの距離が近くなること自体は最新版へのフィードバックが増えることに繋がります。エンドユーザむけ掲示板などとの組み合わせでうまい形で広まるといいなと思っています。

• オンラインサービス・デバイスとの連携

  • ブラウザ上で各種の操作ができるのはいいのですが、オンラインサービスと連携して動作する点は不安のあるところです。
  • たとえばGNOME Online AccountsではGoogle, Facebook, Microsoft, Nextcloudなどとの連携が可能で Google DriveをNetwork Driveのように扱うこともできますが、数えきれないほど沢山あるオンラインサービス(の内デスクトップと連携できるといいもの)から考えるとほんのわずかです。
  • またデバイスも、wacom製以外のペンタブレットでは設定ツールがないなど対応が手薄です。
  • オンラインサービス・デバイス側に十分なモチベーションがない限りこの手の問題は解決しませんので、たくさんのユーザに使ってもらい、シェアをとっていく活動は大事です。

来年こそみんなにとってのLinuxデスクトップ元年がきますように (-人-)

SpeakerDeckが検索にひっかからないのではてなブログにPDFから抜き出したテキストを載せてみた

SpeakerDeckにスライドを公開しているんですが、SlideShareに置いていたときと比較して、びっくりするくらいGoogle検索でひっかかりません。 自分のスライドを発見するのにGoogle検索よりディレクトリを探したほうが速いです。 2つのサービスにはいろいろ違いがあるのですが、こと検索についてはSlideShareの側ではPDFから抜き出したテキストを小さい文字でスライド表示ページに記載しているのが、タイトルと概要しかテキストがないSpeakerDeckより良さそうです。いろいろなキーワードで検索にヒットしますからね。

試しにblog記事として、SpeakerDeckを埋めこんで、スライドの下にpdftotextで作ったテキスト入れたらどうなるのかやってみました。

やったことは以下のとおりです。

1. speakerdeckのembed用スクリプトをblog記事コピペして、下に概要を書く

2. (続きを読む)が入るタグを入れる

3. divで小さいフォントにしてテキストを入れる

実際の記事テキストは以下のような感じになります。

<script async class="speakerdeck-embed" data-id="93c3e6deee684327b5a1473f5ad34d5b" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
Red Hat Enterprise Linux 8の概要および RHEL 7 からの主な違いをまとめたスライドです。

<! -- more -->  (実際は!と--の間にスペースは要りません)
<div style="font-size: 30%; color: gray">
(ここにpdftotextで作ったテキストをコピペする)
</div>

翌日確認したところ、それほど高い順位ではないものの検索で発見できるようになっていました。この作業をスライド毎に全部やるのは面倒くさいので自動化したいなあ。

Mi Band 4買って1ヶ月くらいつけて気付いたこと

はじめてのフィットネストラッカーとしてMi Band 4を買って1ヶ月ほど経ったのでメモ。

電池は2週間以上持つ

バッテリーもちが良いとは聞いていたけど、自分の使い方(自動心拍数検出と睡眠アシスタント10分おき、アクティビティ2日に1回くらい、毎日同期、手首ひねって画面点灯)だとたぶん17,8日くらいもつ。とはいえバッテリー残量が20%台とかになると気になってしまうので結局2週間くらいで充電することに。充電時間はだいたい1時間ほど。最初にバンドを外すときに力加減がわからないでちょっと心配になる。

バンドをつけること自体はあまり気にならない

腕時計もしてたことがないので一日中バンドつけてると鬱陶しいのではないかという点を買う前に一番心配していた。実際に汗かいたあとにはふやけているので左右を交代したりするもののかゆくなるようなことはない。例外的に気になったのは手首にアトピーが出たとき。その時は右手につけて対応した。風呂では外している。

昼寝には対応できない

睡眠は自動検出してくれる、短い起床を挟んだ二度寝にも対応しているが昼寝には対応していない。たぶん2時間くらい起床時間がつづくと駄目な気がしているが他の判定があるのかもしれない。昼寝情報をあとから足すこともできないのでGoogle Fitで手入力して昼寝を追加している。

睡眠の検出タイミング

自分が「意識このへんでなくなった」と思っている時間より30分〜1時間くらい遅い時間に寝たことになってるケースが多い。脈拍が少なく安定したときを入眠と判断しているみたい。睡眠時間の目安としての働きにはあまり影響ないので問題とは感じない。

Google fitの連携

心拍を10分毎に測定しているがGoogle fitにはなぜか一部しか反映されない。なんでやねん……。Mi Fitでは1日中の情報が表示されてもGoogle Fitでは16時から24時くらいの間しか表示されなかったりする。

MyFitnesspalがめっちゃカロリーひいてくるので困る

Mi Fit ←→ Google Fit ←→ MyFitnesspal と連携しているのだが MyFitnesspalにはどうやら歩数しか同期されていないらしい。ジョギングかなにかを想定しているようで消費カロリーがえらく多めに表示される。 たとえば今日はMi Fitが「359kcal消費したよ」と表示してるのだがMyFitnesspalで見ると「982kcalひいとくわ」みたいに出ている。MyFitnesspalだけ同期せずに使ったほうがいい気がする。

Mi Fitのアドバイス機能

情け容赦なく「22時頃までに就眠するよう心がけてください」とか言ってくる。午前2時3時に寝るのがあたりまえだったのが午後の内に寝ることが増えてきたので、生活改善としては機能してる。

目標歩数

8000歩にしてるけどまだトータルで8日しか達成してない。バス乗るのやめて歩くことが増えてきた。

まとめ

• 早寝早起きには有効。
• 運動は……多少ましなくらい。
• MyFitnesspalが消費カロリーを過剰に表示してるのに気付いたの最近で、それまで食べすぎてた気がする……

Twitter新UI用adblock定義

twitter.com - EasyList Forum これを参考にして「プロモーション」も足した定義を書いたら心の平安を得た

twitter.com##[data-testid="tweet"]:has-text(/Promoted|Gesponsert|プロモーション|Реклама|Promocionado/):xpath(..)
twitter.com##[data-testid="trend"]:has-text(/Promoted|Gesponsert|プロモーション|Реклама|Promocionado/):xpath(..)
twitter.com##[data-focusable="true"]:has-text(/Promoted|Gesponsert|プロモーション|Реклама|Promocionado/):not(:xpath(//span[contains(text(),'Реклама в Твиттере')]))

(追記) 普通に文中に「プロモーション」と書いてあるだけでもひっかかるのでfalse positiveが嫌な人にはおすすめできないです。