Print

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

[Lefisu63]

Hi,

I'll give MC a re-try and the hope to get a successfull solution sooner or later - although the trial period is over. But I can re-test on my laptop later.

Currently I'm using Tag & Rename for tagging and

- in TDRC I store the original release year of track (= more or less the recording time).
- in TDRL I store the year of the release when the CD came out on the market.

For example:

The track "A Taste Of Honey - Boogie Oogie Oogie (Original Mix)" itself has been recorded in 1978 (= TDRC), the compilation from where I have ripped the track http://www.discogs.com/release/987752 has been released in 2007 (= TDRL).

In MC 19 there is only one generic "date" field. If TDRL is filled, it will be used. If not, TDRC will be used. So MC merges these 2 different meanings into 1 column.

From ID3v2.4 specification:

TDRC = recording time
TDRL = release time

When I update the files, the content of the "date" field will now be written into TDRC - independent what was the original source. TDRL will not be written back. Finally TDRL overwrites TDRC and the original value of TDRC is lost.

This situation makes MC not compatible to ID3v2.3/4 standard and finally not to other software!

When I now go djing and play with Serato Scratch Live and want to play 70's, the smart crate rule is based on TRDC/year < 1980 wouldn't contain this example track anymore!

Additional info:

TDRC in v2.4 are in v2.3 the 3 columns TYER + TDAT + TIME. However, I only use a year and not the full date or timestamp.

Also other timestamp columns TDOR and TDTG exist in ID3v2.4. Personally I don't use them yet but maybe others want to use them in the future.

Tag & Rename only writes v2.3 yet, but it supports writing of TDRL in v2.3!

I also use Keyfinder 1.25 to get the musical key (TKEY). Keyfinder writes back v2.4, TDRC will be correctly taken from TYER and the library behind also reads TDRL from v2.3 and writes it back into v2.4. The same does Serato Scratch Live when I udpate the tags. All works fine together.

The "expression =tag()" does not work. As user "MrC" wrote in the original first thread "The Tag() function won't allow reading in these Txxx tags that already have a mapping, and the mapping is shown in the Tag Action Window".

I've enclosed a .zip file with example files:

Testfile_TDRC.wav (v24)
Testfile_TDRC+TRDL.wav (v24)
Testfile_TDRL_v23.wav (v23)
Testfile_TDRL_v24.wav (v24)
Testfile_TYER.wav (v23)
Testfile_TYER+TDRL.wav (v23)

TYER and TDRC have the value 1978. TDRL has the value 2007.

So you can test the import into MC.

Finally,

MC looks really great, database driven, etc. and I really want to buy it - but I can not correctly read my files and also not update them.

Will this be fixed?


Thanks a lot!

PS: Original thread http://yabb.jriver.com/interact/index.php?topic=89368.msg614172#msg614172 a few weeks ago.

[Lefisu63]

Hi,

is there anyone from JR who can tell me if it is possible to read TDRC and TDRL separately from ID3v2 (MP3 and WAV in my case) and when I write ID3v2 back to the file I still have the same values in TDRC and TDRL?

The values are required in another software too.

For further details, requirements and example files please read the initial thread.

Thanks a lot - hopefully a future user & customer of JR.

[Matt]

is there anyone from JR who can tell me if it is possible to read TDRC and TDRL separately from ID3v2 (MP3 and WAV in my case) and when I write ID3v2 back to the file I still have the same values in TDRC and TDRL?

TDRC and TDRL both map to the date.

[Lefisu63]

TDRC and TDRL both map to the date.

Thanks a lot Matt, I know but this is the problem.

I want to see both date values - TDRC + TDRL - they are different dates = different meanings!

To "merge" them is the problem. TDRL will be prefered over TDRC into "date". When I write the tags back - TDRC is only written. One date is lost.

How to avoid this sad situations (reading & writing)?

I need both ID3v2 frames in another DJ software - but this is not possible. Data loss when using MC ...

I think the mapping should be cleaner and more standard conform.

I really want to buy MC but when it is not compatible ...

Thanks a lot!

[Lefisu63]

TDRC and TDRL both map to the date.

Matt,

TDRC and TDRL contains different meanings. To map them to one date is not a good idea.

1. Is it possible to read both tags separately in any way with MC (currently 19.0.156) or not? If yes - how?, if not - will it be implemented soon?

2. Is it possible to write both tags separately in any way with MC (currently 19.0.156) or not? If yes - how?, if not - will it be implemented soon?

I've posted some example files above so you can test around.

Thanks a lot,
Robert

[Lefisu63]

Separate columns for TDRC and TDRL!

The values have different meanings, so do not merge them during import from ID3 into "date"!

When reading (importing), TDRL will be prefered over TDRC into "date".
When writing the merged value will be written into TDRC.

Finally one date is lost.

I didn't get any reply how to work with MC19 and read/write these dates. I think it is not possible.

The mapping should be cleaner and more standard conform because the values are required in other software too!

I can not use MC because all my music files have filled these values (or empty if unknown of course).

If I get a reply that this will be done in MC20 for 100 %, I'm ready to buy MC20 until pre-order sale.


Original topic and more info:

http://yabb.jriver.com/interact/index.php?topic=90199.0


Thanks a lot!

[Lefisu63]

I kindly try it again to ask a 3rd time ...

Is it with MC20 now possible (or planned) to read the ID3 frames TDRC and TDRL separately into their own date field (and write back to the file of course)?

These values have different meanings and must not be merged during import into one date field!

With MC19 TDRL and TDRC will be mixed into one "date" field (TDRL will be prefered over TDRC).

When writing the date back to the file the ID3 frame TDRC will be used: Finally TDRL will be moved to TDRC. The original value of TDRC is lost.

I have currently 40.000 files filled with

