影片筆記：Gemini Transcribeで字幕を作る！時刻は正確でも罠が3つ

<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->

⚠️ 全文快速校讀發現待確認修正

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

• 待修正：⚠️ 全文快速校讀發現未解決異常（segment=0 待確認：疑似ASR異常：'全自童'は'全自動'の誤認可能性が高い。また、'動画生成スキル'という表現が前後の文脈（[7]の'自動化できるのスキル'）と重複しているが、文法的に成立する可能性はある。；暫定：し、企画、台本、動画の制作を全自童でYouTubeに投稿してくれる顔出しなしAI動画生成スキルが完成しました。）
• 待修正：逐字稿可先使用，但有待校正清單（segment=0 rapid_semantic_review: 疑似ASR異常：'全自童'は'全自動'の誤認可能性が高い。また、'動画生成スキル'という表現が前後の文脈（[7]の'自動化できるのスキル'）と重複しているが、文法的に成立する可能性はある。）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

一句話總結

Google 推出的「Gemini 3.5 Transcribe」在單詞級時刻精度與處理速度上優於本地 Whisper，但存在「句子單位請求無效」、「智能整理與時刻互斥」、「開啟時刻導致文本準確度下降」及「超過 30 分鐘音聲時刻崩壞」等三大陷阱，使用者必須進行機械檢查以確保字幕安全。

核心重點

1. 性能優勢：

• 高精度：時刻偏差中位數僅 40 毫秒，最大偏差 0.64 秒，全部在 1 秒以內。
• 高速度：處理速度為音聲長度的 22 倍，比本地 Whisper 快 2.2 倍。
• 低成本：11 分 53 秒音聲費用約 5 日元，且開啟時刻不增加字符數計費。

1. 三大陷阱與限制：

• 陷阱一：句子單位請求無效。若請求「句子單位」，API 返回狀態碼 200（成功），但時刻數量為 0 行。即使拼寫錯誤也不會報錯，僅返回 0 行時刻。
• 陷阱二：智能整理與時刻互斥。若同時請求「智能整理（Smart Formatting）」與「單詞時刻」，會返回 400 錯誤（Smart 與時間戳記不兼容）。使用者必須在「乾淨文本」與「單詞時刻」中二選一。
• 陷阱三：長時間音聲時刻崩壞。超過 30 分鐘的音聲雖不報錯，但會出現時刻「飛移」至錯誤時間點（如 38 小時後）的嚴重錯誤，導致字幕行消失或錯位。

1. 文本準確度風險：

• 開啟單詞時刻功能會導致部分內容準確度下降（一致率從 96% 降至 95%）。
• 產品名稱在有時刻時會變為片假名，而無時刻時保留英文原名。
• 人名與產品名需預設為「事後自行修正」。

1. 操作建議：

• 不要相信返回的「200 成功」代碼，必須檢查返回內容的實際數據（如行數、時刻數值）。
• 建議在生成字幕前進行機械檢查：檢查時刻是否超過音聲長度，或時刻是否比前一個單詞更早（倒流）。

詳細大綱

I. 背景與動機

• 作者團隊過去使用本地 Whisper 生成字幕，發現時刻偏差中位數為 40 毫秒（幾乎完美），但每行僅 1.7 字，且請求「句子單位」時會返回 0 行。
• 今年 8 月 1 日發生事故：圖島字幕（字幕）比聲音最大延遲 5.9 秒，原因是後半段時刻偏差。
• 因此開發工具，將音聲重新輸入本地 Whisper 以單詞時刻重建字幕。
• 現在 Google 推出 Gemini 3.5 Transcribe 支援單詞級時刻，作者決定實測比較。

II. 實測設定

• 素材：本節目導音 11 分 53 秒。
• 對照組：台本與實際畫面字幕共 317 行。
• 測試項目：

1. 時刻準確度與速度。
2. 返回結果僅為單詞，請求句子單位無效。
3. 智能整理與時刻不可並用。
4. 開啟時刻後正文內容改變的問題。
5. 超過 30 分鐘音聲的時刻崩壞實例。
6. 費用比較與使用建議。

III. 實測結果詳述

1. 時刻準確度與速度（Gemini 勝）

• 準確度：
• 317 行中，文字一致的 166 行進行比對。
• 時刻偏差中位數：40 毫秒（mm秒）。
• 平均偏差：70 毫秒。
• 最大偏差：0.64 秒。
• 166 行全部在 1 秒以內，字幕層面无可挑剔。
• 速度：
• 無時刻：12.5 秒。
• 有時刻：31.7 秒。
• 速度為音聲長度的 22 倍。
• 對比本地 Whisper（最大模型）：70.3 秒。
• Gemini 速度為 Whisper 的 2.2 倍。
• 註：Whisper 若開啟單詞時刻，時間會增加約 3 成（從 54 秒增至更久）。

