FFDShow and 32bit Float.

[Sharktooth]

I've noticed there were some commits in FFDShow-tryouts that enables 32bit float in some decoders.
I would like to stress the fact it is perfectly USELESS.
It's not better in quality and it's not faster unless you have a CPU that executes FP operations faster than INT...

[nevcairiel]

It depends on the decoder, but if all it was providing before was 16bit int, it is in fact better quality. Going from 32-bit int to 32-bit float is pointless, however.
This only matters of course if you do post-processing on the audio (and/or outputting more then 16bit int to your sound card)

[Sharktooth]

24bit int is what most soundcards are capable of. still 32bit float is useless coz it's in the decoder.
post processing happens AFTER the decoding. so, again, it's useless.

[pandy]

With float You can have 24 bit INT accuracy and higher dynamic range than 24 bit INT without checking and scaling (at least in theory).
Modern CPU are quite similar in terms of speed FP and INT.

[Sharktooth]

the correct terms you should have used are "you COULD, in theory, maybe...", but it's not the case.
every sane encoder uses an INT transform (including video encoders). so, using FP is, again... USELESS.
its all FUD and no good...
oh, and however, Int ops are way faster than FP ops even on modern CPUs, otherwise x264 would use FP... dont you think?

[Gser]

Meh, my core i7 4,2Ghz doesn't complain, so why should I.

[tetsuo55]

The most important part right now is that the extra bits above 16, if/when available are no longer clipped off.

[nevcairiel]

libavcodec can output the 32bit float directly to the application using it, not only internally, so it can be used for post-processing by ffdshow, and then dithered to 16 or 24bit int for output.
If its done this way, i don't know. I know that in the case of the mpeg audio decoder in libavcodec, the integer decoder is actually better, and can be set to produce 32bit ints (a new float decoder was up as a GSoC task, but didnt happen afaik).

Anyhow, for many other decoders in avcodec, they internally already use float processing, but then cut the output to 16bit int for reasons unknown to me (probably compatibility or something).
For lossy formats, you should always try to keep the highest bitdepth possible in your decoding chain. In my system i have ffdshow output 32bit int to reclock, which then does its resampling magic, and converts it to 24bit before its send to the hardware, so any improvements on bit-depth up from the 16bit int are appreciated.

[STaRGaZeR]

The only problem I have with the float decoder is that it produces garbled sound in x64 builds. Is this a known problem when compiling for Win64 or it's just GCC doing its wonderful job like it did with the Vorbis decoder some time ago?

[pandy]

the correct terms you should have used are "you COULD, in theory, maybe...", but it's not the case.


yes and no...


every sane encoder uses an INT transform (including video encoders). so, using FP is, again... USELESS.
its all FUD and no good...


yes and no...
how frequently in video domain IIR filters are used ?


oh, and however, Int ops are way faster than FP ops even on modern CPUs, otherwise x264 would use FP... dont you think?

yes and no...
x264 use (SIMD) features in modern CPU and focus on performance and 8 bit samples

how fast is INT MAC and FP MAC (or rather FMA instruction in FP) on x86 (FMA seems exist only in Itanium family - still waiting for SSE5)

[Blue_MiSfit]

Am I correct in thinking that when doing channel / volume adjustments (i.e. downmixing to 3.1 and applying DRC as I do every day), clipping can be reduced by keeping the entire processing chain in higher bit depth?

Not sure if I'm correct, but it seems logical enough...

Derek

[nevcairiel]

Your thoughts are correct. When you do any processing on the audio, you should do it in the highest bitdepth you can.

[Blue_MiSfit]

Then it seems logical to assume that 32 bit float decode could definitely help me!

I often want to apply heavy DRC to a movie, and even though AC3 metadata should guide the decoder perfectly, it certainly doesn't all of the time.. especially on captured TV shows.

ffdshow-tryouts currently gives me fairly nasty clipping artifacts occasionally when I use the "volume" filter to perform DRC.

