What are the Q and frequency parameters for the Bass and Treble settings, and which bands are used for which?

I assume that it's the last two bands in the spectrum, the ones on the far right, bands 9 and 10, right? Which one gets used for bass and which one gets used for treble?

Also, what if I were to match the Q and frequency of those two bands so that they were the same as what you were using? Would you then (with updates to the code) be able to say:

if (user's Q and frequency = the same as the Q and frequency I use for bass and treble)
{ Those bands = User's data +/- My data }
else
{ Those bands = Totally my data }

The reason I ask is that I want more than the 6db we get from the existing bass/treble controls but I also want to have the bass/treble controls still work, and I'm already using up all of my other bands now for other corrections.

Another option would be to make the Bass/Treble flash bits count for more overall adjustment. For instance, making each click be 2db each instead of 1db each.

Incidentally, a recent issue of Game Developer magazine had a great article on how to conserve bits when bit-packing. Would you or Mark be interested in looking at it? I'm wondering if it could save on flash space if its techniques were implemented.

Another option would be for Hugo to be really nice and look up which bits you need to twiddle in the DSP to adjust its built-in bass and treble controls, instead of having to usurp two equalizer bands to do it.

Another option would be for Hugo to be really nice and look up which bits you need to twiddle in the DSP to adjust its built-in bass and treble controls, instead of having to usurp two equalizer bands to do it.


That would be the ideal way

Yeah, band 9 is bass, 10 is treble. I can't remember the values off the top of my head, I'll check later when I'm at home.
The bits are packed as tight as they can go - so unless we can find some revolutionary method of quantum storage where each bit can hold more than one bit of information then we're out of luck. We could increase the range at the expense of resolution, which might be a problem for other people. Or we could look at the Q factor/frequency used - I guesstimated at the Q factor/frequency values, and they appeared to work farily well for everyone, but they certainly weren't optimised through any process. There are some unpublicised config.ini options that will change these in hijack.c. The problem is that I never completely reverse-engineered the format of the bytes used in them - I discovered the gain value byte fairly easily, but the f and Q format is still unknown to me. (In case you are wondering, I cheated by setting an eq band to the f and Q I was going to use, and wrote down the values )
There should still be a debug option in hijack.c where you can get the tone controls to pump out those hex values to the serail port, so if you wanted to play with this then it'd be a case of recompiling a kernel with this flag set. Then set the tone controls to 0, and the underlying bands 9 and 10 will be active once more - allowing you to try and find f/Q values that work better for you. (Remembering that as the tone controls currently stand you can only adjust +/-6dB).

You will however hit the channel lock bug. So I'd recommend unlocking the channels and trying this with the balance set all the way to one side. (This way, the other channel doesn't color the tone). If you find different values that work for you, write down the hex from the serial port - and then we can plug it into config.ini.

The implementation of the tone controls uses a LUT (look up table) for the gain values. I don't think it'd be easily possible to do math on the values to add the underlying eq bands gain value as you suggested. But I won't rule it out until I've looked at the code again. The only other option would be to petition Mark for a bit more flash so that we could increase the range/resolution.

Thoughts or comments?

You will however hit the channel lock bug.

Actually, I won't. It's good to be on the alpha team.

I've temporarily worked around my immediate issue by re-allocating certain bands. It's just that overall, I don't think 6db of correction is a lot of range for the bass and treble controls unless you're already using the EQ effectively and you only want slight nudges of bass or treble "on the fly".

The bits are packed as tight as they can go - so unless we can find some revolutionary method of quantum storage where each bit can hold more than one bit of information then we're out of luck.

Well, the article talked about how you might think you're packing the bits tightly, but you're really not packing them as tight as they can go. Without going into genuine data compression, they had methods of allocating the bits in a set of bytes that was quite interesting, and it surprised me when I read it.

I can't find the article reprinted on the web at this time, so I'll see if I can get the text of it to you somehow.

In reply to:

---

I can't find the article reprinted on the web at this time, so I'll see if I can get the text of it to you somehow.

---

I'd be interested in a copy too if you can easily get it in some kind of electronic format. I'm kinda sceptical too, like genixia.

Okay, the article shot nicely on my digital camera. Color-reduced to within an inch of its life, its three pages compress down to about 400k. Okay to mail that to you, Shonky and Genixia?

It's possible that you are already doing something like what this article describes. I just thought it had an interesting approach to the idea of bit packing, something that I hadn't considered.

Yep 400k is cool with me:

[email protected]

I am interested for more than just the empeg. The more you mention bit packing, the more I think that Mark was already doing what the article is describing. There might be some thing else to it though. I'll get back here and say yes or no once I've read it.

Thanks Tony.

Why for and how come is this not a copyright concern? This sounds like a "photocopy" of a published article. I'm not trying to be difficult but it seems kind of like selective interpretation to me. We seem to have lots of "police" here and sometimes they are kind of anally rigid, and sometimes not!!!

I'm interested to hear if there is a quasi-legal distinction in this case. Personally, I do not really object to disseminating technical information this way as long as it is not for profit.

Lynn

Take it easy Lynn.... The article was pretty light on information really and so it should be given the subject is fairly simple. Anyone who considers themselves a real game developer really should already know this sort of stuff.

As for Hijack, Mark is already doing this basically. There are a few wasted bits here and there and you might save a byte or two. I don't really think it would be worth the trouble myself. In most cases the bits are used very efficiently already. For example I used 8 bits for the left/right time alignment stuff. Out of the 256 combinations, I used 255. I only wasted 0.3% of the available information in 8 bits.

Yes, it is a copyright concern, I figured that if it was a private exchange between me and one or two friends, then it would be either considered "fair use", or at least under the radar of anyone who cares.