RIX"格式"的部分研究与转码，逆向ROL+INS 或现代化为.fur 文件的部分结论。

[gtr3qq]

大佬您好！
感谢您对pal的付出以及sdlpal的重置！
我对rix文件进行了一些研究，想请您检查作业，可能的话想更多的和您交流一下，如果可能的话，找出更好方法来完成rix文件的逆向。
地址：https://tieba.baidu.com/p/7605051096

余在21时有浅显的对rix文件进行了研究，当时没写多少，而且对rix文件的认知也十分迷糊，弄出了用IDA 打开rix当x86汇编来"逆向"这种蜜汁操作。
不过也的确用穷举法鼓捣出分离出了其中的乐器文件和音高（midi）文件。
我就没期待有10人以上感兴趣。
不曾想，几年后，林坤信大佬来b站的时候偶然相中了余发的视频。问我是怎么做到的，并且想从一些rix文件中分离出他硬盘坏了丢失的rol ins 文件。

现在余对YM3812 和 IBM PC-AT ISA BUS 稍微有多了些认知。
综合起来又洛阳铲了这个帖子。
但在大佬面前，还是些许心虚的……有很多地方我可能没弄对，或者您有更好的方法来完成。
比如对rix结构的结论。

余主要的结论是不要管什么rix格式了，就叫他softstar 388h bit stream。
没有什么"乐器块"，"音乐块"，乐器相关的寄存器初始化只是刚好在rix文件头部。
而且有些时候，还会在曲子中间换乐器。
实际上其中就含了写给388h的"opl寄存器地址"和389h 写给 opl寄存器 的数据。 类似 imf wlf dro格式。
没必要尝试直接分离任何东西，而是通过分析playrix，来直接parse 到dro 这种 "国际上"通常的 YM3812 reg-dump。

但看playrix.asm 看得我头大不说，看起来rix文件还有什么CD 指令来控制loop point……
余对其内部微观结构也是一无所知，抛开之前那篇文件说什么偏移地址有“乐器块”，那些是写给388h的地址数据，那些写给389h的“opl寄存器数据”，有默认写入速度是多少？有曲目自定义写入/更新速度的控制符没？完全不知道。
噢，little endian 储存我认。

目前，主要是以下两个挑战
1，可否请您讲解一下playrix？
2，您可否看一下要怎么直接从rix parse 为 dro？
3，rix 的内部结构细节还是不太清晰。

cheers，
will

[palxex]

你好！不好意思看到得有点晚了。

非常惊讶也特别开心——到现在还有人愿意钻研这些“老家伙”，欢迎！

关于你提的几个问题，我稍作整理分享一下：

关于 playrix
其实个人感觉不用特意去看 playrix，derix 本身就是它的忠实重现。中断 ISR 的频率用的也是历史原值，对原版的还原度相当高。

不过说明一下：我并不是当年这块工作的原作者。某些细节，可能得向当初最早分析并转换为 C 的原作者 bspal 了解才行。遗憾的是，我自己也和他很久没联系上了。

drov1 格式输出
这点其实就很顺理成章了：

你可以把 derix.c 稍作调整（注意先不要看derix262，那个被其他维护者扩展了很多，短篇难尽，看他本人后续有没有兴趣参与讨论吧），尤其是中断处理部分，改成一次性跑完；接着按 drov1 格式写好文件头，再把 ad_bop 的部分从写寄存器改成依次写入寄存器和数值——就可以了。

事实上，AdPlug 的 rix player 初版就是靠这个思路从 dro player fork出来的。可以看看它当时的实现： adplug/adplug@69f9788

关于乐理和结构
这个可能帮不上太多忙……我本身对乐理和 chiptune 并不擅长，主要是负责技术与整合。

不过从代码层面讲，我个人不太认同“rix 就是 388 端口的字节袋子”这个比喻。dro倒是非常符合，但 rix 本身结构性是很强的：

文件头就明确存在音色区和指令区的偏移指针

指令区里还能看到明显的 9x、Ax、Bx、Cx 等几种指令

有些指令看得出是跟音乐层面直接相关的，比如 9x 是用来切换现成的 ins 音色用的。

