"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 -- "This is only temporary... unless it works." _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
