PDA

View Full Version : metadata musings



Steinar Bjaerum
2005-04-06, 23:00
>
> "Steinar Bjaerum" <steinar.bjaerum (AT) online (DOT) no> 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

michael
2005-04-07, 11:39
"Steinar Bjaerum" <steinar.bjaerum (AT) online (DOT) no> writes:
....
>> 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?
....
>
> 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.

I don't know if I'm the best one for that. I just throw patches at the
slim folks every now and then. And I'm certainly not the only one that
messes around with that part of the code, so I'm probably not in a
position to make an accurate assessment.

As for me, I'd like to see a (mostly) standard format emerge too. So
far however the number of contenders has been small enough that it
hasn't been too much trouble. Especially since some of them are things
we deal with in the code anyway, such as parsing cuesheets.
As long as the number of supported formats goes down over time and not
up, we're probably in ok shape.

-michael

--
"kipple drives out nonkipple"