Please Explain Release Date tag

Can someone please explain how the Date/Release Date tag works in AS…

There seems to be inconsistencies because some albums get the full mm-dd-yyyy and others only show yyyy.

Also, whenever mm-dd-yyyy does work… the counter seems to be off by one day. For example, if I want the release date to be May 14, 2019 – I am forced to tag the album 2019-05-13 instead of 05-14

I think this is because AS automatically sets the dates time @ 12:00 AM, and that forces it to show the following +1 Day.

Can someone walk me through which Date tags they use in order to show full dates (mm-dd-yyy). I primarily use AIFF (id3v2) and FLAC (vorbis comments) files.

FIRST

Specific release dates (mm-dd-yyyy) are not always known and recorded in Musicbrainz. Sometimes, only a month and year is known and sometimes only a year.

SECOND

There should be no need for a counter – must be something wrong with Studio’s code.

Studio is giving me all blanks for the release date, although I have the ORIGINALDATE (when the song was first recorded and released) tag populated and sometimes have the RELEASEDATE tag populated. I also have the YEAR* tag populated. Therefore, I do not know from where Studio is getting the “release date” – @Antoine should answer this.

  • Some player programs get the release date from the YEAR tag (but I only use this tag for the year.

THIRD

Tracking dates in file tags is a messy business because no one follows a single standard.

FOURTH

Audirvana should publish Studio’s use of file tags, i.e. which tags are used and exactly for what.

[Windows 10, Studio 1.5.5]

1 Like

Yes I agree there should be a clear standard used. I noticed Release Year will work with AIFF files (but the counter is off by -1 days). However FLAC uses some other tag, and it only works sometimes.

This is clearly some sort of overlapping issue with personal tags vs MusicBrainz tags

There’s a lot of junk metadata in MusicBrainz.
Look what this guy published about AS on Audiophile Style Forum. The artists in his classical albums are wrong.

1 Like

Also related (with meta tags not being read by Studio)… I am having issues with the grouping tag.

I typically add my own grouping tag to single tracks or entire albums as a way to include some sub-genres for creating playlists. However, the grouping tag just comes up empty whenever I view the metadata in Studio for macOS. This seems to be the case for AIFF files with ID3v2.3 & 2.4 tags. I have not fully tested FLACs yet.

For flac files I used RELEASETIME (as advised by Audirvana Support). I populated the RELEASETIME tag as 1995-12-03; Studio displayed this in the release date column as: 12/2/1995 7:00:00 PM.

So what is going on here? Since I only populated the tag with the date, YYYY-MM-DD, and did not include the time, Studio read that as “1995-12-03 00:00:00” (midnight) UTC. That’s right, UTC time. My time zone is 5 hours behind UTC. So take away 5 hours and we have 1995-12-02 19:00:00. Studio reformatted this to “12/2/1995 7:00:00 PM”. Thanks to @VoyagerDude for explaining this to me.

While this explains what is going on, there is no explaining why Audirvana would use the RELEASETIME tag for release date. For flac files the standard tag is DATE. Sometimes, YEAR* (which is not standard) is used.

* File taggers, like mp3tag, use YEAR** for ID3 files (which is the proper tag for release date). And for consistency, also use YEAR for flac files.

** In reality, there is no tag by the name of YEAR within ID3 files. What happens is that the file taggers (and music players) map the YEAR tag to the appropriate ID3 entities (TDRC [ID3v2.4] or TYER + TDAT [ID3v2.3]).

To conclude, the RELEASETIME tag is a bad tag for Studio to use. I suspect there is a similar problem with the Release Year tag.

1 Like

Yeah what likely happens that the app uses a formatter for date fields that converts all date/time values to users local time zone.

This is always a tricky problem to solve in software engineering when the date time field only supposed to have a date value and the time portion needs to be ignored.

@Antoine

1 Like