eac3to - audio conversion tool

[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! (http://www.youtube.com/watch?v=m42KM_2br4c) But his stage name was only inspired by the noise reduction techniques, he was not a member of Dolby Labs...

[Boulder]

• 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 (http://forum.doom9.org/showthread.php?t=161654).Are those libav problems reported to the devs?

[paradoxical]

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.

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]

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


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

[phate89]

No matter if is aac, mp3 or wav. Your receiver can restore the surround and center channels if have the DPL II decoder inside.
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 :thanks:

[Thunderbolt8]

thanks for the update! :thanks:

[Groucho2004]

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]

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]

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]

... 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.

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.

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.

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?

This still doesn't appear to work with 5.0 DTS files.
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.

• 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.


• 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 (http://forum.doom9.org/showthread.php?t=161654).
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.

• 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]

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 (http://forum.doom9.org/showpost.php?p=1608764&postcount=96) 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]

I used the ones included in the zip. tebasuna51 had a similar result (http://forum.doom9.org/showpost.php?p=1608764&postcount=96) 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?p=1599868&postcount=11866
'[truehd @ 00000000]': http://forum.doom9.org/showpost.php?p=1600129&postcount=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. :p

[nickintheforest]

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 (http://forum.doom9.org/showthread.php?p=1508819#post1508819).

[paradoxical]

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.

liba52 in group "A" too (http://forum.doom9.org/showthread.php?p=1508819#post1508819).

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.

[madshi]

Not sure what is meant with "contains audio drops". I've personally tested Brave and had no problems with playback whatsoever.

[sl1pkn07]

according to http://forum.doom9.org/showthread.php?t=23921 and http://web.archive.org/web/20020205230410/http://www.doom9.org/sources.htm and http://web.archive.org/web/20020414191825/http://www.doom9.org/sources.htm

http://web.archive.org/web/20020205230410/http://www.doom9.org/Soft21/Sources/azid-dll-1.7.1.zip
http://web.archive.org/web/20020414191825/http://www.doom9.org/Soft21/Sources/azid-dll-1.8.zip

have sources to api call dll

but.... don't download

EDIT: http://web-beta.archive.org/web/20090228063605/http://dspguru.notrace.dk/BeSweetv1.5b23DLL.zip

is possible use azid trought beesweet dll? (the zip contains headers) (i don't know if beesweet.dll uses azid.dll)

[Chumbo]

@madshi/tebasuna51,
Thanks so much for your efforts. Great to see a new version. :)

[madshi]

according to http://forum.doom9.org/showthread.php?t=23921 and http://web.archive.org/web/20020205230410/http://www.doom9.org/sources.htm and http://web.archive.org/web/20020414191825/http://www.doom9.org/sources.htm

http://web.archive.org/web/20020205230410/http://www.doom9.org/Soft21/Sources/azid-dll-1.7.1.zip
http://web.archive.org/web/20020414191825/http://www.doom9.org/Soft21/Sources/azid-dll-1.8.zip

have sources to api call dll

but.... don't download

EDIT: http://web-beta.archive.org/web/20090228063605/http://dspguru.notrace.dk/BeSweetv1.5b23DLL.zip

is possible use azid trought beesweet dll? (the zip contains headers) (i don't know if beesweet.dll uses azid.dll)
No, that besweet dll doesn't help at all.

[madshi]

eac3to v3.26 released

http://madshi.net/eac3to.zip

* fixed: downmixing of less than 6 channels to stereo failed
* patched libav AC3 decoder to properly decode high frequencies
* added support for floating point volume changes (e.g. -0.5db)
* dialnorm is no longer removed from DTS-HD tracks (didn't work, anyway)

[hubblec4]

thanks a lot madshi, you are the best.

[filler56789]

eac3to v3.26 released

http://madshi.net/eac3to.zip

* fixed: downmixing of less than 6 channels to stereo failed

* patched libav AC3 decoder to properly decode high frequencies

* added support for floating point volume changes (e.g. -0.5db)

* dialnorm is no longer removed from DTS-HD tracks (didn't work, anyway)

:thanks: ( again ) :)

[get8p]

Thanks! Ac3 fix is a huge plus. Finally ac3 demux and decode is possible in one line.
Never got the answer, is there any thoughts on avi, mp4, mov, mpg, flv demuxing(maybe even muxing) and downmix to mono?

[Overdrive80]

Never got the answer, is there any thoughts on avi, mp4, mov, mpg, flv demuxing(maybe even muxing) and downmix to mono?

It would be major improvements, and madshi only will do minor changes, for now.

[get8p]

Well, then I'd like madshi to tell if he's putting it in future to-do list, so I'd just stop asking.
And downmixing to mono, it can't be that big of a deal?

[nickintheforest]

> * patched libav AC3 decoder to properly decode high frequencies
thank you, madshi :)

[Snowknight26]

* encoder bitdepth for lossy DTS tracks is no longer displayed

It still is for DTS core tracks:
4: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz)

[madshi]

It still is for DTS core tracks:
4: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz)
Oh well... Maybe next time...

[madshi]

eac3to v3.27 released

http://madshi.net/eac3to.zip

* fixed: raw processing cut away 16 samples sometimes
I'll probably be gone for a while now.

[VincAlastor]

thank you madshi for eac3to to keeping alive!!! the new release makes me very happy ^^

if you want to expand features in future, maybe you take a look at qaac (neroaac development stopped for years) and flaccl (better compression and sometimes faster than flac.exe; i don't know if flaccl can handle 24bit stream now)

thanks again :)

[DarkSpace]

Thank you for the new releases, and for taking the time to implement float Volume changes as well!

[tebasuna51]

Thanks madshi!

if you want to expand features in future, maybe you take a look at qaac (neroaac development stopped for years) and flaccl (better compression and sometimes faster than flac.exe; i don't know if flaccl can handle 24bit stream now)

You can always use qaac (I don't know flaccl) like external encoder with:

eac3to input stdout.wav | qaac -V 99 --ignorelength -o output.m4a -

[06_taro]

flaccl can handle up to 32bit pcm IIRC, you can always use pipe method: eac3to.exe input stdout.wav | CUETools.FLACCL.cmd.exe -o output.flac -

[VincAlastor]

thank you for your help. i use eac3to often with megui and staxrip automatically... in cmd i think it's not practically for daily using. and why should eac3to come out with outdated encoders (neroaac, flac) and not with newer, often better encoders?

[tebasuna51]

thank you for your help. i use eac3to often with megui and staxrip automatically... in cmd i think it's not practically for daily using. and why should eac3to come out with outdated encoders (neroaac, flac) and not with newer, often better encoders?

- You can't prove than qaac is better than NeroAacEnc at default eac3to -quality=0.5

- If you don't like command line maybe you can test the GUI UsEac3to.

- MeGUI support qaac now.

[LigH]

From the archive:

dg providem me with v1.9 :)
THX for that DSPguru

but i have read the documentation from the azid files and the author (midas) wants me to add splash screens, and some other things which i personally dont really like.
...

The azid.dll could possibly be used via the besweet.dll, but I believe that will only shift the issue to another level.

Midas (Azid), DSPguru (BeSweet), DarkAvenger (HeadAC3he) — Hopping from one dead horse to another... :o

And there is also a package with azid.exe CLI decoders (P3/P4 opt.), but you may try to avoid intermediate files?

[Chumbo]

eac3to v3.27 released

http://madshi.net/eac3to.zip

* fixed: raw processing cut away 16 samples sometimes
I'll probably be gone for a while now.
Thanks again. Hey, before you go, would you update the first post to reflect version 3.27 please?

[madshi]

From the archive:

The azid.dll could possibly be used via the besweet.dll, but I believe that will only shift the issue to another level.

Midas (Azid), DSPguru (BeSweet), DarkAvenger (HeadAC3he) — Hopping from one dead horse to another... :o

And there is also a package with azid.exe CLI decoders (P3/P4 opt.), but you may try to avoid intermediate files?
Doesn't matter anymore, anyway. See v3.26 release notes.

[Atak_Snajpera]

does new version still need MSVCP71.dll in system folder?

http://forum.doom9.org/showthread.php?p=1607304#post1607304

[rapscallion]

Thanks madshi for new version....however, Nemo 7.1 THD, decode to wavs, still fails lossless check :


[libav] Lossless check failed - expected 00, calculated f4. <WARNING>
[libav] Lossless check failed - expected 00, calculated 65. <WARNING>
[libav] Lossless check failed - expected 00, calculated f6. <WARNING>
[libav] Lossless check failed - expected 00, calculated 88. <WARNING>
The original audio track has a constant bit depth of 20 bits.


I've never seen the 20 bits depth before, besides this nemo track.

Edit: Correction, the previous libav (ver 3.25) would crash completely, while now it creates the wavs w/the warnings above. This is the same thing when creating flac via ffmpeg, so maybe it's a somehow corrupted stream.

[Overdrive80]

Hi, one question... Does eac3to decode to do "slowdown"???

[tebasuna51]

Hi, one question... Does eac3to decode to do "slowdown"???
Yes, slowdown-resample work over uncompressed audio data then eac3to must decode compressed audio before.

[Furiousflea]

Is there still a need to remap channels when decoding DTS 6.1 tracks with Arcsoft decoder with latest eac3to.

The changelog is ambiguous if that has been fixed or do we still need to specify a channel layout?

[tebasuna51]

Is there still a need to remap channels when decoding DTS 6.1 tracks with Arcsoft decoder

Decode was always fine, only when you use -down6 was wrong.
And fixed now.

[dansrfe]

So I recently bought a bluray which has 16-bit, 96Khz TrueHD and 24-bit, 48Khz DTS-HD/MA audio tracks. My question is: if space is not an issue and playback will always involve decoding to PCM via arcsoft's decoder or the like, which track should I keep in the mkv encode?

Also, as a side question, if I will always play back from my computer then is it better to encode lossless audio from DTS-HD/MA or TrueHD to FLAC and maintain the original file's bit-depth and sample rate or should I just keep the original DTS-HD-MA/TrueHD file?

[Furiousflea]

Decode was always fine, only when you use -down6 was wrong.
And fixed now.

Thanks for explaining that, much appreciated.

[tebasuna51]

So I recently bought a bluray which has 16-bit, 96Khz TrueHD and 24-bit, 48Khz DTS-HD/MA audio tracks. My question is: if space is not an issue and playback will always involve decoding to PCM via arcsoft's decoder or the like, which track should I keep in the mkv encode?

Seems than standard human ear can distinguise until 20 bit precission audio but not much over 20 KHz frequency (samplerate 40 KHz).

Also, as a side question, if I will always play back from my computer then is it better to encode lossless audio from DTS-HD/MA or TrueHD to FLAC and maintain the original file's bit-depth and sample rate or should I just keep the original DTS-HD-MA/TrueHD file?

If your PC can send to receiver, through HDMI, PCM multichannel audio (decoded from FLAC or DTS-HD-MA/TrueHD) then the quality is always the same. Flac files have less size.

There are external players (PopCorn, Xtreamer, ...) than can send also Flac decoded to PCM multichannel.