The biggest problem with Vorbis comments are too loose specifications and too little standardisation. Another problem is attribution of involved parties. Currently only the ARTIST field name is supported in software. More standardised field names need to be worked out for organisations and persons involved in the production of the recording. See: http://wiki.xiph.org/index.php/VorbisComment#Attributing_involved_parties I have made a some suggestions, but as I have said earlier: Vorbis comments are no good when it comes to including information about musicans, labels, and other involved persons and organisations. A XML replacement to Vorbis comments would provide better mechanisms for defining this. On Wednesday 12. September 2007 05:10:12 Conrad Parker wrote:> On 12/09/2007, Ian Malone <ibmalone@gmail.com> wrote: > > So wiki discussion on the new metadata format > > is ongoing. I'd like to move some things about > > a bit. > > Hi Ian, > > I find the existing Metadata page a bit waffly, and I think we could > improve it to be more constructive. > > Perhaps it should simply give a very brief introduction to how we > approach metadata, and links to the various wiki pages relating to the > various mechanisms and proposals. > > It seems that what we are working towards is a collection of mutually > supportive mechanisms for storing metadata, rather than attempting > some kind of "kitchen sink" solution. So, my concern is that we should > make that clear rather than giving the impression that the various > "proposed solutions" are competing against each other. > > In hindsight, each of us seems to be concentrating on different > aspects of "metadata", and encouraging co-operation based on loose > coupling might be a good way forward. > > As an example, Ogg Skeleton and CMML were designed (after some trial > and error) to be independent, ie. any Ogg stream can happily include > only one or both depending on need, and without any expectation of > overriding VorbisComment. > > New formats such as MDMF which fill a given need can be designed to > usefully work alongside these existing mechanisms, and the scope of > the Metadata wilki page should be to clarify the overall design.-- Daniel Aleksandersen
On 14/09/2007, Daniel Aleksandersen <aleksandersen+xiphlists@runbox.com> wrote:> The biggest problem with Vorbis comments are too loose specifications and > too little standardisation. > > Another problem is attribution of involved parties. Currently only the > ARTIST field name is supported in software. More standardised field names > need to be worked out for organisations and persons involved in the > production of the recording. See: > http://wiki.xiph.org/index.php/VorbisComment#Attributing_involved_parties > > I have made a some suggestions, but as I have said earlier: Vorbis comments > are no good when it comes to including information about musicans, labels, > and other involved persons and organisations. A XML replacement to Vorbis > comments would provide better mechanisms for defining this. >Ultimately the current situation derived from mp3s, where the tags were inserted by end users who put in as much or little info as they cared about into a format which, at the time, only allowed basic tags like Artist, Title &c. With the advent of online music stores the contents have become a bit more dependable but they still follow the old model. Vorbis comments could do better than they currently do but no-one seems compelled to implement any of the exotic tag proposals that have hung around for years. An XML replacement not only allows richer information but allows the creation of a framework where even the basic information might be made more useful. -- imalone
On Friday 14. September 2007 16:52:52 Ian Malone wrote:> On 14/09/2007, Daniel Aleksandersen <aleksandersen+xiphlists@runbox.com>wrote:> > The biggest problem with Vorbis comments are too loose specifications > > and too little standardisation. > > > > Another problem is attribution of involved parties. Currently only the > > ARTIST field name is supported in software. More standardised field > > names need to be worked out for organisations and persons involved in > > the production of the recording. See: > > http://wiki.xiph.org/index.php/VorbisComment#Attributing_involved_parti > >es > > > > I have made a some suggestions, but as I have said earlier: Vorbis > > comments are no good when it comes to including information about > > musicans, labels, and other involved persons and organisations. A XML > > replacement to Vorbis comments would provide better mechanisms for > > defining this. > > Ultimately the current situation derived from mp3s, where > the tags were inserted by end users who put in as much > or little info as they cared about into a format which, at > the time, only allowed basic tags like Artist, Title &c. With > the advent of online music stores the contents have become > a bit more dependable but they still follow the old model. > Vorbis comments could do better than they currently do > but no-one seems compelled to implement any of the exotic > tag proposals that have hung around for years. An XML > replacement not only allows richer information but allows > the creation of a framework where even the basic information > might be made more useful.Another point here is that a replacement format would force software developers to acknowledge the existence of more advanced metadata. Adding and refining the excising comments model would be more ?optional?. (If anyone got that point?) -- Daniel Aleksandersen
On 14 Sep 2007 at 15:52, Ian Malone wrote:> Vorbis comments could do better than they currently do > but no-one seems compelled to implement any of the exotic > tag proposals that have hung around for years.Exotic tag proposals?! Do you mean the ones linked from the wiki? As far can tell, the only roadblock to "implementation" (by which, I assume you mean support from players) is their unofficial status. -- -:-:- David K. Gasaway -:-:- Email: dave@gasaway.org -:-:- Web : dave.gasaway.org
On 14/09/2007, Daniel Aleksandersen <aleksandersen+xiphlists@runbox.com> wrote:> The biggest problem with Vorbis comments are too loose specifications and > too little standardisation. >> I have made a some suggestions, but as I have said earlier: Vorbis comments > are no good when it comes to including information about musicans, labels, > and other involved persons and organisations. A XML replacement to Vorbis > comments would provide better mechanisms for defining this. >Incidentally, and bearing in mind kfish's comment about complimentary technologies, the wiki is accumulating comments about metadata streams replacing vorbiscomment. I don't think this is realistic for several reasons. The most obvious is simplicity; both of implementation and use. Even given a working media description metadata framework vorbiscomments are significantly simpler to implement and interpret, and they survive (de-)muxing of streams much more readily. XML metadata interpetation would require a lot of support components. It's made more difficult by one of the things that would be most useful, the inclusion of non-Xiph metadata types. vorbiscomments also give a simple handle for things like 'currently playing'. In fact working XML metadata would possibly make vorbiscomments more useful too. I could fill in artist and title tags according to what I wanted my portable player to display, confident that the precise information (composer, performer etc.) is still neatly stored away. The widespread support for vorbiscomments is another issue: the entire installed Vorbis base (I list only Vorbis because I don't know too much about the rest, but it's likely similar) uses vorbiscomments. Existing encodes with any kind of metadata mostly use them (excepting crazy people who try to apply ID3 or APE). Finally there's no current media metadata stream implementation. Until we know what it looks like it's really too early to claim what it will do. In conclusion metadata streams certainly wont replace vorbiscomment any time soon and there are good reasons to believe they never will (remember we can't make the end-product implementor *do* anything). Unless there's a very strong argument I've missed. -- imalone