truehd and ffdshow and reclock question

[mindbomb]

lets say I have a 24 bit truehd file.
FFdshow decodes it and outputs it as 32 bit int.
reclock takes the 32 bit int and converts it to 24 bit padded to 32 bit.

How does this end product compare to the original 24 bit truehd file? is it equivalent?

[leeperry]

if I were you, I'd output 24int off ffdshow as Reclock cannot know that you're feeding 24bit padded to 32.

[bjd]

if I were you, I'd output 24int off ffdshow as Reclock cannot know that you're feeding 24bit padded to 32.

That makes sense, but the only way to do this is just to select 24bit output. Now does this output 24bit or 16bit padded to 24bit?

Because if you select 16bit as well, ffdshow only outputs 16bit

My understanding was 32bit had to be selected as an output in ffdshow to get at least 24bit, meaning you would have to run Re-clock in "bit exact" mode to get untouched 24bit padded to 32bit ouput to the soundcard and assume the soundcard ignores the last padded 8bits.

[leeperry]

check 16 and 24bit in ffdshow's output settings, it'll automatically pick the right one depending on the native bitdepth.

[bjd]

Lee,

That seems to work ok on rev3721 although pretty sure it never used to on older builds.

[bjd]

That seems to work ok on rev3721 although pretty sure it never used to on older builds.

That was achieved by passing 24bit from Madflac through ffdshow, however truehd decoded by libavcodec always defaults to 16bit unless 32bit is ticked, presumably because libavcodec only outputs 16 & 32 bit.

[leeperry]

That was achieved by passing 24bit from Madflac through ffdshow, however truehd decoded by libavcodec always defaults to 16bit unless 32bit is ticked, presumably because libavcodec only outputs 16 & 32 bit.
that's easy to test...check 16/24/32int and uncheck them one by one, once you get a sound cut that means it's the natively decoded bitdepth. You can also double-check in the Reclock panel and in ffdshow's "Info & CPU" section what's being output when they're all checked.

[bjd]

Ok, it's possible i was testing with a 16bit TrueHD stream

[Qaq]

How about 32fp from DD, DTS and 32int from libmad?

[mindbomb]

Ok, it's possible i was testing with a 16bit TrueHD stream

i thought the decoder's output would be constant regardless of the file's bit depth.

[bjd]

How about 32fp from DD, DTS and 32int from libmad?

No issues outputting 32fp for mp3/ac3/dts if right decoder is selected in ffdshow

[dansrfe]

http://forum.doom9.org/showthread.php?p=1367141#post1367141

[leeperry]

hah! better go FLAC then, because whatever you do Reclock will never know that it's being fed 24int padded to 32 and not plain 32int...bitperfect will be a no-go IMHO.

[leeperry]

