[mb-users] playlists and picard designs

[Will Holcomb]

Ok, so album ordering is maintained in the id3 tags. I use amarok the bulk
of the time and it can generally does a pretty good job of managing
metadata.

I was wondering about the development path for Picard. I noticed a couple
different interface designs listed on:

http://wiki.musicbrainz.org/IntuitivePicardInterface

Before opening my mouth with comments, I wanted to have an idea of how fixed
this interface is. I searched for IRC logs of the discussion where the
decision was made and found discussion, but nothing that seemed particularly
in-depth. I'm curious about the reasoning behind not going with the single
pane interface. I generally think of dual panes as allowing you to see
either different views of the same thing or completely orthogonal views of
different things. It seems like picard is using them to represent a change
in state which I would think could be done with a change in color or icon,
and double your screen real estate.

Is there an e-mail discussion or chatlog somewhere that goes into the
reasoning?

I was looking to try and lend a hand if I could, but looking at:

http://bugs.musicbrainz.org/query?component=Picard+Tagger&milestone=Picard+Qt&order=status

It seems like there are no open bugs. Am I understanding correctly?

Will

On Jan 10, 2008 8:18 PM, Chad Wilson <chad.wilson at gmx.net> wrote:

> What you're asking for is quite possible if you use a media player that
> is, well, probably not WinAMP; i.e. one that allows you to search and
> index by structured tag data, not filenames, which (my opinion) are
> generally a poor mechanism to build playlists on.
>
> Even if you change the file to be named "artist - track", by default the
> track numbers and album name are saved to the music file tags inside the
> file header, so with a player that respects these in its library, you
> could sort/group by album and play a whole album.
>
> Picard and MusicBrainz are album/release-centric, yes. Picard is
> oriented towards /tagging/ i.e. persisting all known data in a
> structured way to ID3(or equivalent) music file tag headers. Playlists
> are a user-concern, i.e. nothing to do with the shared server data that
> MB seeks to capture.
>
> I guess one could consider "by album" to be one form of playlist for an
> entire artist's tracks; but really, playlists are a separate concern in
> my mind. MB and Picard are about getting correct data into files, not
> about making choices for you about how you should play your music. This
> should be a concern for the music player of choice, and the efficiency
> with which it allows you to sort, find and query for music /based/ on
> those tags.
>
> Anyway, Picard is equally suited towards customising the way in which
> files are name as to tags saved to files. It's somewhat power-user like,
> but if you want to change which tags, and the way tags are saved from
> MB's data, you may want to check out TaggerScript at
> http://musicbrainz.org/doc/PicardQt/Scripting, part of Picard 0.9.0.
>
> Chad / voiceinsideyou
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-users/attachments/20080111/b1254d85/attachment.htm