The ‘Filter’ option within a script line is actually a search text condition in which you can describe your selection criteria’s.
The same expressions are used as already used in the ‘Find-Window’.
You might define Filters to limit the result of your search or to limit the returned media entries within a script-line.
There are two modes to define a Filter:
a) complex Filters
b) simple Filters
Complex Filters can be created using the 'Advanced Find Expression Builder', which can be invoked by clicking on the '?' button next to the filter editor field.
This dialog allows you to specify any kind of filter containing any number of (nested) filters and allows you to logically combine any available meta data field.
Simple Filters are a bit limited, but more easy to use. Here is a description with some examples:
The filter expression consists of a <prefix> and <criteria> (separated by a colon ‘:’).
The <prefix> tells the parser what to search for and the <criteria> contains the actual value to look after.
The following <prefix> are supported:
'title' or 't': title contains key
'artist' or 'a': artist contains key
'album' or 'l': album contains key
'mood' or 'm': mood contains key
'grouping' or 'g': grouping contains key
'isrc' or 'i': isrc contains key
'rating' or 'r': rating contains key
'bpm' or 'b': bpm greater than key
'year' or 'y': year contains key
'genre' or 'e': genre contains key
(if no prefix is given a title search is used)
Use '&' or '+' to combine multiple keys
Use '!' in front of the <prefix> to negate the key.
By default a case-insensitive contains match is used for the search.
Use '=' in front of the <prefix> to perform a case-sensitive exact match serach.
The prefixes ‘bpm’ or ‘b’ as well as ‘rating’ or ‘r’ are somewhat special, as they perform a numeric evaluation of the <criteria> key.
Which means the standard match performs a numeric ‘GreaterOrEqual’ comparison – whereas the exclusion performs a numeric ‘Less’ comparison.
All other prefixes perform a case-insensitive string based ‘Contains’ comparison.
Here are some examples:
't:hello & a:james'
Will match, if the TITLE contains “hello” and the ARTIST contains “james”!
'b:120 + !b:131'
Will match, if the BPM is between 120 and 130!
'r:80 + !r:81'
Will match, if the RATING is exactly 80!
Will match, if the RATING is greater or equal to 40!
Will match, if the RATING is less than 100!
'r:40 + !r:61'
Will match, if the RATING is between 40 and 60!
'r:40 + !r:61 & a:toto'
Will match, if the RATING is between 40 and 60 and the ARTIST contains “toto”!
Some more notes:
a) As the script filter rules might not guarantee, that any track at all in your selected media lib matches the criteria’s, I had to implement some maximum within the try-matching algorithm. This means there is an upper limit of 2 times the number of tracks contained in your media lib or a maximum of 300 tries. If the script cannot determine a track which matches the filter criteria, it will take a next track anyhow. This is needed in order to prevent the script from not being able to deliver new tracks to a playlist.
b) As you might be using folder based media libraries the TAG data is not read from the related audio tracks at startup (unless you have specified the ‘Force TAG reading’ option in the settings).
As such the script evaluates this and might need to read the TAG data on-the-fly if needed.
The result might be, that this on-the-fly TAG reading will cost some time and performance – especially when a lot of tracks needs to be tested.
So an advice would be to use the ProppFrexx-Playlist-Format (.pfp) to store your media entries in (and use the .pfp files as your media libraries) – as the .pfp playlist format directly keeps all TAG data within its format and such no extra TAG reading is needed.
c) This is also the difference between the Find-Window and the Script-Filter option. The Find-Window will not perform any on-the-fly TAG reading! This because, when you are search you entire media libraries with thousands of tracks, any on-the-fly TAG reading would simply kill your system IO performance, if all tracks needs to be accessed for TAG reading.
So using the search criteria’s in the Find-Window will also work best, when using .pfp based media libraries.
d) But of course folder based media libraries works quite well, as:
- in the Find-Window you typically search for a title or artist – if the folder based media entries haven’t read any TAG data yet, the Find-Window also evaluates the filename in its search.
- for the Script Filter on-the-fly TAG reading is performed to guarantee exact results (you might simply discover a little higher IO/CPU hit)
You have a question or need an advice about how to do something? Ask it here!
1 post • Page 1 of 1
Who is online
Users browsing this forum: Google [Bot] and 17 guests