返回列表 发帖

BMS文件数字化及其应用

BMS文件数字化及其应用

一.引言

本人乃BMS新手一枚,信誓旦旦做好了了处女作**交给FF验明正身,结果被无情地打击回来,理由“压音不准”,以下对白:
Me:我咋觉得0.4速都没看出啥问题呢?
FF:视觉和听觉也要跟理论结合!

具体情况如下图:



稍有经验的Noter(甚至菜鸟如我)一眼就能看出来Error 1中一排NOTE应该下移一排,Error 2应该向下微移半格(出现此状况的原因是由于使用了64 Grid;注:本图为32 Grid视图)

Error 1Error 2应该都是新人容易犯的压音问题,出错原因很大程度上是由于不仔细(如理论上有不理解的请参阅论坛相关文章),快速、有效地检查出此两类错误是制作、提交作品时不可或缺的一个步骤,面对上百个小节、上千个Note,我对FF大嚎道:“要是有软件检查就好了~”,FF答曰:“Just do it!
于是,本文诞生了。
谨以此文献给和我一样新的新手Noter,以帮助大家减少压音不准的错误,尽快走上正途(我们的目标~通过审核!)

废话不多说,正文开始。(对于理论不太感兴趣的同志请直接跳往3L实践篇,但请理解“数字串规律”前面“压线”的定义)

二.理论篇

怀着一颗好奇的心,我用笔记本打开了一个BMS文件,得到了以下结果:
*---------------------- HEADER FIELD
#PLAYER 1
#GENRE Pop
………………(省略)
#WAV01 oops.mp3

#BPM01 52.17
#BPM02 122.78
……………(省略)
#LNTYPE 1
*---------------------- MAIN DATA FIELD

#00001:00000001
………………(省略)
#00603:000000000000000000000000000000000000000000AE003C000000000000005A
#00608:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000020300000004000000000000
#00611:0002000200020000
#00612:02000000000000000200000000020000
#00613:0002000000020000
#00614:00000000020000000000000000020000
#00615:0002000200020000
#00616:00000000000002000000000000020000
#00618:00000000000002000000000000020000
#00653:00000000000000000000000002020000
………………(省略)

可以看到一个BMS文件可以完美地用记事本打开(或解码,Decode),打开后文件分为下列几个部分:
1.头文件(HEADER FIELD):记录了曲名、曲风、作者等信息
2K音区(即上文中的#WAV01),如果是K-BMS,这里将会有一大串
3.变速区,记录了变速的信息
4.面条区,即#LNTYPE一行
5重头戏,主要数据区(MAIN DATA FIELD),记录了谱面信息

从上面叙述我们可以看出,用记事本打开的BMS文件详细完整地记录了歌曲的Note信息,换言之,我们完全可以只用记事本而无需BMSE做出Note(前提是你的头脑足够发达,具体见下文)更直白的说,用BMSE只是一个GUI图形用户接口),关于这点的讨论详见后文“四.应用之自动Note机”

