Have compiled id3lib 3.8.3 using the tip from:
<https://sourceforge.net/mailarchive/forum.php?thread_id=1169849&forum_id=5794>
Couldn't get it to compile otherwise.
Also added the following code to demo_convert.cpp to get it to run without hanging (see: <http://sourceforge.net/mailarchive/forum.php?thread_id=1422207&forum_id=5794> for further details):
[CODE]
#include "id3/utils.h"
#include "id3/misc_support.h"
#include "id3/readers.h"
#include "id3/io_helpers.h"
using namespace dami;
void never_called_but_needed(const ID3_Tag &myTag)
{
ID3_Tag::ConstIterator* iter = myTag.CreateIterator();
const ID3_Frame* frame = NULL;
while (NULL != (frame = iter->GetNext()))
{
ID3_Field* fld = frame->GetField(ID3FN_DATA);
ID3_MemoryReader mr(fld->GetRawBinary(), fld->BinSize());
}
}
[/CODE]
After successfully compiling id3convert is the examples directory, running it to strip tags like so:
./id3convert -s myfile.mp3
myfile.mp3 afterwards ends up with a file size of 4294965247 bytes!
I've tried this on all varying types of mp3s, and it happens on all of the ones with ID3v1 tags.
I've tried to look through the code and the best I can tell is after getting the genre in tag_parse_v1.cpp, something gets mixed up, and wr.getCur() in tag_parse.cpp has the value 0xFFFFFFFF, which then gives _appended_bytes the value 0xFFFFFFFF, which is obviously wrong.
This never used to happen in 3.8.2, so I thought I'd go back and try to compile 3.8.2 instead, but now the same thing happens with that, too. So now it looks like Apple has screwed something up.
I'm using Mac OS X 10.2.4, Dec 2002 Dev Tools.
It's look like I might need to upgrade the compiler on my own. I'd rather not do that if a simple fix could be made to id3lib.
If I do need to do that, does anyone have any idea how I go about doing that?
Thanks,
Bob Maguire
