Rejection of "ignore the" patch (split from the Evil_G unsupported build thread)

[lalittle]

@lalittle -> I'd also say, to be blunt, looking through this thread, that you've not gathered hordes of support for your "solution" - you do seem to be the only person arguing for it.

I can't argue with that (although I'm technically not the "only" person on my side in this thread.)  Then again, only a handful of people have posted in this thread at ALL, so I don't think any conclusions can be drawn one way or another.  We just don't have a large enough cross section of opinions posted.

I may in fact be in the minority on this one -- I'm merely pointing out that this "may" not be the case, and I did this in response to the idea that one method would be more conducive to a larger group of people.

Larry

[nls]

I never use the database but personally I would not use the ignore article in it's less flexible incarnation, for example I have swedish artists starting with "the" that I would not want sorted withouht article but would like most of the american artist starting with "the" to be sorted without the article, also I would not like some of my artists with swedish names to be sorted without articles. IOW if this kind of flexibility was impossible I wouldn't use it at all.

That means that I agree with Lloreans suggestion using the sort order tags.
Another good point with this approach is that it would not require any additional options to turn it on or off, just sort by sort order tag if present, else sort by display tag.

[Rincewind]

I want to add another point why only stripping certain articles from the sorting isn't enough.

With Jazz artists, it is a common sorting scheme to sort them by the last name.

e.g.

Code: [Select]

John Coltrane
Miles Davis
Jan Garbarek
Keith Jarett

This is the order they appear in a (my favorite) music store.

I would really like to have support for more tags in the database. It would be very nice to have a tagnavi.config where you can define (=use) all the tags you want to display, even custom ones. The tag scanner then uses this information to scan the additional tags that are defined (for whatever purposes). A common set of tags (used in the wps) should always be scanned, if they are in the config or not.

Advantages:
- every tag tag that someone possibly want to use in the tagnavi.config is available
- no database space is wasted, people who don't want fancy tags leave them out of their tagnavi.config and then they aren't scanned.
- no special cases need to be coded for album/track artist, sort fields, cd numbers etc. The tagnavi.config defines the use of special tags (some more syntax might be needed there).
Disatvantages:
- if the  tagnavi.config is changed, the database needs to be rebuilt.
- the structure of the database would be a little bit dynamic
- a host-based database builder needs access to the tagnavi.config

what do you think, is this worth a proper feature request?

[alienbiker99]

if anybody is interested, norbusan edited this patch to support three other leading "the" in other languages. If somebody could edit the patch so that it can support ignoring two and one letter leading words, we could have it also ignore "a" and any other leading words such as "el" or "la"

[lalittle]

if anybody is interested, norbusan edited this patch to support three other leading "the" in other languages. If somebody could edit the patch so that it can support ignoring two and one letter leading words, we could have it also ignore "a" and any other leading words such as "el" or "la"

Thanks for the information.

As far as I know, the articles that are traditionally ignored in sort lists are "a," "an," and "the."  If these three words could be ignored in each of the languages that Rockbox supports, it would essentially take care of this specific issue.  It would of course not address things like "last name first" sorting, but I'm actually used to this at this point, so an "ignore" function would take care of everything I'd personally need, and it would not require any re-tagging, which is an important issue in my opinion.

Thanks,

Larry

[bascule]

How does this patch deal with different languages?

I remember on my Rio Karma that artists/albums beginning with 'Die' (to be killed) were mis-sorted because it was treated as the German for 'The'

Can it be made to be dependent on the selected language?

[safetydan]

I decided to take a crack at supporting the sorting tags. You can see a very early version of the patch here http://www.rockbox.org/tracker/task/7287

[seani]

I'd  just like to +1 for sorting based on a separate, standards based, used-editable tag(s):

1) As stated a number of times, maintenance of tags is the users responsibility. There are swathes of free apps. that will let you edit tags, and a number that will let you copy a tag from one field to another. This would make it a relatively painless process to "correct" currently tagged files and keep on top of newly tagged files. From memory, TGF may have some support for stripping/transforming tags as they are copied in any case.

2) "Special" processing to press a single value into service in different contexts *always* causes problems, both from the messiness of the implementation, and the resultant functionality. This is a problem I've encountered time and time again in my own systems when a single description has to suit the needs of telesales, online sales, first and second line support, accounts etc. Each faction has it's own requirements in terms of formatting/sorting.

