ReClock 1.8.5.5

[James]

your drivers only do 16bit, end of story? well it'll be resampled to 32float in Reclock, no point in downscaling your 24bit tracks to 16 before feeding Reclock.

For drivers only supporting 16bit, I would simply let MS do the job. The Vista / W7 resampler / mixer uses 32float anyway, so let ReClock output 32float via DSound or Wave. Set ReClock to the same frequency as the MS mixer is set. I believe it'll sound pretty good.

 

[andy o]

I think you overestimate the foobar ppl, they are not audiophiles and are happy as long as they get sound..."oh it's working, wonderful!"(w/ italian accent )

I take it you've already been to hydrogenaudio and gotten in fights and stuff?

 

[leeperry]

I take it you've already been to hydrogenaudio and gotten in fights and stuff?

oh yes, like every normal person on this planet? I've been found guilty of several TOS infringing and got myself banned 8)

anyway, they say in their FAQ that if ppl find that players sound different, it's placebo(they even think that KMixer's distortion on XP cannot be heard, hah bad case of wooden ears)...maybe it's time they stop feeding each other bs on their retarded forum, and actually compare Reclock/XXHighEnd and foobar...they sound anything but identical, and of course each time foobar is the worst.

this said, their DSP are processed in 32float(VST plugin, etc), then you can only output 32bit to ASIO on many soundcards...do they feed full 32 or 24 padded? it's anyone's guess, but well their player sounds ugly anyway so it's not like we really care :disagree:

but they say "setting the bitdepth higher than your actual hardware capabilities will decrease SQ"...so they're prolly sending full 32bit.

For drivers only supporting 16bit, I would simply let MS do the job. The Vista / W7 resampler / mixer uses 32float anyway, so let ReClock output 32float via DSound or Wave. Set ReClock to the same frequency as the MS mixer is set. I believe it'll sound pretty good.

good point! I would never trust the m$ mixer, but well..why not

 

[James]

@yesgrey3

Oh, I'm so stupid. I just realized - while typing in the changes to ReClock - that it is pointless.

Normal version:

					case 32:
						// IEEE Float --> PCM32
						{
							SWITCHBUFF
							float* isample = (float*)l_inputBuff;
							long* osample = (long*)l_outputBuff;
							for(int i=l_sizeIn/4; i>0; i--)
							{
								double l_double = *isample++ * 2147483647.0;
								CLIP_SAMPLE(l_double, -2147483648.0, 2147483647.0)
								*osample++ = lrint(l_double - 0.5);
							}
							l_sizeOut = l_sizeIn;
						}
						break;

Nullified version:

					case 32:
						// IEEE Float --> PCM32 with padding
						{
							SWITCHBUFF
							float* isample = (float*)l_inputBuff;
							unsigned char* osample = (unsigned char*)l_outputBuff;
							for(int i=l_sizeIn/4; i>0; i--)
							{
								double l_double = *isample++ * 2147483647.0;
								CLIP_SAMPLE(l_double, -2147483648.0, 2147483647.0)
								long l_temp = lrint(l_double - 0.5);
								osample[0] = 0;
								osample[1] = (unsigned char)(l_temp >> 8);
								osample[2] = (unsigned char)(l_temp >> 16);
								osample[3] = (unsigned char)(l_temp >> 24);
								osample += 4;
							}
							l_sizeOut = l_sizeIn;
						}
						break;

The difference is only the LSB beeing zeroed. :doh:
Sometimes I need a little bit longer to understand what I'm actually doing.
In other words: It doesn't matter what I do. I'll leave the FP->PCM stuff as it is, it works fine. Only thing I could (should) address is the PCM->PCM conversion if resampler isn't needed.

 

[leeperry]

I'll leave the FP->PCM stuff as it is, it works fine.

so...no 24bit padded to 32 then? converting to 32int yields data that are most likely tossed away, or poorly converted by the audio drivers.

