ReClock 1.8.5.6

[yesgrey3]

well jitter measures in picoseconds..

Yes, but the difference was on the signal amplitude, which does not affect jitter. Jitter occurs when the samples are not played at the exact time they should be played, not when you play them with the wrong amplitude.

 

[leeperry]

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

I just did A/B both several times, the difference is definitely not in my head, hahaha b55 sounds terrible in 32/192 compared to b56...b56 sounds just so much cleaner and clearer, major sound upgrade IMO..you guys rock!

so on lossless audio, is there any difference whether I feed it as integer or let ffdshow do the 32fp conversion? Reclock will have to do it to feed the resampler anyway?

now that the float>int conversion has been polished, how about improving the int>float to feed the resampler?

Yes, but the difference was on the signal amplitude, which does not affect jitter. Jitter occurs when the samples are not played at the exact time they should be played, not when you play them with the wrong amplitude.

just compared b55/b56 again, b55 sounds like a crappy xing mp3 in comparison...so the diff would be harmonic distortion in the trebles I believe.

 

[yesgrey3]

should I let Reclock do the 32fp conversion for lossless?

Yes, you should. I've took a look into ffdshow's code and it's using the 2^31-1 multiplier for 32bit PCM instead of 2^31. 16bit PCM conversion is correct, though. I don't know about 24bit PCM, but probably it's derived from the 32bit PCM, so it would be slightly wrong too.
I will switch to reclock only.

could the resampler possibly be fed w/ 2^15 as WingFeather said?

Yes, I've tryed it. If we send [-8388608.0, 8388607] to the resampler he accepts it and work just fine.

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

As I said previously, it's useless, the result would be exactly the same as we are getting now with the new conversion routines.

 

[yesgrey3]

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)

I've checked. It was... (drums rolling) 0% wrong.
In other words, it was correct. Doing it the previous way or the new is exactly the same.
Sorry

 

[yesgrey3]

I just did A/B both several times, the difference is definitely not in my head, hahaha b55 sounds terrible in 32/192 compared to b56...b56 sounds just so much cleaner and clearer, major sound upgrade IMO..you guys rock!

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

 

[leeperry]

Yes, you should. I've took a look into ffdshow's code and it's using the 2^31-1 multiplier for 32bit PCM instead of 2^31. 16bit PCM conversion is correct, though. I don't know about 24bit PCM, but probably it's derived from the 32bit PCM, so it would be slightly wrong too.
I will switch to reclock only.

Yes, I've tried it. If we send [-8388608.0, 8388607] to the resampler he accepts it and work just fine.

As I said previously, it's useless, the result would be exactly the same as we are getting now with the new conversion routines.

ah, bummer! coz I can decode MP3 as 32float w/ MPC's mp3 decoder, but I need ffdshow to downmix 5.1 to binaural stereo..maybe you could possibly commit a fix please? albain or the other active ffdshow coders would prolly be happy to add it to the SVN trunk :agree:

you lost me here, first you say that we can feed the resampler w/ 2^15 instead of -1/+1, then you say that it won't change anything anyway? is that in Resampler.dll or in Reclock itself for the 2^15 input?

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

I just did, but my ears are tired..it's 10:30PM here. I'll try again tomorrow

 

[yesgrey3]

*** WARNING ***
Pickyness below...

James,
With the new conversion mode, there is the possibility of ocurring clipping "if" the value 1.0 is achieved, because as we already realized, the positive half has one less step than the negative half, and we are using as multiplier the value of the negative half. So, when the float 1.0 appears it will be clipped to the value right bellow.
This is not a big issue, because the clipping would be so small that it would be hardly noticeable, and only when resampling, because that's the only way we could get values of 1.0.
That being said, I realized that we could solve this problem in a very easy way...

