The getid3_write_id3v2::WriteID3v2() function calls getID3::analyze() to retrieve information about any ID3v2 tag that might already be present. If some error occurs while analyze()'ing the file, WriteID3v2() will continue to write a tag. I don't know how many cases might exist where this would be harmful, but there is at least one (set of cases) where this can lead to problems: If any modules are missing, for instance the apetag module, getID3::analyze() will fail and WriteID3v2() will still write a tag. If the given MP3 already contained an ID3v2 tag, then another will be written at the beginning of that MP3, leaving the file with multiple ID3v2 tags. (Some MP3 players seem to pick up the second ID3v2 tag, as well, strangely enough.)
There is no way to disable the module (e.g., apetag), because getid3_write_id3v2 instantiates its own instance of getID3. This could be solved with a patch similar to the one I posted at http://www.getid3.org/phpBB2/viewtopic.php?t=515. However, this time, I have taken a different approach: I have disabled the need for the option_tag_* flags; if the module isn't present (the file in the getid3 directory), then that tag type is considered disabled.
I also noticed that, when writing tags via getid3_writetags, getID3::analyze() will be called, potentially, multiple times; first by getid3_writetags, then by getid3_write_id3v2 and possibly others... (I did not bother to fix this, right now).
I've made a patch that will disable the need for the option_tag_* flags, and another patch that will make getid3_write_id3v2::WriteID3v2() check that getID3::analyze() succeeded before writing an ID3v2 tag (by checking the ['fileformat'] member). I can post these patches if you want them. I'm just not sure if this is how you care to handle the problem. It seemed like the easiest fix and will work okay for my purposes, though.
Think you found a bug in getID3()? Post here with details.
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 2 guests