TrueHD bitdepth

[eheart144]

The Haali Media Splitter doesn't "export" the TrueHD track. And even if it did, we'd still need the Nero Audio Decoder for TrueHD decoding. Haali's Media Splitter isn't decoding, of course, it's only splitting.

One thing I just found out is confusing me quite a lot:

The TrueHD track I was testing (Vendetta) is supposed to be 48kHz 16bit. The Nero Audio Decoder always outputs 24bit. Ok, so I thought I could simply convert that to 16bit without any loss. However, I've just checked: If I convert the 24bit Nero output to 16bit and then back to 24bit, the result is different to the original. It seems that there's more than 16bit real information in the Nero output. But the TrueHD track is only 16bit! I don't quite understand this. My only explanation would be that the Nero audio decoder does some processing on the decoded data, e.g. volume adjustment or something like that. That's kind of bad, though, since that means that converting to 16bit may end up harming the audio quality. But keeping 24bit *significantly* increases the final FLAC file size. Arghh.......

[tebasuna51]

The TrueHD track I was testing (Vendetta) is supposed to be 48kHz 16bit.
How do you know than the track bitdepth is 16 bit?

The Nero Audio Decoder always outputs 24bit. Ok, so I thought I could simply convert that to 16bit without any loss. However, I've just checked: If I convert the 24bit Nero output to 16bit and then back to 24bit, the result is different to the original.
How do you convert 16 bit to 24 bit?
Some conversors can include noise in less significant bits.

Use eac3to to decode TrueHD, the decoders libav/nero always output 24 bits, but eac3to check the less significant bits and, when these bits are always 0, convert 24 -> 16 bits without losse quality.

[doom-nine]

Use eac3to to decode TrueHD, the decoders libav/nero always output 24 bits, but eac3to check the less significant bits and, when these bits are always 0, convert 24 -> 16 bits without losse quality.
Is there any way that eac3to can decode the orginal audio file to the original depth, say, decode the 16bits TrueHD or ac3 to 16bits wav files?
I know there's an option for eac3to like "-down16" that defines the output depth. I think this option is not lossless, is it?

[TDiTP_]

Is there any way that eac3to can decode the orginal audio file to the original depth, say, decode the 16bits TrueHD
You need only:
eac3to input.thd output.wavs
it's all. And that's madshi says:
The bitdepth is simply not known before the processing. The information about the bitdepth is not contained anywhere in the TrueHD track. eac3to has no other choice than to fully decode the full track and check the bitdepth of every single audio sample (of which there are usually 48000 for every second of the runtime). If all 24bit audio samples have 8bits zeroed out, eac3to will state that it's a 16bit track only and will remove the 24bit file. There's nothing else I can do.

...
All TrueHD tracks are stored in 24bit. Some of those may be zero. eac3to shows the true bitdepth after having decoded a TrueHD track.
BTW, real bitdepth you can find out by using -analyzebitdepth in eac3to: eac3to input -analyzebitdepth
BDInfo can measure bitdepth incorrectly:

Known Issues:
* Occasionally inaccurate bit-depth measurement on Dolby TrueHD and DTS-HD Master audio streams.

I know there's an option for eac3to like "-down16" that defines the output depth. I think this option is not lossless, is it?
yes, it isn't lossless.

[tebasuna51]

Is there any way that eac3to can decode the orginal audio file to the original depth, say, decode the 16bits TrueHD or ac3 to 16bits wav files?
I know there's an option for eac3to like "-down16" that defines the output depth. I think this option is not lossless, is it?

About TrueHD read the TDiTP_ answer.

About ac3:
A standard ac3 file don't have bitdepth and don't preserve the data about the original bitdepth of the source.
Then always is recommended decode a ac3 file to, at least, 24 bits in order to preserve the max quality.

Of course "-down16" with ac3 input is not lossless.

[doom-nine]

to TDiTP_ and tebasuna51:
Got it, thank you. ;-)

[nevcairiel]

The bitdepth is simply not known before the processing. The information about the bitdepth is not contained anywhere in the TrueHD track.

FWIW, this is not entirely true. There is a bitdepth field in the TrueHD major sync header, and libav/ffmpeg does read it and output 16 or 24 bit PCM accordingly.

[TDiTP_]

There is a bitdepth field in the TrueHD major sync header, and libav/ffmpeg does read it and output 16 or 24 bit PCM accordingly.
FFmpeg Win32 build can do it? Could you put command line, please?

[Asmodian]

FWIW, this is not entirely true. There is a bitdepth field in the TrueHD major sync header, and libav/ffmpeg does read it and output 16 or 24 bit PCM accordingly.

But this could be just randomly set, I understand it isn't really connected to the source and is often set incorrectly.

[nevcairiel]

But this could be just randomly set, I understand it isn't really connected to the source and is often set incorrectly.

Sure, if its set to 24 bit it could still mean its 16-bit audio just padded with zeros, but if its set to 16 there is no chance its 24-bit audio.
If it doesn't match the actual audio, the file is just broken. I don't consider broken files something to worry about. :p

[Cudo]

If a .thd file is 24-bit and eac3to reports it as broken but ffmpeg can still decode it to .wav using the -acodec pcm_s24le option, and if the decoded .wav can be played just fine, then if eac3to using the -analyzebitdepth option reports the decoded .wav is padded with zeros, does this mean the .thd is also padded with zeros?

[Asmodian]

Yes :D

[Cudo]

Yes :DAww.. lol Thanks alot for your fast reply! :)