Remember the normalizing idea we have discussed some time ago, that when any overflow occured during resampling we would lower the volume accordingly to avoid any clipping? Yes, that's the way.
Currently, reclock looks for any values greater than 1.0, and then multiplies by (1.0/peak_value) all samples to guarantee 1.0 as the maximum value.
With the new conversions, if we consider the maximum allowed value to be (2^15-1)/(2^15) = 0.9999694, then multiplying all samples by (0.9999694/peak_value) will guarantee that overflow never occurs. This should be pretty simple for you to add, because the code is already inside reclock, is just changing the maximum allowed value.
If you want to be really picky, you could set the maximum value accordingly with the output format, because for a 24 bit PCM the maximum value would be (2^23-1)/(2^23) = 0.9999998.

Remember, this is just an idea based on code already inside reclock. It's your call to decide if it's worth it to change anything, I'm only pointing a solution.

 

[yesgrey3]

ah, bummer! coz I can decode MP3 as 32float w/ MPC's mp3 decoder, but I need ffdshow to downmix 5.1 to binaural stereo..maybe you could possibly commit a fix please?

It's not worth it.
ffdshow performs all processing with 32 bit FP. The maximum bit depth that exists in 32bit float is 24 bit, so there is no need to change anything in reclock, because the results would be exactly the same. Also, there are only 24bit soundcards on the market, so there is also no point in changing ffdshow's processing chain for higher bit depths, and, to be honest, even if existed more than 24bit soundcards, that would be pretty useless...
So, relax, and enjoy ffdshow and/or reclock. Use what you prefer, you will get exactly the same results. Trust me.

 

[leeperry]

So, relax, and enjoy ffdshow and/or reclock. Use what you prefer, you will get exactly the same results. Trust me.

humm? you just said that it'd be better to use Reclock for int>float conversion, and now you say that it's perfectly identical

the changes you guys did on the float>PCM32 conversion were pretty drastic SQ-wise, but maybe it's because the two polarities were not using the same coeff? so basically what ffdshow does would only kill the bitdepth resolution, but not give a mushy sound like Reclock used to in b55?

still no go at doing 2^15 in Resampler.dll for int>float either?

 

[yesgrey3]

humm? you just said that it'd be better to use Reclock for int>float conversion, and now you say that it's perfectly identical

I took another look at ffdshow's code and realized my latest findings.
To be exact: If you had a soundcard with 32bit dacs, I would say to use reclock. You haven't, so, use what gives you better usability.

so basically what ffdshow does would only kill the bitdepth resolution, but not give a mushy sound like Reclock used to in b55?

Yes.

 

[leeperry]

I took another look at ffdshow's code and realized my latest findings.
To be exact: If you had a soundcard with 32bit dacs, I would say to use reclock. You haven't, so, use what gives you better usability.

Yes.

okidokie, so they use the same coeff for the two polarities..that's cool!

anyway WingFeather told me that 2^15 could be overkill as we'll be resampling the damn thing anyway...he just emphasized that we should use the same coeffs for the two polarities, which we do now

removing any dynamic anti-clipping scheme, and simply amplifying the resampler output by 0.99 sounds like a plan indeed!

Reclock sounds amazing in 32/192 through the AD797B op-amp anyway, you guys should try it some time...it's great when no software/hardware component works as a nasty bottleneck :agree:

I'll try again tomorrow to identify b55/b56 w/o resampling, but it's a bit more complicated...as the resampler doesn't "fill" the bits, it'd take fresh ears I think

 

[James]

*** WARNING ***
Pickyness below...

James,
With the new conversion mode, there is the possibility of ocurring clipping "if" the value 1.0 is achieved, because as we already realized, the positive half has one less step than the negative half, and we are using as multiplier the value of the negative half. So, when the float 1.0 appears it will be clipped to the value right bellow.
This is not a big issue, because the clipping would be so small that it would be hardly noticeable, and only when resampling, because that's the only way we could get values of 1.0.
That being said, I realized that we could solve this problem in a very easy way...

