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

James

Redfox Development Team
Staff member
Thread Starter
Joined
Oct 22, 2005
Messages
21,801
Likes
3,787
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/SetupReClock1867.exe

Note:
* ReClock must be installed *after* PowerDVD or Arcsoft TMT 3
* Whenever PowerDVD or Arcsoft TMT 3 is updated or reinstalled, ReClock must be reinstalled
* ReClock replaces the ASAudioRenderer.dll in the TMT 3.0 Codec directory. A backup ASAudioRenderer_bak.dll will be created. Do not delete this file, it is required!

1.8.6.7 - 24/03/2010
* New: Installation of DSound / Wave support (replacing default renderers) can be disabled during setup
* New: Installation of TMT3 support can be disabled during setup
* New: Installation of PowerDVD support can be disabled during setup
* New: Save settings when leaving filter graph.
* Change: Send QUIT notification when leaving filter graph.
* Some fixes and improvements

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

I have an issue with this new version. My secondary monitor cannot be detected correctly:
Refresh Rate is 0.000 Hz (DDR)

During the installation I've unchecked the installation of TMT3 and the installation of PowerDVD.
After I've cleaned the timing database.

It worked well is the previous version.

Here's the log in case it can explain the cause of this problem.

Thanks
 

Attachments

  • reclock_log.zip
    10.6 KB · Views: 3
16.82s 000c0c ERROR CalcHardwareInfos() failure, cannot get consistent values

Just try again until it works.
 
thanks for the new beta James, b66 was working amazingly well for me anyway :agree:

BTW, I'm really sorry to ask again...but do you think volume attenuation would still be possible? :eek:

you could improve the UI later, but for the time being 3 registry keys would be more than enough..2 for +/- volume and one to choose the steps accuracy(between 0.01% and 100%)...and later, you could show the current attenuation in the VSYNC OSD possibly? or maybe add one more key, so ppl could decide to reset it to 100% each time a new file is opened?

I tried one of these, but the stereo imbalance was *unbearable*..making me feel half deaf: Shure PA235 - Headphone attenuator

basically, it would be useful to all the ppl who use crappy analog pots that have major stereo tracking issues at low volume...and god knows that there's a lot these around :/

I remember some other users said they'd welcome this new feature, but the main Reclock thread is too damn big..it's hard to dig into it. I hope that you would seriously consider it, as I currently have to resort to KMixer damnbloodyseagull.gif

humm, even the Burson headphones amps have stereo tracking problem...I really think that volume attenuation should STAY in the digital domain whenever possible: http://www.head-fi.org/forums/6514669-post155.html
The only quibble I have is the volume control. Now, I understand the desire to get away from a traditional, noisy control. [..] When I changed the volume down, it noticeably shifted to the left. Another notch and it moved back slightly to the right

and this guy too, because it takes a lot of cash to get a proper pot: http://www.head-fi.org/forums/6507232-post9.html
bad pot at low volume [..] I only go like 20degrees from minimal where it still has a little of imbalance

sadly, not everyone can afford an ALPS RK50 pot: ALPS Potentiometer RK50 pot - eBay

you can count on me to beta-test it, and hype this new feature to death on head-fi...TIA for your consideration otakonleboss.gif
 
Last edited:
James, thanks for your hard work and i appeciate to your efforts.

But i have to report my issues here:

With MPC-HC, when i not select ReClock i take HD bitstream and blue light on my AVR with ffdshow.


But when i accept ReCock (1.8.6.7), i see ac3 decoder (low merit) and dts decoder (low merit) in filters instead of ffdshow and i get decoded pcm in place of bitstream and no blue light on my AVR.

I see under "renderer infos": WASAPI Exlusive" instead of "WASAPI Exl. Bit Exact"

HW:

Clarkdale onboard HDMI to AVR , AVR to TV, (sound and video)
Clarkdale onbord HDMI to AVR (as audio), nVidia to TV (as video)

on 7/64 with MPC-HC 32.


_ _ _
 
Last edited:
OHHH, sorry guys.

There must be a mistake in my side. I reload 1.8.6.6 and living the same issues which i never met before.
 
Hi James,

I have an issue with this new version. My first monitor cannot be detected correctly:
Refresh Rate is not the real Hz (DDR)

I use reclock with MediaPortal 1.1.0 RC1

For let reclock work good I must select manually media adaptation refresh becouse not corresponds.

