Revisit moving text from title to text artist

[ohrenkino]

@ohrenkino

%artist% $regexp(%title%,'(.*) \((.*)\)',$2==$1)

Element	Purpose
%artist%	take the contents of the field %ARTIST%
$regexp	use a regular expression with the following parameters
%title%	take the contents of the field %TITLE%
(.*)	capture any amount of any characters into the first capture group
\(	until you reach an opening bracket which has to be escaped with \ as the brackets serve a special purpose otherwise
(.*)	capture any amount of any characters into the second capture group
\)	until you reach a closing bracket which has to be escaped with \ as the brackets serve a special purpose otherwise
$2	output the contents of the second capture group
==	unique separators for the next, the "guessing" step - could be anything as long as they are unique
$1	Output the contents of the first capture group.

So Forward (Ft. James Blake) is transformed to (Ft. James Blake)==Forward
and in total the string in Source format now reads
Beyoncé (Ft. James Blake)==Forward
which then is guessed by the pattern %artist%==%title%

[ohrenkino]

@mbrazil05

any idea of how to accomplish this?

Source format: %artist% $regexp(%title%,'(.*) \((.*?)\) (.*)',$2==$1 $3)
Guessing pattern: %artist%==%title%

[mbrazil05]

@ohrenkino

%artist%==%title%

PERFECT!!!!! and this is the part where I ask If I can buy you "coffee" again!! THANK YOU, THANK YOU, THANK YOU.

[mbrazil05]

@ohrenkino

%artist% $regexp(%title%,'(.) ((.))',$2==$1)

i'm trying to understand the code and put the bits in their place. Can you check/edit as needed? I don't understand the last part so I put the ????

%artist% Take the contents of the field %ARTIST%
Busta Rhymes

$regexp use a regular expression with the following parameters

%title% take the contents of the field %TITLE%
Twerk It

(.*) capture any amount of any characters into the first capture group
Twerk It

( until you reach an opening bracket
Twerk It (

(.*) capture any amount of any characters into the second capture group
Feat. Vybz Kartel, Ne-Yo

) until you reach a closing bracket
Feat. Vybz Kartel, Ne-Yo)

$2 output the contents of the second capture group
Feat. Vybz Kartel, Ne-Yo

== unique separators for the next step - could be anything as long as it is unique

$1 Output the second capture group.
?????

[ohrenkino]

@mbrazil05

Twerk It

Should be the whole contents of TITLE
Twerk it (Feat. Vybz Kartel, Ne-Yo)

@mbrazil05

) until you reach a closing bracket
Feat. Vybz Kartel, Ne-Yo)

is just the ) - no Feat. Vybz Kartel, Ne-Yo as that is already in the second capture group

@mbrazil05

Output the second capture group.

Sorry, copy&paste error - should be first capture group

[Casual_Tea]

@ohrenkino

Source format: %artist% $regexp(%title%,'(.*) \((.*?)\) (.*)',$2==$1 $3)
Guessing pattern: %artist%==%title%

Interesting approach, but I'd personally use an action group that only matches when one of these:

@ohrenkino

Also, I would consider to unify all the variation of Featuring Feat. Ft. featuring feat. ft. with just 1 string part.

is present to avoid accidentally moving unrelated content within braces.

After a bit of tinkering, here's the solution I came up with that transforms this:

into this:

with one execution.

Action Group:
Name: Feat. to artist

1st action:
Format value:
Field: ARTIST
Format string:

%artist%$if($neql($regexp(%title%,^(.*?) \(((?:Ft\.|Feat\.|Featuring).*?)\) ?(.*)$,$2,1),%title%), $regexp(%title%,^(.*?) \(((?:Ft\.|Feat\.|Featuring).*?)\) ?(.*)$,$2,1),)

2nd action:
Format value:
Field: TITLE
Format string:

$if($neql($regexp(%title%,^(.*?) \(((?:Ft\.|Feat\.|Featuring).*?)\) ?(.*)$,$2,1),%title%),$regexp(%title%,^(.*?) \(((?:Ft\.|Feat\.|Featuring).*?)\)(.*)$,$1$3,1),%title%)

Feel free to ask if you'd like me to explain how they work.
It's also possible to conform all versions of ft., feat., featuring etc. into one (feat. for example). Doing this before using the 2 actions I've provided would allow to further reduce their complexity and improve their readability.

[LyricsLover]

Just a small side note:

The regular expression function $regexp can be used with a 4th parameter:

$regexp(x,e,r,c) replaces the pattern specified by the regular expression e in the string x by r. The optional fourth parameter c enables ignore case (1) or disables the ignore case setting (0). Please note that you have to escape comma and other special characters in e.

I'm pretty sure you can reduce the complexity in your $regexp if you apply this 4th parameter instead of using the F (uppercase) and f (lowercase) repeatedly.

[Casual_Tea]

I forgot about that, thanks. I've adjusted the regexes accordingly.

[ohrenkino]

@Casual_Tea

Doing this before using the 2 actions

The descrete charme of the "Guess value" approach is that you have only 1 action and therefore you have to apply (and maintain) the regular expression only once.

[Casual_Tea]

@ohrenkino

1 action and therefore you have to apply (and maintain) the regular expression only once.

That's the trade-off between precision/safety and ease of use. Sadly for my "safeguarded" actions that don't change the content when there's no match, you even have to maintain the same regex twice per action.
I've asked in the past if there's a less wordy/complex way to abort an action if the regex does not match, but nothing came of it. So wordy it is I guess.

Both approaches are valid tho. If you're comfortable with using filters, filtering and then using less complex/wordy guess value actions should be faster and easier.
I'm usually too lazy to filter so I overengineer my actions to a point where I can run them on pretty much all tracks (at least of one album at a time) without having to worry about them doing harm. However I still check all results manually.

[ohrenkino]

@Casual_Tea

If you're comfortable with using filters

My experience in reading the various problems in this forum led me to the conclusion that very often owners of large collections do not really know the variations of their data.
Just like in this case where there was not just 1 pair of brackets but all of a sudden several.
The filter should pretty much reflect the initial assumption what the data looks like and limit the number of treated files.
And then comes the analysis why some files did not get treated.
And this should broaden the knowledge about the real character of one's collection.
Once I found all the borderline cases, I can create actions that deal with even the odd one's out.
But until then, to limit the damage, it is safer to use filters.

[Casual_Tea]

@ohrenkino

very often owners of large collections do not really know the variations of their data

Agreed.

I have a similar mindset but go the opposite direction. When I write an action I try (emphasis on "try") to make it so precise that it only matches exactly what I'm working with currently. And when I later on encounter files that are not changed by it but should have been (or files that were changed and should not have been), I revisit the action and adjust for these cases.

I found I'm much faster and less mentally taxed when I don't have to think about filters before performing changes (and I often run 10+ action groups on a set of files), but maybe that's just me.
Filtering and then narrowing down possible cases to improve the actions seems like a good workflow as well tho. Thanks for the insight!