TDRC = original recording year of the track (e.g. ABBA / Waterloo: 1974) (TDRC = TYER in ID3v2.3!)
TDRL = release year of the release (e.g. "Best of ABBA" released in 2008)

During import I only get 2008 in "date". "1974" is not imported.
When writing back I have 2008 in TDRC (which is wrong) and 1974 is lost.

and unbelievable 15.000 CDs are waiting to get ripped ... and managed correctly with MC!

I have example files for testing available. Please ask.

I am currently no customer of MC due this problem - but I really want to be one.

Is it now possible with MC20?


Thanks a lot!

[JimH]

There have been no changes for MC20.

[Lefisu63]

There have been no changes for MC20.

Are changes planned to make it possible?

[Arindelle]

Not sure if this would work for you, but couldn't you re-map a custom field to something like TDRC? Then using an expression you could automatically fill in another field, eg. Original Release Date, and setting this to write to the file.  As i understand the custom field has to be identical to the name  of the metadata field in the file.

Here's the wiki  on this  http://wiki.jriver.com/index.php/Tags#Tag_Import_Options

[Lefisu63]

Not sure if this would work for you, but couldn't you re-map a custom field to something like TDRC? Then using an expression you could automatically fill in another field, eg. Original Release Date, and setting this to write to the file.  As i understand the custom field has to be identical to the name  of the metadata field in the file.

Here's the wiki  on this  http://wiki.JRiver.com/index.php/Tags#Tag_Import_Options

No, re-mapping does not work with TDRC and TDRL. 

Not for reading and not for writing.

Although I would be happy if reading / importing would work. Writing maybe later.

When the values will be written back into the files they must be written back into the same standard ID3 frames of course - otherwise it is not compatible with other software - e.g. Serato Scratch Live, Tag & Rename, rekordbox, etc. which I use.

Here are some hints by MrC from the original thread - but it doesn't work:

http://yabb.JRiver.com/interact/index.php?topic=89368.msg613441#msg613441

If someone wants to try it - maybe I did a mistake or someone has a solution - I can send test files via wetransfer.com. Please send me a private message.

Thanks a lot!

[Lefisu63]

Hi,

~ 11 month ago I've asked if it is possible to read/write

the ID3v2.4 tags

- TDRC ... recording time/original release year of a track.
- TDRL ... year of the release when the release (not the track!) came out on the market.

Note: TDRC (from ID3v2.4) = TYER + TDAT + TIME (from ID3v2.3)

Example:

The track "A Taste Of Honey - Boogie Oogie Oogie (Original Mix)" has been recorded (first release) in 1978 (= TDRC/TYER), the compilation from where I have copied the track on my hard disc http://www.discogs.com/release/987752 has been released in 2007 (= TDRL).


In MC 19 there was only one generic "date" field:

During reading, if TDRL is filled, it will be used. If not, TDRC will be used. So MC merges these 2 different meanings into 1 column.  

When I update the files from MC, the content of the "date" field will now be written into TDRC - independent what was the original source. TDRL will not be written back.

In the example above, TDRL overwrites TDRC and the original value of TDRC is lost.

The example track has now a "new" original release year which is 2007 - and not 1978. Completely wrong as you can see.

This sad situation makes/made MC not compatible to the ID3v2.3/4 standard and finally not to other software!

 


I would be interested in to buy MC but due the problems above MC is/was not usable for me.

Are there now 2 separate date fields for TDRC and TDRL in MC (20.0.93) and not mixed anymore?

Thanks.

[JimH]

I've merged your posts on this subject.

[Lefisu63]

Is there any update by the JR MC people / programmers?

Note - you need not read the full thread - only from my last post from "April 17, 2015, 01:27:59 pm" - which has the final summary.

I'm still waiting (soon a year!) to become a customer of JR MC.

Thanks a lot!

[Matt]

So what's the solution?  To map TDRL to a new field "Date (album)"?

I'm a little worried about that because people might end up with files that don't have the regular date filled as a result of the change.

[Lefisu63]

Hi Matt,

So what's the solution?  To map TDRL to a new field "Date (album)"?

"Date (album)" is too specific. Could be also a compilation, single, etc. Discogs.com uses "release". Maybe "product" would be better? I don't know. :-)


Example 1 (album): http://www.discogs.com/Michael-Jackson-Thriller/master/8883

There are multiple releases/products!

When I have the release/product from 1990, then all tracks have TDRL "1990" (product release), but all TDRC have "1982" (all tracks are originally from 1982).


Example 2 (compilation):

http://www.discogs.com/Ben-Liebrand-Grand-12-Inches-5/release/1303347

TDRL is 2015 (product release date), TDRC depends on each track (original release date).

I'm a little worried about that because people might end up with files that don't have the regular date filled as a result of the change.

Not really.

Until yet it is not possible to use 2 dates - so no user has noticed/used it.

So when current users would have imported from file (TDRL) into MC ("date") and wrote back to file (TDRC) and didn't notice a problem => fine (otherwise you would have many threads in the forum).

When they re-import from file into MC then TDRC will be used (TDRL is empty after writing back with MC), and import into "date". Same in MC as before.

=> No changes for the current user.

When you split TDRL/TDRC in a future release (no merge anymore) - new users will not have a problem. They have one or two dates in the correct column(s).


Currently MC makes this mistake with "one" date column:

  - During reading MC prefers TDRL before TDRC and stores it into "date".
  - After writing back MC writes the "date" into TDRC (and nothing into TDRL as I can remember).
  => During reading MC should prefer TDRC before TDRL (and not vice-versa) when writing back to TDRC only!

However, currently MC has a functional problem when merging 2 different date meanings into 1 date - and this MUST be fixed.

