album art in id3 causes improper read

hateeecs · 09-04-2005, 08:41 AM

I save album art in id3v2 tags so that they can be displayed in applications like this. Not only does this program not use album art (i'll have more about this in a feature request) such information appears to cause the id3 reading code in centrafuse to fail.

With album art present, I get around three scrambled characters for album artist. When I go back and remove the album art from the id3 tag, rebuild the library, the information appears correctly.

Thanks,
-Chris

veetid · 09-04-2005, 01:40 PM

I do not currently support album art inside id3 tags...

david

frodobaggins · 09-04-2005, 02:44 PM

But you shouldn't have errors when it exists...

hateeecs · 09-04-2005, 02:55 PM

Quote: Originally Posted by frodobaggins

But you shouldn't have errors when it exists...

Exactly. There is a big difference between not supporting someting and having the existance of valid information cause problems.

However, upon doing more investigation, it would appear that there is something wrong with my source files. They are currently being tagged with a python script of my creation. If i go back in and modify the id3 tags in a 3rd party tagging software they appear correctly when i rebuild.

It should also be noted that these source files to appear correctly in the tagging software, windows explorer (id3 tag view), winamp, etc - so I am at a bit of a loss as to what the problem here is.

With RR i get three strange characters followed by the artist / track. In Centrafuse i get just the three strange characters. I'm going to try playing around with my script and report back.

veetid · 09-04-2005, 03:16 PM

I agree that it shouldn't cause errors... The files I have with images in the id3 tags seem to load fine...

let me know what you find out...

david

hateeecs · 09-05-2005, 11:21 AM

well looking into this more it would appear that this may be caused by unicode strings. Like I said earlier, I'm using python and the library i'm using seems to force the strings into unicode regardless of what I pass into the .set_text method.

But I have verified that working id3 information appears as

'string'

and my garbled stuff appears as

u'string'\x00

Which means unicode string with \x00 termination sequence. I have put an email into the library author to see what they thing about making a switch or something so I can still use my scripts.

veetid · 09-05-2005, 02:32 PM

that would make since... 1.4 has some unicode issues... I am trying to work them out in 1.5...

david

hateeecs · 09-06-2005, 07:03 AM

media engine = strange characters
frodoplayer = works

veetid · 09-06-2005, 12:12 PM

it's just that your script is writing the tags in unicode... if you get something, many many options, that will write the tags not in unicode it will work... I am working to solve my unicode tag problems...

david

hateeecs · 09-06-2005, 12:34 PM

Quote: Originally Posted by veetid

it's just that your script is writing the tags in unicode... if you get something, many many options, that will write the tags not in unicode it will work... I am working to solve my unicode tag problems...

david

I believe it is my id3 library that is writing the tags using unicode strings. This is the only library thus far that allows me to write id3v2 tags with album art successfully. I'd really like to keep writing id3v2 with album art going foward.

On my side of the script i tried to decode the unicode strings to ascii and to chop off the termination by doing the following in python.

mystring = 'blah'
mystring.encode('ascii')[0:-1]

But i just passed this string into the library function
someid3frame.set_text(mystring)

And the unicode/termination appears again. So I think that this is beyond my control for this library. Hopefully the library author will get back to me soon.

-Chris