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.

[leeperry]

it automatically selects 32fp when using liba52/libdts because that's their native output format.

[leeperry]

BTW, I've often read ppl saying that the AC3/DTS decoders in ffdshow sounded too flat compared to AC3Filter...I've run many tests, and so did a friend of mine...we came to the conclusion that AC3Filter does some hidden loudness maximizing/DRC. It's very obvious when comparing DTS and FLAC(using madFlac) :devil:

The author even wrote a PDF about it: loudness_eng.pdf (http://ac3filter.net/files/docs/ac3filter_1_30b/loudness_eng.pdf)

It's based on libdts, and when running A/B comparisons against libdts in ffdshow the sound is far more punchy and less dynamic. It's very impressive for a day or two(especially on headphones), but then it gets odd IMHO. And I highly doubt that it does genuine 32int AC3/DTS, more like 32fp>32int. Libavcodec's DTS in 32fp(using madshi's patch) sounds great anyway, and so does liba52.

[tetsuo55]

It kind-off looks like a realtime replaygain from skimming through it.

Its probably best to (from now on), provide waveform comparisons for all the claims of better/lower quality.

[kieranrk]

Its probably best to (from now on), provide waveform comparisons for all the claims of better/lower quality.

Waveform comparisons are meaningless.

[leeperry]

ok, I've created a 24/48 -0.1dB 1kHz sinewave test tone, then encoded it to AC3 w/ eac3to. All the files are available here (http://www.mediafire.com/?8td4t5yfwt93903).
clearly liba52 is attenuated by -3dB(0.5bit) in ffdshow(using the latest SVN): http://thumbnails26.imagebam.com/11190/2ea21d111890461.jpg (http://www.imagebam.com/image/2ea21d111890461) http://thumbnails29.imagebam.com/11190/67c431111890470.jpg (http://www.imagebam.com/image/67c431111890470) http://thumbnails28.imagebam.com/11190/60b6f7111890475.jpg (http://www.imagebam.com/image/60b6f7111890475)

[leeperry]

