Format value- the skipping of

Hello

I would like to how to skip a format value

I have created a quite big and complex action group, including this two codes:

Format value "TRACK": $mod(%_FILENAME%,100)
Format value "DISCNUMBER": $num(%_FILENAME%,1)

And what they do is they take the number from the beginning of the FILENAME, and copy a proper part o it into the TRACK and DISCNUMBER; which saves me a lot of time and clicks

But sometimes there is already a number in one or two of this tag fields- which I need to retain [and disregard the number from FILENAME]. And also sometimes there is no number at all at the beginning of FILENAME- and so these codes simply delete my already exiting numbers in TRACK and DISCNUMBER

So what I need is some sort of order that would say "do not execute this code if TRACK tag has a number"; or even better "do not execute this code if TRACK tag has any kind of sign"

[I know I could use a workaround by creating a variant of this action group without these two codes. But I could always make a mistake by choosing a wrong one; and also my menu with action groups is already overcrowded- my list is just too long]

I am amused, indeed this works ... $mod(%FILENAME%,100) ...
examples ...
02_Uninvited_AlanisMorissette_GH99
==> 2
20140524-084858_266500786__103-all ==> 24
#24#96 Vinyl Rip ==> 0

This might be not the wanted result, because the tag-feild DISCNUMBER will get the entire leading number of the filename, but not the discnumber itself alone.

You can check for the existence of the tag-field TRACK, ...

$if(%TRACK%,'then ... field does exist ... do this','else ... field does not exist ... do that')

... or check the content within the tag-field TRACK ...

$if($eql($regexp(%TRACK%,'^\d+$',),),'then ... is numeric ... do this','else ... is not numeric ... do that')

DD.20150317.2126.CET

If you work with a set of actions, stored into an actions group, then you may consider to begin the workflow with an action "Remove tag-fields", and remove existing tag-fields TRACK and DISCNUMBER. This would make special $if-tests superfluously.

DD.20150318.1310.CET

I can not take credit for that

If you didn't provide it to me in the first place, the the user ohrenkino must have

As I said, I have a quite big action group [12 "unique" codes and around 20 variants or little / simple similar changes]. And so, some further [already tested back and forth] codes deal with that and some other issues

That's what I thought I should do. But I didn't know how to "if it"

But now I've went to on-line help and searched for >>$if<<

I've found the sub-entry on >>Boolean functions<<

As I understand the >>$if2(x,y)<< will do what needs to be done

And so, starting with the easier second one, I have created:

$if2(%DISCNUMBER%\d,$num(%_FILENAME%,1))
$if2(\d,$num(%_FILENAME%,1))

And both of them work not exactly the way I need them to

I'm know I'm missing something in the first [>>x<<] spot. But I just don't know what

And this [DISCNUMBER] is the easier one because: in my system the DISCNUMBER can be either empty field or be bearing a [most likely] single digit. On the other hand, the first one [the TRACK tag], can have digits but also letters and some other signs like tilde. And to accommodate those already existing eventualities and the possible further non digit signs, I will have to use the combination

\w\s\d\l\u

instead of just simply

\d

?

Yes; when I intent to use the same action group for only tagging completely new files [by taking some of the data from the FILENAME]

But not when I sometimes use it to correct the already existing tags. And as I said, I do not wish to multiply action groups and / or make variants of them [because I could choose a wrong one by accident and not even notice it; and also my and action groups menu is already too long]

Of course there is a workaround to this issue: make corrections only in TITLE tag and not on FILENAME. But when I will forget to comply with that rule [and I just know I will at some point in the future workload] then I will potentially lose some data [in TRACK and DISCNUMBER tag]

And yes- sometimes I clear all the fields or overwrite all of them [by coping all the tags from another file]. But those are high level risk operation [in regard to maintaining as much true / correct data as possible] and I choose simply not to make them part of some automatic process

Alternatively, the $if-tests for those two codes would be also unnecessary if I would use a workaround like this:

1] copy value from TRACK to some XXX tag field
2] run the code
3] copy back the value from XXX to TRACK, but only if the value of XXX do exists [field is not empty]; and of course I don't know how to condition that
4] clear the XXX tag

But that is making my big universal action group even bigger and more complex. And I can imagine, that in the future I will simply forget how to read / modify those codes [as I did with HTML / CSS as the time went by]; and so I need it to be as fit and error proof as possible

TEMP <== %TRACK% TEMP <== some work on the tag-field TEMP TRACK <== $if2(%TEMP%,%TRACK%) TEMP <== $char(0) ... or ... Remove tag-field TEMP

DD.20150319.0754.CET

I did it, with the addition of a safe fail feature to the DISCNUMBER