When I should use MC then I'm not interested in to loose any information - which currently happens - and makes MC completely(!) unusable.

So I hope you can implement this ...

Best regards - and thanks a lot for the fast reply.

[Matt]

Hi Matt,

"Date (album)" is too specific. Could be also a compilation, single, etc. Discogs.com uses "release". Maybe "product" would be better? I don't know. :-)

So "Date (album release)"?  If not, please propose something better.

Thanks.

[Lefisu63]

So "Date (album release)"?  If not, please propose something better.

Thanks.

"Date (product release)" would be the correct (& best) name. As I wrote ... needn't be an album. Could be a compilation, single, ...

THANKS

[Lefisu63]

http://id3.org/id3v2.4.0-changes:


TYER - Year
    This frame is replaced by the TDRC frame, 'Recording time'

TORY - Original release year
    This frame is replaced by the TDOR frame, 'Original release time'


and in ID3v2.4 .. the new TDRL = is the "actual" release time.

TDRC (from ID3v2.4) = TYER + TDAT + TIME (from ID3v2.3).

... and all tagging software I know is using this mapping.


Back to the example http://www.discogs.com/Michael-Jackson-Thriller/master/8883

I have the release from 1990 so:

TDOR/TORY = 1982 (product based)
TDRL = 1990 (product based)
TDRC/TYER = all tracks have 1982 for this album (of course). Different for each track on compilations which contains tracks from different years.

and for example a compilation:

TDOR/TORY = 2015 (no previous original release of this compilation)
TDRL = 2015
TDRC/TYER = value depending on each track originally released ...

Of course you can implement all 2 missing date columns into MC in one go. Personally for me only is TDRL important because I also need it with other software - but maybe would use TDOR later too. :-)

[Matt]

I was planning on mapping TDRL to [Date (original release)], but it sounds like some people might have reservations.

Could you detail what you think we should do as a series of concrete steps to make in the code?

Thanks.

[Lefisu63]

Beside the logical name of each column - the technology is more important:

"TDRL would be something like [Date (this release)], and it seems appropriate to map that to the regular [Date] field."

You can not do this:

  - Currently MC stores [date] into file/TDRC.
  - When you change [date] to TDRL, then you finally break other software (incl. scripts) based on this logical information.
  - If someone installs the new version of MC and makes an import from the files (date stored in TDRC!) into MC then you have it in a different column too.

=> Finally not a good idea.

Currently MC stores [date] into TDRC - and this must not be changed - otherwise you run into troubles. It is good as it is and shouldn't be changed.

Currently there is only one date by MC user. When the user still uses only one date - no change is required. Technically nothing changes!

----

The new version of MC offers 2 additional dates based on the ID3v2.4 specification (=> this write into the release notes):

TDOR Original release time (new)
TDRC Recording time => [MC/date]
TDRL Release time (new)

http://id3.org/id3v2.4.0-changes shows the changes regarding from the old original TYER (ID3v1, ID3v2.3) to TDRC and TYOR => TDOR.

Use my examples above (album "Thriller" and compilation) in your documentation to show the difference if someone requests it.

----

I would highly recommend the ID3v2.4 logical names to be 1:1 compatible with other software.

E.g. Tag & Rename uses

TDOR ... not implemented
TDRC Year (Date/Time)
TDRL Release time

What is the current column heading of [date] within MC? I don't know.

Customers who only buy albums still have "their" correct date in TDRC (recording = original release = release). No change required. Customers can copy this information into the other columns if they want to use it.

Customers who are DJs (like me) have stored "another" date inside TDRC old TYER) - and not the date of a product/release.

Customers can split one date into two or three more specific dates if they want. It's their own manual work. I'm sure they can copy or move from one column/tag to another wihtin MC.

I think the customer can also change the column names within MC to his own preferred name, or isn't it? So if someone doesn't like the new default names (from ID3v2.4) - they should change it. The customer only has to know which physical field is behind that to interact with other software (if required).

I'm working in the biggest bank in Austria as programmer, etc. for over 25 years now. Believe me - we had a lot of changes in our databases regarding this. ;-)

Finally only to do:

- add the 2 new columns as specified in ID3v2.4
- don't import TDRL into [date] anymore (only TDRC)
- read/write all 3 values into the file (no merge!)

I don't see a big change or any troubles.

Whatever the logical names are - the most important thing is that there are 3 date columns and they shouldn't be merged. :-)

[Hendrik]

I would argue that recording time is not what I would expect in the [Date] field, I find the release date/time more appropriate.
I mean, what do I care when it was recorded. The more common date to refer to is the release date.

