You're talking about capitalization of the field names, not the contents of the fields themselves.
Standard ID3v2 tags don't
have field names like that. All fields are labeled with a 4-character Frame ID, which (
according to the standard):
The frame ID made out of the characters capital A-Z and 0-9.
So, written to disk, according to the standard, they don't look like that at all. The "Album" tag is called TALB, and Track Number is TRCK. For user-defined text fields, the identifier is TXXX and the frame contains a Description identifier that can be used as the name. This name can be of mixed case, but there are two considerations:
1. The Descriptions are case sensitive.
2. There can be multiple TXXX frames, but only one of each Description.
Common practice is to use all caps for Description names, because otherwise you could end up with two identically "named" custom TXXX fields, with "different" Descriptions (that are really just different in capitalization).
I think different applications do this different ways, but the vast majority use all caps, and it could be considered good practice to stick to one or the other (and fix any non-conforming tags you find and touch to prevent duplication issues as described above).
XIPH tags (for FLAC, OGG, etc) are, of course, different, and that appears to be what you're using here (based on the comment[] prefixes). The
VorbisComment spec specifies that the field names are case insensitive:
The field name is case-insensitive and may consist of ASCII 0x20 through 0x7D, 0x3D (’=’) excluded. ASCII 0x41 through 0x5A inclusive (characters A-Z) is to be considered equivalent to ASCII 0x61 through 0x7A inclusive (characters a-z).
So, while you can use lowercase letters, the spec says they are case insensitive, and says they are to be considered equivalent. Furthermore, if you read all of the documentation on XIPH, it is clear that the general practice recommended is to use all caps for field names, such as in the proposed minimal set of standard field names:
TITLE
Track/Work name
VERSION
The version field may be used to differentiate multiple versions of the same track title in a single collection. (e.g. remix info)
ALBUM
The collection name to which this track belongs
TRACKNUMBER
The track number of this piece if part of a specific larger collection or album
ARTIST
The artist generally considered responsible for the work. In popular music this is usually the performing band or singer. For classical music it would be the composer. For an audio book it would be the author of the original text.
PERFORMER
The artist(s) who performed the work. In classical music this would be the conductor, orchestra, soloists. In an audio book it would be the actor who did the reading. In popular music this is typically the same as the ARTIST and is omitted.
COPYRIGHT
Copyright attribution, e.g., '2001 Nobody's Band' or '1999 Jack Moffitt'
LICENSE
License information, eg, 'All Rights Reserved', 'Any Use Permitted', a URL to a license such as a Creative Commons license ("www.creativecommons.org/blahblah/license.html") or the EFF Open Audio License ('distributed under the terms of the Open Audio License. see http://www.eff.org/IP/Open_licenses/eff_oal.html for details'), etc.
ORGANIZATION
Name of the organization producing the track (i.e. the 'record label')
DESCRIPTION
A short text description of the contents
GENRE
A short text indication of music genre
DATE
Date the track was recorded
LOCATION
Location where track was recorded
CONTACT
Contact information for the creators or distributors of the track. This could be a URL, an email address, the physical address of the producing label.
ISRC
ISRC number for the track; see the ISRC intro page for more information on ISRC numbers.
That is not accidental. Throughout the XIPH documentation, field names are
always presented in all caps, and those specific fields are "officially designated". The
recommendations for VorbisComment documentdoesn't really address this directly, but even there, all of the field names and proposed field names are shown in all caps. I think MC is doing the sensible thing here with the tags, and whatever "standard" you are following with yours is "wrong" (certainly one you made up yourself). Of course, you are free to do what you'd like (VorbisComments are designed to be free-form, after all), but that's
why MC is doing what it is doing with regards to that.
I'm not sure about the reasons it might be re-ordering them. That might be something it does to preserve compatibility with a flaky 3rd party application, or it might be to make re-writing them more efficient in the future, or it might just not be very careful about it. Matt or someone who knows the ins/outs of Vorbis tagging would probably need to comment here.