52 pages of chit-chat on HD audio (http://forum.doom9.org/showthread.php?t=151151) and the damn thing can't decode bit-perfect TrueHD w/o padding to 32int, hence confusing audio renderers when outputting PCM24 and forcing to process lossy conversions from 32int to 32fp when post-processing...they call it sarcasm where I come from http://forum-images.hardware.fr/images/perso/1/chewee297.gif

[mindbomb]

i see.

but the 32 bit to 24 bit padded to 32 bit is still a better option than using just plain 16 bit all the way through, correct?

[Qaq]

No issues outputting 32fp for mp3/ac3/dts if right decoder is selected in ffdshow
Ok, just wanted to remind that right output formats should be selected also. IMO we just have to keep them all selected to get stream from all of these libdts, liba52, libmad, libav etc as accurate as possible. I do (but prefer bitstream, yeap).

[leeperry]

but the 32 bit to 24 bit padded to 32 bit is still a better option than using just plain 16 bit all the way through, correct?
depends, compare them and let us know...it'll depend on how the audio renderer will react, as I'll be converting from PCM32 when the 8 LSB are actually empty.

they prolly enforced it to please some failtastic Realtek drivers(embedded on AMD graphic cards), I think some of them only work when padding 24bit to 32....now, they need to realize that not only AMD users want to decode TrueHD :rolleyes:

[mindbomb]

so in a scenario where the 24 bit truehd file is actually a 16 bit padded to 24 bit, ffdshow can actually decode it to 16 bits and reclock could do that bitperfectly?

but when you tick the 32 bit int output option, you basically just lose quality in this case cause of the 32 bit to 24 bit conversion?

[bjd]

that's easy to test...check 16/24/32int and uncheck them one by one, once you get a sound cut that means it's the natively decoded bitdepth. You can also double-check in the Reclock panel and in ffdshow's "Info & CPU" section what's being output when they're all checked.

Have tryed this with several truehd streams and sound cuts as soon as 32bit INT is deselected, so I am 99% convinced the truehd codec outputs either 16bit or 32bit. There is no way to pass 24bit TrueHD from ffdshow without resorting to selecting 32bit output with 8bit LSB.

By keeping the format and sample rate the same in ReClock, I can pass 32bit int from ffdshow bit exact through reclock no problem and hope the soundcard just truncates the last 8 bits. However I would also like to output 32fp from ffdshow -> relclock and let reclock resample this to 24bit (for the soundcard) and you can't do both.

Sadly it is not possible to use the Arcsoft TrueHD decoder which does ouput 24bit (TMT 3.185) unless you feed it a non interleaved truehd stream. That means your container must be either an .evo file (no interleave, a non Solveig MKV or a .m2ts file demuxed by Arcsoft demuxer which removes the AC3 stream first. The Mpc-Hc MPEG splitter does not do this and so cannot be used to decode TrueHD with the Arcsoft decoder.

[nevcairiel]

ffmpeg has no 24-bit sample format. It does have 16 bit, and 32 bit, and an extra parameter to indicate how many bits in the decoded sample are actually significant. I don't know how ffdshow works there, but the ffmpeg TrueHD decoder does ouput 32-bit samples with the appropriate mark to indicate that only 24-bit are actually valid in case of a 24-bit truehd file.

So it would be possible to do it properly, if/why ffdshow does not manage it, i don't know (and ffdshow code is way too weird for me to check)

[bjd]

but the ffmpeg TrueHD decoder does ouput 32-bit samples with the appropriate mark to indicate that only 24-bit are actually valid in case of a 24-bit truehd file.

So if ReClock could detect this in 32bit int PCM and treat as 24bit, then this would solve the issue I guess, if the ffdshow output logic isn't likely be fixed.

[mindbomb]

wait, to go back to what leeperry said, what exactly is happening when you force 24 bit output in ffdshow?
It seems like it could solve this problem

[bjd]

libavcodec 16bit padded to 24bit is used.

For the moment I will just alternate between 32bit (if i need TrueHD/MLP) and 24bit output (everything else) through relcock to the soundcard . Having thought about it more, my Auzentech Meridian processes up 32bit, but I imagine rather than ignoring the 8LSB, i think resample to 32bit FP for volume level and any DSP effects, so I don't think it will make that much difference.

[mindbomb]

so how do we know that reclock can't recognize that the 32 bit int from ffdshow is padded?

and a related question, if all these decoders work in float internally, then isn't there inherently always going to be quality loss from the float to int conversion? (im guessing no)

im very confused about this, it seems that sometimes you change formats and it is fine, and sometimes it isn't.

[nevcairiel]

1)
If ffdshow claims that its sending 32-bit data, you can only guess if its padded, you don't know if there might be significant data coming in the next sample, or the one after.

2)
Float is basically 23 bits of significant data (plus some bits in the exponent), so when converted to 24-bit int, you should keep most information. Of course its no lossless process, but it should be good enough to not have any audible quantization errors.

The "best" format is int32, it has full 32 bits of significant data, but there really aren't that many fixed-point decoders, or real 32-bit audio tracks, so the format is very rarely used. Anyone happen to have a TrueHD or FLAC 32bit track?

In general, avoiding any conversion between sample format is of course the best strategy.

On a related note on the whole topic:

Since i've been fed up with ffdshows weird behaviour, and the lacking quality of MPC-HCs internal decoders, i wrote a new audio decoder this weekend based on ffmpeg. It'll always output the preferred sample format based on what the ffmpeg decoder outputs. It successfully detects 24-bit TrueHD and extracts them out of the 32-bit ffmpeg samples. What i have to do next is teach ffmpeg to actually output the 32fp data from the lossy decoders, which is a codec-by-codec job, but i already got my hands on patches for aac, ac3 and dts. The whole decoder focuses on providing the untouched audio from the decoder, so it won't have any post-processing tools*, and preferrably output the samples the way the came out of the decoder. For compatibility, i'll add some code to requantize the audio to more "compatible" formats like 16bit int and 24bit int for people that don't use ReClock or another audio post-processing filter - of course everything optionally.

Keep an eye on the LAVFSplitter thread, i'll probably rename the project slightly and make it a complete decoding chain, LAVFSplitter, LAVCAudio, and who knows if some day it'll be joined by a LAVCVideo.

* If people insist on post-processing, they can use ffdshow in raw mode.

[leeperry]

oh yah, 32fp AC3/DTS off libavcodec would be sweet. madshi has provided a patch to that in the eac3to package.

@mindbomb: you might as well ask Reclock's coder what his software does when it's being fed 24bit padded to 32.

[STaRGaZeR]

Keep an eye on the LAVFSplitter thread, i'll probably rename the project slightly and make it a complete decoding chain, LAVFSplitter, LAVCAudio, and who knows if some day it'll be joined by a LAVCVideo.

Looking forward to see what comes out of this.

[mindbomb]

@mindbomb: you might as well ask Reclock's coder what his software does when it's being fed 24bit padded to 32.