Personally, I also think that having 2 additional (obscure) date fields not very intuitive, and the main [Date] field potentially not being filled anymore in the future, just because the file was tagged with another ID3 date field (and it sounds to me like there isn't a huge consistency)

[6233638]

I would argue that recording time is not what I would expect in the [Date] field, I find the release date/time more appropriate.
I mean, what do I care when it was recorded. The more common date to refer to is the release date.

Agreed.
Though I'd like to see how it compares to what other programs are doing.
All the software I've used to view tags formats them "nicely" rather than displaying the actual field names, so if the "standard" behavior for other software like iTunes is to write date into that field, I guess we have no choice but to honor that?
 
However it sounds like it doesn't suit Lefisu63's existing workflow, rather than that being what other programs are doing.

Personally, I also think that having 2 additional (obscure) date fields not very intuitive […]

Well I haven't been using the official ID3 tags because I had hoped that Media Center would have official support for this at some point, and I anticipated that there might be some debate over how the fields should be used.
 
All of my albums are tagged this way, and none of my views in MC are stock in order to handle this.
Category views look something like:
 
 [Album Artist (a-z)]
↳ [Album Artist (auto)]
 ↳ [Album] sorted by TDOR (date of original release)
  ↳ [Album] grouped and sorted by date TDRL (date of this release)

If you have multiple versions of an album, this makes navigating the library significantly easier and more intuitive.
So an example of navigating my library would look like:

 A
↳ Artist
 ↳ 1991 - Album 1
 ↳ 1993 - Album 2
 ↳ 1995 - Album 3
   ↳ 1995 - Album 3 (Original CD)
   ↳ 2005 - Album 3 (Multichannel DVD-A release)
   ↳ 2015 - Album 3 (Remastered high-res download)
 
There's no other "neat" solution I can think of which would produce those results without modifying fields to contain wrong information.
The way they're actually tagged is that the supplemental name uses the description field, so it's really really grouped/sorted by:
 
 [Date (original)] - [Album]
 ↳ [Date (this release)] - [Album] ([Description])
 
But it would be easy for me to move this into the appropriate TDOR/TDRL fields once supported in MC - that's specifically why I'm storing this information in custom fields that don't use the official ID3 tag names.
 

[…] and the main [Date] field potentially not being filled anymore in the future, just because the file was tagged with another ID3 date field (and it sounds to me like there isn't a huge consistency)

Ignoring what other programs do for the moment, what does MC write to if you enter information into the [Date] field on an untagged file?
 
And as for filling out [Date] - would it perhaps make sense to have [Date] be a "smart" field that pulls in information along the lines of: FirstNotEmpty([TDRL], [TDOR], [TDRC])
While still mapping:
TDRL = [Date (this release)]
TDOR = [Date (original release)]
TDRC = [Date (of recording)]
 
That way Date always has a value, but you can still make use of the other fields.

[Lefisu63]

However it sounds like it doesn't suit Lefisu63's existing workflow

Not true. The workflow itself is not the problem.

The only one problem and bug(!) is that MC merges/mixes 2 different columns/tags (TDRL and TDRC) from files into one column [MC/date] during import.

   * Finally (new) customers can not use their stored data in MC.
   * Lost data when writing back with MC into files.
   * ... which finally makes MC not compatible with other software.

I don't care what are the logical names in MC or any other software like Tag & Rename, mp3tag, Serato DJ, Traktor, Virtual DJ, Qoobar, foobar2000, iTunes, keyfinder, Directory Opus, etc. They always use different logical names but they don't mix the physical columns/tags from ID3v2.4 as MC is doing.

Some software supports to rename the heading (e.g. foobar2000) and so I use "Track Release Year" for TDRC/TYER and "Product Release Year" for TDRL.

But it would be easy for me to move this into the appropriate TDOR/TDRL fields once supported in MC - that's specifically why I'm storing this information in custom fields that don't use the official ID3 tag names.

That is what I mean. If the new date columns are there (and not merged anymore into one "general" date) you can use it and needn't violate another column to store the information and it is written correctly into the files and compatible with other software (whatever the logical names are in other software - that shouldn't be the problem as long MC is your "base").

Another interesting feature regarding this problem:

Click http://qoobar.sourceforge.net/en/documentation.htm and browse down to "Tagging schemes". I never tested/used it but I think it would be very useful in MC too.

@6233638:

Regarding your views or physical storage structure:

My physical structure on hard disc is based on "Product Release Year" and "discogs.com release ID".

Example from my directory names from my subdirectory 1989 (product release year):

Aerosmith_Janie's Got A Gun_[1920996]
Aerosmith_Janie's Got A Gun_[4633689]
Aerosmith_Love In An Elevator_[4633313]
Aerosmith_Rag Doll_[1681770]

I store the release id of discogs in the file and directory names and into ID3V2.4 tag "TPUB" (because I can see this tag in all the software I currently need). With the discogs release id I can always exactly identify my release/product (and it is a short name to avoid long file names).

I will install a new beta and test around when changes are done - and then I should become a new customer.

Have a nice Sunday.

[tiberiuspv]

A few comments.

1. I beg to differ with Hendrik: I care a lot about when the music was recorded, and very little about when a music executive decided he could make some money out of it... Especially in today's market which is seeing an abundance of reissues (I'm talking about classical music, where the legacy big labels are raiding their basements for anything they can reissue 'for free'). There are really 3 interesting dates, and ID3v2.4 does an excellent job of distinguishing them: recording, original release, this release. Most often, recording and original release are close together, but not always (think about a Beatles studio take exhumed out of the vaults 50 years later: is the most relevant date 1965 or 2015?). The exact release date for this specific CD is by far the least interesting of the three.

2. The approach of a 'smart field' like FirstNotEmpty([TDRL], [TDOR], [TDRC]) is excellent for importing tags into the library, but you need to be careful about how updates work. Because all three fields have different semantics and potentially different values, the write should be to only one of the 3 fields. It must be TDRC for backwards-compatibility. As far as I know, this is exactly how the [Date] field works today (with the addition of TDOR for reads). You can then add 2 new fields corresponding to TDOR & TDRL without confusion. Users who care about that level of precision can always change the display name for [Date] to "Recording date" for clarity.

3. Although this discussion has focused entirely on the ID3 tags, some care must be taken of the other file formats. One of the big values of MC as a music database is that it provides as much as possible a unified set of fields across all file formats. I personally use almost only FLAC, so my comments will be only on that format. In a word, it's a godawful mess... For the date fields, there is general agreement that DATE is the 'normal' tag, although some programs describe it as the release date and others as the recording date. Beyond that, anarchy reigns. Here are a few I found:
    - Foobar2K: RELEASE DATE and ORIGINAL RELEASE DATE, DATE is the recording date
    - Helium Music Manager (HMM): RELEASEYEAR and ORIGYEAR (Original Recording Year ?!), DATE is the recording date
    - MP3Tag: RELEASETIME and ORIGYEAR, DATE is the recording date
    - MinimServer: RELEASEDATE and ORIGINALDATE, DATE is the recording date
    - Picard/MusicBrainz: no TDRL mapping, ORIGINALDATE, DATE is the release date but is mapped to TDRC (?!)
    - and many other variants...
