• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

ReClock 1.8.6.2

James

James

Redfox Development Team
Staff member
Thread Starter
Joined
Oct 22, 2005
Messages
21,801
Likes
3,787
James, still no intensions for Reclock in 64-bit? I use MPC-HC and ffdshow x64 and they run smooth as hell so would love a fully 64-bit software setup.
 
To continue our tests for Atom Ion 330 /dual core + 2virtual/ as appeared in detail p#19 in that 1.8.6.0 thread:

for 1.8.6.2:
-----------
- much improved resampler optimization /or just decreased max. allowed sampling rate to avoid choking smaller cpus?
- windows task manager graphs clearly showing less violent activity/spikes at cpu cores in comparison to previous ver. of resampler
- 128-192 mp3 streams are now running smoothly in the top "Best Sinc" setting 88kHz and 176kHz at only ~30%, respectivelly ~60% cpu
- as per SQ will judge that one later as currently only tested in temporary setup w. different headphones to previous session

I'm looking forward to some direct comparison with compiled SRC into b62, but for me the default lib seems good enough now..
 
Last edited:
There is still a bit of a problem with dropouts. Attached is a log file. I've tried WAVE and DS and different quality resampling yet I get a timeout on a single chapter point on this DVD, Every time I get a timeout at exactly the same point and an audible break in the sound. I guess you could say it is bad authoring, but there is no audible problem at all if Reclock is disabled. Any ideas?
 

Attachments

  • SpyLog.zip
    22.5 KB · Views: 1
I also have problems still with system freezes and reboots with this new version. Happens both in zoomplayer 7 using ffdshow and MPC-HC with internal decoders. I've moved back to 1860 which so far has not crashed once.

Also had a strange situation with 1862 before it crashed with reclock displaying a message 20 minutes into a film saying the audio decoder did not support 32bit PCM even though it had been working fine for the first 20 minutes.
 
Jong said:
There is still a bit of a problem with dropouts. Attached is a log file. I've tried WAVE and DS and different quality resampling yet I get a timeout on a single chapter point on this DVD, Every time I get a timeout at exactly the same point and an audible break in the sound. I guess you could say it is bad authoring, but there is no audible problem at all if Reclock is disabled. Any ideas?
Click to expand...
If I change MPC-HC to use AC3Filter instead of its internal decoders I get several more fixed points on this disc where I get timeouts. It is clearly something in the authoring that triggers this; I have other discs that show no timeouts whatsoever. But they are all completely inaudible if Reclock is disabled.

I've no idea if this was introduced in a recent build or if it always would have happened with this disc. I haven't had the disc for long and anyway have not been running these kind of tests for about a year now since our earlier problems of a similar vein. But it does remind me of what I said then. It seems like the pre-buffer is not really "buffering". If we have 1/2 second of audio buffered in theory and if any authoring anomaly is inaudible without Reclock (so presumably very brief) surely the Reclock pre-buffer should be able to deal with it? :confused:
 
Jong said:
It seems like the pre-buffer is not really "buffering"
Click to expand...
it definitely is IME...like when switching from one of my graphic card's output to the other, or firing a DVD drive while streaming audio from my HDD...if I set the audio prebuffer at 100ms, audio will blank out...at 500ms, no problem at all(I will search for the hard limit at some point, prolly around 300ms or so)

I only tried w/ audio, I could try w/ video...I've seen what you're mentioning w/ some buggy versions of mkvmerge, I could even make a sample if you like...if the container hiccups, Reclock doesn't like it.
 
Last edited:
Yeah. i'm not claiming it doesn't store the amount of audio specified, just that it doesn't seemto work in fully protecting Reclock from any minor delays.

The disc I am talking about is a real DVD. I am sure there can be small hiccups @vob/chapter/layer boundaries but Reclock should be able to cope, surely, when there is no audio or video glitch without it.

I tried dramatically increasing buffer and latency and it did not help at all.
 
remux it? VOB works terribly bad in KMP w/ Reclock...I gave up on it ages ago, it keeps glitching up every few mins to catch up.
 
Not an acceptable solution for me. Real DVDs just need to work. Note: I am playing using DVD Navigator, not just linking vobs, which can mean trouble.

Most discs are absolutely fine. This disc works "almost fine" (one glitch) if you pick the right AC3 decoder. Not worth remuxing all my DVDs or even this one. But my point is I think it must be symptomatic of some flaw in the buffering logic as an inaudible transition between chapters without Reclock cannot, surely, legitimately lead to a timeout and rebuffering? Or be so filter dependent, when all these decoders otherwise "work". :confused:
 
change splitters maybe? more often than not, they can wreck havoc(look at HMS and its infamous jitter on 23.976 MKV).

