Print

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

[mwillems]

I think some people have hit that problem, but certainly not "most people".  In the grand scheme of things, it is still only a small fraction of the total users of MC.  And, even assuming there is a good sized pile of people who hit the issue, I seriously doubt that your solution is the one most of those people will use to solve the issue.

The issue is that of all the people who use MC:

1. Most probably haven't hit that problem.
2. Of those who did, most won't care and will ignore it, or pick the one version they want to keep.
3. Of those who do care, most will only have a few, and will solve it by adding a re-issue date or identifier to the [Album] tag (this is me).
4. Only the real nerds will go to the trouble to do anything like this.

So, you're at a fraction of a fraction of a fraction of users. And you're going to risk breaking the workflow of all of the rest of the people (in categories 1, 2, and 3) to try to solve that problem.

Not worth it.  

Exactly.  I'm in category 3) (like glynor, I just modify the Album title), but if there were a separate stock field for original release, I'd probably use it.  But not if that would require breaking everything as it exists now.  

Well as I said, after reading over the specification, I'm thinking that Lefisu63 is right.

The spec may say what it says, but that doesn't make it a good idea.  I'm normally in favor of compliance with standards, but looking at the default tagging behavior of other software (like WMP and dBPoweramp), they don't appear to be spec compliant either.  Neither are downloads from the various online stores I've used.  There may be scraping software out there that does use the spec, but I haven't found any (and it would be useful to know what scraping software and metadata databases do support this kind of trifurcated date scheme).  Tag-editing software exists that can reach these fields of course, but that's meaningless if there's no automated way to populate them (or at least no commonly used way to automate them).

Sometimes specs are dopey and if no one uses a standard, it's not a standard in any meaningful sense.  I don't express dates as 2015-06-30, even though that's the international standard (and I bet no one else here does, I have never seen that "standard" in the wild outside of software).  And the consequences of not following this standard are low because no one else appears to follow the standard (this isn't like POSIX or UPNP compliance where something will break if you don't follow the standard).

I'm with glynor on this, IMO none of this is worth breaking everyone's workflow.

[Matt]

I don't know if anyone noticed, but there's a new build available that makes the changes I proposed.

I'm a little scared that I've entered a worm hole, so hopefully everyone will be happy with the changes!

[flac.rules]

The spec may say what it says, but that doesn't make it a good idea.  I'm normally in favor of compliance with standards, but looking at the default tagging behavior of other software (like WMP and dBPoweramp), they don't appear to be spec compliant either.  Neither are downloads from the various online stores I've used.  

What id3v2.4 tags do the programs and stores you have tested use for date?

I do by the way use dates formatted that way, causes all files and folders to be sorted properly

[flac.rules]

I don't know if anyone noticed, but there's a new build available that makes the changes I proposed.

I'm a little scared that I've entered a worm hole, so hopefully everyone will be happy with the changes!

Just to be clear (i can be a bit slow at times ), the date field is now as a default written to TRDC if you write a tag to mp3?

[6233638]

I don't know if anyone noticed, but there's a new build available that makes the changes I proposed.
I'm a little scared that I've entered a worm hole, so hopefully everyone will be happy with the changes!

As discussed, please use:

Media Center	v2.4	v2.3
[Date]	TDRC	TYER+TDAT+TIME
[Date (original release)]	TDOR	TORY
[Date (this release)]	TDRL

The v2.4 tags should have priority over the v2.3 tags if both are present, or they differ in any way.


[Date (release)] is confusing because it could be applicable to either TDOR/TORY or TDRL
 
And [Date] should only pull in information from TDRC or TYER+TDAT+TIME
It should not pull in information from TDOR/TORY or TDRL if it is empty.
 
 
That covers the basics.
I do think it would be good if this could be expanded upon as outlined earlier in the topic, but I understand if that's as much as you would want to do.
If you're just pulling in the tags and mapping them to those fields, that's enough for me. But It means that most people are unlikely to start using them.

looking at the default tagging behavior of other software (like WMP and dBPoweramp), they don't appear to be spec compliant either

