ReClock 1.8.5.5

[leeperry]

No, because the resampler code expects all values between [-1.0,1.0], so the 2^15 trick cannot be used.

I meant when converting the resampler output to 24/32int before sending it to the soundcard's driver...he says that it's pointless to use all the values and that 2^15 is better

 

[barco]

My god, you guys rock. I have just installed a new HTPC with win 7 to see if TMT3 without reclock would be any good (since I have been unable to use reclock since TMT build 126) with the new EVR renderer. The answer was better, but still not as good as with reclock. I was just about to reinstall again and use TMT3 build 120 when I looked fo a new reclock. And behold, it now works with the latest TMT3 (build 160) !!
Since you are not charging for reclock, can I donate to this project somewhere? Or the slyplayer project?

Thanks a lot for you great work!

 

[James]

There are some things I don't understand....

James,
I took a look at the code and it seems fine to me.
Considering that when the input and output bit depths are the same reclock does not perform the conversion to 32 bit FP, 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.

If 32 bit FP has a 24 bit precision, why would a 24bit->FP->32bit conversion be lossy?

The 32 bit FP has 24 bit of precision, but due to the conversion to the values [-1.0, 1.0] I'm not sure it would be lossless. I would have to run some tests to verify it, but, instead, I've decided to write some code to perform the padding/trimming when converting between different bit depths and the resampling is disabled. This should be faster then performing the conversion to float.
In case you want to add this to Reclock, I attach the file with the code. Note that I'm not sure it's bug free, because I don't have the rest of the code for compiling and running it. If you prefer that I verify that the conversion to float is not lossless before considering adding this code, let me know, and I will run the tests.

The major difference is - as far as I can tell - that your code simply nulls 8 bits with the 24->32bit conversion. But this isn't the same as the current implementation, as it - as far as I can tell - "spreads" the signal over all 32bits in the FP->32bit conversion.
So the conversion 24->32bit of your code is very different to the current 24->FP->32 conversion. Now the question, what do the soundcard drivers expect? 32bit values where 8 bits are ignored, or full 32 bits?
Maybe the correct approach (when resampling) would be, e.g.

16bit->FP->resampler->FP->24->y3->32

I also might try adding dithering for the cases where the output bitdepth is <= 24 bit PCM. This would be helpfull for the cases where occur the conversion from a higher input bitdepth to a lower output bit depth, when bypassing the resampler, and for all the cases, when reclock is resampling.
What do you think? Are you willing to add dithering as an option to Reclock?

This would only be important if a soundcard can't receive 24 or 32bit. I don't know if this is needed, I would first try to get the 32bit output "right" (whatever this means).

 

[leeperry]

if a soundcard can't receive 24 or 32bit. I don't know if this is needed

http://www.diyaudio.com/forums/digi...capable-bit-perfect-output-2.html#post1445693

the file data (3 bytes per sample per channel) will never match a soundcard (needing 4 bytes).
Therefore it's rejected. In kernel code the match won't go.

Better look at it some other way around :

The file says 3 bytes per channel, and THUS the soundcard is attached with that. But no(ne that I know of) soundcard can do that.
Then it backfires on you, because the soundcard needs 32, and now the file doesn't match to that.

What it comes down to (functionally spoken) is that the FILE needs the padding.

What I know is that each driver of which I can expect to report decently, all report 32 bits (at feeding with 24).
All 'n all, I did not find one application that would swallow the 24 bits (but i.e. a Juli@ "SAYS" it can do 24. It only actually works with 32 though).

all I know IRL is that the last drivers for my soundcard from the original designer only do 16/32(and 32 sounds very bright and agressive fed from Reclock...prolly a nasty 32>24 conversion or trim in the audio drivers), and the new ones do 16/24/32(24 sounds just as good as 16).

from what I understand you need to feed 32bit and keep the last 8 bit empty, as these will be trimmed anyway...very few cards accept 24bit as is(a linux ALSA driver expert told me "24bit is quite a fanciful format for DSP due to its 3-byte alignment") and sending full 32bit is a complete waste of SQ.

 

