taglib-devel Digest, Vol 134, Issue 2

Priya Krishnan priya.salman at gmail.com
Wed Dec 9 17:55:51 UTC 2015 

How to read the specified tag like album , or original artist,original
lyricst etc..

i need to how to set and get for the above tags.


On Wed, Dec 9, 2015 at 5:30 PM, <taglib-devel-request at kde.org> wrote:

> Send taglib-devel mailing list submissions to
>         taglib-devel at kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.kde.org/mailman/listinfo/taglib-devel
> or, via email, send a message with subject or body 'help' to
>         taglib-devel-request at kde.org
>
> You can reach the person managing the list at
>         taglib-devel-owner at kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of taglib-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: Problems after Update on taglib-1.10-1 (Urs Fleisch)
>    2. Re: Problems after Update on taglib-1.10-1 (Tsuda Kageyu)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 8 Dec 2015 22:07:08 +0100
> From: Urs Fleisch <urs.fleisch at gmail.com>
> To: taglib-devel at kde.org
> Subject: Re: Problems after Update on taglib-1.10-1
> Message-ID:
>         <CAAekg=WU=
> CGpmiYqrpiG1h-y8dXes6dzBctscLVRHAt5ynoU8g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I can confirm these problems on Arch Linux. I have tested it with kid3. If
> I use kid3 3.3.0-3, which was built against TagLib 1.9.1, and currently
> dynamically links to TagLib 1.10 on Arch Linux, I have the same situation:
> Saved tags are stored with wrong characters. If I build kid3 against TagLib
> 1.10, the problems disappear. As Walter Schineis reported, the problems are
> solved when downgrading to TagLib 1.9.1. This looks like a binary
> incompatibility between the two versions.
>
> I have used abi-compliance-checker and found the following:
>
> In TagLib 1.9.1, we had the following
>
>     String(const wstring &s, Type t = WCharByteOrder);
>     String(const wchar_t *s, Type t = WCharByteOrder);
>
> where WCharByteOrder is a private static const String::Type, which will be
> initialized to UTF16LE on little endian systems (as most of our PCs are).
>
> In TagLib 1.10 we have
>
>     String(const wstring &s, Type t = UTF16BE);
>     String(const wchar_t *s, Type t = UTF16BE);
>
> with a default of UTF16BE. The default encoding seems to have changed from
> UTF16LE to UTF16BE. If a program is built against TagLib 1.9.1 and uses one
> of these String constructors with a default parameter for the type, the
> compiler will assign the value of WCharByteOrder (which still exists in
> TagLib 1.10 and is still UTF16LE) to the type parameter. The code in the
> constructor in TagLib 1.10 now tries to do something for compatibility with
> TagLib 1.8 (had same signatures for these constructors as TagLib 1.10), but
> this will fail if the application was linked against TagLib 1.9.1.
>
> So it seems that TagLib 1.10 is compatible with TagLib 1.8, but not with
> TagLib 1.9. The ChangeLog contains
>
>     Fixed backwards-incompatible change in TagLib::String when constructing
> UTF16 strings.
>
> It seems that applications linked against TagLib 1.9 have to be recompiled.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.kde.org/pipermail/taglib-devel/attachments/20151208/19a62000/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 9 Dec 2015 09:33:39 +0900
> From: Tsuda Kageyu <tsuda.kageyu at gmail.com>
> To: "taglib-devel at kde.org" <taglib-devel at kde.org>
> Subject: Re: Problems after Update on taglib-1.10-1
> Message-ID:
>         <
> CAG4hMGd8TuRPpnNYATe7S63m0yTWwW-+PHyN512rOg7Fdx0UPg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Urs,
>
> The parameter UTF16BE and UTF16LE are somewhat confusing. Unlike their
> name, UTF16BE means "the system byte order" and UTF16LE means "contrary to
> the system byte order" in TagLib 1.8 and 1.10. I introduced WCharByteOrder
> in v1.9 to straighten it out, but it caused some binary incomatibility
> between v1.8 and v1.9, so we reverted it in v1.10.
>
> Privately, I think that either way (keep the compatibility with v1.8 or
> v1.9) is logical accordingly. v1.9 is not compatible with older versions,
> but has been used for a long time...
>
> Regards,
> Kageyu
>
> 2015-12-09 6:07 GMT+09:00 Urs Fleisch <urs.fleisch at gmail.com>:
>
> > I can confirm these problems on Arch Linux. I have tested it with kid3.
> If
> > I use kid3 3.3.0-3, which was built against TagLib 1.9.1, and currently
> > dynamically links to TagLib 1.10 on Arch Linux, I have the same
> situation:
> > Saved tags are stored with wrong characters. If I build kid3 against
> TagLib
> > 1.10, the problems disappear. As Walter Schineis reported, the problems
> are
> > solved when downgrading to TagLib 1.9.1. This looks like a binary
> > incompatibility between the two versions.
> >
> > I have used abi-compliance-checker and found the following:
> >
> > In TagLib 1.9.1, we had the following
> >
> >     String(const wstring &s, Type t = WCharByteOrder);
> >     String(const wchar_t *s, Type t = WCharByteOrder);
> >
> > where WCharByteOrder is a private static const String::Type, which will
> be
> > initialized to UTF16LE on little endian systems (as most of our PCs are).
> >
> > In TagLib 1.10 we have
> >
> >     String(const wstring &s, Type t = UTF16BE);
> >     String(const wchar_t *s, Type t = UTF16BE);
> >
> > with a default of UTF16BE. The default encoding seems to have changed
> from
> > UTF16LE to UTF16BE. If a program is built against TagLib 1.9.1 and uses
> one
> > of these String constructors with a default parameter for the type, the
> > compiler will assign the value of WCharByteOrder (which still exists in
> > TagLib 1.10 and is still UTF16LE) to the type parameter. The code in the
> > constructor in TagLib 1.10 now tries to do something for compatibility
> with
> > TagLib 1.8 (had same signatures for these constructors as TagLib 1.10),
> but
> > this will fail if the application was linked against TagLib 1.9.1.
> >
> > So it seems that TagLib 1.10 is compatible with TagLib 1.8, but not with
> > TagLib 1.9. The ChangeLog contains
> >
> >     Fixed backwards-incompatible change in TagLib::String when
> > constructing UTF16 strings.
> >
> > It seems that applications linked against TagLib 1.9 have to be
> recompiled.
> >
> > _______________________________________________
> > 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/20151209/eed47fe2/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel
>
>
> ------------------------------
>
> End of taglib-devel Digest, Vol 134, Issue 2
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20151209/df31a18f/attachment.html>

More information about the taglib-devel mailing list