eac3to - audio conversion tool

[TDS]

What is the quickest & easiest way to convert THD 7.1 (or higher) to AAC 7.1 ??

Thanks

EDIT:- I think I may have found how to, BUT if there IS an easy way.

[tebasuna51]

For thd input I recommend ffmpeg decoder (avutil 57, avcodec 59), faster and more actualized than eac3to (avutil 52, avcodec 54), and for aac 7.1 output only qaac encoder:

"FFMPEG" -i "INPUT71.thd" -acodec pcm_s24le -f wav - | "QAAC" -V QUALITY --ignorelength --adts --no-delay -o "OUTPUT71.aac"

Others encoders, for instance using ffmpeg internal, convert standar thd 7.1 Channel layout: C L R Ls Rs Lb Rb LFE, to aac 7.1 Channel layout: C L R Ls Rs Lw Rw LFE

For easy way you can use UsEac3toGUI (load input and button A/V Recode)

[TDS]

Originally Posted by tebasuna51

For thd input I recommend ffmpeg decoder, faster and more actualized than eac3to, and for aac 7.1 output only qaac encoder:

"FFMPEG" -i "INPUT71.thd" -acodec pcm_s24le -f wav - | "QAAC" -V QUALITY --ignorelength --adts --no-delay -o "OUTPUT71.aac"

Others encoders, for instance using ffmpeg internal, convert standar thd 7.1 Channel layout: C L R Ls Rs Lb Rb LFE, to aac 7.1 Channel layout: C L R Ls Rs Lw Rw LFE

For easy way you can use UsEac3toGUI (load input and button A/V Recode)

Hi, I really appreciate the info, but I am totally lost

I don't know how to use that command line you provided, and converting the channel layout's....

So you're saying that eac3to isn't the best way to convert ??

I have very recently started using "cleverFFmpeg", and it's got so many options, it's crazy, but I do use eac3to quite bit for e-ac3 conversions.

[tebasuna51]

UsEac3toGUI can work like eac3to and ffmpeg GUI. If you want some eac3to audio management use it and encode with qaac.

cleverFFmpeg can decode with ffmpeg and encode with qaac, remember the discussion in that thread

[Balling]

Originally Posted by tebasuna51

The message is clear: this track is a mix of 1.0 and 2.0
Try with:
ffmpeg -i japanese.thd -ac 2 -acodec pcm_s24le -f wav japanese.wav

Hi, what does it mean? THD 1.0? Is that version of THD or mono? We still have this ticket and it futher regressed. Do you have full japanese.thd?

https://trac.ffmpeg.org/ticket/667#comment:10


* added special handling for TrueHD seamless branching


is that as good as https://github.com/domyd/mlp or worse as in DGDemux? Or even more perfect as in MakeMKV?

[tebasuna51]

Originally Posted by Balling

Hi, what does it mean? THD 1.0? Is that version of THD or mono?

A mix of mono and stereo audio.

We still have this ticket and it futher regressed. Do you have full japanese.thd?

Nope.
The track uploaded in comment 15 is a correct mono track without problems to decode, after extract thd and ac3 streams.

* added special handling for TrueHD seamless branching

is that as good as https://github.com/domyd/mlp or worse as in DGDemux? Or even more perfect as in MakeMKV?

Sorry, currently I haven't TrueHD seamless branching BD's to check it.

[Balling]

>A mix of mono and stereo audio.

The author gave the full sample from another disk, it appears to be just mono.

[tebasuna51]

Originally Posted by Ex0rcist

I'm trying to demux .mkv file with positive audio delay using eac3to. I've noticed that after delay is fixed distortion audio is added/occurs at the beginning, why is that and how to avoid it ?

Seems the method used by eac3to to delay aac streams is repeat the first frame, if it isn't silence an annoying sound can be produced.

Use mkvextract or ffmpeg to extract them.

For ac3/dts streams I think eac3to use methods like the old DelayCut with really ac3/dts silence frames.