Are you saying that they're writing their date information to something other than TDRC or TYER+TDAT+TIME ?

I'm with glynor on this, IMO none of this is worth breaking everyone's workflow.

Other than potentially changing [Date] to be a calculated field, which we have ruled out, none of the other changes I've suggested should break anyone's workflow.
 
It just makes it easier to make multiple versions of an album unique by simply filling out the new [Date (this release)] field, instead of having to modify the album name to make it unique or putting the wrong value in [Date]
 
And that's the right way of doing it - adding more information instead of modifying data which was already correct.

[ferday]

I don't know if anyone noticed, but there's a new build available that makes the changes I proposed.

I'm a little scared that I've entered a worm hole, so hopefully everyone will be happy with the changes!

And as promised, I'm going to insist On clarification

The release note says TDRL = date (release)
What does [date] now map to?

Thanks!  This could be a good addition but I don't want to play around before it's clear what is what

[Matt]

And as promised, I'm going to insist On clarification

The release note says TDRL = date (release)
What does [date] now map to?

[Date] is TDRC or TXXX (JR/Date).

[mwillems]

What id3v2.4 tags do the programs and stores you have tested use for date?

Are you saying that they're writing their date information to something other than TDRC or TYER+TDAT+TIME ?

To be clear, I'm saying that almost all scrapers and metadata services I've used are writing the release date in TDRC (or to superseded fields that map to TDRC), which is not what the standard specifies (the TDRC frame is officially to be used for the recording time, TDRL is for the release time).  

62 are you suggesting partial implementation of the standard (basically not changing the way the Date field works currently and adding a few fields)?  If so, I think I'm fine with that.  Adding extra fields that don't affect existing fields is free and hurts no one. I was just alarmed at the prospect of altering the behavior of the date field, or creating complete adherence to the standard in MC (for example, by writing scraped release dates to TDRL), which would be inconsistent with almost universal practice (by software, and, I suspect, by users).

[flac.rules]

[Date] is TDRC or TXXX (JR/Date).

Based on what? if the existing tag is id3v2.4 or id3v2.3 or older?

[6233638]

To be clear, I'm saying that almost all scrapers and metadata services I've used are writing the release date in TDRC (or to superseded fields that map to TDRC), which is not what the standard specifies (the TDRC frame is officially to be used for the recording time, TDRL is for the release time).  

62 are you suggesting partial implementation of the standard (basically not changing the way the Date field works currently and adding a few fields)?  If so, I think I'm fine with that.  Adding extra fields that don't affect existing fields is free and hurts no one.

Since everyone writes the release date to "Date" (TDRC or TYER+TDAT+TIME) that can't change.
 
So yes, I'm just asking for new fields to be added, and for Media Center to not pull data in from those new fields into [Date] if it is empty.
I can't imagine a scenario where that would occur and it was not done intentionally.
 
As I said, I think whoever is behind setting the ID3 standards really made a mistake by assigning date to "Recording Date" instead of "Release Date" or "Original Release Date" but that won't affect how people use the field, since most programs are going to continue calling that the "Date" field.
 
What I would like to see are further changes which means that Media Center actually makes use of the new date fields (prioritized over [Date]) but let's get the tags supported, and with properly descriptive names first.
 

[Date] is TDRC or TXXX (JR/Date).

What is JR/Date?

[glynor]

Adding extra fields that don't affect existing fields is free and hurts no one. I was just alarmed at the prospect of altering the behavior of the date field, or creating complete adherence to the standard in MC (for example, by writing scraped release dates to TDRL), which would be inconsistent with almost universal practice (by software, and, I suspect, by users).

+1

[glynor]

What is JR/Date?

The real internal high-precision date field, used for all media types in MC.

MC's dates look nothing like the tagging systems that have been discussed here. They're, internally, floating point fields where the integer part is the Date, and the decimal part is the time.

[Lefisu63]

