Talk:VorbisComment

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... Added by Aleksandersen on October 3, 2007

• 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. Added by Aleksandersen on October 3, 2007

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 I'm 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 VorbisComment. 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 (I've used a colon in this example) allowing machine parsing of related attributes

ARTIST_INSTRUMENT_MUSICALPASSAGE="fred:tenorsaxophone:solo"

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

On drawback 2, VorbisComments were designed to be text-only. As you point out, the intention was to put binary data in a separate logical bitstream. Unfortunately, at the moment, adding such a stream to an Ogg container breaks many players. An initiative is in progress to address this using Ogg Skeleton. As for cover art, there is now such a proposal using the VorbisComment tag METADATA_BLOCK_PICTURE.

On drawback 3, VorbisComments are inherently unstructured. For complex relationships, it would be better to use a system which has built-in structure such as XML. Multimedia Metadata Format (M3F) is such a draft proposal.

Martin Leese 19:52, 1 July 2009 (PDT)

Character encoding

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.

Proposals

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)

Attributing involved parties

Moved from article as it is not the consensus view. The section was added by Aleksandersen on September 13, 2007

The goal is to attribute more persons and organisations involved in audio and music productions to make room for more advanced search and sorting.

NO PROPOSALS! VorbisComments need a lot of extension beyond just the ARTIST field name. See work at Multimedia Metadata Format (M3F), the proposed XML replacement for VorbisComments for structured metadata.

Proposal: Adding embedded Lyrics field

Similar to mp3's id3v2-tags lyrics and synchronized lyrics (SYLT) fields - available since 1998. Missing this every day.

Maybe relevant for M3F only? posted there too. --Oggfan 07:32, 8 May 2012 (PDT)

Synchronized lyrics may also be embedded as a Kate text stream, though patches to get playback in misc audio players are mostly been ignored (isn't that the fate of most patches to anything ?). --Oggfan 07:43, 8 May 2012 (PDT)