Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Jamil]

For a long time I have been trying to figure out what media application has been storing a Date tag containing an integer (36245 for example).  All applications I use support the Year tag that contains a string of text ("2020" for example).  I am just now learning that it is Media Center doing this.  I am not understanding why at all.

I store the release year for all of my audio files (YYYY).  I do not store a full date for any file and never need to store this (YYYY-MM-DD).  It appears that Media Center has indirect support for a Year tag string in reading only.  I am seeing that it will always write out this Date containing an integer value that is meaningless to me.

Is there an option to support Year in both reading and writing and shut off Date?  For now, I have disabled Date to never have it written again.

[EnglishTiger]

For a long time I have been trying to figure out what media application has been storing a Date tag containing an integer (36245 for example).  All applications I use support the Year tag that contains a string of text ("2020" for example).  I am just now learning that it is Media Center doing this.  I am not understanding why at all.

I store the release year for all of my audio files (YYYY).  I do not store a full date for any file and never need to store this (YYYY-MM-DD).  It appears that Media Center has indirect support for a Year tag string in reading only.  I am seeing that it will always write out this Date containing an integer value that is meaningless to me.

Is there an option to support Year in both reading and writing and shut off Date?  For now, I have disabled Date to never have it written again.

Like you I only ever Input/Use the YYYY part of the Date Tag/Field. However regardless of if I'm using MC, Widows Explorer, WMP12, Media Monkey, dpPoweramp all dates entered into them in YYYY format all ways display correctly in YYYY format in all those applications; because they all store "Date" as a numeric "Julian/Ordinal Date" as per the IDV3.1 Standard https://en.wikipedia.org/wiki/ID3.

Therefore if the Date Tag/Field is not showing up in YYYY format in your other applications it is because it is them and not MC that is holding Dates in a Non-Standard Format.

[Jamil]

I have a tag called Year that contains text.

MC26 is writing a tag called Date that contains this number:  38718

My question was can I turn off Date and get Year that is widely supported by everything to work instead?

Is your answer yes, no, or I do not know?

[JimH]

There are several date tags.  The wiki should explain this.   Or try a search.

[EnglishTiger]

I have a tag called Year that contains text.

MC26 is writing a tag called Date that contains this number:  38718

My question was can I turn off Date and get Year that is widely supported by everything to work instead?

Is your answer yes, no, or I do not know?

No - because MC already has an unamendable  integer Field/Tag Labelled "Year"

[JimH]

https://wiki.jriver.com/index.php/Library_Fields

and

https://wiki.jriver.com/index.php/Tagging

MC follows standards for tagging.

[Jamil]

Thanks, Jim.

I am seeing from specs that the date recorded is a tag called "DATE".  The tag name per the specs is not YEAR.  A YEAR tag is simply an added tag not per specification (according to the Vorbis tag spec anyway).  What I do not see listed at all is that it is supposed to be a numeric integer.  I am seeing DATE valued in my FLAC files as plain text like this:

DATE=2011

[RoderickGI]

MC internally stores the [Date] field as a floating-point number, which represents the number of days since the Epoch started, with decimal values representing time. If you enter "13/02/2020 6:35pm" into the [Date] field, MC will save that as 43874.7743055555547471. This can be seen by creating an Expression Column in a View and using the expression [Date,0], which shows the raw data.

However, the [Date] field is written to the Vorbis Comment Block DATE tag in the field in plain text. In the above example, as 2020. Yes, it just writes the year for FLAC files. The numeric [Date] field value is also written to the Vorbis Comment Block in the tag JR_DATE. This tag is only written to the file if there is more information than just the year in the [Date] field.

The [Year] field in MC is directly derived from the [Date] tag, and vice versa. If you enter "13/02/2020 6:35pm" into the [Date] field as above, the [Year] field will be set to "2020". If you enter "13/02/2020 6:35pm" into the [Year] field, the field will be cleared. If you enter "2013" into the [Year] field, the [Date] field will be set to "2013" (without quotes in any of the above of course).

The [Date (release)] field is an independent date used in MC. It is a Date Type field and stores the full decimal number of days since the Epoch started, as per the [Date] field. Yes, it is stored in the Vorbis Comment Block as a decimal value, using the tag "DATE (RELEASE)". You can enter just the year into the field, and MC will format it correctly. MC no doubt reads Release Date tags from file, when they are available. But I don't remember the actual tag names it reads. That is a little research for you.

