ReClock 1.8.5.6

[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/SetupReClock1856.exe

1.8.5.6 - 07/01/2010
* Change: Removed "original speed x0.66"
* New: Improved IEEE float / PCM conversion, most conversions will be bit exact
* New: Added "original speed x0.96" which can be used to demonstrate the PAL speedup difference
* New: Added "24 bit PCM padded to 32 bit" to PCM output formats
* Fix: Possible memory access violation

 

[leeperry]

thanks! I think PCM24 does indeed sound more detailed, but I'll A/B several times the two versions before calling it a day...and also check whether PCM32 is still brighter(padded or not)

PS: heh, they all sound different again...I think I prefer PCM32 this time

PPS: indeed "Lou Reed - Walk On The Wild Side.flac" sounds so much better in PCM32/192kHz than in 24/24 padded...Lou's voice sounds as true to life as can be, the left intro guitar is so much clearer and the soundstage is really impressive and natural sounding, only one explanation possible: you guys are mugicians

oh yes, vocals sound amazing in 32/192...the diff is as big as if I had rolled op-amps, the soundstage separation is eye popping...same as XXHighEnd as far as my memory can tell, a much wider and far better seperated/airier stereo image :clap:

 

[yesgrey3]

James, thanks for the update!

Just a small question: have you also included the PCM24->PCM32 (padded) without converting to float, when resampling is bypassed? It's not clear enough from the changes list...

 

[James]

James, thanks for the update!

Just a small question: have you also included the PCM24->PCM32 (padded) without converting to float, when resampling is bypassed? It's not clear enough from the changes list...

No. Do you think it is still necessary? PCM24->FP32->PCM24 should be bit exact. Or not?

 

[leeperry]

I don't really know what you two guys changed to PCM32, but please leave it exactly as is

 

[James]

I don't really know what you two guys changed to PCM32, but please leave it exactly as is

Pretty much nothing, TBH. I don't think you can hear a difference.

 

[leeperry]

Pretty much nothing, TBH. I don't think you can hear a difference.

well, I'm quite sure you did something...I've never heard such a clear and separated stereo image on this soundcard(and I've rolled a hell lot of op-amps)

BTW, I currently decode lossy audio as 32fp and feed it as is to Reclock...but I also use ffdshow to convert 16/24 44.1/48/96/192 lossless audio to 32fp, should I let Reclock do the 32fp conversion for lossless? or could the resampler possibly be fed w/ 2^15 as WingFeather said? could we try it w/ 2^15 both ways possibly?

 

[James]

BTW, I currently decode lossy audio as 32fp and feed it as is to Reclock...but I also use ffdshow to convert 16/24 44.1/48/96/192 lossless audio to 32fp, should I let Reclock do the 32fp conversion for lossless? or could the resampler possibly be fed w/ 2^15 as WingFeather said? could we try it w/ 2^15 both ways possibly?

Maybe yesgrey3 can translate this for me.

 

[leeperry]

Pretty much nothing, TBH. I don't think you can hear a difference.

WingFeather said "whatever you do, DO use the same multiplier for positive and negative halves of the signal!"...what was the case before? it sounds like drastically improved stereo phase matching to me, it literally takes off the headphones of my head...my brain is completely fooled into thinking it's live sound surrounding me.

some op-amps also do that, but it makes so much more sense to do it in the digital domain first hand.

 

[James]

WingFeather said "whatever you do, DO use the same multiplier for positive and negative halves of the signal!"...what was the case before?

This was the case before. Same multiplier for positive and negative halves.

 

[ice25]

Hmm yet another sound improvement and a new output mode.. 8) I think writing a guide about what the different new options mean and when to use them, is starting to become quite necessary though..

 

[yesgrey3]

No. Do you think it is still necessary? PCM24->FP32->PCM24 should be bit exact. Or not?

I've run some tests and confirmed. With the new conversion routine PCM24->FP32->PCM24 is lossless. In fact, you could even simplify the conversion a little and it will still remain lossless, and will be slightly faster (no need to use doubles as intermediate step):

					case 24:
						// IEEE Float --> PCM24
						{
							SWITCHBUFF
							float* isample = (float*)l_inputBuff;
							unsigned char* osample = (unsigned char*)l_outputBuff;
							for(int i=l_sizeIn/4; i>0; i--)
							{
								long l_samp = lrintf(*isample++ * 8388608.0f);
								CLIP_SAMPLE(l_samp, -0x800000, 0x7FFFFF);
								osample[0] = (unsigned char)(l_samp);
								osample[1] = (unsigned char)(l_samp >> 8);
								osample[2] = (unsigned char)(l_samp >> 16);
								osample += 3;
							}
							l_sizeOut = (l_sizeIn*3)/4;
						}
						break;

So, it only remains one reason for performing PCM24->PCM24 without the conversion to float: to be slightly faster.
IMO it's not worth it complicating the code for such a tiny improvement.
Once again, thank you for showing the conversions code. That helped us to discover that it was not lossless, but now it is!
Mission acomplished.:clap:

well, I'm quite sure you did something...I've never heard such a clear and separated stereo image on this soundcard(and I've rolled a hell lot of op-amps)

Pretty much nothing, TBH. I don't think you can hear a difference.

Previously, all negative samples were exact and all positive samples were off by 1/2147483648. Now, they are all exact.
They were off by such a tinny value that I have to agree with James, I don't think you can hear the difference... Placebo, maybe?

BTW, I currently decode lossy audio as 32fp and feed it as is to Reclock...but I also use ffdshow to convert 16/24 44.1/48/96/192 lossless audio to 32fp, should I let Reclock do the 32fp conversion for lossless?

As I posted above, now reclock is lossless for 24PCM->Float->PCM24, so, use what's more convenient to you, the final result should be the same.

could we try it w/ 2^15 both ways possibly?

James, what leeperry wants is reclock to use values in the range [-8388608.0, 8388608.0] instead of [-1.0, 1.0]. I already told him that it's not possible, because it would need changes in libsamplerate's code. Also, with the new conversions, we already achieve lossless even when using the range [-1.0, 1.0], so we already have all that he needs.

 

[yesgrey3]

WingFeather said "whatever you do, DO use the same multiplier for positive and negative halves of the signal!".

This was the case before. Same multiplier for positive and negative halves.

I think what he said was to use the same multiplier for the PCM->float and for the float->PCM conversions. Before they were not used, now they are.

 

[leeperry]

Previously, all negative samples were exact and all positive samples were off by 1/2147483648. Now, they are all exact.
They were off by such a tinny value that I have to agree with James, I don't think you can hear the difference.

well jitter measures in picoseconds..yet it's VERY audible, there is a clear difference to me now in PCM32, the stereo phase coherence is just so much more spot-on..and the sound isn't brighter anymore.

James, what leeperry wants is reclock to use values in the range [-8388608.0, 8388608.0] instead of [-1.0, 1.0]. I already told him that it's not possible, because it would need changes in libsamplerate's code. Also, with the new conversions, we already achieve lossless even when using the range [-1.0, 1.0], so we already have all that he needs.

WingFeather said it'd still work, in his opinion the Resampler truly doesn't need all the value between -1 and +1

so feeding lossless audio as is or converted to 32fp in ffdshow doesn't matter at all? Reclock would do the same exact kind of 16/24int>32fp conversion to feed the resampler as ffdshow?

 

[James]

I think what he said was to use the same multiplier for the PCM->float and for the float->PCM conversions. Before they were not used, now they are.

Yes, he said this and he is right, but his comment "whatever you do, DO use the same multiplier for positive and negative halves of the signal!" was about some other person's conversion routine, if I understood correctly.
As a signed int can hold 1 digit less positive values than negatives, it is tempting to use different multipliers for positive and negative numbers to "correct this". ReClock never did that. And I agree with WingFeather, this *is* probably not a bright idea.

ReClock treated the positive and negative halves of the signal the same way. The only thing which was really potentially "wrong" was PCM24 output because it simply used the 3 most significant bytes of a PCM32 conversion (although it would be interesting to mathematically check how wrong it really was), which leeperry liked the most with 1.8.5.5

 

[James]

Hmm yet another sound improvement and a new output mode.. 8) I think writing a guide about what the different new options mean and when to use them, is starting to become quite necessary though..

Select whatever sounds good to you and is most convenience to use.
And make sure to playback PAL DVDs with 24fps.

 

[leeperry]

which leeperry liked the most with 1.8.5.5

well, the more you improve Reclock's code...the better it sounds, I sincerely apologize for that o/

and yes, PCM32/192kHz never sounded this good...even w/ fresh ears, more small details are clearly audible(the left intro guitar in "walk on the wild side" for instance) and the soundstage positioning is far more accurate and airy...checked both w/ music and 5.1 movies(I use my own 5.1>stereo binaural downmix matrix, and it relies on phase inversion) :agree:

 

[James]

I've run some tests and confirmed. With the new conversion routine PCM24->FP32->PCM24 is lossless. In fact, you could even simplify the conversion a little and it will still remain lossless, and will be slightly faster (no need to use doubles as intermediate step):

You're right, a float should suffice. I've changed it.

So, it only remains one reason for performing PCM24->PCM24 without the conversion to float: to be slightly faster.
IMO it's not worth it complicating the code for such a tiny improvement.

I agree.

Once again, thank you for showing the conversions code. That helped us to discover that it was not lossless, but now it is!
Mission acomplished.:clap:

You're welcome.

Previously, all negative samples were exact and all positive samples were off by 1/2147483648. Now, they are all exact.

Now I'm lost again. Why would different multipliers shift the symmetry of positive / negative samples? Both halves were slightly off by a tiny value (which nobody could hear, @leeperry: PCM24 was off the same way), but not only the positive or negative half.

 

[leeperry]

@leeperry: PCM24 was off the same way

I'm not saying it was or was not, I just compared 192kHz oversampling in 24/24 padded/32 w/ Reclock b56, and PCM32 sounds amazing. I'm sold!

currently listening to "Stevie Wonder - Superstition.flac"(yes, I like old *ss music ) and I've never heard its soundstage so wide and clear, it used to be VERY mushy in foobar and still a bit mushy in Reclock b55/PCM24...now it's just VERY clear, love it! it's annoying how the software you use for audio playback seems to be even more important than the hardware, as it can be a very nasty bottleneck...lesson learned :bang:

PS: my ref. track for vocal texture is "Bebel Gilberto - O Caminho.flac"(Neumann U87 all the way!) and I've got a hard time believing that the difference I'm hearing is only software-based, hah.

even the bell at the very beginning of "Nick Cave - Red Right Hand.flac" clearly never lasted so long(15 damn seconds)! it seems to bring up small details effortlessly

 

[yesgrey3]

Now I'm lost again. Why would different multipliers shift the symmetry of positive / negative samples? Both halves were slightly off by a tiny value (which nobody could hear, @leeperry: PCM24 was off the same way), but not only the positive or negative half.

The rounding was: lrint(isample*multiplier - 0.5)
The negative half has the minus sign favoring it...
Let's look at an example using the value +/-500 (it will be the same for all other negative and positive values):

isample = -500/(2^15) = -0.015258789
isample * (2^15-1) = -499.98474 
lrint(isample*multiplier - 0.5) = lrint(-499.98474 - 0.5) =  lrint(-500.48474) = -500

isample = 500/(2^15) = 0.015258789
isample * (2^15-1) = 499.98474 
lrint(isample*multiplier - 0.5) = lrint(499.98474 - 0.5) =  lrint(499.48474) = 499

Now with the correct multiplier and without "- 0.5":

isample = -500/(2^15) = -0.015258789
isample * (2^15) = -500.000 
lrint(isample*multiplier = lrint(-500.000) = -500

isample = 500/(2^15) = 0.015258789
isample * (2^15) = 500.000 
lrint(isample*multiplier - 0.5) = lrint(500.000) = 500

Sometimes we need to do the math to understand it...

I'm not saying it was or was not, I just compared 192kHz oversampling in 24/24 padded/32 w/ Reclock b56, and PCM32 sounds amazing. I'm sold!

Have you tryed re-install 1.8.5.5 and hear only the 32bit PCM output?