And so here is my whole automated TRACK and DISCNUMBER numbering process; derived from a FILENAME with a 000 / 00 track format at the beginning of it [made with the help of you and user ohrenkino]

So thank you once more

Questions:

  1. How is the correct sequence of the actions?
  2. "000 / 00 track format" .. is 3-digit tracknumber / 2-digit discnumber ?
    Please give a real-life example for the possible input filenames ...
    and the valid result in the target tag-fields.
  3. Regarding ...
    Replace "TRACK" : "0" with nothing
    Replace "DISCNUMBER" : "0" with nothing
    ... both actions are at risk for numbers with trailing zero, like number "10".
    What's the point of the replacements?

DD.20150319.1218.CET

QUOTE (zerow @ Mar 18 2015, 20:52) <{POST_SNAPBACK}>
I have created:
$if2(%DISCNUMBER%\d,$num(%_FILENAME%,1))
$if2(\d,$num(%_FILENAME%,1))

And both of them work not exactly the way I need them to ...


Which effect has the string '\d' in these script expressions?

DD.20150319.1620.CET

Well, I have tried to understand what there is going on, ... and I have given up.
But I wrote down a worksheet.

  1. Example Filenames ...

1 - filename.001.mp3 No Disk Nr
10 - filename.002.mp3 No Disk Nr
100 - filename.003.mp3 No Track Nr
1000 - filename.004.mp3 No Track Nr
0001 - filename.005.mp3 No Disk Nr
001 - filename.006.mp3 No Disk Nr
01 - filename.007.mp3 No Disk Nr
011 - filename.008.mp3 No Disk Nr
101 - filename.009.mp3 Disk Nr and Track Nr exist
0101 - filename.010.mp3 Disk Nr and Track Nr exist

Number format for Discnumber and Track can be or should be ...
DDTT
DD = Disk Nr
TT = Track Nr

  1. Save existing content from DISCNUMBER and TRACK ...
    for possible later use to helper tag-fields ...

ORIG_DISCNUMBER <== $if2(%ORIG_DISCNUMBER%,%DISCNUMBER%)
ORIG_TRACK <== $if2(%ORIG_TRACK%,%TRACK%)

  1. Prepare helper tag-field for Discnumber and Track ...

Get one to four leading digits from filename into helper tag-field, ...
if there is no such number format, then set helper tag-field to '0000' ...
TEMP_DDTT <== $if($eql($regexp(%_filename%,'^(\d{1,4})(\D.+)?$',),),

$regexp(%_filename%,'^(\d{1,4})(\D.+)?$','$1'),'0000')

Make all leading number strings the same format, ...
by right adjust the given numbers with leading zeroes ...
TEMP_DDTT <== $right('0000'%TEMP_DDTT%,4)

Possible DDTT cases ...
0000 No Disk Nr and no Track Nr
0001 No Disk Nr
0100 No Track Nr
0101 Disk Nr and Track Nr exist

  1. Split TEMP_DDTT into Discnumber and Track, fill helper tag-fields ...

... with leading zero ...
TEMP_DISCNUMBER <== $left(%TEMP_DDTT%,2)
TEMP_TRACK <== $right(%TEMP_DDTT%,2)

... or without leading zero ...
TEMP_DISCNUMBER <== $div(%TEMP_DDTT%,100)
TEMP_TRACK <== $mod(%TEMP_DDTT%,100)

  1. Fill standard tag-fields ...

DISCNUMBER <== $ifgreater(%TEMP_DISCNUMBER%,0,%TEMP_DISCNUMBER%,)
TRACK <== $ifgreater(%TEMP_TRACK%,0,%TEMP_TRACK%,)

  1. Remove helper tag-fields ...
    ... use action "Remove fields"
    ... or this way ...
    TEMP_DDTT <== $char(0)
    TEMP_DISCNUMBER <== $char(0)
    TEMP_TRACK <== $char(0)

  2. Probably add a step ...
    for comparing the new values with the original values ...
    and decide what to do ...
    DISCNUMBER ??? ORIG_DISCNUMBER
    TRACK ??? ORIG_TRACK

  3. Probably remove original values ...
    ... use action "Remove fields"
    ... or this way ...
    ORIG_DISCNUMBER <== $char(0)
    ORIG_TRACK <== $char(0)


    Format_DISCNUMBER_Set_DISCNUMBER_TRACK_from__DDTT_Filename_.mta (640 Bytes)
    DD.20150319.1846.CET, DD.20150320.1220.CET

Format_DISCNUMBER_Set_DISCNUMBER_TRACK_from__DDTT_Filename_.mta (640 Bytes)

Thank ou for additional info, but you should have waited for my answer. My system is really simple; if you know its rules

