several patches to taglib 1.7 (based on the tag)

[Tal Sliwowicz]

Thanks for the answer.

I'll look into addFileTypeResolver.

About the debug callback set function - since I use it from C in a different
DLL, it is easier to keep it outside the namespace from a linking
perspective. That's why I opted to do it like this (couldn't get it to link
otherwise). Agreed about the naming convention.

Tal

2011/8/16 Lukáš Lalinský <lalinsky at gmail.com>

> On Tue, Aug 16, 2011 at 3:09 PM, Tal Sliwowicz <tal at tversity.com> wrote:
> > About ID3v2FrameFactory - I agree it is a very small issue (unlike the
> ASF
> > one), however, I thought that when no one holds a reference, why keep the
> > object? Our software is server side based and must be extremely tight.
>
> My only problem is that it's a lot of code for no purpose. The few
> extra bytes will not cost you anything and the memory won't grow over
> time. I imagine that in a server application you are going to use
> TagLib more than once, so re-creating the object over and over again
> is eventually going to cost you a little more than the extra memory.
>
> > Too bad about the aac and m4v. We use it all the time so it will require
> us
> > to always patch your "formal" versions. Most of the AAC we see is in MP4.
>
> You don't have to use a patched version of TagLib. You can use
> FileRef::addFileTypeResolver to add new file type resolvers from your
> application.
>
> > About the debug callback - I'm not showing this to the user. It gets
> written
> > to the application logfile and is very helpful in troubleshooting issues,
> > even when compiled with debug (NDEBUG). Keeping it in cout and just in
> debug
> > mode is a waste. Besides - it is optional. If you do not set the
> callback,
> > it never gets called. Please consider adding it.
>
> I don't have a problem with adding it, but in this case it should be
> named differently. Either following the naming convention from the C
> API (i.e. taglib_XXX) or it should be a C++ function in the TagLib
> namespace.
>
> Lukas
> _______________________________________________
> 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/20110816/55cb2e78/attachment.html>