只是说到每个指令的具体意义和用途……这我真的只能惭愧地说，有待后继高手继续挖掘了

最后再次欢迎哈！江湖之大，相逢便是有缘。

[gtr3qq]

话说... 如果 重构出 084.rol + 5个 ins 文件, 是否对逆向进度有所帮助呢?
我不太期待林大佬会释放这些源文件, 毕竟其都用其作为"身份证"了.

毕竟, 似乎 ROL > RIX 的工具链似乎是齐全的
...
我也许可以猜一下ROL文件中每个通道的Pitch Variation值..
其他的所有参数我都已经复原了.

[palxex]

关于问林老师的话.... 我不太觉得对于084中是否挂载了更多乐器而未使用是 "值得"叨扰的问题... (当然,林老师也时常在b站,也欢迎交流/骚扰😆...您不妨直接和其交流一下?)

有且只有两种情况, 要么其中含有未使用乐器..... 要么就重复映射两个通道.. 显然.... 额... 如果其中含有未使用的乐器...那我会发现.. 这和实际情况相矛盾.

从ROL 文件的角度来说... 根据这个格式说明https://www.vgmpf.com/Docs/Format%20-%20ROL.txt 其Field 24 只有instrument name. 驱动会在standard.bnk(对于仙剑,肯定是修改过的), 自动对应,然后将ins 文件写入对应的寄存器.

也就是说, 引用了一模一样的乐器而没有使用的这个论点是站不住的. 显然,同名的乐器一定会是"重复"的内容. 重复内容,一定是同名乐器. 换言之, 其一定只使用了5个乐器ins 文件.

用自然语言表意总是容易出现误解，还是用实例说明吧。用084做了几个研究，尽可能记录细节，以保证可复现
0. 首先，次序上是使用demkf.py生成的命名，对应MusicID中的0x54号，也即永恒回忆录定名中的"雨1"。
在任一python环境（测试环境为windows 11 64bit python 3.13.2 )
具体命令：
python derix.py MUS.MKF -p MUS

1. 从rix中获取其使用的ins。
   python rixtool_extractins.py -r MUS84.rix -v
   verbose模式下的log:

going to dump ins 1 with range 20-76
going to dump ins 2 with range 84-140
going to dump ins 3 with range 148-204
going to dump ins 4 with range 212-268
going to dump ins 5 with range 276-332
going to dump ins 6 with range 340-396

一共得出6个ins（跟你的结果不同。可能是RIX顺序命名问题）
经vbindiff，确定6个ins均不同。（跟你的结果不同。可能是RIX顺序命名问题）
为确证rix的音色是否可以重复起见，复制ins6.ins为ins7.ins

2. 将ins打包为Adlib Composer可用的bnk文件(不会覆盖，本目录如本来存在standard.bnk需要事先删除）：
   （从该步开始不经说明即为在dosbox下操作。测试环境为dosbox-x 2025.05.03 vsbuild）
   COMP151\BANKMNG.EXE /p /i*.ins standard.bnk
   并拷贝至COMP151目录。

3. 创建一个新的rol（无音乐技能，仅做测试）
   在COMP151中启动Adlib Composer 1.51
   composer.bat
   新建一个rol，将Option中打击乐模式关闭（With Percussion->Without Percussion)（先不考虑打击乐模式）
   将0-8通道中0-5依次设置音色ins1-6；6,7,8模式全部设为ins7
   敲9个音符，分别用一个通道
   （见附件中test.rol)

4. 转换为rix
   该工具使用ins而非bnk，故需将之前生成的所有ins复制到当前目录；其根据rol中记录的ins名（也即bankmnng生成时的文件名）寻找指定目录中的对应音色，多无所取，少则不成。
   rol2rix test .\

5. 重新提取新rix中的ins(同第一步环境)
   python rixtool_extractins.py -r test.rix -v
   verbose模式下的log:

going to dump ins 1 with range 20-76
going to dump ins 2 with range 84-140
going to dump ins 3 with range 148-204
going to dump ins 4 with range 212-268
going to dump ins 5 with range 276-332
going to dump ins 6 with range 340-396
going to dump ins 7 with range 404-460

