MediaMonkey forum

Strange, I'm sure I tried that too... Maybe it didn't work because I used an older version (altough 1.6)...

Thanks!

renowden wrote:I have said against custom fields that you need to beware of unexpected results or errors if your name clashes with and existing field name or other reserved word. I suspect that the reserved word problem is no longer an issue since the fields have been enclosed in <angle brackets>. Correct?

You could use a name for the custom field which contain for example the word Year (e.g. Release Year), but you should not name the custom field Year, because there already exists such field name. I didn't tried it, but I suppose there is no restriction on reserver words (eg. Select or Statistic).

No spaces are permitted in masks except
. Where Fields or Qualifiers contain spaces in which cae they should be single plain spaces
. In filter expressions where spaces can be added for readability.

Correct?

Yeah, spaces are currently not permitted in masks except:
- inside of field names (e.g. Album Artist);
- inside of names of qualifiers (e.g. Sort by);
- inside of expressions of Filter and SQL Filter qualifiers;
- between aggregate functions of Sort by and Statistic qualifiers, if they have multiple arguments (e.g. Statistic:Min(Year), Max(Year)), although you could write same qualifier without spaces between arguments (e.g. Statistic:Min(Year),Max(Year)).

In all mentioned cases you should use exactly one space character, except of Filter and SQL Filter expressions where you could use many of them in sequence (but I think there is not a real need for this).

I highly recommend putting spaces around of arithmetic and logical operators and after comma when separating arguments of functions. Please folks (Bex, you are reading this?), try to write more readable expressions.

I am not sure of the exact syntax for the arguments for the Child of: qualifier - are they closed up as I have shown or are there space in theer? e.g. MyComputer or My Computer?

You wrote correct syntax for Child of qualifier - its arguments shouldn't have space in the name. But if you think that they should, I could modify the script for this.

Sorry, I made a mistake again. It is recommended that names of custom fields shouldn't have SQL reserved words. This is main reason why I changed names of Album AND Artist and Album AND Year fields. For example, what if somebody give a name Album AND Artist to the custom field? Let's take a look on the following expression:
It is perfectly legal for SQL. Angle brackets are mathematical symbols for less then and greater then, right? So, here is an equivalent expression: The script code couldn't know what is about the first expression - regular SQL expression with two fields or one Magic Nodes' field.

I noticed that in MM3 the node
does not really work for me anymore. The english decimal point is ignored and I get average ratings like 43333333333333,5 stars. (in German the delimiter is a coma)

In MM2 the node works perfectly.

Is this easily fixable? By setting language options or something? Or do we (non english) have to live with that?

There is a new revision of the script (1.6.2.3) with removed a bug when Avg(Rating) is used. Thanks to julial49 for the report.

Hello,

I just found out, that the BitRate is rounded to 32k, which is bad for VBR.

I changed: to and it looks well.

Hello,

I just found out that the qualifier "left of" (and "right of") works on uppercase arguments only.

I simply changed: to:

and it works. (same for "right of")

Big Isch wrote:I just found out that the qualifier "left of" (and "right of") works on uppercase arguments only.

Very interesting. Thanks for the report. Anyway, your solution is not very well if you want same behavior in MM2 (case insensitive) and MM3 (case sensitive). Next revision of the script will include that.

Big Isch wrote:I just found out, that the BitRate is rounded to 32k, which is bad for VBR.

Well, that line of code is only for a display of nodes. If you take a look on the line 921, you could see bitrate expression used for sorting/statistic which is not rounded to 32 kB. With your modification, there are displayed too many nodes for VBR files which is not desirable.

Hello,

Yes, displaying the Bitrate for VBR yields to a lot of Nodes.
Roundig to 32k is good for catigorizing.

May a propose a "Bitrate" and a "BitrateExact" ?

Big Isch wrote:May a propose a "Bitrate" and a "BitrateExact" ?

Can you give me a good reason for that? Why somebody would need 160 nodes with different bitrates? This is a number which I get with following masks and your modification:
Maybe I could change the script with a round to some smaller value (16 kB or 8 kB), but 1 kB is really too small.

Hello,

The reason for "Exact" was the fact that I statistically looked at VBR encoding with "Lame q=3". I just wanted to see distribution.

But for listening, 1k rounding is too much as you say. Maybe 32k is too big - as 112kbps would not display.
So your suggestion with 4k or 8K seems very fine to me.

I have just uploaded the manual for Magic Nodes Draft 4 to the same place as before i.e. http://west-penwith.org.uk/misc/MagicNodes.pdf

I hope that will be the last Draft for version 1.6 of the script and, after some fine checking, the next release can be a Final.

There are a lot of stylistic changes to this version to aid readability.

renowden wrote:There are a lot of stylistic changes to this version to aid readability.

Very nice indeed. But, I need to repeat my suggestions about a numeration of pages. Table of contents and Acknowledgments should have its own page numeration (Roman I, II, III, or i, ii, iii,...), Installation chapter should start with page 1 - please, take a look on any book and you will see such thing.

Sorry, I forgot to mention - there are some additions if you want to include them:
- Bitrate is (currently) "Rounded to multiples of 32 in kbps." only for display of nodes. Display of sorting/statistic are rounded to 1 kbps. When used inside of Filter/SQL Filter qualifiers it should be exactly same as in database, e.g. Filter:<Bitrate> = 128 will not return 129 kbps file, neither 128.1 kbps, instead it should be used something like: Filter:CAST(32 * Round(Songs.Bitrate / 32000.0) AS integer) = 128.

- Channels is displayed as Mono, Stereo or Surround only as node. When used in Filter/SQL Filter it is 0, 1 or some value > 1. e.g. Filter:<Channels> = 0, if you want to display only Mono tracks. You could write a description like this: 0 (Mono), 1 (Stereo) or > 1 (Surround).

- File Size is in MB only when displayed as nodes, or as result of sort by/statistic. When used in Filter/SQL Filter it is in bytes.

- Length is displayed with "xx to xx+1 minutes" as node, but with [[hours:]minutes:]seconds as a result of sort by/statistic. When used in Filter/SQL Filter it is in ms, for example you should use Filter:<Length> < 5 * 60 * 1000 if you want to display only songs less then 5 minutes.

- Rating is 0, 0.5, 1, 1.5, 2, ... 5 only when displayed as nodes, or as result of sort by/statistic. When used in Filter/SQL Filter it is in range from 0 to 100.

- Sample rate is in kHz only when displayed as nodes, or as a result of sort by/statistic. When used in Filter/SQL Filter it is Hz.

- VBR is displayed as VBR, CBR or N/A only as node. When used in Filter/SQL Filter it is 0 (CBR), 1 (VBR) or -1 (N/A). e.g. Filter:<VBR> = 0 if you want to display only CBR tracks.

Thanks!

OK - I have picked those up and have finally figured out how to start page numbering on the second page, though I don't think that is a big deal on a document of this length - it is not a book! I have also reinstated the footer with the page number which got lost along the way but I can't get dynamic linking to work.

The implications of what you say about some of the fields used in expressions suggest that more than I thought can be used in this way e.g. VBR & Channels were not flagged with a %. Are there any more e.g. Cover Storage, Cover type, Drive Type?

After that I think we should leave it there for the first edition and you should publish a link on the front page of this thread and on the web site. If there are any other fixes then we can accumulate then for a second edition, coming out perhaps when you next do a major script revision.