Cracking the Code - Organya Reloaded

I apologize for the topic title and hereby take responsibility for any brain damage cause by it.

I've been looking at an ORG I made of the FF3 battle music - it's only three instruments, and they don't vary in panning or volume, so it, in theory, should be easier to identify the notes. So far the only pattern I can find is what appears to be a header, and then three sections corresponding to each of the three used channels(I think).

Each of these sections is made up of two parts - first, a pattern split into four values a section, where the first value increases by 2 each repetition, and the latter three values are all either 00 00 00 or 01 00 00. The thing is, on my first instrument, which starts right off at the very beginning of the song, has a bunch of blanks and then a bunch of the 01 patterns. I can't find anything that really defines the note. Really, the only reason I know it's the first instrument is that I randomly changed one of the 00s to 01 00 00 (in the pattern) and when opened in Orgmaker it was all bugged - the notes didn't even display until you got to a certain bar, and when they did show up they dissappear if you go too far back again, and they, essentially, don't exist.

The second part of each instrument is a block of different values, then about two blocks of different values, then it moves on to the next instrument.

Woah. While reading this I just realized - the first block in the second part corresponds to the notes, and I assume the second and third blocks are volume and panning, although I'm not entirely sure. What I think it is is that the first part uses that 01 as part of a counter, because I just noticed the 01's start after the first counter (that increases by 2) hits F8.

Alright, I can now confirm a few things (It's relatively easy to figure this format out for the most part, I've found out over the last 20 minutes of actually trying. )

Each instrument is split up into two parts - one part with the 00 00 00's and 01 00 00's that I do not know about yet. The other part is made up of a few blocks whose length varies by the length of the instrument(I assume). That part is made up of a few blocks:

-The first block of values defines the actual note. 5F is the highest note possible, and 00 is the lowest. This is for each actual instance of a note, and not each step. You'll know why in a second...
-The second block defines the length of each individual note. The values are simple - 01 for a length of 1 step, 02 for 2, etc. This is how you can get a sustained note and only have one entry in the first block.
-The third block defines volume for each note. Volume seems to only be able to go up to F8 - values any larger show up blank in OrgMaker.
-The fourth block is panning - a value of 06 is center, and it goes from 00 to 0C.

After that the next instrument's section is up. One thing to note is that the next section moves by 4 instead of 2. Read my next post.

 

Nice work. Looks like you're well on your way to seeing this through!

http://jedi.ks.uiuc.edu/~johns/links/music/midifile.html

The midi specs. It's a relatively simple format, but goes a weeee bit further than ORG seems to go (which is good - the opposite would mean data loss from things that can't be converted into the other format.) MIDI is a very event-based format and it's more like a script than a list of notes (though most of the time, you'll be dealing with notes anyhow.)

