MediaMonkey forum

EDIT: Date column fails to show year containing non-digit e.g. 1942-04-15 or 1950/1951, if the file is WMA but not if it is FLAC.

Note that MS defines (http://msdn2.microsoft.com/en-us/librar ... S.85).aspx) WM/Year to be a string, not number.

This is a PITA - it would be nice if it was fixed!

EDIT: The forum seems to have broken that link. Trying again: http://msdn.microsoft.com/en-us/library ... S.85).aspx
EDIT: It broke that too.Trying BBCode url: http://msdn.microsoft.com/en-us/library ... S.85).aspx
EDIT: That works.

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

I'm using 1147 but dates on my WMA files display fine.

> I'm using 1147

Oops, my bad - upgrading now...

> but dates on my WMA files display fine.

Thanks, but still they fail here. E.g. Mp3Tag shows 1942-04-15 and MM shows blank.

Mine are in WM/Year. Yours?

Here's a WMA file demoing this:

http://www.chrisjj.com/temp/MMYearDispl ... rtened.wma

and a screenshot of the failure:

I tagged them in MM so whatever field they get tagged in is where they are. (Sorry, I have no idea what frame it is.)

> I tagged them in MM

That works here. But

> so whatever field they get tagged in

"ReleaseDate", I find.

So, here MM Date fields is reading one tag but writing to another. Urk. Devs, any comment??

chrisjj wrote:So, here MM Date fields is reading one tag but writing to another. Urk. Devs, any comment??

Please?

Yes, WM/Year is stored as a string (as many other WM attributes), but it's supposed to be used for really for year only, see http://msdn.microsoft.com/en-us/library ... S.85).aspx

That said, I just noticed that MediaMonkey doesn't support WM/OriginalReleaseTime attribute yet, it will be fixed.

Jiri

jiri wrote:Yes, WM/Year is stored as a string (as many other WM attributes), but it's supposed to be used for really for year only, see http://msdn.microsoft.com/en-us/library ... S.85).aspx

Jiri, there is nothing in that MS article or the one I quoted that says this string value must be numeric rather than alphanumeric. "2000 B.C." and "Nineteen hundred" are valid values, as is my original example "1950/1951".

I think the MM design's presumption that the value is always numeric is in error, and MM has no justification in restricting the value to numeric. But even if it must, it really should not wipe out my values (on Sync tags) just because they don't fit its own restrictions. Please would you consider fixing this.

I added this issue to Mantis in order to review it for inclusion in next MM version (not 3.1). Note that the issue is significantly more complicated than it might seem. Just to name few problems - proper presentation of various possible date formats (not everyone wants to see 2004/12/24 as suggested e.g. for OGG), internal handling for fast searches and auto-playlists, storage in various formats (e.g. ID3v2.4 allows only yyyy-MM-ddTHH:mm:ss format), etc. So, we'll try to come with some solution, but I can't be more specific at this moment...

Jiri

> I added this issue to Mantis

Thanks Jiri, but could you provide the link? I cannot find the entry.

> the issue is significantly more complicated than it might seem. Just to name few problems - proper
> presentation of various possible date formats (not everyone wants to see 2004/12/24 as suggested e.g. for OGG)

Perhaps MM is trying to be too clever. The "proper" presentation for a string value is simply as is. That would suit me fine.

> internal handling for fast searches and auto-playlists

See above, surely.

> storage in various formats (e.g. ID3v2.4 allows only yyyy-MM-ddTHH:mm:ss format), etc.

The WMA Year field cannot be mapped to that ID3 field, so MM in trying to force the two to accord is making life very difficult for itself.

Either: http://www.ventismedia.com/mantis/view.php?id=5139
Or: http://www.ventismedia.com/mantis/view.php?id=5146

Maybe?

> Or: http://www.ventismedia.com/mantis/view.php?id=5146

That fits the bill - thanks.

Though "add support for dates that are stored as arbitrary string" seems to be in error, since the required support is already present in FLAC and even in WMA many dates stored as arbitrary string are supported e.g. 1940!. Better I suggest would be "Add WMA (and other) support for year values other than just 2,3,or 4 digits".

jiri wrote:Note that the issue is significantly more complicated than it might seem. Just to name few problems...

Jiri, are these problem overcome, now that you have implemented this for MP3? So can we hope for implementation on WMA soon? Especially since standards-wise WMA allows it whereas MP3 does not.