ReClock 1.8.6.3

[James]

Watching PAL DVDs?
Here's why you need ReClock: http://www.schmidt-web.info/malte/english.html
(unfortunately the sound examples were removed from the site... )

http://sandbox.slysoft.com/beta/SetupReClock1863.exe

1.8.6.3 - 20/02/2010
* Fix: Possible crash
* Some fixes and improvements

Source code for GPL'ed code is available here:
http://oss.slysoft.com/ReClock/

 

[leeperry]

will look into it

BTW, James...using KS in PCM over S/PDIF doesn't allow any windows volume control at all

if you still got plans to set up two hotkeys to change the resampler output volume(±5% or so), this would be much appreciated

I'm using an external amp(together w/ an external DAC connected in toslink S/PDIF), but the stupid thing has a 24 stepped attenuator...so it's not precise at all: http://www.bursonaudio.com/hp_volume_control.htm

I'll watch a bunch of movies w/ b63 now, hopefully the random pops will be history..

 

[Doman]

Thanks my man.

 

[Razoola]

Thanks for the new release. So far so good in relation to the system freezes I was experiancing with the last build. I can't say for sure that issue is gone as I need to do more testing but so far no problems

The issue with the 'auto' media adaptation speed setting not understanding the refresh rate is at a multiple of 24 (audio passthrough mode only) still happens. This causes the yellow icon and reclock reporting it needs a refresh rate multiple of 24 even though it already has it. Manually changing the speed setting fixes the issue though.

 

[Kazuya]

Thanks for the new reclock, I stayed on 1.8.5.4 until now.

Little question : is it normal it uses 50% more CPU ressources ?
For the same thing, it increases from 8.9% to 13.5%.

 

[James]

Thanks for the new reclock, I stayed on 1.8.5.4 until now.

Little question : is it normal it uses 50% more CPU ressources ?
For the same thing, it increases from 8.9% to 13.5%.

This depends on your resampler settings.

 

[James]

Thanks for the new release. So far so good in relation to the system freezes I was experiancing with the last build. I can't say for sure that issue is gone as I need to do more testing but so far no problems

The issue with the 'auto' media adaptation speed setting not understanding the refresh rate is at a multiple of 24 (audio passthrough mode only) still happens. This causes the yellow icon and reclock reporting it needs a refresh rate multiple of 24 even though it already has it. Manually changing the speed setting fixes the issue though.

What is "audio passthrough mode"?

 

[Razoola]

What is "audio passthrough mode"?

Sorry, I mean when reclock is set to accept bitstreams and then simply passes it through without resampling.

 

[coconut]

ReClock + Foobar + KS + W7 or Vista = How

Can someone tell me how to make reclock work with Foobar?

And how to make reclock work with Kernel Streaming?


Please.


Thank You

 

[James]

Sorry, I mean when reclock is set to accept bitstreams and then simply passes it through without resampling.

My guess is, that 48Hz is not close enough to 2*23.976 fps. Try to set the refresh rate around 47.95Hz.

 

[Razoola]

My guess is, that 48Hz is not close enough to 2*23.976 fps. Try to set the refresh rate around 47.95Hz.

Thats not it what I am getting at, I understand what you are saying and I agree, the issue I have is more expanded in the way reclock matches video to a 24hz refresh rate and not 23.976 when audio bitstreams are passed through.

Let me put it this way, if I disable bitstream passthrough and use resampling reclock will give a green icon with 23.976 media while using a 120hz refresh rate. What I am getting at is the fact reclock is not giving a green icon if I were to play the same media with passthrough enabled instead. It should be giving the green icon in both cases should'nt it even though reclock will be droping audio packets quite often keep bitstream in sync?

 

[James]

Thats not it what I am getting at, I understand what you are saying and I agree, the issue I have is more expanded in the way reclock matches video to a 24hz refresh rate and not 23.976 when audio bitstreams are passed through.

Let me put it this way, if I disable bitstream passthrough and use resampling reclock will give a green icon with 23.976 media while using a 120hz refresh rate. What I am getting at is the fact reclock is not giving a green icon if I were to play the same media with passthrough enabled instead. It should be giving the green icon in both cases should'nt it even though reclock will be droping audio packets quite often keep bitstream in sync?

With bitstream ReClock will enforce a tighter margin. With PCM you can specify a possible speed difference of up to 10% in video settings.

 

[Razoola]

With bitstream ReClock will enforce a tighter margin. With PCM you can specify a possible speed difference of up to 10% in video settings.

ok, I understand now. I did not think reclock treated each instance differently with regards refresh rate.

A suggestion going on from this then. Have you though about using a new colored icon instead (or new graphic in icon)? IE; Have reclock keep the margin the same for resampling and bitstreaming at 10%. Then have a new color icon to reflect when reclock is in that even tighter range. Use this new color both with bitstreaming and resampling.

 

[James]

ok, I understand now. I did not think reclock treated each instance differently with regards refresh rate.

A suggestion going on from this then. Have you though about using a new colored icon instead (or new graphic in icon)? IE; Have reclock keep the margin the same for resampling and bitstreaming at 10%. Then have a new color icon to reflect when reclock is in that even tighter range. Use this new color both with bitstreaming and resampling.

I fail to understand the benefit.

 

[Razoola]

I fail to understand the benefit.

In my situation of bitstream passthrough and 23.976 content displayed on a 24hz refresh rate multiple the yellow icon makes reclock not use its Vsync options (they are all greyed out). Clearly though reclock can sync the media with Vsyncon as using the same settings with audio resampling show.

I always understood the colored icons were in relation to if reclock can sync the video to the displays refresh rate without it looking stupid regardless of audio. In the situation I have audio plays a part in wether I get a green icon or not. This is why I suggest the new color as an option because there are two different margins as you describe to get reclock to go green

