<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi all,<br>
<br>
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
<a class="moz-txt-link-freetext" href="http://lists.kde.org/?l=taglib-devel&m=113365793626227&w=2">http://lists.kde.org/?l=taglib-devel&m=113365793626227&w=2</a>).
It made its way into Amarok:
<a class="moz-txt-link-freetext" href="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">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</a>
. So really all that needs to be done is to package that up and
distribute it separately. <br>
<br>
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?<br>
<br>
Umesh<br>
<br>
Scott Wheeler wrote:
<blockquote cite="mid459EA6AC.2090606@kde.org" type="cite">
<pre wrap="">Xavier Duret wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Except that never happens. ;-)
</pre>
<blockquote type="cite">
<pre wrap="">2 - I am just going to hope this is not the case.
</pre>
</blockquote>
<pre wrap=""><!---->
I'm not exactly a fan, but no, that's not the thing keeping support out.
</pre>
<blockquote type="cite">
<pre wrap="">3 - I have read there <a class="moz-txt-link-rfc2396E" href="http://mail.kde.org/pipermail/taglib-devel/2005-March/000096.html">"http://mail.kde.org/pipermail/taglib-devel/2005-March/000096.html"</a> 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?
</pre>
</blockquote>
<pre wrap=""><!---->
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.)
</pre>
<blockquote type="cite">
<pre wrap="">4 - This should be easy to fix.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
</blockquote>
<pre wrap=""><!---->
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
<a class="moz-txt-link-abbreviated" href="mailto:taglib-devel@kde.org">taglib-devel@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/taglib-devel">https://mail.kde.org/mailman/listinfo/taglib-devel</a>
</pre>
</blockquote>
</body>
</html>