A 1-1 conversion seems possible. Very good detective work. If I find anything in the game's source that bears mention, I'll bring it up (I've found where the change and restore music events take place and fully decoded them, but I haven't looked at the actually music playing routine yet. I'll give it a peek..)

 

I had meant to edit my last post but might as well put it here.

For conventional purposes, Section A is the part of each instrument I have yet to figure out, while Section B is the section containing the notes, volume, etc. that I DO know.

Section A is very strange. In the first instrument, it progresses pretty normally - add 2, if it's above F8 add one to the second value and restart at 00. On the second instrument, however, it gets a little interesting.

The best way to describe it is to show it:

20 00 00 00 2C 00 00 00 30 00 00 00 3C 00 00 00 40 00 00 00 44 00 00 00
48 00 00 00 4C 00 00 00 50 00 00 00 52 00 00 00 60 00 00 00 64 00 00 00
68 00 00 00 6C 00 00 00 70 00 00 00 74 00 00 00 78 00 00 00 7C 00 00 00
80 00 00 00 84 00 00 00 88 00 00 00 8C 00 00 00 90 00 00 00 92 00 00 00
94 00 00 00 96 00 00 00 98 00 00 00 9A 00 00 00 9C 00 00 00 9E 00 00 00
A0 00 00 00 AC 00 00 00 B0 00 00 00 BC 00 00 00 C0 00 00 00 C4 00 00 00
C8 00 00 00 CC 00 00 00 D0 00 00 00 D2 00 00 00 E0 00 00 00 E4 00 00 00
E8 00 00 00 EC 00 00 00 F0 00 00 00 F4 00 00 00 F8 00 00 00 FC 00 00 00
00 01 00 00 20 01 00 00 28 01 00 00 30 01 00 00 38 01 00 00 40 01 00 00
42 01 00 00 44 01 00 00 46 01 00 00 48 01 00 00 4A 01 00 00 4E 01 00 00
50 01 00 00 52 01 00 00 54 01 00 00 56 01 00 00 60 01 00 00 68 01 00 00
70 01 00 00 78 01 00 00 80 01 00 00 82 01 00 00 84 01 00 00 88 01 00 00
8A 01 00 00 8C 01 00 00 90 01 00 00 92 01 00 00 94 01 00 00 98 01 00 00
9A 01 00 00 9C 01 00 00 9E 01 00 00 A0 01 00 00 B0 01 00 00

Sometimes it's adding 8, sometimes 4, sometimes... bah. I do have a hunch that it has to do with note position, though...

Yep, I was right - I now know what Section A is for - it defines the actual position of the notes. Each 4-byte group corresponds to a single position in the song - Each step is equal to 01 on the first byte. 00 01 00 00 is equal to the beginning of bar 16 in OrgMaker - Each increase in the second byte will jump you forward 16 bars.

So now we have everything mapped out but the header - I'm more or less confident the header defines the instruments, tempo, etc.

 

Examining the header, I find that it has 16 6-byte long entries at the end of it (right before Section A begins for the first instrument) - Only the first three are different from the rest (The default being E8 03 00 00 00 00). So I can safely say those define the instruments.

The header begins with the string "Org-02", which I believe defines it as an ORG made by OrgMaker, although the -02 is a mystery, it is present in all other Orgs, so it's just a string. After that follows 12 bytes that define various parameters for the Org. I'll be listing them as they follow the string (Number 1 being the first byte after the header string[I'm not versed in how you're supposed to identify hex values properly, so I'm doing the best I can ]):
1 through 2. Tempo - the tempo value for the song, entered in OrgMaker. Is a 2-byte value.
3. Steps - Number of steps per bar. For display in OrgMaker
4. Beats - Number of beats per step. For display.
5 through 8. Beginning of Loop - Defines where to begin looping. Goes by beats, because if you change the display in OrgMaker, a bar can have different lengths, and you can only repeat by bar in OrgMaker. Is a 4-byte value.
9 through 12. End of Loop - Defines where to end looping. Is a 4-byte value.

Now I've got the header deciphered except for the format of the instruments. My next post will be on those.

 

I'm quite confident the instruments are in the exact same format sounds are. They're basically up to 4 channels consisting of various parameters for waveforms.

Have you given any thought how you'll make it convert to/from MIDI?

 

Instruments are stored in 16 6-byte long entries at the end of the header. Each entry contains the following:

Bytes 1 and 2 - Defines the pitch, which is a 2-byte entry. Defaults to 1000.

Byte 3 - A hex number defining the instrument - 29, for example, will point to instrument 41.

Byte 4 - Toggles whether "Pi" is on or off (01 and 00, respectively). For those that don't know, Pi disables sustained notes and only plays the first beat, like a lil' beep.

Byte 5 and 6 - This is a 2-byte value counting the number of times an instrument is played in the entire song - this is what defines how long the file is going to be(I don't know if that's it's real function, but that's what it does). Sustained notes count as one note. Maxes out at 4096 (00 01 in hex).

And that's it. That's everything there is to know about the format of an ORG file.

Phew. Maybe now someone can make the converter.

EDIT: If you meant various parameters as in "How the sine wave is formed", then no, it's not. But it does have parameters for each sound, yes.

If I do make the converter, it'll be in VB6 - it's the only programming language I'm comfortable enough with to try it in. I do have a compiler and all that, so that's not a problem. I just dunno if I can get my head around the Midi format - I probably can, but it'll take me time.

There's also the problem of drums in a Midi - most people use a single channel, but OrgMaker uses 8 seperate ones. I can't begin to think of how you'd be able to change it up.

I welcome anyone to try their hand at it by themselves though - I'm just happy I even got this whole thing done. And you guys throught all I did was make music.

 

Attached is a more organized description of the ORG format and the different sections. I've tried to be as specific as possible, but if anyone finds anything confusing, please simply point it out and ask. The guide assumes that the reader has a bare-bones understanding of hex and hex editing/writing to a file in hex.

Perhaps this could make it onto the site?

 

Alright! I've got the translation back of the menus in OrgMaker 2.0.5. I've figured out almost all of the functions.

I'm going to be playing ToS for most of the rest of the day, so if anyone could help me with one thing - the function below normal open. It's labeled with a (P) and it's shortcut is Backspace. It translates to "Open With Specific Dialog". Anyone have any idea as to how this is different from the normal open?