Derek

[pandy]

Float gives only 24 bit accuracy and higher dynamic range - developer is free from thinking about all that scaling problems, range overflow which is in INT domain - but careful 32bit INT is better than 32 bit float (anyway high end audio algorithms use at least 48 bit INT or 64 bit float)

[Sharktooth]

24bit int is what is needed, at least on processing done by ffdshow. im still convinced 32bit float is an overkill and leads to rounding/scaling errors.
since 24bit numbers need to be stored in 32bit integers, then 32bit int is THE choice.

[Dark Shikari]

x264 use (SIMD) features in modern CPU and focus on performance and 8 bit samples

how fast is INT MAC and FP MAC (or rather FMA instruction in FP) on x86 (FMA seems exist only in Itanium family - still waiting for SSE5)On modern CPUs, float add is usually 3/1, float multiply is 4/1 (latency / inv throughput). Int is 1/0.33 and 3/1, respectively.

[pandy]

On modern CPUs, float add is usually 3/1, float multiply is 4/1 (latency / inv throughput). Int is 1/0.33 and 3/1, respectively.

Assume that we talking about 32 bit INT vs 32 bit float (24.8)

[cc979]

if the option is there for 32 bit float output, probably please all

one reason i can think of is if an other dither algorithm is of 'higher' quality than its native one it would be useful

[leeperry]

actually, who cares about 32fp when you can have 32int? 32fp can only transport 23int FWIR.

Pro-audio gear works in 48int (http://akmedia.digidesign.com/support/docs/48_Bit_Mixer_26688.pdf)...The best sounding audio players have a full 64fp pipeline, from the lossy audio decoders/VST plugins to the volume attenuation.

I do a lot of post-processing in ffdshow audio: custom 5.1>stereo downmix matrix, volume attenuation, VST plugins...and the sound is noticeably clearer when I enable 32int processing over 32fp :o

This link (http://mp3decoders.mp3-tech.org/24bit.html) shows that 24int is more accurate than 16int for lossy audio decoding, I'd say that 32int decoding is the next stop...dither it back at the very last stage to 24int and be amazed by the sound clarity.

I'm currently having fun w/ a ffdshow audio patch that allows 32int VST processing...my oh, my oh! The next stop would be to make libavcodec decode AC3/DTS to 32int :eek:

Full 32int audio processing is quite something...like what mVR does for video, nothing less. Higher accuracy + dithering pay in cash in the digital world, madshi knows about that...just like Apogee and Sony w/ their stunning audio dithering algorithms.

[Sharktooth]

That's it. As i said 32bit Int is the way to go (and it's also faster than 32bit FP)

[pandy]

but 32int is not enough sometimes also 32fp is not enough sometimes - so 48/56/64int or fp in audio sometimes can be useful

[leeperry]

exactly, we need 48int in ffdshow :D

[GodofaGap]

but 32int is not enough sometimes also 32fp is not enough sometimes - so 48/56/64int or fp in audio sometimes can be useful
Can you explain when exactly you need 384 dB of dynamic range in an audio signal? (unless you are trying to kill whole countries at once)

[Sharktooth]

32bit INT isnt enough? are you kidding, right?
32FP is WORSE than 32bit INT... and more than 32bits is completely useless since 24 is already enough!

[leeperry]

Can you explain when exactly you need 384 dB of dynamic range in an audio signal?
We're talking about processing accuracy, as explained in this PDF (http://akmedia.digidesign.com/support/docs/48_Bit_Mixer_26688.pdf). The higher it is, the clearer the SQ. I personally think that 32int is enough and 48int overkill...but overkill is nice too.

[Sharktooth]

oh... and BTW, FP is NEVER useful in those kind of processings.

[GodofaGap]

We're talking about processing accuracy, as explained in this PDF (http://akmedia.digidesign.com/support/docs/48_Bit_Mixer_26688.pdf).
Your document does not properly explain/answer my question. There are few cases where one would be able to discern the difference between 16 and 24 bit, and anything with higher dynamic range will simply be unused or lost after dithering/truncating.

I don't really understand the problem here with 32 bit fp in audio, since it's not an uncommon format for DSPs and audio decoding speed is not really a worry since 10 years if not longer. I don't know which format ffdshow uses internally for further audio processing though.

[leeperry]

Your document does not properly explain/answer my question. There are few cases where one would be able to discern the difference between 16 and 24 bit, and anything with higher dynamic range will simply be unused or lost after dithering/truncating.

I don't really understand the problem here with 32 bit fp in audio, since it's not an uncommon format for DSPs and audio decoding speed is not really a worry since 10 years if not longer. I don't know which format ffdshow uses internally for further audio processing though.
There's no "problem" w/ 32fp...but nowadays most VST plugins support 64fp as this is much more precise when doing truckloads of post-processing..

just an example: http://www.dzwiek.org/threads/2956-PSP-oldTimer-nowy-kompresor
VST/AU/RTAS, sample rate do 192kHz internal processing 32/64 FP

http://www.secaudio.ch/side125.html
Hi Resolution 48-bit TDM and 64-bit RTAS "Double Precision" processing for increased clarity

That's it: higher precision provides increased clarity. Ozone4 also works in 64fp internally and can use dithering at the last stage "that reduces quantization distortion with minimal perceived noise" (http://www.izotope.com/products/audio/ozone/__dither.html).

The best stuff I've heard on my PC does processing in 64fp or 32int...Pro gear works in 48int too. A real world experiment in ffdshow I've done is doing a lot of post-processing(5.1>stereo custom downmix matrix/attenuation/several VST plugins in a row) in 32fp/32int + dithering(using Ozone4), and the sound was noticeably clearer in 32int. The only thing missing in ffdshow at this point is getting libavcodec to decode in 32fp/32int instead of 16int(duh), and this might very well be "in the works" ;)

