Tagger Script

From MusicBrainz Wiki
Revision as of 22:05, 28 January 2006 by Shepard (talk | contribs) (first version. now to the interwingling... (Imported from MoinMoin))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

What is TaggerScript?

There are many requests to add certain options to the PicardTagger like "Convert all first letters to upper case" or to set a certain frame in ID3Tag of a MP3. Though it is possible to solve all of those requests more flexible than just by adding checkboxes to the options dialogue.

TaggerScript is a general idea of enhancing the PicardTagger with lightweight scripting features that allow influencing the tagging process easily according to the preferences of the user.

There are two variants of doing so.

Variant 1: Variable System

This would work similar to the naming description fields we have for filenames now. You would have fields like Album, Artist, Title aso that represent the target, that is for a MP3 file it would be the frame of the ID3Tag you want to put something into. And then it would have variables like $albumname, $sortname, $begindate aso that represent the values that come from the server request. When assigning values to the fields you could use both variables and freetext. But nothing more. It would look like this:

Album = $albumname [$year]
Artist = $sortname [$begindate - $enddate]

What is to be decided is: does it use default values for certain fields (so you don't have to write everything down like the MusicBrainzIdentifiers) or does it really only change the values of those fields that you note in the description box (or wherever). This could be an option.

Possible extensions: Add some predefined functions like upper_case_first_letters() which can also be used when assigning the server values to the fields. Use generic field names ("Album") that are matched to certain ID3Tags / FLAC comments depending on the tagging settings but also define specialized field names that overwrite the values of the generic fields. Those specialized field names are the exact equivalents to the places their values are written to (that is you have a field for the ID3v2.3 TALB frame and one field for the ID3v2.4 TALB frame).

Variant 2: Complete scripting language

This would add a complete scripting language to Picard. You could define different scripts for different use cases like full tagging <-> just updating. It would make the tagging process more complicated but would allow very complex operations through loops, if's, string-functions and so on.

Of course both variants could be combined - that is you normally only see a text box where you can enter a syntax as described in variant 1. In the background this is transformed into the complete scripting syntax and by clicking on a "Advanced" button you'd see the result and could edit it. Users of WinAmp might know this method from the simple view editor and its advanced variant. Though when editing the script code it might not be possible to transform it back to the simple syntax. Another way would be that the syntax of the complete scripting language is so easy that it does not look a lot different from the syntax described in variant 1 for such simple tasks. Then you wouldn't need two editors.

Overkill?

One might think variant 2 is a complete overkill and variant 1 is far enough for what users might want to do with the tagger. Though at least when the database converts to the NextGenerationSchema it will be so abstract and contain so much more depth that there are many more possibilities how a file could be tagged. Here are some of them:

Use case 1: Disc numbers

The NextGenerationSchema is to separate many things we currently put together. Among those are SubTitles and DiscNumbers / DiscNames. That means MainTitle and SubTitle of tracks should no longer be stored in one field as should ReleaseTitle and DiscName. This indeed does work also with tagging: ID3 has separate fields for all of those parts. Though very few players support them. Therefore some users might want to use the single fields and some users might want to still handle it as we do it now. So usergroup 1 might want to do something like this:

Album = $albumname;
PartOfSet = $discnumber;
SetSubTitle = $discname;

(Where PartOfSet and SetSubTitle refer to the frames TPOS and TSST in the ID3v2.4.0 standard). And usergroup 2 would do:

if ($discnumber != "")
{
        Album = $albumname + "(disc " + $discnumber;
        if ($discname != "")
                Album = Album + ": " + $discname;
        Album = Album + ")";
}

Use case 2: Artist names

The current ObjectModel for the NextGenerationSchema makes a distinction between an artist (a - virtual or real - person or group of discographic relevance) and a release artist which is mainly a label for how an artist name is written on a release. Users who want to be near to the release might prefer using the release artist string, users who don't want to have several entries for one and the same artist in their media library might prefer using the Artist name string. This could still be done with a simple variable system. But when it comes to classical releases you have a composer linked to the composition object, a performer linked to the recording object and perhaps something completly different as release artist. With some if statements you could do wonders. ;)

Use case 3: Live tracks on live albums

Currently we don't always label tracks as what they are but what they are labeled as on a release or we follow certain guidelines for this. For example an album version on a single is not labeled as this. Or some mix may just labeled as the normal song on a release. In the ObjectModel we have a mix object which shows which version of a song it is. This could contain the title of the mix. Also we have a recording object which could contain information if the song was recorded live or in the studio.

With scripting features in the tagger users could decide if they prefer what is written on the release or what it really is. For tracks on a live album they could decide putting " (live)" behind all track titles (which we of course don't do in the database because normally all tracks on a live album are live).


Original author: Shepard