[mb-devel] Picard & tag mapping

[Vidar Wahlberg]

On Sun, Aug 19, 2007 at 12:52:32AM +0200, Lukáš Lalinský wrote:
> On Ne, 2007-08-19 at 00:45 +0200, Vidar Wahlberg wrote:
>> what's the reason for having one "key" for id3v2/mp4 and another "key"
>> for ogg vorbis/apev2?
> 
> Because it's an existing standard, which applications already do
> support. I don't know the original reason for defining it this way in
> the standard, though.

how widespread is this standard?
are there any software outside mb that use this standard?
myself i'd really like to see these keys be the same across as many
tag-formats as possible.


> In pre-Picard times it wasn't at all, in Picard 0.7.2 it's
> "MUSICBRAINZ_ALBUMARTISTSORTNAME" and "TXXX:MusicBrainz Album Artist
> Sortname" and "----:com.apple.iTunes:MusicBrainz Album Artist Sortname".

right, this is correct. i remember i dropped the "MUSICBRAINZ_" myself
because i felt it was unnecessary as it wasn't musicbrainz specific.


> "ALBUMARTISTSORT" is used by non-MB applications and as this wasn't in
> the original MB tag reference, I changed it in PicardQt.

very well, obviously the most sane thing to do.


>> "MusicBrainz Track Id" is saved as a UFID frame in id3v2, and a "----"
>> frame in mp4. now i know the UFID frame is made especially for "unique
>> file identification" and that the track id fits fair here, but in my
>> opinion this should just be in a TXXX frame to group it with the other
>> ids.
> 
> No, it should be an UFID frame as it is. The other MB IDs should be in
> PRIV frames, but it's too late to change that.

i don't quite agree here, even if the other mb ids were placed in PRIV
frames it would be inconsistent with mp4.
i'm very much a huge fan of KISS, and i'm not talking about the band
then. while it is "correct" according to the id3v2 standard to place
such ids in the UFID and PRIV frames, it would imho be less complex to
put these in TXXX frames instead, as well as more consistent with other
metadata formats.


>> if i got it right the UFID data supposedly should be binary as well.
> 
> Yes, ASCII text is binary. :)

true, but why is an id like "829535f5-f7dd-4a76-bcad-fe81e101e15d"
stored as:
38 32 39 35 33 35 66 35 2d 66 37 64 64 ...
instead of:
82 95 35 f5 f7 dd ...
in the UFID frame?


-- 
Regards,
Vidar Wahlberg