Obviously, there is no agreement... But please do not add yet another FLAC tag name like [Date (original release)], use one of those that already exist. (Date (original release) is perfectly fine as the visual name). Of the existing ones, I tend to prefer RELEASEDATE and ORIGINALDATE because they are descriptive enough and follow the general FLAC tag naming style, but this is very secondary. The alternative is to priority-read (FirstNotEmpty) all the variants in some order, and write all the variants on a change. Note that a similar problem happens for other tags. For example, the label information is represented in FLAC by ORGANIZATION, PUBLISHER and LABEL by various programs. Another one is the total disc & track counts, yet another one is BAND vs ORCHESTRA vs ENSEMBLE.

4. It would be useful to have a wiki page describing the mappings between fields and tags. I'm willing to write a first cut covering at least MP3 and FLAC, though I will need some reviewing by JRiver folks for accuracy and by others for style - my prose tends to be overprecise and technical...

So, my 2c summary recommendation to provide the feature with the least side-effects:
    - leave [Date] roughly the way it is: reading from TDRC then TDRL (possibly TDOR last), write to TDRC only; users can change the display name to Recording Date easily, those that care about the distinction probably know MC well enough to do it...
    - map TDRL to [ReleaseDate], TODR to [OriginalDate] (the display names can/should be more descriptive)

Tag mapping is a huge mine field...

[flac.rules]

If i understand correctly, I am very skeptical to reading from any field and writing back to just TRDC, because if you have both TDRL and TDRC populated, you will read the TRDL, and if you write it back, it will overwrite the TRDC with the TDRL-value, right? Not unexpectedly changing metadata is a very high priority for me. Personally I would like TDOR to be the regular "date-field", but that is of less importance than the overwrite problem and general handling of the tags.

[glynor]

And as for filling out [Date] - would it perhaps make sense to have [Date] be a "smart" field that pulls in information along the lines of: FirstNotEmpty([TDRL], [TDOR], [TDRC])
While still mapping:
TDRL = [Date (this release)]
TDOR = [Date (original release)]
TDRC = [Date (of recording)]
 
That way Date always has a value, but you can still make use of the other fields.

[Date] should remain a standard field (so it can be assigned directly), but I think this sounds pretty good. Use that logic (in addition to the logic you already have, probably) to assign the [Date] on import, but also populate the other, discreet fields.

If the discreet fields change post-import, leave it as an exercise to the user to modify [Date] if preferred. If you're going to change any of the underlying "real tags" when [Date] is changed, then I'd say only do it if they're blank to begin with (and otherwise use a MC-specific Date tag). If you really want to write to one of them, then TDRC seems the most rational to me (but I'm not picky).

I don't know that I love the particular names for the discreet fields that 6233638 picked out, but come up with something that looks nice and works with the "naming scheme" used for other special dates already in MC.

[flac.rules]

But isn't the problem with this the same thing the OP has been struggling with?

You have a file TDRL = 1990, TDRC = 1984. It is imported in MC, TRDL has the highest priority of the tags, the date is shown as 1990.

Later: The user wirtes the tags from library, the date is 1990, it is written back to TRDC, and the tagging on the file is "destroyed" as it is now TRDL = 1990 and TDRC = 1990.

Or do i misunderstand this?

I guess you can as you say have a separate date-tag from MC, but do we really need yet another date-tag? Having a custom tag for something that is pretty well defines in the tagging standards seems like a not very elegant solution.

[flac.rules]

I think i agree with Lefisu(?), follow the id3v2.4 recommendations, use TDRC as the date tag, no more no less.

[Lefisu63]

If i understand correctly, I am very skeptical to reading from any field and writing back to just TRDC, because if you have both TDRL and TDRC populated, you will read the TRDL, and if you write it back, it will overwrite the TRDC with the TDRL-value, right? Not unexpectedly changing metadata is a very high priority for me.

This is what is currently happening in MC and must be avoided in the future.

Please read my "initial" post from "April 17, 2015, 01:27:59 pm" (which has been merged with my old thread - so complex to read - sorry).

I guess you can as you say have a separate date-tag from MC, but do we really need yet another date-tag? Having a custom tag for something that is pretty well defines in the tagging standards seems like a not very elegant solution.

Yes.

Because when we have the 3 ID3v2.4 standard tags TDRC/TDRL/TDOR then we can exchange the data with other software!

I'm currently using Tag & Rename and foobar2000 for tagging and have data stored in TDRC and TDRL (see examples from my entry of "April 17, 2015, 01:27:59 pm") - and I am UNABLE to import both dates into MC (read above!) and NOT able to store both dates back into the same tags into the files (no 2 dates stored in MC!). Finally I can not start to use (and buy) MC.

In MC only you are still able to use a custom tag - feel free - you needn't use the (new) date fields.

Whatever the logical names are in MC or in other software - this is NOT important. Important is the technical part and not mixing physical tags and regarding other standards (not only ID3v2.3/4) - use the same mapping as other software (personally I only use ID3v2.3/4 - however).

This makes MC compatible with other software and data can be exchanged 1:1 - which is important.

[Matt]

I was planning on mapping TDRL to [Date (original release)], but it sounds like some people might have reservations.

So does making that one single change help?

I would add a new field "Date (original release)" and I would map TDRL to use that field on both read and write.  TDRL would no longer be used for the "Date" field.

Thanks.

[Lefisu63]

So does making that one single change help?