a timestamps gap doesn't matter in DS, some video frames will be dropped(hoping noone would notice :D), but Reclock is forced to make an audible glitch to catch up.

maybe a log of that section would shed some lights? together w/ a remux(only for test purposes ;))

I also would like to see VOB working perfectly fine in Reclock, but I don't think it's the culprit...garbage in > garbage out :eek:
 
With "full DVD" you have no choice of "splitter", if using DS at least. Eveyone has to use "DVD Navigator". But my point is I would epxect a 500ms buffer to be sufficient to hide any minor timestamp glitches/slight delays in audio arrival that are small enough to be inaudible i.e much shorter than 500ms, especially for a format that is so "standard" as" DVD". But let's see what James thinks.
 
Jong said:
With "full DVD" you have no choice of "splitter", if using DS at least. Eveyone has to use "DVD Navigator".
Click to expand...
there's many different "DVD Navigators" available, you can select them in KMP..maybe some would work better than others:

05679065575674.gif

maybe you could also see some timestamps "gaps" in the Reclock logs..but you're right, I never open full discs coz the damn menus never work.
 
..if you have those commerical pieces of software and mostly they do not actually work outside of their application (true of Cyberlink at aleast) and then, as you say, things like menus and subtitles often do not work.

FYI, in MPC-HC menus/subtitles work with EVR and the internal or Cyberlink decoders provided you do not use DXVA. Not with madVR though you are right. maybe that is what you are using?

Just to remind you and James i did include a log here: http://forum.slysoft.com/showpost.php?p=243217&postcount=6 with several efforts at viewing the same chapter point. As far as I can see there is nothing odd in the log except a sudden timeout and rebuffer.

I have now discovered that this point does not timeout if I use ffdshow audio decoder for AC3 with liba52 decoder. More evidence for the decoder sensitivity of Reclock. I'm currently playing the whole DVD to see if all plays "clean" or if there are other problem points for this decoder. :bang: But I'm sure none of this should be needed.
 
Jong said:
I'm currently playing the whole DVD to see if all plays "clean"
Click to expand...
I hope for you that it's not Transformers 2 or some other utterly retarded movie ^^

yes, liba52 in ffdshow is great..my favorite decoder for AC3 :agree:

DVD menus have never worked for me, whatever in HR or mVR...I've given up on DVD/VOB.
 
WASAPI gives a tiny bit of extra info when it fails:

