eac3to - audio conversion tool

[tebasuna51]

@all
To report bugs please use the thread http://forum.doom9.org/showthread.php?t=166487

@get8p
please read http://forum.doom9.org/showthread.php?p=1608655#post1608655
and http://forum.doom9.org/showthread.php?t=166487
Use -keepDialnorm.

@phate89
a mix DPL II can recover the surround (more or less) with the appropiated decoder in audio receivers.

[phate89]

Originally Posted by tebasuna51

@phate89
a mix DPL II can recover the surround (more or less) with the appropiated decoder in audio receivers.

But if my goal is to convert the track to aac or mp3 through wav it's useless and i should use -downtostereo right?

[tebasuna51]

No matter if is aac, mp3 or wav. Your receiver can restore the surround and center channels if have the DPL II decoder inside.

[LigH]

Dolby ProLogic is an analog technology. It analyzes phase directions and delays in signals as electrical voltage fluctuations, not as bits and bytes.

There is no technical relation between Dolby ProLogic (analog surround sound mixing) and Dolby Digital (digital audio compression), except for the same company which developed them.

A third different, unrelated technology developed by the Dolby Labs are noise reduction techniques for audio on magnetical tapes.

And a fourth, even more unrelated remark: Thomas Dolby made a song about Science! But his stage name was only inspired by the noise reduction techniques, he was not a member of Dolby Labs...

[Boulder]

Originally Posted by get8p

• Proper ac3 decoding. Whilst a freeware prog like azid can properly decode ac3, it's a real shame such powerful instrument as eac3to uses nero/libav for that, because both decoders has defects.

Are those libav problems reported to the devs?

The decoder author responded in the thread. The problem is that the results in that thread are based on the libav decoder as it was more than a year and a half ago. Which is why madshi asked if those results were even still relevant.

Originally Posted by madshi

The test you're linking to is 1.5 years old and the guy reponsible for the libav AC3 decoder has seen and commented on the test results those 1.5 years ago, too, so I would say a retest would be needed to make sure those results are still valid today. And if they are, a bug report should be created for libav/ffmpeg, so that the problem is fixed.

[bilditup1]

Originally Posted by tebasuna51

We can't support downloaded (and fake) files.

Right, didn't mean to offend anyone or feel entitled

[phate89]

Originally Posted by tebasuna51

No matter if is aac, mp3 or wav. Your receiver can restore the surround and center channels if have the DPL II decoder inside.

Originally Posted by LigH

Dolby ProLogic is an analog technology. It analyzes phase directions and delays in signals as electrical voltage fluctuations, not as bits and bytes.

There is no technical relation between Dolby ProLogic (analog surround sound mixing) and Dolby Digital (digital audio compression), except for the same company which developed them.

A third different, unrelated technology developed by the Dolby Labs are noise reduction techniques for audio on magnetical tapes.

And a fourth, even more unrelated remark: Thomas Dolby made a song about Science! But his stage name was only inspired by the noise reduction techniques, he was not a member of Dolby Labs...

Ok i finally understood. Thanks for the help

[Thunderbolt8]

thanks for the update!

[Groucho2004]

Originally Posted by tebasuna51

No matter if is aac, mp3 or wav. Your receiver can restore the surround and center channels if have the DPL II decoder inside.

Picking up on that once more - I don't have a surround setup (and probably never will), just a plain stereo system. In this case I should always use "-downStereo", right?
Also, if I downmix DTS tracks, should I use the "phaseshift" option or does the downmix algorithm take care of that? How can I even determine if the back channels have a phase shift?

[tebasuna51]

Originally Posted by Groucho2004

Picking up on that once more - I don't have a surround setup (and probably never will), just a plain stereo system. In this case I should always use "-downStereo", right?

Yes.

Also, if I downmix DTS tracks, should I use the "phaseshift" option or does the downmix algorithm take care of that? How can I even determine if the back channels have a phase shift?

This is a old question.

A correct 5.1, no matter if is AC3 or DTS, must have surround channels already "phaseshifted" over same info in front channels, by soft or when are recorded with microphones at different places, if you do a new "phaseshift" you can finish with 180º than convert the mathematical "+", in mix functions, in a "-" and cancel many info.

Like you don't know how the 5.1 was generated my recommendation is don't use "phaseshift", most the times is the correct way. And only try "phaseshift" when the previous mix sounds strange.

[Groucho2004]

Originally Posted by tebasuna51

Yes.

This is a old question.

A correct 5.1, no matter if is AC3 or DTS, must have surround channels already "phaseshifted" over same info in front channels, by soft or when are recorded with microphones at different places, if you do a new "phaseshift" you can finish with 180º than convert the mathematical "+", in mix functions, in a "-" and cancel many info.

Like you don't know how the 5.1 was generated my recommendation is don't use "phaseshift", most the times is the correct way. And only try "phaseshift" when the previous mix sounds strange.

OK, thanks!

[madshi]

Originally Posted by LigH

... the azid.dll should still be available from many BeSweet related sources.

