ReClock 1.8.5.5

[leeperry]

I'm afraid its not much use to me as my ATI 4550 only supports the 'usual' sampling frequencies.

well, you can still fully disable resampling...then fear the consequences if something hiccups

padding 16/24bit to 32 is not bit-perfect anymore, it's...padded

you can pad HDCD from 16/44.1 to 24/44.1 and I don't think any amp will catch the HDCD stream(reason why James added the option to leave 16bit untouched)

 

[James]

I don't agree with that... adding 8 zero bits to the righ just for padding it to another format is not inexact, so I think it should show the "bit-exact" words... Now I realized that the problem I referred sometime ago was not only in XP. The problem is that. When we need to output in another bit depth due to our drivers limitations, reclock considers the audio as not bit exact anymore. I don't agree with this. For me, the bit exact word when we are padding the original audio to output at a higher bit depth (Not 32FP, off course) should always appear.

I have a confession to make....
ReClock isn't just padding bits, it will always convert to IEEE float and back, if there "is anything to do" with the sound. From the design point of view it makes sense, because ReClock is primarily designed to "do something" with the sound anyway which requires IEEE float (resampling, time stretching). Only if everything matches it will not convert.

 

[leeperry]

BTW, James, I've found a thread where a VST plugin coder explains how to transport 25int in 32fp: http://www.diyaudio.com/forums/digi...capable-bit-perfect-output-4.html#post1466525

more details here: http://www.diyaudio.com/forums/digi...capable-bit-perfect-output-4.html#post1467029

and it's been double-checked: http://www.diyaudio.com/forums/digi...capable-bit-perfect-output-4.html#post1470592

maybe that could be used in Reclock at the final stage when converting the resampler's output to integer(and also to feed it)? :agree:

this diyaudio.com thread was initially about ppl like Scott Wurcer(the engineer who designed the AD797 op-amp) making fun of the XXHigHEnd coder(it's hard to bs EE's ), and he said something more than usual here: http://www.diyaudio.com/forums/digi...capable-bit-perfect-output-5.html#post1785111

I keep on poking right into the driver's buffer, nothing in between it.

 

[kawabungler]

Feature request:

Please add the ability to manually change the gain/volume in the reclock properties or config. My laptop is weird in that it doesn't use the windows volume settings when using wasapi so my output ends up being very loud.

Thanks!

 

[James]

Feature request:

Please add the ability to manually change the gain/volume in the reclock properties or config. My laptop is weird in that it doesn't use the windows volume settings when using wasapi so my output ends up being very loud.

Thanks!

Of course it doesn't. Just use DSound if you want volume control.

 

[iSeries]

Is converting to float and back lossy if there is no resampling involved?

 

[yesgrey3]

I have a confession to make....
ReClock isn't just padding bits, it will always convert to IEEE float and back, if there "is anything to do" with the sound...
Only if everything matches it will not convert.

Ok.Thanks for the confession. I will go back to ffdshow for padding it to 32bit. Not a big problem to me, since I use it for almost all my audio decoding.

 

[yesgrey3]

Is converting to float and back lossy if there is no resampling involved?

If done right, it's not lossy.
If we use 32bit FP, 16bit is completelly lossless and 24bit is near the edge, but it can also be lossless if done right. If you want to play safe, use ffdshow for the conversions, it pads.

 

[iSeries]

yesgrey3 - thanks. Do you mean output 32bit fp from ffdshow? Didn't ffdshow have some issues with FLAC decoding?

 

[James]

If done right, it's not lossy.

Now the question - am I doing it right? It's the code made by Ogo, and so far nobody complained...

If you volunteer I can post the conversion routines for you to review.

 

[leeperry]

Now the question - am I doing it right?

didn't like my link above? killer 32fp conversions both ways would be fantastic :agree:

and a shorter gap for audio files too, but well..I won't annoy you w/ that

 

[yesgrey3]

yesgrey3 - thanks. Do you mean output 32bit fp from ffdshow?

