This can't really be done by the community for technical reasons. Not as you are asking anyway.

The EQ is implemented in HW, not in SW. The parameters that you set are used to generate DSP coefficients that tell the DSP how to create the EQ. Unfortunately we don't have access to the algorithm necessary to generate the coefficients from the parameters. It is coded into the (closed-source) player application. Obviously the coefficients aren't linear, so you can't just add a couple together to create a new EQ.

I suppose that the empeg player binary in theory could do the math on the parameters before generating the coefficients, but to be honest with you, this feature is never going to get anywhere close to the top of the wish list.

Even if it did, there's some usability issues to tackle anyway. This feature would require that the frequency and Q factors for matched on both the base EQ and the modifying EQ. And applying large changes to the EQ requires an audio mute to prevent potentially dangerous transients (that could otherwise blow a speaker). But both of those issues could be overcome if the desire was there.

But in hijack space, we cannot do this. We could do something similar though.

First, assume that the EQ is being used in 2x10 mode, and not 4x5 mode. Then we only use the bottom five bands to create the base EQ. We use the top five bands to create the modifier EQ. (There is nothing preventing 2 bands having the same frequency and Q factors, in which case the dBs just add).
Then we create all of the desired EQs in this manner with a constant base 5 but differing modifiying 5, and switch between them when the song changes.
There's still a few technical hurdles to leap.

Firstly, the player wouldn't actually know which EQ was really applied, and we don't have a way to tell it. We'd have to deal with that somehow.

Second we'd have to be able to capture and store the required EQ coefficients so that hijack could use them. Hijack only gets to see the cofficients when they are applied by the player. This would require manually setting and capturing the EQs one by one and writing them to disk. Which in turn requires a partition to be mounted read-write during that operation. None of this is insurmountable, just a complete PITA.

Thirdly, we still need to mechanism to decode the tag when the song changes and to trigger the EQ change.

Fourth, we'd have to decide what to do with bass and treble. The existing bass and treble functionality hijacks the top 2 bands. The preferred option would be to rewrite the bass and treble to use the DSP hardware instead, but I've been trying to find time to do that for over a year now. The easy option would be to limit the base and modifier EQs to four bands each (which kinda makes a mockery out of the whole deal). The final option is to make the two features mutually exclusive. Could you live with that?


I personally don't think that this is worth the hassle. Even if this was all done, are you seriously going to sit in your car and set up 10 different EQs and then categorise thousands of tracks to use them? I doubt very much that anyone else is going to!

What could work, and would be _vastly_ easier to implement, would be a bass/treble modifier on a track. We'd just need the tag decoding mechanism for that. And I can really see people using that - it's a quick and easy thing to recognise that a track could use a little more bass or a little less treble.

I'd still want a method of in-car tagging though. I don't know whether there is any space within each fids data in the dynamic data partition that could be hijacked for this. It would add complexity, but might be doable.