2. 返回結果僅為單詞塊（Gemini 限制）

• 11 分 53 秒音聲返回 2511 個單詞。
• 平均長度：1.73 字。
• 若直接作為字幕，畫面每 1.7 字顯示一次，無法閱讀。
• 請求「句子單位」測試：
• 在設定欄位指定「句子單位」。
• 返回狀態碼 200（成功），無錯誤。
• 但「帶時刻的項目」數量為 0。
• 重複測試 2 次均為 0 行。
• 甚至故意寫入不存在的詞彙，仍返回 200 成功，但時刻為 0。
• 結論：Gemini 忽略「句子單位」指令，僅返回單詞。若拼寫錯誤，不會報錯，但時刻為 0。
• 替代方案：作者團隊自行切分，上限 20 字，結果為 282 行，平均 14.7 字/行。
• 對比 Whisper：返回 215 行，平均 19.4 字/行，最長 66 字，仍需切分。

3. 智能整理與時刻不可並用（Gemini 限制）

• Gemini 3.5 Transcribe 有「智能整理（Smart Formatting）」功能可消除口語廢話（如 EO、A）。
• 限制：若同時請求「智能整理」與「單詞時刻」，會返回 400 錯誤。
• 錯誤訊息：「Smart 與時間戳記不兼容」。
• 影響：
• 必須二選一：要乾淨的字幕文本，還是要單詞時刻。
• 若選時刻，則為原始聽寫內容，需自行刪除口語廢話。
• 對於访谈、對談等口語廢話多的素材，需大量人工修正。
• 對於 AI 朗讀素材（無口語廢話），此限制影響較小。

4. 開啟時刻後正文內容改變（Gemini 缺點）

• 官方文件警告：開啟單詞時刻可能降低整體準確度。
• 實測數據：
• 同一音聲，比較「無時刻」與「有時刻」的結果。
• 54 處不同。
• 句子級別一致率：98%。
• 具體問題：
• 內容改變導致意義不同：「歸來」變為「歸來」，相差 4 字，若直接顯示會改變意思。
• 產品名稱問題：
• 無時刻：保留英文原名。
• 有時刻：產品名稱變為片假名。
• 一致率：無時刻 96%，有時刻 95%。
• 對比 Whisper：一致率 83%，所有英文名稱均變為片假名，且自定義詞彙字典有 1 字差異。
• 結論：無論使用何者，產品名與人名需預設為「事後自行修正」。

5. 超過 30 分鐘的時刻崩壞（Gemini 嚴重缺陷）

• 官方說明：普通文字轉錄支援 1 小時，但開啟「單詞時刻」後上限降至 30 分鐘。
• 實測：
• 輸入 32 分 5 秒音聲。
• 無錯誤，返回 5281 個帶時刻單詞，耗時 76.3 秒。
• 看似正常，但機械檢查發現：
• 僅 1 個單詞的開始時刻變為 140,000 秒（約 38 小時後）。
• 前後單詞均在 1400 秒左右。
• 該單詞「飛移」至 38 小時後，導致字幕中該行實際上「消失」（因為時間點錯亂）。
• 事故案例：
• 今年 8 月 26 日，發布 9 分 25 秒無聲無字幕影片。
• 通過 8 道檢查關卡（台本、原音、繪圖等），但無人檢測「是否有聲音輸出」。
• 作者團隊現在會在生成字幕前進行機械檢查：

1. 時刻是否超過音聲長度。
2. 時刻是否比前一個單詞更早（倒流）。

• 透過這兩項檢查，可立即捕捉 38 小時後的錯誤。

IV. 總結與建議

• Gemini 3.5 Transcribe 優勢：時刻準確（中位數 40 毫秒）、速度快（Whisper 的 2.2 倍）。
• Gemini 3.5 Transcribe 劣勢：
• 需自行處理字幕分行、整理、人名/產品名修正。
• 智能整理與時刻互斥。
• 開啟時刻可能降低文本準確度。
• 超過 30 分鐘音聲會發生時刻崩壞。
• 費用：
• Gemini：11 分 53 秒約 5 日元（時刻不增加字符數，故價格不變）。
• 本地 Whisper：耗時但免費。
• 核心教訓：
• 不要相信返回的「200 成功」代碼。
• 必須檢查返回內容的實際數據（如行數、時刻數值）。
• 即使返回成功，也可能隱藏 0 行或時刻錯誤。
• 檢查內容是防止事故的唯一方法。

工具 / 模型 / 名詞整理

