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

[safetydan]

If you want it to be automatic there are plenty of tools out there that will automatically populate your music files with the correct metadata. Heck, if someone was motivated enough they could write a plugin for Rockbox to go through all your music and copy track details to the sort tags while ignoring articles.

So if people still want something similar to the "ignore the" patch, perhaps they should work on making a plugin to do what I described above. That way we can have things the "right" way in the core, and the "wrong" way is isolated in a plugin.

[Llorean]

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.

[hotwire]

The problem as it appears in the English language, to me at least is as follows: usage of the definite article 'the' in artist/performer titles is ambiguous at best.

In examples such as 'The Beatles', 'The Who', 'The Music', clarity of artist identity is lost on deletion of, or rearrangement of the definite article, but alphabetizing of the a list of these alongside other items lacking a preceding definite article almost always results in a sorting that ignores said definite articles.  This is why for many English speaking Rockbox users, the necessity of an "ignore 'the'" patch is essential for his or her Rockbox experience.  The only examples I can think of offhand of a sorting that does not ignore 'the' are Rockbox, and the Windows file systems.  In fact isn't the official name for the artists above invoke the definite article, and thus any rename results in an inaccurate tag?

As for that ambiguous example: The Arcade Fire... or is it Arcade Fire?  Last.fm states the former, and the English Wikipedia states the latter, although going back a short number of revisions "The Arcade Fire" is used by Wikipedia also.  Their album covers use the latter, and yet all mentions of them in common speech (the same common speech that uses 'their' in place of 'his or her'), I only ever hear the band referred to as The Arcade Fire.  I am absolutely certain with a little effort, someone on this forum could even find two albums by an artist by which the artist uses a definite article in their name for one album, and does not in another.  Which one takes precedence? (this is intended more as a rhetorical question).

In the case of an album name or song title, usage of the definite article is not as ambiguous.  Take "The Black Parade", or "The Rising": both of these are formal titles to which usage of the definite article is deliberate for titling and thus must not be ignored when performing an alphabetized sort.  In other words, any 'ignore the' patch should only apply to artist/performer name and not to album or song title.

There you folks have it in a nutshell as to why in my opinion the requiring of users to perform a batch rename of tags to relocate any preceding definite article (henceforth referred to as "Artist, The") is in fact the inelegant shortcut for when a user wants to perform a sorting of artist names as is normally performed in English.  If you disagree, feel free to attempt to reorder any list on Wikipedia so that artist names starting with "The" appear under T, and see how long you last before your edit get reverted by one of those 'Wikipedian grammar freaks': http://en.wikipedia.org/wiki/List_of_best_selling_music_artists

I'm sure if someone has the will to dig around on Wikipedia for the policy on alphabetically sorting of lists we can find the proper procedure.  I bet it may even link to the norms in other languages.

[Llorean]

Something tells me you completely ignored the whole conversation and chimed in at the end.

BOTH solutions put "The Beatles" between "Beast" and "Beautiful" if applied properly. Both show "The Beatles" when reading the list.

But one doesn't mandate that it goes there, doesn't mandate that other songs starting with "The" have their The ignored (completely flexible), and allows for articles in any language to be handled on a case by case basis.

The other doesn't.

English speaking Rockbox users aren't the only Rockbox users. A solution should encompass everyone, or be able to, and it should not have side effects that prevent its use. "Ignore The" breaks both of these concepts, as if used for English songs it could at the same time break non-English songs. And if non-English articles are added, it could break songs where the same string of characters isn't an article.

[hotwire]

Sorry, my train of thought was considering the sorting order of current rockbox builds.

[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]

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.

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]

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.

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.

[lalittle]

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.

That seems logical to me.  It's the "re-writing" process that would take most of the time, so as long as it didn't have to re-write the files that didn't require it, it would save a great deal of time.

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.

My preference for keeping the process within Rockbox is because for people like myself that use a music organization program that does not make use of the sort tags, Rockbox is the only thing that would utilize them.  I'd therefore prefer to not have a separate program manipulate the tags -- I'd like to keep the original files unchanged.  My personal preference, in other words, would be to keep the process entirely self-contained within Rockbox.  This way, anybody who preferred the "ignore" approach could achieve "sorting without articles" by navigating the Rockbox menu and selecting the "create article-free sort tags" option.  I think this would make the feature much more "accessible" to a much wider group of people.

Thanks again,

Larry

[soap]

My preference for keeping the process within Rockbox is because for people like myself that use a music organization program that does not make use of the sort tags, Rockbox is the only thing that would utilize them.  I'd therefore prefer to not have a separate program manipulate the tags -- I'd like to keep the original files unchanged.

I don't see the separation you are seeing.  For either way this is implemented there will be a separate program manipulating the tags.  The only question is on what platform will said program run.

There is no difference between a Rockbox plugin creating sort tags and a "separate program" (PC side) manipulating the tags of the files residing on your DAP.  

