模拟器整合包瘦身：删除ROM仅留封面视频，打造纯浏览游戏媒体库

模拟器玩家应该都有过这种时刻：下载了一个几十上百 G 的整合包，解压完成，打开前端，翻着封面找游戏。半小时过去了，游戏还没选好；一小时过去了，你可能已经忘了最开始想玩哪一款。说得夸张一点，很多人面对庞大游戏库时的真实行为，其实是“查资料”而不是“打游戏”。

最近看到有人分享一种“更极端”的做法：把天马整合包里的 ROM 全部删掉，只保留封面、简介和预览视频。删完之后，整个包的体积从常见的几百 G 缩到了 50G 左右。这个版本的定位非常明确：打开前端，像逛博物馆一样浏览游戏库。

很多人第一反应是“没有 ROM 的游戏包不就是空壳吗”，但换个角度想，它其实解决了一个非常真实的需求——如果你的主要体验是“浏览”而不是“运行”，ROM 反而是体积占比最高、但对浏览体验没有直接贡献的部分。这篇文章想展开聊聊这个思路：天马前端到底由什么组成，为什么可以这样精简，具体怎么操作，操作过程中又有哪些坑需要避开。

1. 为什么有人要“删掉 ROM”，只留封面简介视频

1.1 整合包的体积大头，几乎都被 ROM 占据

先回到一个基本事实：多机种模拟器整合包的体积之所以动辄几百个 G，最重要的原因不是前端、主题、封面视频做得多精细，而是里面塞了大量 ROM。

ROM 是游戏本体的数据文件，可能是卡带导出的.nes、.sfc、.gba，也可能是光盘镜像.iso、.bin/.cue，还可能是压缩后的.zip、.7z。不同的游戏对应的体积差异很大，FC 游戏可能只有几百 KB，PS1 游戏却可能达到几百 MB 甚至 1G 以上。一个“全机种”整合包，ROM 总体积可以轻松超过封面、视频、简介等所有资源的总和。

所以当有人提出“删掉 ROM，只保留媒体资源”的时候，实际上是把整合包里最占空间的“功能层”去掉了，留下的是用于“展示”的资源层。这也是为什么一个完整整合包可以精简到 50G 左右——视频预览仍然占了一部分，但 ROM 的主要重量被移除了。

1.2 “只看不玩”为什么是一种真实需求

有人会觉得，模拟器不玩游戏还有什么意义？但在实际使用中，“只看不玩”的用户量可能比想象中多，场景大致可以分成几类。

第一类是怀旧考古型玩家。他们下载整合包，不是为了通关某个 RPG，而是为了翻一翻童年见过的封面，看看某台主机上到底出过哪些游戏，读一读简介，唤起记忆。对他们来说，游戏库更像是一本“互动式电子图鉴”。

第二类是内容创作者。做怀旧游戏视频、直播封面、科普稿件时，需要快速查询游戏封面、发行年份和背景资料。与其去各大网站逐个搜索，不如本地维护一份带封面、视频、简介的媒体库，效率高得多。

第三类是收藏整理型玩家。他们享受的是“拥有一套结构清晰的游戏资料库”本身，而不是某一次开机运行。这类玩家往往对目录结构、命名规范、主题展示有超出常人的执着。

还有一种很现实的情况：很多玩家下载了完整整合包之后，真正“点亮并运行”游戏的时间其实很少。预览视频和封面反而成了主要消费内容。既然这样，体积冗余的 ROM 自然就变成了可以优化的对象。

1.3 这个减法为什么合理

从架构上看，前端展示和游戏运行本来就是两套解耦的链路。前端负责读取配置，生成游戏列表，展示封面、简介和视频；模拟器核心负责接收 ROM 路径，加载游戏数据并运行。两者之间只有一个开关连接，就是“用户点击了运行按钮”。

如果用户只使用浏览功能，那么 ROM 文件是否存在，实际上不影响前端构建列表、加载封面和播放预览视频。这和视频网站的逻辑很像：播放器负责播放视频，封面图负责引导点击，封面图所在服务器有没有存原片，并不影响你看到那张图。

因此，“删掉 ROM 只留媒体资源”不是把工具弄残，而是把用户不需要的那一部分去掉，换来更小的体积、更快的扫描速度、更低的磁盘占用和更轻松的拷贝体验。