Code: 
   10.20s 0010b0         video minInt=8 wait=279.1 Ti=-18.969 e=-0.000 U=-1.897 freq=2640002.27(-123.73, 69.07 ppm)
   10.48s 0010b0         video minInt=8 wait=280.0 Ti=-18.969 e=-0.000 U=-1.897 freq=2640006.37(-119.63, 67.06 ppm)
   10.59s 001708         wave audio sync=-38 wait=3008 Y=1064224 Ud=1152000 size=73728 Ti=87776 e=87776 U=9655 freq=96134(+140)
   10.76s 0004bc         video minInt=8 wait=282.1 Ti=-15.424 e=3.545 U=-0.125 freq=2640014.62(-111.38, 65.10 ppm)
   11.09s 0010b0         video minInt=8 wait=318.9 Ti=-12.288 e=3.136 U=0.025 freq=2640023.22(-102.78, 63.21 ppm)
   11.31s 001794 WARNING WasapiThread buffer underrun! Stop!
   11.33s 0013a4         BeginFlush()
   11.33s 0013a4         StopAndClearAudioBuffer
   11.33s 001794         WasapiThread stopped
   11.33s 0013a4         InitPid() rates=(1.000000,1.000000) resampler=(1.000000,1.000000) stretch=(1.000000) psc=0
   11.33s 0013a4         ChangeAudioRate(96000.00,0.0,48000)
   11.33s 0013a4         EndFlush()
   11.33s 001708         Prebuff sample dropped t1=8239 l_shift=494 l_sampleDuration=32 m_timeDrop=500
   11.36s 001708         End of sample predrop
   11.36s 001708         1 buffer(s) waiting for playback (1094592 bytes left)
   11.39s 001708         2 buffer(s) waiting for playback (1020864 bytes left)
   11.39s 001708         video minInt=8 wait=299.9 Ti=-12.288 e=-0.000 U=-1.229 freq=2640035.87(-90.13, 61.37 ppm)
   11.42s 001708         3 buffer(s) waiting for playback (947136 bytes left)
   11.45s 001708         4 buffer(s) waiting for playback (873408 bytes left)
   11.48s 001708         5 buffer(s) waiting for playback (799680 bytes left)
   11.51s 001708         6 buffer(s) waiting for playback (725952 bytes left)
   11.54s 001708         7 buffer(s) waiting for playback (652224 bytes left)
   11.57s 001708         8 buffer(s) waiting for playback (578496 bytes left)
   11.61s 001708         9 buffer(s) waiting for playback (504768 bytes left)
   11.64s 001708         10 buffer(s) waiting for playback (431040 bytes left)
   11.67s 001708         11 buffer(s) waiting for playback (357312 bytes left)
   11.70s 000da8         video minInt=8 wait=316.1 Ti=-9.125 e=3.164 U=0.353 freq=2640040.12(-85.88, 59.58 ppm)
   11.70s 001708         12 buffer(s) waiting for playback (283584 bytes left)
   11.73s 001708         13 buffer(s) waiting for playback (209856 bytes left)
   11.78s 001708         14 buffer(s) waiting for playback (136128 bytes left)
   11.81s 001708         15 buffer(s) waiting for playback (62400 bytes left)
   11.84s 001708         16 buffer(s) waiting for playback (-11328 bytes left)
   11.87s 001708         Flushing 16 buffers waiting for playback
   11.87s 001794         WasapiThread started, sleep time 0
   11.87s 001794         WASAPI exclusive Play!
   12.03s 000da8         video minInt=8 wait=320.0 Ti=-6.000 e=3.125 U=0.650 freq=2640050.28(-75.72, 57.84 ppm)
   12.36s 0010b0         video minInt=8 wait=339.0 Ti=-8.949 e=-2.950 U=-2.075 freq=2640048.20(-77.80, 56.16 ppm)
   12.70s 001708         video minInt=8 wait=336.4 Ti=-8.949 e=-0.000 U=-0.895 freq=2640059.57(-66.43, 54.52 ppm)
   13.04s 000a88         video minInt=8 wait=346.5 Ti=-11.835 e=-2.886 U=-2.338 freq=2640056.67(-69.33, 52.94 ppm)
   13.40s 001708         video minInt=8 wait=357.5 Ti=-6.241 e=5.594 U=1.614 freq=2640067.90(-58.10, 76.32 ppm)
   13.79s 000da8         video minInt=8 wait=379.7 Ti=-6.241 e=-0.000 U=-0.624 freq=2640068.65(-57.35, 62.36 ppm)
   14.16s 0010b0         video minInt=8 wait=381.0 Ti=-6.241 e=-0.000 U=-0.624 freq=2640078.85(-47.15, 54.67 ppm)
   14.37s 001708         wave audio sync=-37 wait=3008 Y=1065745 Ud=1152000 size=73728 Ti=86255 e=86255 U=9488 freq=96131(+135)

What is strange is increasing the buffer does not seem to help. For a while I thought increasing it a lot did help. @800ms it worked quite a few times in a row, but then it dropped again. then I reduced it to 500ms and it worked a few times as well, then dropped. The problem is not 100% solid so I don't think it can be timecode errors, but increasing the buffer or latency or reducing resample quality to the lowest, or reducing the sample rate or bit depth, none of these, seem to reliably fix the issue.

ps. The ATI HDMI driver (10.1) does disconnect WASAPI when MPC-HC closes 8). The downside is, unlike ReakTek, it drops the audio to the AVR completely during any silence and the AVR has to "resync" when the audio returns. Normally not much of an issue, but it makes the audio drops I'm talking about here longer and even more distracting. :(
 
Last edited:
Jong said:
WASAPI gives a tiny bit of extra info when it fails:

