Filter custom columns

I've created customized columns in mp3tag which "validate" certain things in mp3 files (I attach a picture) and would like to filter or export using thoose columns... Is that possible?

Thanks for your help!


I presume you created these columns dependent on self-defined tags?
You can filter or export content of any tag.

Thoose columns are not simply tags... They have scripts which validate certain things for example:

  • Che if capitalization is ok in title
  • check if filename is %track% - %title%
  • check file is UTF8

Etc etc

Well, as I wrote, you cannot base filters or export scripts directly on columns but you certainly can rebuild your scripts behind the columns for filter and export.

Unless you write the contents of a column to a field, you have to repeat the statement that fills the columns in the report and/or the filter. You cannot use the column name for this.
If you have written the contents to fields, then you can use that field name.

Any chance on adding this as a new feature?

I don't know. One would have to make sure that each column name is unique then.

You have used the dialog to define columns and you have created "small scripts" in the edit field "Value" for each column to display a calculated status info, ... nice idea so far.
Then you want to work with these results, which are calculated on the fly by the small scripts in the edit field "Value", afterwards when applying the Mp3tag filter or export features.
This should be possible, anyway you have to make the displayed results permanent by storing them into user defined tag-fields into each underlying media file.
So you have to define a tag-field name for each edit field "Field" within the column dialog.
Then you have to save the content of the new helper tag-fields into each underlying media file, ...
in order to work with these values in Mp3tag filter and export functions.
This last step cannot be automated yet, you need to have it manually.
The calculated value, which is shown in a cell of the table grid, has to be accepted as 'manual' input from user. So you have to set one grid cell into edit mode, then accept the value by "Enter" and do it for each following cell in a column.

At this point you may realize, that the manual procedure is not the best way to get the wanted result.
So it would be better to let a Mp3tag action do this work for you.
To do so you have to set up a group of actions, ...
with one "Format value" action for each helper column, ...
and apply your "small scripts" as the format string.
Afterwards run this actiongroup against the media files.
Then apply filter or export.

DD.20151026.0010.CET

DetlevD thanks for your post but my idea is not to save this things in the tag.

As it seems not to be possible what I did was:

  • pasted column scripts in excel (one per row)
  • changed scripts which returned OK or BAD to 0 or 1
  • created a last row in excel which concats all previous texts and add an "$add" so result is: $add(column_script1, column_script2, column_script3,etc).

I then paste this as a new column which has a final result of 1 and 0.

The idea of having this in a excel is that if I change a script I change it there and it automatically gives me the "final column" script.

I really think that the possibility to interact between columns should be added to mp3tag bug till then this is going to be my solution.

Thanks to all.

But this is the way how Mp3tag works.
Mp3tag is not a spreadsheet application, where you can address any cell by its coordinates.
If you want to work with self calculated values, then you have to make them permanent, therefore you need a place to store them. The only place to hold data is the tag-field within the underlying media file.

Mp3tag uses the concept of "actions"; in this area you can work with all variable content, which can be addressed by a defined name.
Sometimes there is the caveat, to create temporary tag-fields as the intermediate storage.
Mp3tag supplies the concept of actions and functions, where the user can define the rules, how Mp3tag should behave with the tag content of the underlying media file.
There is no need to automatically 'interact' between tag-fields in Mp3tag, in the way like a spreadsheet calculator does work.
The technical concepts of the Mp3tag table view and the Excel spreadsheet are different.

DD.20151026.0805.CET

DetlevD, mp3tag is a tag editor. The columns I created as I said are used to validate thing INSIDE the tags there's no need of storing this things in the id3, what for??

I check:

  • If capitalization is ok
  • If file has a cover
  • If track format is "XX"
  • If disk format is X/X
  • If genres are of a set of defined genres

and many things more.

I (at first) found that columns where useful to do this because I could validate with scripts this things. At the moment I have 24 columns with different validations that make the tags in my mp3's really clean and tidy and the way I like them.

The problem is that when I want to check if any mp3 "does not meet" my "standards" of tagging i have to "sort" 24 columns and check if any of them say "BAD" and not "OK" (see my screenshot in first post).

That's because I think that if you can script in columns there should be some way of:

  • filter by those columns
  • export those columns
  • reference one column from another column

If you or the developers don't think so it's ok but what I'm doing is something related to my mp3 tags and not simply a spreadsheet. I could write all these validations in excel if I wanted but I'd loose the possibility to fix this things within the same app.

You have it recognized.