2. 天马前端的基本概念与整合包目录结构

2.1 天马前端不是模拟器，而是“模拟器前端”

很多刚接触的玩家会把“天马”理解成一个模拟器，其实更容易理解的说法是：天马是一个高度定制过的“模拟器前端”。

它的底层通常基于 Pegasus 前端，作用是做游戏列表展示、主题界面、封面墙和游戏元数据管理。而真正执行游戏的是 RetroArch 或者各种独立模拟器核心。也就是说，天马解决的是“游戏怎么被漂亮地展示出来”，而不是“游戏格式怎么被解析”。

这也是为什么删除 ROM 不会导致前端崩掉：前端的可执行程序、主题资源、配置文件和媒体资源都还在，唯一缺失的只是某些游戏条目里“file”字段指向的 ROM 文件。列表仍然可以显示，封面仍然可以加载，视频仍然可以播放。

2.2 整合包里通常包含哪些成分

不同版本的整合包结构会有差异，但大致可以分成下面几类资源。

从表格能看出，如果你只保留“浏览能力”，前端主程序、配置、封面、简介、视频是必须项，ROM 和模拟器核心都不是必须项。这也解释了为什么精简后的包体可以变得很小。

2.3 删除 ROM 后前端会怎样

删除 ROM 后，前端在启动和扫描阶段的行为通常不会发生变化，因为前端扫描的是配置文件和媒体资源，不会强制校验每个file字段指向的 ROM 是否存在。

但在点击“启动游戏”时，结果会因前端的实现而不同。有的前端会直接报错“文件不存在”；有的前端会根据file字段尝试执行模拟器核心，发现 ROM 缺失后返回错误。这不是前端坏了，而是已经没有可运行的游戏本体，属于预期行为。

如果你连模拟器核心也一起删掉了，点击运行按钮时会提示无法找到可用的核心。如果你计划保留“偶尔补一个想玩的 ROM”的能力，建议在精简时把常用机种的模拟器核心也保留，体积代价并不大。

3. 动手前先想清楚：合法性、备份和目的

3.1 版权不是小事，合法边界必须明确

必须提醒的是，很多商业游戏 ROM 仍然受到版权保护。虽然玩家圈子里长期存在 ROM 分享和整合包传播的现象，但从法律规定和平台规则来看，未经授权传播商业游戏 ROM 存在明显的侵权风险。

这篇文章讨论的“删除 ROM 并整理媒体库”，更适合处理下面几类内容：你自己拥有实体卡带或光盘，并做了合法备份的游戏；已经获得授权或明确允许自由使用的游戏；开源、免费或进入公有领域的作品。

如果你是拿别人的整合包做二次加工，建议只保留媒体资源，不要继续传播其中的商业 ROM 文件。精简后的“媒体库版”虽然不含 ROM，但如果里面包含受版权保护的封面图、视频和简介文案，同样不建议在公开渠道随意分享。技术整理是一回事，分发传播是另一回事。

3.2 先完整备份，再考虑删除

无论你的目标是从几百 G 精简到 50G，还是只清理个别机种，第一步都应该是备份，而不是急着删。

备份的目标不是整个几百 G 的包全部复制一份，而是保留“不可再获得”的部分：

• 原始metadata.pegasus.txt或前端数据库配置；
• 主题文件和自定义配置；
• 媒体资源目录（封面、视频、简介）。

如果担心误删，最简单的做法是把所有 ROM 移动到一个专门的外部备份目录，而不是直接Delete。确认前端媒体库显示正常后，再决定是否永久删除。

3.3 明确精简后的定位

动手之前，先问自己一个问题：精简后的包到底用来做什么？

定位 A：纯媒体库，只浏览，不运行。这种定位下，你甚至可以把模拟器核心也删掉，只保留前端主程序、主题、封面、简介和视频。省下来的空间最多。

定位 B：媒体展示加少量核心。保留 Pegasus 前端、RetroArch 和个别常用模拟器核心，遇到特别想玩的游戏，再单独补充一个 ROM 文件。这种定位需要保留部分模拟器核心，但依然可以从全量包中大幅瘦身。

