On 06.12.2005, Daniel Stenberg wrote:
>> I also believe that having a "prevent clipping" function
>> similar to what Anton developed is beneficial to Rockbox,
>> particularly with respect to making it more accessible to
>> less sophisticated users.
> All the discussions that have been held on this topic, that
> I've read, have more or less stated that people have not
> understood or liked the previous concept used by Rockbox, with
> some stating that they'd prefer the original iriver fw method.
> The approach Jens suggested has not been widely discussed or
That's not entirely true. We do no clipping prevention on the
archos Recorders and Ondios for years...
>> we also retain at least the portion of Anton's "prevent
>> clipping" function that scales back bass boost to prevent
> Yes, we might have to. But we've had Jens' system for the
> Archos models for years without needing a "prevent clipping"
> option so I think it is a fair idea to go without that option
> to start with. People are in fact used to stereo equipments
> etc that clip when you drive everything to too high levels.
> Also, it is not 100% clear exactly how the "scale back bass"
> should work.
That's relatively easy once we switch to dB volume - see my
reply to [IDC]Dragon.
>> Many of you have argued, in various ways, that Anton's
>> approach is less desirable then Jens' approach because
>> Anton's approach leads to undesirable option bloat.
> That's only one reason. There are more reasons, including:
> there are too much magic happenining under the hood and that
> the options are very hard to understand/differentiate.
Exactly. Imho there are too many options and all scaling
appening behind the scenes. If deemed necessary at all, a simple
'prevent clipping: yes/no' should be enough, scaling back
treble/bass, doing its work at the app level, with proper
indication, and for all targets (!).
>> It doesn't seem unreasonable for users to have at least ONE
>> option (ON or OFF) with respect to clipping prevention.
> ... nope, and there is no major resistance against such an
> option. Just a mild "Do we really need it?" And a "How exactly
> would such an option work?" And a "Such an option *really*
> should be user-visible when in effect and how would that work
> when the apps don't have detailed info about the DAC?" etc
See above/ other posts.
If there are no major objections, I'll commit my patch tonight.
Then we can improve upon that.
Received on Wed Dec 7 08:55:27 2005