ReClock 1.8.5.6

[leeperry]

I am considering to get rid of the "24 bit PCM padded to 32 bit" output selection. Instead I want to always use the "24 bit PCM padded to 32 bit" method if the user selects 32bit PCM as output.

ahhhh...PCM32 sounds great, each to his own...ppl can experiment w/ how 32bit is processed in their drivers, PCM32 sounds much better than PCM24 padded to 32 on my VIA drivers

there's some EWDM drivers from ESI that are compatible w/ my soundcard(provided a firmware upgrade), I'll try to hear if they sound any different from the generic VIA drivers.

and if you could PLEASE leave the code untouched, and simply multiply the resampler output by 0.99~ to avoid clipping...PCM32 sounds amazing as it is, that'd be most welcome to leave it as is

When playing back video the prebuffer is filled half so ReClock can compensate both ways. Pure audio playback can fill up the whole buffer. So it is safe to assume that with a working 250ms buffer setting for video, 125ms for audio will work, too.

When ReClock enters "pure audio" mode, it will simply use half of the specified buffer. I'm really too lazy to add a separate setting for audio only.

Satisfied?

well, I'd love to have 50ms for audio and maybe 500 or 750ms for video...but you're the boss! I tried 250ms but madVR and KMP didn't like it, 500ms is perfectly stable for me in 48Hz.

I thought there was just one single "prebuffer" variable for the preliminary DS connection and the actual resampling adaptation...you could call them #1 and #2 and we'd have the best of both worlds, but it's your code and your software. any improvement is always fantastic, thanks for your hard work!

 

[yesgrey3]

well, I'd love to have 50ms for audio and maybe 500 or 750ms for video...

When ReClock enters "pure audio" mode, it will simply use half of the specified buffer. I'm really too lazy to add a separate setting for audio only.

Does it really has to be half? Why not use 1/10th in "pure audio" mode?

 

[James]

PCM32 sounds amazing as it is, that'd be most welcome to leave it as is

Is this the padded or the normal version?

 

[noee]

ReClockHelper.DLL keeps crashing

I get this failure when starting a movie (MKV) using FFDshow for decoding (audio and video). I just hit close, and the movie begins playing as normal. I've attached a log...not sure what to make of this, only thing I've changed is FFDshow....

 

[James]

Does it really has to be half? Why not use 1/10th in "pure audio" mode?

I believe that would be too small. Maybe 1/4.

 

[James]

I get this failure when starting a movie (MKV) using FFDshow for decoding (audio and video). I just hit close, and the movie begins playing as normal. I've attached a log...not sure what to make of this, only thing I've changed is FFDshow....

I would report this to the ffdshow people. It could also be a problem of the MKV parser / splitter. In the meantime, disable "determine frame rate of media files using DShow".

 

[leeperry]

Is this the padded or the normal version?

PCM32, not padded...please leave it as is

why not leaving all these options? better have too many than not enough! maybe some other cards would sound better w/ 24 padded to 32.

I believe that would be too small. Maybe 1/4.

maybe you could let us specify it? w/ a figure between 0 and 1...possibly from the registry

 

[James]

PCM32, not padded...please leave it as is

why not leaving all these options? better have too many than not enough! maybe some other cards would sound better w/ 24 padded to 32.

Nah. Don't think so. This is all theoretical blah. 32bit PCM non padded it is.
EDIT: If you convert integer something (16, 24) to 32 bit integer, the result will be exactly the same regardless if the conversion is done with 32 bit or 24 bit padded to 32.
@yesgrey3: Right?

maybe you could let us specify it? w/ a figure between 0 and 1...possibly from the registry

That's the way it'll gonna be:

There will be a new registry value "AudioOnlyPrebuffTime". It can't be changed using Config.exe. The default will be 100ms which should be ok for all interfaces. You can change it with RegEdit if you feel the need.

Beware: The prebuffer will be at least as large as the sample duration, usually below 50ms, as it must hold at least one sample. But I have seen players which have much bigger durations!
EDIT2: ReClock makes sure the buffer is big enough, you shouldn't need to care. But if sample duration is 1000ms, ReClock will allocate a pre buffer for this size. Duration is shown in ReClock filter properties.

 

[yesgrey3]

why not leaving all these options? better have too many than not enough! maybe some other cards would sound better w/ 24 padded to 32.

Beacause it would be more confusing for the user and no benefit.
I've tryed both padded and normal 32 bit PCM and both sounded the same to me.
I also vote for keeping the normal 32 bit PCM and drop the 24 bit padded to PCM.

 

