Hello again c:
I have made decent progress:
1. I managed to extract the samples from Org Maker 1, and fixing them (The header of the wave files was incorrect,
and thus wouldn't load, however I was able to fix that thanks to Noxid)
2. I debugged OM 1 just to make sure the frequencies were the same (they are, and just like OM 2 they use a intermediate waveform)
This leaves me one last question before I can finish my work:
What would be the BEST way to convert the raw wavedata to .wav (more specifically, the C3 frequency?
Replicating the intermediate waveform didn't work (As i've mentioned in an earlier post)
and recording the waves in audacity is more than just troublesome. (for obvious reasons)
My current plan is to split the wavedata up, and then import it into audacity with the samplerate 66816 (C frequency * 2),
which would result in the desired tone.
But what do you think? Any suggestions would be appreciated.
Aside from that, there's another thing that's been bottering me:
Octave 2's intermediate waveform is 256 points long. Every wave in the wavedata is 256 bytes long.
So why is every other sourcepoint used twice, instead of just using every sourcepoint once? It makes little sense to me.
I have made decent progress:
1. I managed to extract the samples from Org Maker 1, and fixing them (The header of the wave files was incorrect,
and thus wouldn't load, however I was able to fix that thanks to Noxid)
2. I debugged OM 1 just to make sure the frequencies were the same (they are, and just like OM 2 they use a intermediate waveform)
This leaves me one last question before I can finish my work:
What would be the BEST way to convert the raw wavedata to .wav (more specifically, the C3 frequency?
Replicating the intermediate waveform didn't work (As i've mentioned in an earlier post)
and recording the waves in audacity is more than just troublesome. (for obvious reasons)
My current plan is to split the wavedata up, and then import it into audacity with the samplerate 66816 (C frequency * 2),
which would result in the desired tone.
But what do you think? Any suggestions would be appreciated.
Aside from that, there's another thing that's been bottering me:
Octave 2's intermediate waveform is 256 points long. Every wave in the wavedata is 256 bytes long.
So why is every other sourcepoint used twice, instead of just using every sourcepoint once? It makes little sense to me.
Sorry if my notes were unclear. I wasn't trying to say that at all. In my sheet, where I have a1* and a5*, the * note represents the transition between the a1 and the a5: "These two are different". All the other note marks in my sheet work the same way, they mark the two items before and after the change the note is talking about.
> Now I saw a lot of instrument differences between OM2 J and E, so I believe they're named differently? (OM2 J TOM03 = OM2 E TOM01?) I believe that's something you fixed in the translation process, as OM1 TOM01 = OM2 E TOM01)
Correct. I didn't describe this in the sheet and assumed the reader would already be familiar with it. This situation is always challenging to explain in words. Here are some previous documents and posts where I explain this:
1. In org210x.zip, open drums.htm, then go to the bottom section that says "More information".
2. "I'm talking about the sound swaps Bass01/Bass04, Snare01/Snare03, Tom01/Tom03, HiClose/HiClose02, and HiOpen/HiOpen02.": http://www.cavestory.org/forums/threads/orgmaker-2-1-0-english-translation-in-progress.5584/#post-186967
3. "some of the sounds (the actual waves that define the sound) are switched to different names.": http://www.cavestory.org/forums/threads/orgmaker-2-1-0-english-translation-in-progress.5584/page-2#post-209675
> WAVE100 from OM2 (2.05) J/E are slightly different, so that might be Xaser's "fault"
From what I remember, Xaser only rearranged the drum resources in OrgMaker 2.0.5 Japanese so the Cave Story drum sounds once again matched their names OrgMaker 1, undoing the sound swaps that Rxo Inverse introduced as described above. Besides this re-arrangement, from what I remember, the resources in OrgMaker 2.0.5 English (Xaser or Bavi_H) are the same as OrgMaker 2.0.5 Japanese, so I guess it was Rxo Inverse who made the slight changes to the wavedata from OrgMaker 1. (On the other hand, maybe Rxo had access to an internal unreleased OrgMaker from Pixel that was in the process of being updated, and it was Pixel who made the wavedata changes? We just know OrgMaker 1 and 2 have slightly different wavedata.)
continued...