Feature request: Optional tag delimiters

[simoncn]

(07-08-2013 22:04)AMP Wrote:  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).

Each non-compliant implementation of a standard (if this is not an oxymoron) weakens the standard. When two non-compliant implementations provide interoperablity by non-compliant means, this weakens the standard even more. Weakening the standard reduces its value as a means of ensuring compatibility and interoperability between different implementations, which is not in the best interests of users.

Admonishing others who violate the standard whilst doing likewise myself would be hypocritical as well as pointless. The only way to get these implementations fixed is to establish a strong standard with high-quality implementations of the standard and hope that market forces will bring pressure on noncompliant implementations to become compliant.

Quote: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.

If this is correct, it is a clear bug in JRiver as it would mean that users with files tagged to the standard are unable to import these files into JRiver without losing valuable tag information. This seems clearly contrary to JRiver's commercial interests, as it will reduce their ability to attract new users who have made a significant investment in tagging their library.

Quote: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.

This is a bug as well, but given the JRiver view of the world that you have described, there would be less motivation for JRiver to fix this "export" bug than to fix the "import" bug.

Quote: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.

I understand your perspective, but from my perspective this would have a harmful effect on the health of the currently established open standards for file tagging. The effect of weakening these standards would be to weaken the current reasonably diverse marketplace for interoperable audio products based on open standards, and this would tip the balance further towards proprietary ecosystems such as JRiver, Apple, etc. I don't think this would be a good thing for users, and this is why I'm doing my best in MinimServer to follow established open standards where these currently exist.