I would add a new field "Date (original release)" and I would map TDRL to use that field on both read and write.  TDRL would no longer be used for the "Date" field.

Thanks.

Yes - exactly.

One small request regarding TDRL please:

When you read an ID3v2.3 please also import TDRL (although only standard in ID3v2.4). The reason is some software supports this - including the wide used taglib library http://taglib.github.io/.

Tag & Rename only writes "ID3v2.3" but writes TDRL (and maybe others? which I don't use as far as I know). But you can write ID3v2.4 back of course. No problem

Feel also free to add TDOR also during this step. Add one or two date fields -> 1 work. ;-)

Thanks a lot!

[Matt]

We'll try it next build.  The history:

NEW: Added the 'Date (release)' field.
Changed: MP3 tagging maps the field TDRL to the new 'Date (release)' field.

[Hendrik]

Strictly speaking, "original release" is TDOR, not TDRL - which would only be "release date".

[Matt]

Strictly speaking, "original release" is TDOR, not TDRL - which would only be "release date".

So should I name the field 'Date (release)'?

[Hendrik]

Would be ok with me.

[Matt]

Just a note that you'll want to do "Update Library (from tags)" on your files after the new build is available.

[6233638]

So should I name the field 'Date (release)'?

I would prefer that you map each tag to their own field, and I think this naming scheme is the most clear/consistent:

TDRL = [Date (this release)]
TDOR = [Date (original release)]
TDRC = [Date (of recording)]
TDRC = [Date]
 
It sounds like there is an ID3 recommendation to use TDRC as "date".
So I would still suggest that [Date] looks for FirstNotEmpty(TDRC, TDOR, TDRL) on import.
But only writes to TDRC if modified.

[Lefisu63]

I would prefer that you map each tag to their own field, and I think this naming scheme is the most clear/consistent:

TDRL = [Date (this release)]
TDOR = [Date (original release)]
TDRC = [Date (of recording)]

... as ID3v2.4 ... should be so.
 

It sounds like there is an ID3 recommendation to use TDRC as "date".

... yes

• TDRC (from ID3v2.4) = TYER + TDAT + TIME (from ID3v2.3).
• TDOR (from ID3v2.4) = TORY (from ID3v2.3).

See http://id3.org/id3v2.4.0-changes (from id3v2.3):

TDAT - Date
    This frame is replaced by the TDRC frame, 'Recording time'
    [F:4.2.5].
TIME - Time
    This frame is replaced by the TDRC frame, 'Recording time'
    [F:4.2.5].
TYER - Year
    This frame is replaced by the TDRC frame, 'Recording time'
    [F:4.2.5].
TORY - Original release year
    This frame is replaced by the TDOR frame, 'Original release time'
    [F:4.2.5].
TRDA - Recording dates
    This frame is replaced by the TDRC frame, 'Recording time'
    [F:4.2.5].
... but TRDA needn't be supported at the moment. I never saw any software which has used it.

So I would still suggest that [Date] looks for FirstNotEmpty(TDRC, TDOR, TDRL) on import.
But only writes to TDRC if modified.

Definitely NOT - This is what currently happens vice-versa and MUST NOT happen in the future![/b].

When TDRC is NOT used (e.g. this is 70 % of my collection) - but TDRL is used (100 % of my collection - with the discogs.com release date!) - then you have a quirks after writing back to file! =>

Read file:
TDRC = empty
TDRL = 1990

Import into MC:
TDRC = 1990
TDRL = 1990

After write file:
TDRC = 1990
TDRL = 1990

=> which is not the READ information anymore (and finally MC is still unusable).

Your [date] (TDRC) = FirstNotEmpty(TDRC, TDOR, TDRL) would result in:
Example 1: A MJ-Thriller with bonus tracks, etc. released in 2015. TDRL = 2015. After import into MC TDRC would then have 2015 - which is not true because it must be filled with 1982 (all tracks are from 1982).
Example 2: A compilation with tracks from the 70s/80s released in 2015. TDRL = 2015. After import into MC TDRC would then have 2015 - which is not true because each track has a different year (1970-1989).

Again: No exchange and/or merge of tags during reading and writing!

[6233638]

First up, does anyone have recommendations for software which can display raw/unformatted ID3 tags rather than translating things such as "TDAT" to "Date"?
I'd like to see what other software such as iTunes is doing when writing date information to a file.
I think I have an idea of what it would be doing, but I'd like to confirm it.
 

OK, so after looking over the ID3 site:

Honestly, a lot of this sounds like a mess that they have created due to the way that ID3 tags are specified.
I don't understand why they would use "Recording Time" (TDRC) to replace "Date". (TDAT)
To me, using either "Original Release Time" (TDOR) or "Release Time" (TDRL) would make a lot more sense to replace "date". (TDAT)
But that's what they have done.
 
And the original TDAT field only supports dates in the DDMM format, so I assume it would be TDAT+TYER = "Date" (TYER = Year)
TDRC is a "timestamp" field and supports the format yyyy-MM-ddTHH:mm:ss, where items can be removed from the right to provide the precision required.
 
 
So if you were looking at what those fields represent, I can see how someone that is manually tagging their files might fill out TDOR/TDRL without anything going in TDRC.
But since most programs tag everything automatically when ripping, I doubt there will be any files that lack TDRC or TDAT information, but do contain something in the TDOR/TDRL fields.
 
So my recommendation would now be:

TDRC = [Date]
TDRL = [Date (this release)]
TDOR = [Date (original release)]
 
And for pulling in tags on import, [Date] should be using something like: FirstNotEmpty(TDRC, TDAT+TYER)
For compatibility reasons, I don't know if Media Center should only be writing to TDRC when updating dates, writing to TDRC and removing TDAT+TYER, or if it should be writing to all three TDRC, TDAT+TYER tags at the same time.
 