No. 32bit PCM. My soundcard only accepts 16bit PCM and 32bit PCM.

Didn't ffdshow have some issues with FLAC decoding?

The only problem it had was only 16bit support, but I think that it was already solved by someone. But to be secure, I use madFlac for flac, and I enable raw support in ffdshow so I can change its bitdepth.

Now the question - am I doing it right? It's the code made by Ogo, and so far nobody complained...

If you volunteer I can post the conversion routines for you to review.

Sure, I could take a look into it. If you prefer send me the code via PM.

 

[leeperry]

No. 32bit PCM. My soundcard only accepts 16bit PCM and 32bit PCM.

the XXHighEnd coder said in the thread I linked above that most soundcard drivers refer to 32bit PCM when they actually process 24...so if you do 32float>32int in Reclock, the bottom bits would most likely be trimmed.

 

[yesgrey3]

Yes. My soundcard has 24bit resolution, 32bit is only the format for the communication with the drivers. It seems it's needed for a better handling of the bandwidth over the PCI bus. Also, from a coder perspective, it's a lot easier to only support 16bit and 32bit PCM connections, because it will match the unsigned short and int in C. In computer languages, there is no default type definition for a 24bit integer...
When converting between 32bit PCM and 32bit FP the LSB 8 bits of the 32 bit PCM are trimmed, but that's not a big problem, because all audio is 24bit resolution, and even 24 bit is more than needed.

 

[leeperry]

When converting between 32bit PCM and 32bit FP the LSB 8 bits of the 32 bit PCM are trimmed, but that's not a big problem, because all audio is 24bit resolution, and even 24 bit is more than needed.

well, if you resample and output 32int in Reclock, won't 32bit actually be used? 32int has more values than 32fp if I understood correctly?

Apparently 24bit is quite a fanciful format for DSP due to its 3-byte alignment...some old drivers for my soundcard made by the original DSP designer only do KS in 16/32, but VIA has added 24 support...which sounds as balanced as 16, 32 sounds edgy and agressive(nasty conversion in the drivers )

 

[James]

Sure, I could take a look into it. If you prefer send me the code via PM.

It's not really a secret (I hope), I'll attach it here.

 

[yesgrey3]

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.
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.
View attachment conversion_y3.zip

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?

 

[leeperry]

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 feed 32FP and output 24int(and maybe 32int later)...the 2^15 trick mentioned here wouldn't be relevant at all http://forum.slysoft.com/showpost.php?p=238400&postcount=4223

When float32 is used in audio on the PC, audio values do tend to be normalised to between +/-1. [..] Converting the other way involves casting to float32 and then dividing by 2^15

converting asymmetrically seems to be a common way people do this. That's not lossless - in fact, it's quite ugly. People seem to find it important for some reason to make sure they use every floating-point value between -1 and +1. Since the integral formats are asymmetrical, direct conversion will clip if you ever have a floating-point value of +1.

Vista's kmixer either processes the sound regardless if it's required or not, or the conversion is done improperly.

we can't count on vista, but on Reclock?

 

[yesgrey3]

I feed 32FP and output 24int(and maybe 32int later)...the 2^15 trick mentioned here wouldn't be relevant at all

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

 

[imilne]

Hi James

I have a minor feature request that hopefully wouldn't be too difficult to implement (if I've understood what's happening properly).

I use Reclock in combination with Powerstrip to change my refresh rate, and on the whole it works pretty well, with one minor annoyance: if, for example, my display is at 50hz, and I start watching some 50hz content, I get a noticeable stutter in the video for a second or two while Reclock calls the external script, even though the script returns without doing anything. (It probably not Reclock's fault, so much as any delay in the script itself running, or the speed of my CPU etc).

So I was wondering. Would it be possible to add an additional checkbox alongside the "Enable events notification" that states "Only call external event if Reclock state *is not* GREEN".

So the logic would be something like:

- On playback and state != GREEN, then call script
- On playback and state == GREEN, then do nothing
- On stop playback, call script

Thanks