[yesgrey3]

I meant when converting the resampler output to 24/32int before sending it to the soundcard's driver...he says that it's pointless to use all the values and that 2^15 is better

At that stage is already too late, because the precision loss happens when converting from 24 bit PCM to FP values [-1.0,1.0].

If 32 bit FP has a 24 bit precision, why would a 24bit->FP->32bit conversion be lossy?

The problem is due to the conversion to FP with values in the range [-1.0,1.0]. For that you have to perform a division, hence the possible loss of precision. If it was only a type conversion, it would be lossless, but it's not. I will run some tests to see how much the error is.

The major difference is - as far as I can tell - that your code simply nulls 8 bits with the 24->32bit conversion. But this isn't the same as the current implementation, as it - as far as I can tell - "spreads" the signal over all 32bits in the FP->32bit conversion.
So the conversion 24->32bit of your code is very different to the current 24->FP->32 conversion. Now the question, what do the soundcard drivers expect? 32bit values where 8 bits are ignored, or full 32 bits?
Maybe the correct approach (when resampling) would be, e.g.

16bit->FP->resampler->FP->24->y3->32

This is what's described in my soundcard's user manual:

36.6 Transfer Modes: Resolution / Bits per Sample (Windows only)
ASIO
• 24 / 32 bit 4 byte (stereo 8 byte)
This format is compatible with 16-bit and 20-bit. Resolutions below 24-bit are handled by the
audio application.
WDM
• 16 bit 2 byte (stereo 4 bytes)
• 16 bit 4 byte MSB (stereo 8 bytes)
• 24 bit 4 byte MSB (stereo 8 bytes)
• 32 bit 4 byte (stereo 8 bytes)

From this it seems the drivers would accept both formats. If they receive the data "spread" over the 32bit, they should then "shrink" the data for the 24bit of the DAC. If the audio data is only in the MSB 24 bits, they should use the data directly. I will ask them how it works...

This would only be important if a soundcard can't receive 24 or 32bit. I don't know if this is needed, I would first try to get the 32bit output "right" (whatever this means).

Yes, I agree. Today almost all soundcards work with 24bit, so they all should accept 32 bit PCM.

 

[James]

From this it seems the drivers would accept both formats. If they receive the data "spread" over the 32bit, they should then "shrink" the data for the 24bit of the DAC. If the audio data is only in the MSB 24 bits, they should use the data directly. I will ask them how it works...

How does the driver "know" which format is used? In the waveformatex I can't distinguish between 32 bits full and 32 bits 8 bits unused.

Thinking of it... @leeperry:
Could this be the reason - according to some high-end ears- foobar wasapi doesn't sound "as good as" ReClock? Maybe the drivers *expect* full 32bits PCM and foobar sends 24bit and 8 padding bits?
This could be an explanation for the mystery...

 

[leeperry]

How does the driver "know" which format is used? In the waveformatex I can't distinguish between 32 bits full and 32 bits 8 bits unused.

Thinking of it... @leeperry:
Could this be the reason - according to some high-end ears- foobar wasapi doesn't sound "as good as" ReClock? Maybe the drivers *expect* full 32bits PCM and foobar sends 24bit and 8 padding bits?
This could be an explanation for the mystery...

how about offering both options? 32bit DAC's do exist, but I don't think any soundcard supports it yet....hell, even 20 actual bit can hardly be reached on a PC soundcard analog outputs, so 24bit is already overkill.

AFAIK, outputting 32 unpadded bits is a major waste of SQ, and no audio driver engineer would even expect that...many ASIO drivers only allow 32bit, but it seems that they do expect 24bit padded(I think I read the cMP coder mentioning it on gearslutz.com).

this said, if you'd be to allow 24bit padded to 32, I could use those old drivers for my soundcard...they keep KS totally bit-perfect, but feeding it 32bit sounds harsh and bright compared to 16 as they need to convert back to 24int, and every int<>int conversion is very lossy

