Changes to write ID3v2.3 tags and unsynchronization
listsub at lss.com.au
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
- 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
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).
- 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 gmail.com [mailto:mlrsmith at gmail.com] On Behalf Of
> Michael Smith
> Sent: Friday, 23 October 2009 5:57 PM
> To: taglib-devel at kde.org
> Cc: jon at gpsoft.com.au
> 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...
Size: 6558 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20091024/c041a690/attachment.bin
More information about the taglib-devel