速查 › 播報與音訊系統

播報與音訊系統

主播的每一句話、場館廣播、觀眾應援、全壘打音效 —— 全都在 data/audio/ 底下。這一區比整個遊戲其他部分加起來還大， 而且它的索引檔是純文字，你可以直接打開驗算。

先看規模

上面每個數字都是把 data/audio/ 現場走過一遍數出來的，不是引用他人資料。

每個分區都是同一套模板

13 個分區裡有 6 個結構完全一致，各自 6 個檔， 而且這 6 個分區的副檔名組成一模一樣（.txt、.nam、.evt、 .big、以及兩個 .off）。以觀眾應援 chants/ 為例：

chants/
  spch_cht.txt      名稱表(純文字,可以直接讀)
  spch_cht.nam      名稱表(二進位版)
  events.evt        事件表(二進位)
  chanthdr.big      標頭資料
  chanthdr.off      標頭索引(純文字)
  chantdat.off      資料索引(純文字)

cd/chants/
  chantdat.big      ← 真正的聲音在這裡,56 MB

那個叫 .off 的檔可以直接驗算

索引檔 .off 是純文字，打開就看得懂，每行兩個數字：

chantdat.off 的前四行(原檔內容)
0,865536,
865536,805632,
1671168,1658624,
3329792,917760,
      │      └── 這一段有多長
      └───────── 這一段從第幾個位元組開始

把每一行的兩個數字加起來，就是下一行的開頭： 0 + 865536 = 865536，865536 + 805632 = 1671168。 一路對到最後一行都不會斷。

全部 16 個索引檔分成兩半：8 個資料索引（*dat.off）與 8 個標頭索引（*hdr.off）。上表列出 8 個資料索引， 外加 pbphdr.off 當作標頭索引的例子；沒列出的 7 個標頭索引同樣全部相符。

.big 在這裡有三種完全不同的格式

data/audio/ 底下有 28 個副檔名是 .big 的檔案。 實測前四個位元組，只有 12 個是真的 BIGF 封裝檔：

主播語音：三層名稱，而且對不上

主播 spch_pbp/ 是全遊戲最大的一區。它的名稱表 spch_pbp.txt 是 1.1 MB 的純文字，長這樣：

1b_pbp_ex                          ← 群組標頭(沒有數字)
yil.6+.1                    230656 ← 名稱 + 在資料檔裡的位置
yil.6+.3                    241152
yil.6+.4                    251648

23,013 個名稱，但只有 2,056 個資料段。 這兩個數字差了十倍以上，所以名稱跟資料段不是一對一。 名稱表裡的 23,013 條只用到 5,704 個不重複的位置值， 代表同一段聲音會被很多個名稱共用。

13 個分區各是什麼

噓聲、小販、裁判在哪裡

環境音效放在 audio\aems\，只有 20 個檔。 而且檔名直接說了它是什麼：

18 個 .abk 檔的開頭四個位元組全部是 ABKC。 audio\cd\aems\ 底下另有 11 個 .ast，檔名一一對應。

應援曲：索引是純文字，而且看得出來 EA 幫誰錄了

上面說過聲音本體在 cd\chants\chantdat.big（56 MB）。 可是索引 chants\spch_cht.txt 是純文字，記事本直接打得開：

spch_cht.txt 的開頭(原檔內容)
beat_backs
beat_backs.lg.01.wav             0
beat_backs.md.01.wav        432640
mvp
mvp.lg.01.wav                    0
mvp.md.01.wav               458752
pchants:0004
pchant.0004.typ1.1.lg.01.wav     0

格式很單純：一行群組名，底下每個音檔一行，後面那個數字是它在資料檔裡的位置。 原版共 90 個群組、103 個音檔。

驗算：這個檔非空行共 193 行 ＝ 群組 90 ＋ 音檔 103， 一行不多一行不少。

EA 幫這 56 個人錄了專屬應援曲

編號小於 2000 的 43 位，是 2004 年當時的現役球員：

編號 2126 之後的 13 位，全部是傳奇球員：

