in what world can a headache-inducing tone be used to your advantage in your music? I'll believe it when I hear it.
I experimented with using the 15khz noise to augment noise hats and cymbals by throwing the lowest A at volume 1 on the attack of a hat and the sizzle part of a crash. 15khz is part of a frequency band that gets boosted sometimes when mixing drums to boost presence and airiness of the cymbals.
It worked decently enough, it made things sound a bit more sparkly and live but was still a tad harsh, even when turned down to 1.
I tried the same with 7 channels, but the new noise frequency was lowered enough that it was completely useless for this effect; down to like 9khz or something.
Next, we gotta find out if the switching hiss is not only tied to # of N163 channels, but also the NES clock rate :D Can we lower/raise the 15kHz using 40/400hz XD
It is the NES CPU clock frequency divided by 15, then divided again by the number of channels used.
i.e. 1789773 hz / ( 15 * 8 ) = 14975 hz
15 clock cycles is how long it takes the N163 to update a single channel, and then it proceeds to the next channel in a cycle. It outputs each channel one at a time after calculating, instead of mixing them. When the switching is fast enough (i.e. supersonic frequency) you don't really hear the difference between that and mixing, but when it's a sonic frequency, it's quite apparent.
No it is not tied to the music update frequency, which actually has nothing to do with the NES CPU clock. In games they were using the vertical retrace synch (i.e. 60hz), but the NSF specification makes it an arbitrary speed. Changing this update rate does not affect the NES's CPU clock.
It is the NES CPU clock frequency divided by 15, then divided again by the number of channels used.
i.e. 1789773 hz / ( 15 * 8 ) = 14975 hz
15 clock cycles is how long it takes the N163 to update a single channel, and then it proceeds to the next channel in a cycle. It outputs each channel one at a time after calculating, instead of mixing them. When the switching is fast enough (i.e. supersonic frequency) you don't really hear the difference between that and mixing, but when it's a sonic frequency, it's quite apparent.
Oh ok, so that makes sense why the effect I was going for was immediately lost when switching to 7.
As for the prevailing noise at 7 and below, I think you're right, this has to be unintended aliasing. Fixing that may be more than jsr bargained for.
I'm gonna laugh my ass off if the worst of this is due to an aliasing bug.
Well, it wouldn't really be a 'bug'. It's something that naturally happens when you're digitally generating frequency information that high(especially at 44.1). I mean hell, it's generating stuff at 20khz and beyond. Establishing effective anti aliasing techniques is something that plagues audio software developers everywhere.
edit: Yes, it's aliasing without a doubt. You don't need an analyzer to recognize it. Just keep switching between 96khz and 44.1khz and you'll hear the amount of non-harmonic distortion rise and fall.
At 8 channels, 96khz enhances the perception of the 15k hiss, while 44.1khz actually helps it(cos the 15k frequencies are being distorted by aliasing, thus making it more pleasant to listen to).
At 7, the hiss is more felt than heard at 96khz, but the 44.1khz starts to sound like a ring mod type of effect which keeps going as you decrease channels, making it sound worse.
Oversampling is one of the methods used to deal with aliasing artifacts, however a lot of people may not have sound cards that support 96k and above. I'm no dsp engineer, but i do know that other techniques outside of oversampling start to get a bit complicated.
Looks like the only real way to 'fix' this is for jsr to address the aliasing issue. This will be a challenge for anyone writing stuff for nsf players as well.
Addressing the issue will mean compromising the accuracy in order to shape what more closely resembles listening to it in real life. Perhaps maybe disabling the supersonic fundamental frequency somehow, once it gets past 20khz or something since we're unable to actually hear those if this was coming from real hardware. Even 96k will produce tons of inaccurate artifacts as you reduce channels and send that channel-switching frequency higher and higher.
As it stands, this may be an accurate representation in the code, but the clash with sample rates just about throw it as far away from being accurate as having no channel-switching noise at all. Even two channels have a ton of aliasing noise that's not supposed to be there.
editx2: I'm sure jsr has plenty ideas on how this could be handled, but I was curious and did a bit of searching for possible solutions. If anyone's interested, I found a few pages with some good info:
I particularly like the idea of pseudo-randomized sample quantization.
This N163 thing is such a unique problem, haha. I'm sure there has never been an issue quite like this before. I mean gawd damn, FamiTracker is trying to generate audio signals up to 119khz!
At 8 channels, 96khz enhances the perception of the 15k hiss, while 44.1khz actually helps it
Not sure where you got this idea. The difference between 44.1 and 96 kHz is that 96 kHz makes it sound excruciatingly painful, and 44.1 kHz makes it sound horribly painful.
I just tried rewriting some of my 8-channel N163 tunes to use just 7, and that definitely doesn't make them any better. Neither does using just 6 channels. Even downsampling and applying lowpass doesn't help it sound any better.
PLEASE FOR THE LOVE OF ALL THAT IS HOLY let us disable this abomination! There's plenty of arguments for both sides of the debate, but the fact of the matter is, implementing the switch with a little warning makes everyone happy, end of story. And you get the added benefit of not slamming your opinion right into our face and enforcing it on us in the process.
I'm not entirely convinced that aliasing isn't happening on the lower frequencies too. At 10k and above, any harmonic information at all is choked by a 44.1k sample rate. And I'm not sure what might happen when odd-order harmonics of the N163 wave itself are involved.
And Jrlepage, I'm sure this is something which will be fixed eventually. There is no logical reason to include reproduction of ultrasonic frequencies in an emulation. No one can hear them, many speakers/headphones can't even play them, and Nyquist sampling theory makes the whole situation a splitting headache. Kudos to jsr for trying though.
...the fact of the matter is, implementing the switch with a little warning makes everyone happy, end of story.
cak wrote:
There is no logical reason to include reproduction of ultrasonic frequencies in an emulation. No one can hear them, many speakers/headphones can't even play them, and Nyquist sampling theory makes the whole situation a splitting headache.
I don't see why these 2 concepts are so hard to grasp, really.
And also: emulation doesn't involve perfect imitation. The very word "emulation", by definition, allows a certain degree of failure, maybe even optimization.
And in this case, if the most perfect approach to emulation produces unpleasant results (unpleasant to the ears, in this case), what reason is there to make it the only option available?
Yes, it's how it happens in real hardware, I KNOW THAT. You all made it perfectly clear. But that's certainly not what happens with the NSF format in almost all of the options for emulation, which, let's face it, is as close as most of us are gonna get to hearing the real thing.
Also: To everyone saying "keep it", I want to ask you something right now. Pay close attention to my question, please.
How many of you are saying "keep the hiss" as a compromise? How many of you actually dislike the current situation, but feel like you need to deal with it because "that's how it happens in hardware"? Or worse: How many of you agree with it only because other people around here seem to agree with it?
Aliasing itself isn't a problem unique to the N163. The 2A03 APU and all expansions have ways of generating supersonic frequencies. Blargg's blip buffer is being used as a solution for this, and actually deals with it pretty well for the other chips, I think. The solution, however, needs to be tailored to the particular problem at hand. I think the current N163 mixing code is trying to supersample (that's why the aliased noises at other channel sizes aren't nearly as loud), but there's some irregularity in it that leaks out other frequencies. It's a problem I've considered myself, and have been meaning to experiement with in NSFPlay, but haven't gotten to it yet.
Also, as an aside, if you want to test your hearing, use a real test. Don't guess what frequencies you might be hearing from FamiTracker. (The best way to figure that out is with wave-out and direct visual analysis of the waveform.) This test is okay, though all the tones have a low level of harmonic distortion: http://www.noiseaddicts.com/2009/03/can-you-hear-this-hearing-test/
