eac3to - audio conversion tool

[madshi]

Anybody posted this issue to the eac3to bug tracker yet?

[asarian]

Anybody posted this issue to the eac3to bug tracker yet?

Not sure it qualifies as a bug per se. Since the Atmos TrueHD stream is said to be fully backwards compatible (= can be played on regular players), I can only draw the conclusion, that they put the Atmos 'ceiling' channels into the metadata (which receivers are supposed to ignore; which is why this works, I presume).

So, all we really need is a knowledgeable coder (you?!) who will strip off the metadata, so we have a regular TrueHD stream again, right?

[Thunderbolt8]

imho it would be preferable being able to decode the entire stream completely.

[minhjirachi]

When I use the command to extract the Dolby Atmos to mono wavs. I get this error:

eac3to v3.24
command line: eac3to.exe "trans.4.thd+ac3" Vie.wavs
------------------------------------------------------------------------------
The format of the source file could not be detected. <ERROR>


I think maybe eac3to can not recognize that TrueHD (Dolby Atmos type).

[nevcairiel]

imho it would be preferable being able to decode the entire stream completely.

You can't just "decode" Atmos, thats not how it works, its not comparable to any audio codec you dealt with before. It effectively needs to be rendered based on the configuration of speakers in your room, which means its unlikely to be easily supported by the existing software solutions for a long time to come (first because we have absolutely no idea how the Atmos data is structured, and secondly because we would need a lot of new code and configuration potential to actually be able to render the audio in a 3D space). If you want, consider it "3D Audio", which is fundamentally different than the previous "2D Audio" we used so far.

Regarding getting the original TrueHD stream out, its not that easy, its not just metadata you have to ignore, its properly integrated into the TrueHD codec itself, and will need proper fixing of the decoder.
Its possible that it would work if we had an "official" TrueHD decoder or a specification, but since the ffmpeg/libav TrueHD decoder is practically reverse engineered, it lacks the ability to deal with those streams, for now.

[asarian]

Regarding getting the original TrueHD stream out, its not that easy, its not just metadata you have to ignore, its properly integrated into the TrueHD codec itself, and will need proper fixing of the decoder.

Then I wonder how current receivers are able to play the Atmos-enhanced TrueHD stream just fine, if the Atmos data were really a part of the main TrueHD stream. There's obviously some 'easily' discardable info, or current receivers would not be able to pull it off cleanly.

[nevcairiel]

Like I said, if we had the specification of TrueHD, it could tell us what is wrong, but since Dolby is not giving that out, its not that easy.

[Thunderbolt8]

You can't just "decode" Atmos, thats not how it works, its not comparable to any audio codec you dealt with before. It effectively needs to be rendered based on the configuration of speakers in your room, which means its unlikely to be easily supported by the existing software solutions for a long time to come (first because we have absolutely no idea how the Atmos data is structured, and secondly because we would need a lot of new code and configuration potential to actually be able to render the audio in a 3D space). If you want, consider it "3D Audio", which is fundamentally different than the previous "2D Audio" we used so far.

Regarding getting the original TrueHD stream out, its not that easy, its not just metadata you have to ignore, its properly integrated into the TrueHD codec itself, and will need proper fixing of the decoder.
Its possible that it would work if we had an "official" TrueHD decoder or a specification, but since the ffmpeg/libav TrueHD decoder is practically reverse engineered, it lacks the ability to deal with those streams, for now.well whatever the wording is, what I meant is its rather preferable being able to use 100% of thats whats there compared to stripping something off in order to get just to the normal THD track.

Like I said, if we had the specification of TrueHD, it could tell us what is wrong, but since Dolby is not giving that out, its not that easy.maybe the guy knows who told madshi how to deal with the TrueHD track headers back then when there were those THD delay problems because madshi accidentally stripped too much from these tracks.

[foxyshadis]

Unless someone fixes the TrueHD decoder in ffmpeg/libav, AND you get a new eac3to version which uses the fixed decoder, there is nothing anyone can do.

Patch posted. (https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/163189.html)

[Superb]

Patch posted. (https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/163189.html)Hendrik Leppkes is nevcairiel... ;)

[minhjirachi]

Patch posted. (https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/163189.html)

How to use it?

[asarian]

