ReClock 1.8.6.8

[rica]

I can't catch you James, i'm tired. Thanks.
Just one question:
What about "slave reference clock to audio"?
Before updating?

 

[James]

I can't catch you James, i'm tired. Thanks.
Just one question:
What about "slave reference clock to audio"?
Before updating?

Play dare.






EDIT:
No, it's not gone.

 

[rica]

No, it's not gone.

THX, this is what i expected :clap:

 

[leeperry]

It's a bit annoying that the volume control over KS takes a half-second to respond, making it tedious to finetune(in loud gunfights for instance)...but we got a buffer, for the best and the worst I guess.

 

[rica]

3... 2...
All the parameters show us it's about to fire up mysterious Slysoft Player rocket????
I think ReClock is the fuel tank of this rocket.

 

[James]

It's a bit annoying that the volume control over KS takes a half-second to respond, making it tedious to finetune(in loud gunfights for instance)...but we got a buffer, for the best and the worst I guess.

The delay is indeed caused by the buffer (the larger the buffer, the longer the delay). You'll have to live with it.

 

[rica]

3... 2...
All the parameters show us it's about to fire up mysterious Slysoft Player rocket????
I think ReClock is the fuel tank of this rocket.

James, am i right?
Or is it just a conspiracy theory?
Or not?



_ _ _ _ _

 

[James]

James, am i right?
Or is it just a conspiracy theory?
Or not?

Little do I know.

 

[rica]

Little do I know.

I got it at least it's not a conspiracy theory

 

[yesgrey3]

As you are the "official ReClock code reviewer(tm)"

That's my middle name.

here is something for you to review.

m_currentKSVolume is a double with a value between 0.0 (0%) and 1.0 (100%). The cast double to float seems to round correctly (I checked with debugger).

The code looks good to me, and yes, the double to float conversion should be pretty straightforward...

Here is how m_currentKSVolume is set.

I have one doubt about this code, but first one suggestion. I think it would be preferable to perform the subtractions between "long" before the conversion to double. It's slightly more precise in case there isn't a double that represents exactly the long. Like this:

	// units of 6db
	double l_att = ((double)(DSBVOLUME_MAX - m_currentVolume)) / (100.0 * 6.0);
	double l_factor = 1.0 / pow(2.0, l_att);
	m_currentKSVolume = l_factor * (((double)(m_currentVolume - DSBVOLUME_MIN)) / ((double)(DSBVOLUME_MAX - DSBVOLUME_MIN)));

Now, my doubt: Why are you using 6dB steps and then a 2^x formula and all the other stuff instead of the 1dB steps with the 10^x formula?
For example, why not doing it simply like this:

	double l_att = ((double)(DSBVOLUME_MAX - m_currentVolume)) / 100.0;
	m_currentKSVolume = 1.0 / pow(10.0, l_att/20.0);

Also, just to be sure that no issues with floating point math will affect the "no attenuation" mode I would do something like this:

if (m_currentVolume == DSBVOLUME_MAX)
	m_currentKSVolume = 1.0;
else
{
	double l_att = ((double)(DSBVOLUME_MAX - m_currentVolume)) / 100.0;
	m_currentKSVolume = 1.0 / pow(10.0, l_att/20.0);
}

Here the speed is unimportant, but we have to be sure that m_currentKSVolume is 1.0 and not 0.99999999999999. (yes, picky is my second middle name )

And thanks for sharing the code.

 

[James]

Thank you for your feedback!

The code looks good to me, and yes, the double to float conversion should be pretty straightforward...

