bemusic/bmson-spec

Technical specification for bmson format

bmson-spec's Issues

Standardize package distribution on web (also applies to BMS)

Criteria:

• Easy to create.
• Easy to distribute.
• Playable on web?

---

Syndication

How to list available songs?

• Bemuse: Custom index.json file.
• CircularRhythm: Custom index.json music.json file.

Another alternative would be to use an Atom feed or RSS feed, like Podcast. Either as an <enclosure> or <link rel="enclosure" or a new XML namespace.

Package Style

Both Bemuse and CircularRhythm are using custom file format to save assets.

An alternative would be to use ZIP files:

1. Single ZIP file containing everything.
   • Have to redownload whole set on network error.
   • Have to redownload whole package when I want to add extra charts.
   • Have to download video when not needed.
2. ZIP archive containing resources, while note files are outside.
   • Have to redownload whole set on network error.
   • Multiple files to send.
3. A sequence of multiple ZIP files. Files in later archive overrides file in previous archive.
   • Multiple files to send.

Some problem with ZIP files:

• Don't know in advance which files are inside which ZIP file. For example, if player doesn’t support BGA it shouldn’t download bga.zip. May need to generate extra metadata file for web distribution.
• File name encoding problem.
• Browser may crash processing large ZIP files.

Scratch Freestyle Zone

Proposed by @mechacrash to me.
This idea is taken from classic beatmania.

It is a kind of longnote that only appears on turntable.
Instead of continuing to spin the turntable, you can scratch as you will.

Should we include this in the specification, or make implementation player-dependant?

Unspecified case of BPM <= 0

The standard does not explain how the case of bpm <= 0 should be dealt with.
I believe the case should be that:

• BPM < 0: Backwards scroll.
• BPM = 0: Invalid BPM.

Opinions?

Support: WebM

Requesting support for WebM.
https://www.webmproject.org/

Support: FLIF

Requesting FLIF support for bmson. It seems this format is much smaller than super compressed PNG, and its free licensed.
http://flif.info/

About MIDI key sound support

Hi, recently I heard new bms emulator is working in progress and I'm very glad to hear that. But I found there's no support about midi related support(like keysound pitch ...) in bmson format.
Recently I'm working on with *.vos format, which is quite old rhythm game char format based on midi, personally, and I'm integrating that format with my own project. And as vos format is quite old one, I was planning to export this file in 'new playable file format I'm developing myself', and now I'd more like to export as bmson format.

I wish this new bms format, bmson, can support midi file format for playing, as there's no reason to unsupport. just more metadata and pitch data can make bmson format support midi.

Add specifications about a new kind of LN(MSS)

Original game will add a new kind of LN(MSS).

Reference URL

I used the idea of LN key-up sound (#9) as a way to achieve this: allow "up": true for LN objects.

LN1 is a regular LN.
LN2, has "up": true, overlaps LN1.
Due to "up": true, the player will know that LN2 is a MSS object and not a regular LN.

In this way, it is possible to have a Normal Charge section and a Hell Charge section coexist in the same MSS.
For example, in the image above, if we change LN2 to "t": 3, SP1 will be the Normal Charge section and SP2 will be the Hell Charge section.

The text up to this point has been translated using an automatic translation site (deepl.com). The following is the text before translation.
ここまでの文章は自動翻訳サイト(deepl.com)を用いて翻訳されました。以下に翻訳前の文章を示します。

オリジナルゲームに新種のロングノーツ(MSS)が追加されるそうです

参考URL

これをbmson上で再現する方法として、LN key-up sound (#9)のアイデアを用い、LNにも"up": true を用いることを提案します。

LN1 は、通常のLNです。
LN2 には"up": trueがあり、LN1と重なっています。
"up": trueがあるので、再生ソフトはLN2が通常のLNではなく、MSSオブジェクトであることがわかります。

このようにすることで、同じMSS中に通常のチャージ区間とヘルチャージ区間を共存させることができます。
例えば、上の画像でLN2を"t": 3に変更すると、SP1は通常のチャージ区間に、SP2はヘルチャージ区間になります。

TODO List

• Prettify
  • Includes removal of line length limitation
• Recover code block
• Fix in-page links
• Resolve in-doc TODO
• Rename image

Bombs

Notes which remove HP when hit do not have a standard specification on bmson yet.
Given their popularity, I believe we should have a way to specify bombs, whether we'll use a sliced sound (or affect the cutting algorithm at all) or similar.
Besides, I think people have used tricks to do Bombs with special sounds so should we look into this use case as well?

LN key-up sound

zardoru, wosderge, flicknote, suitougreentea, exclusion and I discussed the addition of this in a DM conversation on Twitter.

The idea is simple: The ending point of a LN plays a sound when the player releases the key.
This lets us emulate back-spin scratch from IIDX where a new sound is played at the note release, and it also offers more variety and interesting possibilities for chart creation.

Pictured above:
note1 with l: 240 is a regular long note.
note2 with up: true overlaps note1
Due to up: true, the player will know that note2 is a key-up sound and not a regular note.
note2 may also be in a different sound channel than note1. Like so:

Some key points from the discussion:

• Most people agreed that this is a natural extension of "layered notes", which is already a feature in bmson.
• flicknote said the "up" event is redundant, however suitougreentea explained that we can not trust that all implementations will consider note1.y + note1.l == note2.y as an overlap. We should make it explicitly clear that there is an overlap to ensure that all implementations are similar.

Standardize LN type

Currently it is up to the player to decide which LN type the chart will use. (LN, CN or HCN).
exch implemented an unofficial solution to this in beatoraja which determines LN type per note.

However I think specifying LN type per note becomes quickly tedious and it is also very confusing for the person playing the chart if it mixes LN types.

I would like to propose a global command that specifies the LN type for the entire chart instead of each individual note.

ln_type: 1/2/3
1 = LONG NOTE
2 = CHARGE NOTE
3 = HELL CHARGE NOTE

Other timing classes

Besides BPM/Stops, I think it would be a good idea to add to the spec a standard specification for new timing classes featured in Stepmania and recently osu!mania:

• Speeds
• Scrolls
• Warps

Initial proposition would be to { Time: pulse, Value: pulses_to_skip }
for Warps, and adopt the stepmania initial value, final value, start time and duration specification for speeds and just use the multiplier for scrolls.

Parameterized timing window & life delta values

I know this is really specific but I'm making a game in which each chart can have custom timing window values (Delta in Pulses), like this:
"judgement_deltas": { "KOOL": 5, "COOL": 18, "GOOD": 40, "MISS": 56 }

And the same but for life like this:
"life_deltas": { "COOL": 0.2, "GOOD": 0.1, "MISS": -2.0, "FAIL": -5.0 }

Edit: for the timing they're symmetric but we can just make "JUDGE": [-10,+5] for asymmetry. (Like in 2DX)

Ogg support extend: OPUS codec

Opus provide more effective quality and impressive compression than ogg with major browser support

Especially, opus 1.2 highly improve the music quality with same bitrate. even just 32kb/s, opus still save good quality.