简介Telltale-Speech-Extractor 是一款面向游戏音频提取爱好者与逆向分析人员的开源工具基于 Pascal 语言开发版本 1.4.2由 Bennyboy 维护。它能够从 Telltale Games 引擎制作的游戏中提取语音与音效资源并兼容 Skunkape Games 的《Sam Max Save the World》等第三方作品新增对《行尸走肉权威系列》的支持同时修复了自《蝙蝠侠》第一季以来游戏的自动检测路径问题。资源包共 53 个文件约 1.03MB以 pas 与 dfm 源码单元、dpr 工程文件为主辅以 dll 音频解码库、mp3 示例、pdf 文档与 html 说明结构完整便于二次编译与功能扩展。用户只需指定游戏目录即可自动定位音频文件支持试听、按需保存为 WAV 或 OGG 格式。目前已有 209 人学习下载适合希望研究 Telltale 资源打包机制、批量导出游戏语音或进行音频素材整理的开发者参考使用。1. 从游戏资源包里捞出音频Telltale-Speech-Extractor 能解决什么如果你拆过 Telltale 系游戏的安装目录大概率见过那种一堆.ttarch后缀的资源包。想从里面单独把对白、音效拎出来手动改后缀、拿十六进制编辑器翻基本是自虐。Telltale-Speech-Extractor 就是冲着这个场景来的它用 Pascal 写成专门解析 Telltale 自家打包格式把语音和 sfx 从资源包里提取成可播放的音频文件。适合两类人——做游戏音频逆向的从业者以及想拿原版对白做二次剪辑、字幕对齐、语音分析的开发者。它不依赖游戏运行直接对文件下手所以离线也能跑。下面按“它怎么解析、怎么编译、怎么用、坑在哪”一路拆下去。2. 拆开 .ttarch 之前Telltale 资源包的格式逻辑与工具选型2.1 为什么是 Pascal而不是 Python 或 C#Telltale 的资源打包格式并不复杂但它的索引结构是分块存储的每个块有自己的偏移表和压缩标记。用 Pascal 写这类二进制解析工具有个现实好处Delphi/Free Pascal 对内存块和字节对齐的控制比脚本语言直接读TFileStream时不用像 Python 那样反复struct.unpack拼字段。另一个原因是历史惯性——早期做 Telltale 工具链的那批人很多是从 Delphi 时代过来的Pascal 代码在逆向圈子里有现成的二进制处理库可以复用。从选型角度看如果你只是临时提几个文件Python 写个脚本确实更快但如果你要批量处理几十个.ttarch还要处理不同游戏版本的格式差异Pascal 编译出来的单文件可执行程序在分发和运行环境上更省事。Telltale-Speech-Extractor 走的就是这条路编译一次拿到 exe 就能在 Windows 上直接跑不需要装运行时。2.2 .ttarch 里到底存了什么Telltale 的游戏资源包通常包含几类东西纹理、脚本、音频、字体。音频部分又分两种——预加载的短音效和流式加载的长对白。.ttarch文件本身是一个容器头部有魔数标识后面跟着块索引。每个块记录了自己的压缩方式常见的是 zlib 或自定义的 LZ 变体、未压缩大小和在文件中的偏移。提取工具要做的第一件事就是读头部、验证魔数、定位索引表。索引表里每一项对应一个资源条目条目里有资源名、类型标记、块偏移和大小。音频资源的类型标记和纹理不同工具靠这个标记来筛选。这里有个容易翻车的地方不同游戏版本的索引表项长度可能不一样有的版本会在条目末尾多几个字节的填充。如果工具写死了条目长度遇到新版本就会读串位表现是提取出来的文件全是乱码或者直接崩溃。2.3 提取流程的四个阶段整个提取过程可以拆成四步读容器头验证文件是不是合法的.ttarch拿到索引表的偏移和条目数。遍历索引逐条读资源条目按类型标记过滤出音频资源。解块根据条目的压缩标记把对应块解压到内存。如果是未压缩块直接按偏移和大小读原始字节。写文件把解压后的音频数据写成独立文件扩展名根据音频编码来定——Telltale 常用的是.fsbFMOD 样本库或者裸的.wav头。这四步里第三步最容易出问题。有些块的压缩标记是“继承前一块”的意思意思是它和上一个块用同一种压缩方式但工具如果没维护状态就会用错解压算法。常见做法是维护一个lastCompression变量遇到继承标记就沿用上一次的值。提示如果你拿到的.ttarch是加密的这个工具处理不了。Telltale 后期有些游戏对索引表做了异或混淆需要先解密再喂给提取器。3. 把 Pascal 源码跑起来编译环境、依赖与第一个提取命令3.1 编译环境怎么搭Telltale-Speech-Extractor 的源码是 Pascal通常用 Free Pascal CompilerFPC或者 Delphi 编译。在 Windows 上最省事的路径是装 Lazarus——它自带 FPC 和一套 IDE不用单独配环境变量。如果你习惯命令行也可以直接下 FPC 的 Windows 安装包装完把fpc加到 PATH 里。Linux 和 macOS 下用包管理器装 FPC 就行# Debian/Ubuntu 系 sudo apt update sudo apt install fpc # macOS 用 Homebrew brew install fpc装完之后验证一下版本fpc -iV输出应该是类似3.2.2的版本号。如果提示找不到命令说明 PATH 没配好手动把 FPC 的 bin 目录加进去。3.2 从源码到可执行文件假设你已经把源码包解压到了telltale-extractor/目录里面有一个主程序文件常见命名是extractor.pas或main.pas和若干单元文件。编译命令# 进入源码目录 cd telltale-extractor # 用 FPC 编译主程序-O2 开优化-o 指定输出文件名 fpc -O2 -oextractor extractor.pas编译过程中如果报 “unit not found”说明某个依赖单元不在搜索路径里。FPC 默认会在当前目录和标准库路径找单元如果源码把单元放在子目录比如units/需要加-Fu参数fpc -O2 -Fusrc -Fuunits -oextractor extractor.pas编译成功后当前目录会出现extractorLinux/macOS或extractor.exeWindows。这个文件不依赖外部 DLL可以直接拷到别的机器上用。3.3 第一次提取命令参数与输出结构工具的基本用法是给它一个.ttarch文件和一个输出目录。不同版本的参数名可能略有差异常见形式是# 基本用法指定输入文件和输出目录 ./extractor -i game_data.ttarch -o ./output # 只看资源列表不实际提取 ./extractor -i game_data.ttarch -l # 只提取音频类型跳过纹理和脚本 ./extractor -i game_data.ttarch -o ./output -t audio参数说明-i输入.ttarch文件路径支持相对路径和绝对路径。-o输出目录不存在会自动创建。-l列表模式只打印资源名和类型不写文件。用来确认包里有没有你要的音频。-t类型过滤audio只提音频all提全部。不指定时默认提全部。跑完之后输出目录里会出现按资源名命名的文件。如果原始资源名是哈希值工具可能会用序号代替。音频文件通常是.fsb格式需要再用 FMOD 的fsbext或者vgmstream转成.wav才能直接播放。注意如果提取出来的.fsb文件大小是 0 字节大概率是索引表解析错了。先跑-l看列表能不能正常打印如果列表就是乱的说明这个.ttarch的版本和工具不匹配。4. 避坑与排查提取失败、文件损坏、版本不匹配的五个血泪经验4.1 现象工具直接崩溃没有任何输出原因.ttarch文件头部的魔数不匹配。Telltale 在不同时期用过不同的魔数有些是TTARCH有些是TTA加版本号。工具如果只认一种遇到另一种就会在读取阶段抛异常。解决用十六进制编辑器打开文件看前 8 个字节是什么。如果是TTA开头尝试找支持该版本的提取器分支或者手动改工具源码里的魔数判断逻辑。改完之后重新编译。4.2 现象列表能打印但提取出来的音频全是噪音原因解压算法用错了。Telltale 的块压缩有 zlib、LZ 变体和“无压缩”三种标记。如果工具把 LZ 块当成 zlib 解出来的字节流虽然长度对但内容完全是乱的听起来就是白噪音。解决先确认块的压缩标记。在列表模式下加一个调试开关如果工具支持打印每个块的压缩类型。常见做法是手动改源码在解压函数入口加一行日志把compressionType打出来。对照已知的标记表0通常是无压缩1是 zlib2是 LZ。如果标记是2但代码走的是 zlib 分支改过来重新编译。4.3 现象提取到一半报“磁盘空间不足”但硬盘明明有空间原因索引表里某个资源的大小字段被读成了负数或者超大值。这在 32 位程序里常见——文件偏移超过 2GB 时有符号整数溢出变成负数。工具如果没做无符号转换就会试图写一个巨大的文件。解决把工具编译成 64 位版本。FPC 加-Px86_64参数fpc -Px86_64 -O2 -oextractor64 extractor.pas如果源码里用了 32 位专用的类型比如LongInt存偏移需要改成Int64。改的时候注意所有涉及文件偏移和大小的地方都要统一。4.4 现象提取出来的文件数量对但文件名全是乱码原因资源名在索引表里是定长字符串但不同版本的编码不一样。早期用 ASCII后期用 UTF-8 或者带长度前缀的变长字符串。工具如果按固定长度读遇到变长字符串就会把后面的二进制数据也当成名字的一部分。解决看索引表项的结构定义。如果名字字段前面有一个字节的长度标记说明是变长字符串要先读长度再读对应字节数。如果名字是哈希值常见于后期游戏那本来就没有可读名字工具用序号命名是正常行为不用修。4.5 现象在 Windows 上编译报“找不到 Windows 单元”原因FPC 在 Linux 上默认不包含 Windows 相关的单元比如Windows、Messages。如果源码里用了这些单元做文件对话框或者路径处理跨平台编译就会失败。解决两个选择。一是装 FPC 的交叉编译包在 Linux 上编译 Windows 目标# 装交叉编译工具链 sudo apt install fpc-source fpc-cross-win64 # 编译 Windows 64 位版本 fpc -Twin64 -Px86_64 -O2 -oextractor.exe extractor.pas二是把源码里平台相关的部分用条件编译隔开{$IFDEF WINDOWS}包住 Windows 专用代码{$ELSE}里写 Linux/macOS 的替代实现。后者改动量大但一劳永逸。5. 进阶批量处理、格式转换与验证提取完整性的技巧5.1 批量提取多个 .ttarch游戏目录里通常有几十个.ttarch一个个跑太慢。写个 shell 循环#!/bin/bash # 批量提取当前目录下所有 .ttarch 到各自子目录 for f in *.ttarch; do dir${f%.ttarch}_output mkdir -p $dir ./extractor -i $f -o $dir -t audio echo done: $f - $dir done这个脚本的逻辑很简单遍历当前目录的.ttarch文件为每个文件建一个以原文件名命名的输出目录然后调用提取器只提音频。${f%.ttarch}是 bash 的字符串截取把后缀去掉。跑之前确认提取器在当前目录或者 PATH 里。5.2 把 .fsb 转成可编辑的 .wav提取出来的.fsb是 FMOD 的样本库格式很多音频编辑器不认。用vgmstream或者fsbext转# 用 vgmstream-cli 转换单个文件 vgmstream-cli -o output.wav input.fsb # 批量转换 for f in *.fsb; do vgmstream-cli -o ${f%.fsb}.wav $f donevgmstream-cli的-o指定输出文件名不指定的话默认输出到标准输出。批量转换时注意文件名冲突——如果两个.fsb去掉后缀后同名会互相覆盖。稳妥做法是保留原目录结构或者用序号前缀。5.3 验证提取完整性对比文件数量和总大小提取完之后怎么知道有没有漏两个指标文件数量和总字节数。在列表模式下工具会打印资源总数和音频资源数。提取完之后统计输出目录# 统计输出目录的文件数和总大小 find ./output -type f | wc -l du -sh ./output把文件数和列表模式下的音频资源数对比。如果少了说明有些块解压失败被跳过了。再看总大小——如果和列表模式打印的“音频总字节数”差太多同样说明有问题。常见做法是在提取器的源码里加一个计数器每成功写一个文件就累加最后打印“成功/总数”。如果工具本身没这个功能就靠外部脚本对比。提示有些音频资源在索引表里标记为“流式”意思是它不在.ttarch里完整存储而是分片存在多个块中。这种资源提取出来可能只有第一片需要工具支持流式重组。如果发现某个对白文件特别短大概率就是这种情况。5.4 一个容易被忽略的细节输出目录的路径分隔符在 Windows 上编译的提取器如果源码里硬编码了\作为路径分隔符拿到 Linux 上跑或者反过来就会出问题。FPC 提供了PathDelim常量会自动适配当前平台。如果你要改源码把所有硬编码的\和/换成PathDelim。这个改动很小但能省掉很多“文件写到了奇怪的地方”的排查时间。从那以后我每次拿到新的.ttarch都先跑一遍-l确认列表正常再小批量提几个文件试听最后才全量跑。这个习惯帮我省掉了至少三次“提了 20GB 全是噪音”的后悔药。希望帮到你。本文还有配套的精品资源点击获取