Fine. Where do you think attenuation should be done? Before or after resampling? (I believe it is before at the moment)
Before or after timeshifting? (I believe it is before at the moment)
Obviously after the compressor (I am not sure if it is correct at the moment, I'll have to look up the code)

I have one doubt about this code, but first one suggestion. I think it would be preferable to perform the subtractions between "long" before the conversion to double. It's slightly more precise in case there isn't a double that represents exactly the long. Like this:

	// units of 6db
	double l_att = ((double)(DSBVOLUME_MAX - m_currentVolume)) / (100.0 * 6.0);
	double l_factor = 1.0 / pow(2.0, l_att);
	m_currentKSVolume = l_factor * (((double)(m_currentVolume - DSBVOLUME_MIN)) / ((double)(DSBVOLUME_MAX - DSBVOLUME_MIN)));

Now, my doubt: Why are you using 6dB steps and then a 2^x formula and all the other stuff instead of the 1dB steps with the 10^x formula?
For example, why not doing it simply like this:

	double l_att = ((double)(DSBVOLUME_MAX - m_currentVolume)) / 100.0;
	m_currentKSVolume = 1.0 / pow(10.0, l_att/20.0);

I believe I was seriously confused. It looks better to me your way.

Also, just to be sure that no issues with floating point math will affect the "no attenuation" mode I would do something like this:

if (m_currentVolume == DSBVOLUME_MAX)
	m_currentKSVolume = 1.0;
else
{
	double l_att = ((double)(DSBVOLUME_MAX - m_currentVolume)) / 100.0;
	m_currentKSVolume = 1.0 / pow(10.0, l_att/20.0);
}

Here the speed is unimportant, but we have to be sure that m_currentKSVolume is 1.0 and not 0.99999999999999. (yes, picky is my second middle name )

You have a point. I'll add this.

 

[James]

Thank you for your feedback!
Where do you think attenuation should be done? Before or after resampling? (I believe it is before at the moment)
Before or after timeshifting? (I believe it is before at the moment)
Obviously after the compressor (I am not sure if it is correct at the moment, I'll have to look up the code)

Attenuation is done before the compressor, which is wrong. I don't know if I can (or want) to change it, as this would result in some work.

The chain is

format conversion -> time stretch -> volume control -> resampler -> compressor -> mute -> mono expansion -> format conversion

I certainly don't want the compressor before the resampler in the chain.
If people want to use the compressor, they'll have to crank up the volume. Maybe the volume control can even help to fine tune the compressor...?
I never use it, so I don't know.

 

[yesgrey3]

Attenuation is done before the compressor, which is wrong. I don't know if I can (or want) to change it, as this would result in some work.

I don't know what you are referring as the compressor. I am considering it to be the code for guarantying no clipping after resampling.

Only after resampling we will know if any clipping occurs, so the compressor need to be used after it. Furthermore, I think that the volume control would be preferable after resampling. Resampling adds noise, so, if we lower the volume before, it might happen that the S/N ratio would be a little lower (I don't know if the noise is proportional to the input signal), while changing the volume after decreases both signal and noise by the same amount. The best place for the volume change would be after resampling and before the compressor, which would avoid the compressor usage in some situations...
If that's too much work, you could try to put the volume control at the end. Even though it would not be ideal to have another volume decreasing after the compression, it might not be a problem, because as we already know the compressor is there just for precaution...

The ideal chain would then be:
format conversion -> time stretch -> resampler -> volume control -> compressor -> mute -> mono expansion -> format conversion

Having said that, I don't believe anyone would be capable of hearing the difference between having the volume control where it is now vs the ideal position, so, if it's too much work, simply don't bother.8)

And once again, thanks for hearing us.

 

[James]

I don't know what you are referring as the compressor. I am considering it to be the code for guarantying no clipping after resampling.

No, ReClock does have a sound compressor. It's in the properties in the "sound adaptation" group.

 

[James]

Furthermore, I think that the volume control would be preferable after resampling. Resampling adds noise, so, if we lower the volume before, it might happen that the S/N ratio would be a little lower (I don't know if the noise is proportional to the input signal), while changing the volume after decreases both signal and noise by the same amount.

Interesting point. I've put it before the resampler because I didn't want to increase CPU / FPU load (when increasing the sample rate).
EDIT: And I assumed that reducing volume to the resampler input will avoid clipping at the output anyway.

 

[yesgrey3]

No, ReClock does have a sound compressor. It's in the properties in the "sound adaptation" group.

Right, I forgot it. I've never used it, hence not remembering it... Also, I only checked in the config dialogs, I did not remember the properties dialog...
So, I think it would not be problematic to have volume control after it. Besides, the quality would be so compromised when using it that it would not matter where the volume control is.

Interesting point. I've put it before the resampler because I didn't want to increase CPU / FPU load (when increasing the sample rate).
EDIT: And I assumed that reducing volume to the resampler input will avoid clipping at the output anyway.

Yes, both true, but I don't think the cpu load of a simple multiplication would be significative... As I've said, it's your call, I'm not really intending to use it when watching my movies in "quality mode", so it's not a problem to me. Though, for day to day usage, it's a very nice feature to have... no more need to change to directsound whenever I need volume control.

 

[James]

Right, I forgot it. I've never used it, hence not remembering it... Also, I only checked in the config dialogs, I did not remember the properties dialog...
So, I think it would not be problematic to have volume control after it. Besides, the quality would be so compromised when using it that it would not matter where the volume control is.

Yes, but as it is a "compressor" it makes sense that it receives full volume. Otherwise it tries to amplify the signal previously attenuated.

Yes, both true, but I don't think the cpu load of a simple multiplication would be significative...

I changed the chain like this:

format conversion -> time stretch -> resampler -> compressor -> volume control -> mute -> mono expansion -> format conversion

(Not that it'll make much of a difference.... )

 

[leeperry]

I assumed that reducing volume to the resampler input will avoid clipping at the output anyway.

indeed, there's no point for clipping detection when the volume attenuation's enabled...eagerly awaiting b69 then

 

[yesgrey3]

Yes, but as it is a "compressor" it makes sense that it receives full volume. Otherwise it tries to amplify the signal previously attenuated.

Yes, they would fight against each other...

I changed the chain like this:

format conversion -> time stretch -> resampler -> compressor -> volume control -> mute -> mono expansion -> format conversion

(Not that it'll make much of a difference.... )

Agreed.

 

[leeperry]

The chain is

format conversion -> time stretch -> volume control -> resampler -> compressor -> mute -> mono expansion -> format conversion

I changed the chain like this:

format conversion -> time stretch -> resampler -> compressor -> volume control -> mute -> mono expansion -> format conversion

well, I use very high attenuation, so processing it after the resampler should make for a nice improvement hopefully? as long as it's also enabled when the resampler's not in use so I don't blast my ears off on mismatched refresh rates

hope you can release b69 soon enough, thanks again James!