well, i just realized that you can't get bit exact status when feeding reclock 32 bit pcm and outputing 24 bit padded. So i guess that answers my question.



and im definitely excited about lavcaudio.

[bjd]

Since i've been fed up with ffdshows weird behaviour, and the lacking quality of MPC-HCs internal decoders, i wrote a new audio decoder this weekend based on ffmpeg. It'll always output the preferred sample format based on what the ffmpeg decoder outputs. It successfully detects 24-bit TrueHD and extracts them out of the 32-bit ffmpeg samples. What i have to do next is teach ffmpeg to actually output the 32fp data from the lossy decoders, which is a codec-by-codec job, but i already got my hands on patches for aac, ac3 and dts.

Can we expect 32bit int Mp3 decoding ?

[clsid]

@leeperry
Send me madshi's patch and I can apply it to ffdshow svn.

[leeperry]

sansnom05 has already applied it in a beta build he sent me, it works fine for DTS but two channels(BackR and LFE) are swapped for AC3. he doesn't have time to look into it atm.

[nevcairiel]

Can we expect 32bit int Mp3 decoding ?

I can enable it in ffmpeg, but its disabled by default and does not offer a configuration option, so i'm not sure if it works.

I'll of course test it.
If anything, we'll have 32fp decoding of MP3.

[bjd]

If anything, we'll have 32fp decoding of MP3

That's what I have set ATM from ffdshow. Just remember you saying in another thread that the 32bit Int is better

[nevcairiel]

It is, but i just don't know if it works properly in ffmpeg. But i'll test that.
MP3 is one of the few decoders that actually have a full integer decoder, most other lossy decoders are internally all float, so we won't be getting 32bit int out of them.

[clsid]

sansnom05 has already applied it in a beta build he sent me, it works fine for DTS but two channels(BackR and LFE) are swapped for AC3. he doesn't have time to look into it atm.If it works properly for DTS, then just the DTS part of the patch could be committed now.

[Qaq]

AFAIR, madshi's patches are described (code & comments) in eac3to package. Can't say more.

[Dstruct]

It is, but i just don't know if it works properly in ffmpeg. But i'll test that.
MP3 is one of the few decoders that actually have a full integer decoder, most other lossy decoders are internally all float, so we won't be getting 32bit int out of them.

But what about MP3s that have levels higher than 0dBFS? With floating point decoding you can lower the volume without loosing the >0dBFS content.

This wouldn't work with integer decoding I guess ...

[nevcairiel]

But what about MP3s that have levels higher than 0dBFS? With floating point decoding you can lower the volume without loosing the >0dBFS content.

This wouldn't work with integer decoding I guess ...

I guess thats true. A float can basically store any value, and you will never run into "clipping", you just lose precision in the lower bits eventually.

Float can also better represent very small values. A 32bit FP value always has 23 bits of significant data, this data can be veeery close to 0 as well, because any leading zeros in the actual value are stored in the exponent.

This can make 32-bit FP better for processing then 32-bit Integers. I think at this point, its basically depandant on the algorithm you want to use for processing, and whatnot.

I tested mp3 fp32 decoding, and its working fine. I'll test int32 decoding as well, and possibly offer a checkbox to switch it eventually.

[leeperry]

MP3 is one of the few decoders that actually have a full integer decoder, most other lossy decoders are internally all float
maybe it's due to madshi's patch, but w/ the beta build of ffdshow sansnom05 provided me w/, stereo mp3 decodes to 32int w/ libmad and 32fp w/ libavcodec.

[bjd]

maybe it's due to madshi's patch, but w/ the beta build of ffdshow sansnom05 provided me w/, stereo mp3 decodes to 32int w/ libmad and 32fp w/ libavcodec.

I was under the impression the MAD decoder uses 32bit INT internally and outputs to 24bit, so you could be getting 24/32 padded.

Personally I prefer the sound from 32fp from libavcodec -> reclock

[nevcairiel]

maybe it's due to madshi's patch, but w/ the beta build of ffdshow sansnom05 provided me w/, stereo mp3 decodes to 32int w/ libmad and 32fp w/ libavcodec.

madshis patch does not modify mp3 decoding at all, because its already working in 32fp without any patches.

Its only for ac3/dts to output 32fp (which it decodes in anyway, but converts to 16int before output), and it changes something else in the TrueHD decoder .. what exactly i'm not sure yet, i need to look at the diffs again.

But anyway, ffdshow is just configured that way. It uses the floating point mp3 decoder in avcodec, not the integer decoder. The integer decoder by default works in 16int, but there is a flag to switch it to 32int - but like i said, i don't know if that works properly.

[leeperry]

Oh ok, well VST plugins and Reclock only accept 32fp, so it's prolly better to stick to it in my case...32int<>32fp conversions sound a bit harsh I think, especially when done several times in a row. The SQ seems higher when I stick to 32fp until Reclock.