All floats is of the IEEE 754 type.
All integers is storaged with the Most significant byte first and the Most significant bit first in each byte.
First in the file comes the Song title, encoded in UTF-8. The songtitle is terminated with a Byte that has the value 0.
Afterwards comes the Artist of the song, encoded in UT-8. The artist is terminated with a byte that has either the value 0 or the value 1.
If the terminating byte for the song artist was 0, skip the next paragraph
If the terminating byte was 1 instead, the transliterated song title and author comes, in the same format as the normal tile and artist, save that they are both always ended with a byte that has the value 0.
Then a 2 byte float number follows, specifying the initial delay until the steps starts.
afterwards the bpm data for the song comes,
the bpm data is storaged as pairs of 4 byte values, each pair thuse being 8 bytes in size.
The first value is the beat where the bpm changes and the second value is the new bpm.
The values is both stored as floats according to that IIEEE standard for floats.
The bpm data is terminated when a bpm change specifies NaN/NULL as the new beat.
If a display bpm override is wanted, the lower bpm is stored as a bpm change at beat -20 and the higher bpm is stored at beat -19. An end for the display range that is marked as random has the bpm change set to Infinity.
Stops is encoded in the bpm data as times where the BPM is 0.
Afterwards the song file name is stored, again as UTF-8 with a terminating 0 byte.
Following this pattern, the lyrics filename, the instrumental music file name and any keysound filename follows.
If any of them is not used, the file name is directly ended with a 0, creating a 0 length string.
Afterwards the bgchanges comes.
The two byte is the beat when the change should happen.
Each change begins with a signed integer specifying when the bg change is to occur.
Following is a byte specifying what bgchange type it is.
The special type 0 means that there is no more bgchanges.
IF the value is not 0, the parameters for the bg change follows.
It is up to each change to specify the following bytes until the next bgchange.
The only currently defined change is the replace change.
It takes one unsigned byte, the layer id and an UTF-8 string terminated with a 0 byte determinating the new bg for that layer.
There is a special string that is used to represent the builtin animations. It is "<builtin>", without the quotes, but with the less then and greater then characters.
Then the stepcharts follows.
Each stepchart begins with some bytes of identifying data.
The first nibble(half a byte), also known as the high half of the byte, is a number representing the game type the chart is for.
The Value 1 means the Dance type. Type 15 is reservated for the lights type. More types to be added as needed.
The set of stepcharts is terminated with the end of the file
The second nibble, also known as the lower half of the byte, is the difficulty level of the steps.
Any undefined value is to be treated as an edit difficulty stepchart.
The values 1,2,3,4 and 5 is beginner, easy, normal, hard, and challenge, in that order.
It is valid to have more then one stepchart with the same difficulty for the same gametype and song.
The next nibble, high half of the byte is the foot count minus one.
The other nibble, the low half of the byte is a bit field.
The bits are in order:
1 to be selectable for normal play, 0 to not be
1 to have bpm overrides for the song, 0 to not have them
1 to have scripting, 0 to not have scripting
1 to have forced mods, 0 to not have forced modifiers
if the stepchart is marked to have bpm overrides, they follow here, same format as for the main bpm changes. Note, the initial delay before the steps is the same for all stepcharts.
if the stepchart is marked to have scripting, an UTF-8 encoded string, terminated with a byte with the value 0 follows, that contains the script.
if the stepchart is marked to have forced modifiers, they follow here
each modifier is one or two bytes.
the first byte is the modifier type.
The only defined modifier at this time is the special end of modifier list modifier, that has the id 0.
Modifiers that is two bytes in length must have the first bit on the first byte set.
The secound byte of the modifier is either extra length of the modifier id, or one byte of info for the modifier.
then the actual notes follows.
Each note line has the format of
one or more nibbles representing each receptor
the nibbles has the following values:
0, nothing
1, normal tap
2, hold start
3, hold end
4, roll start
5, lift start
6-14, reservated for future use
15, invalid
each note line is always one or more whole bytes, with an padding nibble if needed
A note line is terminated with a byte with the first nibble, the high half of the byte, set to 15 this is why a note may not have the value 15.
The second nibble, the lower half of the byte determinates what sort of note line the next note line is:
0, normal note line
1, on beat note line
15, end of stepchart