but it's like cables, opamps...sometimes a brighter sound is a good thing...if you have dark headphones/speakers and don't want to EQ, it can be a life saver. it's all about synergy.

I honestly think that foobar is a bad benchmark, this player sounds terrible even on XP...Reclock simply crushes it(both in 100% bit-perfect KS), a good benchmark would be xmplay or cMP/XXHighEnd.

No, because the resampler code expects all values between [-1.0,1.0], so the 2^15 trick cannot be used.

so trying it is not worth a shot either?

 

[James]

how about offering both options? 32bit DAC's do exist, but I don't think any soundcard supports it yet....hell, even 20 actual bit can hardly be reached on a PC soundcard analog outputs, so 24bit is already overkill.

AFAIK, outputting 32 unpadded bits is a major waste of SQ, and no audio driver engineer would even expect that...many ASIO drivers only allow 32bit, but it seems that they do expect 24bit padded(I think I read the cMP coder mentioning it on gearslutz.com).

Thinking of it.... what does ffdshow output if I set it to 32bit PCM? 24 bit with 8 padding bits? Or "full" 32 bit? This "bit stuff" confuses me...

 

[leeperry]

Thinking of it.... what does ffdshow output if I set it to 32bit PCM? 24 bit with 8 padding bits? Or "full" 32 bit? This "bit stuff" confuses me...

it depends...if you input 16/24 and don't do any processing, it will pad.

if you do post-processing *in* ffdshow, you can choose how accurate you want it: 16/24/32int or 32fp...if you go 32fp, you can choose what kind of noise shaping/dithering you want for the fp>int conversion(I suspect these options don't do anything, as I've never been able to ABX them ).

so basically if you input 16/24int, do 32int/32fp post-processing...ffdshow will output full 32int, and if you input 16/24int and either do 16/24int PP or no PP at all, it will pad.

atm yesgrey is padding 16int to 32int in ffdshow...but! because it will be resampled to 32fp in Reclock, if he sets 32int in Reclock as output, he's actually outputting full blown 32int...and his drivers have to do a very lossy conversion to 24int...

if there's no resampling or bit-depth conversion in Reclock whatsoever, then he is indeed outputting 24int padded to 32int.

 

[yesgrey3]

so trying it is not worth a shot either?

It's not possible to try it, because libsamplerate only works within [-1.0, 1.0] values. For trying it libsamplerate would have to be changed to work with other values, and that, obviously, is out of question. Also, It would be worthless, because the error should be minimal...

Thinking of it.... what does ffdshow output if I set it to 32bit PCM? 24 bit with 8 padding bits? Or "full" 32 bit? This "bit stuff" confuses me...

I don't know... I always assumed the padding because I never heard about 32bit DACs, but now thera are already some DAC chips with 32bit resolution.

it depends...

Are you sure of that? I took a look into ffdshow code but the conversion code is all in asm, so I don't have a clue. I think it would be better asking its coders about it...

 

[iSeries]

Whoa sorry chaps, you're losing me

Ok - my movies have either a 16bit or 24bit FLAC soundtrack, which is decoded by MadFLAC and sent to Reclock as bit perfect PCM. Reclock then converts to 32fp, resamples it, and pushes it out at 'full' 32bit int, of which my ATI 4550 will discard 8 bits of?

If I set Reclock to output 32fp and want ffdshow to convert to padded 32bit int, what do I need to do in the ffdshow config other than set the output bit rate to 32bit int? Eg there is a 'Processing' page which has 'Floating point to integer conversion' options (dithering and noise shaping). Do I need to do anything with those?

 

[James]

Whoa sorry chaps, you're losing me

Ok - my movies have either a 16bit or 24bit FLAC soundtrack, which is decoded by MadFLAC and sent to Reclock as bit perfect PCM. Reclock then converts to 32fp, resamples it, and pushes it out at 'full' 32bit int, of which my ATI 4550 will discard 8 bits of?

That's exactly the question - does it really "discard" 8bits?
Or does it something else with them?

 

[iSeries]

