On 6/4/12, Benjamin M. Schwartz wrote:> On 06/04/2012 04:08 PM, Martin Leese wrote:...>> The optimal solution is described at: >> https://wiki.xiph.org/XMLEmbedding > > As that page says, "This page is for development of a specification for > embedding XML streams in Ogg.". "XML streams" are not simply XML > documents. They are _temporally subdivided_ XML documents, such as Jabber > (XMPP) conversation streams. > > I'm not an expert on XMP, but given that it's typically applied to still > images and PDF files, I'm pretty confident that XMP documents are not > meaningfully XML streams, so applying temporal muxing would not make sense.XMLEmbedding is intended for both XML files and XML streams. The former would be used with things like M3F and, in this case, would be stored near the start of the Ogg container before any audio/video data ("chained" and not "grouped"). There is a little more information on the Metadata page at: https://wiki.xiph.org/Metadata#XMLEmbedding M3F is another draft that seems to be moribund, having not been touched since 2008; visit: https://wiki.xiph.org/M3F>> However, this draft hasn't been touched since >> 2007. > > That's because, as it turns out, almost no one actually wants to mux > temporal XML streams into Ogg.Indeed, nobody has requested this. However, XMLEmbedding can accommodate it should it ever be so. On 6/5/12, Oleksij Rempel wrote: || We need fallowing tags: || creation datetime: seconds and time zone should be included. || source host: it can be name or guid. to organise created files by sources. || keywords,events. || date and person ho did transcription of record. To me, this looks like a job for three or more separate VorbisComments. You might want to choose keys which typically are not used for other things. For example, don't use DATE as this typically stores the date the track was recorded. Regards, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: http://members.tripod.com/martin_leese/
On 05.06.2012 20:41, Martin Leese wrote:> On 6/4/12, Benjamin M. Schwartz wrote: > >> On 06/04/2012 04:08 PM, Martin Leese wrote: > ... >>> The optimal solution is described at: >>> https://wiki.xiph.org/XMLEmbedding >> >> As that page says, "This page is for development of a specification for >> embedding XML streams in Ogg.". "XML streams" are not simply XML >> documents. They are _temporally subdivided_ XML documents, such as Jabber >> (XMPP) conversation streams. >> >> I'm not an expert on XMP, but given that it's typically applied to still >> images and PDF files, I'm pretty confident that XMP documents are not >> meaningfully XML streams, so applying temporal muxing would not make sense.it is not limited to images or pdf, see the link[2] gstreamer and tracker can handle xmp in jpeg. But there is no handlers for ogg. Since there is no ready documentation for xmp in ogg, the patches will no go upstream.> XMLEmbedding is intended for both XML files > and XML streams. The former would be used > with things like M3F and, in this case, would be > stored near the start of the Ogg container > before any audio/video data ("chained" and > not "grouped"). There is a little more > information on the Metadata page at: > https://wiki.xiph.org/Metadata#XMLEmbedding> M3F is another draft that seems to be > moribund, having not been touched since 2008; > visit: > https://wiki.xiph.org/M3F>>> However, this draft hasn't been touched since >>> 2007. >> >> That's because, as it turns out, almost no one actually wants to mux >> temporal XML streams into Ogg. > > Indeed, nobody has requested this. However, > XMLEmbedding can accommodate it should it > ever be so. > > > On 6/5/12, Oleksij Rempel wrote: > || We need fallowing tags: > || creation datetime: seconds and time zone should be included. > || source host: it can be name or guid. to organise created files by sources. > || keywords,events. > || date and person ho did transcription of record. > > To me, this looks like a job for three or more > separate VorbisComments. You might want to > choose keys which typically are not used for > other things. For example, don't use DATE as > this typically stores the date the track was > recorded. > > Regards, > MartinI do not like the idea of using separate VorbisComments, but i'll keep this option open. According to this documentation: [1] http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf we can use fallowing tags (page 39): dc:creator dc:date dc:description dc:identifier dc:source dc:subject xmpBJ:JobRef On this stage there is no more TAGS needed, but this list can be changed depending on experience we gather. This document show haw xmp can be used in work with audio and video: [2] http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/DynamicMediaXMPPartnerGuide.pdf -- Regards, Oleksij
Hi Oleksij, I agree with what everyone has said here: you should use VorbisComment for your solution, see existing fields at http://xiph.org/vorbis/doc/v-comment.html , extensions at http://wiki.xiph.org/VorbisComment , and the chapters that you are after at http://wiki.xiph.org/Chapter_Extension . Now you just need to find or write a software that supports it. On Wed, Jun 6, 2012 at 5:32 AM, Oleksij Rempel <bug-track at fisher-privat.net> wrote:> > we can use fallowing tags (page 39): > dc:creatorBe specific what the creator is supposed to be: ARTIST? PERFORMER? ORGANISATION? CONTACT? http://xiph.org/vorbis/doc/v-comment.html> dc:dateVorbisComment has DATE, see http://xiph.org/vorbis/doc/v-comment.html .> dc:descriptionVorbisComment has DESCRIPTION, see http://xiph.org/vorbis/doc/v-comment.html .> dc:identifierMaybe use TITLE or VERSION? http://xiph.org/vorbis/doc/v-comment.html> dc:sourceMaybe use ENCODED_BY? http://wiki.xiph.org/VorbisComment#Recommended_field_names> dc:subjectVorbisComment has TITLE or GENRE. http://xiph.org/vorbis/doc/v-comment.html> xmpBJ:JobRefThis seems to be some random comment field. Could go into VERSION? Not sure if this helps. But you should in general be able to find a mapping. Maybe this helps finding mappings: http://www.w3.org/TR/2012/REC-mediaont-10-20120209/ Cheers, Silvia.