同一個幀率為什麼要有計數率和顯示基數

同一個幀率選項在這裡同時帶著兩個數，但它們承擔的工作不同。一個是推進牆上時鐘到幀數時使用的計數率，可以帶小數；另一個是時碼字串與幀數互相換算時使用的整數顯示基數。

看見 29.97 卻按 30 格去寫時碼，不是把兩個幀率混在一起，而是計數率與顯示基數在做兩件不同的事。

為什麼一檔幀率要保留兩套數

以 29.97 這類檔位為例，計數率負責回答「牆上時鐘過了這麼久，應推進多少幀」，顯示基數負責回答「這些幀應怎樣切成時、分、秒、幀的字串」。前者允許小數，是走時的尺度；後者必須是整數，是時碼幀位的分組基數。把兩者混成一個數，就會把走時速度和字串編號規則誤當成同一件事。

23.976 也是同樣的結構：推進時使用帶小數的計數率，字串換算時使用整數顯示基數。24、25、30 這類整數檔則沒有這層差異，因為計數率與顯示基數相同。這裡討論的重點不是哪個數更「真」，而是兩套數各自服務於不同計算。

兩個數不一致會怎樣累積成時間差

這些非整數檔的計數率比顯示基數慢大約千分之一，因此時碼編號的節奏與牆上時鐘的推進速度並不相同。29.97 配 30、23.976 配 24 時，字串仍按整數顯示基數分組，但實際推進使用較慢的計數率。結果不是偶爾少一個編號，而是同樣的差持續累積。

在這種口徑下，時碼相對牆上時鐘會越走越慢，量級是每小時秒級。按這個速率折算，每小時約慢 3.6 秒；把同一速率乘到 24 小時是 86.4 秒，也就是一分半這一檔。這個差不能用「看起來接近」來抹掉，因為它正來自兩套數的職責分離。

非整數檔的關鍵不是小數長得像整數，而是計數率決定推進速度、顯示基數決定編號結構，兩者的差會隨時間累積。

機位記錄裡的幀率怎樣折回基準率

當某台機位上記錄的幀率是一個高於基準的升格值時，折算邏輯會按除數逐個嘗試，把結果與可用的基準率比較。落進極小容差的首個候選就作為基準率；如果沒有候選命中，則回退到 24。這裡使用小容差，是為了讓接近的升格數值可以落回對應基準，又不把相鄰的正常檔混在一起。

例如 24 與 23.976 相差 0.024，所以容差必須比這段距離更小，才能讓 24 保持為 24，而不是被吸到 23.976。升格素材按基準率計數是行業裡常見的處理方式，但這不等於它是接收方必須採用的單一路徑。接收方仍應根據實際交件與自己的媒體記錄核對幀率標籤。

為什麼這種即時計數仍然是 NDF

在非整數檔的即時鏈裡，幀號連續遞增，不透過跳過某些幀號來追回牆上時鐘，因此這裡屬於非掉幀計數，也就是 NDF。NDF 說的是即時鏈怎樣編號，不是在宣告端到端的交付鏈具有同一種顯示規則。把「不跳號」理解成「時碼會追上牆上時鐘」正好相反：前面的累積差仍然存在。

匯出側另有自己的掉幀顯示裁定，而且這種分號寫法目前只出現在 ALE 與 CSV 的時碼欄上（日報 PDF 的表體沒有時碼欄），所以即時鏈與匯出側的口徑並不一致。這裡不能據此說 App 具有貫穿現場到交付的掉幀時碼能力，也不能把時碼寫成與牆上時鐘同步。關於交件中分號的含義，應另看《時碼裡的分號到底說明什麼》，而不是從即時 NDF 直接反推匯出結果。

交付時為什麼還要檢視標籤與分隔符

幀率標籤告訴接收方這一行交件聲稱採用什麼速率，時碼分隔符則反映匯出側採用了什麼顯示寫法。這兩個資訊都不能替代對源記錄的核驗，尤其在即時鏈與匯出側裁定並不統一的情況下。需要追一欄值從哪裡來時，可以結合《ALE 每一欄的值從哪裡來》逐欄核對，而不是只看時碼長得是否熟悉。

因此，接收方應自行核對交件裡的幀率標籤與時碼分隔符，並把它們與現場記錄、媒體側資訊放在一起判斷。計數率負責推進、顯示基數負責字串換算、匯出側再決定顯示形式，這三層不要互相代替。只要把層次分開，29.97 與 30 同時出現就不再是自相矛盾的兩個答案。

FAQ

29.97 為什麼還會看到 30 這個數？

29.97 是計數率，30 是顯示基數，它們分別用於推進幀數和拆分時碼字串。兩者同時出現是計算分工，不表示把一個檔位臨時改成了另一個檔位。

23.976 也使用同樣的雙數結構嗎？

是，23.976 用帶小數的計數率推進，時碼字串換算使用整數顯示基數。計數率比顯示基數慢大約千分之一，因此時碼相對牆上時鐘會逐漸變慢。

即時鏈的 NDF 是否表示匯出也按 NDF 寫？

不能這樣推出。即時鏈是不跳幀號的 NDF 計數，而匯出側另有掉幀顯示裁定，端到端口徑並不一致。

接收方最後應核對什麼？

接收方應自行核對交件中的幀率標籤和時碼分隔符，並與現場記錄及媒體資訊對照。僅憑某個數字或某種分隔符，不能把整條鏈路當作已經驗證。

Axiom One LLC — SlateX。以上數字截至 2026-09-24。