I'd like to expand
this demo by adding an option to change the "pitch" (i.e., the 16 different noise variations the NES makes) of the noise sample.
I've found that changing the sample rate (the default in the demo being 44100Hz) will change the "pitch" of the noise sample. With this in mind, what are the other sample rate values that the noise channel uses?
I'm beginning to think that just changing the sample rate is just another quick and dirty solution, since it doesn't make much sense. I'm still not totally convinced, though...
GrandonBroseph wrote:
I've found that changing the sample rate (the default in the demo being 44100Hz) will change the "pitch" of the noise sample. With this in mind, what are the other sample rate values that the noise channel uses?
See the table at
APU Noise. For example, entry 9 of the NTSC table is 254, so the sample rate would be 1789773/254 = 7046 Hz.
Ohh, so that's it? I guess all the numbers went way over my head. I've been looking at that table for a while now ._.
Unfortunately, AudioBuffers in the Web Audio API only seem to take values from 3 000 to 192 000. Entries 0 and F give total values of 439.964 and 447443 Hz, so am I out of luck? If so, I'm not too sure how JSNES did their sound sequencing. I thought they were using the Web Audio API, too...
I tried using 7046 as the value for $9. The sample sounds a lot lower and more gritty than that of FamiTracker, though.
Perhaps I need an extra calculation?
For rates lower than about 15 kHz, you might get better results by writing each sample twice and playing at twice the rate.
Okay, I'll try that. What about the higher ones?
Unless you're using periodic noise, periods 0, 1, and 2 just sound like quieter versions of period 3. So you can compose your sound effects without using periods 0, 1, and 2.
That's true.
For rates lower than about 15 kHz, you might get better results by writing each sample twice and playing at twice the rate.
This just means that for entries $C to $F I should play two samples at twice the rate simultaneously, right?
No... since the web audio API doesn't support resampling below 3kHz, you'll have to resample the input yourself.
If the input wave were, say,
__~~_~~_~~~___~~~~~_~_~_~~___
and you wanted to play it back at 440Hz (just for example), ceil(3000÷440)=7, so repeat each input 7 times:
______________~~~~~~~~~~~~~~_______~~~~~~~~~~~~~~_______~~~~~~~~~~~~~~~~~~~~~_____________________~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~_______~~~~~~~_______~~~~~~~_______~~~~~~~~~~~~~~_____________________
and then play it back at 440×7=3080Hz.
Oh wait, yeah. That makes a whole lot more sense.
Interesting hack, should have thought of it earlier though. >_<
EDIT: By the way, why the use of 3kHz in the calculation of 7?
No particular reason; it's just the lowest one that the JS audio API supports. You could pick anything in the supported range.
Okay, that actually makes sense, I guess.
This version of the demo contains a sample played at 3079 Hz and seems to match FamiTracker's 0 entry, but with really, really low quality. Am I missing something?
Quality too low? Double it again! It'll only cost you more memory.
Wow, that worked! Everything is almost totally accurate, except for when the bit sequence is shortened to 93 steps. It lets out this really shrill sound as opposed to the normal buzzing. I'm assuming that it has something to do with the new quality multiplier...