Talk:VorbisComment: Difference between revisions
Martin.leese (talk | contribs) m (→License and Copyright: Added new section with attribution (plus wikified)) |
|||
Line 1: | Line 1: | ||
==License and Copyright== | == License and Copyright == | ||
Do notice that I proposed a simpler standard for those two tags a couple of months ago. | Do notice that I proposed a simpler standard for those two tags a couple of months ago. | ||
Line 14: | Line 14: | ||
--[[User:Saoshyant|Ivo]] 16:33, 13 September 2007 (PDT) | --[[User:Saoshyant|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. | 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 | 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 | |||
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 [http://wiki.musicbrainz.org/PicardQt/TagMapping 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. | 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. [http://www.softpointer.com/AudioShell.htm 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. | 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: | ||
<pre> | |||
How do you indicate which artist played tenor sax in the solo? | |||
</pre> | |||
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 | 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 | ||
<pre> | |||
Or you could amend the Fieldname so it supported a way of linking fields,e.g | ARTIST_INSTRUMENT_MUSICALPASSAGE="fred:tenorsaxophone:solo" | ||
</pre> | |||
Or you could amend the Fieldname so it supported a way of linking fields,e.g: | |||
<pre> | |||
ARTIST-1:fred | |||
ARTIST-2:jane | |||
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 | INSTRUMENT-1:tenorsaxophone | ||
MUSICPASSAGE-1:solo | |||
</pre> | |||
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 |
Revision as of 19:14, 25 June 2009
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
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