Please do not shoot: ASF read support

Scott Wheeler wheeler at
Fri Jan 5 20:27:40 CET 2007

Xavier Duret wrote:
> As far as I can see, there can be 5 arguments against the inclusion of ASF-WMA support in taglib:
> 1 - The maintainer does not want to have to maintain such an ugly format.
> 2 - The maintainer has some ethical or political problems with Microsoft.
> 3 - The origin of the code itself is doubtful.
> 4 - The code itself is not up to the standards of the project.
> 5 - The functionality involved is patented.
> I would like to answer those points one by one. The first four are the easiest to solve.

> 1 - Given that this project is open source, it should be easy to make it clear who is responsible for maintaining the ASF-WMA functionality and avoid bugging the main maintainer about it.

Except that never happens.  ;-)

> 2 - I am just going to hope this is not the case.

I'm not exactly a fan, but no, that's not the thing keeping support out.

> 3 - I have read there "" that Scott wants to avoid having anything to do with code from mplayer. Fair enough. If the functionality came from another source, would it be okay then?

It needs to be clear that it's from an LGPL'ed project or less 
restrictive and that it draws from proper reverse engineering, not the 
official spec.  I mentioned MPlayer specifically because they've got a 
reputation for mostly disregarding such things.  (I have no problems 
with the project, but in that regard I don't want to incorporate their 

> 4 - This should be easy to fix.

It's not up to the standards and would essentially need a complete 
rewrite.  (This isn't Umesh's fault; he just took the code from a C 
project.)  It also doesn't support saving, which is essential for inclusion.

> 5 - This is where it pays to start being specific. I have seen a lot of statement from people about the fact that the format is patented. It seams that the "P" word is being used to close all discussion. The fact is that patents can be worked around. I am going to make a list of precise statements, let's see if some actual evidence of the contrary can be found:

Others have brought up the patent; I haven't.  While that's something of 
a concern, the more notable thing is that the specification has clauses 
which ban OSS implementations.  That makes the spec unusable.  The 
patent claims I haven't seriously looked into just because there are 
presently so many other barriers that they're just a drop in the bucket.

One notable thing is that as of 1.4 (or was it 1.3?) it's possible to 
add support for additional formats without modifying TagLib itself.  
Amarok does so for several formats.


More information about the taglib-devel mailing list