简介：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 2>&1 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 2>&1 cat selfcheck.txt echo "wine exit code: $?"

有个容易被忽略的小点：杀毒软件对这类老工具的误报率不低。自检时如果 exit code 是 0 但 help 文件没生成，多半是 exe 被隔离或静默拦截了，此时去杀毒隔离区恢复即可，跟工具本身没关系。我一般会在放行后再跑一次自检，确认能正常输出才继续下一步。

2.3 这份工具包常见内容与预期的输入输出格式

r55 压缩包解压后，内容一般比较精简，我见过的大致是下面这几样。这个表格只列常见组成，你拿到的包可能更少或更多，不影响使用。

工具能处理的输入，主要是 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 位深和采样率修正

输出格式不是选得越高质量越好，而是取决于你后续拿它做什么。我把实际中常用的一组参考参数列成了表，方便直接抄作业。

按这张表选参数时，有个必须避免的误用：盲目把 48k 的原始音频强制降到 44.1k，重采样后会造成轻微音调偏移，做游戏内替换时尤其明显。判断原包采样率的一个常见做法，是先转换一个探针文件，再用 ffprobe 探它的原始属性，确认后再决定是不是要动重采样参数。如果你不确定，保持默认输出通常是最安全的选择，多数原包本身就是 44.1k 或 48k，不需要额外干预。

# 转换前先探一下某个输出文件的采样率与声道数 ffprobe -v error -select_streams a:0 \ -show_entries stream=sample_rate,channels \ -of csv=p=0 "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(r"arc_conv.exe") PACK_DIR = pathlib.Path(r"in") OUT_DIR = pathlib.Path(r"out") packs = sorted(PACK_DIR.glob("*.arc")) if not packs: print("[INFO] in 目录下没有 arc 文件", file=sys.stderr) sys.exit(0) for pack in packs: out = OUT_DIR / pack.stem out.mkdir(parents=True, exist_ok=True) # 用日文代码页读取输出，避免中文控制台解码报错中断 r = subprocess.run( [str(ARC_TOOL), "--dest", str(out), "--ogg", str(pack)], capture_output=True, text=True, encoding="cp932", errors="replace" ) 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(parents=True, exist_ok=True) 避免目录不存在时工具直接拒绝写入；encoding="cp932" 是因为 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 2>&1 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 输出了一堆只有几百字节的空文件

现象：批量转完后输出目录里出现大量几百字节的小文件，播放器打不开，日志里也没有明确报错。

原因：这类文件多半是伪装文件或索引占位。游戏打包时会把图片、脚本、索引等非音频数据混进同一个 arc，arc_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 format=duration,bit_rate \ -select_streams a:0 -of default=noprint_wrappers=1 "$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 成为你工具链里一个稳定可靠的老伙计。

本文还有配套的精品资源，点击获取