Patch posted. (https://ffmpeg.org/pipermail/ffmpeg-devel/2014-September/163189.html)

Hmm, should I just get this (http://ffmpeg.zeranoe.com/builds/win32/dev/ffmpeg-20140919-git-33c752b-win32-dev.7z) Dev version? Can't compile on Windows myself.

And, even though I understand it's just temporary, I would *still* like ffmpeg/eac3to to retain the option to merely extract the TrueHD core (akin to extracting an AC3 core from the TrueHD stream), so as to have something playable/usable on my system.

P.S. Thanks for the speedy patch! :)

[tebasuna51]

... to extracting an AC3 core from the TrueHD stream), so as to have something playable/usable on my system.

The AC3 from the track can be extracted with tsMuxeR, at least with the sample uploaded here.

[asarian]

The AC3 from the track can be extracted with tsMuxeR, at least with the sample uploaded here.

Yes. What I meant, though, is the ability to extract the TrueHD stream, like we extract the AC3 stream now. :) I have no interest in the AC3 core, of course.

[asarian]

How to use it?

Yeah, someone please tell us where this alleged patch resides: the 'posted' patch is just a mailing list post.

I tried the latest binary, and it says:

c:\eac3to\ffmpeg -i "test.m2ts" -vn -ac 8 -acodec pcm_s24le -f wav c:\video\temp.wav

[truehd @ 02bb57e0] major sync info header checksum error
Last message repeated 42 times
[NULL @ 02bb57e0] start time for stream 1 is not set in estimate_timings_from_pts
[mpegts @ 02bb9080] Could not find codec parameters for stream 1 (Audio: truehd (AC-3 / 0x332D4341), 0 channels): unspecified sample format

It *does* extract a stream, btw, but, upon conversion (and downmixing) to LPCM, eac3to says:

Mixing surround channels...
Writing WAV...
Creating file "c:\video\finak.wav"...
Original audio track, L+R+C+LFE+SL+SR: constant bit depth of 24 bits
Original audio track, BL+BR: no audio data.
The processed audio track has a constant bit depth of 24 bits.

[Superb]

Looking at ffmpeg's git log, the patch wasn't merged in yet... So using the latest precompiled binary won't do you any good.

[foxyshadis]

Hendrik Leppkes is nevcairiel... ;)

Oh, I had no idea. Thank you, nev!

[asarian]

Looking at ffmpeg's git log, the patch wasn't merged in yet... So using the latest precompiled binary won't do you any good.

Yeah, I noticed (when I found the log); seems latest compile was yesterday's. Thx.

[asarian]

Looking at ffmpeg's git log, the patch wasn't merged in yet... So using the latest precompiled binary won't do you any good.

FYI, new ffmpeg with fix is up! :)

http://ffmpeg.zeranoe.com/builds/

[JimmyBarnes]

FYI, new ffmpeg with fix is up! :)

http://ffmpeg.zeranoe.com/builds/

Could someone indicate how is this supposed to be used, especially regarding using eac3to convert the Age of Extinction THD+AC3 stream to DTS or AC3.

TIA

[tebasuna51]

Can be used to decode the track but can't be used by eac3to until madshi can parse the track and add new libav dll's.

By the moment you can do, for instance:

ffmpeg -i 000000.m2ts -map 0:1 recoded.flac

[maxmercy]

Can be used to decode the track but can't be used by eac3to until madshi can parse the track and add new libav dll's.

By the moment you can do, for instance:

ffmpeg -i 000000.m2ts -map 0:1 recoded.flac

Will this mean a new version of eac3to and the ability to extract the 7.1 track from the DTHD stream? Looking forward to it!

JSS

[JimmyBarnes]

Can be used to decode the track but can't be used by eac3to until madshi can parse the track and add new libav dll's.

By the moment you can do, for instance:

ffmpeg -i 000000.m2ts -map 0:1 recoded.flac

Thanks for this, tho what I would really like to do is recode to AC3 640 kbps. Is this possible?

[tebasuna51]

Thanks for this, tho what I would really like to do is recode to AC3 640 kbps. Is this possible?

Of course you can recode to AC3 with ffmpeg, but a 7.1 must be downmix to 5.1 and is always better extract the AC3 included in the track with tsMuxeR (like I say in a precedent post).

BTW:

ffmpeg -i 00000.m2ts -map 0:1 -acodec ac3 -ac 6 -ab 640000 recoded.ac3

[JimmyBarnes]

