News:

ポストを行うにはアカウントの登録を行ってください
Please register account, if you want to post.

Main Menu

Bad Audio Handling - 16-bit - Truncate information

Started by zerowalker, May 30, 2014, 07:55:48 AM

Previous topic - Next topic

zerowalker

I noticed after some testing that Dxtory seems to truncate audio instead of dithering it down.

I did a test with extremely low audio and then increased it, this is because 16-bit and 32-bit only differ in it's noise-floor, meaning 32-bit can have lower volumes which doesn't drown in Audio, but this is however nothing to really care about, it's more or less used in editing software to have the least rounding errors possible, 16-bit is the way to go for the end result.


Now, the thing is, in 16-bit the audio was extremely distorted, it was cut off and sounded like a popping mess, pretty much like it sounds when you yell in a microphone, the audio is cut of cause it's to loud (but here because it was to low?).

32-bit however sounded as expected, much noise (as it was so low volume), but the audio was more or less correct, not comparable to 16-bit.


Now, to conclude this isn't a 32-bit vs 16-bit issue, i took the 32-bit audio and converted it to 16-bit manually, and the result was the same as 32-bit, noise but you could hear the audio.
This means that Dxtory must be doing something wrong when it captured 16-bit.


I am pretty sure that all audio that goes on in windows is 32-bit floating point, as it's mixing around all the time which makes this the best choice.
So, if you now capture in anything else, a transformation must be done, normally the best choice is to dither it down to whatever you want (16-bit for example), and the end result will be next-to-lossless.

Dxtory is however not doing this, my guess it that it just looks at the 32-bit, removes everything that is beyond 16-bit and be done with it.
This isn't a good approach at all. An easy one, yes, but not a good one.

I doubt anyone will actually care about this discovery, but i can at least try to point it out.

This matter should be solved, it's not Dead Serious, but it's an issue that just shouldn't be there for any reason, there is no loss in dithering instead of truncating, except perhaps some CPU use, but we are talking such low usage it isn't comparable in Realtime use, it won't matter at all to recording and effect anything in the system.

Hope someone at least reads this;P

Here is a link to the files: https://drive.google.com/folderview?id=0B_UKJFH8rbiNVGIxSHc1VkZxOG8&usp=sharing
I couldn't save the 32-bit file in Flac without converting it to 24-bit, but it sounds the same and the leap between 16-24 is huge anyway. The result is the same, no worries;)

Thanks!

De-M-oN

Good to know. That explains the hard limiting at -6db as well then.

Thanks for the info.