There's two issues with this that would need to be addressed.

Firstly, integration with the player software. It could be made simpler if we told people that they couldn't use volume ramping with this feature. Then we'd just trap the very first volume IOCTL call in hijack and cap if neccessary. Otherwise we'd have to trap the first X calls, where X is an undefined quantity. We'd have to use the boot timer and pre-define a time during which the cap is active.

But this still might not work - I suspect that the player would complain about failed volume setting calls, unless we lied to it. We currently already lie for the volboost_ code, but the idealogy of that is opposite to what we want here, the volboost code *always* lies to the player when active, but here we wouldn't want to perpetuate the lie beyond the end of the volume ramp. I don't know how the player would react if it thought that the volume was X dB and then it finds out that it was really X-25 dB. It might deal with it fairly gracefully, with no more than a visual anomoly, or it might not.

The second issue is that of storage. I suppose that 6 bits of flash would give 7 levels + off for both AC and DC modes, but I don't know that this feature would be worth that much flash - it's not something that you'd want to modify on a frequent basis. I suspect that config.ini would be a better place for this.

The 'perfect' solution, if time allows, is intercept the powerdown flash write, and cap the volume according to config.ini as the player writes it. That way the player would read the capped volume when it next boots, and ramp accordingly.

Yes, it could be achieved in hijack fairly easily, but I suspect that it would be trivial to include in the player software itself, and ideally this is where it should live.