My receiver defintely isn't getting 32bit so its definitely doing something with them, so how its converting to 24bit int is anybody's guess...and my guess is it isn't pretty lol. Is it too tricky to change Reclock to output padded 32bit int instead of full?

maybe I just need to stop thinking about all this, and just sit back and enjoy a movie for once

 

[leeperry]

That's exactly the question - does it really "discard" 8bits?
Or does it something else with them?

what the driver itself does is anyone's guess...it will either discard the 8 bottom bits(16bit already has 96dB dynamics, how many do you need exactly? ) or it will convert to 16 or 24int(and each int>int conversion is very lossy by essence).

if there were a way to capture the drivers output(loopback S/PDIF?), we could check w/ a bit-meter(as in Wavelab or Ozone)...so that's 16/44.1 fed through Ozone4 in ffdshow(all processing disabled), you can see that the bottom 8 bits aren't lit:



and now if I play w/ ANY setting in Ozone4, they are indeed lit(as Ozone4 works in 64FP internally):



I've checked ffdshow's output bitdepth through Graphedit on many occasions, and that's how any audio app works...if there's no processing(in 32/64 int/fp), there just isn't ANYTHING to feed those 8 bottom bits.

if you convert 16 to 24 w/o any PP, you will get 8 padded bits...spanning 16 bit over 24 requires processing, it requires conversion and optional dithering/noise shaping. but anyway, each int/int conversion is always using dither, ppl talk about it like it's a new thing...but if we were to just trim bits, it'd sound HORRIBLE.

It's not possible to try it, because libsamplerate only works within [-1.0, 1.0] values. For trying it libsamplerate would have to be changed to work with other values, and that, obviously, is out of question. Also, It would be worthless, because the error should be minimal...

65533 roundoff errors? http://www.diyaudio.com/forums/digi...capable-bit-perfect-output-4.html#post1466989

you're in contact w/ the libsamplerate author, maybe this link would make sense to him? this VST plugin coder seems to very much know his business.

Are you sure of that?

if you are inputting 24bit padded to 32 to Reclock, let it do some 32fp processing and outputting 32int in the end again, then yes! I'm pretty damn sure that you're sending more than 24int to your audio drivers.

but 32int includes more data than 32fp, so maybe you're not really sending 32 full bits, I think you can only make 25int out of 32fp?

anyhow, if you guys could just add "32 bit" and "24bit padded to 32" in the Reclock bitdepth options, we would call it a day and anyone would be able to try both and pick whichever one he prefers 8)

 

[yesgrey3]

I've already started a new thread on the RME forum. I will inform you as soon as I get an answer...

each int>int conversion is very lossy by essence

Only from a higher int bitdepth to a lower int bit depth.

I've checked ffdshow's output bitdepth through Graphedit on many occasions, and that's how any audio app works...if there's no processing(in 32/64 int/fp), there just isn't ANYTHING to feed those 8 bottom bits.

No, that's not the reason. They do it like that for minimizing the conversion errors from float to int. All ffdshow internal processing is performed using 32 FP, so, when ffdshow processes audio data, it works like reclock, "spreading" all bits over the entire output bit depth, which is easy when using FP as the intermediate step.
The only difference that remains is reclock not having (yet) an option of conversion to a higher bit depth by padding the input with zeros when no resampling is performed, like ffdshow does when it does not process the audio data.
Before asking James to add that, let's hear what the drivers developers have to say...

65533 roundoff errors? http://www.diyaudio.com/forums/digi...capable-bit-perfect-output-4.html#post1466989

leeperry, you should have read a little more ahead to see that it was the result of bugged code...
http://www.diyaudio.com/forums/digi...apable-bit-perfect-output-19.html#post1470393

And even if it were 65333 roundoff errors, that would only be significant if it were significant errors.

 

[el Filou]

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

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?
My view is that even though those fancy BDs can have 24-bit tracks, there is no way I'm "enjoying" 144 dB (or even 108, which is my DAC's limit, for that matter) dynamic range anyway, so how much lossy is the conversion from 24 to 16 in ReClock?