If you want to work with such cell content from user defined columns you have to make such values permanent in the form of a tag-field with a dedicated name.
Only then you can use such values in the Mp3tag Filter or Export.
You have to recognize that the only memory buffer, which can be used by Mp3tag, is within the static memory of a tag-field.
After further evaluation, you can delete these helper tag-fields.

Strictly speaking, the 'validation scripts' do not do that, but the 'validation scripts' visualize the problem cases.
At last the cleaning work has to be done manually or by actions, by applying the same scripting rules as in the info columns.
Question: why doing the same effort twice?

Therefore you have to describe and set up your standard rules in action scripts and let do the main work by Mp3tag itself.

You can do it all now, with instantiated values in helper tag-fields.

For now you have to accept the circumstances, ...
and try to understand what Mp3tag can do to help you now.

DD.20151026.0957.CET

I definitively understand what mp3tag can do for me, you are the one not understanding what I want to do.

I already realized that what I want cannot be done, the thing is I really think that developers should consider adding the possibility of what I said later.

Because solution to validations cannot be done automatically because some of the things checked require a human (for example if no cover is detected I search for one; if a wrong genre is detected I manually fix it, etc)

Now please, try for a sec (and just a sec, it ain't that difficult) to take a look at the problem and then answer if you want (at this point I'd prefer you don't cause after your first post here all you said is not really helping).

PROBLEM:

  • I have a 50k files mp3 library.
  • Files are synced to other locations inside my lan for security and backup (sync is based in timestamp modification)
  • I want all of the files to meet certain standards and tag validations
  • Writing things to tags as temp ain't a solution because: 1) Will force a sync which really isn't necessary 2) will demand a lot of hard disk reading/writing in 520gb of music

If you think you have a better solution, I'm all ears... If not then let me still suggest:

Which is as I'm saying a SUGGESTION because I already found a solution which is have all my columns code concatenated into one column and use that as a reference to know if my mp3 tags are ok or not and if I see there's any problem I vertically scroll left (where my 24 script columns NOT SAVED TO ID3 are) to see which validation is not being met by the file.

The presence of covers can be detected with an easy filter
NOT %_covers% IS ""
Scrolling through lengthy lists or applying different sort criteria to columns still leaves the human attention span as source for errors. If you only use a filter for each of the checks, you will be just as quick.

e.g.:

%_cover% PRESENT
or
%_cover% MISSING
%track% MATCHES \d\d
%discnumber% HAS /
I still wonder how you check for the genres as there are 128 pre-set one for V1 and many more user-defined genres. This would lead to a very long expression for the column definition.

These filter expressions are much shorter than a (e.g)
"$if($eql($caps2(%title%),%title%),1,0)" IS 0

The advantage of the use of a filter is that the expression has only to be evaluated once (when filtering and not to fill the column cell and when filtering) and definitely shows only the matches. No additional sorting required.

I admit that this does not really solve the problem of the export.

But then again: how often do I have to check my files once they have been tagged properly. It should be enough to treat only the new ones.

I do not think so, my effort is simply to lead you onto the practical Mp3tag route.
You may have to learn a different way to think and solve problems with Mp3tag.

Well ... this seems to be a problematic environment and organization per se, which is outside of the responsibility and the focus and the functionalities of Mp3tag.

If you want to use the Mp3tag Filter or the Export section, you have to work with instantiated tag-fields.

DD.20151026.1058.CET

I want to add, that the open poster's proposal has been coming up already several times in the past.
It is a not so bad proposal, because it bypasses the arbitrariness of the filter dialogue, and can give the set of standard rules a certain structure and pictorial representation.
Therefore an everlasting dedicated developed format string can serve the same purpose as a manual input of a filter expression on the fly.
This can be rather effective, saves time and prevents incorrect entries, and is clear in overview, so far so good.
The next step is the repair of defective tag-fields, because of the possible reported error circumstances.
Then manual procedures or automated actions can be applied for these repairs.
If the user could now reference directly the result from a related 'user defined meta cell' in the grid view, then the user has not to repeatedly write the same format strings at other places in Mp3tag.

DD.20151026.1316.CET

Agree with ohrenkino that filters is the easier way to achieve what you want but with maybe less flexibility than keeping conditions in multiple columns and an excel spreadsheet.

e.g. you can quickly scroll through your saved filters with the mouse wheel looking for tracks which need attention (i.e. they match the filter/validation script) and fix them there and then.

However (rant) the saved filter list cannot be edited or reordered!, and sometimes you want/need to check things in a particular order. And if you try to edit a filter, instead a new filter is created at the top of the list putting it out of your preferred order! (end of rant) :w00t:

That's the really annoying part.

Would be great if filters could be ordered and named.