Barcode 圖片出現抖動／鋸齒
· 閱讀時間約 1 分鐘
今天遇到 Barcode 掃描不太到的問題。
在電腦上，不論是用「PDF 軟體」還是「內建 PDF Viewer 的瀏覽器」看都沒問題。
但實際上印出來就會發現有「抖動／鋸齒／毛邊」的狀況，變得很難掃描。
因此推測可能是電腦上的軟體都會自動做「抗鋸齒」或「平滑顯示」的處理。
所以，當你要縮放 Barcode 圖片時（非向量圖），盡量要做「Integer Scaling（整數縮放）」才比較不會有問題。
Oral-B 電動牙刷換電池
· 閱讀時間約 1 分鐘
手機打字精準控制游標
· 閱讀時間約 1 分鐘
屍體指紋解鎖手機
· 閱讀時間約 1 分鐘
TIL：屍體的指紋不太容易解鎖手機。
人死後皮膚會逐漸失去水分與導電性，所以「電容式」的指紋辨識就有可能解不開。 另外「光學式」、「超音波式」之類的原理雖然不太一樣，但一樣不容易解開。
不要問我怎麼知道的。
小說上看到的。
字幕流程迭代一個月，最後還是接上了 Gemini API
· 閱讀時間約 3 分鐘
上個月弄了一個「產生字幕、翻譯字幕」的流程，自己一直有在慢慢嘗試、迭代，沒想到竟然默默過一個月了！？
本地跑模型
比如說 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 放手機的記憶卡上。
用本地模型跑一整套字幕轉錄與翻譯流程
· 閱讀時間約 3 分鐘
前言
我很偶爾會有「外文影片 → 中文字幕」的需求。
這通常分成兩塊執行：
- 音檔 → 原文逐字稿
- 原文逐字稿 → 翻譯成中文
以前怎麼做
-
轉錄這塊以前都用 faster-whisper，在以前 LLM 還不發達的年代，我都只會用幾個預設參數跑，能出字幕就好。（甚至有自己切音檔 → 依序翻譯 → 再合併的鬼操作）
-
轉錄完成後，我都直接把 SRT 丟到 translatesubtitles.co 套 Google 翻譯，雖然一秒就翻完，但翻得不精準、也完全不吃上下文，一句一句各翻各的，日文的效果還特別差。
現在怎麼做
-
最近剛好又有這個需求，想到 LLM 可以幫忙，請 LLM 幫我看了一下，才知道原來有一堆實用參數可以調，像是逐字時間戳、自動換溫度重試、不讓前段錯誤污染後段，調好之後轉錄結果穩定很多。
-
以前連 ChatGPT3.5 都還沒出，現在則是本地 LLM 就能做翻譯了。重點是小模型提示詞要寫好、要分批、要有重試機制，這幾件事設計好，一整套流程跑起來非常順手，翻譯品質也遠勝 Google 翻譯。
痛點：LLM 如何做翻譯？
因為 LLM 翻譯，特別是小模型，最大的麻煩是「對齊」，模型常會偷偷合併、拆分或漏句，譯文就對不回時間軸了。
這邊 Claude 設計的解法是：給每句一個 [編號]。
- 系統提示裡把規則講死（編號數量、順序必須一模一樣，不可合併拆分漏句）。
- 用一次送一批帶編號的句子當輸入，再放幾句上下文當參考；輸出的部分必須要用指定的格式回傳，對得上才過。
- 那輸出對不上的情況呢？就做重試機制：先把沒對上的那幾句湊成小批補翻，剩沒幾句時乾脆一句一句單獨送（單句不可能對齊錯）。
- 後來又加了「多輪重跑」，整批掃完還有漏的就再跑一輪，直到全翻完、或某一輪一句都補不到才停，讓它自動補到近乎全翻，幾乎不用手動再跑。
- 每次成功的進度先寫進 JSON 檔案，下次可以直接做「斷點續傳」，隨時中斷也不會白做工。
心得
- 這樣一來，從影片到中文字幕，全程在本機完成，不用上傳、不用等線上服務，不會被審查，而且成功率極高。
- 這套流程我覺得還算滿意，可以給 80 分，夠用就好了，如果有更好的方法也可以跟我說。
- 花幾個小時來回跟 Claude 嘴砲，設計流程、修正流程還滿有趣的。（感謝老闆的 Token）
筆記
用 FFmpeg 把 MP4 轉成 WebP 動圖
· 閱讀時間約 1 分鐘
批次下載 YouTube 縮圖並調整尺寸
· 閱讀時間約 1 分鐘
前言
今天在更新網站上「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 當成最大邊界框，在框內保持原始比例縮放。
筆記
大小寫問題讓網站連結失效
· 閱讀時間約 3 分鐘
發現問題
今天偶然發現之前寫的多益資源整理，這篇文章連結點下去會直接跳回首頁。
奇怪，網址明明還停在 /blog/toeic-resources-2026/，內容卻是首頁。
但我在本地跑沒有問題啊！？
想說是不是 Cloudflare Pages 的問題，但往回前翻好幾版都有這個問題。
找出問題
我先去看了 sitemap、RSS、文章列表頁，所有指向這篇的連結都是小寫 /toeic-resources-2026/，沒有問題。
也跑去看了 public/blog/ 底下的資料夾，確實有 toeic-resources-2026/index.html，檔案在啊。
那為什麼 Cloudflare 找不到？
我請 AI 幫我比對 git 跟磁碟上的檔名，這時候真相浮出水面：
GIT: public/blog/TOEIC-resources-2026/index.html
DISK: public/blog/toeic-resources-2026/index.html
兩邊的大小寫不一樣。
為什麼
雖然我想不起來了，不過最有可能的情況應該是，我手動把資料夾從大寫的 TOEIC-resources-2026 改成小寫的 toeic-resources-2026，因為其他文章 slug 都是小寫，看起來比較一致。
當時改完，本機看一切正常，就 commit、push 上去了，根本沒注意到 git 其實沒抓到這次改名。
事後才知道，這是三個東西交織的結果：
- Windows 檔案系統大小寫不敏感，
Foo跟foo是同一個資料夾。 - Git on Windows 預設
core.ignorecase=true，會配合 Windows 的行為，這次的重新命名根本沒被當成一次 diff。 - Cloudflare Pages 跑在 Linux 上，大小寫嚴格區分，
/toeic-resources-2026/跟/TOEIC-resources-2026/對它來說是兩個完全不同的網址。
於是，本機看起來沒事，repo 裡其實還是大寫，部署上去就只認大寫，小寫的 URL 全部 404。
解決問題
要讓 git「真的」承認這次改名，得從索引裡先把舊的拿掉，再加回新的：
git rm -r --cached public/blog/TOEIC-resources-2026
git add public/blog/toeic-resources-2026
git commit -m "Fix case: TOEIC-resources-2026 → toeic-resources-2026"
git push
--cached 只動 git 索引，不會碰到磁碟上的實體檔案。
未來怎麼防範
可以考慮把 git 設成大小寫敏感：
git config core.ignorecase false
之後任何資料夾或檔名只要改了大小寫，git status 就會老老實實顯示「舊名稱被刪除 + 新名稱新增」，不會再無聲無息地漏掉。
再順手跑了一下 git status 全域掃描，確認其他歷史檔案沒有同樣的漏網之魚。
中島美雪《時代》
· 閱讀時間約 4 分鐘
《時代》
中島美雪的代表作《時代》，是在 1975 年那一年，她連續闖過兩個比賽的一首歌。
1975 年 10 月：Popcon
10 月 12 日，第 10 屆 Popcon（ポピュラーソングコンテスト）在靜岡縣つま恋舉辦。
那一屆收到了 12,000 首 應募曲，中島美雪的〈時代〉拿下了最高獎 グランプリ。也因為這個獎，她得到了代表日本參加 11 月世界歌謠祭的資格。
1975 年 11 月：世界歌謠祭
11 月 16 日，「第 6 屆世界歌謠祭」在日本武道館舉辦。〈時代〉再次拿下了最大獎 Grand Prix（グランプリ）。
那一屆的主持人，是日本傳奇歌手坂本九，以及當時已經紅遍亞洲的翁倩玉。
下面這段珍貴的影片中，約 1 分 56 秒處，收錄了當年在世界歌謠祭的影像，你可以清楚地聽到坂本九與翁倩玉主持的聲音。
坂本九：「Entry number 30, 日本, 中島みゆき, "時代".」
翁倩玉：「Entry number 30, Japan, "Time Goes Around".」
伴奏的故事
〈時代〉在舞台上原本是有管弦樂團伴奏的版本。但拿下 Grand Prix 之後的 得獎者加演（安可），中島美雪走上台前，對著指揮耳語了幾句。接著，整個樂團安靜下來，她抱著吉他，只用一把吉他自彈自唱了一遍〈時代〉。
這個決定來自於她的伯樂、YAMAHA 音樂振興會的理事長 川上源一 對她說過的一段話：
「あなたはすごい詞を書く。将来、詞で勝負するようなアーティストに育って欲しい。できれば大音量をバックにするよりも、ギター一本で歌った方が、あなたの詞が人々に伝わる」
「妳寫的詞非常出色。希望將來你能成長為一位以歌詞實力取勝的藝術家。如果可以的話，與其背負著巨大的音量（伴奏），不如只用一把吉他自彈自唱，你的歌詞反而更能傳達進人們的心裡。」（AI 翻譯）
從那之後，中島美雪在每一張專輯的工作人員名單裡，都會寫上一行 「DAD 川上源一」，以此致敬這位恩人。
關於父親
中島美雪在出道單曲〈薊花姑娘的搖籃曲〉發行前一週（1975 年 9 月 16 日），父親就因腦溢血倒下、昏迷不醒。
10 月的 Popcon、11 月的世界歌謠祭，她其實都是從父親昏迷的病房趕到會場上台的。父親後來於 1976 年 1 月離世，始終沒能聽到女兒奪冠的消息。
世界歌謠祭頒給她的 5,000 美元獎金，後來拿去當作父親的葬儀費用。
1993 年的彩蛋
中島美雪在 1993 年重新錄製了《時代》，歌曲的開頭，她取樣了在世界歌謠祭裡面，主持人坂本九與翁倩玉的介紹詞，以及歌曲開頭的一小段演唱。
翁倩玉：「Entry number 30, Japan, compose and sung by Miyuki Nakajima, the title of the song: Time Goes Around.」
（這聲音也太美了吧！！）
備註
我在「這篇貼文」中提到我前陣子跑去看了《陽光女子合唱團》，才發現其實我以前經常聽到這位國民阿嬤翁倩玉的聲音。
至於坂本九的話，我最喜歡的歌曲是《見上げてごらん夜の星を》。
參考資料
- ヤマハ音楽振興会：第 6 回世界歌謠祭 (1975)（主持人、得獎者、會場等基本資料）
- Tap the POP：中島みゆき「時代」③〜亡くなった父の言葉（父親病倒、昏迷、葬儀費的細節）
- 集英社オンライン：23 歳の中島みゆきがオーケストラ演奏を断り、ギター 1 本で『時代』を歌った理由