+- MinimServer Forum (https://forum.minimserver.com)
+-- Forum: MinimServer (/forumdisplay.php?fid=1)
+--- Forum: General (/forumdisplay.php?fid=2)
+--- Thread: Feature request: Optional tag delimiters (/showthread.php?tid=725)
Pages: 1 2
Feature request: Optional tag delimiters - AMP - 07-08-2013 20:34
I understand that in order for Minimserver to interpret tags with multiple values that those tags have to be repeated in the file rather than entered with a delimiter character. I understand the reasoning for this... but...
Would it be possible in a future version to have a configuration option for a specific delimiter to be interpreted for a specific tag field?
Here's why... I'm an audio dealer and use USB-connected playback devices just about as much as UPnP devices. For USB I'm using JRiver (or Audirvana) for playback and I also use JRiver to manage my library and keep metadata up-to-date. Some of the features of JRiver make the tagging process very easy and the majority of my customers are happy with this solution.
Unfortunately, when a database field in JRiver is setup for multiple values it writes the tag to the file as a semi-colon-deliminated string into one tag entry. Furthermore, JRiver doesn't interpret multiple instances of the same tag in a file (so re-tagging with mp3tag won't work either).
In my case I make extensive use of the 'Soloists' tag in JRiver for my classical library, but Minimserver can't properly interpret the Soloist tags for which multiple soloists have been entered.
Although I understand that a delimiter isn't the "proper" way to tag the files it has become an unfortunate default for a lot of software packages.
Would it be possible to add an option which would allow one to specify that for a certain tag (say Soloists) Minimserver should interpret a specific character as a field delimiter and build its cache accordingly?
RE: Feature request: Optional tag delimiters - Oliviander - 07-08-2013 20:54
(07-08-2013 20:34)AMP Wrote: Would it be possible to add an option which would allow one to specify that for a certain tag (say Soloists) Minimserver should interpret a specific character as a field delimiter and build its cache accordingly?
An easy solution to your problem:
Use a custom tag for youre files for
the use with minimserver and ignore
the original Soloists Tag in Minimserver.
Using Mp3Tag
you can create this custom
tag accordingly to the right specs
with only one command.
And you can do that
for all your files at once.
You then can still manage the tags in JRiver to your liking
just use this command on your new (or changed) files
from time to time (best before restarting MinS)
RE: Feature request: Optional tag delimiters - simoncn - 07-08-2013 21:08
(07-08-2013 20:34)AMP Wrote: I understand that in order for Minimserver to interpret tags with multiple values that those tags have to be repeated in the file rather than entered with a delimiter character. I understand the reasoning for this... but...
Would it be possible in a future version to have a configuration option for a specific delimiter to be interpreted for a specific tag field?
Here's why... I'm an audio dealer and use USB-connected playback devices just about as much as UPnP devices. For USB I'm using JRiver (or Audirvana) for playback and I also use JRiver to manage my library and keep metadata up-to-date. Some of the features of JRiver make the tagging process very easy and the majority of my customers are happy with this solution.
Unfortunately, when a database field in JRiver is setup for multiple values it writes the tag to the file as a semi-colon-deliminated string into one tag entry. Furthermore, JRiver doesn't interpret multiple instances of the same tag in a file (so re-tagging with mp3tag won't work either).
In my case I make extensive use of the 'Soloists' tag in JRiver for my classical library, but Minimserver can't properly interpret the Soloist tags for which multiple soloists have been entered.
Although I understand that a delimiter isn't the "proper" way to tag the files it has become an unfortunate default for a lot of software packages.
Would it be possible to add an option which would allow one to specify that for a certain tag (say Soloists) Minimserver should interpret a specific character as a field delimiter and build its cache accordingly?
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".
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?)
RE: Feature request: Optional tag delimiters - AMP - 07-08-2013 22:04
(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.
RE: Feature request: Optional tag delimiters - simoncn - 07-08-2013 23:35
(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.
RE: Feature request: Optional tag delimiters - simoncn - 11-08-2013 21:46
(07-08-2013 22:04)AMP Wrote: 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.
I tried this by using JRiver MC 18 to import a local FLAC file that has multiple Artist tags. JRiver imported both tags correctly and shows the artists with a semicolon delimiter. The semicolon seems to be JRiver's visual indication that there are multiple tag values for the same tag name.
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.
I tried this as well. The updated artist values were both written correctly to the FLAC file. They were written as separate tags, not as a single tag with a semicolon delimiter.
Based on these tests, it appears that JRiver and MinimServer are fully interoperable without any need for a change to either JRiver or MinimServer.
RE: Feature request: Optional tag delimiters - AMP - 12-08-2013 03:56
After your test I did some more digging and think I've figured out the problem. First off, it would appear that the documentation that I was reading on how JRiver was interpreting and writing tags was incorrect (it was a post on their forum).
All of my files are AIFF and are tagged with ID3v2.4. When JRiver writes out the tags it places the separate values into a TXXX frame with the description "Soloists" and each value separated by a NULL character.
Not sure if this was correct behavior I looked at the ID3v2.4 spec on id3.org and found that the language is somewhat ambiguous. For "T..." frames the null separator is correct, but depending on how the spec is read that either does or does not apply to TXXX frames. What is clear is that the descriptor "Solosists" cannot be repeated in a single tag.
Quote:There may be more than one
"TXXX" frame in each tag, but only one with the same description.
So, it would appear that multiple TXXX frames for multiple values won't work and based on looking at the behavior of many tagging programs none take this approach...
I converted the AIFF to an mp3 with dbpoweramp and looked at the file in dbpoweramp, metadatics (mac), kid3 (mac), mp3tag, JRiver, and Media Rage. All showed the file as having id3v2.3 tags and all showed the string for the soloists TXXX frame as "soloist 1/soloist 2"
I changed the tag format to ID3v2.4 in mp2tag and re-wrote it and the value of the TXXX frame changed to "Soloist 1(NULL)Soloist 2". In fact, with every piece of tagging software that I have the Soloists frame was written out using the NULL character as the delimiter.
I've seen it mentioned elsewhere on this forum that your interpretation of the standard is that the NULL delimiter doesn't apply to TXXX frames, and having read the spec I can see that interpretation. Unfortunately, it would appear that few others are reading it that way and instead are creating multiple-entry TXXX frames using the null character. I've yet to find a program which will write a multiple-value tag out as multiple TXXX frames with the same descriptor.
RE: Feature request: Optional tag delimiters - simoncn - 12-08-2013 16:10
(12-08-2013 03:56)AMP Wrote: There may be more than one "TXXX" frame in each tag, but only one with the same description.
So, it would appear that multiple TXXX frames for multiple values won't work and based on looking at the behavior of many tagging programs none take this approach...
Thanks for pointing this out. I hadn't noticed this statement in my previous reading of the ID3 specs.
Quote:I've seen it mentioned elsewhere on this forum that your interpretation of the standard is that the NULL delimiter doesn't apply to TXXX frames, and having read the spec I can see that interpretation. Unfortunately, it would appear that few others are reading it that way and instead are creating multiple-entry TXXX frames using the null character. I've yet to find a program which will write a multiple-value tag out as multiple TXXX frames with the same descriptor.
Given that multiple TXXX strings with the same description aren't allowed, and the statement in the ID3v2.4 spec that the TXXX frame 'is intended for one-string text information concerning the audio file in a similar way to the other "T"-frames' (which do allow null separators), I think it's reasonable for MinimServer to treat null characters in ID3v2.4 TXXX tags as separators for multiple values.
My previous opinion was based on the statement in section 4.2.6 of the ID3v2.4 spec that defines the Value field as "<text string according to encoding>", which doesn't match the line in section 4.2 that defines the Information field as "<text string(s) according to encoding>". Your investigations have convinced me that the 4.2.6 words are an incorrect carry-over from the corresponding section in the ID3v2.3 spec, and should have been changed to match the 4.2 words.
I'm still of the opinion that MinimServer shouldn't split an ID3v2.3 TXXX frame into multiple values if the Information field contains '/' characters, but should interpret these '/' characters as valid text in the frame's (single) value.
RE: Feature request: Optional tag delimiters - AMP - 13-08-2013 00:35
The ID3 specs aren't especially clear in a lot of respects and once I sat down and started reading it became obvious that certain sections got carried through from previous versions with inconsistent changes (and no proofreader).
Thanks again for looking into this and I look forward to an updated version of minimserver!
The browsing functionality provided by Minimserver is far ahead of anything else out there. I actually setup one of my JRiver boxes as a UPnP renderer so that I can browse the Minimserver catalog via BubbleUPnP with playback through JRiver via USB. I'm not able to setup JRiver's browsing structure to be anywhere near as flexible as Minimserver. With close to 10,000 classical tracks alone being able to narrow down results through multiple tags is a godsend.
RE: Feature request: Optional tag delimiters - simoncn - 13-08-2013 07:35
(13-08-2013 00:35)AMP Wrote: The ID3 specs aren't especially clear in a lot of respects and once I sat down and started reading it became obvious that certain sections got carried through from previous versions with inconsistent changes (and no proofreader).
Thanks again for looking into this and I look forward to an updated version of minimserver!
Thanks for your help with clarifying the intention of the ID3v2.4 spec in this area.
Quote:The browsing functionality provided by Minimserver is far ahead of anything else out there. I actually setup one of my JRiver boxes as a UPnP renderer so that I can browse the Minimserver catalog via BubbleUPnP with playback through JRiver via USB. I'm not able to setup JRiver's browsing structure to be anywhere near as flexible as Minimserver. With close to 10,000 classical tracks alone being able to narrow down results through multiple tags is a godsend.
Thanks very much!