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

[Llorean]

They're not custom. They exist in several tagging specs including ID3.

[DefineByte]

Code: [Select]

$if($strcmp($substr(%artist%,0,4),'The '),$substr(%artist%,5,$len(%artist%))', The')

Simple enough. Adapt as required (not that it's supported in rockbox yet).

I love foobar.

[Dixie Flatline]

They're not custom. They exist in several tagging specs including ID3.

This has been very educational, since I was unaware of the TSOP/TSOA/TSOT tags in ID3v2.4.  I'd agree that where this mechanism is available, it's the Right Way to solve the problem universally.  (Of course, I'm obsessive about tag maintenance on my own music collection, so I may be biased.)

However, 99% of my own collection is in either FLAC, Ogg Vorbis, or Musepack (transcoded from FLAC for use with Rockbox).  The former two use Vorbis Comments, the latter uses APEv2 tags.  Obviously, tag names in these formats are freeform, but I've been unable to find any recommendation for separate sort-order tags to use with those two tag formats.  Are the Rockbox developers aware of any?  I'd love to use them if they exist, but from what I can tell so far, they don't.

If they don't exist, then some sort of functionality similar to the "ignore the" patch would be a welcome thing for those whose tag formats don't offer the option of doing things the Right Way.  Certainly not as default behavior, and preferably not English-only, but if it were implemented as a display option, with some mechanism to configure the list of articles used (i.e., to allow localization), would that be more acceptable to the Rockbox developers?

IANAP, so all this is just a thought, but I am very curious to know whether the sort-order tags exist for Vorbis Comment and APEv2 tag formats.

EDIT: See my post below.  Looks like the sort-order tags do exist for Vorbis Comment, APEv2 and lots of other tag formats, so this whole argument becomes more or less inoperative.  Never mind...

[elborak]

Here is the best tag cross-reference I've been able to find: http://www.matroska.org/technical/specs/tagging/othertagsystems/comparetable.html

Another thing to keep in mind: no one is saying that you can't have this functionality in Rockbox, just that the current attitude among the core developers is that it is not the right approach for their codebase. It's pretty easy to produce a patch and do a local build with whatever customizations you want. Throw it up on a web page for others if there's enough demand. One of the true joys of the GPL.

[Dixie Flatline]

Thanks.  The "IANAP" in my most is "I Am Not A Programmer" -- it's unlikely I'll be implementing it myself, but wanted to point out that some sort of similar functionality would probably be welcomed by a lot of people, if it could be brought into the trunk gracefully and non-intrusively.

However, it also looks like I should have done just a little more Googling before I posted.  Thanks for the chart from Matroska.  I also just found this: http://musicbrainz.org/doc/PicardQt/TagMapping, which suggests that ALBUMSORT, ALBUMARTISTSORT, ARTISTSORT, and TITLESORT are the appropriate tags for both Vorbis Comment and APEv2 formats.

Since this functionality seems to be better-represented across tag formats than I first thought, I withdraw the argument made in my previous post.  Since the tags are available to make custom sorting work, and we have the godlike powers of The Godfather and fb2k at our command, it does seem that getting Rockbox to recognize and honor the various sorting tags is a better way to solve the problem.

[saratoga]

They're not custom. They exist in several tagging specs including ID3.

How much software support is there for them?

[elborak]

How much software support is there for them?

Assuming you mean tag editors (as playback software would be irrelevant to the current discussion), any that lets you edit arbitrary ID3 tags. Mp3tag would be one.

[lalittle]

Heck, someone could even write a plugin for Rockbox that would (much more slowly) generate sort tags off the existing tags.

This, to me, would be a better solution than having to use foobar for this task.  I much prefer keeping all the Rockbox-related work within Rockbox itself since it does not necessitate using another, separate application in order to achieve this behavior.  Maybe it's largely a psychological difference to have the Rockbox "duties" confined to Rockbox, but for whatever reason it definitely makes a difference to me, and it would make the difference between me having "article free" sorting or not.

Just to give another example of the way my brain works on this stuff, I have all my cover art contained with the mp3's -- this is my preference based on what's important to me.  I realize that I can run a batch process on my files that would extract the cover art and create versions of this art that the Rockbox iPod could read and display.  I just don't want to have to take the time to do this, however, every time I rip a new album.  Therefore, I end up with no art in Rockbox.  I understand that this is a "choice" I'm making, but to ME -- to MY personal way of working -- it's not worth the trouble to go through this process in order to achieve the outcome.  I WOULD like to have the cover art, and if someone created a Rockbox patch to utilize the native artwork within the files, or that would do this process from within Rockbox, I would use it.  Until then, however, I'll just forgoe art in Rockbox.

All that aside, I agree with saratoga on this one, i.e.

IMO there should be a preprocessor that examines tags when they're loaded.  A language specific text file could define what strings should be parsed out, thus allowing intelligent behavior across many different languages while still allowing consistent behavior with other software.

This just makes "more sense" to my way of thinking -- even with the arguments against it, it still seems like the "right way" to achieve this behavior.  That's just my opinion -- I realize that it's not my choice to make.

Larry

[Llorean]

Okay, exactly why does the way that is entirely redundant seem the right way?

The TSOP features need to go in for a number of reasons:
1) They allow easy removal of any article the user chooses.
2) They allow easy sorting of accented characters (by typing non-accented characters in the sort-field)
3) They allow easy various artist support (by using "Various" in the sort field).
It also is just flexible and there are probably other common problems it solves. This basically should go in regardless.