現役球員的編號散在 4 到 1363 之間，傳奇球員擠在 2126–2164。 編號本身就把兩群人分開了。
上表有一位只有一個字：Ichiro。 他在資料裡姓有、名是空的 —— 57 個人裡只有他這樣。

檔名裡那個數字，是球隊資料表裡的一欄

索引檔裡到處是 tchants:19、teamspecific:03、 stadiums:29 這種寫法。那個數字對得到人： 球隊資料檔 team.dat 第 6 欄 team_artid，值是 1 到 126 的連號。

26 支球隊有自己的隊呼

把 26 個 tchants:NN 對回球隊：

beat_backs   beat_la   larry   mvp   overrated   rally_monkey   tomahawk

只有兩座球場有專屬音效，而且是火車跟飛機

stadium\std_spec.txt 整份只有兩個群組、九個音檔：

全遊戲 87 個球場封裝檔（58 座場地），只有這兩座有自己的環境音效， 而且內容是一列火車跟四種飛機（連機型都分開錄：727、737、777、還有一種客機）。

兩個資料庫打開就是 Excel 表

站上原本把 crowddb 與 speechdb 標成「未確認」， 理由是「只有一個 .big」。 把它們打開之後，裡面完全沒有加密也沒有壓縮，就是純文字 CSV。

群眾在什麼情況下發出什麼聲音，是一張表

crowddb\audiocsv.big 裡有 21 個 CSV、合計 1,478 條規則， 一個檔對應一種場上事件：

另外 9 個：chants（40）、landfoul（48）、 swngstko（52）、lkstriko（52）、newbater（32）、 landfair（24）、htbypich（16）、steal（16）、 heckgen（9）。

拿全壘打那個檔來看，一行是這樣：

homerun.csv 的表頭與兩行
team_at_bat,runs_scored_play,game_state,crowd1_reaction,crowd1_percent,and_or,crowd2_reaction,crowd2_percent
away,1,earlyclose,oh_medium,100,and,none,0
away,1,lateclose,oh_high,100,and,angry,100

兩行的差別只有一欄：比賽進行到哪個階段。 客隊在比賽前段打出帶一分打點的全壘打，主場觀眾發出中等的「喔——」； 同一件事發生在後段的接近比賽，觀眾就變成 高強度的「喔——」加上憤怒，兩種都 100%。

播報員那邊還多一層：EA 自己給台詞打分數

speechdb\speechdb.big 裡有 12 個 CSV、合計 1,568 筆： 204 個事件類別、166 條限制條件、8 種計數器、64 個觸發時機、76 個虛擬事件， 以及六張把它們串起來的對照表。

其中最短的那個檔只有 7 行，卻是整批資料裡最有人味的一份 —— 它是「這句話放在這個情境有多合適」的評分標準：

ContextualEventRatings.csv(EA 自己寫的分類名稱)
 100.00   Perfection
  10.00   Correct but jarring/random
   2.00   Partial coverage
   1.00   Bad samples
   0.00   Just plain wrong
  -1.00   Might get us sued
-1000.00  If we play this everyone will die

事件表自己會驗算

八個分區各有一個 events.evt。它是二進位檔，但結構單純， 而且自己帶著一道驗算 —— 算得對就代表你讀對了。

事件表起點 + 筆數 × 32 = 名稱表的起點
名稱表切出來的字串數   = 筆數

分區編號 0 到 7，一個不缺，順序跟上面那張分區表對得起來。

那 9 個 .asf 不是 ASF

選單音樂的副檔名是 .asf，看起來就是微軟的 Advanced Systems Format。不是。

微軟 ASF 的檔案開頭四個位元組是 30 26 B2 75。 實際打開這 9 個檔：

menu1.asf   53 43 48 6c   SCHl
menu2.asf   53 43 48 6c   SCHl
   ...(9 個全部一樣)

SCHl 就是這一頁前面講過的 EA 自家音訊容器。 換句話說，選單音樂跟主播語音用的是同一種容器，只是副檔名不同。

xxd -l 4 "…\data\audio\cd\music\menu1.asf"

想換聲音的話

