What is the Difference between the File Naming Script and Tagger Scripts?

MusicBrainz Picard
,
1

Tagger Scripts are used “On the Left”, vs. the File Naming Script is what you do with the stuff from the “Right Side”. I got that.

What I don’t quite get is what can I do on the left that I can’t do on the right? I can add many Tagger scripts, but only one file naming script. The latter seems logical, and the former, at least to me, I would think that wouldn’t be any different, if at all.

There’s also something different about the use of variables vs. text between the two, or?

So, outside of those things, why would I want to do anything on the left side?

2

The scripts are not really related to the left or right, they serve different purpose:

File naming script: This creates the file name when you save. Use this to customize how files and folders are named when saving. This script gets processed when you click save, it generates the file name. It has no influence on the metadata.

Options Scripting: The scripts here are for modifying the metadata. Active scripts run automatically on the metadata loaded from MusicBrainz, so the releases and tracks you see loaded in the right pane are already modified by the scripts you have set up. Beside this you can also run scripts manually by right clicking on albums, tracks or files and select the script from the “Run script” submenu. This works both on the left and the right pane.

Now to the panes:

Left pane: Here you see the files you have loaded into Picard before they are matched to releases from MusicBrainz. Usually you want to cluster those files and then in some way match them to releases on MusicBrainz (by lookup, scan or manually through drag and drop to the right pane). But if you want to you can also modify tags manually or manually run scripts and save your files that way. You might want to do this if you e.g. have some files that can not be on MusicBrainz (e.g. you custom compilation or something).

Right pane: If you load a release from MusicBrainz it will be loaded in the right pane. A release loaded here first represents just the metadata, but once files are matched to the tracks you can save them.

See above. Yes, normally you want your files to go to the right pane, being matched to the proper MB release, and then save them. But there can be cases where you want to manually tag something. Having files on the left and save them is basically using Picard as a dumb tagger without metadata lookup functionality. It is not really designed for this, the main use case is definitely tagging against MB data, but sometimes it is useful to just be able to just edit and save manually. E.g. you can still take advantage of Picard’s renaming feature with just your local tags.

6 Likes
3

Thanks for the descriptions, now I know where the other features I have been interested in, are, and how to get to them. My impression of the left side was it was simply for clustering and queuing for the right side where it all happens.

That also means the left side can be used to organize stuff before formally submitted it if it’s going to be.

I have some data that I want to organize into volume, issue, similar to a podcast in annual sets, and then eventually add metadata to it for my local end.

Which leads me to figuring out a work flow for merging metadata from a spreadsheet.

3 Likes
4

As I’ve gotten further with what I’m sorting down, working on here- the differentiation between the two ‘sides’ has become an awful lot more clear.

First, yes, it may sound like a big huge D’oh! moment, but For the longest time I absolutely did not realize that you could even save stuff from the Left side, that you had to run it over to the right, which meant looking up releases manually when you were dealing with a VA release of any kind.

…because otherwise Picard was pretty much guaranteed to match those singles up to an album by artist way more than the compilation album. Which of course, you can see where that is going to go.

Part of the reason I have so many files/different directories of stuff. “Okay. that was a bad idea sorting wise, so I’m going to just keep this all until I have time to do it ‘right’.”

As in, yes, I do keep a backup of everything on a separate drive / volume and use rsync.

But once I figured out that I can save things from the left side, well then, that Mass of the Messes source side has gotten a lot more manageable.

So, with that, I’ve been grouping stuff and changing the filenaming script content accordingly, mostly when dealing with some huge sets of numbered files. (Think a week’s worth of a particular radio stream ripped into individual tracks … into the 10,000’s of tracks per ‘album’) that never got a Compilation Tag initially. So. OMG. But I can ‘gather them’ up again this way.

So, while the absolute goal with Picard was to make a tool to help sort data towards encouraging data submission to the DB, though even with intent by design, it is still very practical to save from the left when the DB does not apply. At least at that point in the flow of sorting.

That said, I can apply a script via right-click execute. But obviously the naming portion of the script can not be used towards path destination in that form as there is no way to apply a specific script to the saving process. Leaving one to go and change the contents of the naming script when something different is desired at that point / with that particular data.

