Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 5 of 5

Thread: Tag Merging

  1. #1
    Senior Member JJZolx's Avatar
    Join Date
    Apr 2005
    Location
    Colorado
    Posts
    11,531

    Tag Merging

    IMO, this topic needs to be reexamined, as I feel that SlimServer 6.5's current behavior of not merging tags is causing a lot of unnecessary confusion.

    Here is Dan's explanation behind the decision to _not_ merge tags in the new scanner included with version 6.5 (from http://forums.slimdevices.com/showth...998#post126991):

    Quote Originally Posted by Dan Sully View Post
    This is another one of the 'some people want it one way, and some people want
    it another' debates. There's a real issue behind this, in that a lot of
    programs (iTunes notably) will not update an ID3v1 tag in a file if an ID3v2
    tag exists. We used to merge the two tags, but people were being confused,
    and getting incorrect data when they would change tag information but would
    still see the old ID3v1 data.
    The part I'm having trouble with is the idea that there are many people who would actually have a preference for the current behavior. Why would anyone _want_ SlimServer to NOT merge tags? The only thing I can think of is to be able to use SlimServer as a tool for cleaing up their tags. Which is an odd use for SlimServer.

    Yes, it can be confusing if you're in some other program looking at id3v1 tags and wondering why SlimServer shows different values. But that's a shortcoming of some _other_ software, or of the program used to tag those files.

    In my experience, most programs DO merge tags, so that when you're viewing tags you see the product of the merged tags, with id3v2 generally taking precedence over id3v1. When an id3v2 field is not present (or is an empty string or zero value) then the id3v1 field value is displayed.

    If people really do have a preference (again, I'm having a hard time believing that), then make tag merging an OPTION to the scanner, with the default behavior to merge them, not the current weirdness.

  2. #2
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,323

    Tag Merging

    > Why would anyone _want_ SlimServer to NOT merge tags?

    Thanks for citing Dan's answer to this question yourself:

    >> We used to merge the two tags, but people were being confused,
    >> and getting incorrect data when they would change tag information but
    >> would still see the old ID3v1 data.


    > that's a shortcoming of some _other_ software, or of the program used
    > to tag those files.


    Tell them to fix it.

    --

    Michael

    -----------------------------------------------------------------
    http://www.herger.net/SlimCD - your SlimServer on a CD
    http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR


  3. #3
    Senior Member JJZolx's Avatar
    Join Date
    Apr 2005
    Location
    Colorado
    Posts
    11,531
    Quote Originally Posted by Michael Herger View Post
    >> We used to merge the two tags, but people were being confused,
    >> and getting incorrect data when they would change tag information but
    >> would still see the old ID3v1 data.[/color][/color]

    > that's a shortcoming of some _other_ software, or of the program used
    > to tag those files.


    Tell them to fix it.
    So you break SlimServer in response to other software being confusing for the user?

    "people were being confused, and getting incorrect data when they would change tag information but would still see the old ID3v1 data"

    This makes no sense. If iTunes or some other software ignores the id3v1 data when making updates to tags, then how does throwing out _all_ id3v1 data address this problem? If the update is done only to the id3v2 tags, then most people would expect the id3v2 tag data to take precedence over the id3v1 data, but not necessarily to exclude _all_ of the id3v1 fields. The issue that the current behavior creates is that people often see merged data in other software and don't know/care whether (say) the ARTIST data is in an id3v1 tag while the ALBUM is id3v2. Even worse, by adding a single id3v2 (or APE) tag, they effectively wipe out all of the id3v1 data without having any idea how or why or where that happened.
    Last edited by JJZolx; 2006-12-20 at 02:33.

  4. #4
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,323

    Re: Tag Merging

    > So you break SlimServer in response to other software being confusing
    > for the user?


    Nobody is breaking SlimServer in not fixing bugs in other's software.

    > If iTunes or some other software ignores the
    > id3v1 data when making updates to tags, then how does throwing out
    > _all_ id3v1 data address this problem?


    It doesn't. But it does not pretend to do so neither. But it's a very
    honest approach: we can't fix all the problems others create. We tried. We
    failed (in the user's eyes). We give up. Please fix your tags.

    --

    Michael

    -----------------------------------------------------------------
    http://www.herger.net/SlimCD - your SlimServer on a CD
    http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR


  5. #5
    Senior Member gerph's Avatar
    Join Date
    Oct 2005
    Location
    Reading
    Posts
    179
    Quote Originally Posted by JJZolx View Post
    IMO, this topic needs to be reexamined, as I feel that SlimServer 6.5's current behavior of not merging tags is causing a lot of unnecessary confusion.

    Here is Dan's explanation behind the decision to _not_ merge tags in the new scanner included with version 6.5 (from http://forums.slimdevices.com/showth...998#post126991):



    The part I'm having trouble with is the idea that there are many people who would actually have a preference for the current behavior. Why would anyone _want_ SlimServer to NOT merge tags?
    Because the other tags are just plain wrong. For example, I use ID3v1 tags on everything. Occassionally an ID3v2 from someone else slips through and I forget to strip it. Invariably this contains rubbish - I only trust a couple of people to actually tag things properly - and thus means that things appear wrongly in the server. In my case, I'd far prefer to use ID3v1 only. Other things use ID3v2 only (I don't know of any that do, but there must be some). My Archos uses ID3v2 if it's present and ignores the ID3v1 in that case (ie same as SlimServer does at present). There are, as has been suggested, many different ways of processing this data, but other than SlimServer/MP3::Info I've never come across any that merge the ID3v1 and ID3v2 information.

    It's made worse that the APE tags actually override the ID3 tags - I definitely don't want that to happen under normal circumstances.

    Earlier this year, I was very tempted to create a set of options to control the processing of ID3 tags. At the time I couldn't really be bothered though. Today, though, I decided to do it.

    http://usenet.gerph.org/SlimServer/i...iguration.diff

    This adds a new configuration 'processID3' and 'processAPE' to the top of the Behaviour settings window. The ID3 configuration allows :
    0 All tags to be ignored
    1 ID3v1 only
    2 ID3v2 only
    3 ID3v1 and ID3v2 merged (ie pre-6.3 behaviour)
    4 ID3v2 if present, ID3v1 if not (ie current behaviour)

    The APE configuration allows the settings to be turned on and off and that's it. This only applies to MP3 files.

    The patch applies to a recent trunk version (ie 7.0) so will not work on earlier systems - the settings code has changed and so you would not be able to configure the changes. The changes to Slim/Formats/MP3.pm would probably work on 6.5 however, so you would only need to add the configuration manually. This is left as an exercise for the reader.

    In the Strings.txt file, I've just added the new strings to the top of the file to make extracting them and putting them in a suitable place easier.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •