On Tue, 6 Dec 2005, Michael E. DiFebbo 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 tested.

> we also retain at least the portion of Anton's "prevent clipping" function
> that scales back bass boost to prevent clipping.

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.

> 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.

> The premise underlying these arguments is that Rockbox already has too many
> options and that adding more makes it unapproachable to new users or overly
> complex.* I disagree with this premise for several reasons.

The ground rule, that many of us core devs are sticking to, is that adding
options is a necessary evil that you avoid as far as possible.

In a few years from now, you too will realize why this is a winning concept.

> First, I think that this issue goes directly to the heart of what an audio
> jukebox is about: the users' experience in listening to music. It is
> abundantly clear that the handing of volume and clipping is important to the
> Rockbox user base.

I disagree. It is not clear. It is clear that the previous approach surprised
a lot of previous iriver-firmware users.

> It's also clear that this issue is critical to the developers;

Yes, but to me at least more in the sense that we want to keep Rockbox simple,
understandable and without bloat. I've never personally experienced the cap
limit, be it the original or Rockbox's, not before not now.

> I don't understand why there is such reluctance to implement a configurable
> option with respect to clipping prevention.

Because if we can work out a system without an added option, that is an even
better approach.

> There are many other Rockbox functions that have more numerous and more
> complex options.

That is not a good argument. Just because we have been sloppy or done mistakes
in the past is not a good reason for us to do them again.

> The peak meter alone, for example, has SIX different options. The LCD has
> NINE different options. The crossfade function has six different options

I would say that each of these are example of option-bloats that we should
address and cut down on.

But it isn't easy to remove or cut down what has already gone into Rockbox as
there's a wild user base that likes every part you'd try to change. It is _a
lot_ easier to break and address things _before_ they go in in the first
place.

And in fact, if we had not been practising the "More Options Are Evil"
philosophy we'd have a *bazillion* more options than we have today.

> 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

> If there really is a belief that Rockbox has too many options

I think most people (both devs and users) would say so.

> Advanced settings

I'm against "advanced" or "expert" options. We've had this argument many times
and I firmly believe:

   1) we'd get lots of arguements which options that are advanced

   2) all users would still use the advanced options

> I do NOT think that bass limiting should be implemented because that is the
> way that iriver does it.

I agree. Rockbox is a lot more than an iriver firmware and we do not mimic
iriver's behaviour. We should do what we consider is The Right Thing in any
given situation.

-- 
  Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/