INTERACT FORUM
More => Old Versions => JRiver Media Center 19 for Windows => Topic started by: InflatableMouse on September 21, 2013, 07:23:59 am
-
math(removeright([sample Rate],3 / 1000) returns 44,099998 but obviously I'd like that to be 44,1 (not sure why it isn't 44.1, isn't the sample rate exactly 44100 Hz?).
I tried wrapping the math expression in round() and trunc() but that doesn't seem to work ?
Using MC 19.0.41.
-
Sample Rates are not always exact, sounds like the track is slightly off and JRiver is displaying the actual rate.
-
Sample Rates are not always exact, sounds like the track is slightly off and JRiver is displaying the actual rate.
Incorrect describes your answer exactly.
The error is a side effective of the precision of 32bit float value division and the values used
To overcome this try
FormatNumber(math(removeright([Sample Rate],3)/1000),1)
-
Thanks!
-
You can use [Sample Rate,0] and avoid the RemoveRight() since you'll then be dealing with raw, unformated numbers. Whenever working in Math(), use raw field values.
FormatNumber(math([Sample Rate,0] / 1000), 1)
It appears the trunc() function is not working correctly (see attached).
-
Ah I accidently led to that bug then, I was doing round(math()) and trunc(math()), figuring I was rounding the result of math(). Now I reread the wiki and trunc() and round() are formatting functions inside math() and not independent functions ... :-[.
Tx again!
-
Right.
And your first expression was missing a closing paren after the ,3 in RemoveRight(). Probably just a typo in the post though, since you'd would have seen an expression error.
-
Indeed.
I find myself getting lost in parentheses and commas. Notepad++ helps as it marks the opening or closing paren when the cursor is on one. I keep pulling the expressions apart and testing each part in a nested expression separately.
These expression textboxes need syntax formatting with fancy colors :).
-
Incorrect describes your answer exactly.
Could you be more specific? are you saying that sample rates are always exact?
-
The sample rate is an integer. But when you divide by 1000, the result is no longer exact due to 32 bit math errors. 44,100 / 1000 should result in 44.1, not 44.099998.
-
Thanks I understand that now, but my question relates to the actual sample rate of the file, If I set my DAC to display the actual sample rate rather than the nominal rate, it can be slightly over or less depending on the file ?
-
Next build:
Fixed: The Trunc(...) math expression function could show incorrect results in some cases.
-
Thanks.
It seems a side affect of the change is that math(44100 / 1000) now correctly results in 44.1.
-
Thanks.
It seems a side affect of the change is that math(44100 / 1000) now correctly results in 44.1.
We were using 32-bit floating point precision in one part of the chain instead of 64-bit, causing precision gremlins like that.