Remember the normalizing idea we have discussed some time ago, that when any overflow occured during resampling we would lower the volume accordingly to avoid any clipping? Yes, that's the way.
Currently, reclock looks for any values greater than 1.0, and then multiplies by (1.0/peak_value) all samples to guarantee 1.0 as the maximum value.
With the new conversions, if we consider the maximum allowed value to be (2^15-1)/(2^15) = 0.9999694, then multiplying all samples by (0.9999694/peak_value) will guarantee that overflow never occurs. This should be pretty simple for you to add, because the code is already inside reclock, is just changing the maximum allowed value.
If you want to be really picky, you could set the maximum value accordingly with the output format, because for a 24 bit PCM the maximum value would be (2^23-1)/(2^23) = 0.9999998.

Remember, this is just an idea based on code already inside reclock. It's your call to decide if it's worth it to change anything, I'm only pointing a solution.

Good idea. I like simple changes.

 

[James]

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

Alright, but the problem is the subtraction of -0.5, not the multiplication of (2^15)-1 instead of (2^15).

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

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

BTW, multiplying with (2^15-1) would secure, that a 1.0 float won't be clipped, the result would be exactly 32767 instead of 32768.
-1.0 would result in -32767. But the result won't be lossless.

Another question - is it really possible (likely?), that the resampler produces sample values of 1.0?

1.0 can never come from PCM integer input, as (2^15-1) is the maximum positive value. Why would the resampler amplify a sample < 1.0 to 1.0?
(I'm ignoring IEEE float input for the moment)

I know we have this code in the resampler:

// by yesgrey3 - start
// if samples > 1.0, normalize using the peak value to avoid clipping
   for(int o = 0; o < *outSamples; ++o)
   {
      if (outBuffer[o] > GETPRIVATEDATA->max_peak)
	  {
		  GETPRIVATEDATA->max_peak = outBuffer[o];
	  }
   }
   if (GETPRIVATEDATA->max_peak > 1.0f)
   {
      for(int o = 0; o < *outSamples; ++o)
	  {
         outBuffer[o] = outBuffer[o]/GETPRIVATEDATA->max_peak;
	  }
   }
// by yesgrey3 - end

but how / when can it happen that max_peak can be greater than 0,999969482421875 (16bit PCM input), not to mention 1.0?

 

[yesgrey3]

Alright, but the problem is the subtraction of -0.5, not the multiplication of (2^15)-1 instead of (2^15).

Right. The multiplication of (2^15) is needed for the process to be lossless.

BTW, multiplying with (2^15-1) would secure, that a 1.0 float won't be clipped, the result would be exactly 32767 instead of 32768.
-1.0 would result in -32767. But the result won't be lossless.

Yes, but still could exist problems with values higher than 1.0...

Another question - is it really possible (likely?), that the resampler produces sample values of 1.0?

Possible, yes. Likely, maybe not. It would depend on the audio data.

1.0 can never come from PCM integer input, as (2^15-1) is the maximum positive value. Why would the resampler amplify a sample < 1.0 to 1.0?
...
but how / when can it happen that max_peak can be greater than 0,999969482421875 (16bit PCM input), not to mention 1.0?

Here is the answer of libsamplerate's author to that question (part of his faq):

Q1 : Is it normal for the output of libsamplerate to be louder than its input?

The output of libsamplerate will be roughly the same volume as the input. However, even if the input is strictly in the range (-1.0, 1.0), it is still possible for the output to contain peak values outside this range.

Consider four consecutive samples of [0.5 0.999 0.999 0.5]. If we are up sampling by a factor of two we need to insert samples between each of the existing samples. Its pretty obvious then, that the sample between the two 0.999 values should and will be bigger than 0.999.

This means that anyone using libsamplerate should normalize its output before doing things like saving the audio to a 16 bit WAV file.

 

[James]

Here is the answer of libsamplerate's author to that question (part of his faq):

Understood, thanks!

EDIT:
So, I'll use a float variable instead the fixed 1.0f and set it according to the requested output format.

 

[James]

Can I get rid of "24 bit PCM padded to 32 bit"

@yesgrey3

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.

The reasoning behind this:

1.) If user inputs 32bit int and outputs 32bit int nothing will happen. Converting 32bit int to 24bit int via FP doesn't make much sense.
2.) If user inputs 32bit and resamples precision will be lost because of the FP conversion anyway.
3.) If user converts anything else to 32bit PCM, conversion is done via FP, so a higher precision than 24bit doesn't make any sense.