[Ex0rcist]

mkvextract ignores delay info and just shifts audio to first frame, so that's pretty much useless because audio won't be in sync as it should be. Is it possible to report this bug to eac3to dev for possible fix in the future ?

[tebasuna51]

In the first post you have the link to the bug tracker.

[jlw_4049]

We've recently discovered removing dialNorm from a truehd track during demux actually edits the header in the way the Atmos data is no longer valid. It's still there, but it cannot be used by any official tools or players.

Is there any way to restore dialNorm to normal?

I confirmed this by demuxing with eac3to with -keepDialnorm and without it and the only one that actually worked with the Atmos channels was the -keepDialnorm. I'm not sure which header is being edited in the file itself, but editing it with a hex editor to match the one with -keepDialnorm allows the Atmos to work correctly again. However, I can't do this across other files as easily.

Is there a way to do this with eac3to or any other tool?

[tebasuna51]

@jlw_4049
Yes, to preserve the Atmos data you must extract it with -keepDialnorm.

And not, I don't know a tool to restore the dialNorm.

[jlw_4049]

Originally Posted by tebasuna51

@jlw_4049
Yes, to preserve the Atmos data you must extract it with -keepDialnorm.

And not, I don't know a tool to restore the dialNorm.

Do you think it's possible for such a tool to be designed? As the data is still in the file, just seems like the header of the file has been modified. Not allowing the atmos to be decoded.

[Nikos]

With the following line:
eac3to audio.thd audio.wav
eac3to removes the Dialogue Normalization metadata.

The question is what happens to Dynamic Range Compression metadata?

[tebasuna51]

Originally Posted by Nikos

The question is what happens to Dynamic Range Compression metadata?

The old libav decoder in eac3to output the same volume than updated ffmpeg, even when I try use -drc_scale 0 with the message:

Codec AVOption drc_scale (percentage of dynamic range compression to apply) specified for input file #0 (D:\Test\chan-check-5.1.thd) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some decoder which was not actually used for any stream.

I try with many thd samples with the same message, then I don't have a sample with DRC, or ffmpeg ignore that metadata if exist.
I can't check it.

[Nikos]

After testing I came to the conclusion:
With a .thd sound, the ffmpeg ignores the DN and the DRC.

Center channel .thd
drc_scale 0.0 --> RMS -28.9576 dB
drc_scale 1.0 --> RMS -28.9576 dB

With a .ac3 sound (core from .thd), the ffmpeg ignores the DN but applies the DRC.

Center channel .ac3 core
drc_scale 0.0 --> RMS -29.0598 dB
drc_scale 0.5 --> RMS -30.2756 dB
drc_scale 1.0 --> RMS -31.1711 dB

[tebasuna51]

The volume level of ac3 drc_scale 0.0 (-29 dB) is the same than the thd, then seems the decode is correct without atenuation.

[nevcairiel]

Dialog Normalization in AC3 is only used if you set target_level to adjust the target volume of the decoded stream. Its how the AC3 spec wants to control a unified volume, by including metadata to let you request a reference level.

[Nikos]

The ffmpeg decoding is correct when with drc_scale 0 we have no compression and with drc_scale 1 we have full compression

For downmix 5ch --> 2ch i prefer audio with DRC=1.

I don't know what it is ac3 target_level...

[Balling]

Originally Posted by tebasuna51

The old libav decoder in eac3to output the same volume than updated ffmpeg, even when I try use -drc_scale 0 with the message:



I try with many thd samples with the same message, then I don't have a sample with DRC, or ffmpeg ignore that metadata if exist.
I can't check it.

FFmpeg does NOT support TrueHD DRC, it just outputs lossless stream, that is the same (aside from the lossy) as EAC3 with -drc_scale 0. Also, FFmpeg does not support it anywhere with encoding.

But EAE and microsoft and others support decoding TrueHD (now lossily) with DRC.