[James]

ReClockHelper.DLL keeps crashing:

I get this failure when starting a movie (MKV) using FFDshow for decoding (audio and video). I just hit close, and the movie begins playing as normal. I've attached a log...not sure what to make of this, only thing I've changed is FFDshow....

Do you have any information why ReClockHelper.DLL crashed? Access violation? Division by zero? Is the crash within ReClockHelper.DLL or some other dll?

 

[James]

Resampler plugin cpp & h

@yesgrey3 (or anyone who cares):

Slightly changed interface for ReClock >= 1.8.5.7

 

[noee]

Do you have any information why ReClockHelper.DLL crashed? Access violation? Division by zero? Is the crash within ReClockHelper.DLL or some other dll?

It's definitely related to the new FFshow versions from Albain.....I went back to 3171 and it works fine (no problem with ReClockHelper.DLL).

I'll go back to one of the newer ones and repro. I think it is related to the DXVA code he is adding (which I am not using). I'll see if I can get some more info and post in both forums....

 

[James]

It's definitely related to the new FFshow versions from Albain.....I went back to 3171 and it works fine (no problem with ReClockHelper.DLL).

I'll go back to one of the newer ones and repro. I think it is related to the DXVA code he is adding (which I am not using). I'll see if I can get some more info and post in both forums....

Thanks!

To help Albain, here is what ReClockHelper.dll basically does:

double doIt( LPSTR lpCmdLine )
{
	double l_detectedFrameRate = -2.0; // no stream found
	CComPtr<IMediaDet> l_mediaDet;
	
	if (SUCCEEDED (l_mediaDet.CoCreateInstance(__uuidof(MediaDet))))
	{
		WCHAR l_fileNameWide[1024+1];
		if( MultiByteToWideChar(isNt() ? CP_UTF8:CP_ACP, 0, lpCmdLine, -1, l_fileNameWide, 1024) )
		{
		if (SUCCEEDED (l_mediaDet->put_Filename(l_fileNameWide)))
		{
			long l_streamCount = 0;
			
			if (SUCCEEDED (l_mediaDet->get_OutputStreams(&l_streamCount)))
			{
				for (int i=0; i<l_streamCount; i++) 
				{
					if (SUCCEEDED (l_mediaDet->put_CurrentStream(i)))
					{
						GUID l_guid;
						
						if (SUCCEEDED (l_mediaDet->get_StreamType (&l_guid)))
						{
							if (l_guid == MEDIATYPE_Video)
							{
								HRESULT hr = l_mediaDet->get_FrameRate(&l_detectedFrameRate);
								
								if (SUCCEEDED (hr))
								{
									if (l_detectedFrameRate <= 0.5)
										l_detectedFrameRate = -1.0; // stream found, but no framerate found
									
									break;
								}
								else
									l_detectedFrameRate = -1.0; // stream found, but no framerate found
							}
						}
					}
				}
			}
		}
		}
	}
	return l_detectedFrameRate;
}

I can put the call to doIt() inside a __try / __except handler, but this will only hide the problem and no frame rate will be detected.

 

[leeperry]

That's the way it'll gonna be:

There will be a new registry value "AudioOnlyPrebuffTime". It can't be changed using Config.exe. The default will be 100ms which should be ok for all interfaces. You can change it with RegEdit if you feel the need.

ok, awesome! so you guys leave PCM32 as it is currently implemented..remove the dynamic anti-clipping scheme and add a coeff(0.99~) that will slightly lower the resampler output volume depending on the output bitdepth?

and with this new registry option, I can leave Reclock for videos to 500ms in the GUI, and put 50/75ms in the registry for audio files? sounds like a plan

Beware: The prebuffer will be at least as large as the sample duration, usually below 50ms, as it must hold at least one sample. But I have seen players which have much bigger durations!
EDIT2: ReClock makes sure the buffer is big enough, you shouldn't need to care. But if sample duration is 1000ms, ReClock will allocate a pre buffer for this size. Duration is shown in ReClock filter properties.

your second edit lost me, but 50 appeared to be too small for audio files...IIRC 75 was perfect!

 

[yesgrey3]

@yesgrey3 (or anyone who cares):

Slightly changed interface for ReClock >= 1.8.5.7

James, don't release the new version until I upload the resampler plugin code. It's not correct. I'm currently working on it...

 

