D13700: implement reading of the replaygain tags

[Alexander Stippich]

astippich added inline comments.

INLINE COMMENTS

> bruns wrote in taglibextractor.cpp:50
> This is definitely broken:
> http://taglib.org/api/classTagLib_1_1String.html#a0ef8ad270d710863e0bb1c1b18cdb95d
> 
> `const wchar_t* TagLib::String::toCWString 	() 	const`
> 
> > Returns a standard C-style (null-terminated) wide character version of this String. The returned string is encoded in UTF-16 (without BOM/CPU byte order), not UTF-32 even if wchar_t is 32-bit wide.
> 
> https://github.com/qt/qtbase/blob/c5307203f5c0b0e588cc93e70764c090dd4c2ce0/src/corelib/tools/qstring.h#L1027
> 
>   inline QString QString::fromWCharArray(const wchar_t *string, int size)
>   {
>       return sizeof(wchar_t) == sizeof(QChar) ? fromUtf16(reinterpret_cast<const ushort *>(string), size)
>                                               : fromUcs4(reinterpret_cast<const uint *>(string), size);
>   }
> 
> Fortunately, platforms with wchar_t == wchar32_t are uncommon ...

This is used throughout the taglibextractor and should then be corrected everywhere in a different patch imho.

> bruns wrote in taglibextractor.cpp:249
> Maybe better `// Check if there are any User Text Identification Frames (TXXX) at all`
> Technically, the `UserTextIdentificationFrame::find(...)` below would be sufficient to lookup the tags.

You're right, the idea was to skip the calls to the replaygain tags if there aren't any TXXX tags

REPOSITORY
  R286 KFileMetaData

REVISION DETAIL
  https://phabricator.kde.org/D13700

To: astippich, mgallien, bruns
Cc: kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, astippich, spoorun, ngraham, bruns, abrahams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180906/0c7569f3/attachment-0001.html>