Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[InflatableMouse]

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.

[Micromecca]

Sample Rates are not always exact, sounds like the track is slightly off and JRiver is displaying the actual rate.

[Henglander]

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)

[InflatableMouse]

Thanks!

[MrC]

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).

[InflatableMouse]

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!

[MrC]

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.

[InflatableMouse]

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 .

[Micromecca]

Incorrect describes your answer exactly.

Could you be more specific? are you saying that sample rates are always exact?

[MrC]

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.

[Micromecca]

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  ?

[Matt]

Next build:
Fixed: The Trunc(...) math expression function could show incorrect results in some cases.

[MrC]

Thanks.

It seems a side affect of the change is that math(44100 / 1000) now correctly results in 44.1.

[Matt]

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.