简介arc_conv_r55是一款面向arc格式压缩包及其衍生封包的解包、转换与重建工具集尤其适合需要处理游戏资源包数据的开发者、逆向爱好者与技术维护人员能够有效解决此类封包无法直接读写与批量转换的问题。压缩包共415个文件、约2.38MB内容以330个asm汇编源码为绝对主体另有30个c源码与27个h头文件辅助编译并包含7个bat批处理脚本、7个inc包含文件以及少量exe、lib、dll成品程序从底层源码到可执行二进制一应俱全。工具集内含构建与清理脚本、文本编码转换模块、arc格式修改与打包组件并对xp3、cpz5等常见引擎封包做了针对性适配用户可自行编译后完成解包、打包、转码及清理全流程便于定制私有资源结构。已有4500余人学习下载适合游戏Mod制作者、资源提取爱好者及有批量封包处理需求的技术人员可作为同类工具二次开发的基础参考。1. arc_conv_r55 到底是什么为什么一个老日系命令行工具还在被反复下载上个月接了个老游戏的音频提取需求arc_conv_r55 这个名词从收藏夹里被翻出来一次跑通了别人折腾两天没解开的包。它本质上是面向 KiriKiri吉里吉里引擎游戏资源包 .arc/.nsa 的提取转码工具r55 是社区长期使用后公认顺手的一个版本能把包内成百上千个文件统一转成 OGG 或 WAV。如果你手里攒着一批老游戏音轨或者在做汉化音频替换、音效素材再整理这份资源的价值在于同一套命令行同时解决解包和转码而不是解包后还要拿另一套编码器二次处理。下面按实际使用顺序来写覆盖环境准备、单文件试转、批量脚本、排错和最终验证新手照着敲就能跑通熟手可以直接看参数表和坑记录。2. 开工前的环境准备目录规划、依赖检测和版本自检2.1 为什么解压即用比安装管理器更靠谱arc_conv 这类老日系工具链很少做安装程序通常是一个 exe 加一个 readme 打到压缩包里。我先说结论这不是作者偷懒反而更方便。工具本身不写注册表、不依赖服务拿到手放在任何目录都能跑换机器只要把整个工作目录拷走即可复现。代价是依赖判断得自己做最常缺的是老版 VC 运行库和某些解码 dll缺了之后不是报错而是“闪退”很容易让新手误以为是工具坏了。我自己习惯按下面这个目录结构放文件先确定好 in 和 out 两个目录再开始跑避免后面脚本在路径上翻车。这个结构很朴素但它能避开大多数老 Windows 工具的长路径和中日文编码问题。# 我惯用的工作目录结构路径层级浅且文件一律用英文名 ~/arc_work/ ├── arc_conv.exe # r55 本体从压缩包解出来单放 ├── in/ # 待处理的 arc 包文件不要用中文名 └── out/ # 输出目录批量脚本会按包名自动建子目录这里其实有两点考虑。第一arc_conv 运行时会以当前工作目录为基准寻找输入文件如果你在其它目录敲相对路径结果大概率是“窗口一闪而过”所以在 in 目录下跑最省心。第二输出目录统一收敛到 out方便后面脚本统计产物数量和做 ffprobe 校验。很多人在这一步图省事直接把输出丢到桌面等到批量跑几十个包之后目录结构一团乱后悔药都没有。2.2 运行环境自检先确认 exe 真的能正常退出在 Windows 下拿到工具包我建议先别急着拖 arc 文件进去先用命令行跑一次帮助信息确认程序能正常响应并返回退出码。这一步能提前暴露缺运行库、被杀软拦截这类问题。命令如下# Windows 下先跑一遍自检帮助信息会落在 selfcheck.txt arc_conv.exe --help selfcheck.txt 21 type selfcheck.txt echo exit code: %errorlevel%注意这里我把 exit code 打出来了。r55 这类命令行工具在正常无输入参数时会打印用法并返回非零退出码只要能看到日文或英文帮助文本且进程没有闪退就说明运行库没问题如果 type 出来是一片乱码或文件是空的再考虑补 VC 运行库。另外如果你在 Linux 或 macOS 上模拟运行常见的做法是走 wine命令变成 wine arc_conv.exe --help判断逻辑一样只是把 type 换成 cat。# 装了 wine 的 Linux/macOS 环境原理与 Windows 自检相同 wine arc_conv.exe --help selfcheck.txt 21 cat selfcheck.txt echo wine exit code: $?有个容易被忽略的小点杀毒软件对这类老工具的误报率不低。自检时如果 exit code 是 0 但 help 文件没生成多半是 exe 被隔离或静默拦截了此时去杀毒隔离区恢复即可跟工具本身没关系。我一般会在放行后再跑一次自检确认能正常输出才继续下一步。2.3 这份工具包常见内容与预期的输入输出格式r55 压缩包解压后内容一般比较精简我见过的大致是下面这几样。这个表格只列常见组成你拿到的包可能更少或更多不影响使用。文件作用是否需要关注arc_conv.exe主程序负责解包与转码核心文件readme.txt / 説明.txt日文用法与参数说明参数有疑问时查阅若干 dll解码或运行时依赖缺失时补全不要删除示例 arc 或 bat演示调用方式有帮助但不影响主流程工具能处理的输入主要是 KiriKiri 引擎的 .arc 容器以及部分变体格式。输出则取决于你的参数可以统一输出 OGG 或 WAV。我需要补充一句容易误会的说明arc 不是加密格式的统一代名词不同游戏用的引擎版本和压包设置不同同一个 r55 工具不可能覆盖全部变体。所以拿到包先跑一遍看输出而不是默认它一定能解开所有 KiriKiri 资源这是后续所有操作的前提。3. 命令行转换实战stop 模式、extract 模式与输出参数怎么设3.1 两种调用方式拖拽入坑 vs 命令行直转绝大多数人第一次接触 arc_conv 都是从“把 arc 文件拖到 exe 上”开始的。双击 exe 会弹出一个窗口把 arc 拖进去后它会列出包内文件并询问要做什么这种交互式方式适合单次操作、看看效果但不适合批量。我要重点讲的是命令行直转因为只有命令行才能进脚本一次跑完几十个包。命令行方式的最小可运行写法是这样的先给个最简命令# 最简调用把 in/sample.arc 里的音频全部转成 OGG 输出到 out/ arc_conv.exe --dest out/ --ogg in/sample.arc逐个拆解参数。--dest 指定输出目录工具会自动创建但层级过深或者带空格时容易出问题--ogg 表示目标格式为 OGG如果做后期处理建议改成 --wav最后一个参数是输入 arc 包的路径。需要说明的是不同版本、不同 fork 的参数名可能略有出入比如有的写法是 -o 而不是 --dest所以我拿到新版本的第一件事永远是先跑一次 --help确认参数名再进批量流程。这一步看着多余实际能省掉整批失败的返工。3.2 stop 模式全量转换前先截取一个条目做验证在批量转换之前最好先拿一个条目验证输出质量而不是直接整包全转。这就要用到 stop 模式它的作用是在处理完指定的条目后立刻停止不做全量遍历。我把它当作全量跑的探针。# stop 模式只转换包内第 3 个音频条目验证码率和时长 arc_conv.exe --dest out/ --ogg --stop 3 in/sample.arc这里的数字 3 是包内文件表的条目序号注意不同包的排序规则不一定按文件名而是按打包时的写入顺序。选这个号的意义在于先找一个样本用播放器试听确认码率、声道、时长都符合预期再上全量命令。我曾经跳过这一步直接全量转换结果一个包跑出来 20 多个体积正常但内容是静音的“哑弹”再排查浪费了大半天从此以后强制先探针后全量。3.3 输出参数怎么选OGG 码率、WAV 位深和采样率修正输出格式不是选得越高质量越好而是取决于你后续拿它做什么。我把实际中常用的一组参考参数列成了表方便直接抄作业。场景推荐输出码率/位深采样率说明最终交付/试听OGGq5 到 q10与原包一致体积适中兼容性好二次剪辑/混音WAV16bit 或 24bit尽量与原包一致避免有损迭代素材入库OGGq8 以上44.1k 或 48k 标准便于后续检索游戏内替换OGGq5 以下按需必须与原游戏一致防止引擎变调按这张表选参数时有个必须避免的误用盲目把 48k 的原始音频强制降到 44.1k重采样后会造成轻微音调偏移做游戏内替换时尤其明显。判断原包采样率的一个常见做法是先转换一个探针文件再用 ffprobe 探它的原始属性确认后再决定是不是要动重采样参数。如果你不确定保持默认输出通常是最安全的选择多数原包本身就是 44.1k 或 48k不需要额外干预。# 转换前先探一下某个输出文件的采样率与声道数 ffprobe -v error -select_streams a:0 \ -show_entries streamsample_rate,channels \ -of csvp0 out/probe.ogg乱调采样率带来的杂音和变调属于那种“出了问题第一时间想不到”的玄学问题所以我把这条单独拎出来。优先保持原包采样率是控制风险最直接的方式。4. 从 .arc 里按包批量提取音频映射表、伪装文件与批量转换脚本4.1 为什么不能直接对一整个目录用通配符处理批量处理最直观的想法是 for 循环套一遍把每个 arc 都走一次第 3 章的转换命令。但实际项目里很少能这么顺利原因有三个。第一arc 包的内部结构不统一有的包内音频是直接存储有的则带索引偏移第二不少游戏会把音频伪装成 png、txt 甚至乱扩展名直接按扩展名过滤会漏掉大量真实音频第三部分包带加密头不处理映射表就拿不到正确偏移转出来的文件全是坏块。所以我建议在批量之前先看一眼包内的文件映射表确认哪些条目值得转。下面这段 Python 逻辑不是让 arc_conv 去做解包而是拿它当参照快速获知包内条目的数量和名字形态再决定要不要全员转换。这其实是很多人忽略的一步但恰恰是它决定了批量是否值得跑。# 快速预览 arc 包打印包大小和头部信息示意 import pathlib def preview_arc(path: pathlib.Path): data path.read_bytes() print(f{path.name} 总大小: {len(data)} bytes) print(头部前16字节:, data[:16].hex( )) preview_arc(pathlib.Path(in/sample.arc))这段代码故意不写死偏移量原因很直接——arc 的头部布局在不同引擎版本间差别很大写死反而误导你。正确做法是先打开包文件看头部魔数再去对应引擎的结构定义里查字段。相比解析细节我更想强调这个习惯全量批量前先让脚本打印一次包内条目概况确认待处理对象确实包含预期的音频再进入转换环节。4.2 批量转换脚本一次跑完整个 in 目录并打日志确认映射表没问题后就可以上批量脚本了。我平时在 Windows 上跑的是 Python因为判断退出码、统计输出文件数量、写日志都比写批处理舒服。下面的脚本处理 in 目录下所有 arc每个包单独建输出子目录并逐一记录成功或失败。import subprocess, pathlib, sys ARC_TOOL pathlib.Path(rarc_conv.exe) PACK_DIR pathlib.Path(rin) OUT_DIR pathlib.Path(rout) packs sorted(PACK_DIR.glob(*.arc)) if not packs: print([INFO] in 目录下没有 arc 文件, filesys.stderr) sys.exit(0) for pack in packs: out OUT_DIR / pack.stem out.mkdir(parentsTrue, exist_okTrue) # 用日文代码页读取输出避免中文控制台解码报错中断 r subprocess.run( [str(ARC_TOOL), --dest, str(out), --ogg, str(pack)], capture_outputTrue, textTrue, encodingcp932, errorsreplace ) if r.returncode ! 0: print(f[FAIL] {pack.name} 非零退出: {r.stderr.strip()}) continue oggs list(out.glob(*.ogg)) print(f[ OK ] {pack.name} - {len(oggs)} 个 ogg)逐段解释。sorted(PACK_DIR.glob(*.arc)) 保证包的处理顺序稳定日志可复现out.mkdir(parentsTrue, exist_okTrue) 避免目录不存在时工具直接拒绝写入encodingcp932 是因为 arc_conv 的输出是日文编码在中文 Windows 控制台下如果没有这一行subprocess 解码会直接抛异常整个脚本中断在第一个报错上——这是我最想让你抄走的一行。判断成功与否只看 returncode不解析文本因为日文输出里出现“成功”字样的写法在不同版本里不一样解析文本很容易误判。脚本只会输出每个包转出的 OGG 数量方便你几分钟内判断哪些包产出异常。如果你要把脚本发给没有装 Python 的同事批处理版本更省事。逻辑一样只是把退出码判断搬到了 %errorlevel% 上。echo off setlocal enabledelayedexpansion for %%f in (in\*.arc) do ( arc_conv.exe --dest out\%%~nf --ogg %%f run.log 21 if !errorlevel! neq 0 ( echo [FAIL] %%f run.log ) else ( echo [ OK ] %%f run.log ) )批处理的坑在于路径中有空格时引号位置非常敏感%%~nf 展开的是不带扩展名的文件名正好拿来建子目录名。这个版本没有 Python 版的输出统计但胜在零依赖。两个版本选一个足够不用都跑。4.3 常见误用全量解出来的文件数量与预期对不上批量脚本跑完后第一件事是对数量。一个包转出多少音频文件应该和它在映射表里标为音频的条目数大致吻合。实际中你可能会遇到两类偏差这里先提前讲清。第一类是“转出的文件比预期多”通常是伪装文件也被当成了音频处理结果产物里混着一批没法播放的坏文件第二类是“转出的文件比预期少”通常是因为加密条目在读取时被跳过工具日志里会有相应提示。# 统计输出目录里 ogg 数量和总体积快速判断是否异常 find out -name *.ogg | wc -l du -sh out如果数量和体积明显异常先别急着删输出回头去看 run.log 里对应包的报错行。这一步能把 90% 的问题定位到具体包上。当年我在这上面交过学费把一整批“体积正常但内容静音”的文件交付出去对方反馈回来才发现源头在参数选择这就是典型的偷懒代价。5. 常见问题排查五个高频坑与修复路径5.1 把 arc 文件拖到 exe 上窗口一闪而过现象双击 arc_conv.exe把 arc 拖进窗口程序立刻退出没有任何输出文件。原因最常见的是输入路径或当前目录的编码问题老日文程序在中文系统下拿不到正确路径时会直接退出其次是缺运行库表现也是闪退。你很难从现象上直接区分是哪一种。解决先按第 2 章自检方式跑 arc_conv.exe --help确认本体能稳定输出帮助文本。然后改用命令行方式先 cd 到 arc_conv 所在目录再用绝对路径调用避免拖拽过程里路径转换出错。我一般会顺手在命令后加一条 pause让窗口停留住把报错信息留给自己看。5.2 转出来的 OGG 播放时长全部为 0 或严重爆音现象文件大小正常几百 KB 到几 MB但播放器里总时长显示 0 或者前几秒是刺耳爆音。原因多数情况下不是工具坏了而是原包内的音频并非标准 OGG 编码而是带私有头的压缩数据arc_conv 按常规流程转出来自然不对。另一个可能性是缺解码 dll解码出的数据是坏的但文件头仍被写出来。解决拿同一个 arc 先用 --wav 输出试听如果 WAV 正常说明问题出在 OGG 封装或 dll 上如果 WAV 也是杂音基本可以判断原包音频本身是特殊编码需要换对应引擎的解码器再处理。这个排查路径能省掉大量无用功因为目标格式一旦换错所有输出都白跑。5.3 中文 Windows 下交互窗口全是乱码现象双击工具后弹出的窗口和菜单全是乱码看不清任何提示不知道怎么选。原因r55 是日文环境开发的程序交互界面按 Shift-JIS 编码绘制在中文 Windows 上被按 GBK 解码自然全是乱码。命令行输出也一样只是我们通常只看退出码所以影响不大。解决不想改系统区域设置的话优先绕开交互窗口全部操作走命令行参数如果一定要用交互模式就右键 exe 属性里开“兼容性”并勾选以日文区域运行或者用区域模拟工具加载。注意改区域会改变整个进程的代码页可能影响其它软件跑完记得改回来。5.4 输出了一堆只有几百字节的空文件现象批量转完后输出目录里出现大量几百字节的小文件播放器打不开日志里也没有明确报错。原因这类文件多半是伪装文件或索引占位。游戏打包时会把图片、脚本、索引等非音频数据混进同一个 arcarc_conv 按文件名或偏移粗暴处理时就会产出这种空壳。还有一种情况是加密头未跳过导致读取偏移错误。解决回到第 4 章说的映射表预览先确认哪些条目标记为音频再决定是否全量转换。批量脚本跑出来的这些空文件可以直接删不用留恋因为它们不占多少空间但会干扰你统计真正的产出数量。5.5 同一个 arc 在别人旧版本能转换我的 r55 却转不了现象同事说某个 arc 能解你用同一份工具或同版本 r55 解出来却是乱码或报错。原因引擎版本差异是最常见的解释。KiriKiri 2 和 3 的 arc 结构不同r55 是被人验证过能稳定处理某几个引擎版本的版本但覆盖不了所有新引擎封包另外有的游戏在打包时启用了带 key 的加密索引工具没有对应 key 就会失败。解决先确认游戏引擎版本再找对应能力的工具链组合处理而不是死磕 r55。别指望一个版本通吃所有 arc 包这个认知能避免不少无效尝试。我现在的做法是写一个 README 记录每个包用什么版本和参数跑成功的下次遇到同类包直接照抄省掉重复试错的环节。6. 进阶验证确认你转出来的 OGG 不是“哑弹”的三个手段全量转完之后我最不放心的事情是文件数量对得上但内容是不是真的能播。数量对得上只能说明工具正常遍历了条目不能说明解码正确。所以我会用三个手段做最终验证给自己留一份“可交付”的证据。第一个手段是用 ffprobe 批量核对 OGG 的时长和码率。正常的游戏音频时长通常在几秒到几分钟之间码率固定在一个合理区间哑弹会同时出现时长为零或码率异常的特征。# 逐个 ogg 输出文件名、时长与码率异常值一眼可见 for f in out/*.ogg; do echo $f ffprobe -v error -show_entries formatduration,bit_rate \ -select_streams a:0 -of defaultnoprint_wrappers1 $f done第二个手段是用 sox 看响度统计。静音文件在文件头里被标记了正常时长但 RMS 振幅会无限接近零用耳朵听太慢交给 sox 一条命令就能扫完。输出里的 RMS amplitude 字段是重点关注对象。# 检查单个 ogg 的响度统计RMS amplitude 接近 0 说明内容实际是静音 sox out/01.ogg -n stat第三个手段是把输出文件数量与包内映射表做一次核对。第 4 章的批量脚本已经给出了数量拿它和历史记录里成功转换过的计数对比能发现漏转和重复转。这个动作不需要额外工具看 run.log 和 out 目录统计就够了。这三个手段加起来不到五分钟却能把“文件都在”变成“文件都能用”。早年在交付一批音轨前我跳过验证结果对方反馈时才发现静音文件混在里面重跑一遍批量浪费了半小时从那以后我每次拿到新 arc 包都强制走一遍先预览映射表再 stop 模式抽一个文件试听然后才是批量脚本最后用 ffprobe 与 sox 做属性核验。希望这些步骤帮你少走同样的弯路让 arc_conv_r55 成为你工具链里一个稳定可靠的老伙计。本文还有配套的精品资源点击获取