> > "Steinar Bjaerum" <[EMAIL PROTECTED]> writes: > ... > > For what it's worth, I am a bit skeptical about how wise it is to > support > > too many formats/methods for embedding FLAC metadata. Isn't it better to > > chose one or a couple of formats for the embedded tags, and strive for > > perfect support of those formats instead of having a dozen of formats > > working 90%? > > > > There are a lot of different preferences about how to manage record > > collections and how to obtain metadata. With an agreement of what FLAC > > metadata formats that slimserver would support natively, it would be up > to > > the different users to interface/translate their preferred method of > > obtaining/storing metadata to the embedded tag format with official > support > > from slimdevices. > > > > As an example, this is what I do: > ... [example snipped] ... > > > I get artist/track information from freedb and have made a small script > that > > translates this information into files of the format: > > in the Flac file. These stacked vorbis comments are parsed by slimserver > and > > works for me. Using standard metaflac commands, it is relatively easy to > > modify/update the tags. > > > > What are your opinions about defining a limited API for Flac metadata > that > > is supported/maintained by slimdevices and let users develop/share > methods > > of interfacing to that API? > > There is no official metadata spec for flac. Josh/Xiph have > specifically declined to specify one. They did however give us Vorbis > Comments, which are "meant for short, text comments, not arbitrary > metadata". They are easy enough to work with though that in the > absence of a better alternative people are using them for metadata > anyway, and some defacto standards have emerged, at least for single > song tracks. When it comes to multi-song flac files, there is no one > method that's used enough yet for anything that convenient to have > happened. Until then, it seems prudent to at least support the > methods most used by other programs and users. > > It's easy to argue that cddb/freedb is the most used source for cd > metadata, but the format is so bad that it's tricky to even tell > artist from song title on some various artist albums. On the other > end of the spectrum there's the musicbrainz xml/rdf format which is > robust and extensible, but not widely used yet for actually tagging to > a file. Quoting again from the Vorbis Comment page, "arbitrary > metadata belongs in a separate logical bitstream (usually an XML > stream type) that provides greater structure and machine > parseability." So it seems that supporting something like musicbrainz > is worthwhile even if it's not widely used for tagging yet. > In between those extremes, there's only two methods I've seen used > widely enough to worry about. One is the practice of stuffing the > text form of the cuesheet (with CD-Text) into a Vorbis Comment, which > some popular programs have been known to do. The other is the > "numbered comments" you used in your example, (stacked comments mean > something different internally) which is preferred by people who are > tagging by hand, or with scripts that rely on metaflac. (Meaning that > multi-line Vorbis Comments are difficult at best.) > > I don't think that we should try to support every crazy tagging scheme > that some user comes up with, but supporting the small number that > seem widely used seems prudent, at least until one of them gains > enough usage to push the others out. > > > This is all just my opinion, and I certainly can't speak for > slimdevices for what they'll officially support. Although I suspect > that anything reasonable that comes with working code stands a fair > chance of getting considered. That's just a guess though. > > > -michael >
I am aware of the lack of an official metadata specification for flac. It is up to the user to put metadata in his preferred format into a METADATA block in the flac file. It is then up to the software accessing the flac file to parse the content of the METADATA block and extract the tags. In the case of slimserver there is parsing functionality for several different formats of tag information in the METADATA block. My intention with the previous post was to get some thoughts of what (and how many) formats that needs to be supported with parsing functionality internally in slimserver. Conceptually, there needs only to be one such supported format. This "slim format" could be xml based (multiline), it could be just numbered vorbis comments, or whatever. An advantage of the simple numbered vorbis comments is that it is readily supported by metaflac. If desired, I guess the METADATA block containing the data in "slim format" could coexist with another METADATA block containing the same information in another format that might be preferred by other applications. Accompanying the "slim format" there would have to be utilities for translating cddb/freedb, musicbrainz, or whatever format, to the "slim format", and for embedding this into the flac file. These utilities could be developed more or less independently of slimserver as long as the "slim format" is properly defined. I am not sure if anything is gained (with respect to flexibility, maintainability etc) by such a modularization of the software. Just some thoughts I had... Steinar _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