Code: 
   10.20s 0010b0         video minInt=8 wait=279.1 Ti=-18.969 e=-0.000 U=-1.897 freq=2640002.27(-123.73, 69.07 ppm)
   10.48s 0010b0         video minInt=8 wait=280.0 Ti=-18.969 e=-0.000 U=-1.897 freq=2640006.37(-119.63, 67.06 ppm)
   10.59s 001708         wave audio sync=-38 wait=3008 Y=1064224 Ud=1152000 size=73728 Ti=87776 e=87776 U=9655 freq=96134(+140)
   10.76s 0004bc         video minInt=8 wait=282.1 Ti=-15.424 e=3.545 U=-0.125 freq=2640014.62(-111.38, 65.10 ppm)
   11.09s 0010b0         video minInt=8 wait=318.9 Ti=-12.288 e=3.136 U=0.025 freq=2640023.22(-102.78, 63.21 ppm)
   11.31s 001794 WARNING WasapiThread buffer underrun! Stop!
   11.33s 0013a4         BeginFlush()
   11.33s 0013a4         StopAndClearAudioBuffer
   11.33s 001794         WasapiThread stopped
   11.33s 0013a4         InitPid() rates=(1.000000,1.000000) resampler=(1.000000,1.000000) stretch=(1.000000) psc=0
   11.33s 0013a4         ChangeAudioRate(96000.00,0.0,48000)
   11.33s 0013a4         EndFlush()
   11.33s 001708         Prebuff sample dropped t1=8239 l_shift=494 l_sampleDuration=32 m_timeDrop=500
   11.36s 001708         End of sample predrop
   11.36s 001708         1 buffer(s) waiting for playback (1094592 bytes left)
   11.39s 001708         2 buffer(s) waiting for playback (1020864 bytes left)
   11.39s 001708         video minInt=8 wait=299.9 Ti=-12.288 e=-0.000 U=-1.229 freq=2640035.87(-90.13, 61.37 ppm)
   11.42s 001708         3 buffer(s) waiting for playback (947136 bytes left)
   11.45s 001708         4 buffer(s) waiting for playback (873408 bytes left)
   11.48s 001708         5 buffer(s) waiting for playback (799680 bytes left)
   11.51s 001708         6 buffer(s) waiting for playback (725952 bytes left)
   11.54s 001708         7 buffer(s) waiting for playback (652224 bytes left)
   11.57s 001708         8 buffer(s) waiting for playback (578496 bytes left)
   11.61s 001708         9 buffer(s) waiting for playback (504768 bytes left)
   11.64s 001708         10 buffer(s) waiting for playback (431040 bytes left)
   11.67s 001708         11 buffer(s) waiting for playback (357312 bytes left)
   11.70s 000da8         video minInt=8 wait=316.1 Ti=-9.125 e=3.164 U=0.353 freq=2640040.12(-85.88, 59.58 ppm)
   11.70s 001708         12 buffer(s) waiting for playback (283584 bytes left)
   11.73s 001708         13 buffer(s) waiting for playback (209856 bytes left)
   11.78s 001708         14 buffer(s) waiting for playback (136128 bytes left)
   11.81s 001708         15 buffer(s) waiting for playback (62400 bytes left)
   11.84s 001708         16 buffer(s) waiting for playback (-11328 bytes left)
   11.87s 001708         Flushing 16 buffers waiting for playback
   11.87s 001794         WasapiThread started, sleep time 0
   11.87s 001794         WASAPI exclusive Play!
   12.03s 000da8         video minInt=8 wait=320.0 Ti=-6.000 e=3.125 U=0.650 freq=2640050.28(-75.72, 57.84 ppm)
   12.36s 0010b0         video minInt=8 wait=339.0 Ti=-8.949 e=-2.950 U=-2.075 freq=2640048.20(-77.80, 56.16 ppm)
   12.70s 001708         video minInt=8 wait=336.4 Ti=-8.949 e=-0.000 U=-0.895 freq=2640059.57(-66.43, 54.52 ppm)
   13.04s 000a88         video minInt=8 wait=346.5 Ti=-11.835 e=-2.886 U=-2.338 freq=2640056.67(-69.33, 52.94 ppm)
   13.40s 001708         video minInt=8 wait=357.5 Ti=-6.241 e=5.594 U=1.614 freq=2640067.90(-58.10, 76.32 ppm)
   13.79s 000da8         video minInt=8 wait=379.7 Ti=-6.241 e=-0.000 U=-0.624 freq=2640068.65(-57.35, 62.36 ppm)
   14.16s 0010b0         video minInt=8 wait=381.0 Ti=-6.241 e=-0.000 U=-0.624 freq=2640078.85(-47.15, 54.67 ppm)
   14.37s 001708         wave audio sync=-37 wait=3008 Y=1065745 Ud=1152000 size=73728 Ti=86255 e=86255 U=9488 freq=96131(+135)

What is strange is increasing the buffer does not seem to help. For a while I thought increasing it a lot did help. @800ms it worked quite a few times in a row, but then it dropped again. then I reduced it to 500ms and it worked a few times as well, then dropped. The problem is not 100% solid so I don't think it can be timecode errors, but increasing the buffer or latency or reducing resample quality to the lowest, or reducing the sample rate or bit depth, none of these, seem to reliably fix the issue.

ps. The ATI HDMI driver (10.1) does disconnect WASAPI when MPC-HC closes 8). The downside is, unlike ReakTek, it drops the audio to the AVR completely during any silence and the AVR has to "resync" when the audio returns. Normally not much of an issue, but it makes the audio drops I'm talking about here longer and even more distracting. :(
Click to expand...
What disc(s) are giving you that problem? I know of some discs (e.g. "Code 46", German) which simply have gaps in the audio stream. The audio stream will stop, Wasapi buffer will empty, as you see with the Wasapi buffer underrun warning. This is an authoring error, and not ReClock's fault.
 
You must log in or register to reply here.
Back
Top