16/24/32bit from Reclock sound very different on my setup...16 and 24 sound identical, and 32 sounds bright and edgy.

Ideally if you could make a "24 padded to 32" that does exactly the same as 24, but then converts to 32 afterwards...so you're not just nulling the bottom 8 bits, you're padding them.

 

[el Filou]

your drivers only do 16bit, end of story? well it'll be resampled to 32float in Reclock, no point in downscaling your 24bit tracks to 16 before feeding Reclock.

OK thanks for the confirmation.

For drivers only supporting 16bit, I would simply let MS do the job. The Vista / W7 resampler / mixer uses 32float anyway, so let ReClock output 32float via DSound or Wave. Set ReClock to the same frequency as the MS mixer is set. I believe it'll sound pretty good.

Well the thing is, I'm still on XP, and I definitely don't trust its mixer nor Realtek-designed ATI drivers (DSound on my system definitely sounds worse than KS through ReClock).
Guess I'll have to upgrade to W7 one day...:bang:

 

[James]

so...no 24bit padded to 32 then? converting to 32int yields data that are most likely tossed away, or poorly converted by the audio drivers.

It wouldn't make any difference. Either ReClock tosses them, or the driver. The code would be exactly the same as if doing FP->32bit and simply blanking one byte.

16/24/32bit from Reclock sound very different on my setup...16 and 24 sound identical, and 32 sounds bright and edgy.

I find this hard to believe, and if it does it's probably because of a driver bug.

 

[yesgrey3]

the only scenario that could have precision loss is when the input is 24 bit PCM, the output is 32 bit PCM, and the resampling is bypassed. This is not the most common situation, but is my situation.

Only thing I could (should) address is the PCM->PCM conversion if resampler isn't needed.

I have not said it exactly like you did, but it was close...

But there is still another situation where the padding would be helpful even with resampling enabled: when the soundcard's DAC has 24 bit, because in these case, the drivers would convert the 32 bit to 24 bit (internally), because that's the only thing that they could feed into the DAC, so, probably it's better avoiding that conversion and feeding them directly with 24 bit padded...
You're code for this situation was not correct, though. Here is how it should look like:

Nullified version:

					case 32:
						// IEEE Float --> PCM32 (24 bit with padding
						{
							SWITCHBUFF
							float* isample = (float*)l_inputBuff;
							long* osample = (long*)l_outputBuff;
							for(int i=l_sizeIn/4; i>0; i--)
							{
								long l_samp = lrint(((double)(*isample++) * 8388607.0) - 0.5);
								CLIP_SAMPLE(l_samp, -0x800000, 0x7FFFFF);
								*osample++ = l_samp << 8;
							}
							l_sizeOut = l_sizeIn;
						}
						break;

Also, I've realized that the code for the IEEE -> PCM24 was not correct. It was discarding the lower 8 bits from the conversion to 32 bit instead of converting to 24 bit. The correct conversion should be:

					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 = lrint(((double)(*isample++) * 8388607.0) - 0.5);
								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;

I also have not yet understood why ogo subtracted 0.5 for the conversion to int. It could be a bug, or not. I will dig into it and will let you know later...

 

[yesgrey3]

Hi Guys. Sorry if that's a dumb question, but is there a lot of precision lost in 16int=>ReClock=>32float=>16int ?

That chain is lossless, because the float has enough precision to handle the 16bit integer.

And with 24int=>ReClock=>32float=>16int?
I mean, in this case I know I will lose something even without going to float in the middle, but will it usually be very ugly or does ReClock uses special tricks to minimize the damage?

No tricks are used, I don't recomend it.
The better options are:
(1) 24int=>ReClock=>32float=>dither to 16int
unfortunately, reclock does not support dithering
This option would give you a pseudo higher output bit depth, despite the 16 bit.
(2) use ffdshow to dither, like this:
24int=> ffdshow dither to 16int=>ReClock=>32float=>16int
This option would also give you a pseudo higher output bit depth, despite the 16 bit, but it will be inferior to (1), because dithering should be performed only at the later stage.
(3) 24int=>ReClock=>32float=>24int=>16int (dropping the lowest 8 bit)
I think that the conversion from a higher input bit depth to a lower output bit depth, with float as the intermediate stage, is not optimal right now...
I think it should convert at the end to the same bit depth as the input, and then discard the lower bits.

