In writing out tags to a file I had trouble reading them back in using iTunes. I'm not EXACTLY sure why, but when I compared the id3v2.4 tags that iTunes generates vs. libid3tag, I found that libid3tag defaults to always using an extended tag header and writing out a CRC for each tag?? I'm not exactly sure what I'm talking about because I can't get to id3.org to get the latest spec, but that's another story.
To fix it, I had to comment out everything in the "tag->options = " line in id3_tag_new, i.e., zeroing out the compression and CRC options. This prevented the extended header from being generated and it prevented the longer header from being generated on each tag.
However, I know I'm disabling something that could be useful. Does anyone have any insight into this? I'd rather not flat out disable a feature in this lib.
On Tuesday, October 1, 2002, at 01:41 PM, Mark Malson wrote:
In writing out tags to a file I had trouble reading them back in using iTunes. I'm not EXACTLY sure why, but when I compared the id3v2.4 tags that iTunes generates vs. libid3tag, I found that libid3tag defaults to always using an extended tag header and writing out a CRC for each tag?? I'm not exactly sure what I'm talking about because I can't get to id3.org to get the latest spec, but that's another story.
To fix it, I had to comment out everything in the "tag->options = " line in id3_tag_new, i.e., zeroing out the compression and CRC options. This prevented the extended header from being generated and it prevented the longer header from being generated on each tag.
However, I know I'm disabling something that could be useful. Does anyone have any insight into this? I'd rather not flat out disable a feature in this lib.
The default behavior of libid3tag is to compress tag frames if it makes them smaller. Tag CRCs are also included by default. Compression is a mandatory feature of ID3v2, so I think any implementation that can't read compressed tags or the extended header is non-conforming.
In any case, you can modify tag->options to eliminate the compression and/or CRC options. You can do this in your own code after creating the tag with id3_tag_new(); you don't have to modify the library.
The next release of the library will contain an id3_tag_options() API to do this without mucking with the structure elements directly.
Rob, thanks for getting back with me.
On 10/8/02 12:38 AM, "Rob Leslie" rob@mars.org wrote:
The default behavior of libid3tag is to compress tag frames if it makes them smaller. Tag CRCs are also included by default. Compression is a mandatory feature of ID3v2, so I think any implementation that can't read compressed tags or the extended header is non-conforming.
Yes - I'm a little surprised that iTunes appears to be non-conforming to quite a few id3v2.4 things. It seems to be unable to handle compression, nor any data length indicator on a frame. I have submitted a bug report to Apple but so far they are largely unresponsive.
In any case, you can modify tag->options to eliminate the compression and/or CRC options. You can do this in your own code after creating the tag with id3_tag_new(); you don't have to modify the library.
For the edification of the readers of archives of this list, here is a code snippet that I added to my app (after restoring the library to its original state):
fTags = id3_file_tag(fId3File);
/* ** These things are all here because iTunes can't handle some things */ // Clear these flags because iTunes can't handle them fTags->options &= ~ID3_TAG_OPTION_COMPRESSION; fTags->options &= ~ID3_TAG_OPTION_CRC;
for (i=0; ; i++) { struct id3_frame *frame;
if ((frame = id3_tag_findframe (fTags, nil, i)) == nil) break; frame->flags &= ~ID3_FRAME_FLAG_DATALENGTHINDICATOR; frame->flags &= ~ID3_FRAME_FLAG_ENCRYPTION; frame->flags &= ~ID3_FRAME_FLAG_COMPRESSION; }
The next release of the library will contain an id3_tag_options() API to do this without mucking with the structure elements directly.
That would be great...
- Mark Malson
That would be great - might I also suggest a tag option that