Talk:VorbisComment - Revision history

Martin.leese: /* Proposal: Adding embedded Lyrics field */ Added attribution

2012-05-08T16:27:15Z

Proposal: Adding embedded Lyrics field: Added attribution

← Older revision		Revision as of 16:27, 8 May 2012
Line 81:		Line 81:
	Maybe relevant for M3F only? posted there too. --[[User:Oggfan\|Oggfan]] 07:32, 8 May 2012 (PDT)		Maybe relevant for M3F only? posted there too. --[[User:Oggfan\|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 ?). 07:43, 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 ?). --[[User:Oggfan\|Oggfan]] 07:43, 8 May 2012 (PDT)

IspamU: /* Proposal: Adding embedded Lyrics field */

2012-05-08T14:43:36Z

Proposal: Adding embedded Lyrics field

← Older revision		Revision as of 14:43, 8 May 2012
Line 80:		Line 80:

	Maybe relevant for M3F only? posted there too. --[[User:Oggfan\|Oggfan]] 07:32, 8 May 2012 (PDT)		Maybe relevant for M3F only? posted there too. --[[User:Oggfan\|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 ?). 07:43, 8 May 2012 (PDT)

Oggfan: /* Proposal: Adding embedded Lyrics field */

2012-05-08T14:32:16Z

Proposal: Adding embedded Lyrics field

← Older revision		Revision as of 14:32, 8 May 2012
Line 79:		Line 79:
	Similar to mp3's id3v2-tags lyrics and synchronized lyrics (SYLT) fields - available since 1998. Missing this every day.		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.	+	Maybe relevant for M3F only? posted there too. --[[User:Oggfan\|Oggfan]] 07:32, 8 May 2012 (PDT)

Oggfan at 14:31, 8 May 2012

2012-05-08T14:31:53Z

← Older revision		Revision as of 14:31, 8 May 2012
Line 74:		Line 74:

	NO PROPOSALS! VorbisComments need a lot of extension beyond just the ARTIST field name. See work at [[M3F\|Multimedia Metadata Format (M3F)]], the proposed XML replacement for VorbisComments for structured metadata.		NO PROPOSALS! VorbisComments need a lot of extension beyond just the ARTIST field name. See work at [[M3F\|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.

Martin.leese: /* Attributing involved parties */ Added attribution

2009-07-10T22:21:18Z

Attributing involved parties: Added attribution

← Older revision		Revision as of 22:21, 10 July 2009
Line 69:		Line 69:
	== Attributing involved parties ==		== Attributing involved parties ==

-	''Moved ~~over~~ from ~~the~~ article ~~to the Talk page~~ as it is not the consensus view''	+	''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.		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 ~~PROPOSAL:'''~~ VorbisComments need a lot of extension beyond just the ARTIST field name. See work at [[M3F\|Multimedia Metadata Format (M3F)]], the proposed XML replacement for VorbisComments for structured metadata.	+	NO PROPOSALS! VorbisComments need a lot of extension beyond just the ARTIST field name. See work at [[M3F\|Multimedia Metadata Format (M3F)]], the proposed XML replacement for VorbisComments for structured metadata.

Martin.leese: Moved from article

2009-07-10T20:39:19Z

Moved from article

← Older revision		Revision as of 20:39, 10 July 2009
Line 43:		Line 43:
	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		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 [[VorbisComment#Cover_art\|METADATA_BLOCK_PICTURE]]	+	: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 [[VorbisComment#Cover_art\|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. [[M3F\|Multimedia Metadata Format (M3F)]] is such a draft proposal.		: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. [[M3F\|Multimedia Metadata Format (M3F)]] is such a draft proposal.
Line 59:		Line 59:
	=== Proposals ===		=== Proposals ===

-	''Field names may be UTF-8 and all UPPERCASE for easier machine processing.''	+	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.		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.
Line 66:		Line 66:

	: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.--[[User:Imalone\|Imalone]] 01:11, 17 September 2007 (PDT)		: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.--[[User:Imalone\|Imalone]] 01:11, 17 September 2007 (PDT)
		+
		+	== Attributing involved parties ==
		+
		+	''Moved over from the article to the Talk page as it is not the consensus view''
		+
		+	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 PROPOSAL:''' VorbisComments need a lot of extension beyond just the ARTIST field name. See work at [[M3F\|Multimedia Metadata Format (M3F)]], the proposed XML replacement for VorbisComments for structured metadata.

Martin.leese: /* Comments by Ijabz */ Clarify

2009-07-02T03:57:29Z

Comments by Ijabz: Clarify

← Older revision		Revision as of 03:57, 2 July 2009
Line 18:		Line 18:
	''The following was added by Ijabz on October 18, 2007''		''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:
Line 24:		Line 24:
	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.		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. 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.	+	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. [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. 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:		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:
Line 43:		Line 43:
	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		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. ~~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]].	+	: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 [[VorbisComment#Cover_art\|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 ~~or one of its siblings~~. [[M3F\|Multimedia Metadata Format (M3F)]]~~, based on XML,~~ is such a draft proposal.	+	: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. [[M3F\|Multimedia Metadata Format (M3F)]] is such a draft proposal.

	:[[User:Martin.leese\|Martin Leese]] 19:52, 1 July 2009 (PDT)		:[[User:Martin.leese\|Martin Leese]] 19:52, 1 July 2009 (PDT)

Martin.leese: /* Comments by Ijabz */ Clarify

2009-07-02T02:53:34Z

Comments by Ijabz: Clarify

← Older revision		Revision as of 02:53, 2 July 2009
Line 43:		Line 43:
	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		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. The intention was to put binary data in a separate logical bitstream. Unfortunately, at the moment, ~~including~~ such a stream breaks many players. An initiative is in progress to address this using [[Ogg Skeleton]].	+	:On drawback 2, VorbisComments were designed to be text-only. 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]].

	: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 or one of its siblings. [[M3F\|Multimedia Metadata Format (M3F)]], based on XML, is such a draft proposal.		: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 or one of its siblings. [[M3F\|Multimedia Metadata Format (M3F)]], based on XML, is such a draft proposal.

Martin.leese: /* Comments by Ijabz */ Responses

2009-07-02T02:52:05Z

Comments by Ijabz: Responses

← Older revision		Revision as of 02:52, 2 July 2009
Line 26:		Line 26:
	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.		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. 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:	+	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:
	<pre>		<pre>
	How do you indicate which artist played tenor sax in the solo?		How do you indicate which artist played tenor sax in the solo?
	</pre>		</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 (I've used a colon in this example) allowing machine parsing of related attributes
	<pre>		<pre>
	ARTIST_INSTRUMENT_MUSICALPASSAGE="fred:tenorsaxophone:solo"		ARTIST_INSTRUMENT_MUSICALPASSAGE="fred:tenorsaxophone:solo"
Line 42:		Line 42:
	</pre>		</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		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. The intention was to put binary data in a separate logical bitstream. Unfortunately, at the moment, including such a stream breaks many players. An initiative is in progress to address this using [[Ogg Skeleton]].
		+
		+	: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 or one of its siblings. [[M3F\|Multimedia Metadata Format (M3F)]], based on XML, is such a draft proposal.
		+
		+	:[[User:Martin.leese\|Martin Leese]] 19:52, 1 July 2009 (PDT)

	== Character encoding ==		== Character encoding ==

Martin.leese: /* License and Copyright */ Added attributions

2009-06-26T03:36:16Z

License and Copyright: Added attributions

← Older revision		Revision as of 03:36, 26 June 2009
Line 5:		Line 5:
	* COPYRIGHT = Name of Entity (e.g. Xiph.Org Foundation)		* 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...	+	:: 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/ )		* 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.	+	:: 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.		This makes it simple for both users and machines to understand the data.
-
	--[[User:Saoshyant\|Ivo]] 16:33, 13 September 2007 (PDT)		--[[User:Saoshyant\|Ivo]] 16:33, 13 September 2007 (PDT)