两种定位不同，清理清单也不同。最怕的是“既想浏览，又想保留所有运行能力”，那还不如直接用完整整合包，精简的意义就没了。

4. 核心流程拆解：如何把整合包变成媒体库

4.1 确认原始包结构和关键配置

不同天马整合包的目录结构不完全一样，但通常都会有类似下面的顶层目录：

tianma/ ├─ metadata/ ├─ roms/ ├─ media/ ├─ system/ ├─ themes/ └─ pegasus-frontend.exe

其中roms是 ROM 所在目录，media通常存放封面和视频，metadata或根目录下的文本文件负责记录游戏列表。第一步不是写清理脚本，而是先花 10 分钟看结构，明确“哪些目录可以整体忽略”“哪些目录是媒体库核心”。

判断方法很简单：打开目录，看扩展名分布。.nes、.sfc、.zip、.iso密集的区域基本是 ROM；.jpg、.mp4、.txt密集的区域是媒体资源。

4.2 列出“删除清单”和“保留清单”

在正式操作前，建议把两类清单固化下来。删除清单通常包括：

• 所有 ROM 文件：.nes、.sfc、.smc、.gba、.gbc、.nds、.n64、.md、.iso、.bin、.cue、.chd；
• 存档或运行缓存目录（如果只是做媒体库，这些也用不上）；
• 可以不删但不使用的模拟器核心包。

保留清单通常包括：

• 前端可执行文件；
• 主题目录；
• 配置文件（.txt、.json、.xml、.db）；
• 封面图片目录；
• 预览视频目录；
• 简介文本目录。

如果不确定某个扩展名是 ROM 还是资源，先查一下目录名和配置文件里的引用路径，不要凭感觉删。

4.3 先移动，再删除

最安全的方式不是“删”，而是“移动”。把 ROM 移动到另一个磁盘分区或外部硬盘，等前端运行验证通过之后再清空备份。

这样做的最大好处是回滚成本极低。如果清理后发现某个机种的封面和视频还需要对应 ROM 作为文件存在性校验，你还能把它移回来，而不需要重新下载一个几百 G 的整合包。

4.4 检查 metadata 和媒体资源路径

ROM 删除之后，需要检查前端配置里的媒体路径是否正确。天马前端构建游戏列表时，会从metadata.pegasus.txt或对应的数据库配置里读取每个游戏的描述、封面路径、视频路径和file路径。

如果file路径失效，前端在“运行”维度会报错，但这不影响浏览。真正影响浏览的是封面路径和视频路径失效。如果移错目录，导致boxFront或video指向的位置不存在，封面和预览视频就会消失。

所以清理后，重点检查两类文件的相对路径是否还准确：一类是封面图片，一类是预览视频。如果整合包里的媒体路径全部是相对路径，移动整个目录时只要相对结构不变，就不需要改配置。

4.5 配置前端，关闭 ROM 存在性校验

部分前端版本在构建列表时会默认过滤掉file不存在的条目。如果你删了 ROM 后发现部分游戏直接从列表里消失了，大概率是遇到了这种配置。

不同整合包的菜单和配置项位置不同，但思路一致：找到“是否过滤缺失文件”或“只显示可运行的游戏”之类的开关，把它关掉。有的版本需要直接修改前端配置文件，把对应的过滤参数改成false。

如果你不想改配置，也有一个土办法：保留空目录占位。在roms目录下保留原路径结构，只是清空文件。这样前端仍然能通过目录扫描找到路径，只是没有实际文件，浏览功能不受影响。

5. 完整示例代码与配置

5.1 示例 1：PowerShell 脚本把 ROM 移动到备份盘

下面是一个适合在 Windows 环境使用的 PowerShell 脚本。它不会直接删除 ROM，而是按扩展名把文件移动到备份目录，便于回滚。

