ReClock 1.8.5.5

[James]

Yes, but when earing 16bit sources, the difference is not significative...

The question is - can it ever be significant?
Anyway, I'll rewrite the whole conversion stuff. Don't know if it will be better or not.

 

[iSeries]

If I make the onboard sound the default playback device and the 4550 the secondary then I guess there's 'less' of a chance that Windows will resample if the input sample rate is the same as is set in the 'Default Format' of the Windows mixer, as there will definitely be no other sounds going through it.

If the input is 24bit 48khz, and I output 32bit float 192khz from Reclock, and Windows converts back to 24bit but doesn't resample - that should be 'good enough' shouldn't it? I mean, in what way would 24bit 48khz input>32bit padded 192khz output from Reclock via WASAPI be better should this method get implemented?

 

[James]

If I make the onboard sound the default playback device and the 4550 the secondary then I guess there's 'less' of a chance that Windows will resample if the input sample rate is the same as is set in the 'Default Format' of the Windows mixer, as there will definitely be no other sounds going through it.

If the input is 24bit 48khz, and I output 32bit float 192khz from Reclock, and Windows converts back to 24bit but doesn't resample - that should be 'good enough' shouldn't it? I mean, in what way would 24bit 48khz input>32bit padded 192khz output from Reclock via WASAPI be better should this method get implemented?

First, I'm not sure if changing the code would make any difference. These conversion routines make me crazy.

Anyway, it wouldn't use the Windows mixer and ReClock can change the HDMI channel setting. Very handy with ffdshow audio or PowerDVD, as the receiver will "know" how many channels are present and can automatically adjust the surround processing.

E.g. (assuming a 7.1 setup):

2 channels -> Receiver does Dolby PLIIx -> 7.1 channels
5.1 channels -> Receiver does Dolby PLIIx -> 7.1 channels
7.1 -> Receiver passes 1:1 -> 7.1 channels

This does not work (well) when not using Wasapi exclusive.

After fiddling with ReClock for a long time, I simply use something which sounds good and is convenient to use. Bit-exactness my a**.

As I use a lot of PAL DVDs (comes with the job, and PAL DVDs feature a higher resolution than NTSC DVDs, that's why it's called "PAL - Pay for Additional Luxury") I have to slow down playback speed by approx. 4% (PAL Speedup sucks big time) and use the resampler all the time. Everything is resampled and played back via 32bit PCM AT HDMI (Realtek drivers) and it does sound really, really good (for AC3 / DTS sound). So, I believe it can't be that bad the way it is at the moment. (Not to mention some audiophiles who pee their pants from excitement how wonderful ReClock sounds )

 

[leeperry]

James -the bluray protection slayer- watches DVD's at home?