What do you think?

 

[James]

@leeperry

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?

 

[James]

@yesgrey3:

I'll change the "bit exact" display to be more relaxed.

I'm doing the following assumptions:

1.) Any use of sound manipulation (resampler, compressor, muting, time stretch, ac3 encoder) is not bit exact. Obviously.

2.) Any conversion from 32bit int -> FP is considered not bit exact.

3.) If the input format is FP, any conversion to <24 bit int is not bit exact.

4.) If the input format is PCM, any conversion from input bit > output bit is not bit exact.

Ok?

 

[yesgrey3]

So, I'll use a float variable instead the fixed 1.0f and set it according to the requested output format.

Agreed.

@yesgrey3
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.

I have performed some tests with my soundcard and a little software tool created by RME, Digicheck, to try to understand how the driver communication works... I think I did.
Yes, I think you should remove it, but, instead of always perform the "24 bit PCM padded to 32 bit", you should leave it as it is, converting the float to 32 bit PCM, that's the best option.
I realized that the drivers communication use a very basic method. They simply use the MSb they need and ignore the rest. So, if I feed 32 bit PCM to a 16bit soundcard, it will use only the 16 MSb. If I feed 32 bit PCM to a 24 bit soundcard, it will use only the 24 MSb and ignore the 8 LSb.

1.) If user inputs 32bit int and outputs 32bit int nothing will happen. Converting 32bit int to 24bit int via FP doesn't make much sense.

Agreed. 32 bit PCM -> 32 bit PCM should be direct (when resampling is disabled), but if you keep it as it is now, it would not be an issue. Read below.

2.) If user inputs 32bit and resamples precision will be lost because of the FP conversion anyway.

Right.

3.) If user converts anything else to 32bit PCM, conversion is done via FP, so a higher precision than 24bit doesn't make any sense.

No. A higher precision than 24bit does make sense, and that's the reason I think you should drop the padding and keep the float to 32 bit PCM as it currently is. I know I have stated that previously, but now I have realized I was wrong. Let me explain...
I was attached to the idea that a 24bit significand in FP has the same meaning as 24 bit in integer, but it's not. The 24 bit significand means that at any exponent used, we have always a precision of 7 decimal places.
With 24 bit PCM, we can only represent the values 1, 2, 3, ... we cannot represent 1.2, or 1.246, but with 32 FP we can, hence we have higher precision at low values.
So, I think we should perform the conversion from float to PCM32 and simply drop the padding idea, because if we convert to 24 bit PCM and pad to 32 bit PCM we will lose precision at lower values.

In reality, we could perfectly live with the "24 bit PCM padded to 32 bit" because there is not (and probably never will) any soundcards with more than 24 bit DACs, so the 8 LSb will always be dropped, but it doesn't hurt to have the data there...

Pros for going with float->24 bit PCM padded to 32 bit:
-Faster conversion
-In case we're storing the data in a file it will compress better
-No soundcards higher than 24 bit

Cons:
-details lost at the lowest 8 bits
-if one day 32 bit soundcards are available you will be asked to remove the padding option...

Sorry for the constant changing in some of my ideas, but I'm somewhere in the middle of the learning curve, so mistakes do have to happen...

 

[yesgrey3]

I'll change the "bit exact" display to be more relaxed.

Great!

I agree with all rules except:

3.) If the input format is FP, any conversion to <24 bit int is not bit exact.

As you will notice after reading my previous post, this should be:
3.) If the input format is FP, any conversion to int output is not bit exact.