Read/write FLAC picture support in trunk

Sander Jansen s.jansen at gmail.com
Mon Jan 24 18:41:39 CET 2011


2011/1/8 Lukáš Lalinský <lalinsky at gmail.com>:
> Hi,
>
> I've committed a patch that adds full read/write support for embedded
> FLAC pictures to trunk. It changes completely how FLAC files are
> saved, so I'd love if somebody else could have a look at the code to
> check for obvious mistakes (full patch in the attachment) and also try
> it on some FLAC files.
>
> https://bugs.kde.org/show_bug.cgi?id=218696
> http://websvn.kde.org/?revision=1154376&view=revision
> http://websvn.kde.org/?revision=1201717&view=revision
> http://websvn.kde.org/?revision=1212863&view=revision
>

Hi Lukas,

Thanks for adding this to taglib. Just tried it out. So far all my
covers are getting loaded properly. It does take longer to read in,
but I'm not sure if this can be avoided. In my music manager I read in
all the text tags to store them in the database, hence I ignore any
cover art. The cover art gets loaded separately later on.

Here are some timing comparison when reading tags:

Timings in cpu-ticks:

(TagLib 1.6.3)
loadTag:         335754 ticks.
loadTag:         328644 ticks.
loadTag:         321075 ticks.
loadTag:         323316 ticks.
loadTag:         322866 ticks.
loadTag:         322065 ticks.
loadTag:         320571 ticks.

(TagLib Trunk)
loadTag:         490239 ticks.
loadTag:         541800 ticks.
loadTag:         472500 ticks.
loadTag:         566028 ticks.
loadTag:         495585 ticks.
loadTag:         478818 ticks.
loadTag:         577116 ticks.

So roughly we're talking about a ~200000 ticks difference. Perhaps a
coverless-read-mode might be nice (for other tags as well).

Cheers,

Sander


More information about the taglib-devel mailing list