Again: I'd need to have a program which displays the raw tag names to figure out what programs like iTunes are using.
They may not support TDRC yet, and only look at TDAT+TYER for example.


And as a side-note, I see there is now TDTG, defined as "tagging time".
Perhaps Media Center should also be writing that to files when modifying their tags?

[ferday]

Wow this is confusing

To me (and I bet nearly everyone) [date] is album release date because the date on a CD or LP outer sleeve is the album release date.  Reissue data is ocasionally on the outer but usually in the liner, and recording date is only in the liner (except classical in some cases, or live albums)

I certainly support multiple date fields 100% (currently I use custom fields for reissue / remaster data) but I humbly submit that [date] should remain release date (like the main label on the sleeve), and reissue / recording fields should be the different ones.  I do agree they should support mapping to the appropriate id3 tags for sure but changing the "common" name [date] panders to a vocal few IMO

If this ends up not the case, that's fine i can deal with it but then I request (insist) a highly detailed release note explaining which field is which, so we all know which "common" name is which tag

[mwillems]

Wow this is confusing

To me (and I bet nearly everyone) [date] is album release date because the date on a CD or LP outer sleeve is the album release date.  Reissue data is ocasionally on the outer but usually in the liner, and recording date is only in the liner (except classical in some cases, or live albums)

I certainly support multiple date fields 100% (currently I use custom fields for reissue / remaster data) but I humbly submit that [date] should remain release date (like the main label on the sleeve), and reissue / recording fields should be the different ones.  I do agree they should support mapping to the appropriate id3 tags for sure but changing the "common" name [date] panders to a vocal few IMO

If this ends up not the case, that's fine i can deal with it but then I request (insist) a highly detailed release note explaining which field is which, so we all know which "common" name is which tag

Not only is that the date on the sleeve, but release date (whether original or current) is what almost all metadata sources seem to put in the date field (e.g. amg, freedb, etc.).  I'm not even sure how one could reconstruct the recording date for many albums without significant research.  For a meaningful chunk of albums in my collection (recorded over a period of years, or too obscure to have wiki entries) the release date is the only date I know for certain.    

I guess the standards say what they say, but are there actual metadata sources that even reliably supply the date of recording?

[Lefisu63]

TDRC = [Date]
TDRL = [Date (this release)]
TDOR = [Date (original release)]

Is correct and ok for me and finally no change for MC users.

And for pulling in tags on import, [Date] should be using something like: FirstNotEmpty(TDRC, TDAT+TYER)

Please read my previous post:

• v2.4 TDRC = v2.3 TYER + TDAT + TIME.
• v2.4 TDOR = v2.3 TORY.

In v2.3, the "timestamp" was splitted into 3 tags (TYER + TDAT + TIME). In v2.4 it is only one tag.

A timestamp can always be truncated! Read http://id3.org/id3v2.4.0-structure:


The timestamp fields are 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.

For compatibility reasons, I don't know if Media Center should only be writing to TDRC when updating dates, writing to TDRC and removing TDAT+TYER, or if it should be writing to all three TDRC, TDAT+TYER tags at the same time.

When MC is reading a ID3v2.x stream then [MC date] = FirstNotEmpty(TDRC, TYER + TDAT + TIME)
When MC is writing a ID3v2.x stream then depending on the writing ID3 format (I think MC always writes v2.4): TDRC for v2.4, TYER + TDAT + TIME for v2.3

The new TDRL should be always read from any ID3v2.x (some programs write TDRL into v2.3). MC writes it back as v2.4.

Regarding TDOR/TORY:

When MC is reading a ID3v2.x stream then [MC Date (original release)] = FirstNotEmpty(TDOR, TORY)
When MC is writing a ID3v2.x stream then depending on the writing ID3 format (I think MC always writes v2.4): TDOR for v2.4, TORY for v2.3

Again: I'd need to have a program which displays the raw tag names to figure out what programs like iTunes are using.
They may not support TDRC yet, and only look at TDAT+TYER for example.

I don't know what iTunes is doing but ... use the same logic again:

When MC is reading a ID3v2.x stream then [MC date] = FirstNotEmpty(TDRC, TYER + TDAT + TIME)
When MC is writing a ID3v2.x stream then depending on the writing ID3 format (I think MC always writes v2.4): TDRC for v2.4, TYER + TDAT + TIME for v2.3

and all is fine.