Yes, but there's no matching header anywhere to be found, and the dll exports a bunch of APIs without any names or descriptions. I don't feel like reverse engineering the dll.

Originally Posted by Snowknight26

Is that still accurate or is libavcodec on par now?

Argh, I changed the first page of this thread, but didn't update the same description in the help.

Originally Posted by 88keyz

Curious, why the change from Nero to libav as the preferred DD decoder?

Because there were some problems with the Nero decoder. Mostly, disabling DRC didn't work for all tracks.

Originally Posted by Snowknight26

Errors that libavcodec spits out break the progress bar

Doesn't happen for me!! Did you maybe replace the libav/ffmpeg dlls with a different version? Can anybody reproduce this problem?

Originally Posted by bilditup1

This still doesn't appear to work with 5.0 DTS files.

Originally Posted by tebasuna51

is't true eac3to 3.25 don't downmix 5.0 files (tested DTS, AC3 and WAV).

Yes, a stupid mistake. I added all the code to make the downmixing work for all possible channel configurations, but then forgot to remove some code which disables downmixing for less than 6 channels. I'll release a new build, but I'll wait a couple of days, in case some other bugs show up. So guys, do testing *now*, because the next eac3to build will probably have to do for a few months again.

Originally Posted by get8p

• avi, mp4, mov, mpg, flv demuxing(maybe even muxing, that would be fantastic). Basically, avi/mp4 support is most important feature I think eac3to is lacking, along with

Yeah, that would be nice, but it would be a lot of work, so it won't come anytime soon.

Originally Posted by get8p

• Proper ac3 decoding. Whilst a freeware prog like azid can properly decode ac3, it's a real shame such powerful instrument as eac3to uses nero/libav for that, because both decoders has defects.

There's no header available for the azid.dll. I think the best solution would be to first double check whether the libav decoder still suffers from the same problem today (that test you mention is 1.5 years old after all), and if it does, post a bug report to the libav devs.

Originally Posted by get8p

• and also, downmix to mono and ac3/dts dialnorm applying - minor, but still useful features.

What would you need dialnorm for? I believe it's a fundamentally broken concept.

[Snowknight26]

Originally Posted by madshi

Doesn't happen for me!! Did you maybe replace the libav/ffmpeg dlls with a different version? Can anybody reproduce this problem?

If I extracted the zip to the same folder as previous instances of eac3to, would the latest version of libavcodec be used (avcodec-54.dll) or would old ones be used if they were present (such as avcodec.dll)?

tebasuna51 had a similar result but he used -progressNumbers or whatever the command is. Strange how mine shows the same thing as ffmpeg "[truehd @ 00000000]" whereas his shows "[libav]".

I'll see what happens when I clear out the eac3to folder..

[madshi]

Originally Posted by Snowknight26

I used the ones included in the zip. tebasuna51 had a similar result but he used -progressNumbers or whatever the command is. Strange how mine shows the same thing as ffmpeg "[truehd @ 00000000]" whereas his shows "[libav]".

tebasuna51's results are fundamentally different. "[libav]" means eac3to got the log message from libav. "[truehd @ ...]" means ffmpeg/libav bypassed eac3to and wrote the log directly to the command line window. Which ffmpeg/libav should not do because eac3to told it to forward all log messages to eac3to instead of writing them to the command line window. So the logging system is broken for you, but not for tebasuna51, nor for me.

[Snowknight26]

Well, I'm not sure what to say but having gone through the thread I see a few people have different results.

For example:
'[libav]': http://forum.doom9.org/showpost.php?...ostcount=11866
'[truehd @ 00000000]': http://forum.doom9.org/showpost.php?...ostcount=11883


Edit:
Just tried a corrupt file and eac3to only showed '[libav]' so I guess it was using older dlls that were present in the folder. Case closed.

[nickintheforest]

Originally Posted by madshi

Yes, but there's no matching header anywhere to be found, and the dll exports a bunch of APIs without any names or descriptions. I don't feel like reverse engineering the dll.

Ok, azid hasn't source code. But liba52 has. liba52 in group "A" too.

Originally Posted by nickintheforest

Ok, azid hasn't source code. But liba52 has.

The source code isn't needed or the issue. The issue is the required header to actually call into the DLL.

Originally Posted by nickintheforest

liba52 in group "A" too.

Yes, based on a test that is 1.5 years out of date. You and get8p seem to gloss over the part where madshi has repeatedly stated that you should be checking that the issue is even still relevant today since the decoder has had changes made to it since that test. Then, if the issue still exists, report them to libav so they can be fixed. This would be the best solution.

[madshi]

liba52 is GPL, not LGPL, so I can't use it.

[mrr19121970]

Perhaps there is an issue with the new version?

http://forum.slysoft.com/showpost.php?p=361367&postcount=2976

Used eac3to 3.25 to successfully process Brave and Finding Nemo with ClownBD. However, the playback of Brave contains audio drops (3 in the first 5 minutes) like in Total Recall (2012). I have not checked Finding Nemo yet.