Taglib 1.9.1 upgrade not reading embedded artwork
lalinsky at gmail.com
Fri Oct 18 16:06:57 UTC 2013
Maybe the file is still open when you are trying to open it again for the
cover art. You should generally only open the file once, it has to read and
parse all the tags every time you open it. It's best to pass a FileRef
pointer to the extractEmbeddedArtwork object.
On Fri, Oct 18, 2013 at 3:57 PM, wifanlith <wifanlith at googlemail.com> wrote:
> I am not thinking its specific to the embedded artwork, but its how I
> noticed the change. I thought everything was working for 1.9.1, then I
> noticed that some of the albums I had imported had no artwork. It was only
> the albums that were mp3s with embedded artwork that had not had their
> artwork read.
> In the method that calls extractEmbeddedArtwork it calls the same code:-
> #ifdef Q_OS_WIN32
> // TAGLIB (under Windows) does not like UTF8
> paths/filenames with
> top-bit-set characters.
> // (conversion from UTF8 to const wchar_t seems to be the
> cause of the
> problem - file
> // is effectively not recognised as an audio file and will
> therefore not
> be loaded)
> TagLib::FileRef f(reinterpret_cast<const wchar_t
> // No such problem with UTF8 for Mac and Linux versions.
> TagLib::FileRef f(path.toUtf8().data());
> TagLib::Tag* tags = f.tag();
> TagLib::AudioProperties* ap = f.audioProperties();
> then extracts the artist/album/genre etc
> it then calls extractEmbedded artwork with the same QString path and calls
> the same fileRef on it, and comes up with the same file ref, and a
> FileRefPrivate, and the f.tag() call fails, and we return without gathering
> Unfortunately the UTF16 change had no effect.
> I am really confused....
> View this message in context:
> Sent from the taglib-devel mailing list archive at Nabble.com.
> taglib-devel mailing list
> taglib-devel at kde.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the taglib-devel