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.
TDRC and TDRL both map to the date.
There have been no changes for MC20.
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 (http://wiki.JRiver.com/index.php/Tags#Tag_Import_Options)
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.
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.
"TDRL would be something like [Date (this release)], and it seems appropriate to map that to the regular [Date] field."
I would argue that recording time is not what I would expect in the [Date] field, I find the release date/time more appropriate.Agreed.
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 […]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.
[…] 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?
However it sounds like it doesn't suit Lefisu63's existing workflow
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 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.
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.
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.
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.
Strictly speaking, "original release" is TDOR, not TDRL - which would only be "release date".
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:
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)]
It sounds like there is an ID3 recommendation to use TDRC as "date".
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.
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
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.
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 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?
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.
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.Yeah, I figured that would happen if [Date] was changed to a calculated field.
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, 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.
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.
Media Center | v2.4 | v2.3 |
[Date] | TDRC | TYER+TDAT+TIME |
[Date (original release)] | TDOR | TORY |
[Date (this release)] | TDRL |
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 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 Centerv2.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.
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.I think it's a chícken and egg problem.
Not worth it. ;) ;D
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. ;) ;D
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.
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!
I don't know if anyone noticed, but there's a new build available that makes the changes I proposed.As discussed, please use:
I'm a little scared that I've entered a worm hole, so hopefully everyone will be happy with the changes!
Media Center | v2.4 | v2.3 |
[Date] | TDRC | TYER+TDAT+TIME |
[Date (original release)] | TDOR | TORY |
[Date (this release)] | TDRL |
looking at the default tagging behavior of other software (like WMP and dBPoweramp), they don't appear to be spec compliant eitherAre 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.
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?
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 ?
[Date] is TDRC or TXXX (JR/Date).Based on what? if the existing tag is id3v2.4 or id3v2.3 or older?
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).Since everyone writes the release date to "Date" (TDRC or TYER+TDAT+TIME) that can't change.
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.
[Date] is TDRC or TXXX (JR/Date).What is JR/Date?
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).
What is JR/Date?
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").
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.
To be clear, I'm saying that almost all scrapers and metadata services I've used are writing the release date in TDRC
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.
Media Center | v2.4 | v2.3 |
[Date] | TDRC | TYER+TDAT+TIME |
[Date (original release)] | TDOR | TORY |
[Date (this release)] | TDRL |
I still haven't found a good piece of software to display raw/unformatted tags though, so that might not be correct.
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%)
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)
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)
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).
+1yes, agreed +1
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 Centerv2.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)