FEB
21
2008

TagLib 1.5 Release

Submitted by Scott Wheeler

TagLib 1.5 is out.

As always, file any bug reports that you happen to run into in the bug tracker. As there are specifically a couple things that I intend to implement (wav / aiff support as well as support for ID3v2 tags in RIFF chunks) I expect a 1.5.1 (or 1.6) to be much faster in coming around this time.

I'd like to give a special thanks to Lukáš Lalinský for the numerous bug fixes, testing and new features, Urs Fleisch, Aaron VonderHaar for their ID3v2 frame implementations and of course Michael Pyne for helping keep the bug list in check.

Changes from 1.4 to 1.5

  • Support for Mac OS X and Microsoft Windows
  • Distributed under the MPL (in addition to the previous LGPL license)
  • Added support for Speex files
  • Added support for TrueAudio files
  • Added support for WavPack files
  • Added support for ID3v2 general encapsulated object frames
  • Added support for ID3v2 unsynchronized lyrics frames
  • Added support for ID3v2 URL frames
  • Propper exports of all public classes / functions
  • Updated the APE::Item API to work with value lists
  • Added support to the FileRef class for new Xiph (Ogg) extensions
  • Made the samples per frame for MPEG headers accessible
  • Made MP3 Xing headers accessible
  • Prevent invalid encodings from being written to ID3v1 tags
  • Non-Latin1 ID3v2 text frames are automatically converted to UTF-8 on write (if they are not explicitly set to UTF-16)
  • Added support for reading ID3v2.2/3 unsynchronized tags
  • Made it possible to search for ID3v2 comment frames by description
  • Fixed a number of bugs in ID3v2 relative volume adjustment reading and writing
  • Added work arounds for iTunes writing invalid ID3v2 frame lengths
  • Added work arounds for iTunes not being able to correctly parse numerical ID3v2 genres
  • Added work arounds for iTunes putting non-text information in ID3v2 comment frames
  • Added a function to export strings to std::wstring
  • Added a function to check ASCII compatibility of strings
  • Added a function to check Latin1 compatibility of strings

Comments

Well, you maybe don't want to hear anything about this anymore, still I would like to ask, if 1.5 changes anything on the behaviour of interpreting ID3v1 tags as Latin1 by default.

In the 1.4 API you write that when ID3 tags were invented Latin1 was chosen as encoding. I'm not that well informed on this issue but reading other sources I am told, that no encoding was enforced at all.

Do you have anything readable on this matter?

I know that 99% of western world doesn't give much about non Latin1, but there actually is a growing community of users not using this as their default encoding. Actually a lot of mp3s you get still come without ID3v2, so this *is* a issue.

Cheers,

chris

By chris11elf at Thu, 02/21/2008 - 19:54

It's not a matter of not caring, it's a matter of ID3v1 sucking. ID3v1 is not supposed to contain non-Latin1 text. Period. TagLib has had support for applications to override that since 1.4, but the default won't change.

Even if it were being considered there are two practical concerns which come into play: First, doing encoding detection on strings that are under 30 bytes is difficult. Especially when you consider that different tag strings may be in different encodings. Second, just supporting code-page-tables for the set of world-wide encodings would be a huge effort, not to mention that the character lookup tables would be bigger than the rest of TagLib. It's just not worth it to support non-standard-compliant behavior.

By Scott Wheeler at Thu, 02/21/2008 - 23:13

We love you wheels :) Last.fm uses taglib a lot. Almost everything I've ever worked on has used your wonderful library.

By mxcl at Fri, 02/22/2008 - 00:33

work fine, thx!

By paris hilton movie at Fri, 07/04/2008 - 19:46