Storing TDRC and TYER/TDAT/TIME in one ID3v2.3/4 is not allowed, but possible. Finally the writing software might do this because of compatibilty reasons (but I've never seen this) - but the "timestamp" value should be always the same - of course.

And as a side-note, I see there is now TDTG, defined as "tagging time".
Perhaps Media Center should also be writing that to files when modifying their tags?

Would be nice too - but should be a new thread:

btw:

I've analyzed all files after writing (hex view) from Serato Scratch Live, Serato DJ, Tag & Rename, foobar2000, keyfinder (taglib library), qoobar, Virtual DJ, Traktor, Wavelab, mp3tag.

All are working fine with ID3v2.3 and ID3v2.4. ... I must do this before I update my collection with any new (version of a) software.

[6233638]

To me (and I bet nearly everyone) [date] is album release date because the date on a CD or LP outer sleeve is the album release date.  Reissue data is ocasionally on the outer but usually in the liner, and recording date is only in the liner (except classical in some cases, or live albums)

I certainly support multiple date fields 100% (currently I use custom fields for reissue / remaster data) but I humbly submit that [date] should remain release date (like the main label on the sleeve), and reissue / recording fields should be the different ones.  I do agree they should support mapping to the appropriate id3 tags for sure but changing the "common" name [date] panders to a vocal few IMO

Not only is that the date on the sleeve, but release date (whether original or current) is what almost all metadata sources seem to put in the date field (e.g. amg, freedb, etc.).  I'm not even sure how one could reconstruct the recording date for many albums without significant research.  For a meaningful chunk of albums in my collection (recorded over a period of years, or too obscure to have wiki entries) the release date is the only date I know for certain.

I agree. However the spec is that Date (TYER+TDAT+TIME) maps to TDRC. (Recording Time)
I think that whoever was in charge of the spec made a mistake there, and it should have mapped to TDRL (Release Time) or even TDOR (Original Release Time) considering how the majority of people use "Date" but that's the spec.
 
I do still think that having [Date] in Media Center be a calculated field might actually be the best solution for displaying/sorting content, but the two possible options seem to be:

1.
TDRC = [Date]
TDRL = [Date (this release)]
TDOR = [Date (original release)]
 
2.
Date = FirstNotEmpty(TDRL, TDOR, TDRC)
TDRC = [Date (of recording)]
TDRL = [Date (this release)]
TDOR = [Date (original release)]
 
In #2 [Date] would not be a modifiable field, and I suspect that people would be confused about which field they should be editing - especially if they intend to use MC for tagging and try to use their files with another program or on another device.
 
Whichever way works out to be best, MC would now be able to read and write to all three of these date fields separately.
And if #1 ends up being implemented, I'll probably just create my own calculated field which does FirstNotEmpty(TDRL, TDOR, TDRC)

[ferday]

62, i agree

i don't mind making [date] into a calculated field so i don't really care that much which way it goes, i just want to make sure there are rigid and unambiguous release notes / wiki entries on the mapping.  i have a lot of remaster/reissue and the date field(s) are important to my structure (which is similar to yours)

[glynor]

In #2 [Date] would not be a modifiable field

You can't do that. There would be people in here with pitchforks (myself included). Way more than the few of us commenting on this thread.

Keep in mind, that MC's [Date] field applies NOT just to music, but to all media types. And, you can't break existing functionality without a substantially good reason. Sorry, but this isn't even close to a good enough reason to break something so core (that has existed, in roughly the current form, for longer than I've been using MC). I couldn't re-tag my photos with the right date without adding a bunch of extra fields? My home movies? Fix dates for Albums? (I, like mwillems, only care about the release date, and usually just the year. I suspect that is very close to the norm.)

No thanks.

Choice #1 is fine with me, and it is fine with me if it has a "smart fill" on Import (as it does now, but expanded as needed).

[6233638]

You can't do that. There would be people in here with pitchforks (myself included). Way more than the few of us commenting on this thread.

Yeah, I figured that would happen if [Date] was changed to a calculated field.
The reason I suggested it is because I'm leaning towards not pulling data in from multiple fields for [Date] now, just the ID3v2.4 TRDC and ID3v2.3 TYER+TDAT+TIME

Keep in mind, that MC's [Date] field applies NOT just to music, but to all media types. And, you can't break existing functionality without a substantially good reason.

Well the reason I suggested it is because it would enhance the functionality of [Date] in existing views.
I did think there might be some issues with changing it to a calculated field, but just thought I would throw out the suggestion to see what other people thought.
 
I hadn't considered how it would affect other file types though - that's a good point, so obviously that won't be happening.
 

I, like mwillems, only care about the release date, and usually just the year. I suspect that is very close to the norm.

I think that's fine until you have more than one copy of an album in your library.
And I think quite a few people using Media Center have run into that problem.
The issue is that the common "solution" for this is to just change the date, because creating a custom field and then customizing all your views to use it is a complicated process.
 
If the official tags are supported, that makes it a lot easier.
 
I'd also like to see the default views updated to use a FirstNotEmpty() rule in place of [Date] (which is why I suggested changing date to being a calculated field) to make it seamless for normal users if they just add information to one of the new fields, but I don't know how much work that would involve.
 
If whatever criteria Media Center uses to determine whether something is an album or not also took advantage of these new fields, that would be huge.
I have some ridiculous rules in some of my smart lists to do things like play a random album, but avoid playing several copies of the same album in a row. (because MC thinks all the releases are a single album)
 

Choice #1 is fine with me, and it is fine with me if it has a "smart fill" on Import (as it does now, but expanded as needed).

Well as I said, after reading over the specification, I'm thinking that Lefisu63 is right.
 
I can't think of any situation where a file is missing TDRC (v2.4) or TYER+TDAT+TIME (v2.3) information, but contains something in either the TDOR/TORY or TDRL tags, where that could be anything other than intentional.
 
So we should have:

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

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

[glynor]

I think that's fine until you have more than one copy of an album in your library.
And I think quite a few people using Media Center have run into that problem.
The issue is that the common "solution" for this is to just change the date, because creating a custom field and then customizing all your views to use it is a complicated process.

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.  

[flac.rules]

I can't think of any situation where a file is missing TDRC (v2.4) or TYER+TDAT+TIME (v2.3) information, but contains something in either the TDOR/TORY or TDRL tags, where that could be anything other than intentional.
 
So we should have:

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

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

I Agree, I think this i the best way to do it, an maybe throw in TDTG while you are at it

[6233638]

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.  

I think it's a chícken and egg problem.
 
It's only a complicated thing because Media Center does not currently support the right tags for this (hopefully addressed soon) and because it does not use those tags for categorization.
 
As soon as someone only has to enter a value in the [Date (this release)] field, and Media Center automatically splits that off into its own album, it becomes a trivial to use rather than the complex esoteric thing it is now.
 
And if the new tagging pane ever gets finalized, it makes that process easier, because you can have a template which makes it clear.
 
I can see potential issues if they started to use [Description] as part of the album identifier (which I currently do) but not if [Year] is replaced with an expression that pulls the year from these new tags with FirstNotEmpty()