R13.5 Bug - WMA->M4A changes some genre's case but not others

[chrisjj]

e.g. WMA:

M4A:

[Spoon]

Re: R13.5 Bug - WMA->M4A changes some genre's case but not others

There are 2 ways of storing Genre, one is a fixed list of names which match the id3v2 list, the other is a free form list of any values. So the first will be in this list of fixed names (ie the number 10 might be saved to represent Pop).

[chrisjj]

Re: R13.5 Bug - WMA->M4A changes some genre's case but not others

There are 2 ways of storing Genre, one is a fixed list of names which match the id3v2 list, the other is a free form list of any values. So the first will be in this list of fixed names

No. The first, "tango", is not in the IDv2 list. "Tango" is in this list, but that's not the name in the source file. dBpa is changing "tango" to "Tango".

[Spoon]

Re: R13.5 Bug - WMA->M4A changes some genre's case but not others

We are not going to change this, because the whole idea of mapping to the standard list is that it is case insensitive, it is how it is for mp3 id3 tags also.

[chrisjj]

Re: R13.5 Bug - WMA->M4A changes some genre's case but not others

We are not going to change this, because the whole idea of mapping to the standard list is that it is case insensitive

In ID3v2 you should not be mapping to a standard list anyway. Only ID3v1 requires a standard list.

The ID3v2 specification http://id3.org/id3v2.3.0 explicitly states that the user-defined values are supported. The current behaviour of dBpa fails to accord with that specification.

it is how it is for mp3 id3 tags also.

Actually not. dBpa does not suffer this problem on mp3 ID3 tags, e.g. http://i.imgur.com/yByL4AX.png .