Changes to write ID3v2.3 tags and unsynchronization

Jonathan Potter listsub at
Sat Oct 24 01:12:59 CEST 2009


Patches are attached. To summarise the changes I've made:

1. id3v2.3 support

The default id3v2 version is set via the ID3DEFVERSION define. The basic
idea is:

- If ID3DEFVERSION is defined as 4, a version 4 tag will always be written -
this is the existing behaviour
- If ID3DEFVERSION is defined as 3, a version 3 tag will be written UNLESS
the file already had a version 4 tag, in which case the version 4 tag will
be preserved

When saving a version 3 tag, any version 4-specific frames will be converted
back to version 3 frames if possible - currently this only happens with the
TDRC frame which is converted back to TYER. If ID3VER3DUMPVER4TAGS is
defined then any version 4 frames which couldn't be converted will be
dropped from the tag.

Note that ID3DEFVERSION is currently defined twice, in id3v2frame.h and
id3v2header.h (this is due to the seeming lack of a common header file for
the whole project).

2. Unsynchronisation

- If ID3VER4UNSYNC is defined, unsynchronisation will be performed on a
per-frame basis if needed (when writing a version 4 tag)
- If ID3VER3UNSYNC is defined, unsynchronisation will be performed on a
whole-tag basis if needed 

Added a number of functions in id3v2synchdata.cpp to support this

3. Fixed (mostly by casting) some minor compile issues affecting Windows 

- A number of minor compile warnings from Visual Studio were fixed
- A number of x64 (64 bit) compile problems were also fixed

4. Added utility function in mpegfile.cpp (replaceFrame) to automatically
replace any existing frame(s) with a new one.

Please let me know if you have any questions about the changes I've made!


> -----Original Message-----
> From: mlrsmith at [mailto:mlrsmith at] On Behalf Of
> Michael Smith
> Sent: Friday, 23 October 2009 5:57 PM
> To: taglib-devel at
> Cc: jon at
> Subject: Re: Changes to write ID3v2.3 tags and unsynchronization
> I'd certainly be interested in that - I looked into what would be
> needed a while back, and it didn't look too hard - so please send your
> patches to the list! Some of us would certainly be interested in using
> it, even if Lukas doesn't think it's appropriate for upstream.

-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/x-zip-compressed
Size: 6558 bytes
Desc: not available
Url : 

More information about the taglib-devel mailing list