Next release
Linus Walleij
linus.ml.walleij at gmail.com
Sun Dec 28 09:01:04 CET 2008
2008/12/27 Dudy Kohen <kohen.d at gmail.com>:
> I'm one of the developers of an application (GtkPod) and recently I've
> realized that the library we're using for ID3 tags is very buggy, and
> doesn't write larger tags than the original, and is unable to add or remove
> tags from a file. (libid3tag)
Yeah, it has these bugs. I realized at some point, there should be a warning.
The implicit usage pattern in libid3tag is: if the tag grows then you have to
strip the tag from the file, render the tag to memory instead, then copy
the file after the tag. The logic for stripping the tag off the file
in that case
has to be implemented by the side, so using it actually requires you to
implement a basic tag parser at the side.
I learnt about this from their mailinglist at some point.
> If I improve the C bindings, when will the next release would be available?
Do you think they will be merged? There is a rationale that taglib C bindings
shall only reflect a very basic interface ("core functionality"), just
reading or writing
basic metadata more or less. For example I implemented stripping of
ID3-tags for the C bindings but the patch was rejected.
http://bugs.kde.org/show_bug.cgi?id=149992
The suggestion was to add some C++ code to my program (gnomad2)
and implement these functions outside of taglib.
Which is doable I guess. But I still hesitate, because bringing in a C++
compiler to the dependencies is heavy and I did it before with
the library id3tag (the old reference implementation, used before
libid3tag) with mixed feelings.
But if you need such bindings for gtkpod as well, perhaps we should
make a glue library with the missing functions instead, like "ctaglib"
that is written in C++ and exposes a larger C API that what comes
with taglib. Then maintain that separately.
Linus
More information about the taglib-devel
mailing list