The Epoch Date used by MC is December 30th, 1899 at 00:00:00, which is the Microsoft COM DATE epoch. See https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoch_dates_in_computing. Other applications should be capable of using it.

There is no standard for tags in the Vorbis Comment Block, only accepted values. https://en.wikipedia.org/wiki/Vorbis_comment
Could you share a link to the Vorbis Comment Spec you are referring to? I can't find anything that refers to the Release Date, other than application specific information. i.e. https://picard.musicbrainz.org/docs/mappings/ You originally said Release Date was your concern.


Note in the above discussion, MC fields are a different thing to file tags. They are related, of course, by they are not the same. MC read tags from files and write them to files as per the standards.

[Jamil]

Here's is the long Vorbis spec:

https://xiph.org/vorbis/doc/Vorbis_I_spec.html

This is the brief version:

https://xiph.org/vorbis/doc/v-comment.html

Just as an FYI, I just purchased a downloadable FLAC file that already had tags set by the artist.  Here is how the DATE tag appears:



As far as I knew, this was the commonly used format.  Digits of a text string that represent the year.  It is always the DATE tag used to store the year.

[RoderickGI]

That is one of the pages I looked up. As it says, "Field names Below is a proposed, minimal list of standard field names with a description of intended use. No single or group of field names is mandatory; a comment header may contain one, all or none of the names in this list."

None of it is mandatory. It isn't a specification, just a proposal. I've never found an actual specification for tags used, other than on a specific application site. Also note that the pages you refer to propose that DATE stores the date. They don't say anything about only storing the year.

Besides, MC does comply with that proposal. It puts the [Date] field into the DATE tag, in the format "DATE=2020", as text. It does include the spaces in the display inside MC, but that is the only difference. MC will read (and write) that tag correctly, and put it into the [Date] field for use by MC, in numeric format.

Generally, the [Date] field in MC is intended to represent the Date Recorded, while the [Date (release)] is usually a separate date, but is also often the only known date, and so the Date Released ends up in the [Date] field, because providers of digital music tracks and metadata sites put that date into the DATE tag. How the dates get used in MC is open to interpretation, but MC is doing the "correct" thing in reading/writing tags from/to the file.


Your original post referred to the Release Year, which is stored as a numeric value when stored in the [Date (release)] field, but when the Release Year is stored in the [Date] field MC does exactly what you want.

So I'm confused. What is the problem?

[Jamil]

So I'm confused. What is the problem?

I have a tag called Year that contains text.

MC26 is writing a tag called Date that contains this number:  38718

My question was can I turn off Date and get Year that is widely supported by everything to work instead?

Is your answer yes, no, or I do not know?

MC26 is writing a tag called Date that contains this number:  38718.  This number is 100% useless and meaningless.

I want Date to be stored as a plain text year, as is done everywhere else just as in the clear example I pasted a screenshot of.  This is the problem.  Since MC26 cannot do this, this is another field I disabled with writing of tags.  This is the problem.

[tij]

38718 is 1/1/2006 ... that is format that Excel uses

According to wiki ID3 defines both YEAR and DATE tags ... YEAR should be stored as 4 digit number ... but there is no mention on wiki how dates are stored

What you expect as four digit number is probably a YEAR tag ("year" and "Original release year") ... it is possible that programs that read YEAR tag then present it to you under "date" label, leading you to believe that DATE tag should be stored in 4 digit number.

EDIT: also possible that whatever program you use to write DATE tag as four digit number is doing it wrong ... as year is definitely not a date (in terms of software development) ... but 38718 is definitely a date format (one of many types of format that can specify date ... i believe Rederick mention another one ... as usual problem arises probably because ID3 does not specify DATE type ... or if it does it is not properly documented or not readily available on Internet ... so ppl just choose whatever they want)

[Jamil]

Thanks for posting, but ID3 is irrelevant in my case.  I do not use MP3 nor have any files using the ID3 specification.

For now, I will simply keep disabling DATE until this gets made usable.

Incidentally, there is a way to fix this using MC26.  What I did to remove these DATE value that are not human readable is temporarily allow MC26 to write to the DATE tag, edit all tags for files having unreadable values, then completely remove the Date value.  MC26 will complete delete the DATE tag.  After doing this, disable the writing of the Date tag again closing MC26.