The sensible option is to have a separate related attribute (ID3 tag in this case), and have each interested party maintain the attributes in the way they see fit. This generally leads to resistance (as it's a maintenance "overhead" despite being "essential") and dissatisfaction with any method that tries to do this automatically by parsing the single value actually held (there are always ambiguities and odd cases). An unhappy compromise.

I don't always have the clout to insist this approach is followed, paying customers and all, but Rockbox has no such restrictions...

[alienbiker99]

i dont want to in anyway steal norbusan's work and the others of the patch so ill link to where he hosts the patch file. http://www.logic.at/people/preining/iriver/patches.full/ i guess you can test it out on how it sorts die.

[lalittle]

Can it be made to be dependent on the selected language?

That's an excellent point.  The patch should incorporate the ability to determine the language being used, and only ignore the articles in that language.

Thanks for specifically pointing that out.

Larry

[Llorean]

And why would someone only want to ignore articles in one language, but leave them in another, with multilingual tracks?

Is "The Who" "El Who" in Spanish, or still "The Who"? Meanwhile, "Los Pericos" (first band I could find starting with Los) should still be "Los Pericos" or should the Los no longer be ignored if the UI is in English? What about the song "Los Angeles", or should that name be used in the name of a band? Clearly that wouldn't be ignored.

Again, I don't see how this solution offers any amount of real flexibility.

Can you name some benefits other than "Users don't have to fix their tags" over the more general solution?

[safetydan]

As Llorean as made clear, a system that automagically determines which articles to drop is unlikely to be comitted to Rockbox. It's also unlikely to ever work well enough to satisfy everyone. Sorting on special tags will work for everyone since it's pretty much infinitely customisable.

So can I be a pain and ask people to test http://www.rockbox.org/tracker/task/7287 which is a patch that adds support for the sorting tags in ID3, Vorbis/APE comments, and MP4 metadata? It should add three new tags to the tagnavi syntax, sortalbum, sorttitle, and sortartist.

I've had a request to support an albumartist sort tag but that might be a bit messier as there's no separate tag in ID3 for that.

[alienbiker99]

i dont know if there is a way to do this, but setting up a system of checking which ones to ignore would work too

[lalittle]

And why would someone only want to ignore articles in one language, but leave them in another, with multilingual tracks?

Is "The Who" "El Who" in Spanish, or still "The Who"? Meanwhile, "Los Pericos" (first band I could find starting with Los) should still be "Los Pericos" or should the Los no longer be ignored if the UI is in English? What about the song "Los Angeles", or should that name be used in the name of a band? Clearly that wouldn't be ignored.

That's a valid point, but the short answer would be that I would have no problem with "Los Pericos" being listed under "L" rather than "P."  To me, the logic behind the ignore approach is to ignore articles in the currently selected language, and let everything else sort as it may.  I admit that the "ignore" approach will run into certain situations where the logic is not necessarily ideal to everybody, but I have found that in practice, the system works VERY effectively on devices like the iPod, as well as applications like iTunes, JR Media Center, and others.  These use the "ignore" approach to sorting without articles, and to put it simply, it works fine in my opinion.

Again, I don't see how this solution offers any amount of real flexibility.

I won't argue that the "tag" method can offer a lot more flexibility, but in my opinion it's not worth the cost (i.e. the extra work), which I believe is the reason that so few other applications or devices (no mainstream ones that I know of at this time) use the "ignore" approach.  To put it simply, it's just easier for the user.  Again, I understand that others don't necessarily agree with this -- I am only stating my opinion.

Can you name some benefits other than "Users don't have to fix their tags" over the more general solution?

No -- that's the only reason for using the "ignore" approach to this issue that I can think of.  To me, however, (and to other users like me who just don't want to have to deal with more tagging duties) this is a VERY important reason, and is a "deal breaker" for the "tag" approach.  You can call it "laziness" if you want, but the simple truth is that I'm already over-capacity on this sort of thing, and given that the "ignore" approach is already proven to work for me in my personal use, I prefer the concept.

Please note that I am not trying to change anybody's mind here -- I'm simply having a discussion where I'm clarifying my thoughts on the issue for anyone that is interested.

Thanks,

Larry

[lalittle]

As Llorean as made clear, a system that automagically determines which articles to drop is unlikely to be comitted to Rockbox.

I understand this and fully accept the situation.  This does not mean, however, that I won't continue to participate in discussions about the issue, or maintain hope that independent users will continue to develope a patch that uses the "ignore" approach for sorting.  Just because it's not officially committed doesn't mean that individuals can't create and apply the patch (which is one of the nice things about Rockbox in general.)

It's also unlikely to ever work well enough to satisfy everyone. Sorting on special tags will work for everyone since it's pretty much infinitely customisable.

I'm not sure why we keep coming back to this idea that the "tag" approach "will work for everybody."  As I've stated, it simply does not work for me because I'm not willing to go through the extra effort of editing tags for this purpose.  Again, you can call this laziness, but to me, it's more important to have it "automatic" (requiring NO user intervention) than it is to have it more "customizable."  I honestly don't NEED the extra customizing power of the "tag" approach, so the "ignore" approach, to me, is a the better option.  That's my opinion -- it's not "right" or "wrong," it's just my opinion.  Just because you don't agree with this does not invalidate the opinion.

On a side note, I'm clearly not the only one who feels this way, as evidenced by the use of the "ignore" approach in so many other devices and applications.  I'm not claiming that this proves it's the "correct" way to do this -- I'm simply pointing out that I'm not alone in my opinions here.

Thanks again for the discussion on this,

Larry