Hi ogg-dev list, After discussing the [lack of] metadata standards on the irc://irc.freenode.net/#Vorbis channel yesterday I figured I had to contribute to this process. Attached is a sample XML formatted metadata sheet describing a song; and shows off other media type elements as well. How this is to be embedded in the OGG container is not my field. I have only spent a couple of hours making this sample. I would like to get feedback on initial thoughts about my sample XML file. The goal would be to describe one or multiple works (a motion picture, film clip, pop song, text, speech, ...) in a clear a way as possible. Look at it and tell me what you think. Below are details describing elements and attributes: First of all: Any element may occur multiple times. Except the container elements preformers, recording, and encoding as well as the title element. And no element or attribute is required except correct containers. So if you want to include a rights element it must appear inside audio:recording. There is no artist element! Nor is there a mechanism for suggesting values to populate the popular artist field in popular music management softwares. This is done deliberately, as I fail to see how one element (or one name) can sum up all work done to produce a performance. Instead persons and organisations involved in the process are described with a role attribute. Since many performances often are published on several medias (such as best of albums, and so on) I though it would be best to be able to say that one song can be part of multiple collection elements. This addresses my own personal irritation over modern music management softwares that they fail to realise that one song may appear on multiple albums; but I only want to have to store it once on my harddrive! The track attribute describe what track number the song has on that CD, and the tracks (plural) attribute describes how many songs that collection has. The encoding:source element was a tricky one. It has a media attribute that could be cd, phonerecording, or whatever. It could also point it's URI to another encoding:source element with a id attribute. The example file shows a file's encoding history by pointing back to the original media. Software may appear (as all elements can) multiple times. I would encourage only attributing the most recent software used. The biggest logical breaker is that date can be an attribute and an element. Should be changed. All suggestions and contributions are welcome!!! -- Daniel Aleksandersen -------------- next part -------------- <?xml version="1.0" encoding="UTF-8"?> <metadata xmlns="http://xmlns.xiph.org/media-metadata/0.1/" xml:base="./"> <video encoding="application/theora+ogg" /> <image encoding="application/svg+xml" /> <text encoding="text/plain" /> <audio encoding="application/flac+ogg" uri="audio.flac"> <title>Boys and Girls</title> <collection track="4" tracks="12" date="2007-01-08">Boy meats Girl</collection> <collection track="7" tracks="13" date="2019-02-08">Summer Hits 2019</collection> <preformers> <person role="vocals">Some Girl</person> <person role="guitar">Some Boy</person> <organisation role="ensemble">Some People in the Background</organisation> <person role="producer">Some People behind the Glass</person></preformers> <recording> <rights>? 2008 Recording Company</rights> <duration>253466</duration> <organisation role="publisher">Guys and Girls Int.</organisation> <organisation role="label" uri="http://recording-people.com/">Recording Company</organisation> <date>2007-01-08</date> <location>China, Earth</location></recording> <encoding> <date>2009-02-17</date> <quality bitrate="180" compression="best|fast|1-8" /> <source media="flac-file" uri="#ripping-cd" /> <source media="cd" uri="urn:x-isrc:0123456789" id="ripping-cd" /> <software title="flac" version="2.2" uri="http://xiph.org/flac/" /></encoding></audio></metadata>
Hey Daniel, I just wanted to write to say thank you for taking the time to work on this. It is desperately needed IMO. I will definitely look at this as soon as I have time and comment. I am a concert musician (what most ppl would call a "classical" musician) and every metadata format I've ever seen falls short for concert music. I am EXTREMELY busy (I'm writing this from work "shhh!!!") though so if you don't hear from me, please nudge me. Thanks, Rich(ard) On 9/6/07, Daniel Aleksandersen <aleksandersen+xiphlists@runbox.com> wrote:> Hi ogg-dev list, > > After discussing the [lack of] metadata standards on the > irc://irc.freenode.net/#Vorbis channel yesterday I figured I had to > contribute to this process. > > Attached is a sample XML formatted metadata sheet describing a song; and > shows off other media type elements as well. How this is to be embedded in > the OGG container is not my field. > > I have only spent a couple of hours making this sample. I would like to get > feedback on initial thoughts about my sample XML file. The goal would be to > describe one or multiple works (a motion picture, film clip, pop song, > text, speech, ...) in a clear a way as possible. Look at it and tell me > what you think. > > Below are details describing elements and attributes: > > First of all: Any element may occur multiple times. Except the container > elements preformers, recording, and encoding as well as the title element. > And no element or attribute is required except correct containers. So if > you want to include a rights element it must appear inside audio:recording. > > There is no artist element! Nor is there a mechanism for suggesting values > to populate the popular artist field in popular music management softwares. > This is done deliberately, as I fail to see how one element (or one name) > can sum up all work done to produce a performance. Instead persons and > organisations involved in the process are described with a role attribute. > > Since many performances often are published on several medias (such as best > of albums, and so on) I though it would be best to be able to say that one > song can be part of multiple collection elements. This addresses my own > personal irritation over modern music management softwares that they fail > to realise that one song may appear on multiple albums; but I only want to > have to store it once on my harddrive! The track attribute describe what > track number the song has on that CD, and the tracks (plural) attribute > describes how many songs that collection has. > > The encoding:source element was a tricky one. It has a media attribute that > could be cd, phonerecording, or whatever. It could also point it's URI to > another encoding:source element with a id attribute. The example file shows > a file's encoding history by pointing back to the original media. Software > may appear (as all elements can) multiple times. I would encourage only > attributing the most recent software used. > > The biggest logical breaker is that date can be an attribute and an element. > Should be changed. > > All suggestions and contributions are welcome!!! > -- > Daniel Aleksandersen > > _______________________________________________ > ogg-dev mailing list > ogg-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev > > >-- Richard Edward Horner Engineer / Composer / Electric Guitar Virtuoso rich@richhorner.com http://richhorner.com - updated June 28th
On 7 Sep 2007 at 1:03, Daniel Aleksandersen wrote:> This is done deliberately, as I fail to see how one element (or one name) > can sum up all work done to produce a performance. Instead persons andI agree that one field cannot contain *all* the information. But it can summarize the most important parts, with the detail stored elsewhere. "Most important" is very subjective, but still useful. :) -- -:-:- David K. Gasaway -:-:- Email: dave@gasaway.org -:-:- Web : dave.gasaway.org
Hi again list, Attached is a much improved version of yesterday's draft. Introducing the audio:collection:artwork element to deal with album cover graphics and such. After giving it much though; I decided to drop the audio:preformers and audio:recording elements. They have been replaced by audio:entities which is supposed to contain all involved organisations and persons. audio:recording:rights, :date, and other elements related to the recording have been changed to audio subsets. I got a question about the use of URNs for the URI attribute. URNs are a subset of the URI specification. I know there is no way of resolving URNs as of now. But I do mean they are a much better way to describe a physical resource than using a URL. A URN says ?what?, where a URL says ?where?. The x- suffix is present because the ISRC numbering is not a registered URN name space. Note that any URI can be used. For example a web music store may set the attribute to point to that particular song in their online catalogue. Example URI attribute describing a CD by it's ISRC number in a URN: urn:x-isrc:0123456789 I have looked closer at the Dublin Core, and MPEG-7 metadata. This XML format is very much more detailed than any of those formats. Compatibility and mapping against these older metadata formats will prove very difficult without loosing functionality of this format. (Which will make this format worthless.) Thoughts on this, anyone? I will create a page for discussing this format in the Xiph wiki in a couple of days. I had hoped to get some feedback and suggestions from the emailing lists before doing so. PS: I will stop development if no one shows any interest in this XML metadata project. So do send in your thoughts or tip off anyone that could be interested in this. -- Daniel Aleksandersen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20070907/0d555c8a/ogg-metadata-DRAFT.htm
Daniel Aleksandersen wrote:> Hi again list, > > Attached is a much improved version of yesterday's draft. Introducing the > audio:collection:artwork element to deal with album cover graphics and > such. > > After giving it much though; I decided to drop the audio:preformers and > audio:recording elements. They have been replaced by audio:entities which > is supposed to contain all involved organisations and persons. > audio:recording:rights, :date, and other elements related to the recording > have been changed to audio subsets. > > I got a question about the use of URNs for the URI attribute. URNs are a > subset of the URI specification. I know there is no way of resolving URNs > as of now. But I do mean they are a much better way to describe a physical > resource than using a URL. A URN says ?what?, where a URL says ?where?. The > x- suffix is present because the ISRC numbering is not a registered URN > name space. Note that any URI can be used. For example a web music store > may set the attribute to point to that particular song in their online > catalogue. Example URI attribute describing a CD by it's ISRC number in a > URN: urn:x-isrc:0123456789 >With metadata resolving doesn't matter very much anyway, what matters is uniquely identifying the resource.> I have looked closer at the Dublin Core, and MPEG-7 metadata. This XML > format is very much more detailed than any of those formats. Compatibility > and mapping against these older metadata formats will prove very difficult > without loosing functionality of this format. (Which will make this format > worthless.) Thoughts on this, anyone?Dublin Core was probably enough, except there wasn't quite enough flexibility in the defined relation types. A list of valid role types or a way to make them meaningful to software and still allow extension is important.> > I will create a page for discussing this format in the Xiph wiki in a couple > of days. I had hoped to get some feedback and suggestions from the emailing > lists before doing so. ><video encoding="application/theora+ogg" /> et cetera, I think you want to avoid duplicating technical metadata like this which is held in Ogg Skeleton. Within a stream anyway, maybe for separate description of media files it might be worthwhile. <artwork uri="#embedded-image" /> Being able to specify resources within an Ogg stream is something that would be useful. -- imalone
Hi list, I have created a page on the Xiph wiki[1] for the format. [1] http://wiki.xiph.org/index.php/MDMF I have also suggested a horrible, but what I thought to be a descriptive name for this work: Media Description and Metadata for the Ogg Container Format (MDMF) Please do contribute to the wiki and keep submitting ideas on the wiki page's discussion page [2] or here on the emailing list. [2] http://wiki.xiph.org/index.php?title=Talk:MDMF I will personally do my best to keep improving the format. But I do need help in many areas. I am especially interested to hear from musicians?still waiting for your input Richard Horner!?, developers, and generally people that know anything at all about the Ogg format, metadata, XML, and media. (That should cover just about everyone on the list?) Video, image, and text media elements does not have any children yet. Can anyone step up and make something similar to what I created for the audio element? A special thanks to Ralph Giles for suggesting to use Ogg serial numbers to describe unique resources in a stream. -- Daniel Aleksandersen
Hi ogg-dev list, I am not trying to ?get someone?. But I though this form would indeed prove successful in making my point. Here we go: I got accused of ?reinventing the wheel? for this little media description format of mine. Fare enough. But I wanted to show everyone why it is sometimes best to sometings that has been done before all over. See the attached document. It uses existing technology plus a new name space. I call my Frankenstein: XML+RDF+DC+M3F (or just M3F for short) or The Resource Description Format (RDF) built on the Extensible Markup Language (RDF) using the well recognised Dublin Core metadata set (DC) with the new Multimedia Metadata Format (M3F). As everyone can see from the attachment: Building an all new XML name space without using existing ones are probably the best way to go. Even though a limited number of elements will be borrowed from existing formats: It will keep things simple when using only one well defined name space. A good thing that came out of my childish experiment was a better name for the metadata format: Multimedia Metadata Format (or M3F). Oh! And if I ever write an autobiography: This email's subject will be it's title! At least the ?Why I reinvented the wheel? part. -- Daniel Aleksandersen -------------- next part -------------- A non-text attachment was scrubbed... Name: Example using XML, RDF, DC, and M3F.rdf Type: text/rdf Size: 1773 bytes Desc: not available Url : http://lists.xiph.org/pipermail/ogg-dev/attachments/20070910/2885169b/ExampleusingXMLRDFDCandM3F.bin
Daniel, nobody has accused you of reinventing the wheel. You give up too easily. If you want to develop a standard, it takes a lot of discussion and input - and it takes diplomacy. Attacking people and attacking the community will not be helpful. You have asked for feedback - feedback has been given. Now it's time to think and digest. I for one have been motivated by the topic of discussion, but am slowly losing interest because you don't seem to be willing to listen to the feedback you're receiving. Regards, Silvia. On 9/10/07, Daniel Aleksandersen <aleksandersen+xiphlists@runbox.com> wrote:> Hi ogg-dev list, > > I am not trying to 'get someone'. But I though this form would indeed prove > successful in making my point. Here we go: > > > I got accused of 'reinventing the wheel' for this little media description > format of mine. Fare enough. But I wanted to show everyone why it is > sometimes best to sometings that has been done before all over. See the > attached document. It uses existing technology plus a new name space. > > I call my Frankenstein: XML+RDF+DC+M3F (or just M3F for short) or The > Resource Description Format (RDF) built on the Extensible Markup Language > (RDF) using the well recognised Dublin Core metadata set (DC) with the new > Multimedia Metadata Format (M3F). > > As everyone can see from the attachment: Building an all new XML name space > without using existing ones are probably the best way to go. Even though a > limited number of elements will be borrowed from existing formats: It will > keep things simple when using only one well defined name space. > > > A good thing that came out of my childish experiment was a better name for > the metadata format: Multimedia Metadata Format (or M3F). > > Oh! And if I ever write an autobiography: This email's subject will be it's > title! At least the 'Why I reinvented the wheel' part. > -- > Daniel Aleksandersen > > _______________________________________________ > ogg-dev mailing list > ogg-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev > > >
Daniel Aleksandersen wrote:> Hi ogg-dev list, > > I am not trying to ?get someone?. But I though this form would indeed prove > successful in making my point. Here we go: >I think it's great someone is trying to work on this.> > I got accused of ?reinventing the wheel? for this little media description > format of mine. Fare enough. But I wanted to show everyone why it is > sometimes best to sometings that has been done before all over. See the > attached document. It uses existing technology plus a new name space. > > I call my Frankenstein: XML+RDF+DC+M3F (or just M3F for short) or The > Resource Description Format (RDF) built on the Extensible Markup Language > (RDF) using the well recognised Dublin Core metadata set (DC) with the new > Multimedia Metadata Format (M3F). >RDF always seems to magically make things less human-readable but if it adds utility then that might be a price worth paying. (Since, realistically, few people are going to attempt to read it themselves.) It's probably an oversight in this example, but: <m3f:person m3f:role="vocal instrument" dc:title="guitar and vocals">Jody Porter</person> <m3f:person m3f:role="instruments" dc:title="drums">Brian Young</person> Either 'instruments' or 'instrument', not both (and probably instrumental to be consistent with 'vocal'). However, this is splitting off vocals separate to other instruments. Possibly role='musician' with 'vocals' as the refinement. (I've got a small draft email on use cases to finish off.) -- imalone
Daniel Aleksandersen wrote:> Hi again list, > > Attached is a much improved version of yesterday's draft. Introducing the > audio:collection:artwork element to deal with album cover graphics and > such. > >Hi, One thing still missing is a subject/synopsis description. This would have little value for pop music, but for tracks from opera, tv programmes and films it would be useful. Also something like clips of birdsong would benefit greatly. -- imalone