[GodofaGap]

Sorry. I mean I want something that is not marketing BS or a personal anecdote.

[Sharktooth]

one word... audiophiles... those ppl can spend 1000+ $ for a CD player that's exactly the same as a cheap chinese player... but it sports the ultimate Serial DAC or the unfiltered DAC converter or crap like that... all useless things that in short produce INFERIOR audio quality or NO DIFFERENCE AT ALL.
32bit int is way more than enough. PERIOD. FFDShow is not a studio production software... and even if you use it that way 32bit INT will be enough...

[yesgrey]

48/56/64int or fp in audio sometimes can be useful
48 bit only is important in professional audio, because they need to be able to sum lots of 24 bit channels and they want a very high resolution volume control, which is not needed on a very simple processing software like in ffdshow. 32 bit int is much more than we will ever need.

For a detailed technical explanation read this (http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_support_techinfo_hdsp_totalmix_hardware) article from RME site, namely the "Internal" topic.

[leeperry]

I mean I want something that is not marketing BS or a personal anecdote.
oh yah, well, let's ask our friend google then: http://www.google.com/search?hl=en&q=48+bit+audio&aq=f&aqi=&aql=&oq=&gs_rfai=

http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
For uniform unit random numbers as input(that is, random numbers between 0 and 1), there is a difference between the output of the two forms that hits a maximum value of about 0.2%. This is even with using 64-bit floating point! There is no hope for realizing this performance using either 32-bit floating point or 24-bit integer.
Clearly, the performance of 32-bit floating point and 24-bit integer will be considerably inferior to that of 64-bit floating point, so we might conclude that it is not possible to achieve high-quality results
http://www.highbeam.com/doc/1G1-53943401.html
High-precision 48-bit data processing is vital to keeping digital signals clean. We are now able to provide the mastering engineer full control over signal integrity
"Sonic's 48 bit signal path built into the HDSP is a digital audio engineer's dream come true," said Bob Katz, well known digital audio guru and chief mastering engineer at Orlando's Digital Domain

