title
Products            Buy            Support Forum            Professional            About            Codec Central
 

Multiple Value Handling in Tags

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • TechVsLife
    dBpoweramp Enthusiast
    • May 2007
    • 95

    Multiple Value Handling in Tags

    I'm trying to sort out multiple value handling (not a request for changes, only info):
    1: wma files (are supposed to) support multiple values even for the AlbumArtist tag, as well as a bunch of other tags:

    --But should one avoid multiple values even for some tags listed there because of some problems in the way that the wma sdk or dbpoweramp handles it? See:
    Update which corrects the storage of CDTOC in WMA files, also Styles tag is moved to WM/ProviderStyles, like WMP11 uses (but is not displayed...) <Now Released>


    2. The itunes m4a or apple lossless format does not appear to support multiple values for artist. (--also it annoyingly lacks a conductor tag.) Am I overlooking something? or advice on how to handle this? This is a problem for classical music, where it would be best to have conductor, soloist, composer, and orchestra/band all listed as artists, and then also (singly) in individual fields (composer, conductor etc). Apparently, all attempts to add multiple values for the artist tag in apple's m4a format produce an entirely new "hybrid/joined" artist (--that's bad):
    The page you tried was not found. You may have used an outdated link or may have typed the address (URL) incorrectly.


    (3. For mp3, it looks like id3v2.4 has the best support for multiple values, but v2.3 is more widely supported.)

    Any advice or caveats on this subject is appreciated.
    Last edited by TechVsLife; 01-19-2009, 06:53 AM.
  • Spoon
    Administrator
    • Apr 2002
    • 43891

    #2
    Re: Multiple Value Handling in Tags

    Indeed often even MS do not follow their own spec!

    >itunes m4a or apple lossless format does not appear to support multiple values for artist.

    Yes it does, off the top of my head they are seperated by '/', or similar.
    Spoon
    www.dbpoweramp.com

    Comment

    • TechVsLife
      dBpoweramp Enthusiast
      • May 2007
      • 95

      #3
      Re: Multiple Value Handling in Tags

      Thanks--unless I'm missing something, apple m4a (iTunes) format does NOT support multiple values for artist. If you separate with a slash, it just combines it into a new "hybrid" artist (so for iTunes browsing etc. Brahms/Perlman becomes the new and otherwise unknown artist "Brahms/Perlman" and not two different artists: "Brahms" and "Perlman"). This is covered in this thread, and other discussions on the web:
      The page you tried was not found. You may have used an outdated link or may have typed the address (URL) incorrectly.


      If this is correct, I'm amazed that apple does not support this basic feature, which is in mp3, flac, and wma. Apparently they didn't give much thought to classical music with the spec. As far as I can see, a big classical music library with m4a format is going to be a mess.

      Originally posted by Spoon
      >itunes m4a or apple lossless format does not appear to support multiple values for artist.

      Yes it does, off the top of my head they are seperated by '/', or similar.

      Comment

      • Spoon
        Administrator
        • Apr 2002
        • 43891

        #4
        Re: Multiple Value Handling in Tags

        That link is incorrect, '/' is the documented spec which we and other programs follow.
        Spoon
        www.dbpoweramp.com

        Comment

        • TechVsLife
          dBpoweramp Enthusiast
          • May 2007
          • 95

          #5
          Re: Multiple Value Handling in Tags

          The link acknowledges that "/" is in the spec as a theoretical matter (in the last post on that thread):
          Whereas in WMP & the ID3 spec. you would use a semi-colon to separate items you will find that iTunes & the Music store use a slash instead. However as you so rightly say iTunes takes the information and construes a new artist entity rather than two artists connected to the same track.
          The issue is that iTunes (including version 8) does NOT read a separate artist, it reads one hybrid artist (so the "/" is meaningless). You cannot browse by the artists separately, but only by a new joint "artist" ("A/B"), different from the true artists ("A" or "B"). Every post I've read about this says the same and is very critical of it. (In wmp by contrast, a wma file that has multiple artists appears and can be browsed under A and B separately).

          But it seems that support for multiple values in any tag is weak and conflicted at best across players and encoders. As far as I can see, wma and flac have by far the best support, followed by mp3 (which has issues with the conflicts with three separate tag standards, it seems id3v2.3 is the closest to one). Unless I always stick with flac and wma, I guess it's better to not rely on multiple values, though it's a much much cleaner solution. Unfortunately too much music is sold in m4a to always stick with wma and flac.

          I think I'll end up having a single value for Composer, and putting that under Artist as well. Then I'll risk putting multiple values for the performers, orchestra, and conductor (and composer) under their new (!) tag AlbumArtist--on the theory that if the problems are ever resolved, I can find it there, but at least I'll always be sure to easily browse works by composer. (I decided Album will store the unique title of the work, e.g. beethoven - symph #6 - karajan, and I won't organize by the cd collection or title. filename will be unique "album" name followed by ordered movement number (similar to track number), so no necessary dependence on folders).

          I might also try custom tags, in case Apple ever decides to add a conductor field etc.

          p.s. Or is there a fix for the iTunes behavior, or some correction in some iTunes 9 beta? I haven't heard of any.
          Last edited by TechVsLife; 01-19-2009, 07:00 PM.

          Comment

          • TechVsLife
            dBpoweramp Enthusiast
            • May 2007
            • 95

            #6
            Re: Multiple Value Handling in Tags

            On further research, it seems safer to have album artist also match the artist (composer), because of the itunes/iPod tendency to multiply albums whenever any difference is encountered. I'll put all of the multiple artist value information into custom tag(s) and see how that goes. (I already have the principal performer's last name(s) appended to the end of the unique work/album name, which makes heavy use of abbreviations.)

            btw, here's another description of the multiple value problem for the artist tag in apple m4a format (vs wma format in media monkey or wmp):


            here's a good guide to the issues in tagging m4a for classical music (a bit of an overkill):

            I wouldn't actually "lie" by putting the non-composers in the composer field, but I'll put them somewhere.
            Last edited by TechVsLife; 01-19-2009, 08:54 PM.

            Comment

            • TechVsLife
              dBpoweramp Enthusiast
              • May 2007
              • 95

              #7
              Re: Multiple Value Handling in Tags

              just fyi for reference:
              This piece gives a more technical account of the current lack of support for multiple values in iTunes m4a files--apparently itunes chokes on null separators:

              There is no way to store multiple values; an atom can only occur once, and null-separation makes iTunes do strange things.
              The piece also describes a workaround using custom tags, though the risk would be that it would get broken in a later itunes (since not documented).
              (as for the "/" separator, as discussed itunes does not treat that any different than any other character, so it does not separate multiple values: two artists "A" / "B" are treated as one new artist named "A/B")
              Last edited by TechVsLife; 02-05-2009, 04:03 AM.

              Comment

              Working...

              ]]>