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

[lalittle]

I don't understand how it's a better idea not updating the files?

My thinking was that the process could be significantly faster since it would not have to re-write the files, and the possibility of any sort of hiccups or corruption during this process would be eliminated.

Also, another "potential" concern of mine in all this has been how the re-writing of files might effect the "native" database on the unit.  I'm not sure about other units, but at least with iPods, Rockbox has always maintained a clean separation from the native database so that when booting to the native firmware, the iPod functions just like it would normally have.  This is important since there are still reasons to maintain full "native" functionality in certain situations.  Are there any potential issues with using the native firmware after re-writing the files via Rockbox?

Thanks,

Larry

[Llorean]

It would only make use of "legal" tags within the tagging specifications. This means the only time one could expect the original firmware to have problems is if it doesn't actually support the tagging specifications it claims to, in which case other "valid" files would break it just as easily.

All Rockbox would be doing is the same job many other taggers do. These tags aren't something we've made up, they're part of several specifications (though the only one for MP3 files that supports this, and is also supported by Rockbox, is ID3v2.4, it's also in Vorbis Comments, ApeV2, and I believe MP4 metadata though I could be wrong on the last one). In the case of the iPod for example, it would just mean more tags on the files that, because the Apple firmware doesn't support them, get ignored completely much like if you had additional comment tags or one of the other obscure tags that are part of the specification.

[ell1ps1s]

Since version 7.1, iTunes does support sorting tags. As far as I can tell, this is not just within its own database; it does also write  TSOP etc. tags to the audio files. (At least on my Mac; I can't comment on the Windows version, although I would hope they behave in the same way.) It also seems to supplement its own behaviour of ignoring (English) articles by adding sort tags, which would thus be available to Rockbox if support for those tags were implemented.

[Llorean]

I need to apologize, apparently there's no "official" way of doing it in Vorbis Comments. Which means I need to figure out where I "learned" that there was.

Either way, it looks like there's at least one mainstream program doing it this way now. And apparently, Apple has received complaints because "The Beatles" are sorted differently in the German version of iTunes than the English version because of differences in their list of articles...

[jurrie]

Forgive me, but I'm unclear what this means.  How does it "update the sorting attributes"?  Could you clarify the details on what the process would involve?  I agree that it seems like a better idea to not alter the files, but I'm unclear how your suggestion would work.

I had envisioned that the plugin would have logic similar to:

• chug through all supported/recognized (by the plugin) audio content
• upon encountering an item requiring sorting modification:
  
  • call (new) database API to locate the entry in the database (based on artist/album/track/title info)
  • if the entry exists in the database, call another (new) database API to update the entry (presumably using a handle/identifier returned by the previous call)
  • if the entry does not exist in the database, either add it to the database via another (new) database API call; or notify the user at completion that new content exists and suggest "General Settings -> Database -> Update Now" and then re-running the plugin

[jurrie]

I don't understand how it's a better idea not updating the files?

First: it's a lot of content to copy for each file just to add one, or a few, tags.  Second (and this is admittedly personal preference): I prefer that a "Player" not modify content.

Surely the files on your device aren't the primary copy of your music collection.

Correct.   However, the primary copy is where the change should be made (a flac file, in my case) and then propogated/published downstream.

Meanwhile, altering the files on the device allows the tags to be used by other programs (as there are programs that do support them),

Programs inquiring about audio content could(should?) query the database instead.

and insures that should you need to re-initialize the database you won't have to re-run the plugin.

Yup, that's one thing that I overlooked previously.  I've updated my previous post to reflect this "con".

In the end, it may just be a difference in philosophy.  I look at at Rockboxed players as players.  Content (including tags) should be created/manipulated elsewhere.  So.... if the perception is that this really is a "Rockbox issue" (which I don't - it's a tag accuracy/integrity issue), then having a sorting-tag fixer utility provided by the Rockbox community (a la, Rockbox Utility) would be my preferred solution.  Such a utility could be run on the primary audio content copy, or if the player's content is mounted on the utility's host it could be run on the Rockbox audio content copy.

[Llorean]

The expectation is that the user will have files they've manually added these tags to.

The plugin would exist as a *means* of adding these tags should their current audio management tools not support the tags, or because they don't want to manually add them and wish to use a basic algorithm stripping a certain list of articles. This plugin should of course be a "last resort" as a tool doing this would work best on a computer where it could run faster.

The idea isn't that this plugin is a primary solution. Rather it's a last resort solution for those who absolutely refuse to tag their files manually or have a utility on their computer do it, and insist everything must be done on the player.

I don't think it would be a good idea to address the database directly, nor do I think plugins should be reading from the database for information about a song unless the plugin is directly related to the database because when doing so the database may not exist. Not that the sort tags are likely to be used outside the context of the database, but I think they're an attribute of the file metadata and should be kept in the file metadata.

Manipulating the database directly, a la iTunes, results in files that aren't properly usable elsewhere because some or all of the metadata a user expects to have been added to them by their actions doesn't show up. (iTunes has been known to not write tags to files, only updating the iPod database, making those files impossible to use in Rockbox since they have no recognizable filename nor complete metadata)

[jurrie]

The expectation is that the user will have files they've manually added these tags to.

Agreed.

The idea isn't that this plugin is a primary solution. Rather it's a last resort solution for those who absolutely refuse to tag their files manually or have a utility on their computer do it, and insist everything must be done on the player.

Right.... I guess we just differ in opinion on where this tool should run.

I don't think it would be a good idea to address the database directly,

Agreed.  That's why I suggested a database API.  The only information that would be available to be read, or changed, would be that which the database elected to make available.

I'll stop harping on this now.  The easiest way for me to contribute in this area is to provide the simple conversion tools for one or more common formats.  Guess I'll get with safetydan to see what format he's looking for.

[safetydan]

I'll just chime in here and say that I've no interest in working on a tag editing plugin. Especially since even such mainstream applications as iTunes already support editing and maintaining the sort tags.

The only thing I'm going to address is getting the database to use the sort metadata (when it's available) for sorting album/artist/title for display.

[alienbiker99]

not to bring up this topic again, but i had a new idea. i was using mediamonkey and found out that it can ignore what ever words you want to ignore by typing it in one of the options. so i was thinking, why can't this kind of option be implemented into rockbox. this would solve the problem of not being multi-language. you would type it into an option which would create a .cfg then the database would ignore the word(s) that are in the config file + one space.

[Llorean]

Because it doesn't handle the cases where a word needs to be ignored for one song (because it's in one language) but not ignored for another (because it's in a different language).

[alienbiker99]

is there really a problem of languages overlapping their articles? and it would only ignore the leading article + one space

[Llorean]

Why does "it would only ignore the leading article + one space" matter, exactly?

And yes, we came up with some situations in the IRC channel where different languages had conflicting articles.

But the most important question is: How does this offer anything that the sort tags don't?

[alienbiker99]

it only means that the leading article would be ignored. i don't know how its different, i just thought of it last night. it seems easier than the tags, but it might not be if there is conflicting articles

[Llorean]

Previous suggestions included ignoring the leading article, so what I meant was, how do you mean for that to be different from other things said?

As well, sort tags offer the ability to have names sorted differently, numbers such as the word "Three" treated the same as the number "3" for people who prefer that, etc. A vast amount of increased flexibility, and no language restrictions.