INTERACT FORUM

More => Old Versions => JRiver Media Center 19 for Windows => Topic started by: InflatableMouse on September 21, 2013, 07:23:59 am

Title: Rounding a value returned from math [Solved]
Post 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.
Title: Re: Rounding a value returned from math
Post by: Micromecca on September 21, 2013, 07:31:57 am
Sample Rates are not always exact, sounds like the track is slightly off and JRiver is displaying the actual rate.
Title: Re: Rounding a value returned from math
Post by: Henglander on September 21, 2013, 11:36:45 am
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)
Title: Re: Rounding a value returned from math
Post by: InflatableMouse on September 21, 2013, 12:01:44 pm
Thanks!
Title: Re: Rounding a value returned from math
Post by: MrC on September 21, 2013, 12:32:12 pm
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).
Title: Re: Rounding a value returned from math
Post by: InflatableMouse on September 21, 2013, 12:49:31 pm
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!
Title: Re: Rounding a value returned from math
Post by: MrC on September 21, 2013, 01:08:37 pm
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.
Title: Re: Rounding a value returned from math
Post by: InflatableMouse on September 21, 2013, 01:15:37 pm
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 :).
Title: Re: Rounding a value returned from math
Post by: Micromecca on September 21, 2013, 08:47:56 pm
Incorrect describes your answer exactly.

Could you be more specific? are you saying that sample rates are always exact?
Title: Re: Rounding a value returned from math
Post by: MrC on September 21, 2013, 09:07:52 pm
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.
Title: Re: Rounding a value returned from math
Post by: Micromecca on September 21, 2013, 09:12:23 pm
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  ?
Title: Re: Rounding a value returned from math [Solved]
Post by: Matt on September 23, 2013, 04:44:35 pm
Next build:
Fixed: The Trunc(...) math expression function could show incorrect results in some cases.
Title: Re: Rounding a value returned from math [Solved]
Post by: MrC on September 23, 2013, 06:08:08 pm
Thanks.

It seems a side affect of the change is that math(44100 / 1000) now correctly results in 44.1.
Title: Re: Rounding a value returned from math [Solved]
Post by: Matt on September 23, 2013, 07:28:19 pm
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.