NEON DRIVE 制作の備忘録(1)制作編 — 前作 RESTART ENGINE から何が変わったか
前作の制作記は「最初にClaudeに投げた相談はこうでした」から始まりました。2作目の始まりも、やはり1つの相談です。
Sunoアルバムの後処理の工程、あなたの側でできない?
正直、ダメ元の質問でした。前作の RESTART ENGINE では、Logic 上の Ozone も、DaVinci Resolve も、DistroKid の入力フォームも、自分が手で操作していました。特に iZotope まわりは GUI でしか動かないものだと思い込んでいたので、無理だろうと思いながら聞いています。
返ってきたのは、Ozone を pedalboard 経由でヘッドレスに動かせる、という答えでした。そこから「前作で自分が手を動かした工程を、一つずつ Claude Code の実装に置き換える」という今作の方針が決まりました。こうしてできたのが、Suno で作った10曲入りのエレクトロポップアルバム「NEON DRIVE」です。この記事は、前作との違いを前作の章立てに沿って並べた記録です。途中で起きた事故や失敗は、姉妹記事の失敗と対策編にまとめました。
自分用の備忘録。前作の制作記(AIと二人三脚でユーロビートアルバムを作って配信するまでの全記録 —「RESTART ENGINE」制作記)の章立てに沿って、「前作でやったこと → 今作はどうなったか」を並べる。次のアルバムで同じ所まで再現できることが目標で、読者向けの説明は最小限にしている。 失敗と対策は別記事(失敗と対策編)に分けた。工程表・日ごとの記録・決めたことの一覧は後ろの付録にまとめた。
🌃 作品はこちら
▶ YouTube(フルアルバム・ビジュアライザ付き)
https://youtu.be/M5dVfir7WWQ
🎧 ストリーミング配信: 2026年10月3日リリース
事前保存(Pre-Save)はこちらから:
https://distrokid.com/hyperfollow/tadanobu/neon-drive
🏁 前作「RESTART ENGINE」の制作記
この記事は前作との比較で書いています。前作の工程を知らない方は、先にこちらをどうぞ。
AIと二人三脚でユーロビートアルバムを作って配信するまでの全記録 —「RESTART ENGINE」制作記
完成したもの
- アルバム: NEON DRIVE(全10曲・34分53秒。歌もの6曲・インスト4曲)
- YouTube: ビジュアライザ付きフルアルバム動画(1920×1080・60fps。H.264、映像は約40Mbps)
- 配信: DistroKid 経由で主要ストリーミングサービスへ。今作は同期歌詞つき(6曲・202行)
- 期間: 9/19〜9/26 の8日。うち制作工程は約6日で、残りは反省会と対策に使いました
- 前作と比べるときの前提: 前作は10曲すべてインストでした。歌詞に関わる工程(歌詞の作成と2版管理、DistroKid の歌詞登録と表記の手直し、同期歌詞6曲202行と原因究明)は今作で初めて発生し、実績表ではこの分が約2日です。前作と同じ工程だけを抜き出すと、約4日になります
先に結論を書いておくと、一番大きく変わったのは技術ではなく分業でした。自分の手番は「聴く・見る・選ぶ・送信する」にほぼ絞られ、張り付いたのはビジュアライザの試作(6〜8往復)と DistroKid の入稿(一晩)の2か所だけです。次に同じ型で作るなら、4〜5日で出せる見込みです。
分業 — PM の席を入れ替えた
前作の分業は、前作記事の「学んだこと」に書いたとおりです。
「Claudeチャット=PM、Claude Code=実装、自分=意思決定と手作業」 自分は判断と、GUIしかない作業(Logic、Resolve、Webフォーム)を担当
実際のところ、前作は Claude が手順を指示し、自分が GUI を操作する時間が大半でした。今作では、GUI でしかできないと思っていた作業の多くをコードに置き換えられたので、PM の席に自分が座り、実装は Claude Code に任せることにしました。
並べるとこうなります。
| 前作(RESTART ENGINE) | 今作(NEON DRIVE) | |
|---|---|---|
| PM | Claude(チャット) | 自分 |
| 実装 | Claude Code(ビジュアライザのスクリプトなど一部) | Claude Code(音・画像・動画・投稿・保管まで) |
| 自分の手番 | 判断+GUI 操作(Logic・Resolve・Web フォーム) | 聴く・見る・選ぶ・送信する |
| 検品 | スクリーンショットを Claude に見せて照合 | 機械の検査(計測・ハッシュ・照合)+自分の目視 |
表にすると一瞬ですが、この入れ替えができたのは前作で一度すべてを手でやっていたからです。その話は後半の「人間の役割の変化」で書きます。
第4章 マスタリング — Logic を一度も開かなかった
Ozone 12: リファレンスカーブ方式で全曲を -13.5±0.25 LUFS に統一 Logic Pro: ギャップ方式で10曲を連結し、YouTube用のフルマスターWAVを作成
前作では、Logic 上で Ozone を曲ごとに手で回していました。その途中でバウンスの「オーディオテールを含める」を入れ忘れて末尾が切れるテールクリップ事件があり、Bluetooth ヘッドホンで Ozone が固まる罠も踏み、最後は自作のラウドネスチェッカーで検品していました。
今作は、同じ作業を毎回手でやる理由がもう無かったので、Ozone をヘッドレスで動かすことにしました。
- pedalboard 経由で Ozone を読み込み、GUI を開かずに処理します。読み込みは VST3 です。AU はロードが速いのですが、バックグラウンドのセッションからは見えませんでした
- プリセット1本を全曲に適用し、-13.5 LUFS への追い込みまで自動で済みます
- 検品は ffmpeg の ebur128 に統一しました。前作の自作チェッカーの役目はここに移っています
- 末尾は無音検出で詰めます。前作のテールの罠は、「末尾を機械で見る」という仕様としてそのまま引き継ぎました
- 曲間のギャップと終端のフェードは設定値です。連結そのものは1秒で終わります
Logic を開かないので、Bluetooth の罠も出番がありませんでした。
第5章 ビジュアライザ — フルレンダは最後の1回だけ
前作: 第5章 ビジュアライザ開発 — ffmpegという選択
修正後、74分48秒で4ファイル(2レイヤー×ProRes/H.264、計20.5GB)のレンダが完走。
前作のビジュアライザは、26分46秒の尺をフルレンダするのに74分48秒かかりました。macOS 標準の bash 3.2 で空配列の展開が静かに死ぬ「静かに死んでいた」バグを踏み、スペクトラム層の黒浮きを数値検品で見つけたのもこの章でした。
今作では、見た目を決めるたびにフル尺を焼くのをやめるところから始めました。
- 設定は config.json に一本化しました(末端の値148、うちビジュアライザが42)。知らないキーや足りないキーがあればエラーで止まります
- 見た目は、短い区間の静止画とクリップで往復して決めました。フル尺を焼くのは確定した後の1回だけです
- レイヤー(L1 バー・L2 波形)を分けて並列にレンダします。今作のフル尺(34分53秒)で、L1・L2 を同時に焼いて約81分、合成が約32分でした
- グローを半分の解像度で計算して −15%(3分の区間で 730秒 → 623秒)。元との差は PSNR 54dB で、目では見分けられません
- 同期歌詞の確認動画も同じ描画関数を通します。確認用と本番で条件がずれないようにするためです
- 前作の黒浮きの知見は、黒レベルとカラーレンジを最初から揃える前提として仕様に入っています
前作の「これから」に書いた v2 の宿題4項目は、全部片付きました。
| 前作の宿題 | 今作 |
|---|---|
| 曲名テロップの自動描画(ffmpeg drawtext) | 完了。手元の ffmpeg に drawtext が無かったので、Pillow で PNG に焼いて重ねました |
| 先頭フレームバグの根治 | 完了。Resolve での1フレームトリムは不要になりました |
| レイヤー並列レンダ | 完了 |
| 設定のプリセット化 | 完了。config.json に一本化しました |
バーが64本中25組しか動いていなかった
試作の途中で、スペクトラムのバーが64本中25組しか独立に動いていないことが分かりました。前作から使っていた、showfreqs の対数表示を64本に切る方式では、隣り合うバーが同じ値を取っていたのです。バーごとに帯域を取り直し、その中の最大値で高さを決める方式に変えて、64本すべてが独立に動くようになりました。
波形の太さと色も、比較シートを並べて決めています。波形は縦横に太らせる round 6 を採用しました(旧来の縦1pxは、急な立ち上がりで線が細ります)。色は背景の明るさで合うものが変わるので、アルバムごとに背景を決めた時点で選ぶことにしました。今回は neon です。
※ この3枚は、当時の比較シートが残っていなかったので、9/26 に同じ時刻を今の設定で焼き直したものです。公開した動画とは見分けられない程度の差があります。
第6章 画像 — 親絵1枚から3点を派生させる
比較シートを面倒がらずに作って、実物を見てから決める——この往復が品質そのものだったと思います。
前作では Windows 機の前に座って画像を手で生成し、ジャケットは Photopea で 3000×3000 に整形、サムネの文字色は比較シートで決めました。
今作は、Windows 機に触らずに済ませたかったので、生成から採用までを album-art にまとめました。比較シートで決める習慣は前作のまま残しています。
- album-art が Forge をリモートで動かします。Windows 機の起動から生成、停止まで Mac から操作します
- 骨子の art 欄に書いたプロンプトから、コンタクトシート → 番号で採用 → 拡大まで自動です
- 題字は Pillow で焼き込みます。書体は5種の比較シートから Audiowide を選びました
- 親絵1枚から派生させる型にしました。ジャケットを親にして、左右をアウトペイントして 16:9 の背景に広げます。シルエットの消去や img2img で、背景とサムネを同じ親から派生させるので、3点の世界観が自然に揃います
背景は seed 違いで4枚出し、波形を置く帯の明るさを測ってから選んでいます。波形が埋もれない暗さかどうかを、目だけでなく数字でも見るためです。
第7章 合成 — DaVinci Resolve を卒業した
movファイルはData Levels=Fullに設定しないと黒が浮く
前作の合成は DaVinci Resolve でした。ProRes の Data Levels を Full に直し、背景下部をウィンドウマスクで減光し、先頭の1フレームをトリムし、Shift+D でバイパスを誤爆する、という Resolve 初心者の洗礼をひととおり受けています。
今作は、この手順を全部 ffmpeg でコード化しました。Resolve は使っていません。
- 減光は config の値です。前作で手で決めた値と手順が、そのまま仕様になりました
- 合成を ffmpeg に寄せたので、Data Levels を設定する場所自体が無くなりました
第8章 YouTube — ブラウザからのアップロードをやめた
前作: 第8章 YouTube — 「15分の壁」と限定公開
前作はブラウザから手でアップロードし、15分を超える動画の電話番号認証に当たりました。
今作は、概要欄やチャプターを毎回手で貼るのを避けたかったので、youtube-upload で API から投稿しています。概要欄・タグ・サムネ・公開設定まで一度に入ります。
- OAuth は「テスト中」のまま、自分をテストユーザーにして7日ごとに再同意して使います
- Google の審査を受けるなら、公開ホームページ・プライバシーポリシー・利用規約が必要です。個人用途なので審査は見送りました
- ここに落ち着くまでに、ドキュメント由来の断定を3回外しています(失敗と対策編の「ドキュメントを鵜呑みにして外した件」)
第9章 DistroKid — ラスボスはまだ倒せていない
前作: 第9章 DistroKid入稿 — ラスボスは入力フォームだった
分割拡大して1項目ずつ照合した結果、9箇所の修正漏れを送信前に発見・修正できました。
前作では10曲×同じ項目を手で入力し、送信前のスクリーンショット検品で「コピーされない項目」など9か所の修正漏れを見つけました。
正直に書くと、ここはまだ前作とあまり変わっていません。
- 入稿フォームの10曲×同じ項目は、今作も一晩かけて手で入力しました。歌詞の表記の決まりでの手直しも多くありました(失敗と対策編の D)
- 変わったのは2点です
- リポジトリ側で登録シート(distrokid.md)を生成し、そこから転記しました。入れる値を、フォームの外で先に確定させておくためです
- 入稿後の歌詞6曲と同期歌詞の入力・照合は、Claude in Chrome に任せました
- 同期歌詞は今作からです(前作は無し)。6曲・202行を登録し、手で直したのは7行でした
フォームの手入力を Claude in Chrome に任せるのは、次回の課題です(「次回の見積もり」に書きました)。
前作に無かった工程 — 作って終わりにしないために
今作では工程がいくつか増えました。上の3つは歌詞まわりで、前作が全曲インストだったために今作で初めて発生したものです。残りは作品そのもの以外の工程で、どれも「次のアルバムで同じことを考え直さない」ためのものです。
| 工程 | 中身 |
|---|---|
| 歌詞の作成と2版管理 | 歌もの6曲の歌詞を作り、2つの版を管理した。2版とは、Suno に渡す版(構造タグ入り)と、配信・表示用の版(表記を整えたもの)。同じ骨子で管理し、DistroKid の登録シートと同期歌詞はそこから生成した |
| DistroKid の歌詞登録 | 行頭以外の大文字が規定に合わず、手直しが続いた。次回は事前の表記チェックで拾う(経緯は失敗と対策編の D) |
| 同期歌詞 | 6曲・202行。分離ボーカル+文字起こし+声の立ち上がりとの照合で、手で直したのは7行に収めた。経緯は失敗と対策編 |
| OneDrive への配置 | rclone で直接置き、md5 で照合。フォルダ構成は固定 |
| 決裁メモと docs | 決裁メモ26本、手順書(docs/README.md)約1,100行 |
| 反省会 | 実績表と、次回の雛形を残した |
| 個人情報の push 前検査 | GitHub に push する前に bin/privacy_scan.py で検査する。ブログ素材を書き出すときも同じ検査を通す |
同期歌詞は、この中で一番手こずった工程です。詳しくは失敗と対策編の「同期歌詞の迷走」に書きました。
人間の役割の変化 — 前作の手作業が仕様書になった
前作は GUI 操作の時間が大半でした。それでも、スクリーンショットを見せて照合する検品が、インスト区分の9か所・黒浮き・チャプターの1秒ずれを公開前に止めていました。手は遅くても、目で止める仕組みは効いていたわけです。
今作で自分が張り付いたのは2か所だけでした。ビジュアライザの試作(6〜8往復)と DistroKid(一晩)です。ビジュアライザは見て選ぶだけで、手でパラメータを打つ作業はありませんでした。DistroKid の入稿フォームは前作と同じ手入力で、ここだけは GUI 作業が残っています。
振り返って一番大事だったと思うのは、前作の GUI 作業で得た知見が、そのまま自動化の仕様になったことです。
| 前作で手で覚えたこと | 今作の仕様 |
|---|---|
| Ozone のチェーン | ヘッドレス実行のプリセット |
| Data Levels と黒浮き | 黒レベル・カラーレンジを最初から揃える前提 |
| テールの罠 | 末尾を無音検出で詰め、機械で検品する |
| 減光のゲイン | config の値 |
前作で一度手でやっていなければ、何を自動化すればいいのかが分からなかったはずです。
もう1つ、前作の「AIの間違いも込みで運用する」に書いた「AIの提案は仮説、確定は実物で」は、今作でもそのまま有効でした。今回はそこに「ドキュメントの断定も仮説」が加わっています。YouTube API の準備で、ドキュメント由来の断定を3回外しました(失敗と対策編)。
歌詞まわりの工程が増えて、前作より工程は多くなりました。それでも、自分が張り付いていた時間は前作より減っています。
次回の見積もり — 同じ型なら4〜5日
型をそのまま使う前提で、4〜5日と見ています。今回かかったのは制作工程で約6日でした。
- 縮む所: 音(Ozone・計測・連結)は設定済みなので、ほぼ流すだけです。ビジュアライザの見た目は今回決めた値が config にあるので、試作の6〜8往復は要りません。残るのは、背景に合わせた波形の色選びと、ゲインの合わせ直しです(ゲインはアルバムの音で変わります)
- 縮まない所: 同期歌詞(即興のある曲は手で直す行が出ます)、DistroKid の入稿フォーム(今回は手入力で一晩)、フル尺のレンダリング(約2時間)
- 次回の分担(DistroKid): メタデータの入力と照合も Claude in Chrome に任せ、自分はアップロード・重要事項のチェック・送信だけにします。元に戻せない操作は自分がします。入れる値は今回と同じく distrokid.md からです
- 歌詞関連: 次回は 0.5〜1日の見込みです。lyrics_check の大文字チェックで登録前に表記を直し、同期歌詞は疑わしい行だけの確認動画で見ます
- 段取り: レンダリングを走らせている間に同期歌詞をやります。DistroKid の歌詞は、事前に英字の表記チェックに通してから入れます
2作目は「前作で手でやったことを、全部仕様に変える」アルバムになりました。前作の苦労が無駄にならず、次の作品の土台になっていく感じは、作品を作るのとはまた別の楽しさがあります。DistroKid のフォームというラスボスは残りましたが、それは次回の楽しみに取っておきます。
ここまで読んでいただきありがとうございました。夜のドライブや作業のお供にどうぞ。
▶ YouTube: https://youtu.be/M5dVfir7WWQ
🎧 Pre-Save / 配信ページ(2026年10月3日リリース): https://distrokid.com/hyperfollow/tadanobu/neon-drive
🏁 前作の制作記: 「RESTART ENGINE」制作記
🌃
付録A: 工程の流れ(この順で回す)
再現するときの順番です。後処理は album-pipeline(Python 35本・約6,200行)にまとめてあり、描画は music-visualizer の bash スクリプト(約400行)です。手順書は album-pipeline の docs/README.md(約1,100行)が正なので、再現するときは記事ではなく手順書を見ます。この記事は「なぜそうしたか」の索引です。
| 順 | 工程 | 主なツール | 実績の日 |
|---|---|---|---|
| 1 | 曲を生成・確定 | Suno | 9/19 |
| 2 | マスタリング(ヘッドレス) | Ozone(pedalboard 経由、VST3) | 9/21 |
| 3 | ラウドネス計測 | ffmpeg の ebur128 | 9/21 |
| 4 | 連結(曲間・終端) | ffmpeg | 9/21〜22 |
| 5 | 聴き比べ(曲間・変わり目) | 合図音を重ねた確認用音源 | 9/22 |
| 6 | ジャケット → 背景(16:9 に広げる)→ サムネ | album-art(Forge をリモート実行)、Pillow | 9/22〜23 |
| 7 | ビジュアライザ(バー・波形・文字) | music-visualizer(bash の描画スクリプト)、ffmpeg、Pillow | 9/22〜24 |
| 8 | 本番レンダリング | ffmpeg(ProRes の中間レイヤー → H.264) | 9/24 |
| 9 | 同期歌詞 | ボーカル分離(demucs)+強制アラインメント | 9/24〜25 |
| 10 | 配信登録 | DistroKid(フォームは distrokid.md から手で転記。入稿後の歌詞・同期歌詞は Claude in Chrome が入力・照合) | 9/24 夜 |
| 11 | 投稿 | YouTube(youtube-upload で API 投稿) | 9/25 |
| 12 | 掃除・保管・公開前の整理 | OneDrive(rclone)、GitHub | 9/25 |
付録B: 日ごとの記録
- 9/19 Suno で10曲を生成・確定。album-pipeline を作り始める
- 9/20 パイプライン(音・動画・画像)を試運転しながら構築(日付は推定)
- 9/21 Ozone をヘッドレスで回す、ラウドネス計測、連結。バックグラウンドのセッションから AU が見えず、VST3 に切り替え
- 9/22 曲間・変わり目の聴き比べ。ジャケット候補出し。ビジュアライザ試作開始。ffmpeg に drawtext が無いと判明し、文字は Pillow で焼くことに
- 9/23 ジャケット確定、背景とサムネに着手、ビジュアライザ試作2〜3ラウンド。画像と音・動画でセッションを分けた
- 9/24 動画の見た目を確定 → 本番レンダリング → 同期歌詞 → 夜に DistroKid 登録
- 9/25 YouTube 投稿、同期歌詞の仕上げ(6曲)、掃除・docs・保管、GitHub 公開前の整理、YouTube API の準備
- 9/26 反省会と対策の実装、Suno の時刻との比較、ビジュアライザの高速化
付録C: 決めたこと(工程別)
決裁メモは26本あります(album-pipeline の docs/decisions/)。ここには「次回もこのまま使う前提」のものを工程別に並べます。
音
- Ozone は VST3 で読む。AU はロードが16倍速いが、GUI のセッションでしか動かない。バックグラウンドからは見えない
- ラウドネスは全項目 ffmpeg の ebur128。LRA だけ loudnorm にすると計測系が二重になる。比較は同じ物差しでその場で測る。過去の表との数値の連続性は捨てた
- 曲間は 0.2秒、終端はフェード2秒+無音2秒、曲ごとに上書きできる欄つき。9/21 は 0秒+末尾の無音トリムにしたが、翌日実際に繋いで聴いて 0.2秒に上書きした。1.5秒は根拠のない仮置きだったので捨てた
- 変わり目の確認用の合図音は、差し込まずに重ねる。判定したいのは変わり目の聴こえ方そのものなので、差し込むと判定対象を壊す
画像
- 候補は
art/<用途>/<日時>/に移す。生成ツールの置き場のままだと7日で消える - 別案は
art/<用途>/<別案>/と<用途>-<別案>_final.png。本命と混ぜると「最新の候補」の判定が別案に食われる - 背景の候補は seed 違いで4枚出し、波形を置く帯の明るさ(y380-460 の平均)を測って選んだ
- サムネの題字の見た目は動画の文字から切り離す(9/26)。動画側の設定を借りていると、動画を変えたときに確定済みサムネの影が黙って変わる
- 生成画像のメタデータは消さずに伏せ字にする。接続先とユーザー名は出さない。プロンプトと seed は再現のために残す
動画(ビジュアライザ)
- 文字は Pillow で PNG に焼いて重ねる。ffmpeg を入れ直すと計測にも影響が読めないので、入れ直しと別ビルドの併置はやめた
- バーの感度は sqrt+高域補正(+4.5dB/oct)。9/23 に一度 lin にして同日に上書き。目標の高さの分布に一番近かった
- グローは描画側で1回だけ。合成側のグローは遅く、にじみも太い
- バーの帯域は1本ずつ取り直して、最大値でまとめる。取り直して 64/64。中央1列だけ取る案と平均案(高域が横並びになる)は捨てた
- 波形は round 6(縦横に太らせる)。round 8 は太すぎ
- 焼き込み文字は ×1.8、紺の縁取り 3px。明るい背景でも読める。×1.4 は小さかった
- 見た目を確定したら config に書き戻す。明るい空の背景は波形が埋もれるので捨てた
- 波形の色は白系を起点に、背景を決めた時点で選ぶ。今回の公開版は neon(#FF00AA〜#00E5FF)
- グローは半分の解像度で計算する(9/26 から既定)。1/4 は差が出始める
- L1(バー)の自前描画は見送り、中間レイヤーは ProRes のまま。実装2日と見た目の再承認をして、フル尺で1.5〜2倍にしかならない
同期歌詞
- 声の区間ごとの強制アラインメント+根拠つきの手動補正。曲全体で合わせると間奏の声に吸い寄せられて最大 +40秒崩れる。規則を足し続けると別の行が動く
- 03 の掛け声は聞こえる行だけに(47→39行)
- 同期歌詞の正はリポジトリ。DistroKid に登録した値を残す
- Suno の歌詞の時刻は使わない。経緯は失敗と対策編
投稿・配信
- YouTube の OAuth はテスト中のまま、自分をテストユーザーにして再同意で回す(第8章のとおり)
- DistroKid の表記の決まりと手間の話は失敗と対策編
運用
- 画像と音・動画でセッションを分ける。2つのセッションが同じファイルを同時に書き換えていた
- config を唯一の入力にする(反省会の対策。詳細は失敗と対策編)
付録D: レンダリング時間(次回の段取り用)
3分の区間を、各段1本ずつ直列で測りました(9/26)。
| 段 | 変更前 | グロー半分解像度(既定) | +中間レイヤーのハードウェア圧縮(既定ではない) |
|---|---|---|---|
| L1(バー) | 248.8秒 | 197.4秒 | 163.3秒 |
| L2(波形) | 332.8秒 | 276.5秒 | 248.8秒 |
| 合成 | 148.4秒 | 148.9秒 | 105.3秒 |
| 計 | 730.0秒 | 622.8秒(−15%) | 517.4秒(−29%) |
- 変更前の内訳: グローが全体の44%。中身はほぼぼかし(gblur)。L1 はグロー161.9・その他のフィルタ61.2・書き出し25.7、L2 はグロー162.1・その他151.8・書き出し18.9
- 半分の解像度にしてもグローは約162秒 → 約100秒までしか縮まない
- フル尺(34分53秒)の実測: L1・L2 を同時に焼いて約81分、ProRes の中間レイヤーは計約28GB。合成は約32分。空き容量は 30GB 以上見ておく
- 最終出力のエンコーダ比較(40Mbps、可逆の基準と比べて): H.264 VideoToolbox 50.0dB / HEVC VideoToolbox 51.6dB / libx264 62.3dB。今回は VideoToolbox の H.264
付録E: 仕組みの規模(9/26 時点)
- config.json: 最上位のキー60・末端の値148(うちビジュアライザ42)
- 決裁メモ26本、コミットは album-pipeline 67・music-visualizer 16
- 当時の比較シート56枚(album_out の 005 の blog_materials/)