Fwd: ATF: Stop spreading FUD about other media players

[Joe Wreschnig]

On Thu, 2006-08-17 at 21:04 +0000, Jeff Mitchell wrote:
> I realized I didn't hit Reply to All and don't know if you're on the list.

Thank you; I'm not.

> Quoting Joe Wreschnig <piman at sacredchao.net>:
> > I've seen this on the wiki, and also your blog, but it's clear you're
> > the one who doesn't understand the ID3v2 format. The UFID frame takes an
> > owner subkey[0], which is required to be a URL. Without that owner
> > subkey, it's impossible to implement support without conflicting with
> > other potential users of UFID. For example, MusicBrainz also uses UFID,
> > with a subkey of "http://musicbrainz.org".
> 
> Read the specs again.  The owner subkey is not required to *be* a URL.
>    It is required to *contain* a URL where an email address with the
> responsible organization can be found; alternately, that email address
> can be the owner subkey.

When the ID3 standard says "contains" it means "is". (emphasis mine):

TBPM
The 'BPM' frame *contains* the number of beats per minute in the
mainpart of the audio. The BPM is an integer and represented as a
numerical string.

Now, does that mean TBPM's value can be "here's a BPM: 192"? No, it
means it's just "192".

TLAN
The 'Language(s)' frame should *contain* the languages of the text or
lyrics spoken or sung in the audio. The language is represented with
three characters according to ISO-639-2.

Does that mean TLAN can be "Hey, I'm in eng"? No, it's just "eng".

It's clear from context that "contains" means "is". I realize you want
to have a nice all-caps advertisement for Amarok; too bad.

> Anyways, what's your point?  We use a
> correct owner subkey just like MusicBrainz does.

My point is that, even regardless of whether your interpretation of
"contains a URL" is valid, you still never actually document the owner
subkey you use. Therefore, it can't be supported.

> Interoperation really requires the same owner subkey, which makes
> sense, but makes it harder to have a responsible party...you'd have to
> have some sort of shared URL or email address.  If you are planning
> support, we could implement a workaround by:
> 
> a) Deciding on an algorithm for UID generation (we already have one
> that avoids some possible pitfalls).
> b) If our owner string isn't detected but yours is, copy the UID to
> our owner string.
> c) If we ever run a function to change the UID, ensure that yours is
> changed as well, if present.
> d) Vice-versa for you.

If we share the same algorithm for UID generation, then there's no
problem. However, I can safely say that Quod Libet won't be generating
these IDs, just using them where possible. 

> > Secondly, in your tests on the TagLib mailing list[1] you're using an
> > invalid UFID owner, since it's not a URL. Please go read the ID3v2
> > specification yourself.
> 
> As I just explained, you're wrong.
> 
> > Thirdly, that only covers ID3. There's no documentation on what to do
> > for APEv2 or Vorbis tags.
> 
> APEv2 is not supported, though maybe in the future.  Vorbis uses
> XiphComments.  It's a slight abuse of the purpose of XiphComments,
> however it's short (they specify it should not be used for large
> amounts of arbitrary data) and the alternate way is to interweave a
> second stream, which TagLib doesn't support and is rather scary.

You've missed my point again: What's the name of the Vorbis comment
field? It's useless to just say "it's a field" without saying what the
field's key is.

> > But stop picking on other
> > software that doesn't support your undocumented methods
> 
> Coming up with a new feature and promoting it is not picking on other
> software.  I've never gotten contact from someone saying that they
> wanted to interoperate, and I've not gotten requests for specific
> documentation of the methods, either.

Consider this a request. Of course, you could be more proactive: Quod
Libet documents its tag usage long before anyone asks, and we also don't
talk down other players that don't support them all. You're certainly
proactive about pointing out what *doesn't* support them.

> Nor have I put anything
> extremely detailed on the Wiki, because the API has still been in some
> flux as we've gotten more testers and more feedback.

Then why are you criticizing other players for not having the feature?
Technical details should come long before advertisements.
-- 
Joe Wreschnig <piman at sacredchao.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.kde.org/pipermail/amarok/attachments/20060817/401b4091/attachment.sig>