thanks, Giovanni.
 
Things are working great with my Clarkdale setup. At the moment, Clarkdale does not provide for a real 23.976 hz frame rate so many people have an issue with the extra frame that gets added periodically.

I have TMT3 outputting decoded PCM and everything looks and sounds great and it is completely seamless.

Thanks!
 
Things are working great with my Clarkdale setup. At the moment, Clarkdale does not provide for a real 23.976 hz frame rate so many people have an issue with the extra frame that gets added periodically.
Another reason *not* to use bitstreaming. ;)

I have TMT3 outputting decoded PCM and everything looks and sounds great and it is completely seamless.

Thanks!
You're welcome.
 
Stop nagging. It'll come. ;)
I'm sorry, I didn't mean to nag you! great news nevertheless :D

and thanks for all, the more I upgrade my audio gear, the more I'm stunned by Reclock's SQ...it's a bit too clear for music sometimes, but for movies dialogs clarity it's spot-on 8)
 
Last edited:
Another reason *not* to use bitstreaming. ;)

People forget that their so-called "unmolested" bitstreamed audio has already been resampled when the telecine process changes a 24 fps film to 23.976 fps.

I am not saying that what reclock does reverses any damage done but, in truth, it sounds great to me.

Bitstreaming was very important when we didn't know how players were handling PCM output or what Windows was doing to it. Now? Not so much.
 
People forget that their so-called "unmolested" bitstreamed audio has already been resampled when the telecine process changes a 24 fps film to 23.976 fps.
Very good point.
 
Very good point.

Come on, be objective here:
1) Just because it has been resampled from 24.000 to 23.976023976... does not make resampling it AGAIN to an arbitrary frequency any good
2) Some titles are authored at an exact 24.000 so no resampling here. The same is true for almost all TV material at 59.940(i)
3) I trust the DACs in my amplifier much more than those of a cheap $7 onboard soundchip or even a $250 soundcard
4) Many of current receivers post processing features/bass management is only available if a bitstream is passed.
5) Its nice to just have one wire/optical running from the computer to the receiver
6) occasional dropping of an audio packet is much more inaudible than screwing with the playback frequency

Bottom line: There are many valid points for using bitstreaming.
 
2) Some titles are authored at an exact 24.000 so no resampling here.
Do you know some examples?
3) I trust the DACs in my amplifier much more than those of a cheap $7 onboard soundchip or even a $250 soundcard
Me, too. I use multi channel PCM via HDMI.

4) Many of current receivers post processing features/bass management is only available if a bitstream is passed.
With analogue ports, yes (only really good models offer this), but with HDMI? Maybe I'm lucky with my Denons and Onkyos, but I would be surprised if (m)any modern AVRs have this problem via HDMI.

5) Its nice to just have one wire/optical running from the computer to the receiver
Now I'm lost. I have only one HDMI wire for picture & sound.

6) occasional dropping of an audio packet is much more inaudible than screwing with the playback frequency
I disagree. And you never watched a PAL disc. :D

Bottom line: There are many valid points for using bitstreaming.
Maybe. :rolleyes:
 
3) I trust the DACs in my amplifier much more than those of a cheap $7 onboard soundchip or even a $250 soundcard
5) Its nice to just have one wire/optical running from the computer to the receiver
Now I'm lost. I have only one HDMI wire for picture & sound.
People keep forgetting that PCM is also a bitstream format.
I think it would be a good idea, for clarity reasons, to remove the designation of "bitstream formats" when referring to AC3, DTS, or any other compressed audio formats.
How about this changes to the config dialog:
Code:
Group name: Compressed formats pass-through 
1st option name: Accept (not recommended)
2nd option name: Disable media speed correction (recommended)
With the shorter names, you can also put the 1st and 2nd options side by side, as they should be...

I know this could also be a problem, because the idea of associating bitstream with AC3 and DTS bitstreams is spread all over, but you could always try...;)

Bottom line: There are many valid points for using bitstreaming.
Bottom line: PCM OUTPUT IS A BITSTREAM OUTPUT. You only get an analog output from it if you use your soundcard to perform the conversion for you instead of wiring it to your receiver...;)
 