一共得出7个ins
经检查前6个同于之前，第七个同于第六。
结论0：rix中的ins部分即为rol用到的所有ins部分压缩后的集合。与上文推测相符。
结论1：rix生产的整个工具链允许相同（内容）的音色文件存在。与上文推测相符。
6. 重新去dosbox，截取dro，用playrix播放两遍新生成的test.rix，停止。
7. 打开opl3 bank editor，import instruments, open bank打开刚生成的playrix_000.dro

可见一共识别到6个instrument。确证从dro中只能识别到不同的ins，与上文推测相符。
8. 回到第三步回归测试，将ins7,8,9的三个音符删除；重复4-5步
仍然得出如上7个ins（log重复，不再贴出）
结论：rolrix打包会将通道定义中存在，但没有实际音符使用的ins（也就是上文猜测存在的未使用音色）也打包进去。与上文推测相符。

附件仅包含上文提到的两个自制rol，其他文件请复现者尝试自行生成，以免主观干扰。
testrols.zip

[gtr3qq]

WOW，谢谢您的详细测试。稍后我复现后看看是哪里出了问题。

[gtr3qq]

在任一python环境（测试环境为windows 11 64bit python 3.13.2 )
具体命令：
python derix.py MUS.MKF -p MUS
.
从rix中获取其使用的ins。
python rixtool_extractins.py -r MUS84.rix -v
verbose模式下的log:
.
going to dump ins 1 with range 20-76
going to dump ins 2 with range 84-140
going to dump ins 3 with range 148-204
going to dump ins 4 with range 212-268
going to dump ins 5 with range 276-332
going to dump ins 6 with range 340-396
.
一共得出6个ins（跟你的结果不同。可能是RIX顺序命名问题）
经vbindiff，确定6个ins均不同。（跟你的结果不同。可能是RIX顺序命名问题）
为确证rix的音色是否可以重复起见，复制ins6.ins为ins7.ins
.

嗯, 应该是顺序不同. 我这里得到 6个乐器的结果是
py .\rixtool_.... .py -r ".\MUSIC_83.RIX"
.
084,或者 MUSIC_84.RIX (Date:1995/6/19 15:29 CRC32:315B96D4 Size:2KiB), 解出来只有5个ins.

[gtr3qq]

感谢您的时间! 测试了一下您给的文件, 与您的结果一致.
对RIX的理解又进了一步! 任何出现不正确的信息的地方均已修正.

[PalMusicFan]

欢迎！非常高兴在2025年还能有机会认识研究RIX格式的同好。

客套话不多说了哈，咱们进入正题。

首先，我的认识是，RIX并不完整包含原ROL+INS档的全部信息。也就是说，RIX逆向回ROL+INS需要很多人工，而且能还原到“等效”ROL就算是成功了。

RIX并没有保留BPM一类的信息，只留下了单纯时序信息，而且INS名称也没有保留，这两点相信我们都知道了。但是，我发现，这个格式似乎还有更多的“奇特”之处。

1. RIX似乎扩展了ROL的pitch bend范围。Ad Lib Visual Composer v1.51只允许把note pitch在上下一个半音的范围内调节，但RIX里这个范围要大得多。相应的，这个扩展的结果要在RIX里才能听到，ROL编曲环境下我们依然只能听到较小的pitch bend。

2. 某些RIX的部分音轨是存在降调/升调的，通过INS音色的Note offset补偿回来。我不确定这是作曲家在创作过程中的设计，还是ROLRIX这个工具引入的。

[gtr3qq]

半音指的是semitone/st 吗？
钢琴键盘上一键？
换言之， 以 G-2 为例
F#2 G-2 G#2,这个范围？
还是？

[gtr3qq]

INS格式定义老实说我从未看过，有note offset 还是很新鲜第一次知道。
我熟知的INS格式,实际上应该叫做 HSC Instrument Format,只有12byte，就含OPL FB MUIT ADSR TL等寄存器数值。
80字节的AdLib Instrument Format，看着头大，除了那小尾数12字节外还有很多字节我以为只是dummy。
待会我找找看header之类的看看。

[gtr3qq]

ROL文件中，相信您也看完了多少遍了，并无明显的channel detuning 参数。
当然，除去作曲家直接在开头设置PA值外。
您提到的这个通道detuning，如果最后INS格式中平衡回来了的话，也许可以通过证明一下是不是在advc中产生的排除一下。稍后我看看。

