Please do not shoot: ASF read support

[Umesh Shankar]

Hi all,

  I'm that guy that wanted WMA back in the day, and basically hacked it 
up to get something working. Fortunately, there is a nicer 
implementation that doesn't use mplayer sources and supports both 
reading and writing (see 
http://lists.kde.org/?l=taglib-devel&m=113365793626227&w=2).  It made 
its way into Amarok: 
http://www.google.com/codesearch?hl=en&q=+lalinsk%3F+show:zeiX03IyRo0:usKRzNnyrIs:h9jy4mKXGIo&sa=N&cd=6&ct=rc&cs_p=ftp://ftp.kde.org/pub/kde/unstable/snapshots/kdeextragear-multimedia.tar.bz2&cs_f=kdeextragear-multimedia-585268/amarok/src/metadata/wma/wmatag.cpp#a0 
. So really all that needs to be done is to package that up and 
distribute it separately.

Scott, it's been a long time but last time I tried to make a separable 
package, I couldn't get it to work because there wasn't a registration 
mechanism that could be reliably invoked without modifying Taglib. Has 
that changed more recently? Are there successful add-ons that use this 
mechanism?

Umesh

Scott Wheeler wrote:
> 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 "http://mail.kde.org/pipermail/taglib-devel/2005-March/000096.html" 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 
> code.)
>
>   
>> 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.
>
> -Scott
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/taglib-devel/attachments/20070105/d9d866f8/attachment.html