Currently, IMO reclock distorts the output when the input bit depth (if PCM) is higher than the output bit depth (if PCM)...

 

[leeperry]

I find this hard to believe, and if it does it's probably because of a driver bug.

I currently use PCM24 and all is well, it sounds identical to PCM16..but if there's some hiccup in the PCM32 conversion(whatever in Reclock or in the drivers) going 24bit padded to 32 should sound identical to PCM24 on my soundcard.

it is VERY much brighter and edgy, I've done the test many many times

anyway, I'm kinda beating a dead horse here...but XXHighEnd never outputs full blown PCM32, it does PCM24 padded to PCM32 as there's currently no drivers that sends untouched PCM32 to the DAC AFAIK...who needs 32 bit anyway? PCM24 is already overkill, but at least it fills all the registers of the DAC for the most accurate analog conversion(especially at 192kHz).

That chain is lossless, because the float has enough precision to handle the 16bit integer.

even w/o the 2^15 trick?

I think that the conversion from a higher input bit depth to a lower output bit depth, with float as the intermediate stage, is not optimal right now...
I think it should convert at the end to the same bit depth as the input, and then discard the lower bits.

Currently, IMO reclock distorts the output when the input bit depth is higher than the output bit depth...

I only feed 32float to Reclock, and output PCM24 to my soundcard drivers....is that bad?

 

[yesgrey3]

16/24/32bit from Reclock sound very different on my setup...16 and 24 sound identical, and 32 sounds bright and edgy.

I find this hard to believe, and if it does it's probably because of a driver bug.

If you read my previous posts, maybe he's right...
When the input is 24bit, if you "spread" the data to 32 bit and then simply cut the lower 8 bit, it would not be nice... The conversion should be to 24 bit and setting the lower 8bit to zero. If the input is 32 bit, then you should "spread" the data to all 32 bit.

Summing up, the way the data is converted from float to PCM, depends on the input bit depth (if PCM).
Probably I have confused you a little more, but I really hope not.

 

[leeperry]

Summing up, the way the data is converted from float to PCM, depends of the input bit depth.

it doesn't match what I see in Ozone or Wavelab when measuring the number of bits of ffdshow+libsamplerate...as soon as you do 32float processing, you do feed all the 24bits...they all light up!

so whatever 16/24/float input, they will all end up in full 32float format in Reclock's resampler...from what I understand what you said is true if you don't resample. you can convert 16int to 32float, only the top 16 top bits will light up, but if you resample in 32float, the 24 bits will light up

what matters now is to allow float conversion to :
PCM16
PCM24
PCM24 padded to PCM32
PCM32

so depending on your drivers or whatever, you can choose what sounds best to you.

and ideally PCM24/PCM24 padded to PCM32 should sound identical on my sourcard.

 

[yesgrey3]

even w/o the 2^15 trick?

Yes.

I only feed 32float to Reclock, and output PCM24 to my soundcard drivers....is that bad?

Sorry, I forgot to add that it only applies for PCM. I already edited the post.

 

[James]

Also, I've realized that the code for the IEEE -> PCM24 was not correct. It was discarding the lower 8 bits from the conversion to 32 bit instead of converting to 24 bit.

Ah... But Leeperry's ears kinda liked it.

 

[leeperry]

Ah... But Leeperry's ears kinda liked it.

well, 16/24 sound identical...and 32 sounds brighter, but both in foobar and Reclock...and both apps appear to send non padded PCM32.

but I'm feeding 16bit files anyway..hahah

I will try some older drivers for my Envy24 card that were not made by VIA(they bought ICEnsemble), maybe the last ICEnsemble drivers would sound different(they only allow PCM16/32)