So, if there were a way to connect a tagger script to saving on demand, as an exception to the default naming script.

Maybe I can figure some back end hack out for this, too :wink: Two weeks ago I’d have never imagined. I’ve picked up Python quite well, though not enough to go from scratch by any means, but following and using whats there as examples works great and can only lead to the point of being able to start from a blank slate. Because yeah, “Hello World” just doesn’t do it for me. Except, for checking to see that the installation was done correctly.

…and if Picard could import a list of tags from a csv and apply them to files by name… Oh that would turn this amazing toolbox of functions into the whole tool truck.

But right now… just being able to use an alternate set of rules for saving would go a long ways more.
e.g.: Maybe I can come up with something.

5

Whilst composing another post, a possible option for specifying alternate save rules occurred to me.

It sounds messy though.

Since the scripting structure is straight down, top to bottom, left to right parsed… if at some point in the script there is a way to clear the string being built and start anew.

%naming script here%
%here ... %
% ... here%

(String has been built)

However, –IF– logic as such could be applied:

$if($in(%bpm%,666),
  )
$noop#Let's nuke what we have generated so far#
$delete(_stringGeneratedSoFart),
(
$noop# Continue on, string will re-generate
 )(
(%new naming script here%)
(%here ... %)
(% ... here%)
$noop #Though most likely less complex#
NewStringBuilt))))))
$noop Done. Or, again, if bpm is 777 ..

That would be parallized parenthesis in action.

Or like this:

$noop section builds %string_1%  by ongoing append $set(%variable%,%sting_1%) 
$noop section builds %string_2%  by ongoing append $set(%variable%,%sting_2%) 
$noop section builds %string_3%  by ongoing append $set(%variable%,%sting_3%) 

$if(in(%bpm%),666)%string_1%)
$if(in(%bpm%),777)%string_2%)
$if(in(%bpm%),888)%string_3%)

…and only one of the compiled results gets spit out.

There would be a couple three options to choose from all within the same naming script.

6

By Active, I gather that means if the tickbox is selected to the left of the Script name.
(Like none of them are set in this example)

34%20PM
34%20PM1016×299 25 KB

…and if none of these are [ ] Active… shouldn’t I still see results if I use (the one in the example) manually on selected tracks?

11%20PM
11%20PM1549×409 125 KB

I can Add New Tag/Edit Tag data on those, but I get no results from the any manually run scripts.

I still have areas that I need to better understand having to do with Tagger vs. Naming scripting actions, when %xxxxx%, %_xxxxx% (Tags and Variables) are used

In this case, I’m opting to use a %catalognumber% value of ‘No MBDB’ or some other value that means something to me if I save from the Left side. If those tracks do get sent to the Right then that %catalognumber% will get overwritten/emptied by design.

7

Your script is wrong. It should be:

$set(catalognumber,No MBDB)

The variable name is vatalognumber. Using %catalognumber% is short for $get(catalognumber).

If you do $set(%catalognumber%,No MBDB) it is the same as writing $set($get(catalognumber),No MBDB), and this will set a variable with the name of whatever value catalognumber has. So if catalognumber is set to “AB-123” you will get a tag AB-123 with the value “No MBDB”. If catalognumber is empty nothing will happen.

1 Like
8

Okay, so I still have yet to firmly nail down when and when not to use %, _ … tags, variables, hidden, or not. Whatever. (!!)

9

It’s not so difficult: You use %...% whenever you want to access the variable value.

As for variables starting with a _ (aka hidden variables) this is just part of the name. The difference with these variables is that they don’t get written to the tags. So for existing variables you don’t need to care really, you just use them as they are named. For you own defined variables you have to decide: Is this something you want to have written to the tags or not. If it is just some value you use for scripting or maybe file naming start the name with a _.

2 Likes
10

…and so I’m clear on the other stuff, there is no way to have something automatically applied to the left?

… but a properly scripted, active [✓]Tagger Script will do it’s due diligence once the track ends up to the right?

Otherwise, an inactive Tagger Script can always be run from the contextual menu.

11

Yes, that is correct.

2 Likes