I then added dates back in using a third-party tag editor that created a readable Year tag.  After this, launch MC26 and import all files.  MC26 will detect the dates from the readable Year tags added to restore all lost years.  Issue solved permanently.

[tij]

FLAC is using Vorbis ... as per wiki regarding Vorbis "Any tag name is allowed, and there is no format that the data values must be in. This is in contrast to the ID3 format used for MP3s, which is highly structured. "

So Vorbis defines how to store metadata in FLAC ... but does not define standard fields ... you can basically create any fields you want

I think to be consistent with MP3 ... ppl just apply ID3 tagging system inside Vorbis (field names and data types allowed) ... and that makes it relevant to a degree

EDIT: again as there is no official/standard way to tag common fields in Vorbis ... technically whatever is possible and it is still correct ... so bringing ID3 standardized fields inside Vorbis is like bringing order to chaos

[ferday]

where are you "writing out" this tag that you see the epoch number?  you mention that in the tag dump you see DATE=2020, which is exactly what you want to see...is the epoch number visible in some other program?

[Jamil]

where are you "writing out" this tag that you see the epoch number?  you mention that in the tag dump you see DATE=2020, which is exactly what you want to see...is the epoch number visible in some other program?

DATE=2020 is what I want to see.  If MC26 was writing this, I would not have started this thread in the first place   

MC, for reasons only the coders know, writes out DATE tag values like this:

DATE=36245
DATE=28465
DATE=45867

and etc.

I am using fb2k now as my primary media player.  With some media files that MC had previously written out the DATE tag, it will show year as follows:

https://dl.dropboxusercontent.com/s/hn0o2k1i3uylktp/fb2k.png

Also, I am not at all suggesting fb2k is at fault here.  Their implementation is 100% logical and makes sense-- this particular file has two tags with two different values.  Year=2007 and DATE=39xxx.  The commonly used Year tag takes priority and gets displayed first.

Here is a display of all tags in an easy to read format:

https://dl.dropboxusercontent.com/s/22ppn2y8cyy5tqt/combo_year_tag_details.png

[tij]

Here's is the long Vorbis spec:

https://xiph.org/vorbis/doc/Vorbis_I_spec.html

This is the brief version:

https://xiph.org/vorbis/doc/v-comment.html

Just as an FYI, I just purchased a downloadable FLAC file that already had tags set by the artist.  Here is how the DATE tag appears:



As far as I knew, this was the commonly used format.  Digits of a text string that represent the year.  It is always the DATE tag used to store the year.

I looked briefly in those specs ... as wiki mentioned it defines no standard fields/tags and the data type they should be in (it only propose some) ... as I mentioned earlier - ppl just use ID3 defined tags and data type (last one is hard to enforce in Vorbis ... thats why you see stuff like DATE=2020 ... which imho is incorrect)

[tij]

there was thread mentioning Dunning-Kruger effect ... so I thought ... darn, maybe I am too hasty in asserting these tags stuff ... so I dig a bit deeper ... and indeed - there is no limit to my ignorance lol

So ... what i found

MP3 use ID3 tags that also clearly define certain fields and what value they should contain (for example it clearly defines YEAR as numeric string with digit number)