you know, computer digital audio is a lot less easy than it seems...I think the XXHighEnd coder spent several years to code his player and finetune it, 70 EUR is not that expensive when you get to think about it if it's as good as they say(last time I tried it was like 6 months ago, I'll try again anytime soon). Amarra sells for like $400 in mini-version and $1K for the full one, and it's said to blow everyone else out of the water(it's made by Sonic).

PS: ok, I've sent compare.cpp to Wingfeather, the VST plugin coder from diyaudio.com

PPS: hah http://www.phasure.com/index.php?topic=1007.msg8383#msg8383

Maybe I'm too early with my judgement, but it is fuller, again more tight and pressured bass and something like a better colour. More mid.
It can play inifinitly loud at the same time.

Also, if I look what I did relatively to WASAPI, it indeed would go that direction.

Yes, it is Kernel Streaming, but implemented in a way for sure nobody does / has done.

I can assure you that KS in Reclock and foobar sounds VERY different.

 

[leeperry]

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:

Hi leeperry,

A few thoughts:

An immediate problem I see is that lines 113/114 (float->PCM32) and lines 129/130 (float->PCM24) of the file you linked use the same multiplier and clipping limits as each other - probably not what you want, and I can see why this might mess up the float->PCM24 conversion if nothing else.

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.

My point of view is that you're incredibly unlikely to produce any samples which occupy the few floating-point values that cannot be converted (properly) to PCM, especially if you're taking samples from the PCM input anyway, so I always do it in a symmetrical fashion. I believe the guys from PortAudio (for example) disagreed with me on the importance of that point, so I modify their conversion library if I need to use it.

Just to be clear, I would use a multiplier of 2147483648.0 in line 113 and 8388608.0 in line 129, etc.

Hell, your code is closer to this than some - I've seen one converter which uses different multipliers depending on whether the sample is positive- or negative-valued! That's rather hideous from a signals/distortion perspective.

Another quick point is the comments about subtracting 0.5 prior to converting to int. To be honest, I'm not sure why he's SUBTRACTING (I always add, which I'm pretty sure is the right way to do it), but it appears to be a rounding vs. truncation thing: when you convert a float to an integral type it truncates off the last few bits rather than rounding to nearest. This doesn't mean much of anything in terms of distortion, but it does introduce a -0.5LSB DC offset into the signal. If you add the half an LSB prior to the truncation you get proper rounding instead, which is more elegant. It might be better to add it prior to clipping rather than after it.

I'm sorry that I'm not sure what could be wrong with PCM24->PCM32 conversion - I think the code looks broadly right, but I hope this has helped in some small way. It has been a little while since I've had to code anything in this area, so there are likely to be things I've missed.
I don't have much more time to look at the code right now (am at work!), but I'll have another look later - do let me know if I can do anything else. This stuff is fun

 

[yesgrey3]

anyway, WingFeather has answered me:

His doubts were my doubts. The not usage of the higher number representable by the integer types, but that value-1 and the roundig subtracting 0.5 instead of adding 0.5, like I also use to do.
Like I've said, I will look into it more carefully and if James wants I could change the code according to this...

 

[yesgrey3]

Ah... But Leeperry's ears kinda liked it.

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

 

[iSeries]

On Win 7: If I go the DirectSound route instead of WASAPI and output 32bit float 192khz from Reclock, and I set the 'Default Format' through the Windows volume mixer to 24 bit 192khz, will it resample the output (assuming no other sounds playing)?

 

[James]

On Win 7: If I go the DirectSound route instead of WASAPI and output 32bit float 192khz from Reclock, and I set the 'Default Format' through the Windows volume mixer to 24 bit 192khz, will it resample the output (assuming no other sounds playing)?

It probably won't resample (Vista *will* resample everything to 192k), but it is still going through the mixer. It will not be bit exact. But - who cares, as long as it sounds good?