First, here is the part of my action group related to naming and correcting

[all of the above is based on your codes and that of user ohrenkino]

It know it would comprehensive if I would write down all of my tests, to present full capabilities of the whole action group. But I will limit myself to examples showing the core principles

FILENAME ---> TITLE tag
DISCNUMBER --- TRACK number

Song AAA ---> Song AAA

205 Song BBB ---> Song BBB
2 --- 5

05 Song CCC ---> Song CCC
--- 5

5 Song DDD ---> 5 Song DDD
--- 5

2015 Song EEE ---> 2015 Song EEE
--- 15

205 2015 Song FFF ---> 2015 Song FFF
2 --- 5

2nd Day ---> 2nd Day
--- 2

  • please note that >>5 Song D<< have erroneous TRACK >>5<<; but that is the fault of wrongly pre-formatted FILENAME
  • please note that >>2015 Song EEE<< have erroneous TRACK >>15<<; but is that the fault of wrongly pre-formatted FILENAME
  • please note that >>2015 Song FFF<< have retained >>2015<< as a part of the [real] title and have proper DISCNUMBER and TRACK
  • please note that >>2nd Day<< doesn't become an erroneous >>2 d Day<<; but have erroneous TRACK >>2<<, but that is a very rare case / exception

...and you can note that, when you know, that the overall rule [process] comes to this basics:

  • TRACK / DISCNUMBER are always at the beginning of FILENAME
  • disc number is always a single digit
  • track number has always two digits
  • track number always follows the disc number
  • track number that starts with zero ["01", "02" etc,] is cleared of that zero ["1", "2" etc.]
  • two digits mean there is no disc number at all
  • one digit is not a number for numbering purposes [because it is a part of title of the song]
  • four digits is not a number for numbering purposes [because it is a part of title of the song]
  • TRACK / DISCNUMBER are removed from TITLE / FILENAME at the end of process
  • all new files have all tag fields emptied by me, before acting out the action group
  • contamination of 00 / 000 format in the form of addition of dots / minuses / pauses [following the number] are removed at the end
  • further cleaning of white spaces [and some other possible errors indigenous to my naming system] is done later with other action group

Differences from those rules, when wanting to automatically deliver data to empty TITLE / TRACK / DISCNUMBER tag fields [for the first time when adding new files to the collection] will probably cause some errors. But that's what my nomenclature is for- I stick to designed naming system and profit from it as the times go by

Real errors are only to be expected when updating [changing] TITLE with data from a FILENAME; and only if a song haven't been numbered [and as so have no digits in the TRACK / DISCNUMBER field]; because it will be filled with a part of a title of a song and not a real number of a given track. [And to counter that I can either manually remove a false number like that after using this action group; or prevent it from happening in the first place by starting from now to use some kind of a sign for a non existing track number, for example an empty seat ∅ or a simple minus -; or use a different action group]

And so it works
Or am I wrong, and there I some flaw that I'm currently not foreseeing?

I've taken a look at it. You have some interesting ideas / solutions

Well yes; but

1] Most downloaded tracks are in format 000 / 00
2] There could be [rarely] a "disc" with more than 99 tracks. For example music files extracted from some videogame files
3] More than 9 discs is rarely the case
4] Titles of songs beginning with numbers would also mess up the automation process

So my choice for making an action group for "000 / 00" format [and not "000" or "DDTT"] is made with my main goal in mind: save as much time as possible on the most common appearances of files. I know what material [format] most likely I will get and what info I want o retain [and how]. And that's where the need for the processing of "000 / 00" comes from

That is a good idead; the concept of saving the original info and / or making a temporary value

The overall problem is that there can be different formats, errors in FILENAME [digits format] made by me, all kind of typos, titles containing numbers

And because of that it is up to me to manually oversee and decide what to do in all those excerpts and unusual case; if I wish to maintain order. It can't be fully automatic, because Mp3tag will not think for me [and that is why I separated some actions from this main of mine action group]; and there is no software that thinks like me

I can only think of one more update:

automatically putting a >>1 / 1<< in DISCNUMBER; but only when a TRACK number is being added [delivered from FILENAME] from only two digits format

What would a code for that look like? A code that would put >>1 / 1<< in DISCNUMBER when there is 00 format in FILENAME and at the same time a value [not necessarily a digit] in TRACK tag?

[On the other hand, automatically added >> / 2<<, >> / 3<<, etc. would not be a good idea. Because a new song that is being added can have it's highest number in FILENAME like >>205<< or >>315<< , but that doesn't always mean that there were only 2 or 3 disks. Info like >> / 2<< and >> / 3<< I add via separate action group, after checking manually how many disks a given album has]