Of course you can recode to AC3 with ffmpeg, but a 7.1 must be downmix to 5.1 and is always better extract the AC3 included in the track with tsMuxeR (like I say in a precedent post).

BTW:

ffmpeg -i 00000.m2ts -map 0:1 -acodec ac3 -ac 6 -ab 640000 recoded.ac3

Thanks for the above.

Does this actually convert the entire THD+AC3 to AC3 (rather than simply extract the AC3 stream, as you suggest with tsMuxeR)?

[asarian]

Could someone indicate how is this supposed to be used, especially regarding using eac3to convert the Age of Extinction THD+AC3 stream to DTS or AC3.

TIA

I simply used this:

ffmpeg -i "test.m2ts" -vn -ac 8 -acodec pcm_s24le -f wav c:\video\temp.wav

[DoctorM]

Thanks for the above.

Does this actually convert the entire THD+AC3 to AC3 (rather than simply extract the AC3 stream, as you suggest with tsMuxeR)?

Re-read what you quoted.

[JimmyBarnes]

ffmpeg -i 00000.m2ts -map 0:1 -acodec ac3 -ac 6 -ab 640000 recoded.ac3

This worked and the resulting AC3 synced OK with the recoded x264 video :thanks:

[minhjirachi]

Waiting for an update of eac3to.

[Lenmaer]

We were promised updates for over a year now, will it finally happen?

[JimmyBarnes]

Waiting for an update of eac3to.

This would be the ideal solution to the Dolby Atmos issue, I would expect..

But the ffmpeg solution described here can be used meanwhile.

[Nico8583]

Hi :) could you explain me the difference between 16bits and 24bits DTS ? And the real utility to use -dontPatchDts option or not ? Thanks !

[tebasuna51]

In the standard (lossy) DTS headers there are a field to remember the bitdepth (precission) of the source PCM used to encode the DTS.
After the encode this info is useless because we can't recover the original precission.

By default eac3to change this field to put always 24 bits to remember than any lossy format (AC3, DTS, ...) must be decoded at last to 24 bits, even if the source PCM was 16 bits, to preserve the max quality.
Then use -dontPatchDts is useless because don't change any relevant info in the stream.

[Nico8583]

Thanks for your response. So it's useless now to use this option because any player can read a "virrtual" 24bits stream ? Even in a MKV ?

[tebasuna51]

Players don't use that field because lossy formats don't have bitdepth, must be ignored in standalone DTS or in any container.

[Nico8583]

Ok thanks for these informations !

[RoseM]

Hello

Someone could see why the audio of the file below isn't recognized by the program?

http://www.mediafire.com/download/5wndl415r97o84z/09-30_12-25-28_Globo_HD_SP.ts

Thanks
Because this format is not supported by eac3to tool.

Audio #1
ID : 274 (0x112)
Menu ID : 59200 (0xE740)
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AAC / LC
Muxing mode : LATM
Codec ID : 17
Duration : 1mn 11s
Bit rate mode : Variable
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz / 24.0 KHz
Compression mode : Lossy
Delay relative to video : -400ms
Could add support for this format in a update future .

thanks

[Overdrive80]

That is not format audio, is muxing mode. The audio format for you code is AAC, and eac3to already support that format.

[Music Fan]

The message from eac3to about the aac tracks of this file is "parsing failed".
But it works when put in MKA (and probably also MKV), eac3to has maybe problems with aac in TS container.

Could add support for this format in a update future .
Open your TS in MKVMerge, uncheck video if not needed, export in mka, open the mka in eac3to.
Strange thing : the aac 2.0 becomes 3.0 when in mka and the frequency becomes 22.05 KHz ;

Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 1mn 8s
Channel(s) : 3 channels
Channel positions : Front: L C R
Sampling rate : 22.05 KHz
Compression mode : Lossy
Default : Yes
Forced : No


edit : I spoke too quickly ; analyzing works but not decoding ;

eac3to v3.27
command line: "C:\Program Files\eac3to\eac3to.exe" "F:\09-30_12-25-28_Globo HD_SP.mka" "F:\09-30_12-25-28_Globo HD_SP.wavs"
------------------------------------------------------------------------------
MKA, 1 audio track, 0:01:09
1: AAC, 3.0 channels, 22kHz
Track 1 is used for destination file "09-30_12-25-28_Globo HD_SP.wavs".
[a01] Extracting audio track number 1...
[a01] Decoding with DirectShow (Nero Audio Decoder 2)...
[a01] Getting "Nero Audio Decoder 2" instance failed. <ERROR>
Aborted at file position 220599. <ERROR>

