PDA

View Full Version : metadata musings



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

michael
2005-04-06, 17:45
"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

--
"Pinky, are you pondering what I'm pondering?"
"I think so, Brain, but isn't a cucumber that's small called a gherkin?"

Kevin O. Lepard
2005-04-06, 18:24
>I have to wonder though if it's worth the effort to define a new
>format, if slim is the only one using it?

If no one else has a good system in place, one that can handle
classical music, etc., that is poorly handled by ID3 tags, then I
think it might be useful.

Out of curiosity, does anyone know how the METADATA is formatted by
Slim Devices if they rip and convert your original CDs to FLAC?

Kevin
--
Kevin O. Lepard
kolepard (AT) charter (DOT) net

Happiness is being 100% Microsoft free.