It is a burden with the many exceptions.
You should go away from the filename as the central data storage and reference.
Once the filename has been splitted properly into tag-fields, then you can ask the tag-fields and generate all formats as you like.

$if(%TRACK%,then,else)

$if($eql(2,$len($regexp($regexp(%_filename%,'\D',' '),'^(\d+)\D?.*$','$1'))),yes,no)

DD.20150321.2011.CET

Following my proposal from above ...
Format value- the skipping of
... you have only to do ...
Action "Format value"
Field: DISCNUMBER
Formatstring: $if($and(%ORIG_TRACK%,$not(%DISCNUMBER%)),'1/1',)
... or ...
Formatstring: $if($and(%TRACK%,$not(%DISCNUMBER%)),'1/1',)

DD.20150321.2118.CET

Unfortunately you are correct

I did some new work and realized in empirical way, that it would require some sort of pre-formatting [like making all new FILENAMES to 0000 format]- and that would consume more time that the amount of time saved by automating the numbering process [when taking into consideration the existence of files with a empty value being a true value for TRACK and DISCNUMBER; and also taking into consideration some other issues]

Instead I've came up with a workaround: I add the overall disc number [>> / X<<] or single disc value [>>1 / 1<<] at a separate step; and also I've came up with no / unknown value for DISCNUMBER and TRACK, also added at this separate step. And so, every single file has some TRACK / DISCNUMBER value

[And it is not the first time that I came to conclusion, that using some kind of signs for "no value" value rather that an empty value is better, because it gives more information and works as a potential fail safe when operating on tag fields]

For the first step, catching the leading number from 'old file names' ...
this should be no problem ... see step 1 in ...
Format value- the skipping of
... the algorithm allows as input a number string from no digit up to 4 digits.

And later on when the values are stored into tag-fields, you can design the filename as you like it, ...
today this way, tomorrow otherwise.

That's sounds fine. Furthermore, much success!

DD.20150325.1930.CET

... but there is no crucial need to establish a helper value for a non existing value; ...
a non existing value can always be detected by the non existing tag-field.

DD.20150326.0947.CET

I beg to differ

For example: I have a system of "genres" based on numbers [codes]. How do I distinguish a song without category [with "no value" value] from a song that haven't been evaluated yet for my genres [wasn't decided to what category be putted in]? In order to do that I just put "00" to be sure in future, that a given song has been categorized as a "non genre" song [and that it wasn't simply missed by me in the process of "listening for genres"]

Furthermore: can I copy "no value" to another [temporary] field [for the purpose of being copied back later to the original], in the process of running an action group? I have to have at least one space [" "] in the field as a value in order for it to be copied, because no value [""] is not copied back [and I can end up with some new / wrong value that wasn't suppose to be put in this "empty" field]

I do not think I understand that sentence

Could you elaborate on that; give some example?

In general "no value" means "undefined status" or "empty set" ...
in relation to the quantitative definition of possible elements in the set.

Mp3tag can check this situation ...
$if(%FIELD%,'there is something in the field', 'there is nothing')

Therefore "no value" is equivalent to "empty tag-field", ...
which is realized by having no tag-field.

But for your work you want to have a dedicated value, ...
which has the meaning of "no value" ...
therefore this value will become a real member of the set of possible values.

Note: On this consideration, the discovery of the number "zero" is founded.
http://en.wikipedia.org/wiki/0_(number)

For your system you can define values like ...
"genre unknown" ... -1
"genre unsure" ... 0
"genre evaluated and known" ... values greater than 0

If you define the status "no value" to be a non existent tag-field, ...
then a not copied tag-field, ...
... because an empty tag-field does not exist in Mp3tag, ...
transmits automatically the information of "no value", ...
and the status can be interrogated by ...
"$if(%FIELD%,'then ... some value','else ... no value')"

But maybe you dislike such logical coding ...
and you like to work with number ranges ...
$ifgreater(%FIELD%,0,'genre evaluated and known',$ifgreater(%FIELD%,-1,'genre unsure','genre unknown'))

DD.20150330.2142.CEST

I actually use the empty seat sign in two of the tag field, to differ between the states of not knowing / forgotting / skipping the value and having no value

Yes

I prefer to put something for "nothing"

Because I can always easily look for it and change it [replace, split into sub-categories, merge with existing types of characterizations]; and be absolutely sure, that I evaluated a file and not skipped it / made an error

Between ...

"empty set" (german: Nullmenge) "empty seat" (german: Platz frei)

... there is a big difference.

DD.20150408.1800.CEST

0:

One stupid misreading of the

sign, has led me to thinking all this time about it as an "empty seat" and not "empty set"

Now I finally stand corrected