The other option would be to relax the margins when using bitstreaming to match the margins used when resampling, This would then take audio out of the equasion again to get reclock green. That said I can follow the logic of why you have the timings tighter for bitstreaming but I wonder if it is needed given that people should understand you will loose more packets the further out the refresh rate is.

 

[leeperry]

James, I was wondering...when is it advisable to clear Reclock's timings exactly? because I recently switched soundcards, tried zillion versions of Reclock, updated to the latest DX9 update...and Reclock was going quite nuts...

it now looks a lot better after clearing the timings! don't you think Reclock should warn the user once in a while about this? like if the audio drivers have a different name, the DirectX DLL versions have changed..or stuff like that?

and I've been suggesting you for a while that it'd be nice if Reclock did a short fade out/fade in when seeking...maybe you could try how cool it is in this audio player(it supports ASIO/WASAPI)? http://www.head-fi.org/forums/6421688-post138.html

it would be really nice in Reclock because:
-seeking right on a loud explosion wouldn't be so annoying anymore
-audio drivers behave differently when Reclock's resampler is catching up...some make hardly audible crackles, but most of them make loud glitches...crossfading would sound a lot more professional IMHO.

and you said that volume control in Reclock would come, would that be uneducated of me to ask about a rough ETA? maybe it'd be better to do it in 32/64fp after the resampler's output, so it'd even work when audio is not being resampled...

volume cannot be controlled whatsoever over PCM S/PDIF in KS/WASAPI, and I'd die to be able to set 2 hotkeys on my Griffin Powermate

it would also be useful for ppl whom S/PDIF receiver digital volume control works in 16bit only, or for lazy ppl who have their receiver at the other side of the room w/o a remote...they could simply assign 2 hotkeys on a RF computer remote

anyway, I've been suggesting you these 2 feature requests for a while, I think they'd be a great asset to Reclock...I dearly hope that you will consider them

in the mean time, I might just have to stick to KMixer to get volume control in Reclock

 

[James]

James, I was wondering...when is it advisable to clear Reclock's timings exactly? because I recently switched soundcards, tried zillion versions of Reclock, updated to the latest DX9 update...and Reclock was going quite nuts...

it now looks a lot better after clearing the timings! don't you think Reclock should warn the user once in a while about this? like if the audio drivers have a different name, the DirectX DLL versions have changed..or stuff like that?

and I've been suggesting you for a while that it'd be nice if Reclock did a short fade out/fade in when seeking...maybe you could try how cool it is in this audio player(it supports ASIO/WASAPI)? http://www.head-fi.org/forums/6421688-post138.html

it would be really nice in Reclock because:
-seeking right on a loud explosion wouldn't be so annoying anymore
-audio drivers behave differently when Reclock's resampler is catching up...some make hardly audible crackles, but most of them make loud glitches...crossfading would sound a lot more professional IMHO.

and you said that volume control in Reclock would come, would that be uneducated of me to ask about a rough ETA? maybe it'd be better to do it in 32/64fp after the resampler's output, so it'd even work when audio is not being resampled...

volume cannot be controlled whatsoever over PCM S/PDIF in KS/WASAPI, and I'd die to be able to set 2 hotkeys on my Griffin Powermate

it would also be useful for ppl whom S/PDIF receiver digital volume control works in 16bit only, or for lazy ppl who have their receiver at the other side of the room w/o a remote...they could simply assign 2 hotkeys on a RF computer remote

anyway, I've been suggesting you these 2 feature requests for a while, I think they'd be a great asset to Reclock...I dearly hope that you will consider them

in the mean time, I might just have to stick to KMixer to get volume control in Reclock

nag, nag, nag...
are the pops and crackles gone now?

 

[leeperry]

nag, nag, nag...
are the pops and crackles gone now?

hahaha, well..try the audio player I just mentioned? you'll see how cool it is to have a crossfade when you seek, it feels so pro! and this player also allows to set 2 hotkeys for volume attenuation, and applies it in 64fp over ASIO/WASAPI...it sounds AMAZING. Reclock would reach another new level of audio goodness if it were to support these 2 features

yes, I think they're gone...I'll watch another bunch of movies this evening just to be sure, I'll take one for the science

so do you think we should clear Reclock's timings for each new version? or changing audio drivers/updating DirectX would be valid reasons to do so?

PS: the english resource file for the audio player is available here(you need to copy it in \uLilith\Common\): http://forum.slysoft.com/attachment.php?attachmentid=11127&d=1267050083

 

[James]

so do you think we should clear Reclock's timings for each new version?

No, unless you update from a very old version.

or changing audio drivers/updating DirectX would be valid reasons to do so?

Audio drivers - no. DirectX version - probably. Graphic card drivers - yes, if you believe something is wrong (stuttering).

 

[Zardoz]

Tiny adjustment request...

Hi,

i noticed the following behavior of reclock with sp/dif passthrough. Lets say we got 11ms DTS packets and the screen refresh is very slightly off. Then naturally the audio offset increases (or decreases) gradually in one direction. Reclock then corrects that by dropping (or repeating) packets. But it does not do is very efficiently. It seems that reclock tries to get back to a 0ms offset. Lets say the threshold is 22ms, if the audio offset increases beyond this point reclock drops 2 packets and the same cycle starts again: increasing offset until 22ms is reached and then it drops two packets again.

I think it would be better if the "window" without correction is centered around 0ms... so a 22ms window would imply a threshold of +11ms.... and when that threshold is reached reclocks drops 2 packets and gets to -11ms.... audio would on average be much more in sync, without the loss of anything.

The only change would be to center the correction threshold window around 0ms and if the threshold is exceeded in either correction, the correction target is the other side of the window (instead of 0 as it is now)


Would that be a viable scheme?

regards