Rockbox General > Rockbox General Discussion

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

<< < (14/23) > >>

Llorean:
Current Rockbox builds sort strictly by exactly what is displayed.

The two offered solutions are

1) Ignore a pre-set list of articles, when enabled (possibly extended to enabling/disabling individual articles, but still impossible for a full multilingual solution)

2) Use a second set of standard (as in: part of existing standards) tags that contain a separate string, which is used for determining how it's sorted, while the normal string is what is displayed. For example, "The Beatles" would be the display string, but "Beatles, The" would be the sort string. The song would show up as "The Beatles" in the list, but its position would be determined by "Beatles, The". A plugin could be made to evaluate the songs on your player and create these tags if you didn't want to customize them on your own or have a PC-side utility that is capable.

lalittle:

--- Quote from: Llorean on June 11, 2007, 08:47:32 PM ---And just to clarify, if it's not clear from above, what that would mean is that if you simply run that plugin, after you've run it, no other user steps, Rockbox would then act like it had the "Ignore The" patch for the database (or ignore articles based on whatever list of articles the plugin had) without any further user intervention (assuming the TSOP support was also implemented by that point). And a plugin like that could surely get accepted into SVN, meaning you wouldn't have to have the hassle of using an unsupported build and depending on someone else for your updates or maintaining the patch.

--- End quote ---

Based on the information at hand, this would get my vote.  I definitely agree that it would be really nice to have the feature officially supported by the developers, and eventually rolled into the builds by default rather than requiring patches and custom builds.  I assume it would take a little while for the "ignore" plugin to do it's thing and create the "advanced tags," but given that it only requires the user to say "do it" and then leave the iPod alone for a little while, that's fine.

On this note, am I correct in assuming that the process of creating new tags and re-writing the files could potentially take a considerable amount of time?  If so, perhaps 1) the "advance tag" plugin could revert to reading the standard name tags for sorting as long as the "sort" tags were blank, and 2) the "ignore" plugin could be make to ONLY process names that actually begin with an article and leave the rest alone.  This way, only the files that NEEDED the special sorting (i.e. files with articles) would be processed/rewritten, so the process wouldn't waste time re-writing files that didn't begin with articles.  Does this seem logical?

Thanks again,

Larry

Llorean:
The plugin would have to read every tag, because it'd be impossible for it to know in advance which files have an article and which don't, but of course it'd only write the sort tags for the ones that needed changing, if done properly.

Also, as was said far, far earlier in this discussion, a very simple PC-Side program or script could do the exact same thing as this plugin, on a computer, as well automating the process and doing it in a far, far, far shorter time.

Walrus:

--- Quote from: Llorean on June 11, 2007, 10:33:43 PM ---
2) Use a second set of standard (as in: part of existing standards) tags that contain a separate string, which is used for determining how it's sorted, while the normal string is what is displayed. For example, "The Beatles" would be the display string, but "Beatles, The" would be the sort string. The song would show up as "The Beatles" in the list, but its position would be determined by "Beatles, The". A plugin could be made to evaluate the songs on your player and create these tags if you didn't want to customize them on your own or have a PC-side utility that is capable.

--- End quote ---


I still don't see why this is so complicated, (I mean, if it's implemented and someone doesn't like it, they can always turn it off) but...that option of having a separate 'sort' tag in the ID3 would work.

Llorean:
Features take up binary space. Saying "You may as well implement" is saying "you may as well hurt other people's experience for my benefit" because that binary space could be used for something else.

If a feature is implemented, it should be as small as possible, with the greatest overall benefit as possible. If this means a little bit more work for the end user to set up, but allows fully multilingual improved sorting rather than a improved sorting for a very limited subset, I think the "forget you, I don't want to have to do an extra step, the other people who get left out entirely with this feature if it's done this way can just bite me" argument is just a little bit unacceptable. Especially since the idea that "it doesn't cost the people who don't use it anything" is false. You don't have "Group A gains Sorting, Group B loses nothing." Group B gets a very, very little bit less RAM to store their music in. A little bit that counts on some players, and hardly matters at all on others, but it isn't free. So if the feature works, at the very least people of *any* language should have the option to use it freely and flexibly.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version