Your method only works with a set list of articles, requires a list in every possible language that could desire to ignore articles, cannot be turned on and off by a song by song basis but rather ignores all articles or none, and does nothing to solve any of the other problems. As well, it would be entirely redundant if the other, imho essential, code went in.

What makes it "right" other than the fact that it requires no user intervention to set up? I think I don't understand what you see as the advantage other than it means users don't have to do a (relatively minor) extra step in making sure their files are properly prepared (a step that can be automated by any enterprising person).

Also, I don't even understand why eliminating the article makes a list easier to read, but you still want the article visible. This is somewhat unrelated, but to me

Bad Religion
Blue October
Blue Oyster Cult
Metallica
The Beatles
The Rolling Stones
Queen

looks a lot better than

Bad Religion
The Beatles
Blue October
Blue Oyster Cult
etc...

I mean, it's not like they aren't then in alphabetical order under the "The" section, and it presents a more unified look.

But I'm not arguing against the option to remove articles, it just seems silly to waste binary size on a very, very limited solution, and I don't understand why you think it's the "right" solution in the context of Rockbox. The only advantage I see to Rockbox is that it's slightly easier for users, but I think that's far outweighed by the related costs (binary size, since it would in effect be redundant and the fact that it depends on an arbitrary list).

I mean, I understand why you like it more: It's simple, and easy for you to use, and you relate yourself as the average user. But it needs to be fully effective for all users, with a minimum of impact on those who don't use it, and a maximum of flexibility for what is added. So while I don't have a problem with your solution, I don't see how you can state you think it's right for Rockbox, which is multilingual, aimed at (on average) somewhat advanced users, and wants to try to keep the binary size down. (As a note, I'm not certain, but what I know suggests adding 3 tags to the database will result in much less binary increase than a new sorting algorithm with associated menu options and list of articles to avoid).

[lalittle]

Also, I don't even understand why eliminating the article makes a list easier to read, but you still want the article visible. This is somewhat unrelated, but to me

Bad Religion
Blue October
Blue Oyster Cult
Metallica
The Beatles
The Rolling Stones
Queen

looks a lot better than

Bad Religion
The Beatles
Blue October
Blue Oyster Cult
etc...

I mean, it's not like they aren't then in alphabetical order under the "The" section, and it presents a more unified look.

I don't have time to address all your questions at the moment, but I wanted to address this one (I'll post more later.)

Basically, it comes down to preference, and what one "expects" to see based on what they're used to in other systems.  I "expect" to see "The Beatles" under "B," which is most likely due to the fact that this is the way other systems work.  It is a generally accepted standard for "collections" or "lists" to be sorted by ignoring leading articles.  Libraries, indexes, lists of movies, books, songs, etc. all tend to use this approach.  I guess the idea is to use the first "important" word when sorting rather than the very first word period.  This just makes intuitive sense to a lot of people, which I assume explains why it is in fact a standard.  For lack of a better word, it "feels" logical to do it this way.

I'm not sure if this explanation really helps or not (I hope it does at least a little.)  This is a highly subjective area, and it's somewhat difficult to explain the specifics of what makes one approach "feel" better than another.

Larry

[lights0ut]

Bad Religion
Blue October
Blue Oyster Cult
Metallica
The Beatles
The Rolling Stones
Queen