In other words: currently I'm outputting 24int to ReClock from 24-bit sources and then ReClock has to downsample it to 16-bit to send to the driver; do you think it would be better if I configured ffdshow's decoders to output 16-bit directly?
I'm still searching for a worthy movie scene to compare these but it's hard as I don't know what kind of sounds would best show the difference.

Thanks for the interesting info in this thread.:clap:

 

[leeperry]

I've already started a new thread on the RME forum. I will inform you as soon as I get an answer...

well, luckily RME is not god...they don't give a damn about WaveRT drivers(Echo Digital fully support them since day 1), and don't even allow 24bit in their drivers...VIA does support 16/24/32.

I think most ppl using crappy Realtek drivers are worried of wth happens when they feed 32bit, you can rest assured that they prolly went the EASIEST way...like downscaling to 16bit?

adding "24 bit padded to 32" in Reclock would give more options for ppl w/ audio OCD #_#

Only from a higher int bitdepth to a lower int bit depth.

well yeah, going 32int>24int for instance..that's what I was referring to.

No, that's not the reason. They do it like that for minimizing the conversion errors from float to int. All ffdshow internal processing is performed using 32 FP, so, when ffdshow processes audio data, it works like reclock, "spreading" all bits over the entire output bit depth, which is easy when using FP as the intermediate step.
The only difference that remains is reclock not having (yet) an option of conversion to a higher bit depth by padding the input with zeros when no resampling is performed, like ffdshow does when it does not process the audio data.

yes, that's exactly what I meant
english is neither yours or my native tongue, so stuff gets lost in translation from time to time I guess ^^
if you output 32bit FROM Reclock, you don't get your 24bit padded to 32.

if you wanna see how it's processed in ffdshow, get it to output to a WAV file in Graphedit...and count the bits in Wavelab or Ozone. IME if you input 16int and don't do any PP, you can output whatever you like(24/32fp or int), only the top 16bit will light up.

leeperry, you should have read a little more ahead to see that it was the result of bugged code...
http://www.diyaudio.com/forums/digi...apable-bit-perfect-output-19.html#post1470393

And even if it were 65333 roundoff errors, that would only be significant if it were significant errors.

oh yes, this code goes way over my head! and I never said these errors would be significant, nor audible...considering we'll end up resampling them anyway. But, maybe going 2^15 back and forth the resampler would offer better results in the end...only asking the libsamplerate's coder would answer this question for sure?

 

[James]

adding "24 bit padded to 32" in Reclock would give more options for ppl w/ audio OCD #_#

Yes, and if I wasn't so lazy, I could do it this way:
If you select 24 bit and the driver refuses, automatically switch to 32 and pad 8 bits. I believe this is the way foobar does it.

OTOH, if you select something manually you know exactly what you're getting. Either sound or no sound (in case of Wasapi a message box saying the driver didn't like it). And it's less work.

 

[yesgrey3]

Yes, and if I wasn't so lazy, I could do it this way:
If you select 24 bit and the driver refuses, automatically switch to 32 and pad 8 bits. I believe this is the way foobar does it.

It's not my preferred, but it would be the better for you... Prepare for a lot more questions like: should I select output with pad or without?

 

[leeperry]

Yes, and if I wasn't so lazy, I could do it this way:
If you select 24 bit and the driver refuses, automatically switch to 32 and pad 8 bits. I believe this is the way foobar does it.

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 )

just 2 options "32 bit" and "24 bit padded to 32" would be really cool, and I'll write down a nice section in the manual if you like.

AFAIK, XXHighEnd only does 24 padded to 32...and everyone agrees that it's the best player on PC.

maybe spending that time at implementing two separate prebuffer values for the initial DirectShow handshake and the Resampling adaptation would be better spent?

so we'd have almost no buffer on audio files(in KS/WASAPI, something like 25/50ms) and a big buffer for video files(500ms or more, to improve CPU overhead and global CPU load)

output 16-bit directly?

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.