> > "Steinar Bjaerum" <[EMAIL PROTECTED]> writes: > ... > > 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 get what you're saying. I have to wonder though if it's worth the > effort to define a new format, if slim is the only one using it? Or > are you suggesting picking one of the four previously mentioned, and > provide scripts to translate the other three (and perhaps others) into > the chosen one, instead of supporting each directly in the server? > What would be the advantage to the end user to make this translation, > in addition to whatever format they currently prefer? > > Just curious. > > -michael >
The chosen format could very well be one of the existing formats. Possible advantages of choosing a slim-preferred format: Easier maintainance resulting in rock solid operation, it might be easier for non-experts to develop the utilities than to do development inside slimserver itself, ... It could be that supporting/maintaining the different formats inside slimserver is not that big deal and that it is easy to get acceptance for inclusion of new formats. If so, it is probably not worth to pursue these ideas further. I guess you Michael are the best one to do such an assessment. Steinar _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