[gtr3qq]

RIX似乎扩展了ROL的pitch bend范围。Ad Lib Visual Composer v1.51只允许把note pitch在上下一个半音的范围内调节，但RIX里这个范围要大得多。相应的，这个扩展的结果要在RIX里才能听到，ROL编曲环境下我们依然只能听到较小的pitch bend。

PBtest.7z.zip
经测试. 遍历了 ADVC 中的Pitch bent 有效值, 其效果与在ADVC 中一模一样.
从 0.00 到 2.00.

也就是,将 1 半音 semitone 等分为 100 分,

此 claim, 可能是基于这个:

(2)頻率微調
命令碼0xA
設定值頻率調整值(0x00-低半音,0xFF-高半音)

其设计理念与现代软件 Furnace 的E5xx 指令完全一致, E580 为频率中央, E500 低1st FF 高1st

也就是将 1半音等分为 127分.....

那么, 这条 claim 的正确说法应该是

RIX 的 Pitch bent 比 ROL 要更细分........ 多分了27分...

然而.... 实际上... 这不太重要.... 基本上可以确定程序是直接对应对应的值... 也就是说多出来的精度调用不了...

[gtr3qq]

只有一些极端的情况... 比如同时几个通道一起detune, 这时可能通道detune的指令无法按时完成, 带宽全部被挤占.
这时,假如程序足够聪明的话, 可以将某些通道detune 得"稍微" 过一点, 然后这个通道下一tick就不用detune了, 节约了带宽来干其他事件............

这种情况真的有吗???
程序足够聪明应对这种情况吗???

[PalMusicFan]

关于播放器。

经过多年的迭代，我想，现阶段PalResearch项目的RIX播放方案已经实现了音乐意义上的百分百完成。但是，是否能达成寄存器完美，我心里也没有底。

如果打算追求更高精度的还原，那么我猜我们应该先确定现阶段效果最好的软硬件配置：

1. 播放器：

PLAYRIX。这是官方版播放器。
DERIX。
最新的Ad Plug。
DOS原版PAL游戏。
SDLPal。值得一提的是，SDLPal的RIX播放代码里，我们依样在播放开始之前向核心发送了一些魔术值。现在并不确定这些魔术值是做什么的。而且，我们做了个别数值的微调之后，音乐意义上的效果才和官方版的一致。

2. 核心：

DOSBOX提供的核心。请注意，不要用DOSBOX原版默认的设置来回放RIX。我们应该同时设置 [sblaster] oplrate=49716 和 [mixer] rate=49716，这样就可以绕开DOSBOX内部的低质量重采样算法，让OS的音频系统来实现采样率转换，使音质更高。

Ad Plug（SDLPal版和foobar2000版）提供的核心。请选用Nuked OPL3核心。按说明，这是一个电路级精确的模拟核心，而且无论你选什么输出采样率，它内部均使用49716Hz合成，只是会重采样到你设置的输出采样率而已。

YMF7x4系列声卡的FM模块。这是雅马哈的官方方案，内部应该也采用了49716Hz合成，重采样到48000Hz后输出。个人感觉其重采样算法所实现的音质远好于DOSBOX的，所以它的输出可以直接参考。这个系列的亮点是大部分型号原生支持SPDIF数字输出，只要软硬件启用即可。

CMI8738系列声卡的FM模块。这应该是一个精确度很高的clone。较早的型号据说也支持SPDIF数字输出FM音频。值得注意的是，这块卡从DOS到Windows 11均可以支持，兼容性无以伦比。因此，8738可以当作对比用硬件。

[gtr3qq]

嗯嗯，我也是看了一片vogons上研究FM芯片奈奎斯极限的文章才完全理解了为什么会有这么多的争论。文章连接暂时找不到了，似乎是比较ESFM OPL3 CQM频率极限的一片文章。
49716的确是很重要的。

NukeOPL3早就做到CycleAccurate了，故我也完全不担心什么能在win11下写入388h，spdiff采样。不过之前我尝试在tb上找过cmi卡，不知道为什么没买。现在提起来，那我还是入手一个吧。

