Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 27th September 2010, 00:36   #12501  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 713
Quote:
Originally Posted by leeperry View Post
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...
kieranrk is offline   Reply With Quote
Old 27th September 2010, 02:11   #12502  |  Link
dansrfe
Registered User
 
Join Date: Jan 2009
Posts: 1,212
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?
dansrfe is offline   Reply With Quote
Old 27th September 2010, 02:15   #12503  |  Link
SamuriHL
Registered User
 
SamuriHL's Avatar
 
Join Date: May 2004
Posts: 3,768
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.
__________________
HTPC1:W10 Creator Edition, I7 3770k, GTX 1060, Pioneer Elite SC-65, Panasonic 65" 1080p Plasma
Laptop: MSI GT70 Dominator
SamuriHL is online now   Reply With Quote
Old 27th September 2010, 03:45   #12504  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,408
Quote:
Originally Posted by dansrfe View Post
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.
Quote:
Originally Posted by kieranrk View Post
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.
leeperry is offline   Reply With Quote
Old 27th September 2010, 04:03   #12505  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,388
Quote:
Originally Posted by dansrfe View Post
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.

Last edited by Midzuki; 27th September 2010 at 04:07. Reason: clarification
Midzuki is offline   Reply With Quote
Old 27th September 2010, 07:00   #12506  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,848
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 27th September 2010, 07:26   #12507  |  Link
Reimar
Registered User
 
Join Date: Jun 2005
Posts: 278
Quote:
Originally Posted by leeperry View Post
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.
Reimar is offline   Reply With Quote
Old 27th September 2010, 07:41   #12508  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 8,858
Quote:
Originally Posted by kieranrk View Post
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 is online now   Reply With Quote
Old 27th September 2010, 07:55   #12509  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 8,858
Quote:
Originally Posted by Reimar View Post
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.
madshi is online now   Reply With Quote
Old 27th September 2010, 08:01   #12510  |  Link
Gleb Egorych
Registered User
 
Join Date: Aug 2008
Posts: 231
I assume it's a known problem: bitrate calculation does not work with libav AAC decoder.
Gleb Egorych is offline   Reply With Quote
Old 27th September 2010, 08:37   #12511  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,848
Quote:
Originally Posted by Reimar View Post
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!

Quote:
Originally Posted by madshi View Post
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 27th September 2010 at 08:40.
nevcairiel is online now   Reply With Quote
Old 27th September 2010, 12:15   #12512  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,408
Quote:
Originally Posted by Reimar View Post
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.

Last edited by leeperry; 27th September 2010 at 12:26.
leeperry is offline   Reply With Quote
Old 27th September 2010, 13:04   #12513  |  Link
Keiyakusha
契約者
 
Keiyakusha's Avatar
 
Join Date: Jun 2008
Posts: 1,567
Quote:
Originally Posted by leeperry View Post
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.
Keiyakusha is offline   Reply With Quote
Old 27th September 2010, 13:13   #12514  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,408
Quote:
Originally Posted by Keiyakusha View Post
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 :/

Last edited by leeperry; 27th September 2010 at 13:16.
leeperry is offline   Reply With Quote
Old 27th September 2010, 13:57   #12515  |  Link
rack04
Registered User
 
Join Date: Mar 2006
Posts: 1,526
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?
rack04 is offline   Reply With Quote
Old 27th September 2010, 14:34   #12516  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,408
Quote:
Originally Posted by rack04 View Post
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.
leeperry is offline   Reply With Quote
Old 27th September 2010, 18:20   #12517  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,307
Quote:
Originally Posted by Keiyakusha View Post
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.

Quote:
Originally Posted by leeperry View Post
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.
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 27th September 2010, 18:28   #12518  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 8,848
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
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 27th September 2010, 18:37   #12519  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 8,858
Quote:
Originally Posted by nevcairiel View Post
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...
madshi is online now   Reply With Quote
Old 27th September 2010, 18:45   #12520  |  Link
Gleb Egorych
Registered User
 
Join Date: Aug 2008
Posts: 231
Does Vista/7 mixer dither audio stream?
Gleb Egorych is offline   Reply With Quote
Reply

Tags
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 20:20.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.