• Google Gemini 3.5 Transcribe：Google 推出的文字轉錄專用模型，支援單詞級時刻。
• Whisper：本地運行的音聲轉文字模型，作者團隊過去使用。
• YouTube：影片發布平台。
• Open Chat（開放聊天室）：位於影片描述欄，用於提供 AI 自動化 YouTube 運營技能的指引。
• 圖島テロップ（圖島字幕）：逐字稿中出現的詞彙，疑為特定字幕類型或口誤，未查證。
• EO、A：音聲中的口語廢話/填充詞。
• Smart Formatting（智能整理）：Gemini 的功能，用於消除口語廢話。
• HTTP 狀態碼 200：表示請求成功。
• HTTP 狀態碼 400：表示請求錯誤（如 Smart 與時間戳記不兼容）。

操作流程整理

1. 準備素材：準備音聲文件（如 11 分 53 秒導音）。
2. 呼叫 API：使用 Gemini 3.5 Transcribe 進行轉錄。

• 可選擇是否開啟「單詞時刻」。
• 可選擇是否開啟「智能整理」。
• 注意：兩者不可同時開啟，否則返回 400 錯誤。

1. 檢查返回結果：

• 確認狀態碼是否為 200。
• 關鍵檢查：若請求「句子單位」，確認時刻數量是否為 0。
• 關鍵檢查：若音聲超過 30 分鐘，檢查是否有時刻「飛移」至異常時間點（如 38 小時後）。
• 關鍵檢查：檢查時刻是否比前一個單詞更早（倒流）。

1. 後處理：

• 若未使用智能整理，需自行刪除口語廢話。
• 若開啟時刻導致產品名變為片假名，需手動修正為正確名稱。
• 若返回結果僅為單詞，需自行切分為合適長度的字幕行（建議上限 20 字）。

1. 發布：確認無誤後發布影片。

值得注意的限制或風險

1. 句子單位請求無效：Gemini 忽略「句子單位」指令，僅返回單詞。若請求句子單位，API 返回 200 成功，但時刻數量為 0 行。
2. 智能整理與時刻互斥：同時請求兩者會返回 400 錯誤。
3. 文本準確度下降：開啟單詞時刻會導致部分內容準確度下降，產品名稱可能變為片假名。
4. 長時間音聲時刻崩壞：超過 30 分鐘的音聲會出現時刻「飛移」至錯誤時間點（如 38 小時後）的嚴重錯誤，導致字幕行消失或錯位。
5. 需自行處理字幕分行：預設返回單詞級時刻，需自行切分為合適長度的字幕行。
6. 人名與產品名需修正：無論使用何者，產品名與人名需預設為「事後自行修正」。

逐字稿辨識疑點

• 40mm秒：逐字稿中多次出現「40mm秒」，疑為「毫秒」的聽寫錯誤或口誤，但依指示保留原樣。
• 1.7時：逐字稿中描述單詞平均長度為「1.7時」，疑為「字」的聽寫錯誤，但依指示保留原樣。
• 全自童：疑為「全自動」的聽寫錯誤。
• 分の単位：疑為「句子單位」或「段落單位」的聽寫錯誤，但依指示保留原樣。
• 鍵で測った：疑為「自身で測った」或類似意思的聽寫錯誤。
• 図島テロップ：疑為特定術語或口誤，無法確認實際名稱。
• 3.5トランスクライブ：指代 Gemini 3.5 Transcribe 功能。
• 200番：指 HTTP 狀態碼 200（成功）。
• 400番：指 HTTP 狀態碼 400（錯誤）。
• AA：疑為「口語廢話」或「填充詞」的代稱或聽寫錯誤。
• 飯いみ：疑為「意味」（意義）的聽寫錯誤。
• 5位：在「カスタム語5位」中，疑為「語彙」或「設定」的聽寫錯誤。
• 5281号：疑為「5281個」的聽寫錯誤。
• 1ゴ：疑為「1個」的聽寫錯誤。
• 工場：結尾處「工場でお会いしましょう」，疑為「チャンネル」（頻道）或「YouTube」的聽寫錯誤，但依指示保留原樣。

可延伸追問

1. 對於超過 30 分鐘的音聲，是否有其他替代方案或工作流可以避免時刻崩壞？
2. 作者團隊自行切分子幕的演算法邏輯為何？是否有開源工具可供參考？
3. 若需同時獲得高準確度文本與精確時刻，目前的最佳實踐是什麼？
4. Gemini 3.5 Transcribe 的定價策略是否會隨使用量變化？對於大量使用者是否有更優惠的方案？
5. 如何自動化檢測「時刻飛移」與「倒流」？是否有現成的程式碼範例？