I know PeterSt(the XXHighEnd coder) tried to register to help w/ the float conversions(I didn't ask him to), but he apparently didn't get any confirmation emails

well, it's clear than Reclock sounds better than foobar...it's also clear that PCM32 sounds brighter than PCM16/24 on my system, and apparently several ppl agree that Ogo's float conversion code could be improved, so why not? you know audio OCD is about improving the SQ on a permanent basis, just like "good enough" doesn't exist in madshi's dictionnary

each audio upgrade makes the previous one laughable, so maybe some conversion code everyone agrees upon would sound even better than it currently does :agree:

and I told WingFeather that the resampler needs all the values between -1 and +1 so the 2^15 might not work...here's his reply:

In terms of the "2^15 trick", I do still think it would be okay to use this multiplier, as you are clipping the signal after it is received from the resampler and scaled up. So there's no chance of a wrap-around occurring.

Then again, the exact multiplier only affects distortion down at the LSB level. Since you're using floating-point arithmetic for the resampling, a similar amount (at least) of distortion will already be introduced by that - and hardly increased by the one extra operation. Further, a single-precision float won't losslessly encode PCM32 to begin with, so if you're using that PCM32 as the input then it makes no difference anyway.

Whatever you do, DO use the same multiplier for positive and negative halves of the signal!

Wingfeather

 

[James]

well, it's clear than Reclock sounds better than foobar...it's also clear that PCM32 sounds brighter than PCM16/24 on my system, and apparently several ppl agree that Ogo's float conversion code could be improved, so why not?

Sure, I'll do it... still wondering about the -0.5

 

[James]

ok, I've tried XXHighEnd but the GUI is just unbearable and crashes constantly..I couldn't get it to output any sound at all, apparently I should wait for the next version

anyway, WingFeather has answered me:

This is particularly interesting:

My second comment depends on your point of view with regards to lossless conversion: If you want the ability to perform lossless PCM->float->PCM conversion, then when doing float->PCM you need to multiply by the same amount that you divided by in PCM->float (that is, 2^n). What you - and most people - are doing is multiplying only by (2^n)-1 instead. Of course, this stops the PCM output from overflowing in the case of a 1.0f-valued sample, but will NOT allow the conversion to be lossless.

 

[yesgrey3]

still wondering about the -0.5

The functions used to convert from double/float to integer are lrint()/lrintf(). These functions converts a FP value to its nearest integer value. ogo subtracted 0.5 because he preferred to truncate instead of rounding to the nearest integer.
Considering that clipping is performed after the conversion, IMO we should use rounding, dropping the - 0.5 from the conversions. It would be faster, too.
Here is the conversion.cpp with symmetric conversion for lossless, removing of the - 0.5, and the correction of float -> PCM24 as I have told you previously.
View attachment conversion_corr.zip

 

[leeperry]

correction of float -> PCM24

do want

 

[James]

The functions used to convert from double/float to integer are lrint()/lrintf(). These functions converts a FP value to its nearest integer value. ogo subtracted 0.5 because he preferred to truncate instead of rounding to the nearest integer.
Considering that clipping is performed after the conversion, IMO we should use rounding, dropping the - 0.5 from the conversions. It would be faster, too.
Here is the conversion.cpp with symmetric conversion for lossless, removing of the - 0.5, and the correction of float -> PCM24 as I have told you previously.
View attachment 10534

Thanks! Funny, I already changed Ogo's code in a similar way and have done some tests.

But I believe there is an error in your code here, the positive values for CLIP_SAMPLE are too big.

E.g. for FP -> 16bit

CLIP_SAMPLE(l_samp, -32768, 32768);

should be

CLIP_SAMPLE(l_samp, -32768, 32767);

As 32768 won't fit in signed 16 bit, it would in fact be -32768. This can't be right.

Same with the other FP->PCM conversions.

CLIP_SAMPLE(l_samp, -8388608, 8388608);

should be

CLIP_SAMPLE(l_samp, -8388608, 8388607);

and

CLIP_SAMPLE(l_double, -2147483648.0, 2147483648.0)

should be

CLIP_SAMPLE(l_double, -2147483648.0, 2147483647.0)

I used the smaller values in my tests. Or was this intentional and I (again) failed to understand something?

 

[James]

do want

Patience....

 

[James]

@yesgrey3:

... and the 8bit conversion must be wrong, too:

long l_samp = (long)128 + (long)(*isample++ * 128.0f);
CLIP_SAMPLE(l_samp, 0, 255);

As l_samp is signed, this will sound really bad, everything from -128 to -1 will be cut. Ogo's code already was wrong, good thing ReClock doesn't offer 8 bit output and usually won't receive it.

Or am I again not seeing the whole picture?


EDIT:
Forget what I wrote, I overlooked the +128 in the first line. :doh:
I should switch on my brain before typing...

 

[James]

The functions used to convert from double/float to integer are lrint()/lrintf(). These functions converts a FP value to its nearest integer value.

Yes, but depending on the "rounding mode" register in the FPU. I wonder if I need to set it. Please tell me that I don't....

ogo subtracted 0.5 because he preferred to truncate instead of rounding to the nearest integer.
Considering that clipping is performed after the conversion, IMO we should use rounding, dropping the - 0.5 from the conversions. It would be faster, too.

I completely agree with you on this one, and preliminary tests show that most conversions PCM->FP->PCM are now bit exact - they never were before.

 

[yesgrey3]

I used the smaller values in my tests. Or was this intentional and I (again) failed to understand something?

No, you understood it right. I have not verified what would be the higher positive values for the signed integers... sorry.

 

[yesgrey3]

I should switch on my brain before typing...

Don't worry, it also happened to me before...

Yes, but depending on the "rounding mode" register in the FPU. I wonder if I need to set it. Please tell me that I don't....

I don't know for sure, but I believe you don't have to. The x86 CPUs by default round to the nearest integer. The register should be set only when you want to truncate. C by default truncates, which makes the FP to integer conversions slower because the register must be always set before each conversion, and reset after it. The Intel compiler has an option for disabling this setting C conversion to the nearest, to speed up the conversion.
I think that was the reason why libsamplerate author created the lrint functions, to speed up the float->int conversions by avoiding changing the register, so if it was needed, he would have done it.

 

[James]

I don't know for sure, but I believe you don't have to. The x86 CPUs by default round to the nearest integer. The register should be set only when you want to truncate. C by default truncates, which makes the FP to integer conversions slower because the register must be always set before each conversion, and reset after it. The Intel compiler has an option for disabling this setting C conversion to the nearest, to speed up the conversion.
I think that was the reason why libsamplerate author created the lrint functions, to speed up the float->int conversions by avoiding changing the register, so if it was needed, he would have done it.

Yes, the default is rounding to the nearest integer, and the OS will preserve the FPU registers on task switch (or only save them per process? I don't know). However, ReClock (or the resampler) run in the context of some alien process (usually a player) which might or might not set the FPU registers as it pleases. Wouldn't be polite, but who knows?
Ogo already saves & restores the FPU registers while ReClock "does something", he wrote in a comment that some sick codec or player may require this as it expects the FPU registers to be unaltered. :doh:
Maybe I should clear the rounding mode bits right after Ogo saved the FPU registers. Just to be sure... (not that anyone would ever hear a difference, not even Leeperry )

 

[James]

I think that was the reason why libsamplerate author created the lrint functions, to speed up the float->int conversions by avoiding changing the register, so if it was needed, he would have done it.

I think he (and Ogo and everybody else) is doing this, because the MS compiler doesn't have the lrint functions (at least not up to VS2005). And that's the scary part, everyone is now messing around with the FPU directly.

 

[yesgrey3]

that's the scary part, everyone is now messing around with the FPU directly.

Yes, I understand you, because there are always someone that does not make it right...
This is the description of a ICL11 compiler option to speed up the float to integer conversion, by deactivating the C truncation mode.

Description
This option enables fast float-to-integer conversions. It can improve the performance of code that requires floating-point-to-integer conversions.

The system default floating-point rounding mode is round-to-nearest. However, the C language requires floating-point values to be truncated when a conversion to an integer is involved. To do this, the compiler must change the rounding mode to truncation before each floating-point-to-integer conversion and change it back afterwards.

This option disables the change to truncation of the rounding mode for all floating-point calculations, including floating point-to-integer conversions. This option can improve performance, but floating-point conversions to integer will not conform to C semantics.

As you can see, when they perform the C truncation mode, they do it right. They set the register for the truncation, perform the conversion, and then reset the register to its default value. The problem is that someone could be setting it and just leave it like that...
So, the removing of the "- 0.5" of the code is also better for that scenario, because in the worst case, when someone set the register for truncation in another application, the conversion would use truncation instead of rounding. The code like it is right now is worse, could be a kind of double truncation...
But I agree with you, at 24 bit PCM, this would not be noticeable by anyone, even by leeperry...

 

[leeperry]

well the resampler has been drastically improved since 1.7b4...now the float>PCM conversions will be too, what's next?

James, do you think that'd be possible to lower the pregap on audio files as previously discussed? now I would need to find someone willing to add gapless FLAC/APE in MPC(it already works for BD .m2ts )

thanks fellas!

 

[James]

well the resampler has been drastically improved since 1.7b4...now the float>PCM conversions will be too, what's next?

64 bit port?

James, do you think that'd be possible to lower the pregap on audio files as previously discussed?

Discussed? You said "I want it". I said nothing.

 

[leeperry]

64 bit port?

Discussed? You said "I want it". I said nothing.

64bit appears pointless for video playback, but yes I guess for the WMP ppl it could be good?

well, audio sounds great in Reclock...but waiting half a second each time you open an audio file gets odd

it's so much snappier when set to 25/50ms, but then video playback suffers.

or maybe a trick to have 2 versions installed simultaneously would be easier? but yes OK, I understand you don't really care as you don't play audio in Reclock...but atm there's only one gap setting for the preliminary DS handshake and the resampling adaptations...two separate settings would be awesome, but if it's too annoying to you let's just forget it indeed