ffdshow tryouts project: Discussion & Development

[kieranrk]

Originally Posted by leeperry

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]

Originally Posted by 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?

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.

Originally Posted by kieranrk

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]

Originally Posted by dansrfe

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.

[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]

Originally Posted by leeperry

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]

Originally Posted by kieranrk

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]

Originally Posted by 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.

[Gleb Egorych]

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

[nevcairiel]

Originally Posted by Reimar

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!

Originally Posted by madshi

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]

Originally Posted by Reimar

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]

Originally Posted by leeperry

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]

Originally Posted by Keiyakusha

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]

Originally Posted by 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?

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]

Originally Posted by Keiyakusha

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.

Originally Posted by leeperry

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

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]

Originally Posted by nevcairiel

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?