Me and a friend tried to replicate the Intermediate waveforms for Octave 3, and I compared it to a recording of OrgMaker, however the differences were extremely obvious. This is both extremely fascinating and frustrating (I know you didn't make OrgMaker, but well, I'm basing my tests on your notes, as I've said)
Cave Story Tribute Site Forums
OmegaFoxie
SuperJaws100
I have noticed that ORGs sound slightly different when put into the .exe as well. I always figured it was just because the playback method in Doukutsu.exe was more primitive than the one in OrgMaker 2. I never expected the WAVs to be different.
OmegaFoxie
Yeah. I assume Rxo Inverse (the person that made OrgMaker 2) edited the waves slightly
Bavi_H
> Have you ever done any testing with the wavedata from Doukoutsu.exe, since it's different from the OrgMaker one?
Yes. Back in late 2010 and early 2011, I extracted and compared the resources from Cave Story (Doukoutsu.exe), Cave Story BGM Player (dou_bgm.exe), OrgMaker 1.3.4 Japanese or English (Org134_.exe), OrgMaker 2.0.5 Japanese by Rxo Inverse (Org205.exe), and OrgMaker 2.0.5 English translation by Xaser (Org205x.exe).
I revisited my notes in late 2011, and then again in April 2013 to make minor revisions (changing how the letter-number codes in my notes worked, and describing some things better so I wouldn't forget what they meant).
Here is the last spreadsheet from April 2013 in PDF format: rnhart.net/orgmaker/resource-comparisons.pdf
> I compared them [the wave data from Doukoutsu.exe and OrgMaker] in Audacity, and aside from some minor, but noticeable differences in the waves, they mostly seem to differ in volume
In my spreadsheet, I wrote: "These two wave data" [Cave Story or OrgMaker 1 vs OrgMaker 2] "aren't bit-for-bit identical, but I can't hear any perceptible difference." I don't remember if I took volume into consideration, but it looks like I came to a similar conclusion as you did.
Yes. Back in late 2010 and early 2011, I extracted and compared the resources from Cave Story (Doukoutsu.exe), Cave Story BGM Player (dou_bgm.exe), OrgMaker 1.3.4 Japanese or English (Org134_.exe), OrgMaker 2.0.5 Japanese by Rxo Inverse (Org205.exe), and OrgMaker 2.0.5 English translation by Xaser (Org205x.exe).
I revisited my notes in late 2011, and then again in April 2013 to make minor revisions (changing how the letter-number codes in my notes worked, and describing some things better so I wouldn't forget what they meant).
Here is the last spreadsheet from April 2013 in PDF format: rnhart.net/orgmaker/resource-comparisons.pdf
> I compared them [the wave data from Doukoutsu.exe and OrgMaker] in Audacity, and aside from some minor, but noticeable differences in the waves, they mostly seem to differ in volume
In my spreadsheet, I wrote: "These two wave data" [Cave Story or OrgMaker 1 vs OrgMaker 2] "aren't bit-for-bit identical, but I can't hear any perceptible difference." I don't remember if I took volume into consideration, but it looks like I came to a similar conclusion as you did.
Bavi_H
> Me and a friend tried to replicate the Intermediate waveforms for Octave 3, and I compared it to a recording of OrgMaker, however the differences were extremely obvious.
I'm happy you found my tests interesting! It seems like you tried re-create my tests, but your results didn't agree with mine? Can you explain more about what differences you saw? Here are some thoughts:
Intermediate waveform creator unclear
Regarding the intermediate waveform method I described on my page rnhart.net/orgmaker/pitch.htm , be aware that I'm not sure how much of that is caused by OrgMaker itself, and how much of that is caused by the operating system (DirectSound and so on). I didn't dig into OrgMaker enough to find out if OrgMaker was making the intermediate waveform entirely by itself.
(On the other hand, I know the wave playback rate is selected by OrgMaker, because I found the parts in OrgMaker that call the DirectSound function SetFrequency and captured what number values OrgMaker was sending to that function.)
If your intermediate waveform tests don't agree with my results, maybe the DirectSound part on your computer is working differently than mine was, or maybe we're not testing the same way or not understanding each other's results the same way.
Recordings are not exact
Were you frustrated because the intermediate waveform you generated and your recording didn't match exactly match point-for-point?
I don't think you can confirm the exact intermediate waveform pattern points from a recording. My understanding is the data you see in a recording is the output after your sound card has done "resampling", and possibly also went through a digital-to-analog-to-digital path. The output recording won't match the intermediate points exactly point by point.
For example, on my page rnhart.net/orgmaker/pitch.htm , if you go down to the section "Testing Procedure", you can see my test wave has "perfect" shapes, but the first recording has little squiggles in places the test wave (opened as signed 16-bit big endian) was perfectly flat, and the second recording doesn't reach the zero point exactly every time, like the test wave (opened as signed 8-bit) did.
That's why I ended up using that test wave. It had a carefully chosen shape so I could still make out the overall shape in the final recording after all the squiggles, distortions, and flipping upside-down that got added along the way.
I'm happy you found my tests interesting! It seems like you tried re-create my tests, but your results didn't agree with mine? Can you explain more about what differences you saw? Here are some thoughts:
Intermediate waveform creator unclear
Regarding the intermediate waveform method I described on my page rnhart.net/orgmaker/pitch.htm , be aware that I'm not sure how much of that is caused by OrgMaker itself, and how much of that is caused by the operating system (DirectSound and so on). I didn't dig into OrgMaker enough to find out if OrgMaker was making the intermediate waveform entirely by itself.
(On the other hand, I know the wave playback rate is selected by OrgMaker, because I found the parts in OrgMaker that call the DirectSound function SetFrequency and captured what number values OrgMaker was sending to that function.)
If your intermediate waveform tests don't agree with my results, maybe the DirectSound part on your computer is working differently than mine was, or maybe we're not testing the same way or not understanding each other's results the same way.
Recordings are not exact
Were you frustrated because the intermediate waveform you generated and your recording didn't match exactly match point-for-point?
I don't think you can confirm the exact intermediate waveform pattern points from a recording. My understanding is the data you see in a recording is the output after your sound card has done "resampling", and possibly also went through a digital-to-analog-to-digital path. The output recording won't match the intermediate points exactly point by point.
For example, on my page rnhart.net/orgmaker/pitch.htm , if you go down to the section "Testing Procedure", you can see my test wave has "perfect" shapes, but the first recording has little squiggles in places the test wave (opened as signed 16-bit big endian) was perfectly flat, and the second recording doesn't reach the zero point exactly every time, like the test wave (opened as signed 8-bit) did.
That's why I ended up using that test wave. It had a carefully chosen shape so I could still make out the overall shape in the final recording after all the squiggles, distortions, and flipping upside-down that got added along the way.
OmegaFoxie
First off all, thanks for the very informative response!
Now I should clarify, the reason I'm running these tests is because I want to find the optimal way to extract the Wavedata to .wav format
Since I'm going for the C3 pitch, since that's the "normal" pitch in OrgMaker, I tried
- Recreating the intermediate waveform, which ended up looking and sounding pretty badly, plus we (me and a friend) couldn't find an easy way to edit the files like that, so we gave up on that
- Importing at C frequency (In Audacity) and then applying the Speed effect
- Importing at double frequency, thus giving us the C3 tone, however this left us with a ludicrous samplerate of 66816, and I don't want to resample.
When I say optimal way I mean the closest to original (Either OM or CS sound) you could also say I'm trying to find the most lossless way
The two thoughts you presented me are very plausible and definitely pushed me further away from the recording method, so that's definitely out of the race for me.
I looked at the resource comparison sheet and a few things stood out to me:
You said WAVE100 from CS / BGM is slightly different from OM1, yet I checked them again, in various ways, and they seem to be exactly the same. It's funny because you labeled it a1*
WAVE100 from OM2 (2.05) J/E are slightly different, so that might be Xaser's "fault" (though I can't actually check if they're different as I can't find downloads for 2.05)
I assume this doesn't apply to OM2 2.10, which isn't listed in the sheet so it's not relevant right now anyway
BASS02, BASS03, CRASH, PER02, SNARE02, TOM02 are not present in Cave Story? I also looked at the Japenese Cave Story and couldn't even find the .wav samples, only the wavedata (looked both in data folder and in the executable itself) [EDIT: As I was writing this I looked at the comparisons I saw that the instruments in CS are stored as PixTone data, which would explain why I didn't find them) But I'm pretty sure they're used in both Cave Story and BGM (they're also included in CS+ but that's not relevant)
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)
The remaining instruments are the same between OM2 J and E, so those can be disregarded easily
I think that's all for now
Now I should clarify, the reason I'm running these tests is because I want to find the optimal way to extract the Wavedata to .wav format
Since I'm going for the C3 pitch, since that's the "normal" pitch in OrgMaker, I tried
- Recreating the intermediate waveform, which ended up looking and sounding pretty badly, plus we (me and a friend) couldn't find an easy way to edit the files like that, so we gave up on that
- Importing at C frequency (In Audacity) and then applying the Speed effect
- Importing at double frequency, thus giving us the C3 tone, however this left us with a ludicrous samplerate of 66816, and I don't want to resample.
When I say optimal way I mean the closest to original (Either OM or CS sound) you could also say I'm trying to find the most lossless way
The two thoughts you presented me are very plausible and definitely pushed me further away from the recording method, so that's definitely out of the race for me.
I looked at the resource comparison sheet and a few things stood out to me:
You said WAVE100 from CS / BGM is slightly different from OM1, yet I checked them again, in various ways, and they seem to be exactly the same. It's funny because you labeled it a1*
WAVE100 from OM2 (2.05) J/E are slightly different, so that might be Xaser's "fault" (though I can't actually check if they're different as I can't find downloads for 2.05)
I assume this doesn't apply to OM2 2.10, which isn't listed in the sheet so it's not relevant right now anyway
BASS02, BASS03, CRASH, PER02, SNARE02, TOM02 are not present in Cave Story? I also looked at the Japenese Cave Story and couldn't even find the .wav samples, only the wavedata (looked both in data folder and in the executable itself) [EDIT: As I was writing this I looked at the comparisons I saw that the instruments in CS are stored as PixTone data, which would explain why I didn't find them) But I'm pretty sure they're used in both Cave Story and BGM (they're also included in CS+ but that's not relevant)
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)
The remaining instruments are the same between OM2 J and E, so those can be disregarded easily
I think that's all for now