When I use the masstagger, edit values manually or delete tag fields in MP3 files all the values in the different tag fields get replaced by unknown characters or question marks. It doesn't matter if I update only one field or multiple.
After altering a value manually and saving it I do get a notification that the tag is stored successfully.

If I alter OGG files everything is ok.

I checked using the "Reload info from file(s)" option, using Winamp2 and Tag&Rename2.

"MP3 tag writing" is set to "ID3v2".
Tested using the ID3v2 plugin version 1.05 and 1.06.
Using foobar2000 version 0.7.2.
OS Win2000

I unloaded 2 files one with the altered tag and one with the tag values stored propperly but who get f*cked up after changing as well.

Altered with wrong values:
http://allard.student.utwente.nl/~tijmen2/...0-%20Adouma.mp3
Propper values:
http://allard.student.utwente.nl/~tijmen2/...20Of%20Love.mp3

God damnit, ID3v2 sucks.

WMP, Winamp, and dBPowerAMP, along with many, many players that support UTF-16 ID3v2 tags, don't like it if I include a byte order marker (BOM) in the string. (As the standard specifies.)

iPod (or is it iTunes?) requires it.

The specification also includes a means of indicating the endianness of the UTF-16 strings in the text encoding field, but one would gather from id3lib that this indicator is not used/supported. ID3lib ignores it, relying solely on the BOM.

Writing without BOM becomes confusing.

WMP and Winamp expect the strings to be little-endian. dBPowerAMP expects them to be big-endian.

This is all with the encoding type of ID3TE_UTF16, not ID3TE_UTF16BE.

So, we have conflicting software expecting different byte orderings with nobody supporting the simplest mechanism for detecting the true byte order.

Therefore, ID3v2 sucks because the majority of software which supports it does so in a manner inconsistent with the standard. Hell, inconsistent with other pieces of software also breaking the standard in their own unique ways.

Oh, hell, screw dbpa. I've changed it to write little-endian Unicode strings when excluding the BOM. EDIT: And now it will write little-endian with BOM. Doesn't seem to fix dbpa reading, and it causes WMP to spit out this error: "Windows Media Player cannot find the specified file."

Maybe you should just turn off Unicode support and use ISO-8859-1. Or hell, ANSI, since every other piece of software supports ID3TE_ISO8859_1 as ANSI.


Incidentally, I switched to UTF-16 from UTF-8 because officially, UTF-8 is only supported by ID3v2.4.0, which almost nothing supports.

Yup. I've only seen ID3v2.4.0 support in Winamp 5 beta so far.

...it might be me being plain stupid...but foobar doesn't support it correctly eighter.
It's ok n the database but it didn't retreive the info correcty from the file again.
Please correct me if I'm wrong.

I realy understand your frustrations, and I would do anything to get of your back about ID3v2 errors.
I'm trying to spread the web standard "gospel" as much as possible because of all the bad implementations by different browsers and in a lot of cases there is no propper and clean way if creating something which will work in multiple browsers correctly.

Anyway, on topic again:
If there's a good alternative for ID3v2 I will drop the use of this standard immediately. The only reaon I started using the ID3v2 tags was because of it's long value support so if something else will do the trick I'm just as happy. As far as I know there isn't an alternative for me to use which will work in the applications I use or might start using in the future.



Like I said, I'm happy if it works the way it should be and applications support it.
I must admit I'm not very familiar with all this Unicode, ISO-8859-1, ANSI stuff.
Can you tell me if switching to e.g. ID3TE_ISO8859_1 will have unwanted effects or consequences in what ever way possible?

I am trying to follow everyone else's behavior, which is nearly impossible if nobody does things consistently.

The tags written with 1.06 without BOM are now broken, you have to recreate them.

Well, with that, things are a little different. You can design a server-side script to feed the right quirks to the correct browser, or in-page script which adjusts the page in the same way.

I suppose I could document presets for each known application, but that's still kludgy.


APEv2 is an excellent replacement, if everyone would support it. There is only one encoding to deal with: UTF-8.


ISO-8859-1 is the only "ANSI" type encoding supported by ID3v2. Using ISO-8859-1 properly follows the standard, but does not support most local codepage specific characters. Most players just write text in your local codepage and indicate the encoding is ID3TE_ISO8859_1, and read ID3TE_ISO8859_1 as if it is encoded with your local codepage. Check the third option in preferences to read and write tags like this.