前回までは、機械に「聞いた以上のことを言わせない」話でした。今日は、もっと手前の話です。聞いたものを、失わない、という話。
15 分が、消えた
15 分の打ち合わせを録音して、停止を押しました。文字起こしはできていて、あとは要約を待つだけ。その待ち時間に、ホームへ戻って、ほかのことをしていました。
アプリに戻ると、ノートがありませんでした。要約どころか、文字起こしも、音声そのものも。15 分の話が、丸ごと消えていた。録り直しは、できません。その打ち合わせは、もう終わっているからです。
保存が、最後にいた
何が起きたのか。当時の処理は、停止のあと、文字起こしを整えて、話者を分けて、要約を作って、それから音声を書き出してノートを保存する、という一本道でした。保存は、列のいちばん後ろにいた。
そして、長い録音の要約には 1〜2 分かかることがあります。そのあいだにホームへ戻っていると、システムは、メモリを空けるために、裏にいるアプリを終了させることがある。列の途中で終了させられれば、保存はまだ来ていないので、すべてが消えます。
作っている本人には、要約が主役に見えていました。だから要約を仕上げてから、完成品を保存しようとしていた。でも、消えて分かりました。主役は、音声のほうです。要約は、あとから何度でも作り直せる。音声は、そのときを逃したら、二度と手に入らない。
順番を、ひっくり返した
直しは、列の並べ替えです。停止した瞬間に、まず音声をファイルに書く。次に、要約を作る前に、音声と文字起こしだけのノートを確定保存する。要約は、できてから、あとで書き足す。
これで、途中でアプリが終了させられても、音声と文字起こしは残ります。要約だけが空のノートは、次にアプリを開いたときに、自動でやり直されて埋まります。
録音中も、書きながら録る
考えはじめると、もうひとつ手前が気になりました。録音の最中はどうなのか。それまで、録音中の音声はメモリの上にいて、ファイルになるのは停止後でした。つまり、録音中に何かが起きれば、そこまでの全部が消える。
そこで、録りながら、そのつどファイルへ書き足していく形に変えました。書きかけのまま途中で終わっても、そこまでの音声はちゃんと読める形式で、です。これで、電池が切れても、アプリが落ちても、残るのは「そこまでの録音」であって、「何もなし」ではなくなりました。
拾う仕組みと、断る仕組み
仕上げに、まわりを固めました。起動時に、ノートに紐付いていない音声ファイルが残っていれば、自動でノートに起こします。90 分を超える長い録音は、途切れなく章に区切って、章ごとに保存していきます。そして、端末の空き容量が 100 MB を切っているときは、録音を始める前に、そのことを伝えて断ります。途中まで録って書けなくなるのが、いちばん悪い結末だからです。
学び
要約は、待てる。録音は、待てない。
最初の回に、話は録り直せない、と書きました。あの言葉に、自分の設計が追いついていなかった。いちばん失ってはいけないものを、列のいちばん先頭に置く。あたりまえのことに、15 分を失ってから、気がつきました。
次回
こんどは、聞き取りそのものの話です。録音の途中で英語が混ざると、文字起こしが崩れる。それを「二度聞き」で直した話をします。
STIL.NOTE は App Store で公開しています。
