1256 Date stored in WMA Release Time attribute [#5968]

[chrisjj]

1 On a WMA track, in Date enter 1900-01-30
2 Inspect file attribute in e.g. Mp3tag

Expected: WM/Year = EDIT: 1900, perhaps some MM custom attribute = 1900-01-03 or 01-03, WM/OriginalReleaseTime left intact
Observed: WM/Year = EDIT: 1900, WM/OriginalReleaseTime = 1900-01-03

This is a violation of the WMA (WMF11) spec:
http://msdn.microsoft.com/en-us/library ... S.85).aspx

The WM/OriginalReleaseTime attribute contains the time at which the content was originally released.

MM is writing a date to an attribute that should be used only for time, and wiping any pre-existing genuine instance of that attribute.

Note: In http://www.ventismedia.com/mantis/view.php?id=5564 Rusty wrote:
> It appears that OriginalReleaseTime was chosen because there was no other standard spec for a tag that included all date information.

OriginalReleaseTime is not a tag that includes all date information, or any.

This use of WM/OriginalReleaseTime does not gain interoperability with any program I know of.

Suggested fix: MM leaves WM/OriginalReleaseTime untouched and writes the Date to a custom MM date attribute.

Tracked at: http://www.ventismedia.com/mantis/view.php?id=5968

[Lowlander]

I'm not following. Why would WM/Year be 1990? Shouldn't MM's/Date be connected to WM/Year?

Also am I correct that WMA doesn't support full date at all?

[chrisjj]

> Why would WM/Year be 1990?

Sorry, typo for 1900, now corrected.

> Shouldn't MM's/Date be connected to WM/Year?

I think it shoud. And it is. That's not a (or the) problem.

> Also am I correct that WMA doesn't support full date at all?

Not quite correct. There's WM/MediaOriginalBroadcastDateTime http://msdn.microsoft.com/en-us/library ... S.85).aspx . Let's not go there

[jiri]

Well, yes, according to specs, WM/OriginalReleaseTime wasn't originally intended for this purpose. On the other hand, there isn't any better attribute in the complete list of WM attributes. We could define our own attribute, but it seems to be even worse solution for such a often used value (e.g. in case of Podcasts).

Btw, I reviewed http://msdn.microsoft.com/en-us/library ... S.85).aspx and wonder whether 'ID3/TDRL' wouldn't be quite suitable and at least partially mentioned by specification, i.e. not completely MM specific. Thoughts?

Jiri

[chrisjj]

> Well, yes, according to specs, WM/OriginalReleaseTime wasn't originally intended for this purpose.

Original intent? The point is WM/OriginalReleaseTime is not currently for this purpose.

> On the other hand, there isn't any better attribute in the complete list of WM attributes.

That's not good reason for abusing this attribute. MM's abuse attribute overwrites legitimate use.

> We could define our own attribute, but it seems to be even worse solution for such a often used value

I don't see anything worse about this. MM has already done this for twelve other attributes inc. the often-used Rating.

> Btw, I reviewed http://msdn.microsoft.com/en-us/library ... S.85).aspx
> [The following table lists all of the attributes that correspond to ID3 tags...]

All tags, note. WM/OriginalReleaseTime is excluded, meaning it it does not have the ID3 correspondence of MM's current behaviour.

> and wonder whether 'ID3/TDRL' wouldn't be quite suitable and at least partially mentioned by specification, i.e. not completely MM specific. Thoughts?

I think
a) the intent of that is one uses native OR ID3tags, not a mixture.
b) the result would still be MM specific in practice since I've seen no desktop app that uses ID3 in WMA, let alone a mixture of ID3 and WM/ in WMA.

[jiri]

I think that problems of tagging several tagging formats according to specs and in the best possible agreement with other apps have been discussed several times. Words like 'abuse' seems to me to be too strong in such a context.

Anyway, the truth is that it seems that WM/OriginalReleaseTime usage should be changed. If anybody knows of any app using this or other attribute for release date storage, please let me know. Some of the possible options to be used are 'ReleaseDate', 'ReleaseTime' or 'ID3/TDRL', although none of them is known to be used by any other application.

Jiri

[chrisjj]

> I think that problems of tagging several tagging formats according to specs
> and in the best possible agreement with other apps have been discussed several times.
> Words like 'abuse' seems to me to be too strong in such a context.

Agreed... but this is not such a context. This simply about one format that does not standardly accomodate MM's "Date" property. MM's behaviour is an abuse, because it is using an attribute for something it is not supposed to be used for. And this can lose user data.

> Anyway, the truth is that it seems that WM/OriginalReleaseTime usage should be changed.
> If anybody knows of any app using this or other attribute for release date storage

Jiri, this issue is not about any "release date". It is about the primary date MM calls "Date". MM has a separate field "Original Date" that maps onto format release dates e.g. ID3 TORY ("The 'Original release year' frame is intended for the year when the original recording").

> Some of the possible options to be used are 'ReleaseDate', 'ReleaseTime'

Please no. It is not a release date.

> or 'ID3/TDRL'

That is also for a release date plus it is from the ID3 V2.4 spec that IIUC MM does not generally support.

I propose DATE. It is
a) clear, esp. in having a direct accordance with the MM internal name Date obviating the need for MM to define what it really means by "Date".
b) safe w.r.t. the WM standard
c) accordant with the FLAC standard http://xiph.org/vorbis/doc/v-comment.html
d) looking attractive to other programs already having a Date property e.g. WinAmp, which hopefully would adopt it.

[jiri]

Please no. It is not a release date.

Some people might use it for the date/time of recording, but I see it mostly as a time of release. I think it makes most sense both for a year of release of an album or a date of release of a Podcast. In both cases the most important information is when it was released, not when it was recorded or any other date.

That said, the proposal of 'Date' also makes sense to me, it's definitely a viable option.

Jiri

[chrisjj]

> I see it mostly as a time of release

Note that I'm reporting that MM is writing a date into this time field.

> In both cases the most important information is when it was
> released, not when it was recorded or any other date.

Maybe to you Jiri, but MM's calling it Date leaves each user to exercise his own preference.

[jiri]

Note that I'm reporting that MM is writing a date into this time field.

I'm not sure what you expect there, but in my opinion 'time' here means complete time information, which is date+time.

[chrisjj]

> in my opinion 'time' here means complete time information, which is date+time.

So how come MM doesn't write that either?