Bad Religion? Awesome! Let me guess, your favorite song is "I wanna Conquer the World"? By the way, thanks for splitting this thread, Llorean,  it's much appreciated. To add my 2 cents, I'm leaning towards Llorean's opinion: The sorting should be done with tags, after all, that is how music is sorted, by looking at the tags. By keeping the sorting in the tags you get other features (like Llorean and others pointed out) like being able to have some artists sort under various. I really don't use database view (as most of my music isn't tagged), but I don't find it irritating that The Killers, and The White Stripes are both under T for The, it's always been sorted that way (on my PC and on my DAP) so I'm used to it. While I understand that 'ignore-the' is quick and painless for users, it's not so quick and painless for the rockbox codebase, and this is what matters most to the devs. This is why we have to be patient for things like album art (which I am not complaining about, just making a point).

In the end, I trust what the devs do with the code, the focus seems to be on a rock solid DAP, with awesome audio playback,  that has well implemented, and equally solid features, plugins, and extras.  (way more than 2 cents worth, I think)

[elborak]

Basically, it comes down to preference

Exactly, which is Llorean's point. Supporting the sorting tags allows everyone to sort exactly as they want according to their preference. The other approach satisfies your preference but leaves others without a solution. Hence the choice seems obvious.

[lalittle]

Basically, it comes down to preference

Exactly, which is Llorean's point.

My point is that issues directly pertaining to the sort behavior are only PART of this discussion -- there are other factors involved, such as the conditions under which this sorting takes place.  Whether or not the process requires user intervention is an important aspect of this to me.  I understand that this isn't the case for everybody, but it is for ME.  You can accuse me of being "lazy" if you wish, but that doesn't change the fact that having to go through a separate process in order for this to work is a central issue for me, and THIS is at the core of my argument.

Supporting the sorting tags allows everyone to sort exactly as they want according to their preference.

But it does NOT do it automatically, which once again is an important aspect of this in MY personal opinion.  You can point out OTHER advantages to "your" method, but these have no bearing on the issue of making the feature fully automatic.  We are talking about two different aspects of one overall subject.

The other approach satisfies your preference but leaves others without a solution.

Remember, however, that the reverse is ALSO true -- i.e. your approach does not satisfy MY needs given that non-intervention is one of my "needs" in this situation.  We simply disagree on how much extra effort is "acceptable" in order to get this behavior.  I want to rip, sync, and go -- and have everything sorted without the articles.  Your method does not offer this.

Hence the choice seems obvious.

Your method is the obvious choice from YOUR point of view, but "my" method is a better choice from my point of view because your method does not satisfy certain parameters.

Keep in mind also that when you bring the idea of "others" into the equation as you did, you need to consider that we really don't know how many people would prefer one method over the other.  Your statement implies that I'm essentially alone (or at least in the minority) in my opinion, but the fact of the matter is that we don't know this.  It could be that more people would want to keep the process entirely automatic compared to those that would prefer the other capabilities that your method offers.

As pointed out by the developers, however, it doesn't matter -- it's up to them what they do, and I accept this (althougth I'll still voice my opinions on the subject.)  I'm simply saying that without a lot more evidence, it's not fair to paint a picture where my opinion is the minority one.  The opposite "could" be true.

Larry

[Llorean]

You can use MY method by performing one extra step: Tagging.

Others CANNOT do certain things with your method independent of the number of extra steps because it is inflexible.

This is a case of "Everyone can do anything, though some need a little extra work" vs "Some can do what they want with a minimum of work, and others can't do what they want at all" and I think the option that actually allows everyone to use the feature is preferable, clearly, because it doesn't force exclusion.

You cannot claim to be forcibly excluded: You CHOOSE not to fix the tags. Meanwhile, those who speak a language that Rockbox doesn't support the articles for, or those who have songs that are mixed case as to whether the article needs to be removed or not (multilingual: Something may be an article in one language and not one in another) are forcibly excluded by your method, and no choice of theirs can make their existing collection compliant with a limited system.

It's not a case of your opinion being the minority, I suspect the majority would prefer a simple method that doesn't require intervention. It's a case where yours forcibly excludes a group, your method is redundant (it makes the binary size bigger, but you seem to not care about technological hurdles in the slightest), and if we were to avoid the redundancy your method doesn't offer any solution to the other problems that the sort order tags solve (without coding independent solution, which brings us back to the binary size issue).

[GodEater]

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