PDA

View Full Version : metadata musings



Steinar Bjaerum
2005-04-05, 14:35
> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com [mailto:discuss-
> bounces (AT) lists (DOT) slimdevices.com] On Behalf Of michael
> Sent: 5. april 2005 21:52
> To: Slim Devices Discussion
> Subject: [slim] metadata musings
>
> Sean Goller <sean (AT) goller (DOT) net> writes:
> ...
> > While a useful hack, I'm not so thrilled about using the
> > vorbis CUESHEET tag to store metadata long-term, especially since
> > updating/modifying the data seems like a non-trivial process. (at
> > least, I haven't seen anything other than metaflac or foobar2000
> > that'll do it, and manipulating a multiline tag is annoying at best)
> > Overall it just seems better to separate the audiodata from the
> > metadata entirely.
> >
> > Right now I'm just trying to see if someone's got an existing schema
> > that gets me 90% of the way there so I can get things up and running
> > reasonably quickly. If I can do that, then I can see if I can make
> > slimserver deal with the archive setup. That gets me a fairly robust
> > music archive/jukebox like thing.
>
> For what it's worth, slimserver will read a musicbrainz xml
> description of the flac file out of an app block. The thing that
> isn't available yet is a tool to insert the xml into the flac. But
> I'm sure it would be easy to make it read an external version of that
> xml as well. And the tools to pull the data from musicbrainz would
> lend themselves well to inclusion in an automated system like what you
> describe.
>
> -michael
>

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:

I get artist/track information from freedb and have made a small script that
translates this information into files of the format:

ARTIST=Diana Krall
ALBUM=Live in Paris
YEAR=2002
GENRE=Jazz
TRACKNUMBER[1]=1
TITLE[1]=I Love Being Here With You
ARTIST[1]=Diana Krall
TRACKNUMBER[2]=2
TITLE[2]=Let's Fall in Love
ARTIST[2]=Diana Krall
TRACKNUMBER[3]=3
TITLE[3]='Deed I Do
ARTIST[3]=Diana Krall
TRACKNUMBER[4]=4
TITLE[4]=The Look of Love
ARTIST[4]=Diana Krall
TRACKNUMBER[5]=5
TITLE[5]=East of the Sun (and West of the Moon)
ARTIST[5]=Diana Krall
TRACKNUMBER[6]=6
TITLE[6]=I've Got You Under My Skin
ARTIST[6]=Diana Krall
TRACKNUMBER[7]=7
TITLE[7]=Devil May Care
ARTIST[7]=Diana Krall
TRACKNUMBER[8]=8
TITLE[8]=Maybe You'll Be There
ARTIST[8]=Diana Krall
TRACKNUMBER[9]=9
TITLE[9]='S Wonderful
ARTIST[9]=Diana Krall
TRACKNUMBER[10]=10
TITLE[10]=Fly Me to the Moon
ARTIST[10]=Diana Krall
TRACKNUMBER[11]=11
TITLE[11]=A Case of You
ARTIST[11]=Diana Krall
TRACKNUMBER[12]=12
TITLE[12]=Just the Way You Are
ARTIST[12]=Diana Krall

With the metaflac command
metaflac --import-tags-from=%tagFile% %flacFile%
this information is stored as

METADATA block #3
type: 4 (VORBIS_COMMENT)
is last: false
length: 1149
vendor string: reference libFLAC 1.1.1 20041001
comments: 40
comment[0]: ARTIST=Diana Krall
comment[1]: ALBUM=Live in Paris
comment[2]: YEAR=2002
comment[3]: GENRE=Jazz
comment[4]: TRACKNUMBER[1]=1
comment[5]: TITLE[1]=I Love Being Here With You
comment[6]: ARTIST[1]=Diana Krall
comment[7]: TRACKNUMBER[2]=2
comment[8]: TITLE[2]=Let's Fall in Love
comment[9]: ARTIST[2]=Diana Krall
comment[10]: TRACKNUMBER[3]=3
comment[11]: TITLE[3]='Deed I Do
comment[12]: ARTIST[3]=Diana Krall
comment[13]: TRACKNUMBER[4]=4
comment[14]: TITLE[4]=The Look of Love
comment[15]: ARTIST[4]=Diana Krall
comment[16]: TRACKNUMBER[5]=5
comment[17]: TITLE[5]=East of the Sun (and West of the Moon)
comment[18]: ARTIST[5]=Diana Krall
comment[19]: TRACKNUMBER[6]=6
comment[20]: TITLE[6]=I've Got You Under My Skin
comment[21]: ARTIST[6]=Diana Krall
comment[22]: TRACKNUMBER[7]=7
comment[23]: TITLE[7]=Devil May Care
comment[24]: ARTIST[7]=Diana Krall
comment[25]: TRACKNUMBER[8]=8
comment[26]: TITLE[8]=Maybe You'll Be There
comment[27]: ARTIST[8]=Diana Krall
comment[28]: TRACKNUMBER[9]=9
comment[29]: TITLE[9]='S Wonderful
comment[30]: ARTIST[9]=Diana Krall
comment[31]: TRACKNUMBER[10]=10
comment[32]: TITLE[10]=Fly Me to the Moon
comment[33]: ARTIST[10]=Diana Krall
comment[34]: TRACKNUMBER[11]=11
comment[35]: TITLE[11]=A Case of You
comment[36]: ARTIST[11]=Diana Krall
comment[37]: TRACKNUMBER[12]=12
comment[38]: TITLE[12]=Just the Way You Are
comment[39]: ARTIST[12]=Diana Krall

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?

Steinar

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

--
"This is only temporary... unless it works."

michael
2005-04-06, 12:16
"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

--
"This is only temporary... unless it works."