bug encoding multibyte?

[Xavier Duret]

> You are misunderstanding how does it (not) work.
Probably, yes.

> There is "no" plugin
> support in TagLib. All you have are two separate libraries. Taglib works
> on it's own, the one with additional plugins links to TagLib (not the
> other way around). Now what you need to to is load TagLib, register the
> new file type to TagLib and use the TagLib::FileRef class. So instead of
> one header file, you will include two header files and instead of
> linking to "libtag", you will link to "libtag" and "libtagext". Again,
> no external dependencies.
How to do things in C++ is very clear to me. I am having trouble to
imagine the C bindings. Remember that there is no overloading
mechanism in C.

The following 3 declarations are a problem:
- TagLib_File_Type: this is an enum declared in C so it cannot be extended.
- taglib_file_new: use the base FileRef::create method which does not
know of the types declared in taglibext.
- taglib_file_new_type: this is dependent on TagLib_File_Type and also
use the "new" operator which would lead to a #include <m4afile.h>
inside tag_c.cpp which is not acceptable.

What I can imagine is:
- TagLib_File_Type is replaced by something that can be extended like
an int with DEFINE statements or TagLib_File_Type is extended to
support even types that are not supported by taglib.
- An initialization function like taglib_file_init is added to
libtag_c for registering new types. A new type is defined by a
File_Type, a FileTypeResolver (needed by taglib_file_new) and a
FileTypeFactory (needed by taglib_file_new_type). This function adds
the FileTypeResolver to a FileRef object.
- Each extension library like libtagext needs to provide a function
(e.g. taglibext_getm4a_info) to provide the input to
taglib_file_init.
- taglib_file_new uses the FileRef object initialized by
taglib_file_init instead of using the base class directly.
- taglib_file_new_type is adapted to use the replacement of TagLib_File_Type.
- taglib_file_new_type does a lookup of the proper FileTypeFactory
using the File_Type as index.
- the main program includes "tag_c.h" and the different "tagext_c.h".
It calls the different
taglib*_get*_info function and feed the result to taglib_file_init.

This is not as straightforward as the current situation. I would not
be surprised to learn that the other bindings need some drastic
changes to accommodate taglibext. Changes to the API do not get
accepted by Scott that often. Project that do not use C++ will be
stuck without WMA nor M4A support for quite some time.

> Of course, this is the way to go if the "generic" TagLib::Tag API is
> enough for you. I personally think using ID3v1-like API for audio
> metadata these days it just silly. So for any real use you will need to
> use the new classes directly and deal with file format differences.
I am not going to answer that...