Come on, be objective here:
1) Just because it has been resampled from 24.000 to 23.976023976... does not make resampling it AGAIN to an arbitrary frequency any good
2) Some titles are authored at an exact 24.000 so no resampling here. The same is true for almost all TV material at 59.940(i)
3) I trust the DACs in my amplifier much more than those of a cheap $7 onboard soundchip or even a $250 soundcard
4) Many of current receivers post processing features/bass management is only available if a bitstream is passed.
5) Its nice to just have one wire/optical running from the computer to the receiver
6) occasional dropping of an audio packet is much more inaudible than screwing with the playback frequency

Bottom line: There are many valid points for using bitstreaming.

I have absolutely nothing against bitstreaming the undecoded formats. It is a pick your poison situation for many people. For me, the .1% change from 23.976 to 24 is not something that I can hear. I wonder who could notice this kind of change? I have been playing clips from material that I am very familiar with and if they sound is any different, I can't tell. I assume that someone would be able to tell. Then, it would probably just sound a little bit different, not better or worse. Just a guess.
 
People keep forgetting that PCM is also a bitstream format.
I think it would be a good idea, for clarity reasons, to remove the designation of "bitstream formats" when referring to AC3, DTS, or any other compressed audio formats.
How about this changes to the config dialog:
Code:
Group name: Compressed formats pass-through 
1st option name: Accept (not recommended)
2nd option name: Disable media speed correction (recommended)
"compressed format passthrough" is not a bad term. Personally I would go with "Dolby/DTS passthrough" for its clarity. I agree "bitstreaming" is confusing.

I think the term "bitstreaming" has been corrupted through misuse. There are at least 3 reason why people use what they call "bitstreaming", maybe 4.

  1. they don't want to use the PCs DACs
  2. they don't want the PC to resample, as Reclock normally does and as players normally do with 96Khz or 24-bit sources over PCM (the latter not currently true of TMT3 when using a 5xxx card via Reclock)
  3. they trust their receivers decoding over their PCs. Although the decoding should be identical, at the very least for the lossless formats, there is some question whether the metadata eg. for DTS-ES is respected by PC players
  4. (possible lack of AVR post-processing with PCM on some, unspecified, AVRs)?
"Bitstreaming", whatever its technical origins is used by many to mean the pure, unadulterated passing of the audio data from the disc to the AVR with no possibility of manipulation or error in conversion, avoiding all the above issues. Unfortunately using PCM, especially if resampled by Reclock does not.

1) is certainly avoided by using PCM over HDMI. 4) is not a problem for many/most/(all?) AVRs. 2) and 3) are legitimate reasons for concern, even if the problems are now far reduced by Reclock's much improved resampling algorithms, PC performance improvements that allow for "best" methods to normally be used and the ability to avoid player resampling, in some circumstances, by using PAP or by (currently) using TMT3 with a 5xxx card and Reclock.

It is possible to have a PCM track on disc, even on Blu-ray, I think the last PoC was an example, and wish to "bitstream" that, i.e. avoiding Reclock resampling. Consequently I'm not sure we currently have the right way of determining Reclock's behaviour.

So how about we return to a tick box to
Allow Dolby/DTS passthrough
and have another multiple tick box
Disable media speed correction for All (not recommended) / Dolby/DTS (recommended)
 
Last edited:
Personally I would go with "Dolby/DTS passthrough" for its clarity.
That's not a good naming for licensing reasons...

2) and 3) are legitimate reasons for concern, even if the problems are now far reduced by Reclock's much improved resampling algorithms
You can always avoid 2) by using the slave reference clock to audio trick...

So how about we return to a tick box to and have another multiple tick box
After thinking a little more about this, how about this way...

Putting the "Bitstream" group before the "PCM Output" group with the following options:
Code:
--"Bitstream passthrough"----------------------
| [ ] PCM            [ ] Correct media speed  | 
| [ ] Other Formats  [ ] Correct media speed  | 
-----------------------------------------------
Recommended usage mode would be "PCM" unchecked, activating the PCM Output group. If anyone wants to passthrough the PCM bitstream untouched to their receivers, it would be enough checking "PCM". As a consequence, the entire PCM output group would be disabled, including all its options.

The problem I can see with this idea, is that reclock's recommended working mode would be a little more complicated to set, but maybe it would be more clear and help to avoid the current bitstream confusion...

Note: I'm only trying to help improving reclock's user-friendliness. I don't use any of these features, only the 2 reg keys James created by my request...;)
 
Last edited:
Back
Top