Bugzilla – Bug 4674
Comment tag in WMA file does not display in Slimserver
Last modified: 2009-09-08 09:13:47 UTC
(reference support tmid 19538) Customer is not seeing the proper tags in his wma files. Tried updating him to 6.5.1 which coreected some of the problem, but he still cannot see the comment tag. I tried his file here and confirmed. (file attached)
Created attachment 1774 [details] wma file where comment tag doesn't appear in slimserver
I see the same behavior on both Mac OS X and Win XP.
how did the comment get put in there, as in which tools are used? Looking at the getTags, it's a bit of a mess around the comment section, and the parse seems to show it as a block of ID3 tags, including COMM and APIC. I don't think there has been any attempt at parsing ID3 tags in a WMA file in slimserver.
(In reply to comment #3) > how did the comment get put in there, as in which tools are used? Looking at > the getTags, it's a bit of a mess around the comment section, and the parse > seems to show it as a block of ID3 tags, including COMM and APIC. I don't > think there has been any attempt at parsing ID3 tags in a WMA file in > slimserver. I used Tag & Rename originally to tag the file.
Andy: weren't you looking at ID3 tags in WMA files?
ID3 tags are not valid nor supported in WMA files.
Wait, are you saying the WMA file attached is ID3 tagged? What is the best way for a user to test for this?
I my comment #3, I noted that the comments were embedded in id3 tags. For users: Tag & Rename is one easy way to find out, if you select the folder with wma files, then select the id3v1 or id3v2 tag buttons, it will show any tags of that type. For wma, it should only show tags when wma is selected.
Thanks KDF, I will give that a shot when I get a chance.
there are a whole family of legal, correct to spec, WMA tags that are not picked up by the scanner ... the comment field is one, replaygain is also not-seen/ignored WMA tags are located in two seperate blocks in the WMA/ASF header, and are of two slightly different formats, which i imagine is the root of this issue. the old, freely available, microsoft ASF spec documentation describes how to retrieve all the WMA header data. (sorry i'm being a bit vague here, it was a good while ago that i briefly looked at this sort of thing, but after checking the MS doc, was able to quickly cobble together my own personal (amateur-night) scanner to populate the slim database with the mssing WMA tag data ... so it's all easily do-able)
Well, this bug is about an ID3 tag in a WMA file, which is not valid. But if there are valid WMA tags we're missing, would you consider submitting a patch to Audio::WMA since you've already worked out the details?
hmmmm, the bug was originally about not reading the comments. the user's file is certainly an 'interesting' ol' item, but as you correcly state, ID3 tags are not part of the WMA spec, and i wouldn't think there would or should be any expectation that the scanner support or parse them. (whatever application insisted on pushing them in there definitely wasn't in the mood for taking any prisoners) but if you scroll down way past all that ID3 stuff (located at offset 35056 if your looking at the sample file in a binary editor) ... you find a perfectly valid and legal WMA comment tag. this is the comment tag that is recognized, read and editable by all the other apps i showed this file to (most notably Windows Media Player and MP3Tag), but it is not seen by the scanner and never makes it into MySQL. so i'd say the original bug still stands, the ID3 thing is a bit of a distraction, if we ignore that, we can still say that the 'comment tag in WMA file does not display in SlimServer'. (i've got 35,000 examples of WMA files with valid, compliant WMA comments that wouldn't get seen or loaded into the database) likewise, it would also be good if we could broaden this to include the (again legal, and in the right place) replaygain family of tags that are similarly ignored by the scanner when it inspects a WMA file. it'd be a nice bunch of extra utility for a specific slice of users for not too much effort. as to me patching Audio::WMA ... i'm not quite so sure that's our best plan ;) ... i'm a microsoft and .NET kind of guy, hence all the WMA files i suppose, (the scanner i wrote was VB.Net so that's no good to you - although i've got to say, custom built it could therfore be insanely fast, scan, parse and build the whole data structure in memory, jiggle it round to create the foreign keys, and do a MySQL bulk insert - full wipe and 35,000 track rescan takes hardly any time at all) i gotta believe that someone that is even vaguely familiar with the Audio::WMA code could add the extra few lines to parse the required tags a whole lot faster and more reliably than it would take me to have to teach myself Perl. (although if the decision is made that is not worth fixing, then you never know, i might have a crack at it) --- david
Can you point me at the docs for the WMA comment and replaygain tags? Are we missing any other tags? I don't see these mentioned in the Microsoft ASF spec.
to find the comment tag in the ASF spec: you want to go to the "Content Description Object", and there you'll find two fields, the "Description Length"(WORD), and the "Description"(WCHAR) ... that's where they hid the comment tag. (hey i agree, the ASF spec is tortuous) replaygain isn't mentioned as such by ASF but the replaygain tags and data are legitimate (ie, in the correct place and format) WMA tags they are stored in the Extended Content Description Object ... to quote from the spec: "The Extended Content Description Object lets authors record data describing the file and its contents that is beyond the standard bibliographic information such as title, author, copyright, description, or rating information. This information is pertinent to the whole file. Each Content Descriptor stored in this object uses a name/value pair metaphor." the scanner will already be familiar with this ExCDO, this is where tags such as WM/AlbumArtist, WM/Genre, and stuff like the track year, album title etc. etc. are all stored. RG tagnames (or descriptor names in ASF parlance) are as you would expect: replaygain_album_gain replaygain_album_peak replaygain_track_gain replaygain_track_peak the "Descriptor Value Data Type" for RG tags is 0x00, which means a unicode string, and the RG values are therefore stored as strings. off-hand i can't think of additional tags that would need support, but certainly given the nature of the slimserver app, i would think these two would add plenty of benefit for WMA users. it was a year since i last had to look at the ASF spec, so a bit rusty, but i hope this helps.
Thanks, do you have an example file with replaygain tags?
Interesting, while I'm personally still not seeing the 'legal' tags anywhere, I can state that Tag & Rename behaves badly with WMA. Even set in WMA tag mode, editing a comment writes to the TCOM id3 tag section. Using WMP seems to leave that unaffected. lib/Audio/WMA.pm is already collecting the Description field, so we just need to map it back to comment. adding the following to Formats/WMA works: Index: C:/slim/server/Slim/Formats/WMA.pm =================================================================== --- C:/slim/server/Slim/Formats/WMA.pm (revision 14987) +++ C:/slim/server/Slim/Formats/WMA.pm (working copy) @@ -18,6 +18,7 @@ 'AUTHOR' => 'ARTIST', 'VBR' => 'VBR_SCALE', 'PARTOFACOMPILATION' => 'COMPILATION', + 'DESCRIPTION' => 'COMMENT', );
Created attachment 2448 [details] WMA file with comment and replaygain tags
Created attachment 2449 [details] grabe replaygain and comments this should do it, unless we want to do the additional processing for the WM/AlbumTitle, WM/TrackNumber, WM/Year or WM/Track. TrackNumber in this case is 4 while Track is 3, so I need to look that one up. Will attach a dump of the ECDO for reference.
Created attachment 2450 [details] ECDO contents
info about WM/Track vs WM/TrackNumber is here: http://msdn2.microsoft.com/En-US/library/aa392014.aspx
Created attachment 2451 [details] corrected my mistake. the array is for a list of metadata that we collect into full lists. Obviously other data is fine, and we currently ignore the WM/Track as recommended. updated the patch to simply allow the addition grab of replay* metadata.
Thanks kdf, go ahead and apply!
merged at change 14990. Comments and replay gain info should now show up, while ID3 block remains ignored.