完整的可改／不可改分級見 什麼改得動、什麼還不行。

⚠️ 本站 2026-08-28 訂正：換播報語音做得到

📌 重點整理

• 一句話 音訊這一區比整個遊戲其他部分加起來還大，它的索引是純文字、可以自己加總驗算，而這裡的副檔名一再騙人。
• 規模與那道免費驗算 13 個分區、111 個檔、736.9 MB，其中 729 MB 集中在 cd/，最大的單一檔是 212 MB 的主播語音。.off 索引是純文字，把裡面所有「長度」加起來會剛好等於對應資料檔的大小，本站算過的 16 個全部相符，一個 byte 都不差。events.evt 也自帶一道驗算，八個檔零例外。
• 最容易誤讀的：看副檔名 data/audio/ 底下 28 個 .big，真正是 BIGF 封裝檔的只有 12 個（8 個是 SCHl 音訊容器、8 個 *hdr.big 開頭四碼沒有兩個一樣）。看到 .big 就套 BIGF 解析器，28 個裡會有 16 個當場失敗。9 個選單音樂的 .asf 也不是微軟 ASF，兩份剛安裝好的原版量下來都是 9 個全部 SCHl。判準是開頭四個位元組。
• 名稱跟聲音不是一對一 主播那一區有 23,013 條名稱（18,492 個不重複），卻只有 2,056 個資料段，只用到 5,704 個不重複的位置值。不能假設「第 N 個名稱對應第 N 段聲音」。
• 本站訂正一：方向整個寫反了 原本寫「觀眾的音檔比噓聲大二十倍」，那是拿索引在比。真正的聲音在 .ast 裡，論聲音是噓聲大 2.7 倍、論索引才是觀眾大 7.7 倍。更糟的是本站當時還替它編了一個「觀眾聲要一直播」的解釋，讓錯誤看起來更可信。
• 本站訂正二：「未解」貼錯了層次 換播報語音原本標成做不到，理由是「SCHl 內部編碼未解」。實際上要換語音需要的是產生一個遊戲吃得下去的檔，不是把 EA 錄的解碼出來；社群語音包用的是 GSTR 子格式而遊戲照吃。同一輪也把 batdit 從「小遊戲音效」那一列搬出來，它是打者上場音樂，原本的三份證據只證了 batmini 與 ptcmini 兩個檔名。
• 順手撿到的 speechdb 裡跟著遊戲出貨的是一張 EA 內部評分表，最低兩級寫著 Might get us sued（−1 分）與 If we play this everyone will die（−1000 分）。另外全遊戲 87 個球場封裝檔（58 座場地）只有兩座有專屬環境音效，內容是一列火車跟四種飛機；EA 錄了 57 組球員專屬應援曲（剛安裝好的英文版原版、剛安裝好的中文版原版、本站測試機三份 spch_cht.txt 都是 57 組，號碼集合完全相同），其中 56 組在兩份原版的名冊裡對得到球員、13 位是傳奇球員，剩下的 pchants:0538 指向沒有人使用的編號；編號本身就把兩群人分開了。
• 本站沒驗的 應援曲 lg／md 兩種版本差在哪、檔名裡的 typ1／gen1 各代表什麼、七個有名字的應援分別屬於哪一隊、pchants:0538 為什麼指向一個沒人使用的編號、那兩座球場為什麼是它們、events.evt 每筆 32 個位元組裡的欄位意義、18 個 .abk 裡沒有同名 .ast 的那 7 個聲音放在哪，全部未解。群眾反應那張機率表改了會怎樣，本站沒有實機驗證。（「15 個位元組還原成 28 個取樣」的公式原本也列在這一條裡，2026-08-29 已經解開 —— 對照 ffmpeg 驗過 21,678,328 個取樣 0 個不同，見上面〈整條路每一段的狀態〉那張表。）

接下來

• 遊戲檔案地圖 —— 音訊只是 224 個封裝檔的其中一區
• 五秒看穿一個檔案 —— 自己動手確認那 28 個 .big 其實有三種格式
• BIGF 封裝格式 —— 那 12 個真的是封裝檔的長什麼樣