A pluggin is nothing more than that, a "separate program", just one which runs on a small processor with limited resources.

There appears to be no difference between a PC side application and a DAP side application (pluggin) outside the aesthetic (and, again,  the limited resources affecting the DAP).  You must have your DAP plugged into the computer to transfer new files, might as well use the computer to create sort tags at that time.

[lalittle]

I don't see the separation you are seeing.  For either way this is implemented there will be a separate program manipulating the tags.  The only question is on what platform will said program run.

In one case, an entirely separate program is required -- this program must be downloaded, installed, and configured to run a specific script.  In many cases, the re-written files will then have to be either updated or re-imported into the libary of the management program being used on this system.  Rockbox users would also need to have prior knowledge of this separate process that existed outside of Rockbox -- i.e. it wouldn't be inherently apparent that this capability existed.

In the other case, everything needed for the system to work would be contained on the Rockbox itself, and since it would be a menu item, it would be visible to everybody as an available feature.  Since the Rockbox sorting capability would be the only use for the advanced tags for many people (given that many mainstream programs don't utilize these tags) I feel it makes sense to completely contain this capability within Rockbox.  The feature would be right there in the Rockbox menus for all users to see, which would make it readily accessible to everybody who wanted to utilize this feature.  If a separate, outside process was needed for this, many people would never even know about it.

On top of this, I would rather not manipulate my original files any further if I don't have to, and I prefer to use a single application for this rather than one app for my "main" audio management duties, and another for this specific purpose.  In the past, there have been various "issues" related to editing tags with more than one program.  These issues are not that common, but they do exist.

There is no difference between a Rockbox plugin creating sort tags and a "separate program" (PC side) manipulating the tags of the files residing on your DAP.

There may be no difference to the end result, but there is definitely a distinct difference in work-flow philosophy.  This work-flow difference may not matter to some people, but it does to others.

A pluggin is nothing more than that, a "separate program", just one which runs on a small processor with limited resources.

But since this is a Rockbox specific feature to many (if not most) people, it makes sense (in my opinion) to offer the "complete" process from within Rockbox.  Again, this will make the feature more "accessible" to a wider group of people.  I honestly believe that if this feature was offered (i.e. the ability to have Rockbox add these "sort tags" itself via a self-contained process), a lot of people would take advantage of it.

Larry

[soap]

I don't see the separation you are seeing.  For either way this is implemented there will be a separate program manipulating the tags.  The only question is on what platform will said program run.

In one case, an entirely separate program is required -- this program must be downloaded, installed, and configured to run a specific script.  In many cases, the re-written files will then have to be either updated or re-imported into the libary of the management program being used on this system.  

No - you merely retag files while they reside on your DAP.  You keep stressing this point, but it is an invalid one.  There is no need for this process to interfere with your music management program of choice.

Rockbox users would also need to have prior knowledge of this separate process that existed outside of Rockbox -- i.e. it wouldn't be inherently apparent that this capability existed.

As opposed to Rockbox users needing to have prior knowledge of the plugin?

In the other case, everything needed for the system to work would be contained on the Rockbox itself, and since it would be a menu item, it would be visible to everybody as an available feature.  Since the Rockbox sorting capability would be the only use for the advanced tags for many people (given that many mainstream programs don't utilize these tags) I feel it makes sense to completely contain this capability within Rockbox.  

 Be it a plugin or a PC side application the end results would be the same - modified metadata on the audio files residing on your DAP.  Whether this affects your usage of "mainstream" music management programs or not is inconsequential, as said program will be equally affected either way.

The feature would be right there in the Rockbox menus for all users to see,

Not to split hairs, but it will be a pluggin, not a menu item.

which would make it readily accessible to everybody who wanted to utilize this feature.  If a separate, outside process was needed for this, many people would never even know about it.

Failure to read the manual affects people's knowledge and understanding of the "Random Folder Advance" pluggin.  How would this one be different?

On top of this, I would rather not manipulate my original files any further if I don't have to,

Again - nowhere did anyone suggest modifying your original files.

and I prefer to use a single application for this rather than one app for my "main" audio management duties, and another for this specific purpose.  In the past, there have been various "issues" related to editing tags with more than one program.  These issues are not that common, but they do exist.

Straw man - a broken tagger is a broken tagger.  A pluggin would be modifying your tags in the exact same fashion as a PC side app.

EDIT:spelling

[safetydan]

One thing that I think needs clarification is that support for sort tags (e.g. TSOP and company) is not a Rockbox specific feature. These tags are defined in the ID3v2.4 metadata specification and equivalents can be found in various Vorbis comment specs.

There are several other systems out there that can edit and make use of these sort tags. For example the Squeezebox from SlimDevices supports using these tags (well technically I think it's the SlimServer, but the point stands). So Rockbox is not alone in using these.