Check if field value is identical for all selected tracks

Hello,

if you select a number of files and the values differ for a field, Mp3tag will display < keep > for that field. If the value is the same for all files, it just displays the value itself.

Is it possible to perform such a check in export, too? I want it to write the value if it's the same for all selected files, but write some fixed value like "Various" if it differs.

I tried it with a user-defined variable and a seperate loop like this:

$loop(%_app%)$puts(check,%field%)$loopend()
$loop(%_path%)$if($eql($get(check),%field%),,$puts(check,Various))
$loopend()$get(check)

Setting the variable first (so it can be checked against), then check if it matches for each track. If it doesn't, set it to "Various". Then, after the loop has ended, get the value.
For some reason it always sets the variable to "Various" as soon as I put $puts(check,Various) in the false-part of that $if-function, regardless if the false-part actually comes in play or not. If I place something else there, say a plain text "not equal", it works perfectly.

I hope I'm just missing something obvious or doing something wrong. Thanks in advance.

I've tried something similar recently and came to the conclusion, that the $put/$get variable is lost when another $loop starts.

I don't know if this is wanted behaviour or if there is any way around that.

I think, in a Mp3tag export script the visibility of a user defined variable is limited to the current loop block.
And yes, there might be a trick to use a user-defined variable, which has been defined outside of the current loop block.
I remember I have discovered something like this ... once the user-defined variable has been 'elevated' into the 'global loop stage memory' it can be used within other loop blocks.
Sadly I do not know it from my memory yet, how I have done it.
( ... try to find some of my recent export scripts here in the forum. ... ;-))

Hmm, study the attached test export script, maybe you can see how it could work.
20110601.Test.Visibility._puts.mte (2 KB)

DD.20120321.0630.CET

20110601.Test.Visibility._puts.mte (2 KB)

Thanks for your replies!
After studying your test script, DetlevD, I performed another test myself.
The problem doesn't seem to be the visibility - I can set it in loop1 and then get it in loop2 without problems. The problem I face is that I can't control if a value gets set or not. $put and $puts seem to ignore any conditions.
See my attached test script:

loopvariabletest.mte (3.25 KB)

$loop(%_app%)$puts(check,%artist%)$loopend()
$loop(%_path%)$puts(check,$if($eql($get(check),%artist%),%artist%,Various))
$loopend()$get(check)

Wow, awesome! I was so close. :slight_smile:
It works perfectly, thanks a lot dano!

Knowing that bit about controlling variables would still be interesting, though.

Hi there.
Hurrrg... I spent a lot of time with this one! :frowning:
I've been having this problem for months now. Initially I thought it was me doing something wrong, but it wasn't me. I really think it is a bug.
I also checked the code you supplied here, which I thank, but unfortunately it didn't solve my particular problem. :frowning:

However I did find one important thing:
Mp3tag sometimes looses the variables values between iterations, because apparently it only commits a variable value after a $loopend() command.
This is the conclusion to which I reached.
Please try to confirm that for yourself.

So, I managed to find a turn-around.
If we make a short loop with one iteration and set the variable inside it, that variable will hold its value in later loops. :wink:

Here is an example of how to set a variable named "OrigDuplID" with the value of field: %TrackID%

$loop(1,1)$puts(OrigDuplID,%TrackID%)$loopend()

This way that variable may be used later with the correct value, otherwise it would always have the value from the previous record.
How annoying that was!

In my opinion this is clearly a bug and it is a very critical one.
Why? Because it destroys the main goal of creating variables, and therefore, of using export and therefore of using the only programming language available in Mp3Tag. :frowning:

It's a pity it hasn't been fixed yet... this one really needs and deserves to be fixed. :slight_smile:

I have a working example of this for a specific case in which I automatically detect and mark duplicates of tracks. If someone wants it, just ask.