XiphWiki - User contributions [en]

VorbisComment

2009-04-03T10:21:19Z

Imalone: /* Proposal: METADATA_BLOCK_PICTURE */

VorbisComment is a base-level [[Metadata]] format initially created for use with Ogg [[Vorbis]]. It has since been adopted in the specifications of
[[Ogg]] encapsulations for other Xiph.Org codecs including [[Theora]], [[Speex]] and [[FLAC]].

The use case for VorbisComment is given as:
<blockquote>
... much like someone jotting a quick note on the bottom of a CDR. It should be a little information to remember the disc by and explain it to others; a short, to-the-point text note that need not only be a couple words, but isn't going to be more than a short paragraph.[http://xiph.org/vorbis/doc/v-comment.html]
</blockquote>

VorbisComments are typically used to provide basic information like the title and copyright holder of a work.
As such the scope is similar to that of ID3 tags used with MP3 files.
VorbisComment is widely supported on [[VorbisHardware|portable Ogg Vorbis players]] as well as streaming, editing and playback software.

Although the syntax of VorbisComment is well-specified, various conventions exist for the field names in use.
The goal for this page is to codify best practices and collect proposals for standardization of VorbisComment field names.

VorbisComments are typically encoded as the second packet in a codec stream. When VorbisComments are included in the first (ie. Theora) stream of an Ogg Theora file, they are assumed to cover all streams in the multiplexed group. [http://lists.xiph.org/pipermail/vorbis-dev/2008-December/019676.html]

VorbisComment is the simplest and most widely-supported mechanism for storing metadata with Xiph.Org codecs. For other existing and proposed mechanisms, see [[Metadata]].

==Recommended field names==

The current [http://xiph.org/vorbis/doc/v-comment.html VorbisComment recommendation] contains a recommended set
of field names for comments.

==Proposed field names==

Some proposals for extra field names:

* [http://reactor-core.org/ogg-tagging.html Ogg Vorbis Comment Field Recommendations]
* [http://gophernet.org/articles/vorbiscomment/ Proposals for extending Ogg Vorbis comments]

Comments are intended to be free-form, but for the purposes of interoperability, it is helpful to define
tag sets for particular applications, and provide some guidelines for machine parsing.

:: '''Some''' field names may have to be non-free-form to achieve machine parsing. Such as ENCODER, DATE, RIGHTS-DATE, and RIGHTS-URI. See reasoning below.

=== Cover art ===
VorbisComments don't officially support album cover art yet. Since this is a frequently requested feature though, the goal is to find a consensus and an official standard on how to embed (or link) album cover art pictures within ogg vorbis files.

==== Proposal: METADATA_BLOCK_PICTURE ====
The [http://flac.sourceforge.net/format.html#metadata_block_picture binary FLAC picture structure] is base64 encoded and placed within a vorbis comment with the tag name "METADATA_BLOCK_PICTURE". This has the following benefits:

* Easy to use for developers since the identical (or similar) structure is also used by FLAC and MP3, which means that chances are good that people and software programmers are willing to support this.
* The cover art can either be linked or embedded within the stream.
* Common picture file formats are supported (jpg and png).
* A description may be included and the picture type (front cover, back cover...) and image mime type are provided.
* Base64 encoded data is invariant under UTF-8 and a valid UTF-8 string, so obeys the rules for comment data.

Implementations interpreting or writing picture blocks should note the following details:
===== General encoding/decoding =====
* Failure to decode a picture block should not prevent playback of the file (failure to deal with the particularly large packet required by the comment header is a separate problem with the player implementation).
* Base64 encoding is used as in section 4 of [http://www.faqs.org/rfcs/rfc4648.html RFC4648]. We note that line feeds are not allowed and padding characters ('=') are required.
* Applications adding picture blocks should inform users that some applications or hardware may not support them and should provide a method to remove the blocks (this is expected to be trivial for applications capable of adding them).

===== Block handling =====
* The unecoded format is that of the [http://flac.sourceforge.net/format.html#metadata_block_picture FLAC picture block]. The fields are stored in big endian order as in FLAC, picture data is stored according to the relevant standard.
* Picture data should be stored in PNG or JPEG formats or linked separately. It is recommended readers support both PNG and JPEG
* Allowed values for the MIME string are "image/", "image/png", "image/jpeg" and "-->" (the link indicator) and "" (length 0). An empty MIME string indicates type "image/"
* Fields present in the ID3V2.4.0 [http://www.id3.org/id3v2.4.0-frames#line-1085 Attached Picture Frame] (APIC Frame) take the same interpretation as in the ID3V2.4.0 format with the following exceptions (following the FLAC format):
** The description field is UTF-8 (encoded without ID3V2's initial 'encoding byte')
** String fields are not null terminated: their preceding length fields are used instead.

===== Linked images =====
Support for linked images is optional for applications handling picture blocks. When a linked picture is indicated the following rules are observed:
* The picture data is a complete URL indicating the picture to be used, relative URLs are allowed (note relative URLs do not start with a protocol specifier and are retrieved with the same protocol as the file being processed).
* Links are ISO-8859-1 encoded
* Applications MAY retrieve linked images via the file:// protocol.
* Applications MUST obtain user approval if they wish to retrieve images via remote protocols.
* Link targets may become unavailable: applications supporting linked images SHOULD recover gracefully from this and MAY report the absence to the user.
* The type of the linked file is not restricted to JPEG and JFIF and applications MAY support other formats
* If the application does not support linked images, the target is unavailable, not permitted or an unknown format the picture block should be skipped.
* Applications may make links available to users, this is of particular use when links are unsupported or of unsupported type

===== Image dimension fields =====
* The height, width, colour depth and 'number of colours' fields are for purely informational purposes. Applications MUST NOT use them for decoding purposes, but MAY display them to the user and MAY use them to make a decision whether to skip the block (for example if selecting the most appropriate among multiple blocks).
* Applications writing picture blocks MUST set these fields correctly OR set them all to zero.

===== Multiple blocks =====
* Multiple image blocks MAY be included as separate METADATA_BLOCK_PICTURE comments.
* There may only be one each of picture type (APIC type) 1 and 2 in a Vorbis stream.
* Block order is significant for some types and applications should preserve the comment order when reading or writing Vorbis comment headers. The block order may be used to determine the order pictures are presented to the user.

===== Playback tests =====
Embedding a picture into the file might break playback of existing players (especially hardware players, software players could be updated easily). A workaround would be to link the picture within the tag. Furthermore users should become informed in some way that embedding a picture COULD cause problems (as stated above).

In order to test if there are playback problems with this proposal, there is a test file available [http://www.audioranger.com/with_coverart.ogg here]. You're invited to download this file, test playback on your software and hardware players, and report the results here on the wiki.

'''Tested software players'''
* Audacious 1.5.1: no problem
* foobar2000: no problems
* Gnome: built-in preview playback: no problem
* MediaMonkey: no problems
* Media Player Classic (unicode build) 6.4.9.1: no problem
* RoarAudio: no problems (server and client side)
* Rythmbox 0.11.6: no problem
* Totem 2.24.3: no problem
* VLC 0.9.4/0.9.6: doesn't play
** Patch send to VLC to fix this - should get in 1.0.0
* WinAmp: no problems
* Windows Media Player 11: no problem
* XMPlay 3.4.2: no problem
* Nero ShowTime: no problem

'''Tested hardware players'''
* Logitech Squeezebox: doesn't play this file (and all other oggs with embedded picture)
** Workaround: The needed Server Software (called SqueezeCenter) can convert ogg to mp3 on the fly, and has also no problem to convert oggs with embedded pictures
* Sandisk Sansa Fuze (Firmware 01.01.22): Hangs up when trying to playback the demo file - had to reset the player
** Note: The "Fuze" can play ogg vorbis files which have embedded pictures from "Easytag"
* Cowon iAudio U3 (Firmware 1.29, 4 GB): works
* Cowon D2: no problem (latest Firmware: 2.59, 8GB Version)
* iRiver E100: no problem (latest Firmware: 1.16 G_U, 8GB Version)

'''Tested tag editors'''
* Easytag 2.1.6: can open the file to edit the normal tag fields
* MP3Tag 2.42e: can open the file to edit the normal tag fields

'''Tested other software'''
* Total Recorder: can open the file without a problem. After re-saving content of the "BINARY_COVERART" will be lost.

==== Unofficial "COVERART" field ====
There exists an unofficial, not well supported comment field named "COVERART". It includes a base64-encoded string of the binary picture data (usually a JPEG file, but this could be a different file format too). The disadvantages are that
* no additional information like a description about the cover art or its type (front cover, back cover etc.) is provided,
* the cover art can't be linked
* the base64 string is displayed within many tag editors as plain text because of their missing support for this "COVERART" field
* it may breaks the playback on hardware players because of a large vorbis comment header
The unofficial "COVERART" field is supported for example by such software as AudioShell (http://www.softpointer.com/AudioShell.htm) and Total Recorder (http://www.totalrecorder.com/).

===Dates and time===
The goal is to specify '''one''' standard format for describing dates and time.

====ISO proposal====
The date format for any field describing a date must follow the ISO scheme: YYYY-MM-DD or shortened to just YYYY-MM or simply YYYY.

We have been recommending this usage with the DATE tag for some time. It is proposed that the spec be amended to include this
information for machinability.

The time format for any field '''except''' track duration must be specified with leading T and ending with a time zone. Schemas with and without dates: YYYY-MM-DDTHH:MM:SS+TS THH:MM+TZ

===New ENCODER field name proposal===
The goal is to attribute encoder software. This value can be used in the future to determine which files can be improved by being re encoded with a newer version.

:'''Comment''': What is lacking from the vendor string present in the spec from the start? All libvorbis and encoder tunings I'm aware of have recorded the encoder version here.
:: Note that ffmpeg2theora uses ENCODER, but does not include a url.
::: A URI/L—especially one with version numbering—will be more unique. See the above goal for this comment.
:: I've also seen ENCODED_BY.
::: ENCODED_BY is usually the person who did the encoding. This should not be part of the recommendation due to legal problems around deliberate and accidental distribution to third parties. Basically the name of the encoder should not be included to protect encoders from their own egos and possible legal prosecution.
:: I am trying to get the specification to include that this field '''must''' contain a unique URL and version number. For the reason listed above. Whether to including the field at all would of course be optional.

====Proposal====
The encoder field name must be a unique URL providing both encoder software name and version. If no unique URL address is available were both name and version is available; then the version number can be specified by separating with a space character. For examples:

<nowiki>ENCODER=http://flac.sourceforge.net/ 1.2.1</nowiki>

===Improving license data===
The goal is to provide a method for proclaiming license and copyright information (basically clarifying ‘distribution rights (if any) and ownership’).

The [http://xiph.org/vorbis/doc/v-comment.html specification document] describes LICENSE and COPYRIGHT fields. But is not clear enough about whether these should be machine-readable.

We should consider working together with Creative Commons to have complementary and interlinked information on the CC and Xiph wikis. Refer to the [http://wiki.creativecommons.org/Ogg Ogg page] in the CC wiki.

==== New RIGHTS field name proposal ====
One proposal is to replace the COPYRIGHT and LICENSE field names with RIGHTS. RIGHTS must be a human-readable copyright statement. Basic example:

<nowiki>RIGHTS=Copyright © Recording Company Inc. All distribution rights reserved.</nowiki>

But this is not machine-readable. Adding two complementary field names should do the trick: RIGHTS-DATE, describing the date of copyright; and RIGHTS-URI, providing a method for linking to a license. Software agents can assume that multiple songs uses the sameURIs, such as in the case for Creative Commons. Full example:

<nowiki>RIGHTS=Copyright © 2019 Recording Company Inc. All distribution rights reserved.</nowiki> 
<nowiki>RIGHTS-DATE=2019-04</nowiki> 
<nowiki>RIGHTS-URI=http://somewhere.com/license.xhtml</nowiki>

Software such as for multimedia management and playback are encouraged to display the RIGHTS statement as a linked phrase using RIGHTS-URI.

RIGHTS-DATE does not need to be displayed as it is required in the human readable version by international copyright agreements. RIGHTS-DATE can be used to determine when a copyrighted work falls under the public domain and related matters. (''The Beatles''' copyright on their original studio recordings (not the remixes) are soon expiering. So mechanisms such as the RIGHTS-DATE are indeed required in music management and filesharing software!)

To remain machine-readable it would be required to have at most one instance of each RIGHTS field name. All fields would of course remain optional.

The ''Dublin Core Metadata Initiative'' recommends the use of ‘rights’ to describe license and copyright matters. The web feed format Atom 1.0 has implemented a rights element in their specification.

==== Improving existing fields proposal ====
Similar to the DATE tag above, we have generally recommended that a URL uniquely identifying the license be included in the LICENSE field to allow machine identification of the license. This is in agreement with the proposal in the CC wiki. Since the COPYRIGHT field is a human-readable statement of the copyright, like the proposed RIGHTS tag above, some people include a license url there. Therefore if a url can't be found in a LICENSE tag if any, applications should use one from the COPYRIGHT tag, if any. Contact information for verification, attribution, relicensing, etc. can be obtained from the COPYRIGHT field, but CC also recommend a separate CONTACT tag for this information. This is reasonable, so we propose it be included.

=== Attributing involved parties ===
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!''' Needs much extending beyond just ARTIST field name. See work at proposed XML replacement for Vorbis Comments, [[M3F]].

=== Geo Location fields ===
The LOCATION field is meant to carry a human readable location for the recording/creation of the media file.

Having geographical coordinates according to [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84] can be useful as well, especially in a form that can be machine parsed. The agreed format is similar to this [http://en.wikipedia.org/wiki/Geo_(microformat) geo microformat]:

GEO_LOCATION= ''latitude'' ; ''longitude'' [; ''elevation'' ]

where each value is a fixed point decimal number formatted in the C locale with a period (.) for the radix. Values are separated with a ';' and white space is not significant. The elevation is optional.

''latitude'' is the geo latitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the equator, negative values for southern latitudes) (C double).

''longitude'' is the geo longitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the prime meridian in Greenwich/UK, negative values for western longitudes). (C double).

''elevation'' is the geo elevation of where the media has been recorded or produced in meters according to WGS84 (zero is average sea level) (C double).

== Character encoding ==
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.--[[User:Imalone|Imalone]] 01:11, 17 September 2007 (PDT)

== Implementations ==

* [http://sbooth.org/importers/ Spotlight importer]
* vorbiscomment
* oggz-comment

VorbisComment

2009-04-03T00:52:10Z

Imalone: /* Proposal: METADATA_BLOCK_PICTURE */

VorbisComment is a base-level [[Metadata]] format initially created for use with Ogg [[Vorbis]]. It has since been adopted in the specifications of
[[Ogg]] encapsulations for other Xiph.Org codecs including [[Theora]], [[Speex]] and [[FLAC]].

The use case for VorbisComment is given as:
<blockquote>
... much like someone jotting a quick note on the bottom of a CDR. It should be a little information to remember the disc by and explain it to others; a short, to-the-point text note that need not only be a couple words, but isn't going to be more than a short paragraph.[http://xiph.org/vorbis/doc/v-comment.html]
</blockquote>

VorbisComments are typically used to provide basic information like the title and copyright holder of a work.
As such the scope is similar to that of ID3 tags used with MP3 files.
VorbisComment is widely supported on [[VorbisHardware|portable Ogg Vorbis players]] as well as streaming, editing and playback software.

Although the syntax of VorbisComment is well-specified, various conventions exist for the field names in use.
The goal for this page is to codify best practices and collect proposals for standardization of VorbisComment field names.

VorbisComments are typically encoded as the second packet in a codec stream. When VorbisComments are included in the first (ie. Theora) stream of an Ogg Theora file, they are assumed to cover all streams in the multiplexed group. [http://lists.xiph.org/pipermail/vorbis-dev/2008-December/019676.html]

VorbisComment is the simplest and most widely-supported mechanism for storing metadata with Xiph.Org codecs. For other existing and proposed mechanisms, see [[Metadata]].

==Recommended field names==

The current [http://xiph.org/vorbis/doc/v-comment.html VorbisComment recommendation] contains a recommended set
of field names for comments.

==Proposed field names==

Some proposals for extra field names:

* [http://reactor-core.org/ogg-tagging.html Ogg Vorbis Comment Field Recommendations]
* [http://gophernet.org/articles/vorbiscomment/ Proposals for extending Ogg Vorbis comments]

Comments are intended to be free-form, but for the purposes of interoperability, it is helpful to define
tag sets for particular applications, and provide some guidelines for machine parsing.

:: '''Some''' field names may have to be non-free-form to achieve machine parsing. Such as ENCODER, DATE, RIGHTS-DATE, and RIGHTS-URI. See reasoning below.

=== Cover art ===
VorbisComments don't officially support album cover art yet. Since this is a frequently requested feature though, the goal is to find a consensus and an official standard on how to embed (or link) album cover art pictures within ogg vorbis files.

==== Unofficial "COVERART" field ====
There exists an unofficial, not well supported comment field named "COVERART". It includes a base64-encoded string of the binary picture data (usually a JPEG file, but this could be a different file format too). The disadvantages are that
* no additional information like a description about the cover art is provided,
* the base64 string is displayed within many tag editors as plain text because of their missing support for this "COVERART" field
* it may breaks the playback on hardware players because of a large vorbis comment header
* the cover art can't be linked
The unofficial "COVERART" field is supported for example by such software as AudioShell (http://www.softpointer.com/AudioShell.htm) and Total Recorder (http://www.totalrecorder.com/).

==== Proposal: METADATA_BLOCK_PICTURE ====
The [http://flac.sourceforge.net/format.html#metadata_block_picture binary FLAC picture structure] is base64 encoded and placed within a vorbis comment with the tag name "METADATA_BLOCK_PICTURE". This has the following benefits:

* Easy to use for developers since the identical (or similar) structure is also used by FLAC and MP3, which means that chances are good that people and software programmers are willing to support this.
* The cover art can either be linked or embedded within the stream.
* Common picture file formats are supported (jpg and png).
* A description may be included and the picture type (front cover, back cover...) and image mime type are provided.
* Base64 encoded data is invariant under UTF-8 and a valid UTF-8 string, so obeys the rules for comment data.

Implementations interpreting or writing picture blocks should note the following details:
===== General encoding/decoding =====
* Failure to decode a picture block should not prevent playback of the file (failure to deal with the particularly large packet required by the comment header is a separate problem with the player implementation).
* Base64 encoding is used as in section 4 of [http://www.faqs.org/rfcs/rfc4648.html RFC4648]. We note that line feeds are not allowed and padding characters ('=') are required.
* Applications adding picture blocks should inform users that some applications or hardware may not support them and should provide a method to remove the blocks (this is expected to be trivial for applications capable of adding them).

===== Block handling =====
* The unecoded format is that of the [http://flac.sourceforge.net/format.html#metadata_block_picture FLAC picture block]. The fields are stored in big endian order as in FLAC, picture data is stored according to the relevant standard.
* Picture data should be stored in PNG or JPEG formats or linked separately. It is recommended readers support both PNG and JPEG
* Allowed values for the MIME string are "image/", "image/png", "image/jpeg" and "-->" (the link indicator) and "" (length 0). An empty MIME string indicates type "image/"
* Fields present in the ID3V2.4.0 [http://www.id3.org/id3v2.4.0-frames#line-1085 Attached Picture Frame] (APIC Frame) take the same interpretation as in the ID3V2.4.0 format with the following exceptions (following the FLAC format):
** The description field is UTF-8 (encoded without ID3V2's initial 'encoding byte')
** String fields are not null terminated: their preceding length fields are used instead.

===== Linked images =====
Support for linked images is optional for applications handling picture blocks. When a linked picture is indicated the following rules are observed:
* The picture data is a complete URL indicating the picture to be used, relative URLs are allowed (note relative URLs do not start with a protocol specifier and are retrieved with the same protocol as the file being processed).
* Links are ISO-8859-1 encoded
* Applications MAY retrieve linked images via the file:// protocol.
* Applications MUST obtain user approval if they wish to retrieve images via remote protocols.
* Link targets may become unavailable: applications supporting linked images SHOULD recover gracefully from this and MAY report the absence to the user.
* The type of the linked file is not restricted to JPEG and JFIF and applications MAY support other formats
* If the application does not support linked images, the target is unavailable, not permitted or an unknown format the picture block should be skipped.

===== Image dimension fields =====
* The height, width, colour depth and 'number of colours' fields are for purely informational purposes. Applications MUST NOT use them for decoding purposes, but MAY display them to the user and MAY use them to make a decision whether to skip the block (for example if selecting the most appropriate among multiple blocks).
* Applications writing picture blocks MUST set these fields correctly OR set them all to zero.

===== Multiple blocks =====
* Multiple image blocks MAY be included as separate METADATA_BLOCK_PICTURE comments.
* There may only be one each of picture type (APIC type) 1 and 2 in a Vorbis stream.
* Block order is significant for some types and applications should preserve the comment order when reading or writing Vorbis comment headers. The block order may be used to determine the order pictures are presented to the user.

As with the base64 "COVERART" field, it might break playback of existing players (especially hardware players, software players could be updated easily). A workaround would be to link the picture within the tag, or to notify a user of a software tagger that his hardware player ''might'' not support playback of the file if he embeds a picture.

In order to test if there are playback problems with this proposal, there is a test file available [http://www.audioranger.com/with_coverart.ogg here]. You're invited to download this file, test playback on your software and hardware players, and report the results here on the wiki.

'''Tested software players'''
* Audacious 1.5.1: no problem
* foobar2000: no problems
* Gnome: built-in preview playback: no problem
* MediaMonkey: no problems
* Media Player Classic (unicode build) 6.4.9.1: no problem
* RoarAudio: no problems (server and client side)
* Rythmbox 0.11.6: no problem
* Totem 2.24.3: no problem
* VLC 0.9.4/0.9.6: doesn't play
** Patch send to VLC to fix this - should get in 1.0.0
* WinAmp: no problems
* Windows Media Player 11: no problem
* XMPlay 3.4.2: no problem
* Nero ShowTime: no problem

'''Tested hardware players'''
* Logitech Squeezebox: doesn't play this file (and all other oggs with embedded picture)
** Workaround: The needed Server Software (called SqueezeCenter) can convert ogg to mp3 on the fly, and has also no problem to convert oggs with embedded pictures
* Sandisk Sansa Fuze (Firmware 01.01.22): Hangs up when trying to playback the demo file - had to reset the player
** Note: The "Fuze" can play ogg vorbis files which have embedded pictures from "Easytag"
* Cowon iAudio U3 (Firmware 1.29, 4 GB): works
* Cowon D2: no problem (latest Firmware: 2.59, 8GB Version)
* iRiver E100: no problem (latest Firmware: 1.16 G_U, 8GB Version)

'''Tested tag editors'''
* Easytag 2.1.6: can open the file to edit the normal tag fields
* MP3Tag 2.42e: can open the file to edit the normal tag fields

'''Tested other software'''
* Total Recorder: can open the file without a problem. After re-saving content of the "BINARY_COVERART" will be lost.

===Dates and time===
The goal is to specify '''one''' standard format for describing dates and time.

====ISO proposal====
The date format for any field describing a date must follow the ISO scheme: YYYY-MM-DD or shortened to just YYYY-MM or simply YYYY.

We have been recommending this usage with the DATE tag for some time. It is proposed that the spec be amended to include this
information for machinability.

The time format for any field '''except''' track duration must be specified with leading T and ending with a time zone. Schemas with and without dates: YYYY-MM-DDTHH:MM:SS+TS THH:MM+TZ

===New ENCODER field name proposal===
The goal is to attribute encoder software. This value can be used in the future to determine which files can be improved by being re encoded with a newer version.

:'''Comment''': What is lacking from the vendor string present in the spec from the start? All libvorbis and encoder tunings I'm aware of have recorded the encoder version here.
:: Note that ffmpeg2theora uses ENCODER, but does not include a url.
::: A URI/L—especially one with version numbering—will be more unique. See the above goal for this comment.
:: I've also seen ENCODED_BY.
::: ENCODED_BY is usually the person who did the encoding. This should not be part of the recommendation due to legal problems around deliberate and accidental distribution to third parties. Basically the name of the encoder should not be included to protect encoders from their own egos and possible legal prosecution.
:: I am trying to get the specification to include that this field '''must''' contain a unique URL and version number. For the reason listed above. Whether to including the field at all would of course be optional.

====Proposal====
The encoder field name must be a unique URL providing both encoder software name and version. If no unique URL address is available were both name and version is available; then the version number can be specified by separating with a space character. For examples:

<nowiki>ENCODER=http://flac.sourceforge.net/ 1.2.1</nowiki>

===Improving license data===
The goal is to provide a method for proclaiming license and copyright information (basically clarifying ‘distribution rights (if any) and ownership’).

The [http://xiph.org/vorbis/doc/v-comment.html specification document] describes LICENSE and COPYRIGHT fields. But is not clear enough about whether these should be machine-readable.

We should consider working together with Creative Commons to have complementary and interlinked information on the CC and Xiph wikis. Refer to the [http://wiki.creativecommons.org/Ogg Ogg page] in the CC wiki.

==== New RIGHTS field name proposal ====
One proposal is to replace the COPYRIGHT and LICENSE field names with RIGHTS. RIGHTS must be a human-readable copyright statement. Basic example:

<nowiki>RIGHTS=Copyright © Recording Company Inc. All distribution rights reserved.</nowiki>

But this is not machine-readable. Adding two complementary field names should do the trick: RIGHTS-DATE, describing the date of copyright; and RIGHTS-URI, providing a method for linking to a license. Software agents can assume that multiple songs uses the sameURIs, such as in the case for Creative Commons. Full example:

<nowiki>RIGHTS=Copyright © 2019 Recording Company Inc. All distribution rights reserved.</nowiki> 
<nowiki>RIGHTS-DATE=2019-04</nowiki> 
<nowiki>RIGHTS-URI=http://somewhere.com/license.xhtml</nowiki>

Software such as for multimedia management and playback are encouraged to display the RIGHTS statement as a linked phrase using RIGHTS-URI.

RIGHTS-DATE does not need to be displayed as it is required in the human readable version by international copyright agreements. RIGHTS-DATE can be used to determine when a copyrighted work falls under the public domain and related matters. (''The Beatles''' copyright on their original studio recordings (not the remixes) are soon expiering. So mechanisms such as the RIGHTS-DATE are indeed required in music management and filesharing software!)

To remain machine-readable it would be required to have at most one instance of each RIGHTS field name. All fields would of course remain optional.

The ''Dublin Core Metadata Initiative'' recommends the use of ‘rights’ to describe license and copyright matters. The web feed format Atom 1.0 has implemented a rights element in their specification.

==== Improving existing fields proposal ====
Similar to the DATE tag above, we have generally recommended that a URL uniquely identifying the license be included in the LICENSE field to allow machine identification of the license. This is in agreement with the proposal in the CC wiki. Since the COPYRIGHT field is a human-readable statement of the copyright, like the proposed RIGHTS tag above, some people include a license url there. Therefore if a url can't be found in a LICENSE tag if any, applications should use one from the COPYRIGHT tag, if any. Contact information for verification, attribution, relicensing, etc. can be obtained from the COPYRIGHT field, but CC also recommend a separate CONTACT tag for this information. This is reasonable, so we propose it be included.

=== Attributing involved parties ===
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!''' Needs much extending beyond just ARTIST field name. See work at proposed XML replacement for Vorbis Comments, [[M3F]].

=== Geo Location fields ===
The LOCATION field is meant to carry a human readable location for the recording/creation of the media file.

Having geographical coordinates according to [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84] can be useful as well, especially in a form that can be machine parsed. The agreed format is similar to this [http://en.wikipedia.org/wiki/Geo_(microformat) geo microformat]:

GEO_LOCATION= ''latitude'' ; ''longitude'' [; ''elevation'' ]

where each value is a fixed point decimal number formatted in the C locale with a period (.) for the radix. Values are separated with a ';' and white space is not significant. The elevation is optional.

''latitude'' is the geo latitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the equator, negative values for southern latitudes) (C double).

''longitude'' is the geo longitude location of where the media has been recorded or produced in decimal degrees according to WGS84 (zero at the prime meridian in Greenwich/UK, negative values for western longitudes). (C double).

''elevation'' is the geo elevation of where the media has been recorded or produced in meters according to WGS84 (zero is average sea level) (C double).

== Character encoding ==
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.--[[User:Imalone|Imalone]] 01:11, 17 September 2007 (PDT)

== Implementations ==

* [http://sbooth.org/importers/ Spotlight importer]
* vorbiscomment
* oggz-comment

Spread Open Media Contributions

2008-03-19T01:16:24Z

Imalone: play.com letter now on MailOgging

This page lists proposed additions to the SOM project. If you plan to write an article or a tutorial, or create a video, audio, or image contribution, you should post it in this page.

If your contribution is deemed worthy, it will be posted on the SOM web site with due credit. You may contribute with about anything your mind can imagine. The only limitation is that you will agree to license your contributions under the Creative Commons Attribution 3.0 License, or any later version published by Creative Commons.

Contributions are _not_ limited to English.

Translations requests may be listed here, as well.

Separate contributions by using either headers or break lines.

MailOgging

2008-03-18T23:57:03Z

Imalone: /* Letter to Play.com requesting Vorbis and FLAC */

This project is for the use of the average bloke (yes, you), who would like to further help and promote the use of your favorite free format. The MailOgging is a strategy to get the attention of hardware and software vendors who do not know the Ogg family, do not care about it, or do not know how many people care about it. The MailOgging provides free templates that you can use (and change according to your likeness) to create letters that you can then send to the corporations you want to nag. Nagging as many as you can is appreciated and gives you magical elite points.

==FAQ==
'''Q.''' Why should I do this? 
'''A.''' You tell me, but if you think it's worth it, if you want to support the Ogg family, and if you'd like to try making your voice heard, then there's your reasons. Most vendors never gave a damn about Xiph or free formats, so maybe it's time they hear some words from the community.

'''Q.''' Can I induce others to do the same? 
'''A.''' Now we are talking.

'''Q.''' Can I expand, modify and make corrections to the templates? 
'''A.''' But of course. The MailOgging is available in wiki format for this sole reason. Please help fix problems you see in the text, or further expand it. You can also suggest changes in the Talk page.

'''Q.''' What about translations? 
'''A.''' Sure. Go ahead and make them available here. There's lots of companies outside the English speaking world like Haier (China) and Samsung (Korea), and surely they would rather hear from customers on their homeland.

'''Q.''' Is this official, as in, part of the Xiph.Org Foundation? 
'''A.''' Yes, it's part of the [[SpreadOpenMedia|Spread Open Media]] iniative by [[User:Saoshyant|Ivo Emanuel Gonçalves]] and a few other goons.

'''Q.''' What are magical elite points? 
'''A.''' Oh, you'll find out when you get them.

'''Q.''' So, how do I use the templates? 
'''A.''' You need to change a few things in the template you want to use. After you are done, get either the physical address or e-mail address (or both) of the corporation you'd like to contact and send the letter.

Here's a list of things you'll need to replace in the text: 
* XXX = Name of the corporation, company, or person (e.g. Creative, Peter Pawlowski) 
* YYY = Your name. If you'll be using snail-mail, don't forget to sign the letter with a pen! 
* ZZZ = Name of the product (e.g. iTunes, Creative Zen, etc.)

You also need to know what formats you'll be requesting support for, since you'll need to edit out the template to remove what shouldn't be there. Don't forget that asking for all of them at once is probably not wise. The list is as follows:
* [[Vorbis]]
* [[FLAC]]
* [[Speex]]
* [[Theora]]
* [[XSPF]]

There's also a few slashes "/" so you can choose what's more appropriate for you and the letter. Don't forget to make decisions on what goes and what stays.

==The templates==
Dear XXX,

Through this letter, I, YYY, would like to request you to support other digital formats in the ZZZ, namely Vorbis, FLAC, Speex, Theora and XSPF. I'm one/I intend to become one of your customers/users and, as such, I believe I have a say on what I'd like you to provide me, after all, XXX exists to provide services for the people.

Now, as you may have guessed, I took the time to put this letter together because I really want this feature, I really want the XXX to be able to play the digital formats that I like. I have my music/videos/media under those formats, and so I believe I have the right to at least ask if my favorite product could one day support my media.

I'm pretty sure your fine technicians already know these formats I've mentioned above, but I'll make a brief introduction to each of them, so you'll understand why I have chosen them to store and encode my media.

Vorbis, commonly known as Ogg, because of its container format, is a lossy audio codec with higher quality over MP3 and WMA. It also streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the ZZZ play it.

FLAC is a lossless audio codec with high compression. It stores songs with all quality possible. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the ZZZ play it.

Speex is an audio codec for speech. It can be used for both audio books and VoIP, among other things. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the ZZZ play it.

Theora is an advanced video codec like MPEG 4. It streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the ZZZ play it.

XSPF is a playlist format based on XML with a lot of features that make life easier for both consumers and vendors. It's simple, cute and mean. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the ZZZ play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Vorbis 
//en.wikipedia.org/wiki/FLAC 
//en.wikipedia.org/wiki/Speex 
//en.wikipedia.org/wiki/Theora 
//en.wikipedia.org/wiki/XSPF

So, please, dear XXX. Be kind enough to consider my request. Outdo your competition, hear the voices of your customers/users. Add support for Vorbis, FLAC, Speex, Theora and XSPF in the ZZZ.

Sincerely, 
YYY

==A few examples==

===Letter to Apple regarding the iPod===
Dear Apple,

Through this letter, I, Ivo Emanuel Gonçalves, would like to request you to support other digital formats in the iPod, namely Vorbis and FLAC. I intend to become one of your customers and, as such, I believe I have a say on what I'd like you to provide me, after all, Apple exists to provide services for the people.

Now, as you may have guessed, I took the time to put this letter together because I really want this feature, I really want the iPod to be able to play the digital formats that I like. I have my music under those formats, and so I believe I have the right to at least ask if my favorite product could one day support my media.

I'm pretty sure your fine technicians already know these formats I've mentioned above, but I'll make a brief introduction to each of them, so you'll understand why I have chosen them to store and encode my media.

Vorbis, commonly known as Ogg, because of its container format, is a lossy audio codec with higher quality over MP3 and WMA. It also streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the iPod play it.

FLAC is a lossless audio codec with high compression. It stores songs with all quality possible. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the iPod play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Vorbis 
//en.wikipedia.org/wiki/FLAC

So, please, dear Apple. Be kind enough to consider my request. Outdo your competition, hear the voices of your customers. Add support for Vorbis and FLAC in the iPod.

Sincerely, 
Ivo Emanuel Gonçalves

===Letter to Microsoft regarding Windows===
Dear Microsoft,

Through this letter, I, Ivo Emanuel Gonçalves, would like to request you to support other digital formats in Windows, namely Vorbis, FLAC, Speex, Theora, and XSPF. I'm one of your users and, as such, I believe I have a say on what I'd like you to provide me, after all, Microsoft exists to provide services for the people.

Now, as you may have guessed, I took the time to put this letter together because I really want this feature, I really want Windows to be able to play the digital formats that I like. I have my media under those formats, and so I believe I have the right to at least ask if my favorite product could one day support my media.

I'm pretty sure your fine technicians already know these formats I've mentioned above, but I'll make a brief introduction to each of them, so you'll understand why I have chosen them to store and encode my media.

Vorbis, commonly known as Ogg, because of its container format, is a lossy audio codec with higher quality over MP3 and WMA. It also streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

FLAC is a lossless audio codec with high compression. It stores songs with all quality possible. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

Speex is an audio codec for speech. It can be used for both audio books and VoIP, among other things. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

Theora is an advanced video codec like MPEG 4. It streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

XSPF is a playlist format based on XML with a lot of features that make life easier for both consumers and vendors. It's simple, cute and mean. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Vorbis 
//en.wikipedia.org/wiki/FLAC 
//en.wikipedia.org/wiki/Speex 
//en.wikipedia.org/wiki/Theora 
//en.wikipedia.org/wiki/XSPF

So, please, dear Microsoft. Be kind enough to consider my request. Outdo your competition, hear the voices of your users. Add support for Vorbis, FLAC, Speex, Theora, and XSPF in Windows.

Sincerely, 
Ivo Emanuel Gonçalves

=== Letter to Samsung regarding YP-xx player series ===

Dear Samsung,

Through this letter, I, Ivo Emanuel Gonçalves, would like to request you to support other digital formats in your portable audio and video players, namely Vorbis, FLAC, and for video players also Theora. I'm one of your users and, as such, I believe I have a say on what I'd like you to provide me, after all, Samsung exists to provide services for the people.

Now, as you may have guessed, I took the time to put this letter together because I really want this feature, I really want my portable player to be able to play the digital formats that I like. I have my media under those formats, and so I believe I have the right to at least ask if my favorite product could one day support my media.

I'm pretty sure your fine technicians already know these formats I've mentioned above, but I'll make a brief introduction to each of them, so you'll understand why I have chosen them to store and encode my media.

Vorbis, commonly known as Ogg, because of its container format, is a lossy audio codec with higher quality over MP3 and WMA. It also streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

FLAC is a lossless audio codec with high compression. It stores songs with all quality possible. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

Theora is an advanced video codec like MPEG 4. It streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Vorbis 
//en.wikipedia.org/wiki/FLAC 
//en.wikipedia.org/wiki/Theora 

So, please, dear Samsung. Be kind enough to consider my request. Outdo your competition, hear the voices of your users. Add support for Vorbis, FLAC, and Theora.

Sincerely, 
Ivo Emanuel Gonçalves

=== Letter to NIKON regarding digital cameras ===

Dear NIKON,

Through this letter, I, Ivo Emanuel Gonçalves, would like to request you to support other digital formats in your cameras, namely Theora and HuffYUV or Lagarith. I'm one of your users and, as such, I believe I have a say on what I'd like you to provide me, after all, NIKON exists to provide services for the people.

Now, as you may have guessed, I took the time to put this letter together because I really want this feature, I really want my camera to output movies in free and optionally also lostless digital formats that I like, rather than formats being both proprietary and lossy. I have my media under those formats, and so I believe I have the right to at least ask if my favorite product could one day produce such media more easily and directly.

I'm pretty sure your fine technicians already know these formats I've mentioned above, but I'll make a brief introduction to each of them, so you'll understand why I have chosen them to store and encode my media.

Theora is an advanced video codec like MPEG 4. It streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Theora 

So, please, dear NIKON. Be kind enough to consider my request. Outdo your competition, hear the voices of your users. Add support for Theora and free lostless video codecs in your products.

Sincerely, 
Ivo Emanuel Gonçalves

=== Letter to Creative regarding soundcards and soundchips ===

Dear Creative,

Through this letter, I, Ivo Emanuel Gonçalves, would like to request you to publicly provide full technical documentation of your soundcards and soundchips, rather that "windows" codecs only.

Now, as you may have guessed, I took the time to put this letter together because this issue is really important for me, I really want to play my media stored in free formats using alternative OS'es, rather than play "windows"-friendly media on "windows".

Examples of free media formats:

Vorbis, commonly known as Ogg, because of its container format, is a lossy audio codec with higher quality over MP3 and WMA. It also streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

FLAC is a lossless audio codec with high compression. It stores songs with all quality possible. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

Speex is an audio codec for speech. It can be used for both audio books and VoIP, among other things. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

Theora is an advanced video codec like MPEG 4. It streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Vorbis 
//en.wikipedia.org/wiki/FLAC 
//en.wikipedia.org/wiki/Speex 
//en.wikipedia.org/wiki/Theora 

So, please, dear Creative. Be kind enough to consider my request. Outdo your competition, hear the voices of your users. Provide full documentation of your audio hardware, don't make alternative OS development unnecessarily difficult, let the users to choose their OS.

Sincerely, 
Ivo Emanuel Gonçalves

=== Letter to Play.com requesting Vorbis and FLAC ===

Dear Sirs,

I'd like to congratulate you on Play.com's recent decision to supply music downloads in a DRM-free format. By doing this you have made it easier for you customers to listen to the music they purchase using the player of their choice and I hope that they will reward you for this bold move.

But there is still something missing. Currently you offer your downloads in mp3 format; this was one of the first to become popular for digital music and hence has widespread support, but mp3 is still covered by a multitude of patents which makes it illegal in places to play it with open source software. In addition, though I clearly don't know what your commercial arrangements are, I can guess that you must pay a licensing fee to use the mp3 format. It's for this reason that open media formats such as (Ogg) Vorbis were developed.

Vorbis was designed as a patent-free format and is widely supported by open source software, with support on Windows, Linux and Macintosh platforms as well as support in many hardware players (from high-end manufacturers such as IRiver and Cowon to the “mp4 players” that predominate on eBay). It is now being used as the sound format for high profile projects like Wikipedia and One Laptop Per Child.

I'm not going to try to convince you that you should give up on mp3 and provide downloads in Vorbis instead, but I would ask that you consider supplying Vorbis as an alternative where practical. You may even, for high quality options, want to consider FLAC, a lossless counterpart to Vorbis. You have already taken a step towards regaining some of the trust between consumers and music stores; please consider the next one, I hope it will gain you an even wider audience.

If you would like any more information on Open Media Formats please get in touch with me or look at [http://www.spreadopenmedia.com www.spreadopenmedia.com].

Yours faithfully, 
Ian Malone

MailOgging

2008-03-18T23:55:58Z

Imalone: Add Play.com letter

This project is for the use of the average bloke (yes, you), who would like to further help and promote the use of your favorite free format. The MailOgging is a strategy to get the attention of hardware and software vendors who do not know the Ogg family, do not care about it, or do not know how many people care about it. The MailOgging provides free templates that you can use (and change according to your likeness) to create letters that you can then send to the corporations you want to nag. Nagging as many as you can is appreciated and gives you magical elite points.

==FAQ==
'''Q.''' Why should I do this? 
'''A.''' You tell me, but if you think it's worth it, if you want to support the Ogg family, and if you'd like to try making your voice heard, then there's your reasons. Most vendors never gave a damn about Xiph or free formats, so maybe it's time they hear some words from the community.

'''Q.''' Can I induce others to do the same? 
'''A.''' Now we are talking.

'''Q.''' Can I expand, modify and make corrections to the templates? 
'''A.''' But of course. The MailOgging is available in wiki format for this sole reason. Please help fix problems you see in the text, or further expand it. You can also suggest changes in the Talk page.

'''Q.''' What about translations? 
'''A.''' Sure. Go ahead and make them available here. There's lots of companies outside the English speaking world like Haier (China) and Samsung (Korea), and surely they would rather hear from customers on their homeland.

'''Q.''' Is this official, as in, part of the Xiph.Org Foundation? 
'''A.''' Yes, it's part of the [[SpreadOpenMedia|Spread Open Media]] iniative by [[User:Saoshyant|Ivo Emanuel Gonçalves]] and a few other goons.

'''Q.''' What are magical elite points? 
'''A.''' Oh, you'll find out when you get them.

'''Q.''' So, how do I use the templates? 
'''A.''' You need to change a few things in the template you want to use. After you are done, get either the physical address or e-mail address (or both) of the corporation you'd like to contact and send the letter.

Here's a list of things you'll need to replace in the text: 
* XXX = Name of the corporation, company, or person (e.g. Creative, Peter Pawlowski) 
* YYY = Your name. If you'll be using snail-mail, don't forget to sign the letter with a pen! 
* ZZZ = Name of the product (e.g. iTunes, Creative Zen, etc.)

You also need to know what formats you'll be requesting support for, since you'll need to edit out the template to remove what shouldn't be there. Don't forget that asking for all of them at once is probably not wise. The list is as follows:
* [[Vorbis]]
* [[FLAC]]
* [[Speex]]
* [[Theora]]
* [[XSPF]]

There's also a few slashes "/" so you can choose what's more appropriate for you and the letter. Don't forget to make decisions on what goes and what stays.

==The templates==
Dear XXX,

Through this letter, I, YYY, would like to request you to support other digital formats in the ZZZ, namely Vorbis, FLAC, Speex, Theora and XSPF. I'm one/I intend to become one of your customers/users and, as such, I believe I have a say on what I'd like you to provide me, after all, XXX exists to provide services for the people.

Now, as you may have guessed, I took the time to put this letter together because I really want this feature, I really want the XXX to be able to play the digital formats that I like. I have my music/videos/media under those formats, and so I believe I have the right to at least ask if my favorite product could one day support my media.

I'm pretty sure your fine technicians already know these formats I've mentioned above, but I'll make a brief introduction to each of them, so you'll understand why I have chosen them to store and encode my media.

Vorbis, commonly known as Ogg, because of its container format, is a lossy audio codec with higher quality over MP3 and WMA. It also streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the ZZZ play it.

FLAC is a lossless audio codec with high compression. It stores songs with all quality possible. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the ZZZ play it.

Speex is an audio codec for speech. It can be used for both audio books and VoIP, among other things. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the ZZZ play it.

Theora is an advanced video codec like MPEG 4. It streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the ZZZ play it.

XSPF is a playlist format based on XML with a lot of features that make life easier for both consumers and vendors. It's simple, cute and mean. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the ZZZ play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Vorbis 
//en.wikipedia.org/wiki/FLAC 
//en.wikipedia.org/wiki/Speex 
//en.wikipedia.org/wiki/Theora 
//en.wikipedia.org/wiki/XSPF

So, please, dear XXX. Be kind enough to consider my request. Outdo your competition, hear the voices of your customers/users. Add support for Vorbis, FLAC, Speex, Theora and XSPF in the ZZZ.

Sincerely, 
YYY

==A few examples==

===Letter to Apple regarding the iPod===
Dear Apple,

Through this letter, I, Ivo Emanuel Gonçalves, would like to request you to support other digital formats in the iPod, namely Vorbis and FLAC. I intend to become one of your customers and, as such, I believe I have a say on what I'd like you to provide me, after all, Apple exists to provide services for the people.

Now, as you may have guessed, I took the time to put this letter together because I really want this feature, I really want the iPod to be able to play the digital formats that I like. I have my music under those formats, and so I believe I have the right to at least ask if my favorite product could one day support my media.

I'm pretty sure your fine technicians already know these formats I've mentioned above, but I'll make a brief introduction to each of them, so you'll understand why I have chosen them to store and encode my media.

Vorbis, commonly known as Ogg, because of its container format, is a lossy audio codec with higher quality over MP3 and WMA. It also streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the iPod play it.

FLAC is a lossless audio codec with high compression. It stores songs with all quality possible. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have the iPod play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Vorbis 
//en.wikipedia.org/wiki/FLAC

So, please, dear Apple. Be kind enough to consider my request. Outdo your competition, hear the voices of your customers. Add support for Vorbis and FLAC in the iPod.

Sincerely, 
Ivo Emanuel Gonçalves

===Letter to Microsoft regarding Windows===
Dear Microsoft,

Through this letter, I, Ivo Emanuel Gonçalves, would like to request you to support other digital formats in Windows, namely Vorbis, FLAC, Speex, Theora, and XSPF. I'm one of your users and, as such, I believe I have a say on what I'd like you to provide me, after all, Microsoft exists to provide services for the people.

Now, as you may have guessed, I took the time to put this letter together because I really want this feature, I really want Windows to be able to play the digital formats that I like. I have my media under those formats, and so I believe I have the right to at least ask if my favorite product could one day support my media.

I'm pretty sure your fine technicians already know these formats I've mentioned above, but I'll make a brief introduction to each of them, so you'll understand why I have chosen them to store and encode my media.

Vorbis, commonly known as Ogg, because of its container format, is a lossy audio codec with higher quality over MP3 and WMA. It also streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

FLAC is a lossless audio codec with high compression. It stores songs with all quality possible. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

Speex is an audio codec for speech. It can be used for both audio books and VoIP, among other things. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

Theora is an advanced video codec like MPEG 4. It streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

XSPF is a playlist format based on XML with a lot of features that make life easier for both consumers and vendors. It's simple, cute and mean. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Vorbis 
//en.wikipedia.org/wiki/FLAC 
//en.wikipedia.org/wiki/Speex 
//en.wikipedia.org/wiki/Theora 
//en.wikipedia.org/wiki/XSPF

So, please, dear Microsoft. Be kind enough to consider my request. Outdo your competition, hear the voices of your users. Add support for Vorbis, FLAC, Speex, Theora, and XSPF in Windows.

Sincerely, 
Ivo Emanuel Gonçalves

=== Letter to Samsung regarding YP-xx player series ===

Dear Samsung,

Through this letter, I, Ivo Emanuel Gonçalves, would like to request you to support other digital formats in your portable audio and video players, namely Vorbis, FLAC, and for video players also Theora. I'm one of your users and, as such, I believe I have a say on what I'd like you to provide me, after all, Samsung exists to provide services for the people.

Now, as you may have guessed, I took the time to put this letter together because I really want this feature, I really want my portable player to be able to play the digital formats that I like. I have my media under those formats, and so I believe I have the right to at least ask if my favorite product could one day support my media.

I'm pretty sure your fine technicians already know these formats I've mentioned above, but I'll make a brief introduction to each of them, so you'll understand why I have chosen them to store and encode my media.

Vorbis, commonly known as Ogg, because of its container format, is a lossy audio codec with higher quality over MP3 and WMA. It also streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

FLAC is a lossless audio codec with high compression. It stores songs with all quality possible. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have Windows Media Player play it.

Theora is an advanced video codec like MPEG 4. It streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Vorbis 
//en.wikipedia.org/wiki/FLAC 
//en.wikipedia.org/wiki/Theora 

So, please, dear Samsung. Be kind enough to consider my request. Outdo your competition, hear the voices of your users. Add support for Vorbis, FLAC, and Theora.

Sincerely, 
Ivo Emanuel Gonçalves

=== Letter to NIKON regarding digital cameras ===

Dear NIKON,

Through this letter, I, Ivo Emanuel Gonçalves, would like to request you to support other digital formats in your cameras, namely Theora and HuffYUV or Lagarith. I'm one of your users and, as such, I believe I have a say on what I'd like you to provide me, after all, NIKON exists to provide services for the people.

Now, as you may have guessed, I took the time to put this letter together because I really want this feature, I really want my camera to output movies in free and optionally also lostless digital formats that I like, rather than formats being both proprietary and lossy. I have my media under those formats, and so I believe I have the right to at least ask if my favorite product could one day produce such media more easily and directly.

I'm pretty sure your fine technicians already know these formats I've mentioned above, but I'll make a brief introduction to each of them, so you'll understand why I have chosen them to store and encode my media.

Theora is an advanced video codec like MPEG 4. It streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Theora 

So, please, dear NIKON. Be kind enough to consider my request. Outdo your competition, hear the voices of your users. Add support for Theora and free lostless video codecs in your products.

Sincerely, 
Ivo Emanuel Gonçalves

=== Letter to Creative regarding soundcards and soundchips ===

Dear Creative,

Through this letter, I, Ivo Emanuel Gonçalves, would like to request you to publicly provide full technical documentation of your soundcards and soundchips, rather that "windows" codecs only.

Now, as you may have guessed, I took the time to put this letter together because this issue is really important for me, I really want to play my media stored in free formats using alternative OS'es, rather than play "windows"-friendly media on "windows".

Examples of free media formats:

Vorbis, commonly known as Ogg, because of its container format, is a lossy audio codec with higher quality over MP3 and WMA. It also streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

FLAC is a lossless audio codec with high compression. It stores songs with all quality possible. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

Speex is an audio codec for speech. It can be used for both audio books and VoIP, among other things. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

Theora is an advanced video codec like MPEG 4. It streams pretty well over the Internet. The specification is available free of charge, it's not encumbered with patents, and there's no need for you to pay royalties to have your devices play it.

But don't take my word for it. Wikipedia offers detailed articles that may be found at:

//en.wikipedia.org/wiki/Vorbis 
//en.wikipedia.org/wiki/FLAC 
//en.wikipedia.org/wiki/Speex 
//en.wikipedia.org/wiki/Theora 

So, please, dear Creative. Be kind enough to consider my request. Outdo your competition, hear the voices of your users. Provide full documentation of your audio hardware, don't make alternative OS development unnecessarily difficult, let the users to choose their OS.

Sincerely, 
Ivo Emanuel Gonçalves

=== Letter to Play.com requesting Vorbis and FLAC ===

Dear Sirs,

I'd like to congratulate you on Play.com's recent decision to supply music downloads in a DRM-free format. By doing this you have made it easier for you customers to listen to the music they purchase using the player of their choice and I hope that they will reward you for this bold move.

But there is still something missing. Currently you offer your downloads in mp3 format; this was one of the first to become popular for digital music and hence has widespread support, but mp3 is still covered by a multitude of patents which makes it illegal in places to play it with open source software. In addition, though I clearly don't know what your commercial arrangements are, I can guess that you must pay a licensing fee to use the mp3 format. It's for this reason that open media formats such as (Ogg) Vorbis were developed.

Vorbis was designed as a patent-free format and is widely supported by open source software, with support on Windows, Linux and Macintosh platforms as well as support in many hardware players (from high-end manufacturers such as IRiver and Cowon to the “mp4 players” that predominate on eBay). It is now being used as the sound format for high profile projects like Wikipedia and One Laptop Per Child.

I'm not going to try to convince you that you should give up on mp3 and provide downloads in Vorbis instead, but I would ask that you consider supplying Vorbis as an alternative where practical. You may even, for high quality options, want to consider FLAC, a lossless counterpart to Vorbis. You have already taken a step towards regaining some of the trust between consumers and music stores; please consider the next one, I hope it will gain you an even wider audience.

If you would like any more information on Open Media Formats please get in touch with me or look at [[http://www.spreadopenmedia.com|www.spreadopenmedia.com]].

Yours faithfully, 
Ian Malone

2007-09-20T19:22:21Z

Imalone: /* Granulepos mapping */

{{draft}}
Schemes such as [[MDMF]] require an embedding in physical Ogg streams. This page is for development of a specification for embedding XML streams in Ogg. The final version will probably look like the CMML mapping.

==Current plans==
(taken from mailing list discussions)

===Magic number?===

Should we have a magic number for this? By convention the beginning of stream packet for codecs in Ogg identifies the packet, Strictly speaking we will have a magic number regardless, but should it be:

* '<?xml' the opening of the XML declaration. In this instance the demuxer would pass this upwards to an XML parser which would derive from the rest of the bos packet what to do with it.

* Some other sequence before the XML starts, identifying the particular stream type, probably with a version number which will imply the contents to be some form of XML. CMML does this. This may avoid the almost inevitable problem of some implementor assuming '<?xml' is always metadata, it may also reduce the difficulty of writing a demuxer. Demuxers could still peek ahead and try to look of an xml namespace it recognizes.

===Division into packets===

The raw XML should ideally be broken into packets in a way that the loss of some packets, while destroying information, does not result in an invalid stream. Generally this means:

* The bos packet should consist of any initial processing directives, namespace declarations, and the root tag if there is one.
* Subsequent packets should be valid xml stanzas, similar to the [http://xmpp.org/ XMPP] definition, which concatenated are also valid xml.
* The eos packet can be empty. If there was a root tag in the bos packet, it should be closed here.

Parsers should close all open tags on encountering eos to handle truncated stream conditions. Encountering eos here means either a after processing a packet marked with the eos flag, having finished on an Ogg page with the eos flag set, or a virtual eos, implied by encountering bos flags for a new chain segment.

===Granulepos mapping===

c.f. Silvia Pfeiffer on [http://lists.xiph.org/pipermail/ogg-dev/2007-September/000570.html ogg-dev]:
<blockquote>I suggest using the solution that CMML has come to use.

The XML file is essentially the same as an unencapsulated physical bitstream.

Then there is a mapping into a logical bitstream, where some of the
default information - in particular the XML header - are split off and
put into the bos packet - nothing really needs to go into the eos
packet. There's also a magic number and a version number.

Also, use the granulepos scheme that we defined for CMML pages- you're
going to make your lives easier.</blockquote>

That is, use a split granulepos scheme like keyframe codecs to indicate the offset to the previous packet.
Whether this is appropriate for a given XML steam will depend on its application. Metadata that applies
to the whole stream should just be included at the beginning, like OggSkeleton, and the granulepos can just
all be zero. Time-based data, like a slideshow or 'currently playing' for radio streams, should be muxed
throughout the stream.

Given that the CMML mapping would be sensible should we simply hijack
CMML for this use (i.e. just put the metadata XML in a CMML stream?
Arguments against this: it means stream parsing is needed to find out
whether the CMML stream contains metadata too and possibly complicates
CMML handling. If not hijacking CMML it might be worth having a flag
indicating whether the stream is continuous or secondary header only.

==Test Files==
It is a barrier to the widespread introduction of any metadata format that the [http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html Vorbis I spec] only requires players to support an unaccompanied [[Vorbis]] stream; many [[Ogg]] [[Vorbis]] players will refuse to play augmented streams, especially if the content is not recognised (although many recent players do succeed). As a prelude to development of an [[Ogg]] metadata format it will be necessary to encourage developers to introduce more flexible [[Ogg]] filters.

To help with testing the following files are available, based on a speculative (and very basic) metadata format. In each case the derivative files are under the same license as the original. Two sets are provided to allow chained stream testing. On some players the seek tests produce an annoying clicking—if you like the music get the originals. Please notice that filenames are mixed case
and add a note in discussion if you find a broken link.

Original (Vorbis I): [http://music.ibiblio.org/pub/multimedia/pandora/vorbis/contrib/Debbie_Hu/Bach-Busoni_Nun_freut_euch_3.ogg Bach - Nun freut euch lieben Christen] performed by Debbie Hu, from [http://music.ibiblio.org/pub/multimedia/pandora/mp3/Read.html Pandora Records] and available under the [http://www.eff.org/IP/Open_licenses/eff_oal.php EFF OAL].
* The [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.rdf.ogg Ogg-Vorbis-XML version]
* The XML/RDF description as a [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.xml separate document]
* With the XML page [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.multi.ogg repeated after every fifth Vorbis page]. (This is not a suggested way to add meta data, just a way of testing how players handle seeking in the presence of an unknown stream.)
* With the XML page repeated after every fifth Vorbis page and the [http://www.srcf.ucam.org/~ibm21/Bach-Busoni_Nun_freut_euch_3.end.ogg stream ending on a meta data page] (breaks simpler track-length strategies, again not a suggested format for metadata)

Original (Vorbis I): [http://ccmixter.org/media/files/disharmonic/2958/ On The Moon (Trip Hop mix)] by [http://ccmixter.org/media/people/disharmonic/ Disharmonic], from [http://ccmixter.org/ ccMixter] and available under the Creative Commons [http://creativecommons.org/licenses/by/2.5/ Attribution 2.5] license.
* The XML/RDF description as a [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).xml separate document]
* With the XML page [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).multi.ogg repeated after every fifth Vorbis page].
* With the XML page repeated after every fifth Vorbis page and the [http://www.srcf.ucam.org/~ibm21/disharmonic_-_On_The_Moon_(Trip_Hop_mix).end.ogg stream ending on a meta data page]

2007-09-14T15:32:10Z

Imalone: /* [VorbisComment Vorbiscomments] */ wikiwords; hate 'em

This page aims to give an overview of the current state of metadata in Ogg and the ongoing projects towards improving it. There is ongoing discussion on implementing the Media Description and Metadata for the Ogg Container Format.

==[[VorbisComment|Vorbiscomments]]==

All the Xiph.org codecs have some internal mechanism for including metadata about the current stream.
Generally, this is one of the codec headers, and in the words of the [http://www.xiph.org/vorbis/doc/v-comment.html vorbis spec],
"It is meant for short, text comments...much like someone jotting a quick note on the bottom of a CDR."

Vorbiscomments store metadata describing the stream in key=value pairs, such as "ARTIST=Elvis", "TITLE=Blue Suede Shoes". Multiple copies of any given key are allowed (for example you can specify ARTIST several times for multiple performers). The specification has several suggested keys: TITLE, VERSION, ALBUM, TRACKNUMBER, ARTIST, PERFORMER, COPYRIGHT, LICENSE, ORGANIZATION, DESCRIPTION, DATE, LOCATION, CONTACT, ISRC. See the [http://www.xiph.org/vorbis/doc/v-comment.html specification] for the intent of each one.

The [[VorbisComment]] page contains improvements to the suggested comment set.

==Improved metadata==

Vorbiscomments work well enough for most things, and can be overloaded/abused (depending on your point of view) for most other things. But there are three major requirements that point to the design of an external metadata format; one that can be interleaved with the other streams in a container.

* ''Machinability'' There are a number of items of metadata that a player will want to parse and take action on. While there are usually 'convention' schemes for doing this with the embedded comment headers, this is much easier if there is a separate metadata stream designed for such use, instead of having to do best-effort parsing of natural language comments. For example, a video file with multiple audio tracks can specify the language of each one; a player than can parse these reliably can match them against a language preference list configured by the user to automatically select and begin playback of the best option.

* ''Kitchen Sink'' There are a minority of people who care passionately about having every detail about a track available. In the sense of conserving such information, and providing an equivalent to liner notes for online distribution, this is a goal worth supporting. However, the simple unstructured key-value pairs offered by the inline metadata are unwieldy for this level of detail. How do you tell the 2nd unit Assistant Director from the USA unit Assistant Director? How do you indicate which artist played tenor sax in the solo?

* ''Addressability'' The internal comment metadata headers are by necessity attached to a single content stream. This is useful for some appication, but a limitation in others. In a multiplexed stream, which set of comments refers to the collection as a whole? (By convention, in Ogg, it's the first logical bitstream occuring, but we can do better.) A separate metadata stream type must address this issue of collective metadata while still allowing description of individual streams. It should also allow temporal addressability, so that changes can be described. Because the in-stream comment metadata are part of the codec headers, it cannot change over the course of the stream, and allowing additional comment packets elsewhere in the stream presents seeking challenges. In the Ogg container this can be resolved by inserting a chain boundary, but this is a poor option for very-low-bitrate streams and unreliable transports such as RTP.

== Mechanisms ==

* [[VorbisComment]], basic cataloguing information.

* [[Ogg_Skeleton]] is emerging as the way to approach machineable metadata.

* [[MDMF|Media Description and Metadata for the Ogg Container Format]] (MDMF), a proposal for an extensive metadata format based on XML.

* RDF + dublin core

* XML-encoding (options include generic rdf, [[CMML]] and [http://www.adobe.com/products/xmp/ XMP])

* MusicBrainz [http://wiki.musicbrainz.org/MusicBrainzXMLMetaData XML MetaData]

Suggestions for features or applications are welcome at the
[http://lists.xiph.org/mailman/listinfo/ogg-dev Ogg-dev] mailing list
or on this entry's [[Talk:metadata|Talk]] page.

Metadata

2007-09-14T15:31:39Z

Imalone:

This page aims to give an overview of the current state of metadata in Ogg and the ongoing projects towards improving it. There is ongoing discussion on implementing the Media Description and Metadata for the Ogg Container Format.

==[VorbisComment Vorbiscomments]==

All the Xiph.org codecs have some internal mechanism for including metadata about the current stream.
Generally, this is one of the codec headers, and in the words of the [http://www.xiph.org/vorbis/doc/v-comment.html vorbis spec],
"It is meant for short, text comments...much like someone jotting a quick note on the bottom of a CDR."

Vorbiscomments store metadata describing the stream in key=value pairs, such as "ARTIST=Elvis", "TITLE=Blue Suede Shoes". Multiple copies of any given key are allowed (for example you can specify ARTIST several times for multiple performers). The specification has several suggested keys: TITLE, VERSION, ALBUM, TRACKNUMBER, ARTIST, PERFORMER, COPYRIGHT, LICENSE, ORGANIZATION, DESCRIPTION, DATE, LOCATION, CONTACT, ISRC. See the [http://www.xiph.org/vorbis/doc/v-comment.html specification] for the intent of each one.

The [[VorbisComment]] page contains improvements to the suggested comment set.

==Improved metadata==

Vorbiscomments work well enough for most things, and can be overloaded/abused (depending on your point of view) for most other things. But there are three major requirements that point to the design of an external metadata format; one that can be interleaved with the other streams in a container.

* ''Machinability'' There are a number of items of metadata that a player will want to parse and take action on. While there are usually 'convention' schemes for doing this with the embedded comment headers, this is much easier if there is a separate metadata stream designed for such use, instead of having to do best-effort parsing of natural language comments. For example, a video file with multiple audio tracks can specify the language of each one; a player than can parse these reliably can match them against a language preference list configured by the user to automatically select and begin playback of the best option.

* ''Kitchen Sink'' There are a minority of people who care passionately about having every detail about a track available. In the sense of conserving such information, and providing an equivalent to liner notes for online distribution, this is a goal worth supporting. However, the simple unstructured key-value pairs offered by the inline metadata are unwieldy for this level of detail. How do you tell the 2nd unit Assistant Director from the USA unit Assistant Director? How do you indicate which artist played tenor sax in the solo?

* ''Addressability'' The internal comment metadata headers are by necessity attached to a single content stream. This is useful for some appication, but a limitation in others. In a multiplexed stream, which set of comments refers to the collection as a whole? (By convention, in Ogg, it's the first logical bitstream occuring, but we can do better.) A separate metadata stream type must address this issue of collective metadata while still allowing description of individual streams. It should also allow temporal addressability, so that changes can be described. Because the in-stream comment metadata are part of the codec headers, it cannot change over the course of the stream, and allowing additional comment packets elsewhere in the stream presents seeking challenges. In the Ogg container this can be resolved by inserting a chain boundary, but this is a poor option for very-low-bitrate streams and unreliable transports such as RTP.

== Mechanisms ==

* [[VorbisComment]], basic cataloguing information.

* [[Ogg_Skeleton]] is emerging as the way to approach machineable metadata.

* [[MDMF|Media Description and Metadata for the Ogg Container Format]] (MDMF), a proposal for an extensive metadata format based on XML.

* RDF + dublin core

* XML-encoding (options include generic rdf, [[CMML]] and [http://www.adobe.com/products/xmp/ XMP])

* MusicBrainz [http://wiki.musicbrainz.org/MusicBrainzXMLMetaData XML MetaData]

Suggestions for features or applications are welcome at the
[http://lists.xiph.org/mailman/listinfo/ogg-dev Ogg-dev] mailing list
or on this entry's [[Talk:metadata|Talk]] page.