# 文件路径：move_roms.ps1 # 用法：建议先保持 $dryRun = $true 运行一次，确认没有误判后再改成 $false $targetRoot = "D:\tianma" $backupRoot = "E:\tianma_rom_backup" $dryRun = $true $romExtensions = @( ".nes", ".sfc", ".smc", ".md", ".gba", ".gbc", ".nds", ".n64", ".iso", ".bin", ".cue", ".chd", ".zip", ".7z" ) if (-not (Test-Path $targetRoot)) { Write-Host "目标目录不存在: $targetRoot" exit 1 } if (-not (Test-Path $backupRoot)) { New-Item -ItemType Directory -Path $backupRoot -Force | Out-Null } $movedCount = 0 foreach ($ext in $romExtensions) { Get-ChildItem -Path $targetRoot -Recurse -File | Where-Object { $_.Extension -and $_.Extension.ToLower() -eq $ext } | ForEach-Object { $relativePath = $_.FullName.Substring($targetRoot.Length).TrimStart('\') $dest = Join-Path $backupRoot $relativePath $destDir = Split-Path $dest -Parent if ($dryRun) { Write-Host "[DRY RUN] 将移动: $($_.FullName) -> $dest" } else { New-Item -ItemType Directory -Path $destDir -Force | Out-Null Move-Item -Path $_.FullName -Destination $dest -Force Write-Host "已移动: $($_.FullName)" } $movedCount++ } } Write-Host "共处理文件数: $movedCount" Write-Host "操作完成。"

这个脚本的核心是“先判断、后移动”。dryRun参数在技术上非常重要，因为.zip和.7z这种扩展名不一定只用于 ROM，有些主题或工具包也会用压缩包存放资源。建议第一次运行时严格保持$true，把输出日志保存下来，人工确认没有误伤资源文件后，再改成$false。

脚本里使用了Substring来保留原目录结构，这样如果后续想恢复 ROM，可以直接用Move-Item反向移回，不需要重新整理目录。

5.2 示例 2：Python 脚本分析整合包体积构成

在删除之前，先用 Python 统计各种扩展名的体积和数量，能让你知道“删什么最划算”。下面的脚本遍历目标目录，按扩展名统计文件数量和总大小。

# 文件路径：analyze_size.py import os from collections import defaultdict root = r"D:\tianma" # 只统计常见资源类型，避免扫描系统文件 interesting_exts = { ".nes", ".sfc", ".smc", ".md", ".gba", ".gbc", ".nds", ".n64", ".iso", ".bin", ".cue", ".chd", ".zip", ".7z", ".jpg", ".jpeg", ".png", ".webp", ".mp4", ".avi", ".txt", ".json" } size_map = defaultdict(int) count_map = defaultdict(int) for dirpath, dirnames, filenames in os.walk(root): for name in filenames: ext = os.path.splitext(name)[1].lower() if ext in interesting_exts: full_path = os.path.join(dirpath, name) try: size = os.path.getsize(full_path) except OSError: continue size_map[ext] += size count_map[ext] += 1 print("扩展名 数量 体积(GB)") print("-" * 40) for ext in sorted(size_map, key=size_map.get, reverse=True): gb = size_map[ext] / (1024 ** 3) print(f"{ext:8s} {count_map[ext]:6d} {gb:10.2f}")

运行结果会告诉你，这个整合包里 ROM 到底占多少、视频占多少、封面占多少。如果视频占 40G，封面只有 2G，那么精简到 50G 的结论就会很有说服力；如果发现某些版本的整合包视频本身就有 100G，那删掉 ROM 后的最终体积也不会是 50G，这个数字必须结合实际资源量判断。

这个脚本本身不删除任何文件，只是辅助决策，属于安全操作。缺点是如果整合包里文件数量非常多，遍历可能需要几十秒甚至几分钟，属于正常现象。

5.3 示例 3：检查封面和预览视频是否成对出现

删除 ROM 之后，最大的风险不是“游戏不能运行”，而是“封面和视频对不上”。下面脚本的目标是粗略检查：每个封面图文件，是否在相同目录下存在同名或相关名的视频文件。

# 文件路径：check_media.py import os from pathlib import Path root = Path(r"D:\tianma") video_exts = {".mp4", ".avi", ".mkv"} image_exts = {".jpg", ".jpeg", ".png", ".webp"} missing_videos = [] total_covers = 0 for dirpath, dirnames, filenames in os.walk(root): videos = {Path(f).stem for f in filenames if Path(f).suffix.lower() in video_exts} covers = [f for f in filenames if Path(f).suffix.lower() in image_exts] for cover in covers: total_covers += 1 stem = Path(cover).stem # 有些整合包会在视频名前加 extra 或 video 前缀，这里只做粗略判断 matched = any(stem in v or v in stem for v in videos) if not matched: missing_videos.append(os.path.join(dirpath, cover)) print(f"共检查封面 {total_covers} 个") print(f"可能缺少预览视频的封面 {len(missing_videos)} 个") for path in missing_videos[:30]: print(path)

