"Original Release Date" tag not saving

- Only active plugin is "Add Cluster As Release" version (0.3).
- Tagger script is enabled:

$if($eq($left($lower(%artist%),4),the ),
    $set(artistsort,$right(%artist%,$sub($len(%artist%),4))\, The),
    $if($eq($left($lower(%artist%),3),an ),
        $set(artistsort,$right(%artist%,$sub($len(%artist%),3))\, An),
        $if($eq($left($lower(%artist%),2),a ),
            $set(artistsort,$right(%artist%,$sub($len(%artist%),2))\, A),
            $set(artistsort,%artist%))))

$if($eq($left($lower(%albumartist%),4),the ),
    $set(albumartistsort,$right(%albumartist%,$sub($len(%albumartist%),4))\, The),
    $if($eq($left($lower(%albumartist%),3),an ),
        $set(albumartistsort,$right(%albumartist%,$sub($len(%albumartist%),3))\, An),
        $if($eq($left($lower(%albumartist%),2),a ),
            $set(albumartistsort,$right(%albumartist%,$sub($len(%albumartist%),2))\, A),
            $set(albumartistsort,%albumartist%))))

$unset(genre)

- My entire music collection is AAC (m4a) files, but I just tested on an mp3 as well.  To my surprise, the "ORIGYEAR" tag saved just fine (and independently verified with Mp3Tag that it is there).  So the issue must have something to do with AAC music files vs. mp3's.

Any further insights?  Are there perhaps different "versions" of AAC files which can or cannot support this kind of tagging?

Thanks for your help!

Although I would prefer to have the original release date as its own tag to preserve the integrity of the tagging process, the script example you post below is certainly a good workaround until (if?) this functionality is implemented.

Thanks for your help, voiceinsideyou!

I have installed picard 1.0 today. It seems to be absolutly the same issue for me, but with only mp3 files in catalog.
=>I move some album folders into picard. It finds the right album but shows a difference in original date (Datum der Erstveroeffentlichung). If i save the album all checkmarks change to green. Now i remove the album and move it in again. The result ist the same as the first time -> a difference in original date  :-(
Have Win7 64bit here.
thx in advance  Yves

I think he is saying that the saving process didn't change the date at all even after saving.

What I read is his file has
Date of 01-01-2012

musicbrainz original date
Date of 02-02-2012

When saved it shows a green check mark, but when added into Picard again the date is still 01-01-2012

If wrong I am sorry, also make sure you are saving with ID3 2.4 tags and not 2.3

I agree on it being best not to assume, and apologize for my guess work maybe making this thread more confusing.

I can't say the recommendation was blind, being that it was mentioned previously in this thread or through the links to the tickets that 2.3 does not have the same full value and thus you would need 2.4 if you wanted year/month/day instead of just year.

However you are right that I did forget to take the risks of tag changing and how it may affect the situation into account because of how the user uses their music and through what devices.

I had to read your posts a few times, to see the answer was given allready. I have the seeting to use v2.3. That may be the reason. But at all it is some kind of bad, if i save an album, und if i try to check if its ok, there are new (old) changes. Probably this could be filtered by picard to let the green checkmarks be there. ?

If you want to stay with ID3v2.3, a workaround you might want to try is to change your Options > advanced > tagger script to include

$if(%originaldate%,$set(originaldate,$left(%originaldate%,4)))

This will normalise the date from MB to the same as what ID3v2.3 can represent.

This one is likely due to the fact that ID3v2.3 doesn't (properly) support multiple values for fields so when it persists them, it has to insert some kind of string splitter. I'm confused though, as I regularly save composers etc to ID3 and don't recall having an issue with the metadata box comparisons - and these are often multi-valued. I'll have to have a check later as to whether I understand this as expected behaviour. Maybe there's something special for ISRC.

Assuming the '/' is what's in the files, a workaround that might work (not tested) is

$if(%isrc%,$set(isrc,$replace(%isrc%,; ,/)))

This will force the MB data into a single-value (rather than multi-valued); so you wouldn't want to do this if you're saving files to formats that DO support multi-valued fields (e.g. Vorbis comment).

A better longer term fix might be to allow a user-specified separator when converting down to ID3v2.3; and to use this same separator internally in Picard when displaying multi-valued tags in the metadatabox.