我当时选择了ESS的 ESFM，对于我来说FB的算法不一样不怎么听得出来，且72op可是力大砖飞啊。(相反，AWE64的CQM我反而听得出口味。)

某种意义上，DOSBOX的确“还原了”sbPRO 之后声卡的49.7khz -> 44.1khz 的重采样造成的二次混叠失真。
对于当时用这些带软mixer的卡的人来说，这反而是更“纯正”的。
显然，我们要以 ntsc彩色晶振/72 hz 为准。

╯﹏╰有一点指正，YMF声卡，尤其是PCI系，虽然内置正版OPL核心，但其不是重采样，而是直接运行在48000hz。
显然这会使得nyquist极限附近的混叠产生变化。来源也是vogons。

[PalMusicFan]

据我测试YMF7x4内置YMF289的确像工作在49716Hz上，这是因为它的打击乐音效很准确。灵山一曲有一个对频率要求很严的效果音，可以测试。

[gtr3qq]

大概知道您说的是哪个SFX.
的确,那要求也很高.
我也有张联想OEM的YMF7 卡, 当时测试时自己也没听出多差...
RIX也罢, 其他OPL曲也罢. 还觉得"正版"OPL芯片....老HiFi 怎么说的? "高频更加清甜,中频更加....🤣"

看到那帖子后,觉得可能Vogons 上的那些大佬知道的比我多, 大约就是运行在48khz, 以后就避开使用这卡了.
(而且,那帖子的确有几张图,直观的显示其高频不同.)
但, 我们推理一下,
理论上这些AC97的卡的确,因为要符合AC97,所以均锁定在48khz, 那些老HiFi还会说什么SB live! 因为这重采样而不好.
雅马哈既可以重采样, 也可以直接降低其内核的phiM 时钟来降低输出采样率(OPL3 datasheet 规定的phiM是个范围.)
直接降低还可以省略个重采样电路.

但为什么我们两都觉得没差呢?
我觉得可能有两个原因

1. ....49khz-48khz/2.... 这范围的音高实在太高了, 人耳可不容易检测(示波器"简单(如果你有钱! 上Gs级示波器)"), 听到没听到真太容易主观影响.而且... 范围也太小... 就 250hz的频宽, 如果用的是普通喇叭,哪些无法重现高频的喇叭,更是直接被低通掉了.
2. 雅马哈的48khz 可不是DOSBOX那超级快速的重采样算法, 显然其假设重采样/slow down, 其知道要注意哪些点, 弄得很好.

[gtr3qq]

SDLPal。值得一提的是，SDLPal的RIX播放代码里，我们依样在播放开始之前向核心发送了一些魔术值。现在并不确定这些魔术值是做什么的。而且，我们做了个别数值的微调之后，音乐意义上的效果才和官方版的一致。

是哪些值? 写向哪里/哪些OPL2寄存器? 微调???

[gtr3qq]