这段脚本的价值在于“提前发现问题”。因为天马前端在列表页通常显示封面，在详情页才播放视频。如果封面存在但视频缺失，最直接的表现就是“进入详情页后视频黑屏或一直在加载”，这种问题如果靠肉眼逐个检查几千个游戏，效率极低。

脚本里的匹配规则是简化版，只判断文件名是否包含对方。不同整合包的命名规则不同，有的封面叫kof97.png，视频叫kof97.mp4；有的封面叫kof97.png，视频叫kof97.preview.mp4。如果你发现结果大量误报，可以调整匹配逻辑或写死前缀规则。

5.4 metadata 配置示例与修改建议

天马前端构建游戏列表时，依赖的是 Pegasus 前端格式的 metadata 文本文件。下面是一个简化的条目示例，字段名和书写习惯请以你实际使用的整合包为准。

# 文件路径：metadata.pegasus.txt（示例片段） collection: 拳皇系列 shortname: kof game: 拳皇97 file: ./roms/kof97.zip developer: SNK description: 经典 2D 格斗游戏，街机版本最受玩家关注。 boxFront: ./media/covers/kof97.jpg video: ./media/videos/kof97.mp4

如果删除 ROM 后前端列表仍然正常，则不需要改动这个文件。如果前端把file不存在的游戏过滤掉了，可以考虑把file改成空字符串或者注释掉该行，具体取决于前端版本对缺失字段的容忍度。

需要特别提醒的是，metadata 文件里的路径通常是相对路径，也就是说它们依赖目录结构。如果你在整理过程中移动了covers或videos目录，就必须同步修改这里的所有路径。否则真正精简完，重启前端之后很可能会发现封面大面积丢失。

6. 运行效果验证与常见问题排查

6.1 怎样算精简成功

把 ROM 移走之后，不要急着将它永久删除，先做一次完整验证。一个精简成功的媒体库版，应该满足下面的检查清单：

• 启动天马前端，能正常进入主题界面；
• 游戏列表仍然完整显示，没有被系统过滤掉；
• 每个游戏的封面图在列表中正常渲染；
• 点击游戏进入详情页，可以读到简介文字；
• 预览视频能正常加载和播放，没有大面积黑屏；
• 如果还保留了模拟器核心，点击运行时会被“找不到 ROM”的预期错误中断；
• 如果删掉了模拟器核心，点击运行时的错误提示也应该是“核心不存在”，而不是前端崩溃。

只要满足前五项，你的“只看不玩”媒体库就算做成了。最后两项是预期行为，不算是故障。

6.2 常见问题与排查方法

其中最高频的问题，实际上是“删完 ROM 后发现列表也消失了”。这往往不是因为前端坏了，而是因为它默认只展示“当前可运行”的游戏。在纯媒体库定位下，这个默认行为非常反直觉，必须先找到并关闭它。

如果你不确定过滤开关在哪里，最省事的做法是把metadata.pegasus.txt里的file字段全部改成一段不存在的占位文本，比如./roms/removed.txt，这样前端会认为文件确实存在，只是运行时才失败。不过这个做法会比较繁琐，不建议大包手动改，可以配合脚本处理。

7. 最佳实践与工程建议

7.1 目录规划比清理动作本身更重要

整理完一次之后，你会发现最影响后续使用感受的其实是目录规划。建议在动手前就建立一个干净的布局：

media_lib/ ├─ frontend/ # 前端主程序、主题、配置 ├─ media/ │ ├─ covers/ # 封面 │ ├─ videos/ # 预览视频 │ └─ descriptions/ # 简介文本 ├─ roms_backup/ # 被移走的 ROM 备份 └─ metadata/ # 游戏列表配置