To be clear, I'm saying that almost all scrapers and metadata services I've used are writing the release date in TDRC, which is not what the standard specifies ("The TDRC frame is officially to be used for the recording time, TDRL is for the release time").  

Correct.

TDRC (v2.4) = TYER (v2.3) = recording time and is "track" based.
TDRL (v2.4) = - (v2.3) = release time and is "product" based.

Example:

You have e.g. a compilation with 70's & 80s bought in 1998,
which includes "Lipps, Inc. - Funkytown" from 1980, "Patrick Hernandez - Born to be alive" (1978)

Until v2.3:

Option 1: In TYER you have stored 1980 for "Funkytown" and 1978 for "Born to be alive".
Option 2: In TYER you have stored 1998.

You could have used TORY for 1998 or 1980/1978, if a software would have supported TORY and people would have stored this information (they most didn't).

Of course it all wasn't clear for everybody.

With v2.4 you are able to store both v2.3 options and id3.org has decided to add the new tag TDRL for v2.3/option 2.

That's why TDRC is TYER(+TDAT+TIME), and TDRL is new.

If people have used option 2 in v2.3, they should clean up their collection for v2.4 and move 1998 from TYER/TDRC to TDRL.

So with v2.4 you have
TDRC with 1980 for "Funkytown" and 1978 for "Born to be alive".
TDRL with 1998 for the product release date (the compilation release date).

Personally I think
"Product release time" is a good name for the column TDRL - and very clear.
"Track release time" is a good name for the column TDRC.
"Original Product release time" good be a good name for TDOR.

Regarding TDOR:

If you have bought MJ - Thriller album re-release from 1996.
TDRC = all tracks have 1982 (if a track would have been released/recorded as a single earlier then there would be another year for this track!).
TDRL = 1996 (= product release time)
TDOR = 1982 (= original product release time)

[mwillems]

Personally I think
"Product release time" is a good name for the column TDRL - and very clear.
"Track release time" is a good name for the column TDRC.
"Original Product release time" good be a good name for TDOR.

I think you're overreading the standard a bit.  TDRC is supposed to "contain[...] a timestamp describing when the audio was recorded."  Not when the track was released.  I don't see any evidence in the standard distinguishing between tracks and albums in any of these fields.  Thriller is a bad example because it was recorded and released in 1982.  

Fleetwood Mac's Rumours, was recorded in 1976 and released in 1977.   A strict reading of the standard says that TDRC should have 1976 in it, but I've never seen scraped metadata that said anything other than 1977, and that date gets written by default to TDRC by all software I've interacted with.  So the metadata situation in my experience is:   1) Most of the time a metadata service only provides one date and that date is the release date and 2) Most software dumps that date into TDRC or tags that map to TDRC (for historical reasons, or because Id3v.2.4 adoption is hardly universal).  

Recording time is a quagmire precisely because you don't often know when exactly certain tracks on a given album were recorded, or an album may have been recorded over a period of years.  How it wound up as the default mapping for TYER is anybody's guess.

You can use the tags the way you describe if you want, but that's not the standard nor is it common practice.  As noted above, my vote is to leave the current behavior of the [Date] tag entirely alone.  I'm agnostic on additional tags, but agree they might be useful.  

[ferday]

To be clear, I'm saying that almost all scrapers and metadata services I've used are writing the release date in TDRC

The way it is works for me, with release date, I'll just consider TDRC as original release date and the new date as re-release date.  It eliminates a custom tag and scarpers that fill date will still work for most cases....I think.  Time shall tell

[Lefisu63]

I think you're overreading the standard a bit.  TDRC is supposed to "contain[...] a timestamp describing when the audio was recorded."  Not when the track was released.  I don't see any evidence in the standard distinguishing between tracks and albums in any of these fields.  Thriller is a bad example because it was recorded and released in 1982.  

Fleetwood Mac's Rumours, was recorded in 1976 and released in 1977.   A strict reading of the standard says that TDRC should have 1976 in it, but I've never seen scraped metadata that said anything other than 1977, and that date gets written by default to TDRC by all software I've interacted with.  So the metadata situation in my experience is:   1) Most of the time a metadata service only provides one date and that date is the release date and 2) Most software dumps that date into TDRC or tags that map to TDRC (for historical reasons, or because Id3v.2.4 adoption is hardly universal).  

You can use the tags the way you describe if you want, but that's not the standard nor is it common practice.  As noted above, my vote is to leave the current behavior of the [Date] tag entirely alone.  I'm agnostic on additional tags, but agree they might be useful.  

I know the standard.

I've only set "recording = release" to the same value because of the v2.3 where only TYER was there and used. Nobody has made a difference between recording and release back in the days (I think). And I'm sure the most won't do it today - because from where will you get all the informationwhen a track has been recorded or released? I have over 40.000 tracks on my hard disc and I have no time to sort out the difference between recording + released.

I know from tracks that all parts have been recorded in 1976, the pre-mix itself in 1976 or 1977 and or the final mix a few month later in another studio in 1977. Or mastering happend in 1977, etc. What should be stored? Normally I store the first release - except it is an unreleased mix released years later as a bonus anywhere.

Personally I think the id3.org people wanted to say my above names but did a bad description? (I think they were and are no experts in data ... otherwise we would have a clear XML solution today).

However - as long the dates are not mixed technically anymore (TDRL/TDRC) during the initial import - and you know which functional date you have stored in which column/tag - it makes no difference for me what the heading is - because it's different in every software.

In some software (e.g. foobar2000) you can define your own heading for each tag/column/function - maybe in MC too? (I've just downloaded the latest release of MC and will start my "deep" beta test tomorrow. My last beta was over a year ago with MC 19 and I can't remember anymore or didn't fully test it because of the initial troubles).

So personally I find "my" solution very useful:

"Product release time" is a good name for the column TDRL - and very clear.
"Track release time" is a good name for the column TDRC.
"Original Product release time" could be a good name for TDOR (although I currently don't use).

Other people might keep the "TDRL value" in TDRC as the only one date ... it depends on what the user want's to store.

[6233638]

It doesn't look like the newly added "Date (release)" field is reading from or writing to TDRL tags.
It seems to be writing to a generic TXXX tag?
 
I still haven't found a good piece of software to display raw/unformatted tags though, so that might not be correct.
 
Please read from/write tags in this format:

Media Center	v2.4	v2.3
[Date]	TDRC	TYER+TDAT+TIME
[Date (original release)]	TDOR	TORY
[Date (this release)]	TDRL

 
[Date (release)] is not a helpful field name.
This is a common problem with much of the naming of things in Media Center. (IPC, WDM etc)

[Lefisu63]

I still haven't found a good piece of software to display raw/unformatted tags though, so that might not be correct.

Mediainfo 0.7.73 is free and displays the 2 fields:

http://sourceforge.net/projects/mediainfo/

(after installation change view to "Text")

General
Complete name                            : M:\Archive\discogs\1984\ABBA_Greatest Hits Vol. 2_[1205130]\ABBA_Angeleyes_(Original Album Mix)_[1205130].wav
Format                                   : Wave
File size                                : 43.6 MiB
Duration                                 : 4mn 19s
Overall bit rate mode                    : Constant
Overall bit rate                         : 1 411 Kbps
Album                                    : Greatest Hits # 2
Album/Performer                          : ABBA
Track name                               : Angeleyes
Grouping                                 : DFS70, DFTPK, MSFCL, MSLEAC
Performer                                : ABBA
Composer                                 : DR13; RMS-16.08; Peak-1.01
Remixed by                               : Original Album Mix
Publisher                                : 1205130
Genre                                    : Disco
Released date                            : 1984
Recorded date                            : 1979
BPM                                      : 133
Initial key                              : 1B

Audio
Format                                   : PCM
Format settings, Endianness              : Little
Format settings, Sign                    : Signed
Codec ID                                 : 1
Duration                                 : 4mn 19s
Bit rate mode                            : Constant
Bit rate                                 : 1 411.2 Kbps
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 KHz
Bit depth                                : 16 bits
Stream size                              : 43.6 MiB (100%)

If you really want a hex view of the file - use

HxD version 1.7.7.0 http://mh-nexus.de/en/

Open e.g. the .wav file, press STRG+F and search for "id3" (=.WAV identicator) (as Text-String):

or "ID3" in .mp3 files ...

See enclosed screen shot (HX_2015-07 ...)

PS: My screen shot is from my original file - not from a tested MC updated file!

[6233638]

Media Info doesn't display whether the fields are custom (stored in TXXX) or using the properly defined frames.
I did try using HxD actually, but that just listed the frames in plaintext. Looks like it works with WAV, but not FLAC files.
 
Looking at a WAV file seems to confirm that [Date (release)] is being stored in a TXXX frame and not TDRL or TDOR. (I'm not sure which one it's supposed to be)

[Lefisu63]

Media Info doesn't display whether the fields are custom (stored in TXXX) or using the properly defined frames.
I did try using HxD actually, but that just listed the frames in plaintext. Looks like it works with WAV, but not FLAC files.
 
Looking at a WAV file seems to confirm that [Date (release)] is being stored in a TXXX frame and not TDRL or TDOR. (I'm not sure which one it's supposed to be)

OK - TXXX would be wrong.

I don't have (I think) or use .flac files nor do I know the internal format ... because of compatibility with other software & hardware.

[Lefisu63]

Media Info doesn't display whether the fields are custom (stored in TXXX) or using the properly defined frames.
I did try using HxD actually, but that just listed the frames in plaintext. Looks like it works with WAV, but not FLAC files.
 
Looking at a WAV file seems to confirm that [Date (release)] is being stored in a TXXX frame and not TDRL or TDOR. (I'm not sure which one it's supposed to be)

PS: Maybe foobar2000 helps.

As far as I can remember you are able to read/write TXXX tags into columns - also from flac files information could be read. Also try qoobar 1.6.6 .. also possible hopefully --- but both are tricky until you know how to do it. I've forgotten it. ;-) ... I always make my deep checks with HxD - shows the truth ;-)

[Arindelle]

Quote from: mwillems on June 30, 2015, 04:41:05 pm
Adding extra fields that don't affect existing fields is free and hurts no one. I was just alarmed at the prospect of altering the behavior of the date field, or creating complete adherence to the standard in MC (for example, by writing scraped release dates to TDRL), which would be inconsistent with almost universal practice (by software, and, I suspect, by users).

+1

yes, agreed +1
hmm so many posts to catch up on, and no time to test this yet and all these aconyms

For what its worth I use the "date" field as the original release date, like a book publication -- usually using AMG as the umpire. I only use the original recording date in this field for Classical music and, rarely, jazz. Someone said something about when ad executives want to make money etc. Not sure I buy that logic, but whatever.

I always manually retag this when necessary and often on an individual song basis on compilations I'm fond of.  I either modify the titles for remasters or use custom fields when/if its important. Like books, I want to know the original publication date, not the re-print date.

Question, please, as I have the JR date field (txxx?) set to write to the file. I'd think that this new mapping won't really affect me as I manually verify the default date is actually what I want to see.

Could someone confirm that if I were to write back to the library my metadata I won't blow out my work? I might have made backups of my backups already before reading this and I have considerably more than 40k tracks ... so this is pretty important to me. Thanks in advance

[6233638]

Bump.

It doesn't look like the newly added "Date (release)" field is reading from or writing to TDRL tags.
It seems to be writing to a generic TXXX tag?
 
I still haven't found a good piece of software to display raw/unformatted tags though, so that might not be correct.
 
Please read from/write tags in this format:

Media Center	v2.4	v2.3
[Date]	TDRC	TYER+TDAT+TIME
[Date (original release)]	TDOR	TORY
[Date (this release)]	TDRL

 
[Date (release)] is not a helpful field name.
This is a common problem with much of the naming of things in Media Center. (IPC, WDM etc)