Feature request: Optional tag delimiters

[AMP]

(07-08-2013 21:08)simoncn Wrote:  I undertand the reason for this request. However, the standards are very clear on this point and MinimServer is complying with the standards. If JRiver is not complying with the standards, this is a bug in JRiver that JRiver should fix. I don't think MinimServer should provide an option to "do the wrong thing" just because others are also "doing the wrong thing".

I understand all of this and agree with it as well, but the fact of the matter is that a large number of programs and, therefore a large number of users, are doing it the wrong way. In my mind, at least, there's nothing wrong with being a champion of standards (I know your background very well) while at the same time providing simple compatibility for those who, for whatever reason, are using a non-compliant tagging / management solution. Call it "solecistic mode" and admonish the offending developers in the release notes (it's going to be a LONG list).

Quote:Can you be more specific about which type of file tag with multiple values is not interpreted correctly by JRiver? For example, are these:

Vorbis comment tags in a FLAC file
iTunes tags in an MP4 or M4A file
ID3v2 tags in an MP3 or AIFF file (and if so, is this ID3v2.3 or ID3v2.4?)

As far as I know it's not that JRiver is interpreting any specific tag type incorrectly as the issue appears to impact any format. From what I understand JRiver indexes the first instance of any given tag and ignores any others. JRiver (similar to iTunes in this regard) builds a database out of the file tags and then uses the database for its functionality. A user can add database fields to meet his needs and in doing so has options as to the name and structure of those fields. Most common fields are strings and are interpreted as a blob of text regardless of content. For tags which store multiple unique values the structure is set as a "list" in which the content is a group of strings delimitated by semi-colons. The user has the option, for each database field, of maintaining that information solely in the database or writing it out to the files as well. In the case of lists JRiver writes them out as a single tag with items delimitated by semi-colons.

From my perspective, and I'm a relatively new JRiver user, the assumption is that in most cases the user will solely interact with JRiver for his media needs (management, import, purchase, playback, etc -- sounds familiar, eh?). Writing the tags back out to the files almost seems to be more of a courtesy than anything else. Getting them to change their ways would likely be only slightly easier than getting Apple to stop screwing up iTunes.

As with anything in computer audio it's all a matter of trade-offs. In my case JRiver provides some powerful functionality for managing a large library and at the same time will handle search, selection, and playback chores for non-UPnP devices. It's client-server functionality along with an absolutely stellar remote control app have solved numerous problems. Using yet another software package to fix JRiver's tagging structure is an option, but it adds another level of complexity and another set of steps in the workflow in which something could get severely messed up.

Again, this was simply a request for a feature which I'm sure a number of users would find valuable and in itself would have little negative impact on the default operation of Minimserver.