License and Copyright
Do notice that I proposed a simpler standard for those two tags a couple of months ago.
- COPYRIGHT = Name of Entity (e.g. Xiph.Org Foundation)
- Should be renamed ‘RIGHTS’ (as proposed on the wiki page). Copyright... Well. It is not nice. We are talking about Distribution rights, anyways...
- LICENSE = Link to license, only URI/IRIs allowed ( e.g. http://creativecommons.org/licenses/by/3.0/ )
- But it lacks a way to determine machine readable date of rights. Such as with RIGHTS-DATE.
This makes it simple for both users and machines to understand the data.
--Ivo 16:33, 13 September 2007 (PDT)
Comments by Ijabz
The following was added by Ijabz on October 18, 2007
I really like VorbisComments because in contrast with other metadata formats (e.g ID3,MP4 metadata) it is very simple to develop a programing interface, you can treat every field as a simple name value pair without breaking anything, if a field value is formatted in a special way to aid machine parsing but your program doesnt know about it thats ok it wont break. Having seen how long it has taken for ID3v2.4 to be adopted I think Xiph would do better to improve VorbisComment (without breaking backwards compatability) rather than provide alternatives.
It only really has three drawbacks:
1. The list of official fields is too small, we need a definitive list of offical fields now that is much larger than it is now. These fields are not mandatory so I cant see any drawback in extending this list, but there seems to be a reluctance to actually do it. A reasonable approach would be to look at the list of defined frames in ID3 and provide vorbis equivalents where possible. Should also consider adding the list of tags added by the Musicbrainz project, seeing as they are an opensource not for profit organisation whose main aim is to improve the quality of infdormation about recordings they appear to be a prefect partner.
2. VorbisComments do not provide support for binary data, and when anybody mentions this it is explained that the data should be added as a seperate multiplexed stream. I dont understand this solution and Im not aware of any applications that actually do this so even if I implemented support for it in one program it would be of limited use. The most important binary data for audio files is cover art images and without support for these OggVorbis is at a serious disadvantage. Audioshell implements it by base64 encoding the image, this seems a perfectly sensible solution that would be easy to implement, and would work for any binary data.
3. VorbisComments do make it more difficult to show complex relationships and an XML format would proably be better as expressing these. However if a relatiuonship is complex it is probably too complex to be of much interest to anybody, however it can still be done using Vorbis Comment. For example the following example is given within the Metadata wiki page:
How do you indicate which artist played tenor sax in the solo?
This is a very specific request, but could be done by adding a subfield character (Ive used a colon in this example) allowing machine parsing of related attributes
Or you could amend the Fieldname so it supported a way of linking fields,e.g:
ARTIST-1:fred ARTIST-2:jane INSTRUMENT-1:tenorsaxophone MUSICPASSAGE-1:solo
so the rule is if a field ends with (-n) all fields ending with the same value of n are linked, I dont see how this breaks things
Moved from article as it is not a good idea. The section was added by Aleksandersen on September 13, 2007
The goal is to be offer better support for more languages and make machine processing faster.
The specification should be a little more strict to achieve this.
Field names may be UTF-8 and all UPPERCASE for easier machine processing.
Allowing tag names to be UTF-8 instead of ASCII is a backwards-incompatible spec change. If we did this, requiring that the case mapping happen in the tagging application rather than in decoders is reasonable, since case mapping in unicode is non-trival.
The original argument for ASCII was that we need standardized tag names for interoperability, so there's no point in being able to localize them, and we might as well go with our native prejudice. Localizing the values should be done by appending a language code to the tag, since this is both machinable and there may be collisions between translated tag names.
- UTF-8 is a bad idea in field names. The field names are for machine interpretation, localisation should be done on the software side. UTF-8 introduces matching problems (canonical form) and encoding/decoding problems (difficulty in finding length of a string). Please sign comments; I think the above is a cumulative set of comments, but no idea.--Imalone 01:11, 17 September 2007 (PDT)