Organya (org) is a custom music tracker format created by Pixel in 1999 as an improved version of his other music format - Pixel Music Data(pmd), which was used by his other music editor PiyoPiyo. It is most prominently known for its use in Cave Story, but several other games use it, too, like Stargazer and Azarashi 2001.
The format allows the playback of 14-16 simultaneous channels, with 8 note polyphony and 6-8 different percussion instruments, depending on the player used.
Cave Story only allows 6 of the 8 available percussion tracks to be used, and each is hard-coded to a specific instrument. Changing percussion instruments in the editor will not affect which one will be used during playback ingame. Any notes put in tracks U and I will crash the game. These instruments are:
This is the case because unlike the org editors which use .wav samples for drums, Cave Story uses the .pxt (PixTone) format. This means that drum samples in Orgmaker2 can be replaced by downloading the source code and replacing the .wav files, but the other drum formats used in Cave Story will need to be edited using a PixTone editor, such as PixTone or SeaTone and can also be extracted via SeaTone’s sfx pusher.
Two original versions of the org editor have been released to the public, titled Orgmaker and Orgmaker 2, respectively.
The Orgmaker 2 editor allows for different drum instruments to be specified.
Several other community efforts have been made to update or completely replace these editors and add some missing quality-of-life features. A notable example of this is Orgmaker 3.
There is also a project called OrganyaMaker-16, whose initial goal was to double the number of channels from 16 to 32. Since it’s still in active development and may be unstable, its file format is not described in this article.
The ORG music file is in binary.
The instruments are baked into the reader (the file tells the player what instrument number to use)
The first 18 bytes are header info.
| Block offset (bytes) | Size (bytes) | Name | Description |
| 0 | 6 | Org Type |
This can be org-01, org-02, or org-03 and corresponds to the capabilities that the file has, such as fancy drums or using more tracks. However, starting with version v1.3.2, OrgMaker writes org-02 instead of org-01, regardless of whether pipi is used or not.
|
| 6 | 2 | Wait | Tempo. See Org Tempo. |
| 8 | 1 | Line | Number of beats per measure. Can also be thought of as the number of vertical "lines" the editor shows between each measure. |
| 9 | 1 | Dot | Resolution, number of notes in each beat. |
| 10 | 4 | Repeat_x | Start of repeat loop. These values are per “dot” individual note, despite the player only allowing these to be set at the start of each measure. |
| 14 | 4 | End_x | End of repeat loop. |
| Total size: | 18 bytes | ||
4F 72 67 2D 30 32 64 00 04 04 00 00 00 00 80 00 00 00
After this, there is a chunk of (16 (tracks, including drums AND notes) *6 (bytes of info each)), for a total of 96 bytes.
Structure of the info block for every track is as follows:
| Block offset (bytes) | Size (bytes) | Name | Description |
| 0 | 2 | Frequency | - |
| 2 | 1 | Wave_no | Waveform/percussion instrument. |
| 3 | 1 | Pipi |
Makes the selected instruemnt play in a pizzicato state. Only regarded if org type is org-02 or greater, otherwise is set to 0, is a binary value.
|
| 4 | 2 | Note_num | Total number of notes in the song from this track, including note modifiers, such as pan or volume events. |
| Total size: | 6 bytes | ||
E8 03 46 00 00 00 E8 03 46 00 31 00 E8 03 20 00 00 00 E8 03 00 00 00 00 E8 03 00 00 00 00 E8 03 00 00 00 00 E8 03 00 00 00 00 E8 03 00 00 00 00 E8 03 00 00 18 00 E8 03 02 00 08 00 E8 03 05 00 2C 00 E8 03 06 00 00 00 E8 03 04 00 03 00 E8 03 00 00 00 00 E8 03 00 00 00 00 E8 03 00 00 00 00
The file then goes by individual tracks, starting at track 0 and incrementing to 15 (covering all tracks)
Each track length has the note data in the following order, each piece of data is repeated by the number of notes in the track in question (I.E all the note values are written back-to-back for the first track, then all the pan values, etc.):
| Block offset (bytes) | Size (bytes) | Name | Description |
| 0 | 4 | X location | Placement of a note. |
| 4 | 1 | Y location | Key, doesn’t need to be as big of a number, 00 is low, FF is high, FF if the note does not exist (is instead a modifier event like pan/vol). |
| 5 | 1 | Note length | From X location, 01 if note is just something like a volume change. |
| 6 | 1 | Note volume |
0x00 is quiet, 0xFF is loud (it's given to undefined notes). Orgmaker limits this between 4 and 252.
|
| 7 | 1 | Note pan | Left pan is 0x00. 0x0C is right pan, given 0xFC if undefined. |
| Total size: | 8 bytes | ||
Each note has a total of 8 bytes allocated for it.
When all of the above data is read for each note in the track, the dataset for the next track is presented. If there are no notes in the track, it is skipped. There is no separator data between note data. There is also no termination value; the file ends with the last piece of note data.
Access.org uses only 1 non-percussion channel: channel 2. This means that the examples below represent the melody of everybody’s favorite Cave Story song.
00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 00 0A 00 00 00 0C 00 00 00 10 00 00 00 12 00 00 00 14 00 00 00 18 00 00 00 1A 00 00 00 1C 00 00 00 20 00 00 00 22 00 00 00 24 00 00 00 28 00 00 00 2A 00 00 00 2C 00 00 00 30 00 00 00 32 00 00 00 34 00 00 00 38 00 00 00 3A 00 00 00 3C 00 00 00 40 00 00 00 42 00 00 00 44 00 00 00 48 00 00 00 4A 00 00 00 4C 00 00 00 50 00 00 00 52 00 00 00 54 00 00 00 58 00 00 00 5A 00 00 00 5C 00 00 00 60 00 00 00 62 00 00 00 64 00 00 00 68 00 00 00 6A 00 00 00 6C 00 00 00 70 00 00 00 72 00 00 00 74 00 00 00 78 00 00 00 7A 00 00 00 7C 00 00 00 7E 00 00 00
26 26 2A 24 24 28 26 26 2A 24 24 28 26 26 2A 24 24 28 26 26 2A 24 24 28 22 22 26 20 20 24 22 22 26 20 20 24 22 22 26 20 20 24 22 22 26 20 20 23 25
01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06 06
ORG music can handle 1000 individual notes per second. The wait time is expressed in milliseconds, with the shortest time possible for a single note being 1 millisecond (having a wait value of “1”).
To convert BPM to “WAIT”, use the following formula:
60000/(BPM * NPB) = WAIT
To convert from “WAIT” to BPM, use the following formula:
60000/(WAIT * NPB) = BPM
Where:
WAIT is the time in milliseconds each note takes to play (ORG’s internal tempo format)NPB is the number of notes per beatBPM is the number of beats per minuteExample, with a new org file, the wait value is 128, with 4 notes per beat.
Plugging this in yields: 60000/(128*4)=117.1875
Converting 117 BPM back to WAIT yields: 60000/(117*4)=128.205
Note that ORG Wait time is in whole numbers only, so 128.205 would be truncated to 128.
Below is a list of songs created with an Organya Editor to show how it looks and sounds.