Next-generation muri detector for simai, supports DX charts.
支持 DX 谱面的 Maimai 自制谱无理检测器，可检测包含内屏无理在内的所有类型无理配置并给出报告。
从 Release 页面下载打包好的 MaiMuriDX 压缩包，解压到你喜欢的位置。
双击 run.bat 即可运行，按照命令行窗口里的提示输入谱面文件路径，选择难度后，跟随程序的指引操作。
报告分为两部分：静态检查和动态检查。在静态检查中会有外键无理、撞尾无理、叠键无理的报告，在动态检查中会有所有 5 种无理的报告。
引号的 Simai 语中若出现 Tap 后接 _，表示该 Tap 是星星头，如 3_ 表示某条 3 号键开始的星星的星星头，若出现 Slide 的形状前接 *，表示是同头星星的其中一条。
下面是几个静态检查报告的例子：
撞尾无理："8"(L17,C27) 可能被 "5-8[8:1]"(L17,C21) 蹭到 (+35 ms)
外键无理："3"(L19,C26) 可能被 "3-6[8:1]"(L19,C21) 蹭到 (-150 ms)
叠键无理："2b$"(L47,C37) 与 "2b"(L47,C40) 重叠
叠键无理："4_"(L56,C8) 与 "4h[4:1]"(L54,C54) 重叠
撞尾无理："1_"(L70,C77) 可能被 "5<1[8:1]"(L70,C57) 蹭到 (-17 ms)
撞尾无理："5_"(L70,C86) 可能被 "1-5[8:1]"(L70,C66) 蹭到 (-37 ms)
这六行的含义分别是：
- 第 17 行第 27 列的
8的正解之后 35 ms，第 17 行第 21 列的5-8[8:1]会到达 A8 区，因此可能被撞到。 - 第 19 行第 26 列的
3的正解之前 150 ms，第 19 行第 21 列的3-6[8:1]启动，因此可能被蹭到。 - 第 47 行第 37 列的
2b$和第 47 行第 40 列的2b重叠了。 - 第 56 行第 8 列的星星头
4_和第 54 行第 54 列的4h[4:1]重叠了。 - 第 70 行第 77 列的星星头
1_的正解之前 17 ms，第 70 行第 57 列的5<1[8:1]会到达 A1 区，因此可能被撞到。 - 第 70 行第 86 列的星星头
5_的正解之前 37 ms，第 70 行第 66 列的1-5[8:1]会到达 A5 区，因此可能被撞到。
动态检查报告中的每一条都附加了一个时间戳，零点是 BGM 开始播放的时刻，格式为 分:秒F帧，其中帧以 60 FPS 为基准。
下面是几个动态检查报告的例子：
[00:39F40.33] 撞尾无理："3"(L17,C49) 被 "8w4[3:1]"(L17,C45) 蹭到 (-27 ms)
[01:48F25.33] 叠键无理："4_"(L56,C8) 似乎与另一个note重叠 (+152 ms)
[01:49F57.67] 内屏无理："5?>8[64:96]"(L55,C40) 被提前蹭掉，相关判定区如下
A5: Skipped
A4: "4h[4:1]"(L54,C54)@01:48F11.00 (H-83, S-534, J-2989, E-3241)
A3: "3h[4:1]"(L54,C62)@01:48F11.00 (H-83, S-534, J-2989, E-3241)
A2: "4>4[64:96]"(L56,C17)@01:49F17.00 (H+1017, S+566, J-1889, E-2141)
A1: "4>4[64:96]"(L56,C17)@01:49F37.33 (H+1356, S+905, J-1550, E-1802)
A8: "4>4[64:96]"(L56,C17)@01:49F57.67 (H+1695, S+1244, J-1211, E-1463)
[01:52F42.67] 叠键无理："5"(L57,C16) 似乎与另一个note重叠 (+155 ms)
[01:54F35.33] 多押无理：下列note可能形成了3押
"5h[8:15]"(L57,C12) "4"(L57,C28) "5"(L57,C29)
[02:19F36.33] 撞尾无理："5"(L70,C97) 被 "1<5[8:1]"(L70,C84) 蹭到 (-18 ms)
这六条报告的含义分别是：
- 0:39 的第 40.33 帧，第 17 行第 49 列的
3在正解之前 27 ms，被第 17 行第 45 列的8w4[3:1]蹭到了。 - 1:48 的第 25.33 帧，第 56 行第 8 列的星星头
4_在正解之后 152 ms 才判定，可能是和另一个 Note 重叠导致没判上。 - 1:49 的第 57.67 帧，第 55 行第 40 列的
5?>8[64:96]被提前蹭掉，相关判定区如下：- A5 区被跳过；
- A4 区在 1:48 的第 11.00 帧被第 54 行第 54 列的
4h[4:1]按下，此时是星星头正解前 83 ms，星星启动前 534 ms，星星正解前 2989 ms，星星结束前 3241 ms； - A3 区在 1:48 的第 11.00 帧被第 54 行第 62 列的
3h[4:1]按下，此时是星星头正解前 83 ms，星星启动前 534 ms，星星正解前 2989 ms，星星结束前 3241 ms； - A2 区在 1:49 的第 17.00 帧被第 56 行第 17 列的
4>4[64:96]按下，此时是星星头正解后 1017 ms，星星启动后 566 ms，星星正解前 1889 ms，星星结束前 2141 ms； - A1 区在 1:49 的第 37.33 帧被第 56 行第 17 列的
4>4[64:96]按下，此时是星星头正解后 1356 ms，星星启动后 905 ms，星星正解前 1550 ms，星星结束前 1802 ms； - A8 区在 1:49 的第 57.67 帧被第 56 行第 17 列的
4>4[64:96]按下，此时是星星头正解后 1695 ms，星星启动后 1244 ms，星星正解前 1211 ms，星星结束前 1463 ms。
- 1:52 的第 42.67 帧，第 57 行第 16 列的
5在正解之后 155 ms 才判定，可能是和另一个 Note 重叠导致没判上。 - 1:54 的第 35.33 帧，第 57 行第 12 列的
5h[8:15]，第 57 行第 28 列的4，第 57 行第 29 列的5可能构成了三押。 - 2:19 的第 36.33 帧，第 70 行第 97 列的
5在正解之前 18 ms，被第 70 行第 84 列的1<5[8:1]蹭到了。
在程序采用渲染模式运行且电脑性能较差时，可能会误报叠键无理，可以根据报告行末的时间差判断（真叠键一般都大于 150 ms，如果只有 50 ms 的话应该只是电脑卡了）
程序根目录下的 config.json 存放了 MaiMuriDX 的运行参数，如果 config.json 文件不存在，运行时会自动创建一个默认版本：
{
"hand_radius_max": 180,
"hand_radius_wifi": 100,
"hand_radius_normal": 60,
"distance_merge_slide": 20,
"delta_tangent_merge_slide": 3,
"tap_on_slide_threshold": 0.3333,
"touch_on_slide_threshold": 8,
"overlay_threshold": 2,
"collide_threshold": 12,
"extra_paddown_delay": 3,
"release_delay": 1.3333,
"wifi_need_c": false
}各项参数含义如下：
hand_radius_max是处理 TouchGroup 时允许的单手最大半径，单位是像素，在官方框体上 100 px ≈ 5 cm；hand_radius_wifi是处理 Wifi 时的手的半径，单位是像素；hand_radius_normal是处理所有其他配置时的手的半径，单位是像素；distance_merge_slide是允许两条 Slide 动作合并的最大距离，单位是像素；delta_tangent_merge_slide是允许两条 Slide 动作合并的最大夹角，单位是度；tap_on_slide_threshold是将 Tap 识别为拍划配置的时间阈值，单位是帧 (60 FPS)；touch_on_slide_threshold是 Slide 撞 Touch 的时间阈值，单位是帧；overlay_threshold是静态检查时识别叠键的时间阈值，单位是帧；collide_threshold是静态检查时识别撞尾的时间阈值，单位是帧；extra_paddown_delay是动态检查时应该在 Slide 启动后重复触发 A 区的延迟，用以模拟外键无理，单位是帧release_delay是动态检查时每个动作的松手延迟，单位是帧；wifi_need_c是开启模拟旧框 Wifi 的 C 区抬手判的开关，填true或false。
MaiMuriDX 提供了 cli，在命令行中输入 cli -h 即可查看 help。
MaiMuriDX 使用 Python 编写，所以只要你有对应平台的 Python 解释器就可以直接从源代码运行。
我寻思 MajdataEdit 也只能在 Windows 上运行吧……真有跨平台需求吗？