郭靖放開白馬韁繩，說道：「你沒用，自己去吧。」在紅馬臀上一拍，二人一馬，一齊躍入大江。小紅馬一聲長嘶，領先游去。郭靖與黃蓉並肩齊進。游到江心，那紅馬已遙遙在前。

「馬會游泳！？」 ← 這個人甚至可能沒看過馬。

我同學：「哺乳類動物大部分都會游泳」，然後傳了一堆動物游泳的影片給我看。

結論是：大概只有我和黑猩猩不會游泳。

Bonus 補一個很靠腰的斷章：

等到天黑，朱聰與全金發伏在郭靖母子的蒙古包外，過了小半個時辰，只聽郭靖說道：「媽，我去啦！」

問題​

大概半年前，我發現使用 FreshRSS 追蹤的一些 RSS/Atom Feed 會被 Cloudflare 驗證給擋下。

當時的解法是用 Cloudflare Worker 當跳板去抓，雖然偶爾還是會被擋，但是在大多數的情況下是 OK 的。

BUT！最近幾天整個大失效，不論是直連還是跳板都被擋，導致漏掉了許多訂閱的文章。

解決​

今天照關鍵字查了一下，發現 Ivon 的這篇「介紹 FreshRSS 的文章」裡面有解法！

• 安裝擴充套件「FreshRSS Flaresolverr Extension」

馬上安裝起來，成功解決！

原理是呼叫 Flaresolverr 來開一個「Selenium + undetected-chromedriver」去抓那些被擋掉的 Feed。

額外討論​

缺點是這個擴充套件的 API 可以直接被存取，如果你的 FreshRSS 是直接暴露在 Public 的，就有機會被有心人士濫用，拿去當成 Proxy 跳板。（不曉得機率有多大...）

所以，透過 Tailscale 之類的服務去存取 FreshRSS 可能還是比較安全一點。

或者，你可能需要特別針對擴充套件的 API 設定存取限制。（也太麻煩了吧）

不過，既然已經知道使用 Flaresolverr 可以順利抓到 Feed，那你也完全可以自己寫（AI 寫）一個迷你服務去呼叫 Flaresolverr 抓 Feed，這樣就沒問題啦。

所以我最後怎麼做？當然是什麼也不做，等真的遇到問題再說囉（？？？）

今天遇到 Barcode 掃描不太到的問題。

在電腦上，不論是用「PDF 軟體」還是「內建 PDF Viewer 的瀏覽器」看都沒問題。

但實際上印出來就會發現有「抖動／鋸齒／毛邊」的狀況，變得很難掃描。

因此推測可能是電腦上的軟體都會自動做「抗鋸齒」或「平滑顯示」的處理。

所以，當你要縮放 Barcode 圖片時（非向量圖），盡量要做「Integer Scaling（整數縮放）」才比較不會有問題。

說到自己換電池，想到昨天才在網路上學到如何幫 Oral-B 的電動牙刷換電池。

• 影片版教學
• 圖文版教學

整個過程非常簡單：把牙刷插上充電座之後轉 90 度扭開，接著把本體推出來，再換上電池就可以了。

每個型號的做法可能不太一樣，但是都非常容易更換，超讚。

TIL：手機打字時「按住空白鍵左右滑」可以精準控制游標位置。

從「刷比小廢報 Vol. 69」中的「近日學習」裡學習到的。

學到了～

TIL：屍體的指紋不太容易解鎖手機。

人死後皮膚會逐漸失去水分與導電性，所以「電容式」的指紋辨識就有可能解不開。 另外「光學式」、「超音波式」之類的原理雖然不太一樣，但一樣不容易解開。

不要問我怎麼知道的。

小說上看到的。

上個月弄了一個「產生字幕、翻譯字幕」的流程，自己一直有在慢慢嘗試、迭代，沒想到竟然默默過一個月了！？

本地跑模型​

比如說 faster-whisper 的參數可以照自己的喜好調整敏感度，就算是遇到一長串重複字的情況，也不一定要把參數調得保守，自己後處理一下也沒啥問題。

再來就是「Qwen3:8B」 vs 「Qwen3.5:4B」 vs 「Gemma E4B」的對決了，我無聊測了幾個模型，最後是比較喜歡 Gemma，又快又準，但差異沒有到很大啦。

直接用 Gemini API​

然後我就想到，就跟之前在「相關文章」那篇一樣......有 Gemini API 可以接啊！！

免費版的「Gemini 3.1 Flash Lite」每天可以打 500 次，我一次送個 1000 句翻譯，一次就成功，這樣只消耗一次對話。就算遇到內容審查被擋掉，改拆成 200 句去送後也就沒問題了。

他的「Gemma 4 31B」以及「Gemma 4 26B」每天也有各一萬多次的對話可以用，再怎麼說也比自己跑「Gemma E4B」好多了，不論速度還是精準度。

這就好像吹氣球，你可以保留自己嘴巴吹、用手動的打氣筒的選項，但直接去外面跟別人借電動的絕對是更省事一點。

