ffdshow tryouts project: Discussion & Development

[kieranrk]

the only reason to go 32fp for lossy audio is this: http://mp3decoders.mp3-tech.org/24bit.html

it provides a more accurate decoding w/ less rounding errors, very important if you down-upmix/resample/post-process/use Reclock. There isn't a single good reason to decode lossy audio to 16int.

Here there be audiophiles...

[dansrfe]

Don't most soundcards handle only 16 bit? I can definitely handle decoding to 32 bit fp but I was under the impression that windows or the soundcard automatically discards all that extra information or "downsizes" to 16 bit upon outputting to the speakers?

[SamuriHL]

No, I don't think so. Commercial Blu-ray players will do that if they don't detect PAP hardware that they support, but, Windows won't downsample by itself.

[leeperry]

Don't most soundcards handle only 16 bit? I can definitely handle decoding to 32 bit fp but I was under the impression that windows or the soundcard automatically discards all that extra information or "downsizes" to 16 bit upon outputting to the speakers?
DirectSound on Vista/W7 works in 32fp, so even w/o Reclock there'll be a SQ improvement...and madshi would explain it better, but it's better to decode lossy audio to 32fp and then use noiseshaping/dithering to 24int than decoding to 16int in the first place.
Here there be audiophiles
any kind of audio post-processing requires 32/64fp to avoid rounding errors(that's how accurate VST plugins are). I personally do a lot of post-processing on AC3/DTS in ffdshow in order to get a binaural stereo downmix.

[Midzuki]

Don't most soundcards handle only 16 bit?

That's a BIG "perhaps". :) OK, I myself do not have reliable statistics on that, but it's a fact that even an outdated frAudigy-2 can accept a 24-bit+96kHz input and transmit this directly to its Digital2Analog Converter. :cool:

[nevcairiel]

Yeah, quite alot of sound cards actually do support 24-bit these days.
And even if they don't, decoding to 32fp and then dithering down to 16bit is far superior to just decoding in 16bit directly.

Not everyone may notice the difference, but there certainly are people that do. And especially when you do alot of post-processing, a 16bit signal can be degraded quite heavily, and you might even hear it yourself.

[Reimar]

the only reason to go 32fp for lossy audio is this: http://mp3decoders.mp3-tech.org/24bit.html

it provides a more accurate decoding w/ less rounding errors, very important if you down-upmix/resample/post-process/use Reclock. There isn't a single good reason to decode lossy audio to 16int.

Are you really sure you understand that linked page? Because that will only work if someone used a MP3 encoder that takes > 16 bit as input and the decoder is somewhat matching. How many people do you think will have such files? Everyone else as soon as they use e.g. dithering to reduce the supposedly 24-bit output to 16 bit will actually reduce the accuracy from 16 to 15 bit (the lowest bit will be replaced by dithering, and the dithering will be based on pure noise, since the encoder did not have more than 16 bit input, anything beyond 16 bit the decoder produces can only be noise).
If someone wanted to do this, they'd have to add a flag indicating the number of bits the MP3 encoder used and then the decoder/ditherer would behave based on that - like this you'd always win, otherwise the loss from 16 -> 15 bit seems more critical to me than the potential e.g. 16 -> 18 bit win.

[madshi]

Here there be audiophiles...
You seem to miss the fact that libav decodes internally to floating point and then ROUNDS the decoded data down to int16. This is a very clear violation of digital processing laws and results in relatively high quantization errors. If libav would dither the floating point decoding results down to int16, you could argue about audiophiles bla bla. But what libav currently does is a middle sized catastrophe for audio quality.

[madshi]

Everyone else as soon as they use e.g. dithering to reduce the supposedly 24-bit output to 16 bit will actually reduce the accuracy from 16 to 15 bit (the lowest bit will be replaced by dithering, and the dithering will be based on pure noise
Incorrect. Dithering does not *replace* the lowest bit. You clearly don't understand how dithering works.

[Gleb Egorych]

I assume it's a known problem: bitrate calculation does not work with libav AAC decoder.

[nevcairiel]

Are you really sure you understand that linked page?

You clearly do not understand how decoding lossy audio works (nor the linked page, which clearly specifys how it works). The decoding process should produce as many bits of data as it can, and that does not depend on the bitdepth of the original source!

You seem to miss the fact that libav decodes internally to floating point and then ROUNDS the decoded data down to int16. This is a very clear violation of digital processing laws and results in relatively high quantization errors. If libav would dither the floating point decoding results down to int16, you could argue about audiophiles bla bla. But what libav currently does is a middle sized catastrophe for audio quality.

Actually i think the default internal MP3 decoder in libav is pure integer (and int16 at that), but yes, thats true for most other formats.

[leeperry]

Are you really sure you understand that linked page? Because that will only work if someone used a MP3 encoder that takes > 16 bit as input and the decoder is somewhat matching.
There's no bitdepth in lossy audio, and the higher it is at the decoding stage the closer you will be to the lossless integer source.

There's no point in decoding lossy audio in anything else than 32fp. You're making a truckload of rounding errors in 16int...There's a good reason if all the audio software always post-process in 32/64fp: avoiding useless rounding errors. Even media players such as foobar decode mp3 in 32fp, and so do liba52 and libdts...why not libavcodec? :(

I've been whining about it since forever, but apparently the libavcodec ppl don't care...maybe STaRGaZeR could hook us up w/ 32fp DTS, I don't care much for AC3 as liba52 sounds great(in 32fp at that) but I really don't like libdts...it sounds metallic, I very much prefer libavcodec.

[Keiyakusha]

the only reason to go 32fp for lossy audio is this: http://mp3decoders.mp3-tech.org/24bit.html

it provides a more accurate decoding w/ less rounding errors, very important if you down-upmix/resample/post-process/use Reclock. There isn't a single good reason to decode lossy audio to 16int.

Well if 32bit will be slower - I will be able to measure this. But speaking of quality, I'm sure me and all of my friends with different kind of hardware from cheaper to more expensive won't notice any difference between rounded 16bit and 32bit. In other words, all I care about is speed, everything else comes after that.

[leeperry]

if 32bit will be slower - I will be able to measure this. But speaking of quality, I'm sure me and all of my friends with different kind of hardware from cheaper to more expensive won't notice any difference between rounded 16bit and 32bit.
it wouldn't make a difference, even on a Pentium IV...actually, 32fp should be faster I think.

Don't be so sure that 32fp doesn't many an audible diff over 16int...especially if you're using DirectSound or Reclock resampling.

Anyway, STaRGaZeR didn't confirm whether he could fix DTS in libavcodec...libmad already does 32fp MP3 and liba52 32fp AC3.

I also wish the winamp2 DSP plugins in ffdshow were not converted to 16int both ways(I use a VST plugins wrapper), as 24int is entirely possible :/

[rack04]

How does ffdshow determine which output format, i.e. 16 bit int, 24 bit int, 32 bit int, or 32 bit fp if all the boxes on the output tab are checked?

[leeperry]

How does ffdshow determine which output format, i.e. 16 bit int, 24 bit int, 32 bit int, or 32 bit fp if all the boxes on the output tab are checked?
if the decoder outputs 32fp natively and if you have 32fp checked in ffdshow's output, it will be automatically picked over the others.

[STaRGaZeR]

STaRGaZeR
Just a little suggestion. I never saw floating-point build yet but if it will work, could you please keep both variants (16 and 32 bit) if 32bit any slower? Maybe it will be possible to add switch "libavcodec (16bit)" and "libavcodec (32bit)" like it is done for h264 in case of libavcodec and ffmpeg-mt. Also if you know better solution - just skip this post. Thanks.

Do you have a Pentium II or similar? If not, you should forget about the speed argument.

maybe STaRGaZeR could hook us up w/ 32fp DTS, I don't care much for AC3 as liba52 sounds great(in 32fp at that) but I really don't like libdts...it sounds metallic, I very much prefer libavcodec.

Nope, unless there is a strong negative from ffmpeg against this, in that case I'll consider it. Custom code sucks.

Reimar, since you're a ffmpeg developer, could you consider adding an option to bypass the float to int16 conversion you have at the end of your decoders? Easy, cheap and everybody is happy.

[nevcairiel]

Custom code only sucks when you use subversion trying to manage it .. what you do .. :P
Don't blame code for your version control shortcomings, imho :D

Anyhow, the patch to enable 32fp decoding of DTS is pretty short, but its more then a one line change to disable the downconversion.
Maybe one of the ffmpeg guys could shed some light on the reasons why its downconverting everything to int16 anyway

[madshi]

Maybe one of the ffmpeg guys could shed some light on the reasons why its downconverting everything to int16 anyway
An eternity ago I had asked both Benjamin Larsson (DTS) and Justin Ruggles (AC3 + E-AC3) about that and IIRC both said that native bitdepth output was planned for a future libav version. But that was ages ago. I had sent my eac3to patches to both of them, but neither was willing to apply them. So I keep on patching libav, year after year... :(

[Gleb Egorych]

Does Vista/7 mixer dither audio stream?

[STaRGaZeR]

Custom code only sucks when you use subversion trying to manage it .. what you do .. :P
Don't blame code for your version control shortcomings, imho :D

Custom code sucks the same on git, IMHO :D

[nevcairiel]

But keeping in sync with the upstream repository is trivial! :)

[STaRGaZeR]

I don't know git, but it can't be worse than svn :D

To all, please test r3602. Things to test:

a) Audio channel mapping is fine for 5.1 streams and above. Fine means the same as in previous revisions.
b) Yadif works fine. Please test on CPUs without SSSE3, SSE2 and MMX2, or any combination of them. If your CPU has SSE2 but no SSSE3 for example, test it. Fine means it doesn't crash and the speed is the same as before or within margin of error.

