Rockbox mail archiveSubject: Re: Replaygain without a setting, and other menu cleaning.
Re: Replaygain without a setting, and other menu cleaning.
From: Jeff Goode <jeffg7_at_gmail.com>
Date: Sat, 20 Jun 2009 08:41:46 -0400
Thomas Martitz wrote:
> Jeff Goode schrieb:
>> To your main point: I have a number of files from the same albums
>> that are replay gain tagged for each track but not for the entire
>> album. Therefore, when I play back tracks that play directly into
>> the next track with replay gain enabled, there is a jump in volume.
>> This is not a subtle "purity" argument, but a very evident
>> distraction. Also please explain to me why I should have to go back
>> and retag all my files to allow you to remove the ability to turn off
>> a feature I don't want and have no use for? It's not as though you'd
>> have to do some extra coding to implement a feature. You want to go
>> out of your way to take one out. Are aesthetics preferable to
>> function here?
> IMO, your tags are at fault here.
> But anyway, we have the very good suggestion to merge the gain type
> with the on/off setting. Why aren't we just doing that?
>> Merging settings is one thing. Removing the ability to disable an
>> unwanted feature is something else.
> I cannot see how it is unwanted at all. Rockbox is setup to read those
> tags. Your laziness to clear up your tags doesn't make it generally
Rockbox is set up to do a lot of things. But just because it's
*capable* of doing something doesn't mean that it *must* do something.
I don't mind at all that tags (faulty or otherwise) are read. I do mind
if playback is affected outside of my control. But as you say, it's
probably beside the point since we're talking a settings merge now
instead of removing the option of disabling.
I do have to object to the ingrained arrogance on display here by some
posters. How else can you describe an attitude that states: we designed
such-and-such a feature, so you must use it. That's getting away from
the philosophy that the end-user's needs should be satisfied first and
foremost, and it's the developer's job to decide how best to do that.
That doesn't mean dictating what those needs are. Taking options *away*
from the end-user For-His-Own-Good, or Because-We-Say-So, or even
Because-We-Don't-Do-That-Nobody-Should-Do-That, is rampant arrogance.
Be developers. Do cool stuff. Design great features. But don't
unnecessarily limit the end-user's options because you don't do things
that way. Chances are very good that somebody out there does. Faulty
tags or no.
Received on 2009-06-20