[James]

ok, awesome! so you guys leave PCM32 as it is currently implemented..

ack.

remove the dynamic anti-clipping scheme and add a coeff(0.99~) that will slightly lower the resampler output volume depending on the output bitdepth?

no. The dynamic anti-clipping is adjusted to the output bitdepth. I don't believe this is a problem in the "real world".

and with this new registry option, I can leave Reclock for videos to 500ms in the GUI, and put 50/75ms in the registry for audio files? sounds like a plan

ack.

your second edit lost me, but 50 appeared to be too small for audio files...IIRC 75 was perfect!

Default is 100ms *if* the sample duration is <=100ms. If it is bigger, the prebuffer will be, too, regardless what you have specified in the registry.

 

[James]

James, don't release the new version until I upload the resampler plugin code. It's not correct. I'm currently working on it...

Oh dear. Maybe I should look for another job.

 

[yesgrey3]

Oh dear. Maybe I should look for another job.

No you don't. We need you there.
Who will have all your patience to support our constant whining?

Here is the code:
View attachment ResamplerPlugin_y3.zip
It was a very small bug. You forgot to ad the peak_limit to the normalization process, so the normalization would be to 1.0, what we don't want...
I also updated the libsamplerate version number in the comments.

 

[leeperry]

no. The dynamic anti-clipping is adjusted to the output bitdepth. I don't believe this is a problem in the "real world".

ok, but it'll be fixed...not dynamic? because IIRC it used to lower the resampler output volume *ONLY* if clipping would occur...it's prolly better to just go 0.99~ right off the bat and disable any dynamic attenuation IMHO.

Default is 100ms *if* the sample duration is <=100ms. If it is bigger, the prebuffer will be, too, regardless what you have specified in the registry.

how could the sample duration be more than >50/70ms? I'm mostly feeding stereo 32float/44.1 or 96 from ffdshow.

Hmmm, maybe we are getting there. Can you compare both but without any resampling? and post the results?

ok, just did! on the left intro guitar of "Lou Reed - Walk On The Wild Side.flac", the same difference exists! it's far mushier in b55 than in b56(in 32bit/no resampling), and far more audible/musical sounding/articulated in b56..PRaT(Pace Rhythm and Timing, the toe tapability factor of the music) is way higher

b55 sounds like a nasty mp3, w/o or w/o resampling..I just A/B'ed several times to make sure.

and when I go 32/192 in b56, then the jazz brush seems more defined...like it's got its own location in the soundstage, it's not a mushy part of the complete mix anymore, it's got its very own location around 11 o'clock and it doesn't just make 1 single sound...I can hear far more nuances, it's really living between 10'30 and 11'30..it's got a soundstage of its own.

the right guitar also sounds more audible and clearer, and especially Lou's voice sounds more natural and much "thicker"...I'm not listening to a mere FLAC anymore, I've got Lou singing right in front of me. When I go back to 44.1kHz, it sounds less "defined"/"focused" and more like a crappy mp3 from a soundblaster...emotionless and PRaT is way lower, my brain isn't fooled that it's hearing a live session anymore. Also the final sax sounds 3D'ish in 192kHz.

I think that's what really kills in Reclock at 32/192, it gives a very true-to-life realistic sound(especially vocals, OMG!) the upsampling makes sure to magnify all the small details that were hardly audible and fatiguing to focus on at 44.1/48, it makes them flow and allows them to take far more room within the soundstage. I also tried 176.4kHz(that my card supports w/o resampling, but I don't like how it sounds...I put my money on 192 :agree

It also allows to extract more details from lossy audio(especially when decoded in 32float)..as the cMP says: http://photos.imageevent.com/cics/v... art of building Computer Transports v0.3.pdf



I keep repeating myself, but I was so sure that all the players would sound EXACTLY the same in KS/ASIO and that upsampling was just a way to degrade THD and SQ...theoritical certitudes are meant to be killed by real field experiences!

No you don't. We need you there.
Who will have all your patience to support our constant whining?

yeah, but we're gonna need new whiners I'm afraid! I think my everlast whining has come to an end, we need fresh blood ^^

 

[James]

No you don't. We need you there.
Who will have all your patience to support our constant whining?

Here is the code:
View attachment 10564
It was a very small bug. You forgot to ad the peak_limit to the normalization process, so the normalization would be to 1.0, what we don't want...
I also updated the libsamplerate version number in the comments.

Thank you! New ReClock coming up any minute...