下面关注数据区(main data field,和BMSE上所见一样,数据的记录也是按小节来记的,如#000****#001****#002****……那么以006节为例,#006后面的数字又代表什么意思呢?

经过实验,可以得出结论:#0061X记录的是米粒Note#0065X记录的是面条Note,也就是说BMS里面米粒和面条是分开记录的。自然地,我们可以猜测,#0060X记录的是变速信息(为何存在#00603#00608两行?有待研究)

进一步,我们通过实验可以的出上文所提到的X代表的是Note所在列----BMS记录每小节的NOTE信息是以记录的,具体对应关系如下:(Xà键)
6à1
1
à2

2
à3
3
à4
4
à5
5
à6
8
à7
记实际击打键位从左至右为1-7,详见下图:

#00611后面的一串数字“0002000200020000”(下称为数字串)就是X=1,即实际击打的2号键(左蓝)的米粒NOTE信息(因为是1X,注5X为面条信息),02#WAV 02的意思,代表该位置排了一个#WAV 02
为什么有的数字串为16位(如#00611#00613)有的数字串为32位(如#00612#00614)?这与排放NOTE的位置有关,见下图:




                                      注:此图不与上文所述#006对应!(假设该小节为#001,且除所示Note 外无其余Note

我们称1号键位第一个Note(自下往上数)压在Grid 4上,2号(蓝)压在Grid 8上,3号(白)压在Grid 16上,4()压在Grid 32上, 5号(右白)压在Grid 64 (本图为Grid 32视图,每一节有32格线,每一拍有8格线)

数字串规律:


1.数字串位数为该键位该节所压最细Gird数乘2(由于#WAV 后面的编号由两位,如#WAV 01#WAV 02)如1号键(对应X=6)在第一节(#001)压的最细的Grid4,则#00116:后面的字串有4*2=8

2.记录Note的顺序总体上为从上向下(以一个最细Grid线为单位上移),例如1号键压的最细格线为4,则#00116:后面的数字串由4部分(每部分2位)从上向下记录该节1号键的Note米粒信息。





[ 本帖最后由 handsome8848 于 2010-8-6 23:23 编辑 ]

不实用。有这样的时间放慢也对完了,还能顺便测试下手感

TOP

我想知道这个方法对FF的极速+写字是否可行。。。。

TOP

已收录在Mania技术贴中

★☆ BMS 技术贴总览 ☆★



这篇论文写的很认真,图文并貌,作者用心可见一斑,虽则有些许争议,不过艺术之路本身就没固定的方法,只希望对后人有用。

感谢支持我们共同的BMS爱好,一起加油吧~

[ 本帖最后由 Freefire1943 于 2010-9-13 08:45 编辑 ]

TOP

太棒了!
分析得如此透彻,以后直接看你的研究成果,这可为我省了不少时间哦  :)
留个爪印先

TOP

平时使用16格线不就没事了?
干嘛自找麻烦去用那么密的格线?又不是在变速

话说楼主的帖我能完全明白,因为我曾经深入研究过笔记本与BMSE之间的紧密联系。
笔记本还能让你知道你的变速有没有溢出等问题。

顺便说我习惯吧MP3用WAV2 表示,然后用WAV1 和WAV3 分别代表米粒/面条开头 和 面条结尾。

TOP

原帖由 Farseeker 于 2010-8-9 21:41 发表


不了解你所说的 "1/11秒" 的数据, 请给出数据的出处~ 我了解的数据是1/24秒.

如果你所说的 "人类视觉分辨最短时间" 指的是视觉暂留的时间, 那么不用担心视觉暂留现象的影响~ 原因是这样的:
Note下落的 ...


学习了~

TOP

除了经验,悟性更重要。我做了50多还是一点进步都没有。
子曾经曰过:在哪里跌倒了,就在哪里躺着。

TOP

原帖由 handsome8848 于 2010-8-8 21:27 发表
不好意思,算时间的时候忘了每小节有4拍~
不知道0.15秒的误差以及0.075秒的误差能否看得出来,要知道这是放慢速度后还有0.15秒
人类视觉分辨最短时间大概是1/11秒吧?0.15秒可能有点玄~ 况且还有个听觉到视 ...


不了解你所说的 "1/11秒" 的数据, 请给出数据的出处~ 我了解的数据是1/24秒.

如果你所说的 "人类视觉分辨最短时间" 指的是视觉暂留的时间, 那么不用担心视觉暂留现象的影响~ 原因是这样的:
Note下落的时候, 它在某一时刻t具有的影像会 "留" 在我们眼中一段时间, 设这个影像的坐标为y. 其后的t+Δt时刻, 这个Note具有的影像变了位置, 设新位置的坐标为y'. 因为Note在Δt时间内做了运动, 所以y和y'并不相等, "留" 在眼中的影像y并不会妨碍我们观察影像y'.
也就是说, 视觉暂留现象并不妨碍咱们观察Note是什么时候落到红线上的.

实践上看, BPM在120左右的歌, 1/32小节的误差确实挺明显的~ xD

也许多做两首歌就适应了吧. 我感觉, 做BMS, 经验真的很重要~

TOP

回复 #16 Farseeker 的帖子

不好意思,算时间的时候忘了每小节有4拍~
不知道0.15秒的误差以及0.075秒的误差能否看得出来,要知道这是放慢速度后还有0.15秒
人类视觉分辨最短时间大概是1/11秒吧?0.15秒可能有点玄~ 况且还有个听觉到视觉的传递过程。。。

TOP

原帖由 handsome8848 于 2010-8-8 08:45 发表
再提出一点疑问:文中提到的两种Error 靠“放慢速度”似乎难以听出!

以BPM 100的歌曲为例,每一小节0.6秒,Error 2这种错误引起的误差是1格64线,也就是0.6/64约为0.01秒,Error 2引起的误差为1格32线,约0.02秒,不知道要放慢到什么样的速度才能察觉出0.01秒数量级的误差呢?(不知道0.1速能否看出,也就是视听之间有0.01(~0.02)/0.1=0.1(~0.2)秒的误差,话又说回来,一首5分钟的歌用0.1速听一遍可是50分钟)


对于BPM100的4/4拍歌曲, 每一小节是2.4秒, 类似Error2的错误引起的误差是0.0375秒, 类似Error1的错误引起的误差是0.075秒.

用半速来检查的话, Error1这样的错误会引起0.15秒的误差, 很明显的.

[ 本帖最后由 Farseeker 于 2010-8-8 20:33 编辑 ]

TOP

应该说两种方法各有利弊吧,不过不论是哪种方法,用得熟练的人一般很快直接扫一遍就能看出来了


小B的那种放慢方式说的也不全面,事实上尤其像Rock里那种电吉他的面条音在放慢的情况下更难听出来,(面条收尾音就更不用提了),而LZ你这个方法的局限刚才也提到的,就是不适用于不规则的变速。

至于恒速下,哪怕是一段0.5倍变速段中,如果这个方法用的得当的话,自己显然也可以辨认的,毕竟是自己的作品,大概在什么地方会出现怎么样的“信号”应该有数的,反之,如果是检查别人的问题那么又另当别论了。

关键还是个习惯问题,如果新人看了这篇文,觉得很能接受并且会投入使用的话,这也绝对是件好事呢~

TOP

再提出一点疑问:文中提到的两种Error 靠“放慢速度”似乎难以听出!

以BPM 100的歌曲为例,每一小节0.6秒,Error 2这种错误引起的误差是1格64线,也就是0.6/64约为0.01秒,Error 2引起的误差为1格32线,约0.02秒,不知道要放慢到什么样的速度才能察觉出0.01秒数量级的误差呢?(不知道0.1速能否看出,也就是视听之间有0.01(~0.02)/0.1=0.1(~0.2)秒的误差,话又说回来,一首5分钟的歌用0.1速听一遍可是50分钟)

是以,我认为对于这两种粗心所导致的误差,还是本文提出的方法比较适用,而放慢速度的方法,恰是对付本文没有涉及到的错误(如抓音不准等),望指正

TOP

"毕竟他是以记事本来检查,从记事本的代码转到BMSE的小节,又得花大工夫去找"
上文提到的方法是“用笔记本打开BMS文件,然后在WORD中剔除到只剩下压64线,128线”,剔除后剩余的结果为#0xy????:的形式,其中XY即代表所在小节,直接在BMSE中查看即可,本文提出的方法没有在“不使用BMSE”的条件下呀,只是为了方便查找需要检查的、可能出错的小节。不信的话您可以拿一首变速不太多的歌曲实验一下,由于可以成片跳过剔除结果(如变速段、高潮段),检查效率其实是挺高的。

至于所说只有发明人会用,就此问题特别在3L总结了使用方法,可以不必透彻研究理论,按照3L的方法操作几步WORD即可知道出现问题的小节,何乐而不为呢?

另,我有一点疑问,传说中RO的超级变速难道变完了不压小节线的吗?如果变完了还是要压小节线,我们要做的只是检查的时候“跳过变速段”,文中已经提到,此方法不检查变速度(因为经常压高线)的错误!当然,如果变完速不压小节线,后面的NOTE全排在64,128线上,那就无能为力咯~

综上,我认为在一个“规律的歌曲”(变速不太多)和规律的BMS writing(对齐小节线)情况下,该方法还是可以起到一定作用的~

当然,如果习惯了用放慢速度检查的方法,那也是可以的~

打个不太恰当的比方,原子弹和小刀都可以杀人,原子弹杀人速度快但精确度可能有所欠缺(不能解决所有问题),小刀可以一个一个杀(精确)但是效率低,喜欢那种杀人方式任君选择~

TOP

社友者(37969986) 19:54:01
还有一点,RO的变速经常是移动NOTE的,而且经常出现64线甚至192线的NOTE
社友者(37969986) 19:54:28
碰到这种,他的“快速检查压音法”也是无能为力
道·Freefire(183203079) 19:55:34
所以本来就是新手用的  
道·Freefire(183203079) 19:55:43
当时我跟他说起过这个的  
道·Freefire(183203079) 19:55:56
不过如果只是以提高效率来说的话,也勉强可以吧  
社友者(37969986) 19:56:02
也不行的
道·Freefire(183203079) 19:56:07
你一个个检查,这样跳跃起来快写  
道·Freefire(183203079) 19:56:25
就像word里的查找一样,不一定查找的都是你的不表,不是的话就跳过去就行了  
道·Freefire(183203079) 19:56:39
毕竟大多的地方还是比较规律的  
社友者(37969986) 19:56:45
毕竟他是以记事本来检查,从记事本的代码转到BMSE的小节,又得花大工夫去找
道·Freefire(183203079) 19:57:13
这方法发明者自己用或许还不错  
道·Freefire(183203079) 19:57:20
别人用的话可能就不适应了  
社友者(37969986) 19:57:29
你就算找到有几个是不合规律的,还得用BMSE再进行确认
再者,这只能针对无变速或纯A类变速的BMS
社友者(37969986) 19:58:03
有这工夫一点一点找,我MANIA放慢2次看都整曲看完了
道·Freefire(183203079) 19:58:33
那得看曲子有多长了  
社友者(37969986) 19:58:41
以技术帖来说,这帖写得是有创意
但是从可行性来说,太低
道·Freefire(183203079) 19:58:43
这个方法某种场合还是很适用的  
道·Freefire(183203079) 19:59:09
越是时间长,BPM稳定的曲子就越实用  
社友者(37969986) 19:59:19
就是这某些场合具体是多大的场合
实际上据我看来,5个曲子有1个都不错了
社友者(37969986) 19:59:40
因为现在的投稿很少出现完全没变速的
道·Freefire(183203079) 19:59:43
从总体投稿的BMS来看的话,应该远远不止  
社友者(37969986) 19:59:51
一碰到变速的,这办法就行不通了
道·Freefire(183203079) 19:59:53
只能说,如果是RO的话,估计没啥用  
道·Freefire(183203079) 20:00:13
包括DB这种比较喜欢渐进缓冲变速的  
社友者(37969986) 20:00:34
就说新手的变速吧,新手不会用RO那种级别的变速,我就简单举例,某个地方旋律缓慢,新手整体来个0.5倍BPM,这怎么办
道·Freefire(183203079) 20:01:30
那段直接跳过就行了  
道·Freefire(183203079) 20:01:35
做的人应该自己有数的  
社友者(37969986) 20:01:48
所以你还得去查这段对应在记事本里是什么位置
道·Freefire(183203079) 20:01:54
不过如果在0.5BPM的段落出现压音问题的话,就不行了  
社友者(37969986) 20:02:02
是啊
道·Freefire(183203079) 20:02:02
我先重启  
社友者(37969986) 20:02:16
所以说实用性太低

TOP

返回列表