一个清晰的目录结构，能让你在几个月后依然快速定位问题。反过来，如果你简单粗暴地把所有文件堆在一起，清理完之后哪怕只是一个小路径错误，排查成本也会很高。

7.2 先拿单机种试点，再批量清理

不建议一上来就全盘清理几百个 G 的整合包。正确做法是从单个机种入手，比如先处理“街机”或“GBA”目录，验证媒体库显示效果，确认视频、封面、简介都没有丢失，再扩展到其他机种。

这种小规模试点能让你在最早期就发现 metadata 路径规则，比如哪些字段是自己用的整合包实际需要的，哪些字段删了也没关系。把这些经验固化下来，后续处理其他机种时就可以用同一套流程复制。

7.3 统一压缩视频，可以进一步缩小体积

如果你的精简目标是“尽量小”，视频是第二大体积来源。很多整合包里的预览视频是 1080p 甚至更高码率，对“只看不玩”的用途来说，压缩到 720p、控制码率，通常已经足够在详情页里正常观看。

压缩视频可以用 HandBrake、FFmpeg 等工具。处理前先预览一段原视频的画质，找到不损害观看体验的压缩参数。视频压缩是一个有损操作，保存原始压缩配置后，也可以作为可选优化步骤，不一定非做不可。

7.4 用同步工具维护媒体库，而不是手动拷贝

精简后的媒体库只有几十 G，但如果后续要分享给朋友或拷贝到多台设备，建议使用支持增量同步的工具，例如 FreeFileSync、rsync 或网盘同步目录。

增量同步的好处是：第一次拷贝完整包，后续只同步变化的封面和视频，避免重复拷贝。特别是当你想“保留模拟器核心但不保留 ROM”这种半精简状态时，增量同步能保证多端结构一致。

7.5 安全与分享边界

强烈建议不要把你整理后的“媒体库版”再打包上传到公开网盘。即使里面没有 ROM，封面图、视频、简介数据库同样可能涉及版权。整理给自己用是技术行为，传播给陌生人就是另一回事了。

如果你需要和朋友共享，最好只在明确授权和合法范围内进行，或者只分享“整理方法”和“目录结构模板”，而不是整个资源包。

7.6 适合谁、不适合谁

这个方案最适合以下人群：

• 以怀旧浏览为主要需求，想快速看到“某平台有哪些游戏”；
• 需要在本地维护一套游戏资料库，为直播、文章、视频创作提供素材；
• 磁盘空间有限，但想保留整合包的展示体验；
• 喜欢整理和收藏，享受“一套结构完美的媒体库”的成就感。

不太适合的人群也很明显：真正想通关游戏、想研究模拟器核心兼容性、想用金手指或者即时存档深度体验的玩家，还是要用完整整合包。“只看不玩”是一个明确的取舍，它牺牲了运行能力，换来体积和浏览体验。

8. 总结：收藏的本质是筛选，不是囤积

一个“删掉了 ROM，只保留封面简介视频”的天马包，看起来违背了模拟器整合包的初衷，但换个角度想，它其实触及了收藏的本质：收藏不是把一切塞进硬盘，而是构建一个可以随时访问和浏览的信息空间。

从技术上看，这个方案并不复杂，核心只有三件事：识别 ROM 和媒体资源，把 ROM 移动出去，修正前端配置让它继续展示列表。真正容易出现问题的反而不是操作本身，而是对“前端负责展示、模拟器负责运行”这个架构的理解。理解了这一点，你就知道哪些文件必须保留，哪些文件可以大胆移走，哪些配置项需要在删完 ROM 后调整。

这篇文章提供的脚本和检查思路，可以直接用来处理你自己的整合包。建议收藏备用，但更重要的是在第一次清理时保持克制：先小范围试点，先移动而不是删除，先验证再继续。等你亲手把几百 G 的整合包整理成一个只有封面、简介和视频的清爽媒体库，再回头看它，可能会对“资源包”和“游戏库”有完全不同的理解。

下一步值得深入学习的方向是 Pegasus 前端的主题配置和元数据规范。如果你能自己修改卡片布局、背景视频和简介排版，那么“只看不玩”的媒体库体验会比默认整合包更加完整。到那时，你就不只是在使用别人的整合包，而是在搭建自己的游戏资料馆了。