[gst-devel] tags and metadata

[Thomas Vander Stichele]

El jue, 22-01-2004 a las 16:04, in7y118 at public.uni-hamburg.de escribió:
> Quoting David Schleef <ds at schleef.org>:
> 
> > "length" in an id3 tag doesn't somehow magically become metadata.
> > 
> Thomas described streaminfo as something that can only be changed by 
> reencoding. The id3 length tag can easily be changed without reencoding and I 
> asume Rhythmbox is going to that

The id3 spec is not the be-all-end-all.  Having length in id3 is a hack
- length is something that should be queriable through the framework. 
The reason it's in the completely overengineered id3v2 spec is because
there were too many libs/programs calculating the length in the wrong
way :) Also, in some cases it can be an expensive operation to calculate
the length of a file.  So an id3 tag was added in the hopes that people
would keep it up-to-date with the actual file content.

I'd like to think we can at least agree that the length tag from id3 is
to be considered metadata in this case, since changing it doesn't
automatically make the file itself grow smaller :) Sure, you're free to
put the wrong value in all of your audio files.

Anyways, arguing things have to be a certain way because of a spec like
id3v2 is not productive for me.  I am very interested though in how you
are going to implement support for

4.14.   Attached picture

   This frame contains a picture directly related to the audio file.


> Another interesting thing are stuff like bitrates. It is easily changeable and 
> user might even want to change it so it mirrors the actual bitrates (nominal 
> bitrate in a vorbis stream for example), but if it's streaminfo, you can't 
> change it.

It's the other way around.  There are properties that are part of the
encoded format which by definition you cannot change by wishing it to be
different.  You can query a vorbis file for its average bitrate, but you
cannot set it to a different average bitrate.  It might be possible that
the nominal/minimum/maximum bitrate is changeable by changing the bytes
in the file, but AFAICT from the API you cannot just - and aren't meant
to - change these values.  I might be wrong for nominal, but it would at
the very least be weird for minimum and maximum bitrates.

Anyway, feel free to quote the relevant bits from specs and so on.  But,
while I'm happy you're addressing some of the theoretical concerns,
right now I'm concerned with fixing up the applications using GStreamer
so they have their functionality back.  So I don't feel like going into
a legal-like discussion about semantics.

> Well, this depends on how narrow you define streaminfo and metadata. If you 
> define streaminfo as "possible to extract by looking at stream" and metadata 
> as "needs additional info external to stream" I can offer you "language" (you 
> can easily tell what language some text is told in without additional info, 
> it's just that there's no GStreamer that can do this yet)

Not sure.  How about a Sigur Ros song ? What language is it in and how
do you detect it ? What about songs in more than one language ? It's not
as clearcut as you make it out.  Anyway, not sure what you're getting
at.  My idea is that there are streaminfo properties which could, for
whatever reason, be implemented as metadata, ie outside of the stream,
using some mechanism to tag this value onto the data.  That's how it's
historically been done.

>  or "average bitrate" 
> (there's no way to figure that out in unlimited vbr streams such as iradio 
> without additional info) for a start.

One way is to measure it.  Another way is to signal it out-of-band. 
Another way is to signal it in-stream.  But it doesn't mean it just
magically becomes metadata like artist or title is.
Anyway, the only time when average vbr on a network stream has some
meaning is when the streamer tries to minimize differences across
medium-sized intervals.  Ie, if a station broadcasts five songs, and
each of them have a VBR that is wildly different from the others, then:
- the station doesn't have an intended average bitrate at all
- the listener measures an average bitrate that's a value over the five
broadcasted songs
- this value will be different from each of the ABR values that could
have been signalled in-band with the songs

Basically, the average bitrate has lost a lot of its meaning if the
broadcaster doesn't actively limit its transmission to make the global
ABR match the short-term ABR.  But again, what's the point you're trying
to make ?
 
> Anyway, I removed the streaminfo/metadata distinction for a reason. And that 
> reason was I couldn't easily tell what is what for the general case.

I am sure that with some effort you can see, and understand why some
users perceive, a natural difference between the title of the track and
the average bitrate or the encoder version used.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Will you take me for a ride
The one that never ends
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/