One major annoyance in running MediaTomb on a NAS box is the lack of support for wma tags. There seem to be a lot of Windows users that run MediaTomb on a NAS and many have wma files in their collection. When running in a normal linux environment, it looks like ffmpeg handles the reading of wma tags and it works really well. However, compiling ffmpeg for the NAS is difficult. I have found another solution and I found it listed as a feature request for MediaTomb.
I have compiled taglib-1.4 with the wma patch. At first this worked only marginally (it would not read some Track Number data), but I have modified the code and got it working. Next, I looked at the MediaTomb source and saw that it only attempts to read mp3, flac, and ogg tags with taglib. I tested with an extremely crude hack to metadata_handler.cc (adding item->getMimeType().startsWith(_("audio")) to the #ifdef HAVE_TAGLIB section)and I have it reading wma tags with taglib. It looks like the cleanest way of handling this would be to create CONTENT_TYPE_WMA and associate it with mimetype audio/x-ms-wma, then use it as a valid type for taglib. Does this make sense?
I can also send you the patched taglib-1.4 source if you wish in case you would like to use it for future static builds.
well, if you ask me - WMA itself is a major annoyance :)
I know the story, taglib devs refused to include wma support in their library, so those patches are subject to bitrot. I can add an option to configure to enable WMA processing by taglib, just to make it easier for those who mess around with it, but I do not think that I will be patching taglib for the static builds. I anyway plan to switch to taglib 1.5 for the next static releases and I do not have any motivation to invest any additional work in messing with taglib and wma, it's anyway an evil format :>
So unless you manage to get those patches into an official taglib release or add this functionality to id3lib, you'll have to roll your own binaries, sorry.
I agree with you, but with static binaries for NAS devices, you're going to hear about wma and iTunes (another evil format) ;) At least libmp4v2 works and the iTunes folks won't complain :) Actually, my wife only has a few wma tracks, so I could live without it as well. I'm just in a generous mood this week trying to help the masses :) From what I've read, the taglib developer is anti-M$ and wma support will probably never happen.
On another note, I have made a static build (SVN 1903) available for the DNS-323 and it seems people are happy with it, especially with the ogg and flac transcoding. Also, online streaming seems to popular. Mp3, ogg, and MMS (wma) are working really well.
> At least libmp4v2 works and the iTunes folks won't complain
speaking of libmp4v2 - is there anyone still maintaining it or is there a forked project? is there anyone whom you could send your patches?
> From what I've read, the taglib developer is anti-M$
> and wma support will probably never happen.
I do share his views and understand why he does not want to add it to his library :)
> On another note, I have made a static build (SVN 1903) available for the DNS-323 and it seems
> people are happy with it, especially with the ogg and flac transcoding.
I still had no time to look at the toolchain that you posted, I'll be happy when I manage to produce a working build for the 323 and other Marvell Orion based devices in my OpenEmbedded environment, OE is very handy, once the basic configuration is done it allows me to quickly cross compile for a number of targets.
> speaking of libmp4v2 - is there anyone still maintaining it or is there a forked project? is there anyone whom you could send your patches?
From what I see, nobody is maintaining the project and I did not see a forked project. It also clearly states that no further contributions will be accepted. Cisco actually owns the project and the person that maintained it left the company. It seems they are not willing to pay anyone else to maintain it.
As far as the change I made, I posted what I did on their sf forum. The change I made is pretty much a hack anyway just to get it working on the DNS-323 and I'm not sure it is valid for other Marvell Orion devices. There may also be a bug in the toolchain I am using that prompted this change. I think the root cause has something to do with converting 32 and 64 bit "words" to machine byte order. I had a related issue when porting libmms to this device.
btw is the DNS-323 little or big endian?
I just got an explanation why the unmodified libmp4v2 code doesn't work on my NAS. In one relevant function in the code, it tries to read a 32-bit value from an unaligned address and this doesn't work on an ARM. The address must be aligned (multiple of 4). You'll probably have the same issue if you include libmp4v2 in future static builds and have to modify the source. Just thought you should know :)
I've just discovered the same problem... and I've already ripped a couple of hundred albums to WMA VBR (because I read WMA VBR is better than MP3 VBR). As I've already got the tracks stored as /music/artist/album/track.wma it should be possible to extract basic info about the track from its location rather than simply dumping everything in 'Unknown'.
I'm a noob at js scripting, so if anyone could help...
(I see someone else has a similar complaint about AAC files, so it could be a simple generic answer)
I think I've found an answer... first impressions are that it is working (although their aren't any error traps to catch anything that fails)
The answer is based on the first offering in the scripting wiki ('File System Structured Import Script')
It assumes you store the files in '..../Artist/Album/Track.ext' format and should pick up the missing 'Artist' and 'Album' for any audio file that taglib/id3lib can't find ID3 tags (wma, aac, flac, etc)
var chain, dir_artist, dir_album;
var location = obj.location.split('/'); //obj.location is the complete filespec for the file
chain = new Array();
dir_artist = location[location.length-3]; //3rd item from end should be artist directory
dir_album = location[location.length-2]; //2nd item should be album directory
// location[location.length-1] should be file itself, but the MT already knows that
You then tweak the existing script to replace "artist = 'Unknown'" with "artist = dir_artist", etc
(you can tell the ones that are built this way because the 'title' is the filename, eg. "She Loves You.wma" rather than "She Loves You")
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.