now for the DTS test, files available here (http://www.mediafire.com/?pclx43codbtu710).

Kazuya used the Surcode encoder and couldn't get it to encode to stereo w/ eac3to, but anyway I've set a custom mixing matrix in ffdshow to only use the stereo front channels w/ a 1.0 coeff(in 32int).

I've compared AC3Filter and ffdshow using libdts/16int libavcodec/32fp libavcodec:
http://thumbnails26.imagebam.com/11192/1f7c36111911741.jpg (http://www.imagebam.com/image/1f7c36111911741)http://thumbnails31.imagebam.com/11192/6fc9a6111911744.jpg (http://www.imagebam.com/image/6fc9a6111911744)http://thumbnails26.imagebam.com/11192/0e83f8111911751.jpg (http://www.imagebam.com/image/0e83f8111911751)http://thumbnails36.imagebam.com/11192/4d3728111911754.jpg (http://www.imagebam.com/image/4d3728111911754)

AC3Filter clips to death :devil:

Here are my AC3F settings:
http://thumbnails25.imagebam.com/11192/bf0010111912206.jpg (http://www.imagebam.com/image/bf0010111912206)http://thumbnails30.imagebam.com/11192/1dd6d0111912212.jpg (http://www.imagebam.com/image/1dd6d0111912212)http://thumbnails37.imagebam.com/11192/de6635111912223.jpg (http://www.imagebam.com/image/de6635111912223)
http://thumbnails32.imagebam.com/11192/104e3c111912227.jpg (http://www.imagebam.com/image/104e3c111912227)http://thumbnails24.imagebam.com/11192/d34171111912237.jpg (http://www.imagebam.com/image/d34171111912237)http://thumbnails24.imagebam.com/11192/dfbe97111912253.jpg (http://www.imagebam.com/image/dfbe97111912253)

[leeperry]

ok, running more tests on a 5.1 DTS movie sample (http://www.mediafire.com/?dbm1mz5qeluyj7s), processed in 32int in ffdshow(96kHz libavcodec upsampling > 0.46 attenuation > stereo custom downmix matrix).

comparing AC3F(32fp)/libdts(32fp)/libavcodec(32fp):
http://thumbnails29.imagebam.com/11192/cf323c111917603.jpg (http://www.imagebam.com/image/cf323c111917603)http://thumbnails35.imagebam.com/11192/f97cde111917585.jpg (http://www.imagebam.com/image/f97cde111917585)http://thumbnails25.imagebam.com/11192/e0de8b111917597.jpg (http://www.imagebam.com/image/e0de8b111917597)

AC3F does a +3dB amplification, and I had it all set to "1.0" coeff in its GUI.

The loudness curves are identical...still ACFilter will clip anything that's louder than -3dB :devil: :
http://thumbnails34.imagebam.com/11192/666e95111917094.jpg (http://www.imagebam.com/image/666e95111917094)http://thumbnails33.imagebam.com/11192/447710111917097.jpg (http://www.imagebam.com/image/447710111917097)http://thumbnails30.imagebam.com/11192/6f27f5111917102.jpg (http://www.imagebam.com/image/6f27f5111917102)

[leeperry]

OK, so that's my -0.1dB AC3 sample in AC3Filter alone(no ffdshow):
http://thumbnails29.imagebam.com/11193/08a614111925011.jpg (http://www.imagebam.com/image/08a614111925011)http://thumbnails34.imagebam.com/11193/3c6e01111925018.jpg (http://www.imagebam.com/image/3c6e01111925018)http://thumbnails28.imagebam.com/11193/668d12111925022.jpg (http://www.imagebam.com/image/668d12111925022)

and now for the -0.1dB DTS file in AC3Filter(no ffdshow): http://thumbnails4.imagebam.com/11193/5c8599111925293.jpg (http://www.imagebam.com/image/5c8599111925293)http://thumbnails23.imagebam.com/11193/b9e550111925304.jpg (http://www.imagebam.com/image/b9e550111925304)http://thumbnails34.imagebam.com/11193/fef92d111925318.jpg (http://www.imagebam.com/image/fef92d111925318)http://thumbnails35.imagebam.com/11193/581efc111925325.jpg (http://www.imagebam.com/image/581efc111925325)

so basically AC3Filter amplifies DTS by +3dB, this is clearly not acceptable and will lead to clipping on loud sequences.

It would be nice if someone could fix the bogus -3dB attenuation done on liba52 in ffdshow ;)

[leeperry]

Been doing more tests w/ the 32int winamp2 DSP plugin ffdshow patch: http://thumbnails24.imagebam.com/11194/fe4402111930259.jpg (http://www.imagebam.com/image/fe4402111930259)
I've got it all checked in the ffdshow output options: http://thumbnails36.imagebam.com/11194/1a00dd111930263.jpg (http://www.imagebam.com/image/1a00dd111930263)
Reclock does see 32int: http://thumbnails29.imagebam.com/11194/5e3e70111930269.jpg (http://www.imagebam.com/image/5e3e70111930269)
On a -0.1dB test tone, Wavelab's bit-meter confirms that indeed 24bit are in use: http://thumbnails29.imagebam.com/11194/1cd6f7111931297.jpg (http://www.imagebam.com/image/1cd6f7111931297)
and so does Ozone4's bit-meter: http://thumbnails35.imagebam.com/11194/c4d473111933863.jpg (http://www.imagebam.com/image/c4d473111933863) http://thumbnails28.imagebam.com/11194/ce8eef111933869.jpg (http://www.imagebam.com/image/ce8eef111933869)

It would have been nice to go 32fp in order to avoid several useless int>fp conversions, but the official winamp2 DSP plugin SDK only supports 16int..it can be hacked to 32int, but 32fp isn't possible(both Vincent Burel & sansnom05 have confirmed it). Anyway, it's still a far cry from the nasty roundings you get w/ 16int :devil:

There isn't that many plugins that support 32int(most remain silent, as only 16int is officially supported), but the most important ones do work perfectly fine(you can always whine to your favorite plugin coder to have him accept BPS32 input on top of BPS16):
-Christian Budde's VST plugin wrapper (http://www.savioursofsoul.de/Christian/programs/winamp/)
-Vincent Burel's FFX-4 (http://vb-audio.pagesperso-orange.fr/us/products/dxrack/dxrack.htm)(DX plugin wrapper)
-OzoneMP (http://www.google.com/url?q=http://www.winamp.com/plugin/izotope-ozone/79374&sa=U&ei=QAcRTb_BEcek8QOow7SEBw&ved=0CAwQFjAA&usg=AFQjCNFD7v4EJSoPZLqmO-CUygpW8ZWhvA)

Hopefully, sansnom05 will be kind enough to commit this patch soon http://forum-images.hardware.fr/images/perso/otakonleboss.gif

[tetsuo55]

Hey Leeperry, i can confiirm the liba52 -3DB problem, but i do not seem to notice it with mpc-hc's internal AC3 decoder (which is also liba52), can you check for me?

[leeperry]

so I've used the standalone MPC audio decoder from this package (http://www.xvidvideo.ru/component/docman/doc_download/5010-standalonefilters-142797x86-msvc2008.html), and set it to 32int.

liba52 is not attenuated like in ffdshow: http://thumbnails30.imagebam.com/11206/6c3a16112053980.jpg (http://www.imagebam.com/image/6c3a16112053980)
24bit are in use: http://thumbnails26.imagebam.com/11206/d98152112053985.jpg (http://www.imagebam.com/image/d98152112053985)

but MPC's DTS decoder is attenuated by -0.5dB(unlike ffdshow): http://thumbnails30.imagebam.com/11206/529db6112053994.jpg (http://www.imagebam.com/image/529db6112053994)
24bit are also in use, though: http://thumbnails30.imagebam.com/11206/1075e0112054002.jpg (http://www.imagebam.com/image/1075e0112054002)

[leeperry]

apparently the liba52 -3dB attenuation in ffdshow doesn't occur on all channels, meaning that it will also temper w/ custom mixing matrixes and standalone receivers calibration. Some channels will be dimmer than when using DTS/FLAC.

I'll have to make a -0.1dB 7.1 test tone in eac3to and check the level of each and every channel in AC3/DTS/FLAC...that would explain why the same stereo downmixing matrix doesn't give me the same results on AC3 and DTS/FLAC.

[clsid]

Does it only happen with liba52? Or also with libavcodec/libdts? Does it also occur when the Mixer is disabled?

[leeperry]

I had the mixer disabled on that stereo AC3 file, liba52 > 32int, nothing more...and it was -3dB attenuated as you can see.

I will run more tests w/ a -0.1dB 7.1 test tone using madFlac/liba52 and 32fp libavcodec DTS. These are my 3 favorite decoders, I will have to calibrate them using the ffdshow volume filter to make them all output -0.1dB on all channels. There's no point in calibrating your speakers/headphones stereo downmix matrix if decoders aren't outputting the right levels in the first place.

[leeperry]

ok, I just made the -0.1dB 7.1 test tone (http://www.mediafire.com/?cuin8rgcxf4y3ug) in dBpoweramp: http://thumbnails33.imagebam.com/11209/0278ec112081402.jpg (http://www.imagebam.com/image/0278ec112081402)http://thumbnails35.imagebam.com/11209/651e12112081396.jpg (http://www.imagebam.com/image/651e12112081396)

more results tomorrow. I'll prolly have to revert to 5.1 for AC3(eac3to can't encode to 7.1) and libavcodec/libdts might not support 7.1 either.

[leeperry]

tests I plan on conducting:
-checking whether the ffdshow built-in FLAC decoder is limited to 16int..urban legend? reality?
-checking if all channels output as -0.1dB w/:
-7.1 FLAC: ffdshow built-in decoder, madFlac
-5.1 AC3: ffdshow built-in 32fp liba52/32fp libavcodec(the coeffs seem wrong)/16int libavcodec, MPC audio decoder, AC3Filter, Sonic 4.2
-5.1 DTS: ffdshow built-in libdts/libavcodec, MPC audio decoder, AC3Filter, Sonic 4.2

I'm dubious about Sonic because it works exactly as I want in ffdshow(automatic profiles), but AC3 sounds very DRC'ed..and many ppl have stated that you can't disable SRC in Sonic. OTOH, eac3to can use it and the CRC is identical to Arcsoft on DTS-HD :confused:

PS: weird I was upsampling a WMV w/ libavcodec, my media player crashed and DrWatson says that it was because of ff_samplerate(libsamplerate) :confused:

I will delete it from now on, together w/ the other DLL's I don't need(theora and so). I use an ICL12 VS2010 build on XPSP3.

[leeperry]

ok, so I've used 2 songs, one 16/44.1 and the other 24/96. I had to remux to MKV to use ffdshow's built-in FLAC decoder, considering it doesn't have a source filter(unlike madFlac).

left side is madFlac, right side is ffdshow's libavcodec.

16/44.1: http://thumbnails35.imagebam.com/11216/ac4512112155709.jpg (http://www.imagebam.com/image/ac4512112155709) http://thumbnails24.imagebam.com/11216/cf8ed8112155707.jpg (http://www.imagebam.com/image/cf8ed8112155707)
24/96: http://thumbnails25.imagebam.com/11216/0a3129112155719.jpg (http://www.imagebam.com/image/0a3129112155719) http://thumbnails36.imagebam.com/11216/d55a10112155714.jpg (http://www.imagebam.com/image/d55a10112155714)

so unlike all that's been said, ffdshow *can* decode 24bit FLAC...but maybe not 7.1, I shall try and check the output volume of all channels later on.

[tetsuo55]

Just to be sure: none of those open source decoders support DTS-ES(6.1) and DTS 96/24 right?

[leeperry]

I don't think so.

From some preliminary tests, the first five channels are indeed -0.1dB when using liba52 in ffdshow(LFE can't be tested as it seems limited to 80Hz)...but on a stereo AC3 stream they're attenuated by -3dB. I might need to try all possible combinations..mono/stereo/3/4/5 channels to nail it down.

And the built-in ffdshow FLAC decoder can also decode 7.1 24bit...so madFlac isn't needed anymore for FLAC within a container.

[leeperry]

I'm struggling a bit w/ the LFE in AC3/DTS :o

in AC3, it's limited to -35dB(capped to 80Hz), but in DTS it's EMPTY. Apparently, it's normal behavior: http://www.hometheaterhifi.com/volume_7_2/feature-article-misunderstood-lfe-channel-april-2000.html
DTS's LFE channel is a little different. In fact, in the cinema, DTS is actually 5.0 (as oppose to 5.1) in that there is no discrete LFE channel. The LFE channel from the mixing sessions gets low-passed at 80 Hz and added to the surround channels. In the theater, the surround channels are high-passed at 80 Hz with the reciprocal becoming the LFE channel. The reasons for this multiplexing is one of space. DTS's original encoder only handles full-bandwidth channels so a discrete LFE channel would require a full 20% more space on the medium (the disc) as if it were another full range channel.

so I can't isolate and measure the volume level of the discrete LFE channel...considering it does not exist :rolleyes:

[leeperry]

alright! doing a 60Hz test tone for DTS does the trick, I do get sound on the phantom LFE channel...anyways:

madFlac, -0.1dB 1kHz 7.1 24/48:
L: -0.1dB
C: -0.1dB
R: -0.1dB
SL: -0.1dB
SR: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -0.1dB

ffdshow's built-in libavcodec FLAC decoder, -0.1dB 1kHz 7.1 24/48:
L: -0.1dB
C: -0.1dB
R: -0.1dB
SL: -0.1dB
SR: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -0.1dB

ffdshow's built-in libavcodec FLAC decoder, -0.1dB 1kHz 5.1 24/48:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -0.1dB

ffdshow's built-in libavcodec FLAC decoder, -0.1dB 1kHz 5.1 24/48:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -0.1dB

ffdshow's built-in 32fp liba52 AC3 decoder, -0.1dB 1kHz 5.1 48kHz 640kbit AC3:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -35dB

ffdshow's built-in 16int libavcodec AC3 decoder, -0.1dB 1kHz 5.1 48kHz 640kbit AC3:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -35dB

ffdshow's built-in 32fp libavcodec DTS decoder, -0.1dB 60Hz 5.1 48kHz 1.5Mbit DTS:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -1.2dB

ffdshow's built-in 32fp libdts DTS decoder, -0.1dB 5.1 60Hz 48kHz 1.5Mbit DTS:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -1.2dB

AC3Filter:

32fp, -0.1dB 1kHz 5.1 48kHz 640kbit AC3:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -35dB

32fp, -0.1dB 5.1 60Hz 48kHz 1.5Mbit DTS:
L: -0dB (requires 0.99 coeff to reach -0.1dB)
C: -0dB (requires 0.99 coeff to reach -0.1dB)
R: -0dB (requires 0.99 coeff to reach -0.1dB)
BL: -0dB (requires 0.99 coeff to reach -0.1dB)
BR: -0dB (requires 0.99 coeff to reach -0.1dB)
LFE: -1.2dB
My AC3Filter settings: http://thumbnails29.imagebam.com/11222/32f1b8112214834.jpg (http://www.imagebam.com/image/32f1b8112214834) http://thumbnails33.imagebam.com/11222/457c41112214838.jpg (http://www.imagebam.com/image/457c41112214838) http://thumbnails20.imagebam.com/11222/c4d5e8112214840.jpg (http://www.imagebam.com/image/c4d5e8112214840)

Sonic 4.2.2:

-0.1dB 1kHz 5.1 48kHz 640kbit AC3:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -36dB

16int, -0.1dB 1kHz stereo 48kHz 640kbit AC3:
L: -0.1dB
R: -0.1dB

-0.1dB 5.1 60Hz 48kHz 1.5Mbit DTS:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -0dB (requires 0.99 coeff to reach -0.1dB, but it should be -1.2dB)

PowerDVD 10:

-0.1dB 1kHz 5.1 48kHz 640kbit AC3:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -35dB

-0.1dB 5.1 60Hz 48kHz 1.5Mbit DTS:
L: -0.6dB
C: -0.6dB
R: -0.6dB
BL: -0.6dB
BR: -0.6dB
LFE: -0dB (requires 0.99 coeff to reach -0.1dB)

MPC Audio Decoder:

32fp, -0.1dB 1kHz 5.1 48kHz 640kbit AC3:
L: -0.1dB
C: -0.1dB
R: -0.1dB
BL: -0.1dB
BR: -0.1dB
LFE: -35dB

32fp, -0.1dB 5.1 60Hz 48kHz 1.5Mbit DTS:
L: -0.6dB
C: -0.6dB
R: -0.6dB
BL: -0.6dB
BR: -0.6dB
LFE: -1.2dB

conclusions:
-AC3Filter always clips DTS(except the phantom LFE channel), whatever stereo or 5.1
-Sonic 4.22/PDVD decoder output a louder LFE than the GPL decoders
-MPC's audio decoder attenuates stereo and 5.1 DTS by -0.5dB

I shall run more tests on stereo DTS, and using 1/2/3/4/5/6 channels AC3 using ffdshow's liba52.

[tetsuo55]

unsettling results.

So there is a bug in MPC-HC.

Could you please try MP3, AAC and COOK ?
In my samples i have to put those 3 audio types on i have to lower my audio with 10 points.
So AC3/DTS on 40 points, and those 3 on 25-30 points.

[leeperry]

why not, but right now I'm more focused on my own use within ffdshow :)

I've added measurements for PDVD10 on AC3/DTS, and it clips the LFE just like Sonic 4.22. The DTS file was encoded using the Surcode encoder...I find it kinda weird that the GPL decoders output a dimmer phantom LFE than commercial decoders. If Arcsoft didn't install so much bloat, I'd give it a shot.

[leeperry]

It seems that "dialog normalization" is enforced on stereo AC3 when using liba52 in ffdshow: http://everything2.com/title/Dolby+Digital+vs.+DTS
DD uses a feature called 'dialogue normalisation' which usually reduces overall volume by 3dB, in an effort to standardise volume across all Dolby software

And apparently, this is more of a headache than it seems:
Using a 1kHz test tone a 0.6dB difference was found between the DD and DTS encoders. The studio is said to have reported this to DTS, who then "updated the code in the unit," removing the gain.

It's still not too clear to me what the LFE volume should be between AC3/DTS: http://www.hometheaterhifi.com/technical-articles/163-the-misunderstood-01-lfe-channel-in-51-digital-surround-sound.html
DTS's LFE channel in consumer applications, unlike its cinema counterpart, is discrete but still has a few 'special' considerations. In the early days of mixing 5.1 for DTS CDs, the studios were not being calibrated correctly, with the end result of the LFE channel being set too low. When the material is played back on a correctly calibrated system, the LFE channel is way too high. THX was forced to introduce DTS Music and DTS Movie playback modes which distinguish between a correct LFE setting and a -10 dB setting to compensate for material assembled under mis-calibrated circumstances
Production facilities know that unless they provide a dedicated two channel soundtrack, nothing important should be exclusively put in the LFE channel: Depending on the playback system, it may not be heard.

[tebasuna51]

- To make a proper ac3 decoder test first you need encode your sample with:

Dialog Normalization: -31 dB
Dynamic Range Compression: none
RF overmodulation protection: none
Digital deemphasis: none
DC high-pass filter: none
Bandwidth low-pass filter: none
LFE low-pass filter: none
90 Degree phase shift: none
3 dB attenuation: none

Then you avoid any Preprocessing issue of the encoder or any Postprocessing issue of the decoder and can compare the source with the decoder output. You can use Aften encoder, all disabled by default.

The LFE -35 dB problem is clearly a effect of the LFE low-pass filter, enabled by default in some encoders, when you use a 1KHz sample. Also the low bitrate assigned to LFE channel can produce problems with samplerates > 100Hz (use 60 Hz al least in LFE Channel)

- About DTS decoders:
I don't know how disable LFE low-pass filter in DTS encoders, BTW you are using 60 Hz already.
Yes, seems there are a different output with LFE volume between commercial decoders (tested ArcSoft) and free decoders (tested libav and NicAudio, I found -1.8 dB)
The Ac3Filter DTS decoder clip the output to +3dB (try with -3dB in Master Gain and you can see like all the channels (not LFE) reach your -0.1 dB source volume without clip)

- About phantom LFE channel.
Maybe you mistake the subwoofer speaker with the LFE channel. All receivers/amplifiers/soft-decoders can extract the low frequencies from all the channels and send to subwoofer, don't matter if LFE is empty or not. This is your phantom LFE channel?

[leeperry]

thanks for the insights!

Is there any free AC3 encoder where I could set the Dialog Normalization to -31 dB? My sample was emcoded in eac3to from a plain 24/48 5.1 FLAC(made w/ dBpoweramp).

tbh I'm able to "fix" any volume output by myself using the custom mixing matrix of ffdshow, I'm just wondering if when using a -0.1dB test tone, they're all supposed to be -0.1dB when using DTS? Sonic/PDVD clip the LFE in my tests, and libdts/libavcodec play it at -1.2dB

Also, there's a lot of confusion about the LFE channel in AC3...but I guess I'd need a proper test tone before drawing conclusions. Life is easier w/ lossless soundtracks :o

[tebasuna51]

eac3to uses Aften and always encode with Dialog Normalization to -31 dB and all other options to none.

I can't test Sonic/PDVD, with ArcSoft I get -1 dB and -3 dB with free decoders.

[leeperry]

OK, I guess I'd need to look up some DTS decoding white paper...the Sonic decoder was meant to be used w/ their DVD authoring software for soft proofing, it also decodes DTS-HD and so...I find it hard to believe that they'd have goofed up on the coeffs.

Both commercial/freeware decoders agree on the -35dB of my AC3 sample so I'm more confident. I've put it here (http://www.mediafire.com/?aekc3k6mxbzhssa) in case you could get it through Arcsoft. My DTS sample is available there (http://www.mediafire.com/?iyfap0vyydekqzy).

[leeperry]

been doing more tests, 32int is nice and all...but lossy audio decodes to 32fp and Reclock converts to 32fp prior to resampling...and each int<>fp conversion is very lossy FWIR.

The optimal ffdshow-audio pipeline seems to be: 32fp lossy decoding > 32fp processing(possibly using 96/192kHz upsampling to increase the accuracy of the trebles (http://www.gearslutz.com/board/5101666-post296.html) beforehand?) > 32fp VST plugins > 32fp Reclock resampling > 24/96 KS/WASAPI output.

http://www.pixelz.fr/6/7/7/51a90b7114ab8616cfae3eea4f138tt.jpg (http://www.pixelz.fr/6/7/7/51a90b7114ab8616cfae3eea4f138.png)

I shall write a guide to all this anytime soon if there's any interest. I also need to clear up the license scheme of FFX-4 w/ Vincent Burel. But 32fp VST in ffdshow is very much real(thank you so much sansnom05http://forum-images.hardware.fr/images/perso/mzarella.gif) and it sounds spectacular http://forum-images.hardware.fr/images/perso/fumble.gif

[TheLion]

been doing more tests, 32int is nice and all...but lossy audio decodes to 32fp and Reclock converts to 32fp prior to resampling...and each int<>fp conversion is very lossy FWIR.

The optimal ffdshow-audio pipeline seems to be: 32fp lossy decoding > 32fp processing(possibly using 96/192kHz upsampling to increase the accuracy of the trebles (http://www.gearslutz.com/board/5101666-post296.html) beforehand?) > 32fp VST plugins > 32fp Reclock resampling > 24/96 KS/WASAPI output.

http://www.pixelz.fr/6/7/7/51a90b7114ab8616cfae3eea4f138tt.jpg (http://www.pixelz.fr/6/7/7/51a90b7114ab8616cfae3eea4f138.png)

I shall write a guide to all this anytime soon if there's any interest. I also need to clear up the license scheme of FFX-4 w/ Vincent Burel. But 32fp VST in ffdshow is very much real(thank you so much sansnom05http://forum-images.hardware.fr/images/perso/mzarella.gif) and it sounds spectacular http://forum-images.hardware.fr/images/perso/fumble.gif

That's great. I would appreciate it very much if you could provide a guide.
Please allow for two questions: Which version of ffdshow are you using and is it a special build that allows for 32bit VST processing or is it part of the latest revisions anyway?

Which pipeline would you suggest for lossless audio decoding (flac in mkv container transcoded from DTS-HD MA/TrueHD) together with VST and reclock?

Thank you very much for all your efforts!

[leeperry]

Which version of ffdshow are you using and is it a special build that allows for 32bit VST processing or is it part of the latest revisions anyway?
I currently use a beta build that adds 32fp off libavcodec(using madshi's patch), DTS is fine but 2 channels are swapped in AC3...this issue is being looked into.

liba52 is nice(and output 32fp as well), but it mistakenly forces -3dB "dialog normalization" attenuation on stereo AC3 in ffdshow...libavcodec doesn't.

The winamp 32bit patch has made it to the SVN...it supports both 32int and 32fp, depending on what you've set in the general ffdshow post-processing bit depth settting.

Which pipeline would you suggest for lossless audio decoding (flac in mkv container transcoded from DTS-HD MA/TrueHD) together with VST and reclock?
decoding > 32fp processing > 32fp to Reclock > 24int rendering via KS/WASAPI.

[bur]

While browsing through the ffdshow settings I came across these 16/24/32 bit output options. With my onboard sound chip I'm pretty sure I won't hear any difference whatsoever but I'd still like to know which setting would THEORETICALLY be able to produce the best results on a 24 bit chip. Is it better to use 24 bit ffdshow output in that case?

Also is FP worse than INT in most cases? If all options are checked ffdshow seems to default to 32fp though.

Simply put, if wasting processing power doesn't matter - which output option should I choose?

[mindbomb]

you should use lav audio, as it always chooses the best option.

[bur]

LAV also chooses 32bit FP ... so is this the best choice under some circumstances?

And offtopic, I noticed LAV outputs 6 channel ac3 as 6 channel pcm but I only have stereo speakers. I guess DirectSound takes care of that or the sound chip? Are there any disadvantages compared to ffdshow that outputs directly as 2-channel?

[clsid]

Enable everything in ffdshow that your card supports and it will automatically use the best one. Usually that means using the same format that the decoder outputs.

[bur]

In my case that's 32bit FP. I was just wondering because of this post:

32FP is WORSE than 32bit INT

[nevcairiel]

32-bit int might have a few more bits to code the actual data, however, if the decoder outputs 32-fp, converting it to 32bit int will not improve anything!
I'm not aware of any decoder that actually natively deals with 32bit INT. PCM Lossless decoders are toping out at 24-bit int, and lossy decoders will either give you 16 int or 32fp

[bur]

Ok so I can just have ffdshow make the choice. Will it be better to prevent 32bit from being chosen since the soundchip supports 24bit only?

[mindbomb]

no. assuming you are using directsound, windows will convert it to the default format, which is 16 bit or 24 bit. you actually can set this in the control panel.

[leeperry]

DS works in 32fp in Vista/W7 AFAIK.

[bur]

no. assuming you are using directsound, windows will convert it to the default format, which is 16 bit or 24 bit.So there's no disadvantage by this conversion? Will there be any advantage of having ffdshow output 32bit only to have DS convert it to 24bit?

I'm just wondering, normally you'd think, if the soundcard is 24 bit anyway, then having the decoder output 32bit data will yield nothing but might have an (if ever so slight) impact on performance.

[Mitchan81]

been doing more tests, 32int is nice and all...but lossy audio decodes to 32fp and Reclock converts to 32fp prior to resampling...and each int<>fp conversion is very lossy FWIR.

The optimal ffdshow-audio pipeline seems to be: 32fp lossy decoding > 32fp processing(possibly using 96/192kHz upsampling to increase the accuracy of the trebles (http://www.gearslutz.com/board/5101666-post296.html) beforehand?) > 32fp VST plugins > 32fp Reclock resampling > 24/96 KS/WASAPI output.


I shall write a guide to all this anytime soon if there's any interest. I also need to clear up the license scheme of FFX-4 w/ Vincent Burel. But 32fp VST in ffdshow is very much real(thank you so much sansnom05http://forum-images.hardware.fr/images/perso/mzarella.gif) and it sounds spectacular http://forum-images.hardware.fr/images/perso/fumble.gif

thx for all

now i'm waiting for your guide :p

[jaytrinitron]

So obviously this thread is over 5.5 years old but it's the only thing I could find while googling. I still use ffdshow's audio processor to mix my surround and stereo tracks into ffdshow's headphone spatialization. If my audio decoder decodes a 16int or 24int track into pcm and then passes it to ffdshow, and my sound card can handle 16int or 24int output from ffdshow, what should I use for ffdshow's processing and mixing, keeping in mind that at the end of mixing the output has to be converted to either 16int or 24int? My options for ffdshow processing are 16int, 32int, or 32fp. Furthermore, should I have ffdshow output 16int or 24int for best quality? What is the combination of formats for processing and output for best quality overall?