FLAC use Vorbis that do not define any standardized fields ... they only provide suggestion for few of them (https://xiph.org/vorbis/doc/v-comment.html)

It seems ppl use ID3 defined fields inside Vorbis ... I guess cause Vorbis defines nothing and this provides consistency with MP3 tagging

ID3 have different versions and depending on what version is used - tags can hold different values

... Now to tags definitions in ID3

YEAR - is TYER clearly defined as numeric string with 4 digit (https://mutagen-specs.readthedocs.io/en/latest/id3/id3v2.3.0.html)

DATE
- in v2.3 is TDAT defined as numeric string with 4 digit in format DDMM (https://mutagen-specs.readthedocs.io/en/latest/id3/id3v2.3.0.html)
- in v2.4 is TDRC defined as the timestamp fields based on a subset of ISO 8601. When being as precise as possible the format of a time string is yyyy-MM-ddTHH:mm:ss (year, “-”, month, “-”, day, “T”, hour (out of 24), ”:”, minutes, ”:”, seconds), but the precision may be reduced by removing as many time indicators as wanted. Hence valid timestamps are yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and yyyy-MM-ddTHH:mm:ss. All time stamps are UTC. For durations, use the slash character as described in 8601, and for multiple non- contiguous dates, use multiple strings, if allowed by the frame definition. (https://mutagen-specs.readthedocs.io/en/latest/id3/id3v2.4.0-structure.html)

So yeah ... I have to agree with Jamil that if MC uses Microsoft Excel date format (days after 1/Jan/1900) then it might not be compatible with other players (internally MC can use whatever it wants ... but once written to file, tags should confront to some standards ... not sure if there is a way to tell MC how to write certain tags??). This probably don't get notice cause DATE field is rarely used

And to original question:

My question was can I turn off Date and get Year that is widely supported by everything to work instead?

You can turn off writing certain tags to files

[Options]->[Library&Folders]->[Manage Library Fields] ... after that just go to each Date tag and untick [Save in file tags]

[EnglishTiger]

In my library there are over 25,000 Tracks some where in MC the "Date" is in the DD/MM/YYYY format whilst others are in the YYYY only format.
No matter what program/application that can read/present FLAC Metadata I use, including a clean install of foobar2000, there isn't a single file/track which has anything other than a 4 character Year Number in the range 1972 to 2099 (I intentionally entered that one just to see what would happen) nor are their any files that contain multiple dates.

MC will only let me enter a YYYY format year in the range 1899 - 9999. If I try any date outside that range it defaults to blank.

What ends up in the Flac "Date/Year" tag is dependent on what the user entered - in the attached screenie the snapshot on the left shows the date in yyyy mm dd format that dbpoweramp added whilst the one on the right shows it in the YYYY format after I'd edited the "Date" in MC

P.S. MC will only change the FLAC Date/Year Tag to YYYY format if you modify it in MC or let MC do anything which writes to the Flac File, i.e. run Audio Analysis.

[EnglishTiger]

I've finally, hopefully, found just what it is that is putting the wrong value in a "date" tag/field and it was Jamil's second screenie which shows the tag details in an APEv2 Tag Editor that gave me the clue. Matt & JimH may not like it but when I used MC to convert a Flac File to Monkeys Audio (APE) Format guess which Non-Standard APE Key/Tag ended up in the File - Yes you guessed it one called "Date" with a value of 72986

[tij]

MC will only let me enter a YYYY format year in the range 1899 - 9999. If I try any date outside that range it defaults to blank.

that looks like excel date format limitation ... still as I mentioned before, it doesn’t matter how MC stores dates in their database ... but writing tags to file should be in format that other programs can use (whatever that is for FLAC lol)

[RoderickGI]

Just to clarify, MC doesn't use the Excel Epoch, they just both happen to use the same Epoch, as explained in Reply #7 above. I linked to the various Epoch definitions. It isn't January 1st 1900.

The Epoch Date used by MC is December 30th, 1899 at 00:00:00, which is the Microsoft COM DATE epoch. See https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoch_dates_in_computing. Other applications should be capable of using it.

Good find here EnglishTiger.

when I used MC to convert a Flac File to Monkeys Audio (APE) Format guess which Non-Standard APE Key/Tag ended up in the File - Yes you guessed it one called "Date" with a value of 72986

MC does indeed save the date to APE files in a tag such as "Date: 34335". But that is an APE tag, and not a Vorbis Comment Block tag. Different.

Another point of clarity. All tags written to files are characters, as they are just text. It is only an application which may assume a particular tag that contains the text "1994" is a numeric value. Each application can treat that differently. MC has fields in String, Integer, Decimal, Percentage, List and Date, but they are all just text in the database.

For FLAC files:
1. MC doesn't by default write the [Year] field to file tags, and in fact, you cannot make MC write those tags. It shouldn't, because it is calculated based on the [Date] field, and to save it in a tag would be redundant. Any "Year" tag in a file comes from somewhere else, or is just the DATE tag presented as only the year.
2. Windows Explorer takes the Date tag and displays it as the "Year" and "Date Released" in four digits. Most Date fields in Windows Explorer are about the file date, not the content date. Even if the "DATE (RELEASED)" tag is written to a FLAC file, Windows Explorer doesn't use it.
3. Discussion of ID3 is largely irrelevant. MC writes TYER to MP3 files, and not Date Released.
4. MC does not write FLAC tags in the format "DATE=36245". It just doesn't do it. It does write the "DATE (RELEASED)" tag using the numeric value. If there are "DATE=36245" tags in a FLAC file, MC didn't write them.
5. Jamil, I can't tell from your first image in Reply #15 what file type you are displaying in FooBar2000. Is it FLAC? We are talking about FLAC files here aren't we? If FooBar2000 shows both the YEAR and DATE tags in one column like that, fine. There is no standard for this stuff. The fact that they show 2007 and 39xxx means that Foobar2000 also uses and Epoch date, and they are probably actually displaying the DATE tag in year format, as is saved to tags, and the "DATE (RELEASED)" tag in Epoch format, the same as MC. Your second image is of an APE file's tags, or is using APEv2, which is just not relevant.

If you want to sort out which applications are saving which tags in which format, get a Hex Editor and looks inside the files directly, after saving tags in the various applications. I recommend Tiny Hexer version 1.8.1.6. Just be careful where you download it from, as some sites can't be trusted.

Be warned though, that some applications won't overwrite tags if they exist. So test carefully.

MC26 is writing a tag called Date that contains this number:  38718.

No, it isn't.


Bottom line, MC isn't putting numeric strings into the DATE tag in FLAC files. It does put them into the "DATE (RELEASED)" tag, and some applications use that tag and display it as the Date.

Didn't I say all that in my first reply to this thread? Reply #7? Yes, I did.

[EnglishTiger]

This morning I thought I'd try a few experiments to see if the weird "additional APE key/tag problem" was resticted to just using MC to convert Flac files to APE by:-
1 - Use dbPoweramp to rip my R.E.M. cd to APE
2 - Use MC to rip Dire Straits "Brothers in Arms" to APE
3 - Use MC to rip Dire Straits "Communique" to  APE
4 - Use MC to rip Dire Straits "Communique" to Flac

And then look at all those tracks in MC
According to the MC Tag Dump dbPoweramp had put a tag called "Year" containing "2003 10 28" but, as the attached screenie shows, that value was not transferred to either the Date or Year columns/fields
Because the YADB info for Brothers in Arms included the year MC used that to populate both the Date and Year columns/fields and the Tag Dump had 2 date related tags to APE files/tracks one called "Year" that had "1985" in it and one called "Date" which had "31048" in it
Since the YADB info for Communique did not include the Year in the Tag Dump neither the APE files or the Flac files contained any date related tags.
I then entered "1996" in the Year column for both variants of track 1 from the Communique CD and since Year & Date are intrinsically linked in MC that value also appeared in the Date column.
When I looked in the Tag Dump for each of those 2 tracks the APE one had 2 date related tags "Year" with "1996" in it and "Date" with "35065" in it. But the Flac one only had one date related tag "DATE" with "1996" in it.
I then got MC to do an Audio Analysis on the 1st 2 tracks from the R.E.M. album and when I did a Tag Dump on them neither track had a date related tag present even though there had been one present before MC analysed them.

My findings ask a few, potentially, awkward questions:-
Why isn't MC detecting the "Year" tag/key for APE files/tracks that were not ripped by MC given that it does detect the "DATE" tag in Flac files/tracks it did not rip?
Why is MC writing 2 date related keys/tags "Year" (the right one) and "Date" (the wrong one in a format that only MC understands) to APE files/tracks?
Why is MC removing the existing, but not recognized, "Year" key from APE files/tracks as a consequence of running an "Audio Analysis"?
What other audio format files is it adding additional and probably unnecessary tags, in a format that only MC recognizes, too?

[tij]

What other audio format files is it adding additional and probably unnecessary tags, in a format that only MC recognizes, too?

I actually dont mind MC adding tags that only MC recognizes - but it would be better if those tags are marked such that it can be easily seen that MC add them (maybe append "MC_" or prepend "_MC" to tags ... so one does not wonder where those tags came from)

It is helpful to rebuild libraries from tags inside files (in case original library is unrecoverable)

However, for standard tags (Year, Date, Artist, etc) ... I prefer MC write in format that other players can recognize.

At the moment ... all my media files sit on read only mapped drives ... to prevent my media players (MC, Plex, etc) from writing something to media ... and to prevent my family from accidently deleting the media

[Jamil]

No, it isn't.
say all that in my first reply to this thread? Reply #7? Yes, I did.

I will comment on this incorrect statement above that is just plain wrong.  MC, for a fact, wrote a tag called DATE having the value 38718.  I honestly do not care what the MC UI calls it [Date (Released), as you noted].  The fact remains that this software created a new tag in the output file on its own called "DATE".  It wrote the value for this tag as 38728. 

I am happy to see that you are sastisfied with this behavior, but it is broken for me.  Hence the reason I turned it off never to be used again.

[RoderickGI]

No, MC did not write a tag called DATE with a value of 38718, to a FLAC file. Nor did it write a tag called [Date (Released)]. Nor did I say it wrote such a tag.

MC wrote a tag called "DATE (RELEASED)" with a numeric value in it.

You might think that the difference is subtle, or irrelevant, but when it comes to tagging audio files, it is the detail that matters. Even the case (upper, lower or title case) of the tag name makes a difference, and different applications handle tags differently, or ignore them, because of such a minor difference.

MC also write a tag called DATE, which contains a four digit value for the year. You could confirm that very quickly by allowing the [Date] field to be written to files, and then running the "Update tags from library" function for one file, and then look in the file using a hex editor to confirm it has a tag of "DATE=yyyy".

Tagging is a can of worms generally, but I don't think I can make that any clearer.

[tij]

Looking at Jamil posted picture there is tag called “Date” with excel date like value ... but it looks like APE file ... not FLAC

So Jamil ... is the problem with APE or FLAC?

If it’s APE only ... then problem might be same as EnglishTiger describe for APE ... thumbs up for taking time to test it

For FLAC that uses Vorbis ... I think tags are case insensitive ... not sure for APE

BUT ... since APE is done by Matt ... maybe he can chime in and say what is right for APE

[Jamil]

I tried it for one FLAC file and this time got the results for this single file as shown below:



I changed the year from 2020 to 1900, and I do see a four digit year in the DATE tag that MC created and wrote to.  I previously deleted all tags.  This instance worked as I expect and require.  This one test scenario did work.  I did not test every single scenario, and I can guarantee that I was seeing weird DATE tag values written by MediaCenter and MediaCenter alone to FLAC files.  I am not in a position to do all testing for this software.

The problem here is MC26 is inconsistent with this handling.  Date, that I temporarily enabled, is a single shared tag output field.  If this above behavior was consistent for all, there would be no issues and no need for my to have even started this thread.  There is not consistent behavior, so I must again disable this Date tag field and stop using it.

[RoderickGI]

My findings ask a few, potentially, awkward questions:-

1. The DBPoweramp YEAR tag containing "2003 10 28" doesn't conform to any definition of a year. It is a date. So I would assume that MC ignores it because it doesn't comply. DBPoweramp tagging is probably configurable, so the DATE tag is populated and contains the YEAR value. I haven't checked. YEAR and DATE tag usage between applications varies, and is sometimes in conflict. i.e. They get switched around, or DATE is always just a year (the MC assumption for FLAC files). I have to admit though that putting a full "YYYY MM DD" vlaue into a YEAT tag is a bit strange.

2. It seems that the tag format used in APE files includes a YEAR tag which is a four digit year, and a DATE tag which is an Epoch date. Lots of applications use Epoch dates. I haven't searched for an APE standard for tags to confirm that.

3. When MC does Audio Analysis it writes tags to the file. I believe that when MC does write tags, it write all tags, so that they fit correctly in the header area and are assessable to all applications. I think tags have to be written as one chunk. As MC didn't use the existing YEAR tag, it wouldn't have it to write back to the file.

4. MC does a pretty good job of writing tags in formats and named to be consistent with other applications. But it isn't perfect, because tagging is a can of worms, and a huge number of conflicts exist between different file format tagging and applications that use tags. So there are compromises, such as the DATE tag only storing a four digit year value. Generally speaking, only the basic tags are used consistently; Name, Artist, Album, Track, and usually Album Artist (in at least two formats), Genre and Date.



PS: I'm not sure about the behaviour of other applications that use Vorbis Comment Block tags, but my understanding is that MC reads all tags as case sensitive. In order for MC to read a non-standard tag, the field name in MC must exactly match the tag name in the file, including case.

======================

Thanks for doing that simple test Jamil. I have no doubt that you saw strange DATE tags, but you are using multiple applications, and each application handles tags the way the developer though they should be handled, so misinterpretations and inconsistencies can happen. MC saves the "DATE (RELEASED)" using a numeric Epoch date value, but some other application could have decided to use the DATE tag for YEAR, and use the "DATE (RELEASED)" tag for DATE, which would cause what you saw.

The question is not whether you saw unwanted values, but where those values came from, because they weren't written by MC.

Even now, you are using another application to check the tags that MC wrote. I thought it was Foobar2000, but the copy of Foobar2000 I have looks different. It's not MP3TAG either, is it? Regardless, whatever other application you use to check tags could be interpreting the tags found in the files, and putting them into its own fields, just as MC does. That is why I recommended using a Hex editor to check the actual tag values inside the files.



BTW, even though it might sound like I do, I don't work for JRiver, or get compensated by them or anything. I have participated in this thread to share knowledge. My hope is that the information is of some value.

[Jamil]

BTW, even though it might sound like I do, I don't work for JRiver, or get compensated by them or anything. I have participated in this thread to share knowledge. My hope is that the information is of some value.

I know you do not work for JRiver.  It is unfortunate that you do not.  You love this software.  That much is obvious.

I use a small set of software.  I do not use dbpoweramp and do not even have it installed.  I use Sound Forge v14 now for all audio conversions.  It has superior dithering features that I use when needed.  It also costs a lot more, so it better be better for the price of it.

I do use foobar2000 now for reasons discussed previously on these forums.

The software to display tags is what I have primarily been using it for.  It shows me every single tag in a list for all of my audio files.  It also easily allows me to easily delete tags of my choice.  I just found and installed it recently.  It's something called Professional Tag Editor.

My primary tag editing tool I use is Tag&Rename.  Tag&Rename does not have the ability to display all tags.  It only displays tags within its list.  Other than that missing feature, Tag&Rename is feature complete and has the best tag export out of anything available. 

Professional Tag Editor fills the gap in displaying all tags even unknown ones.  It also allows me to delete any and all tags easily.  I do not use it often, but it comes in handy when I do need this feature.

[EnglishTiger]

Rod - APE does indeed have 2 "Date" tags/keys - 1 named "Year" and 1 named "Record Date" but for both the "recommended format of value" is Date - http://wiki.hydrogenaud.io/index.php?title=APE_key

And I agree with you, regardless of "file format", seeing a YYYY MM DD date in a "tag" seems a bit "non standard" but, MC and a load of other programs/software, including that cranky lump of software Microsoft call an Operating System, handle it. The only thing that didn't appear to like it in an APE File was MC. Incidentally dbPoweramp has a setting which allows the user to choose between writing the "long YYYY MM DD" variant of the date and the "shorter/more usual YYYY" variant to the "relevant tag".

However; what we all have a habit of forgetting is that unlike "The Ten Commandments" MetaData standards are not "set in stone" they have all evolved over time. Indeed if you just take a look thru the history of ID3 tags you could be forgiven for thinking a lot of them were added to stop the OCD Brigade complaining about the fact that they couldn't enter everything you can find on an Album Cover/Booklet. Of course the biggest joke of the lot is that some of these sites that provide (frequently wrong) MetaData impose standards/restrictions that the Music Industry have no inclination to conform to. That bunch can't even agree about what "info/metadata", if any, should be added to the CD-Text file.

Coming soon to your local "Music Download Site" a 3 minute track where 90% of it's 500Gb size is "The life story of the artists involved"

[RoderickGI]

EnglishTiger, I note in the APEv2 spec that the YEAR tag is actually meant to mean the "Release date", but is named YEAR for "upward compatibility". That is the sort of compromise that makes tagging so frustrating when using multiple applications that make different compromises. That compromise also explains why the YEAR tag had a full Date value in it, as the spec says it should be a Date format.

That sort of thing is why I pretty much stick to using MC for tagging, although I have used MusicBrainz Picard to gather metadata for a bunch of files, because YADB is somewhat limited for use with individual files.

I totally agree with you on the vagaries of tagging music files, and the audio industry generally. And Microsoft/Windows.

Jamil, I think we have a conclusion. If you only, or mainly, use FLAC files I think you could let MC save DATE tags. But as you have other applications to do that, I guess it doesn't matter. As long as MC can read the tags and you don't edit the DATE tag in MC, your metadata should be safe.

Enjoy the music all.

[Matt]

I'll add this change to a coming build:
Changed: When loading dates from an APE file, if no "Date" field is found, the "Year" field will be read (which could contain a full date).

[Matt]

Build 103 with this change is live now.

https://yabb.jriver.com/interact/index.php/topic,126364.msg875620.html#msg875620