Build: http://www.mediafire.com/?l90nft4ccgam2o4

And to the devs, mplayer now only contains mp3lib, which is IMO not needed at all, with libavcodec and libmad. We can remove it and libmplayer will be gone.

[leeperry]

unless there is a strong negative from ffmpeg against this, in that case I'll consider it.
Put simply, they don't seem to care :o

And sorry to beat a dead horse(I know, that's my speciality :D), but would you have any idea how to enable PCM24/32 for winamp DSP plugins? the input/output is currently downconverted to 16int, which is a major bummer as there's many DX/VST plugins wrappers...and ffdshow is the perfect place for this kind of job :devil:

You can see tons of "int16_t"/"SF_PCM16" in those sections:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/audioFilters/winamp2/Twinamp2.cpp?view=markup&pathrev=1928
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/audioFilters/TaudioFilterWinamp2.h?revision=1609&view=markup&pathrev=1928

winamp2 DSP plugins work in PCM24/32 using the foobar wrapper: http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components_0.9/Winamp_DSP_Bridge_(foo_dsp_winamp)
16-bit: low quality, failsafe. Choose this setting, if you encounter a problem while playback;
24-bit: hi-quality;
32-bit: highest quality.

I asked its author for help but he told me that the ffdshow code was quite messy and that he had no time to work on it :(

Christian Budde(a professional VST plugin coder) helped Haruhiko to iron out a few bugs in the winamp DSP plugins host code of ffdshow, and confirmed that PCM24/32 were entirely possible w/ winamp2 DSP plugins.

If anyone's interested, I could make a complete tutorial to VST awesomeness in ffdshow...including upmix/downmix matrixes based on Lexicon's Logic7 routines. The key is to calibrate their coefficients to your gear/brain. Its author, David Griesinger, is the living god of audio DSP for hometheater use.

After a bit of work, you can make very convincing stereo downmixes(very short FLAC samples):
http://www.mediafire.com/download.php?hzgj3fsco1gqsbf
http://www.mediafire.com/download.php?xrfcj9rm2od453k

b) Yadif works fine. Please test on CPUs without SSSE3, SSE2 and MMX2, or any combination of them. If your CPU has SSE2 but no SSSE3 for example, test it. Fine means it doesn't crash and the speed is the same as before or within margin of error.
I'm a noob at deinterlacing, but YADIF always gives me tons of combing...I was trying it on a 29.97fps NTSC source yesterday, and bingo still a combo feast. It works wonderfully in double frame rate mode, though...but it's not too handy in 89.91Hz.

One thing I've never understood about double frame rate deinterlacing is that it looks like frame interpolation...It really looks as if I were watching a 59.94fps source, when it should actually be 29.97*2 :confused:

A friend of mine is completely hooked to 1080i*2 on his projector, he finds the picture WAY smoother.

[kieranrk]

One thing I've never understood about double frame rate deinterlacing is that it looks like frame interpolation...It really looks as if I were watching a 59.94fps source, when it should actually be 29.97*2 :confused:

A friend of mine is completely hooked to 1080i*2 on his projector, he finds the picture WAY smoother.

Double frame rate is the *right* way to do it. That's what true interlaced looks like if you were watching it on a CRT. Just because there's a lot of 24/25/30p misuse out there and that many people are used to watching web video (or pirated video) at a max of 30p doesn't suddenly mean it's right.

[kieranrk]

There's no point in decoding lossy audio in anything else than 32fp.

Why not use 64fp (doubles); in fact why not use 128fp (long double); don't forget you're losing quality at each stage...

[leeperry]

Double frame rate is the *right* way to do it. That's what true interlaced looks like if you were watching it on a CRT. Just because there's a lot of 24/25/30p misuse out there and that many people are used to watching web video (or pirated video) at a max of 30p doesn't suddenly mean it's right.
I know what 24fps looks like, same goes for 25 and 29.97....29.97 double frame rate deinterlace looks like 29.97 interpolated to 59.94 to my eyes. Trimension DNM all the way.
Why not use 64fp (doubles); in fact why not use 128fp (long double); don't forget you're losing quality at each stage...
my favorite audio player(Lilith) decodes all lossy audio in 64fp, and so are its volume attenuator and VST plugins pipeline. SQ is amazing.

http://thumbnails22.imagebam.com/6979/c05f0669780253.gif (http://www.imagebam.com/image/c05f0669780253)

But right now, libavcodec DTS and VST plugins are stuck to 16int in ffdshow :(

[kieranrk]

I know what 24fps looks like, same goes for 25 and 29.97....29.97 double frame rate deinterlace looks like 29.97 interpolated to 59.94 to my eyes. Trimension DNM all the way.

my favorite audio player(Lilith) decodes all lossy audio in 64fp, and so are its volume attenuator and VST plugins pipeline. SQ is amazing.

http://thumbnails22.imagebam.com/6979/c05f0669780253.gif (http://www.imagebam.com/image/c05f0669780253)

But right now, libavcodec DTS and VST plugins are stuck to 16int in ffdshow :(

Clearly you don't understand the difference between interlace and progressive then....

I'm glad you enjoy your 64-bit double placebo. The rest of us live in reality.

[leeperry]

they took a 29.97fps progressive source, once properly deinterlaced it should be reconstructed to 29.97 progressive...no need for frame interpolation. anyway, I don't care for interlaced stuff...I have a bunch of poorly authored DVD's using it, that's all.

oh yes, placebo...good thing I didn't tell you about software induced jitter (http://www.cicsmemoryplayer.com/index.php?n=CMP.03Jitter), I don't think you'd be ready for that just yet.

and in case you were wondering, you can measure it (http://www.phasure.com/index.php?topic=692.0) too...so much for placebo.

even a 11yo girl can hear the difference (http://www.audioasylum.com/forums/pcaudio/messages/2/21586.html), but she has better hearing than you and I.

foobar's volume attenuator also works in 64fp, just like all the pro-audio software....anyway, my original point was that 16int for lossy audio decoding and post-processing butchers the SQ.

[_xxl]

And to the devs, mplayer now only contains mp3lib, which is IMO not needed at all, with libavcodec and libmad. We can remove it and libmplayer will be gone.
Remove it. It is hard to maintain.

[STaRGaZeR]

I'm a noob at deinterlacing, but YADIF always gives me tons of combing...I was trying it on a 29.97fps NTSC source yesterday, and bingo still a combo feast. It works wonderfully in double frame rate mode, though...but it's not too handy in 89.91Hz.

One thing I've never understood about double frame rate deinterlacing is that it looks like frame interpolation...It really looks as if I were watching a 59.94fps source, when it should actually be 29.97*2 :confused:

A friend of mine is completely hooked to 1080i*2 on his projector, he finds the picture WAY smoother.

First, please do not parrot your feature request/bug fixes/whatever each time you have the chance. It's annoying, and this is not the first time I tell you this.

Second, you should really learn what interlaced video is. If you have 29,97fps pure interlaced content you have 59,94fps of temporal information there. Outputting 29,97fps is an abortion, but needed in some cases. That's why deinterlacers have that option.

Remove it. It is hard to maintain.

OK. What about theora? It hasn't been included in the installer for quite some time, why is still there?

[Astrophizz]

That XXHighEnd developer and the people that buy into his overpriced software sound a bit loony to me. You can still measure something with a sensitive device and yet not be able to sense a difference and so you would be subject to a placebo effect. I could point out the differences in spectral patterns of two stars to determine that one is of slightly different composition, but I could never see the difference with my eyes.

[leeperry]

You can still measure something with a sensitive device and yet not be able to sense a difference and so you would be subject to a placebo effect. I could point out the differences in spectral patterns of two stars to determine that one is of slightly different composition, but I could never see the difference with my eyes.
Of course, many FREE audio engines provide the same sort of low jitter(cMP/Reclock/Lilith)...I couldn't care less about XXHighEnd myself. Did you compare all the media players, do they sound the same to you? Jitter is real, and far from placebo.
this is not the first time I tell you this.
If you had a bugtracker anyone cared about, this wouldn't be happening...bumping bugfixes requests is the only chance to see anything happening(just like MPC).

I've asked three very skilled audio plugins coders for help and they've all told me that the ffdshow audio code was a bug feast(full of syntax errors and beginners mistakes) and a huge mess...so I guess this is not going to change anytime soon. They were even wondering how it could be working at all :confused:

ffdshow is a lost cause for studio grade audio, atm it's just a toy to watch movies in WMP...sorry for rubbing it in http://t0.gstatic.com/images?q=tbn:0qtMKZwl3EPf5M

[fastplayer]

OK. What about theora? It hasn't been included in the installer for quite some time, why is still there?
clsid disabled it some time ago in the hope that someone would update it. IIRC the current version in the trunk is hopelessly outdated.

[nm]

I'm a noob at deinterlacing, but YADIF always gives me tons of combing...I was trying it on a 29.97fps NTSC source yesterday, and bingo still a combo feast. It works wonderfully in double frame rate mode, though...

I haven't seen yadif leaving residual combing in neither single nor double-rate mode if the spatial deinterlacing check is enabled (not skipped, modes 0 and 1 in the MPlayer implementation). Do you have a sample clip?

[leeperry]

I haven't seen yadif leaving residual combing in neither single nor double-rate mode if the spatial deinterlacing check is enabled (not skipped, modes 0 and 1 in the MPlayer implementation). Do you have a sample clip?
I didn't have it disabled, I'll try to come up w/ a sample.

so videos shot interlaced actually have 59.94fps, great! that would explain why my friend is so hooked to 1080i concerts on his projector...but I believe he also likes 1080i movies, that can't possibly have more than 24fps AFAIK(IVTC put aside).

[_xxl]

OK. What about theora? It hasn't been included in the installer for quite some time, why is still there?

If you can update it ok. If not remove it.

x264 should be updated to latest, I can t update it anymore....

[Reimar]

An eternity ago I had asked both Benjamin Larsson (DTS) and Justin Ruggles (AC3 + E-AC3) about that and IIRC both said that native bitdepth output was planned for a future libav version. But that was ages ago. I had sent my eac3to patches to both of them, but neither was willing to apply them. So I keep on patching libav, year after year... :(

I think some were changed. The biggest issue is that the format conversion inside the codec uses some tricks to be a lot faster, particularly on systems with slow FPU like ARM. Just removing them would mean that FFmpeg would get a lot slower on these systems.
And for FFmpeg speed (even on non-mainstream platforms) is most important than output resolution.
But if someone sends a patch to fix this issue, there'd probably no objections to changing the output format.

[madshi]

I think some were changed. The biggest issue is that the format conversion inside the codec uses some tricks to be a lot faster, particularly on systems with slow FPU like ARM. Just removing them would mean that FFmpeg would get a lot slower on these systems.
And for FFmpeg speed (even on non-mainstream platforms) is most important than output resolution.
I understand. I'm just wondering why there isn't a simple (compile time) configuration switch for activating "native" output. I did try to get such a switch added to the (E-)AC3 and DTS decoders, but my patches were declined.

[Reimar]

Everyone else as soon as they use e.g. dithering to reduce the supposedly 24-bit output to 16 bit will actually reduce the accuracy from 16 to 15 bit (the lowest bit will be replaced by dithering, and the dithering will be based on pure noise
Incorrect. Dithering does not *replace* the lowest bit. You clearly don't understand how dithering works.

Bad choice of words maybe. But to clarify: If you take a 16 bit input, add random bits to expand it to 24 bit and then dither that to 16 bit the dithering will have added noise. If the encoder never had more than 16 bit to start with, anything more than 16 bit in the decoded output can't be much more than noise (I guess this is not 100% true since the encoder can "expand" the input data to more than 16 bit by knowing how audio data is "supposed" to look).

[madshi]

If you take a 16 bit input, add random bits to expand it to 24 bit
What are you talking about? I don't think anybody is doing that.

If the encoder never had more than 16 bit to start with, anything more than 16 bit in the decoded output can't be much more than noise
I'm not really sure if you understand how lossy encoding/decoding works. Look, the encoder gets samples in the time domain, but encoding is done in the frequency domain (for lossy formats). After conversion to frequency domain, you end up with floating point data with full precision. The precision is not limited to 16bit here, because the conversion to frequency domain is a complex mathematical process. In the next step the encoder compresses the frequency domain audio data. Later, when you decode that, you again get floating point frequency data back. This will not be identical to the input data, of course, since the encoder is lossy. The decoder converts the frequency data back to time domain, which means that you end up with *full precision* floating point time domain data. Because of that you cannot say that only 16bit contain data and the rest is noise. That doesn't make any sense. The native output of a lossy decoder is usually *full precision* floating point. This data will only be an approximation of the original input data, but still it is full precision. You can't say that the data is only 16bit and the rest is noise. That's not true. After decoding, the data is floating point, not 16bit. The decoder doesn't even *try* to reproduce the original 16bit PCM data. Instead the decoder tries to reproduce an approximation of the original frequencies. And it does so in full floating point precision. Of course the decoding result will never sound better than the 16bit original, though, because it's only an approximation.

[clsid]

I am OK with removing Theora and mp3lib.

[kieranrk]

But if someone sends a patch to fix this issue, there'd probably no objections to changing the output format.

I would suggest including float output in ENABLE_AUDIOPHILE_KIDDY_MODE (which already exists).

[nevcairiel]

I would suggest including float output in ENABLE_AUDIOPHILE_KIDDY_MODE (which already exists).

You realize that it already decodes in full floating point? All we basically ask for is to move the conversion to int16 from the decoder to ffdshow. If you're happy with int16, it wouldn't change much for you at all, but if you're not, you can select another bitdepth for output, and you get higher quality.

No downsides, just added value. Why are you arguing?

[leeperry]

I would suggest including float output in ENABLE_AUDIOPHILE_KIDDY_MODE (which already exists).
A troll is a troll, but troll feeding can be fun sometimes.

madVR brings world class PQ, and ffdshow sub-par consumer SQ...you're watching your videos in YV12 OVERLAY point resize on an ATi I presume http://forum-images.hardware.fr/images/perso/smoking.gif

All it needs is a few fixes, it will not worsen the SQ...at worst, it'll sound the same to your ears. Point of the matter is that either the few active coders don't care(libavcodec) or can't fix it due to an unmanageably messy code(ffdshow audio) so it's a lost cause. WYSIWYG.

[madshi]

Why are you arguing?
Because he evidently does not understand the basic laws of digital audio processing.

[kieranrk]

Because he evidently does not understand the basic laws of digital audio processing.

Having written a decoder for a perceptual audio format (with floating point transforms) I can tell you that's not the case.

All I'm saying is that the people arguing for float output because of "higher quality" are wrong. It is also laughable to see leeperry's talk of 64bit float - I can guarantee the decoder from the audio codec is 16-bit int or possibly 32-bit float at most. As reimar said the encoder had most likely 16-bit input in the first place so insisting on float producing a higher quality is an invalid argument. The LSBs of audio are generally noise anyway.

Feel free to also add the slowest but "highest quality" DCTs for mpeg-2 video and other codecs while you're at it. Also rewrite ffmpeg's MDCT to use 64-bit float since it "only" uses 32-bit float.

[madshi]

Having written a decoder for a perceptual audio format (with floating point transforms) I can tell you that's not the case.
Then you do know that every time you reduce audio bitdepth, you have to apply dithering, if you don't want to introduce quantization noise. Do you know that, or do you not? Are you aware that libav violates this basic processing law, or are you not aware of that?

All I'm saying is that the people arguing for float output because of "higher quality" are wrong.
No, they are right. Because of the simple reason that libav currently does not *dither* down to 16bit, but they *round* down the internal float32 decoding data to 16bit int. Which is a violation of audio processing laws and adds quantization noise. If libav correctly dithered down to 16bit, there would be little point to ask for floating point output. Not for ffdshow, at least.

[kieranrk]

...

Read what Reimar said.

[leeperry]

It is also laughable to see leeperry's talk of 64bit float - I can guarantee the decoder from the audio codec is 16-bit int or possibly 32-bit float at most.
http://www.sonicspot.com/lame/history.html
found bugs in some sections when using 32 bit floating point. Default is now back to 64bit floating point.
Lilith decodes MP3 in 64fp and processes attenuation/VST plugins in 64fp as well...just like any serious pro-audio app. The higher the resolution, the less distorted the tiny details and phase coherence will be.

Reclock provides 53bit volume attenuation and bit-perfect float/integer conversions(they all pass the HDCD flag and were looked over by WingFeather -a pro VST plugin coder from diyaudio.com-, James and yesgrey).

I use a low jitter 24/96 transport w/ Reclock via a bit-perfect audio renderer, and my two bottlenecks are libavcodec for DTS and the VST plugins processed in 16int...Some call it parroting, I call it uncalled for and a damn shame as the chain is only as strong as its weakest link. But nothing ever works the way it should thanks to Murphy's Law, so that's no big deal.