From: Michael E. DiFebbo <medifebbo_at_rcn.com>
Date: Tue, 06 Dec 2005 11:42:36 -0500

Although I am not a developer, I would like to offer some comments from
the perspective of someone whose primary contribution to Rockbox has
been writing documentation and educating new users about how Rockbox
works.

I like Jens' approach to volume. However, 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. I believe that these approaches
are not mutually exclusive. Thus, I propose that we implement Jens'
approach to volume, but that we also retain at least the portion of
Anton's "prevent clipping" function that scales back bass boost to
prevent clipping.

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. I've seen statements like, "Rockbox already
has too many options," and "option bloat makes Rockbox unapproachable
for new users." 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.

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. As I have noted on IRC (and many of
you have agreed), the volume/clipping prevention issue has been the
single biggest source of complaints and questions about Rockbox. It's
also clear that this issue is critical to the developers; in my time
involved with the Rockbox, I have not seen any other issue be the
subject of such intense debate.

Given the importance of this issue to both users and developers, I don't
understand why there is such reluctance to implement a configurable
option with respect to clipping prevention. There are many other
Rockbox functions that have more numerous and more complex options. The
peak meter alone, for example, has SIX different options. The LCD has
NINE different options. The crossfade function has six different
options, and even with the simplifications that Jens suggested
yesterday, it would still have three options. It doesn't seem
unreasonable for users to have at least ONE option (ON or OFF) with
respect to clipping prevention.

If there really is a belief that Rockbox has too many options, then I
think that we should look at all of the options and examine how they can
be streamlined and made more ergonomic, rather than looking at this
single issue of clipping prevention in isolation.

Second, I believe that implementing a prevent clipping option makes
Rockbox easier for new users, not more complex. Less sophisticated
users do not understand what clipping is or what it sounds like. They
don't understand the significance of the 0db threshold. Some of them
don't even understand the difference between bass and treble. Moreover,
they don't want to have to understand these things just to be able to
listen to their music. For these users, I think that it makes sense to
have some sort of clipping prevention mode, and perhaps to enable
clipping prevention mode by default. I believe that this is MUCH more
user-friendly than requiring these users to learn what clipping is and
how to avoid it.

To the extent that adding another option adds to the complexity of
Rockbox, that can be addressed to a very large extent by taking a more
global look at how the interface works, and by moving certain of the
more sophisticated options to an "advanced settings" submenu. For
example, the "Sound settings" menu could be restructured as follows:

Sound Settings

   Volume

   Bass

   Treble

   Balance

   Advanced settings

The "Advanced settings" submenu would contain things like "Channels,"
"Crossfeed," "Stereo width," and "Prevent clipping." This would present
a simple and understandable interface to new users while maintaining
Rockbox's power and flexibility for more sophisticated users.

Finally, if a clipping prevention mode is retained, I agree with Anton
that the clipping prevention mode should at the very least prevent
clipping by scaling back bass boost. However, I disagree with Anton's
reasoning. I do NOT think that bass limiting should be implemented
because that is the way that iriver does it. Instead, I believe that
bass limiting should be used because it makes the most sense and is the
most transparent to the user. The Fletcher-Munson effect is
well-documented. The human ear perceives lower frequencies better at
higher volume. Reducing bass boost as volume is increased is far less
noticeable to the user than capping volume. (Again, while I don't
advocate that this method be adopted solely because it is the way that
iriver does it, we can look at user comments in both the Rockbox forum
and Mistic River to support this. Many users have commented on the
volume cap, but I've never seen a single user say, "has anyone notice
that iriver's firmware has less bass at higher volumes than at lower
volumes?")

Thank you all for considering these suggestions.

____________________________________________
Michael E. DiFebbo


*Note: I recognize that there may also be arguments related to the
addition of arguably unnecessary code, but I am not qualified to
address those arguments.




Linus Nielsen Feltzing wrote:
> Anton Oleynikov wrote:
>> The whole point of my patch was that user finally have intelligent
>> bass/volume control that allow him to compare sound directly
>> to original iRiver's firmware
>
> This is absolutely irrelevant IMHO. We couldn't care less about the
> original firmware.
>
> Linus
>
>
Received on 2005-12-06