I\'m using CVS + gstreamer.

You\'re probably aware of this... but...

Reading UTF8 tags seems to work ... however writing them (storing them after changes) does not. I\'m begining to think this might be a wider problem with the id3lib stuff because no linux program seems to do this correctly. An experience with constantly expanding tag length in easytag made me think the UTF pre-text post-text bits were being constantly doubled up. Not sure if that could be happening here.

I have gotten Amarok to read UTF tags from files written through windows programs.

I\'m using the locale ja_JP.UTF-8

BTW, I have been nothing but impressed with Amarok it puts other linux media players to shame.

- Ben

Yes, you have come to the point we all came:
ID3v2 support in amaroK is completely fcked up. However, the whole ID3v2 and every piece of software, so this is excuse.

1) ID3v2 standard says \'There should be only Unicode or Latin1 in ID3v2 tags.\'
2) Every program, including id3lib and winamp happily write ID3v2 in random encodings like cp-1251. So, basically, everyone violates standard.
3) amaroK, as last rhythmbox, are trying to obey standard. Result - They can\'t properly show ID3v2, noone can see their ID3v2\'s.
4) They BOTH have one work-aroud turned on. Interpret tags as latin-1 always. So, europe gets their stupid cockroach umlauts, everyone else __gets a ****: even if your tags are 100% standard and amaroK compliant, you will get garbage if they are in unicode. You will have to dig some src (trivial) and rebuild.
5) TagLib author was aware that ID3v1 tags may be not only in latin1. He made reconverting possible, for what we are grateful. He DID NOT KNEW that ID3v2 have same problem. Even more, he looked really surprised when i told him.
6) Everyone either points everyone else and say \'it is he who is guilty, not me\'. Or just ignore standards, encodings, linux, etc. As good, happy, kind idiot would be, of course.

Taking this all into account. We have a patch to TagLib and amaroK that makes it use ID3v1 first! If they are present.
And ID3v1 DO have chrset selection!
So this work really sweet.
But we are Russian users and have cp-1251 as tags codings and koi8-r locales. Your mileage may vary as your tags might rarely fit into ID3v1 tags, \'cause multibyte.

P.S. Additions and suggestions are welcome.
P.P.S. ilyak AT online DOT ru.

Frankly we don\'t really understand all this stuff properly, it\'s been fixed and broken many times. We want to fix it honest. We will try. Patches would REALLY help though.

I understand, but it is the TagLib author who should fix, not you:

Ideally, this would be, on prefs screen:

ID3v1 Encoding:

ID3v2 Encoding:
(*) Use Unicode
( ) Use encoding (violates standard):

Now only 1st setting is present, which is bad.

But implementing it without taglib support would be quite a hack.

well, that\'s not the way id3v2 works. it\'s utf only, and there is no need for such an option, imho. if there are tags inside id3v2 which are stored in some different locale, then it\'s a bug of the program which wrote these tags.

...muesli

Well. I have a id3v2 console util, WinAmp, Microsoft Windows Media writing such tags.

I guess they may all not obey standard, but this is reality - everyone cares stat music sould work on these

May be i look wrong at problem. I can mail you mp3 that works in lotsa players but displays garbage with amaroK.


So, we do *really* need options i show you.

And, anyway *AMAROK DO NOT HAVE UTF-8 ID3v2 TURNED ON*.
So, if you are not latin1/iso-foo-1 guy, bad luck for you whatever tags do you use.

Although locale selection may be a nice option, i agree that UTF8 is an ideal solution. Still the problem seems to be that Amarok reads UTF8 tags fine but doesn\'t write them correctly. Not sure how to explain the problem any better but ... someone could try pasting:

猫になりたい

into the track field of an MP3 and saving the tag. Reload the collection. Assuming you could see the japanese text correctly in the first place (*should* be UTF in the msg) after reloading the field will now be gibberish (or it is for me at least).

Be happy to help with this in any way I can ... I can look into the code but am not the best C programmer.

- Ben

I\'m very confused about those tags. I tried to tag a file with id3tag, using utf8 encoding. Amarok doesn\'t show the tags correctly, but instead displays weird characters. I also tried to record only v1 or v2 tags but none worked for me.
As discussion showed some people could read utf8-tags. Am I doing something wrong?

With amaroK 1.4 it's all even worse!

I used to setup amaroK 1.3.x so that ID3v1 encoding defaults to cp1251, while ID3v2 is still unicode. Now in 1.4 it's impossible. More of a problem, you can't even say, which ID3 version a file uses, when you try to edit some tag!

Just a pure example: I take a file with ID3v1 tags only, and the tags are encoded in cp1251. amaroK displays them wrong (why?), and I try to edit them. I put the proper characters (non-latin) in the tags, and save the file. Now, do you think amaroK has written some ID3v2 tag? Hell no! It has written ID3v1 again, in UTF-8. Let's try to open the same file again, what we see? Garbage in tags, again!!!

I EDIT THE TAGS WITH AMAROK ITSELF, AND AMAROK ITSELF DOES NOT DISPLAY THEM CORRECTLY AGAN!!!

What the hell?

It appears that after a year it still has this problem

thats the thing I hate about community based software
you (developers) ahve a bunch of ppl here, which are keeping telling you, that the 1.3.x option of selecting the charset was of great help, and in response they have "retag the files!, use idv3!, convert to utf!", or whatever else... but not the "ok, will bring it back"

instead of that you just lock the topics on the forum because some greek guy goes crazy without seeing his lovely song titles.

Personally I have about 10G of cp1251 id3v1 only tagged files, and it will take for me about an hour or two to write a perl progyy that will the job (god bless CPAN),  but is it fair? I do not think so.

I'm really disappointed about problem with id3v1...
I edit mp3 tags (non-latin characters) and save file with Amarok, but it also has written ID3v1 with UTF-8 encoding. That is wrong! If new versions of Amarok does not support for custom character encoding at id3v1 then Amarok should leave id3v1 tags unchanged.

Amarok 1.4.1beta1
Sorry for my bad english.