就算真的要付費，目前 Gemini 的方式也很不錯，預付一次 10 美金就有很多的量可以用，只要設好限制就不怕被刷爆。

可以用現成的​

除了把自己寫的那套接到 Gemini 以外，也可以直接用這個 gemini-srt-translator 更省事，用起來是沒啥問題，只是我習慣用自己的就好，反正都寫好了，也感受不出差異。

當然，語言這種東西還是要自己學一點，才能領會到表達者在口語或文字上的意境，這是翻譯沒辦法取代的部分。

（啊，好像也可以把音訊丟給 Gemini 的模型當翻譯參考，不過那不是重點。）

關於影片​

最近從 B 站抓了點影片回來，發現 1080P/24FPS/AV1/300kbps 品質竟然還不錯，跟 H.264/6000kbps 好像也沒差多少，超級震驚！！！

音訊的話 AAC/192kbps 也夠用，沒什麼問題。我的 FLAC，也傾向轉成 AAC/256kbps 放手機的記憶卡上。

前言​

我很偶爾會有「外文影片 → 中文字幕」的需求。

這通常分成兩塊執行：

1. 音檔 → 原文逐字稿
2. 原文逐字稿 → 翻譯成中文

以前怎麼做​

1. 轉錄這塊以前都用 faster-whisper，在以前 LLM 還不發達的年代，我都只會用幾個預設參數跑，能出字幕就好。（甚至有自己切音檔 → 依序翻譯 → 再合併的鬼操作）

2. 轉錄完成後，我都直接把 SRT 丟到 translatesubtitles.co 套 Google 翻譯，雖然一秒就翻完，但翻得不精準、也完全不吃上下文，一句一句各翻各的，日文的效果還特別差。

現在怎麼做​

1. 最近剛好又有這個需求，想到 LLM 可以幫忙，請 LLM 幫我看了一下，才知道原來有一堆實用參數可以調，像是逐字時間戳、自動換溫度重試、不讓前段錯誤污染後段，調好之後轉錄結果穩定很多。

2. 以前連 ChatGPT3.5 都還沒出，現在則是本地 LLM 就能做翻譯了。重點是小模型提示詞要寫好、要分批、要有重試機制，這幾件事設計好，一整套流程跑起來非常順手，翻譯品質也遠勝 Google 翻譯。

痛點：LLM 如何做翻譯？​

因為 LLM 翻譯，特別是小模型，最大的麻煩是「對齊」，模型常會偷偷合併、拆分或漏句，譯文就對不回時間軸了。

這邊 Claude 設計的解法是：給每句一個 [編號]。

• 系統提示裡把規則講死（編號數量、順序必須一模一樣，不可合併拆分漏句）。
• 用一次送一批帶編號的句子當輸入，再放幾句上下文當參考；輸出的部分必須要用指定的格式回傳，對得上才過。
• 那輸出對不上的情況呢？就做重試機制：先把沒對上的那幾句湊成小批補翻，剩沒幾句時乾脆一句一句單獨送（單句不可能對齊錯）。
• 後來又加了「多輪重跑」，整批掃完還有漏的就再跑一輪，直到全翻完、或某一輪一句都補不到才停，讓它自動補到近乎全翻，幾乎不用手動再跑。
• 每次成功的進度先寫進 JSON 檔案，下次可以直接做「斷點續傳」，隨時中斷也不會白做工。

心得​

• 這樣一來，從影片到中文字幕，全程在本機完成，不用上傳、不用等線上服務，不會被審查，而且成功率極高。
• 這套流程我覺得還算滿意，可以給 80 分，夠用就好了，如果有更好的方法也可以跟我說。
• 花幾個小時來回跟 Claude 嘴砲，設計流程、修正流程還滿有趣的。（感謝老闆的 Token）

筆記​

1. Whisper：影音轉錄字幕檔
2. Ollama：用本地 LLM 翻譯字幕

今天在寫部落格時，順手學會了怎麼把 MP4 片段轉成 WebP 動圖。

這個用途很適合拿來做文章裡的小動畫，比直接塞影片更輕巧。

筆記​

• MP4 轉 WebP 動圖

參考資料​

• 動畫圖的正解是 WebP

前言​

今天在更新網站上「Tiny Desk Concerts」的欄位，突然想到沒有把下載步驟記下來，在這邊補一下。

第一步：用 yt-dlp 抓整個播放清單的縮圖​

yt-dlp ^
--skip-download ^
--write-thumbnail ^
--convert-thumbnails jpg ^
-o "%(title)s.%(ext)s" ^
"{播放清單／影片網址}"

第二步：用 ImageMagick 統一縮放​

magick mogrify -resize 480x270! *.jpg

mogrify 會直接覆寫原檔，省下另開資料夾的功夫。

尺寸後面的 ! 代表忽略原始長寬比，強制拉伸到指定尺寸。

沒加的話，ImageMagick 會把 480x270 當成最大邊界框，在框內保持原始比例縮放。

筆記​

• YT-DLP 指令筆記