[tebasuna51]

@RoseM

1) Extract with eac3to (ignore warnings)

2) Use vlc to convert LATM to standard .m4a (see http://forum.doom9.org/showthread.php?p=1453484#post1453484 ), for instance:

vlc.exe -I dummy aud_latm.aac --sout #std{access=file,mux=mp4,dst="aud_nolatm.mp4"} vlc://quit

[RoseM]

@RoseM

1) Extract with eac3to (ignore warnings)

2) Use vlc to convert LATM to standard .m4a (see http://forum.doom9.org/showthread.php?p=1453484#post1453484 ), for instance:

vlc.exe -I dummy aud_latm.aac --sout #std{access=file,mux=mp4,dst="aud_nolatm.mp4"} vlc://quit
Okay.'ll Try

There's no mode of eac3to do the demux without having to use other programs.

TMPGEnc makes the conversion but isn't free. Wanted to use RipBot264

'm Half noob in conversions.

Thank you guys for replys

[tebasuna51]

There's no mode of eac3to do the demux without having to use other programs.

eac3to demux the aac but still in LATM format not recognized by standard decoders.

I only know VLC to change the LATM to a standard AAC format.

[DonDan]

Hey guys,

I've been testing around for quite a while now trying to achieve the following: AC3 stereo (well fake stereo, originally mono source made to 2 identical stereo chans on DVD) to aac mono in one step piping output from eac3to to neroaac or fdkaac (to make sure it's not an encoder issue).

Whereas both commands (that encode stereo) work fine:

eac3to test.AC3 stdout.wav | neroaacenc -ignorelength -lc -q 0.4 -if - -of neroenc_out.mp4

eac3to test.AC3 stdout.wav | fdkaac --profile 2 --bitrate-mode 2 -o fdkaac_out.mp4 -

I fail as soon as I try to make eac3to output mono.

On the eac3to side I tried with adding -normalize -down16 -mono or just -mono, also tried naming the output both stdout.wav aswell as stdout.wavs.

On the encoder side I also tried all available options like --ignorelength --raw --raw-channels 1 --raw-rate 48000 --raw-format S24L for fdkaac and *well nothing* for neroaac to no extent...

Nero will just refuse to encode, fdkaac at least tries but the best I got so far was a file with noise for the correct duration of the input file.

Ofc when I encode the ac3 to mono.wav in eac3to and in a second step encode that to aac I get a proper result, but I'ld love to find a way to use a pipe to get there.


Anybody got an idea? Or is it just plain impossible?


Muchas Gracias!

[tebasuna51]

When you decode AC3 2.0 to stdout.wav with the -mono parameter (Left channel only) with:

eac3to test.AC3 stdout.wav -mono | neroaacenc -ignorelength -q 0.4 -if - -of neroenc_out.mp4

NeroAacEnc send the message: "Invalid Channel mask" and finish.
In fact the stdout.wav have the channel mask 3 (Left + Right) like the original AC3 file.

A workaround is use simple wav header instead the default WAVE_FORMAT_EXTENSIBLE header with:

eac3to test.AC3 stdout.wav -mono -simple | neroaacenc -ignorelength -q 0.4 -if - -of neroenc_out.mp4

And now work fine.

[DonDan]

I guess this is the right time to say: 'That -simple?!?' ;-)

:thanks: :thanks:

[jpsdr]

Madshi, could you take a look here (http://forum.doom9.org/showthread.php?p=1698609#post1698609) and enlight us ?
Is it something you add on your own, or can it be handled by an option using flac.exe (or libflac) ?

[madshi]

Is it something you add on your own, or can it be handled by an option using flac.exe (or libflac) ?
What do you mean with "it" exactly?

[jpsdr]

... You're right indeed... "it" was not clear. It was the "HDCD" and "VALID_BIT" tags. But, i think Groucho2004 provided the answer.
I am right to say it's a custom meta_data tag, finaly exclusive specific to eac3to, and so irrelevant or with no interest for any other software ?

[madshi]

Well, any other software is free to use it, but yes, it's not an "official" meta data tag.

[mini-moose]

apologies if this was asked before..

Are there plans to add support for TrueHD Atmos?