需要指出的是，寄存器完美，我已经人工完成了一次084的重构。
用的是playrix 陪dosbox 73-3，输出的dro type2。
工期大概1周，而且得占用所有空闲时间。
但肯定不是CycleAccurate…Furnace的 OPL驱动在tickrate设置在64hz时显著比 dro 写得快。(信号的setup快）
但KeyOn同步，且在hold阶段可观所有寄存器数值均一致。

有很多步骤理论上是可以自动化的，这样可以大幅节省时间，无奈编程较弱。

[gtr3qq]

bpm通常使用的是十分科学的连懵带猜。
当然，仙剑如果有对应midi文件就直接看bpm即可。
如果不知道，就通过数拍子，确定一个可能的bpm，然后建立一个音乐工程文件，写入bpm值，然后渲染wave文件，在audacity下看两文件时长……
很是尴尬。
有些特殊的，如轩辕剑2的sword.rix，前16tick是空的，得在重建工程中跳过16tick，输出音频文件才时长一致，这种还得猜靠……

[gtr3qq]

乐器名就自己乱写，听着像brass.ins就叫brass
当然，这个是可以不用猜且可量化的。
可以直接拿着从rix文件中提取的乐器，和standard.bnk中乐器比较，只需要比较几个参数即可知道这个乐器和哪个标准乐器相近。
如果一模一样就直接命名。
不一样就在命名中写，如 brass.Mod.TL-3.Mod.A2 之类的.
通过这种方式来量化乐器。

[gtr3qq]

网上已然找不到完全的使用RIX 格式的游戏列表, 目测最早的游戏是轩辕剑1,1990中那几个半成品RIX.

[gtr3qq]

也许可能文件不是RIX, 具体我得找找源文件. 但至少轩辕剑2 中有一个战斗曲是改都没改直接复制的.

[gtr3qq]

网上找到的列表大多是这种款
大富翁2（1993年）
轩辕剑贰（1994年）
天使帝国2（1994年）
魔法世纪2（1994年）
正宗台湾十六张麻将（1994年）
妖魔道（1994年）
格斗拳王（1994年）
轩辕剑外传 枫之舞（1995年）
明星志愿（1995年）
仙剑奇侠传（DOS/1995年）
大富翁3（1996年）
魔神战记2（1996年）
春秋争霸战2（1996年）
正宗台湾十六张麻将2（1997年）

少了 幻象雷电, 还有可能的轩辕剑1.....那就有可能少了更多.

[PalMusicFan]

幻象雷电和轩辕剑初代所用MIX格式和RIX不一样，因此这两作不建议计入列表。

[gtr3qq]

幻象雷电和轩辕剑初代所用MIX格式和RIX不一样，因此这两作不建议计入列表。

oof......大宇当时还有其他格式？？
好吧....这就改wiki....
也就是,这表实际上是全的? 没写的就是MIX格式?
第一个用RIX的真是大富翁2??

[gtr3qq]

https://www.newton.com.tw/wiki/rix/3368600
这里又多出一个 蜥蜴超人L-MAN....

[gtr3qq]

正在编辑的vgmpf页面, 欢迎助力
https://www.vgmpf.com/Wiki/index.php?title=RIX

[PalMusicFan]

现在几乎肯定RIX相关工具的维护者是当年的程式支援童培诚，PLAYRIX已经很清楚地记载了作者的名字。

[gtr3qq]

🤣自己开坑自己XX。
挺好！
您有其Email吗？ 我写vgmpf wiki想引用其几句。
主要想知道。

1. RIX 格式出现是为了解决什么问题。
2. 大宇是怎么外包RIX 格式开发给他的。
3. RIX 他觉得应该叫“notational”（注音式格式，如MIDI），还是“instructional”（..imf/wlf 那种写给OPL数据的dump）

其他暂时想不到....
也没必要问了...
总不能让别人给你写个 rix.h, 把格式全部说完吧.....

[gtr3qq]

写完了, 欢迎review.

[gtr3qq]

目前, 网上典型的格式说明只有两篇一模一样的描述.
这里引用正体版.

RIX格式RIX是《仙劍奇俠傳DOS版》的音樂格式，它採用小尾數法存儲。
.
RIX格式
1.頭結構
偏移長度描述
0x000x02標識碼(0x55AA)
0x020x01是否保留打擊樂器(0-全樂音,1-保留打擊樂)
0x080x02樂器塊偏移(不過我懷疑是4位元組的.不過我還沒找到證據)
0x0C0x02音樂塊偏移(同樣懷疑是4位元組)
2.樂器塊結構
樂器塊是以樂器為單位，每個樂器為INS格式的0x02-0x41，共0x40位元組合成起來的。
INS格式是ADLIB公司BNK格式的前身(至今仍有INS編輯器)。
具體格式，有ADLIB音效卡開發包的可以看一下。
3.音樂塊結構
音樂塊是以2位元組為單位的，每一個單位都有兩種狀態：
(1)普通狀態
低位元組設定值
高位元組
高4位命令碼
低4位通道號
(2)延時狀態
當普通狀態的命令碼不是合法的(即不為"命令一覽"中的值之一)，即為延時值，其大小為兩個位元組。
音樂塊以雙位元組魔數0x8000結尾(碰到它，千萬不要以為是延時了!!)，一般也是整個檔案的結尾。
說明1：樂器通道
當打擊樂器標誌==0,0-8全為樂音。
當打擊樂器標誌==1,0-6為樂音,7-A為打擊樂器(BD,SD,TT,CY,HH);
說明2:命令一覽
(1)設定樂器
命令碼0x9
設定值樂器塊內的樂器號
(2)頻率微調
命令碼0xA
設定值頻率調整值(0x00-低半音,0xFF-高半音)
(3)音量調整
命令碼0xB
設定值音量值(0x00-最小,0x7F-最大[默認7F])
(4)設定音符
命令碼0xC
設定值音符號碼(0x3C是中央C,半音為單位[0x00為禁止通道發聲,也就是靜音])注意，必須有延時才能放出音來，兩個通道可以同時延時形成和音。

这个说明都快盘包浆了.....
作者不明,准确度未知.
其作为一个大概的guide line 还可以, 但假设细看就不精看了.
例如其定义的
0x0000, 2byte AA55h
到
0x0020, 1byte
中间的都是dummy吗?
0x0020 这一个byte, 什么叫做"0", 什么叫做 "1"? 是 00h和01h吗? 还是00h,FFh?

音乐块以 2 "位元"?(byte?字节?) 为单位(作为一个word??)?
状态????
....哪怕带着现在的些许知识, 看这篇说明依然如同读文言.(也许正是"文言"..)
亟待更新此说明.

[gtr3qq]

还有.... 说文件是小端...写出来的值又变大端了....

[gtr3qq]

當打擊樂器標誌==1,0-6為樂音,7-A為打擊樂器(BD,SD,TT,CY,HH);

显然, 是 0-5 6-A..

[gtr3qq]

(3)音量調整
命令碼0xB
設定值音量值(0x00-最小,0x7F-最大[默認7F])

稍微莫名其妙... OPL2 显然是6 位 TL 控制振荡器衰减, 这里怎么变成7位....
只是复制粘贴 ADVC 中的 0.00 到 1.00 浮点转整数啊?

[gtr3qq]

然后.... 丢弃LSB? 只写前6 nibble?

[gtr3qq]

尝试使用ROLRIX.EXE 生成了一下Thecloud.ROL, 打开编译后RIX看到如下.
(文件:TheCloud.7z.zip)

其显然,完整的保留了所有乐器的名称.
甚至.. 我们打开源文件的SYN2.INS, 并在其头部插入2 byte 的 $FFFF dummy 来LSR整个文件.

............
显然...........除了INS文件尾部十几个Byte 外(看起来, INS尾部 14byte 的00 dummy被cut), 所有INS 信息,均完整保留.

因此, 我不认为"RIX 没有完整保留INS格式."这一说法严谨.
文件名则是另外的问题了.
根据林老师最新放出的视频, FG01.ROL(MUSIC_36.RIX), 显然至少有个通道1的 "kabass1.ins"(standard.bnk中找不到)
然显然的, 其编译后文件中均找不到乐器名.
大概看了下ROLRIX.EXE的strings
没有发现purge 乐器名的switch.
这是否说明 RIX目录下的开发工具还至少少了个清除乐器名的程序?

也或者? 我使用OPL3BANKEDIT生成的 INS 文件是新版文件?
使用了一些 INSMaker没使用的dummy bytes来存文件名?

另外...... 根据那篇格式描述......... 期待在 $20 offset 找到 $01 $00 来区别是否开启打击乐模式.....
我们在这里找到........

???????????????
这算什么??????????
难不成? 是这个byte的LSB 来标识是否开启打击乐??????
显然, $0A = (0000) 1010b
的确, 此曲也没有打开打击乐模式.
但无法否定与肯定,这是否是巧合.........
....或者.........记得前面对比INS文件吗?
$0A在源INS 文件中..................
因此...............基本可用认为, 此描述是错误的.
?或者, 其尝试描述INS 格式中, 区别 percussion 和 melodic 乐器的byte???
而非指定是否OPL开启打击乐模式的byte?
因此, 此得在全曲中重复多次? 每个INS chunk都出现一次?直到遍历整个乐器chunk?
........
就是这些吓人的小细节,导致我都不敢看那篇说明了.

其,听起来也和原ROL 没有太多的区别, 暂未检测寄存器实际写入的值是否与AdLib Sound Driver 等价.
而原.ROL 中此曲使用了极宽的Pitch bent(记得是 0.85 到 0.50, 大概是35cent...当然,还有Fnum取值的问题, 实际输出频率也只是在35ct 附近).

无法验证 "RIX 中扩展了pitch bent 范围这一说法."?
假如有, 也许其差距在此曲范围内实在太小.
或者, 此扩展只在升调区间?
😂

[gtr3qq]

ROLRIX.EXE真是当年使用的程序吗?????

[gtr3qq]

另外, 林老师演示FG01.ROL 的视频中, 假设其使用的不是RIX播放后的音频,而是直接在ADVC中点击"Play", 可以听见,至少前面几秒是和编译后文件一模一样.

[PalMusicFan]

鉴于现在已经可以使用整套工具来制作RIX，具体格式对比还是以实践为主吧。

此外，相关的内容可以阅读DERIX.C。虽然它不见得和PLAYRIX.EXE等效，但是大致是不差的。

[gtr3qq]

鉴于现在已经可以使用整套工具来制作RIX，具体格式对比还是以实践为主吧。

此外，相关的内容可以阅读DERIX.C。虽然它不见得和PLAYRIX.EXE等效，但是大致是不差的。

没事没事，大家一起看。
信息分对错，热情可不分哦！

[gtr3qq]

ROLRIX.EXE 有date code 吗? git库中的文件datecode 已被摧毁.

[gtr3qq]

无法记得在哪里看到, 大富翁2用的RIX格式似乎与其他游戏中的格式不同一样? 如您知道不同是哪里,欢迎指出.

[gtr3qq]

我稍微看了一下, 没发现多少区别,除了显然的...每一曲都很长....

[gtr3qq]

来源:https://www.newton.com.tw/wiki/rix/3368600

[gtr3qq]

一些Vogons 上的信息.
ESS FM 的FEEDBACK 算法与OPL3 比较,https://www.vogons.org/viewtopic.php?p=523420&hilit=esfm#p523420

结论是区别实在不重要... ESS FM的FeedBack 算法反而比OPL3要更加柔和.

https://www.vogons.org/viewtopic.php?t=49648

魂牵梦绕的图片演示高频混叠区别....

https://www.vogons.org/viewtopic.php?p=1259488&hilit=esfm#p1259488

硬件播放现代ESFM音乐的软件.

[gtr3qq]

完蛋.....🤣
我成功的在ADVC 下 把 ROLRIX.exe 的带宽挤占完了.... 要不..就是哪里溢出了.....
FM9 通道的伴奏中间突然间就掉了...
derix看通道音量变成0 到 36 之间的噪声. 然后锁128...
一点也不高兴..............
本来想整活,花两周编写ROL 文件..... 做所谓2025年全新RIX 音乐..........
...显然, 除整活外,还有些许程序上的研究价值..
些许泡汤....................

F..............

well, 文件在此... 感兴趣欢迎查看........然后也许指着笑?

newrix.7z.zip

[gtr3qq]

今天突然想到分页的方式突破ROLRIX.EXE 的不知道是什么限制.
将nochil.rol 分成 两个 互相重叠 8个bar(乐曲的单位之一) 的小ROL 文件.
然后将两者编译. 为1号 2号 RIX 文件,
修改2号RIX文件的乐器映射, 因为 1号文件遍历了全部INS 文件, 而2号文件因为截掉了开头, 有些乐器就不存在,存在的顺序也不一样. 0x9xyy 指令对应的乐器号就不一样.
然后 在2号文件中找特征码, 对应好后 PPAP 两个文件.
🤣pew... 总算是救了这project...

[gtr3qq]

修复后文件.
NORCHIL3.7z.zip

[gtr3qq]

大概看了下RIX 格式之前用的 所谓 MIX 格式
在幻象雷电中, s文件夹内
存有大量 Mus + SND 文件.
可惜这些文件均被不知道什么算法压缩.
只有tboss1.mus/snd 因为尺寸大,而没有压缩, 可以直接用标准工具反编译为ROL + INS...
.....怎么识别是什么算法呢?.....

干脆! 等游戏加载这些文件, 然后在内存中期待有解压后的文件..........额.....怎么做到...
还得想一想....