Cyrillics detect fix about getid3 HOT 8 CLOSED

I made some fixes (including your suggestion) in 7c7eb57

But don't expect perfection if the input file is broken. For example, using your sample file the ID3v1 displays (mostly) correctly now, but the ID3v2 is broken because the tags are written in CP1251 but the tag is encoded as ISO-8859-1, which is wrong. You should retag your files with a multi-byte-encoding aware tagger (which should be pretty much anything) so that the ID3v2 tag is written as UTF-8 (or UTF-16 if you prefer).

from getid3.

Thanks for the fixes. But you know, there are tons of music encoded this way, I saw enough examples. What do you think, may be it's safe to expand this hack to id3-v2 tags as well? Cause using cp1251 in id3-v1 is kind of a violation too..

from getid3.

No, it will not be expanded to ID3v2.
ID3v1 doesn't have any mechanism for specifying character sets, and there was no alternative before ID3v2 was introduced, so the spec violation is unfortunate but understandable.
There is no excuse for using the wrong encoding in ID3v2.

from getid3.

I see, but usually users don't care about such matters (they just have their mp3s and want them ok) and I suppose we'll never find (and punch) people who produce such kind of id3-v2 tags... May be some switch then? Let's say... if (id3v1==true or crazyRussians==true) then {...check_1251...}

from getid3.

I'll leave that to the getID3 user if they want to second-guess the specified tag encoding and juggle things around with iconv or mb_convert_encoding.

from getid3.

Ok, one more question. Did you try the new version with that 3 test tracks? How many correct do you have? My friend says that with new version of getid3.php his project now does not recognize cyrillics. There was 1 track of 3 recognized before and 0/3 after. That's a bit strange, cause the old version plus that new regexp shows 3/3...

from getid3.

ID3v1 is automatically interpreted as Windows-1251
ID3v2 treated as ISO-8859-1 because that's the encoding the ID3v2 tag claims to be in.
The [comments] key will generally be returned with ID3v2 data overriding equivalent ID3v1 data.
If you have a lot of these broken files with CP1251 encoding you may want to access [tags][id3v1] instead of [comments].

from getid3.

Yeah, I guessed that may be id v2 overriding... It's clear now, thanks.

from getid3.