The ppl who buy these are sound engineers(Bob Katz is a very famous mastering engineer), they're no alienated audiophiles who buy $500 coax cables and $300 isolation feet. They need hard proofs and they don't fall for placebo nonsense. 64fp/32int/48int processing pays in cash, it really does :cool:

[GodofaGap]

There is no DSP going on that requires 32 or 48 bits or more after you decode your audio with ffdshow. Your links and quotes don't provide information that they do. 24 int already gives 16 times more precision than needed for playback provided that you'd like to listen the audio at levels that make your ears hurt.

[leeperry]

There is no DSP going on that requires 32 or 48 bits or more after you decode your audio with ffdshow. Your links and quotes don't provide information that they do. 24 int already gives 16 times more precision than needed for playback provided that you'd like to listen the audio at levels that make your ears hurt.
The whole point of such a high accuracy is that you can chain as much DSP as you want(+10 VST plugins if you'd fancy that) and you will still obtain the highest clarity...stop focusing on the dynamic range. This is all well explained in the ProTools PDF.

The links I've provided prove my case, your choice if you want to deny verifiable facts. It's like the 16bit pipeline in madVR dithered to 8bit in the end, would you say that the human brain cannot see that many colors and that the YV12 input stream is 8bit anyway? 8bit YV12 doesn't equal 8bit RGB btw...it's all about reducing "quantization distortion with minimal perceived noise".

If everything I link is commercial bs and/or snake oil, why don't you give it a shot? do a hell lot of processing in ffdshow, try 16int and 32int...if you don't believe hard proofs, maybe you'll trust your ears? provided that you don't run a realtek off cheap headphones/speakers, that is.

You want to decode lossy audio w/ the highest accuracy(32fp in ffdshow), and then use DSP w/ the same highest accuracy(32fp in ffdshow)...and then dither at the very last stage. That's most likely how your best sounding CD's have been mastered. The SQ improvement is nothing to sneeze at, especially considering that's it's a free upgrade...It does what madVR does compared to EVR, it's not a night and day but it provides a clearer experience...Free cookies always taste good IME :p

[kieranrk]

Sorry. I mean I want something that is not marketing BS or a personal anecdote.

http://www.jamminpower.com/PDF/48-bit%20Audio.pdf
http://www.highbeam.com/doc/1G1-53943401.html


Both of those are press releases.

[leeperry]

these too? http://www.google.com/search?hl=en&q=aes+48bit+audio&aq=f&aqi=m1&aql=&oq=&gs_rfai=

http://www.aes.org/e-lib/browse.cfm?elib=8142

AES E-Library

48-Bit Integer Processing Beats 32-Bit Floating Point for Professional Audio: Applications

The emergence of new consumer formats for the delivery of digital audio into the home places ever more pressure on professional systems for maintaining the highest possible audio quality throughout the production process. For a while, it was thought that the 32-bit floating point processors provided a simple and adequate solution to the issues of dynamic range and scaling inherent in professional audio processing. It is clear now that even more precision is required to produce a finished product of 24-bit PCM at sampling rates of 96 kHz to 192 kHz. This paper discusses the differences between fixed point and floating point computation with respect to the audibility of computational error, and makes a case for the use of 48-bit integer processing as the standard by which professional systems should be measured.

http://www.barryrudolph.com/mix/waves.html
L2's internal 48-bit resolution to represent and process the audio signal, even if the input signal is 16-bit. This new, ultraprecise digital signal is then requantized to your desired, selected, final bit depth, be it 16-, 18-, 20-, 22- or 24-bit. Simple truncation of the 48-bit internal signal would result in rounding errors of the digital word and would produce distortion of low-level signals--a loss of resolution of low-level information such as reverb tails, ambience and directional cues that our ears require to reconstruct a mental image of a soundstage. Barry Rudolph is an L.A.-based recording engineer.

A higher bit depth increases the low levels details retention and stereo phase coherence = the sound is audibly clearer :cool:

Anyways, believe what you want...use 16int decoding/DSP if you like. Ffdshow will soon be improved if the 32int libavcodec/winamp2 DSP patches appear to be fully effective, it's all that matters http://forum.slysoft.com/images/smilies/agreed.gif

[Sharktooth]

even 32bit INT beats 32bit FP... however, can we stop this madness?
actually FFDShow uses 32bit FP resolution, if 32bit INT is going to happen we will all be happy.

[leeperry]

libavcodec is 16int-only at this point for AC3/DTS decoding, not 32fp whatsoever...same goes for winamp2/VST plugins. Getting both to use 32int will be a major SQ improvement over 16int...there's no "madness" involved, just easily verifiable facts.

[GodofaGap]

Then provide verifiable facts, not one marketing trick after another. Claims of recording engineers are not by definition facts.

Argh, believe what you want.

[pandy]

32INT can be better than 32FP but on some algorithms 32FP can be better than 32INT - what is better depend from algorithm which is used to process data.

clear example is such "audiophiles" DSP (less than 4$) as a http://www.analog.com/en/audiovideo-products/audio-signal-processors/adau1702/products/product.html or bit more expensive "audiophiles" DSP http://focus.ti.com/docs/prod/folders/print/tas3103a.html
some areas need higher precision than 32INT http://www.analog.com/en/audiovideo-products/audio-signal-processors/ad1940/products/FAQ_When_should_use_double_single_precision_filter/resources/faq.html?display=popup

[leeperry]

Actually you can set AC3Filter to output 32int(I've checked it w/ a bitmeter, its output is not padded 16int: 24bit do get through), then enable 32int processing in ffdshow...and you do get 32int decoding + 32int processing http://forum.slysoft.com/images/smilies/agreed.gif

Too bad my VST>winamp2 DSP plugin wrapper only supports 16int, can't get it all I guess.

The only annoying thing is that you cannot set automatic rules in ffdshow when using AC3Filter, it just does not work (http://sourceforge.net/tracker/index.php?func=detail&aid=2725991&group_id=173941&atid=867360).

It works fine w/ Sonic 4.2, madflac and the built-in decoders, but fails with AC3Filter and the MPC audio decoder. My bug report is +1.5 year old, I guess this will never be fixed http://forum-images.hardware.fr/icones/ohwell.gif

[Kazuya]

I checked up this bug and indeed it do the same for me !

AC3filter decoder > ffdshow audio : the preset 2 channels is loaded for DTS 5.1 !!! :o

[Sharktooth]

32INT can be better than 32FP but on some algorithms 32FP can be better than 32INT - what is better depend from algorithm which is used to process data.

clear example is such "audiophiles" DSP (less than 4$) as a http://www.analog.com/en/audiovideo-products/audio-signal-processors/adau1702/products/product.html or bit more expensive "audiophiles" DSP http://focus.ti.com/docs/prod/folders/print/tas3103a.html
some areas need higher precision than 32INT http://www.analog.com/en/audiovideo-products/audio-signal-processors/ad1940/products/FAQ_When_should_use_double_single_precision_filter/resources/faq.html?display=popup
... but 32bit INT processing has more precision than 32bit FP processing. dont forget that.

[pandy]

... but 32bit INT processing has more precision than 32bit FP processing. dont forget that.

I know that - so 44/64/80 bit FP can be useful in some type of the algorithms. FP is easier to use from programmer point of view, INT need always proper ranging, dealing with headrooms etc.

"First, audio typically use cascaded IIR filters to obtain high performance with minimal
latency., But, in doing so, each filtering stage propagates the errors of previous stages.
So a high degree of precision in both the signal and coefficients are required to minimize
the effects of these propagated errors. Second, signal accuracy must be maintained,
even as it approaches zero (this is necessary because of the sensitivity of the
human ear). The floating-point format by its nature aligns well with the sensitivity of the
human ear and becomes more accurate as floating point numbers approach 0. This is
the result of the exponent’s keeping track of the significant zeros after the binary point
and before the significant data in the mantissa. This is in contrast to a fixed point system
for very small fractional numbers. All of these aspects of floating-point real arithmetic
are essential to the accurate reproduction of audio signals."

http://focus.ti.com/lit/wp/spry061/spry061.pdf

[leeperry]

I checked up this bug and indeed it do the same for me !

AC3filter decoder > ffdshow audio : the preset 2 channels is loaded for DTS 5.1 !!! :o
Yeah, that's because AC3Filter and the MPC audio decoder say stereo when they connect the first time, and then reconnect stating the right number of channels...Sonic 4.2 and madflac don't do that, they give the right number of channels right away :devil:

The root problem is that ffdshow video can automatically switch profiles on the fly, but ffdshow audio cannot...it picks one profile at the initialization, and that's it. So if you need different profiles due to careless decoders, files opened in seamless playback mode or wrongly tagged AC3 files (http://forum.doom9.org/showpost.php?p=1386984&postcount=11208), you're SOL.

I've made a report on the AC3Filter bug tracker, but it hasn't been updated in a year http://forum-images.hardware.fr/icones/ohwell.gif

ah well, nothing ever works the way it should on an HTPC...just need to accept it as a fact.

[clsid]

The AC3Filter dev is often inactive for long periods. The code repo is offline atm, but last time I checked it had commits for 7.1 support.

[leeperry]

AC3filter seems to process some sort of dynamic compression even when you disable DRC in it GUI, kinda weird :o

The SQ is very much different from the two ffdshow decoders...anyway, I'm betatesting a 32int version of this VST/DX>winamp2 wrapper: http://vb-audio.pagesperso-orange.fr/us/products/dxrack/dxrack.htm

http://www.pixelz.fr/2/3/9/9efb0e1855a8d9772d121a2712998tt.jpg (http://www.pixelz.fr/2/3/9/9efb0e1855a8d9772d121a2712998.png)

it seems to work wonderfully in the latest 32int ffdshow beta: 32fp AC3/DTS libavcodec > 32int mixing matrix > 32int VST/winamp2 wrapper > Reclock resampling to 24/96...It all works in full scale 32int, not 24bit padded to 32, the SQ is http://forum-images.hardware.fr/images/perso/kb208.gif

There's far more details audible at very low volume, as those used to be blurred by the 16int rounding errors :devil:

I can make a tutorial to full 32bit audio in ffdshow if anyone cares.

[Wilbert]

I can make a tutorial to full 32bit audio in ffdshow if anyone cares.
Yes, please do!

[leeperry]

Yes, please do!
At my request, sansnom05 has been kind enough to join the ffdshow dev team, apply madshi's patch to make libavcodec output 32fp DTS(instead of 16int) and allow 32int winamp DSP(useful for VST wrappers)...too good to be true, can't thank him enough http://forum-images.hardware.fr/images/perso/prosterne2.gif

His patches work wonders, hopefully they'll make it to the SVN sooner than later.

I plan on making a full tutorial to 32int audio, upmixing/downmixing using the Harman-Kardon Logic7 (http://www.automotive.harmankardon.com/en/innovations/logic7.aspx) mixing matrix coeffs, 32int VST plugins and so.

I'm still strongly impressed by the SQ you can get in 24/96 in ffdshow now...here's a 1 min 24/96 FLAC sample of Darth Vader from The Return Of The Jedi: http://www.mediafire.com/?u7adu3zn3awj2jy http://forum-images.hardware.fr/images/perso/captain%20flam.gif

[mark0077]

So should ffdshow not select 32int over 32float, as currently for me with all output formats selected in ffdshows output tab, ffdshow audio will select 32float above 32int. Given the discussion in this thread, is this now considered a bug / piece of logic that should be fixed.