eac3to - audio conversion tool

[Atak_Snajpera]

Exactly Motenai Yoda. It is better to have more bits in areas where you actually can here difference than waste bitrate for high frequencies where most adults (30+) do not here anything. After all it is a lossy codec. Some information must be discarded.

[Q-the-STORM]

all true.... but the aften encode does sound worse (I let a few people do double blind tests, though that's not really enough to draw a real conclusion)... and the official dolby encoder does not cut off at 16,5Hz... even aften's developer says that nobody should be using aften anymore and everyone should switch to libav....

[DoctorM]

Originally Posted by Q-the-STORM

all true.... but the aften encode does sound worse (I let a few people do double blind tests, though that's not really enough to draw a real conclusion)... and the official dolby encoder does not cut off at 16,5Hz... even aften's developer says that nobody should be using aften anymore and everyone should switch to libav....

Got a link for that quote?

[Q-the-STORM]

Originally Posted by DoctorM

Got a link for that quote?

these are from mid 2011

Originally Posted by jruggle

Well, yeah it's pretty much abandoned. At least I'm not planning on spending my time improving it. It still does have multi-threaded encoding, which the Libav encoder does not have, but in pretty much every other way the Libav encoder is better.

Originally Posted by jruggle

I don't really have time for a release right now. I'm very busy improving the (E-)AC3 encoder in Libav. It's better than Aften now, and I will most likely no longer do additional improvements to Aften other than bug fixes.

from his github page

I am currently working on improving the (E-)AC-3 encoder. The improvements were based initially on my previous work with the Aften project, but at this point the Libav encoder is more advanced.

[LigH]

I faintly remember how Aften developers wondered about improving the quality by learning from LAME. But if libav already surpasses Aften, well ... it's getting more interesting.

[Furiousflea]

Hi there, brilliant developments with the new open dcadec stuff.
I'm currently swapping out for the opus codec, seems to produce fantastic results.

Anyways,

I've noticed that eac3to isn't always automatically selecting the dcadec decoder by default for 7.x tracks as it should, currently on "Dawn Of The Planet Of The Apes", the 7.1 "strange setup" is still decoding with arcsoft...I've set the swtich to force dcadec decoder, but am a little confused as to if this is correct or that maybe there is a reason for this still going the old arcsoft route by default?

Thanks
Great work, didn't think .29 would ever be released but mighty pleased it's here.

[Motenai Yoda]

Originally Posted by Furiousflea

I'm currently swapping out for the opus codec, seems to produce fantastic results.

[OT MODE on]
Be aware that opus encode only at those samplerate

   +----------------------+-----------------+-------------------------+
   | Abbreviation         | Audio Bandwidth | Sample Rate (Effective) |
   +----------------------+-----------------+-------------------------+
   | NB (narrowband)      |           4 kHz |                   8 kHz |
   |                      |                 |                         |
   | MB (medium-band)     |           6 kHz |                  12 kHz |
   |                      |                 |                         |
   | WB (wideband)        |           8 kHz |                  16 kHz |
   |                      |                 |                         |
   | SWB (super-wideband) |          12 kHz |                  24 kHz |
   |                      |                 |                         |
   | FB (fullband)        |      20 kHz (*) |                  48 kHz |
   +----------------------+-----------------+-------------------------+
      (*) Although the sampling theorem allows a bandwidth as large as half
   the sampling rate, Opus never codes audio above 20 kHz, as that is
   the generally accepted upper limit of human hearing.

If input samplerate didn't match opus use the silk resampler.
[OT MODE off]

[Furiousflea]

Originally Posted by Motenai Yoda

[OT MODE on]
Be aware that opus encode only at those samplerate

   +----------------------+-----------------+-------------------------+
   | Abbreviation         | Audio Bandwidth | Sample Rate (Effective) |
   +----------------------+-----------------+-------------------------+
   | NB (narrowband)      |           4 kHz |                   8 kHz |
   |                      |                 |                         |
   | MB (medium-band)     |           6 kHz |                  12 kHz |
   |                      |                 |                         |
   | WB (wideband)        |           8 kHz |                  16 kHz |
   |                      |                 |                         |
   | SWB (super-wideband) |          12 kHz |                  24 kHz |
   |                      |                 |                         |
   | FB (fullband)        |      20 kHz (*) |                  48 kHz |
   +----------------------+-----------------+-------------------------+
      (*) Although the sampling theorem allows a bandwidth as large as half
   the sampling rate, Opus never codes audio above 20 kHz, as that is
   the generally accepted upper limit of human hearing.

If input samplerate didn't match opus use the silk resampler.
[OT MODE off]

Thanks for taking the time to post, it's ok though I read up fully and was aware of this so am only using it with 48Khz sample rate tracks, which is 96-97% of my material. Really appreciate that there's people like yourself willing to take the time to point this out as it could have been a disaster had I not know.

Can't fault this opus codec, quality is simply astonishingly good, only time it needs a little helping hand is for extremely busy audio tracks and it's quite obvious as the average is near the vbr average very quickly in those instances...anyway back on topic...

[Nebudchanezzer]

Originally Posted by Furiousflea

I've noticed that eac3to isn't always automatically selecting the dcadec decoder by default for 7.x tracks as it should, currently on "Dawn Of The Planet Of The Apes", the 7.1 "strange setup" is still decoding with arcsoft...I've set the swtich to force dcadec decoder, but am a little confused as to if this is correct or that maybe there is a reason for this still going the old arcsoft route by default?

The developer is aware of this behaviour, and it is not supposed to be this way, should be fixed in a new version.

[Furiousflea]

Originally Posted by Nebudchanezzer

The developer is aware of this behaviour, and it is not supposed to be this way, should be fixed in a new version.

Good news and reassuring, thanks for your time.

[tebasuna51]

Originally Posted by madshi

I'm not sure why different decoders produce different results in this situation. Sounds weird. If you can find a way which allows me to reproduce the problem on my PC, I would look into it. But without being able to reproduce the situation, there's probably not much I can do.

I make a check about one overlap in Taken 3 BD. This one:

[a03] Audio overlaps for 12ms at playtime 0:12:44

BDInfo Name  Time In      Length
-----------  -------      ------
...
02269.M2TS   0:10:47.188  0:01:56.407
02318.M2TS   0:12:43.596  0:00:31.364
...

1) Decode to wavs the full DTS-HD MA track using ArcSoft and DcaDec.
There are low differences (-84.29 dB) in C channel and time 0:12:43.57729 (47 samples between 0:12:43.577146 and 0:12:43.578125).
I call the full C channel wav like GAPS.wav

2) Decode to wav the dts's extracted and joined from 02269.M2TS and 02318.M2TS.
I call the C channel wav like NO_GAPS.wav.

3) I compared the GAPS.wav and NO_GAPS.wav. See the attached image from NO_GAPS.wav and:

- There are 587 samples less (12.2 ms) in GAPS.wav (at 0:12:43.578). B zone.

- There are 47 samples different (A zone at 0:12:43.577). Seems a interpolation to avoid a click in join point.

- The point when finish the 02269.dts match with the BDInfo cut point 0:12:43.596 (after than 0:12:43.577)

- The first 256 samples from 02318.dts (C zone) exist in GAPS.wav, but maybe are wrong because we can't know if last frame from 02269.dts is the correct one to initialize the first 02318.dts frame.

Conclusions:

a) I don't know for wath the point selected to realize the gap (cut 12 ms) is 0:12:43.577-8, seems more convenient 0:12:43.596 to cut possible wrong samples instead correct samples.
In this case the correct point match with BDInfo but I can't be sure if is always true.

b) I don't know for what the differences between ArcSoft and DcaEnc decode, but zone A is irrelevant at all, maybe rounded differences in interpolation.

c) The more important conclusion:

When we have a "seamless branching" BD and the "skipping identical frames" method is not enough to recover the sync video-audio, and the "Realizing DTS gaps..." is necesary, we can't recover a bitidentical lossless source.
See http://forum.doom9.org/showthread.ph...94#post1600694 for more info.

The join points always are innacurate.

[Smithy]

Originally Posted by Q-the-STORM

as long as you're on a roll with improving eac3to, maybe you can dump aften and encode ac3 with libav?

One dts-hd ma source decoded with eac3to
Two ac3 encodes of the decoded source (both 448kbps), one encoded with eac3to (aften), the other with ffmpeg (libav)

as you can see spectral frequency display shows that aften has cutoff at about 16,5kHz while ffmpeg has it at about 21kHz
(I only had the center in that screenshot, but it applies to all channels...)

that's a lot of lost information...

this must be wrong bandwidth setting by eac3to @ encoding 5.1 448 or 384 kbps.

aftengui or wavtoac3encoder have Bandwidth settings:

the best audio quality is set bandwidth to close by/above the Source frequency are.
it makes no sense to use more bandwidth setting then Source have, to save more Audio Quality and Bitrate for the Real Frequency.

AC3 5.1 @ 448 kbps need a bandwidth of 48 for frequency around 20 kHz (official dolby encoder)
AC3 5.1 @ 384 kbps need a bandwidth of 40 for frequency around 18 kHz (official dolby encoder)

Max. Bandwidth is 60 @ frequency around 24 kHz when is needed for 5.1 @ 640kbps and it works fine in eac3to.
so eac3to use bandwidth around ~30 for 448 and ~20 for 384, and thats killed all frequency above 16,5 kHz (448) and 14,3 kHz (384)

AftenGui ist the better and much faster way for AC3 encoding then eac3to. (i don't know how much fast ffmpeg is)
Surcode for Dolby Digital have a DC-Offset Filter during the compression @ Encoding, but encoding is very slow, no bandwidth option and a cutoff by 20,34 kHz.
madshi is that possible u can add a DC-Offset Filter and Dialog normalisation (-27db) for AC3 encoding in eac3to, maybe in future ?
an LFE lowpass (120hz) Filter is welcome, too.

[DoctorM]

My old 'Soft Encode' software is supposed to be an official DD encoder and it largely agrees: for 5.1 channels @ 384kbps = 18.05khz, but 448-640kbps = 20.30khz. Nothing makes the audio bandwidth go higher than that. Maybe an EX extension is needed (which Soft Encode doesn't support.)

Also, it recommends you always enable the DC high-pass filter, the Bandwidth low-pass filter and the LFE low-pass filter for best results.

[Smithy]

Originally Posted by DoctorM

My old 'Soft Encode' software is supposed to be an official DD encoder and it largely agrees: for 5.1 channels @ 384kbps = 18.05khz, but 448-640kbps = 20.30khz. Nothing makes the audio bandwidth go higher than that. Maybe an EX extension is needed (which Soft Encode doesn't support.)

Also, it recommends you always enable the DC high-pass filter, the Bandwidth low-pass filter and the LFE low-pass filter for best results.

not Allways, these Filters are recommended for lower bitrate to save more Quailty.

So if necessary then use the High-pass or Bandwidth low-pass Filter, but this cut-off frequency, too

LFE Lowpass Filter is only set for High frequency above 120 Hz, so when the Soure was filtered, u don't need lfe low-pass filter again.

The EX extension set only a Flag Matrix for 6.1/7.1 Audio, so the Bandwidth are the same.

EDIT:
many Master Tracks (DTS-HD MA, TrueHD or PCM) have DC offset and many of them are normalized to 0.0 dB .
The First Step bevor AC3 Encoding is:
Fix DC-Offset and Normalize the Complete AudioMix maybe to -2dB/-3dB for safty against Clipping an more DC-Offset from Compression @ AC3 Encode (normalize can be differently from Mix to Mix and wich Bitrate is used)

[tebasuna51]

Originally Posted by Q-the-STORM

... even aften's developer says that nobody should be using aften anymore and everyone should switch to libav....

You are free to use external encoders with eac3to, for instance:

eac3to input stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k output.ac3

[DoctorM]

From Dolby's website:

DC Filter
This parameter determines whether a DC-blocking 3 Hz highpass filter is applied to the main input channels of a Dolby Digital encoder prior to encoding. This parameter is not carried to the consumer decoder. It is used to remove DC offsets in the program audio and would only be switched off in exceptional circumstances.

Lowpass Filter
This parameter determines whether a lowpass filter is applied to the main input channels of a Dolby Digital encoder prior to encoding. This filter removes high-frequency signals that are not encoded. At the suitable data rates, this filter operates above 20 kHz. In all cases it prevents aliasing on decoding and is normally switched on. This parameter is not passed to the consumer decoder.

LFE Lowpass Filter
This parameter determines whether a 120 Hz eighth-order lowpass filter is applied to the LFE channel input of a Dolby Digital encoder prior to encoding. It is ignored if the LFE channel is disabled. This parameter is not sent to the consumer decoder. The filter removes frequencies above 120 Hz that would cause aliasing when decoded. This filter should only be switched off if the audio to be encoded is known to have no signal above 120 Hz.

'Exceptional circumstances' sure doesn't sound like 'only for low bitrate'. The lowpass filter also seems to alter its cutoff with bitrate from the way it is described.

IIRC, the only times you should disable these is if you know you've already filtered these frequencies from your audio track.
Why would you want to waste bitrate on frequencies that cannot be heard? That just makes audible frequencies worse.

[arrgh]

ability to analyse and extract iso files (without mounting them) would be a nice feature for batch conversions with eac3to...

[Q-the-STORM]

Originally Posted by tebasuna51

You are free to use external encoders with eac3to, for instance:

eac3to input stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k output.ac3

that's what I'm doing atm...

[huhn]

Originally Posted by arrgh

ability to analyse and extract iso files (without mounting them) would be a nice feature for batch conversions with eac3to...

windows 10 can mount isos natively. this may helps adding things like that.

[nevcairiel]

Originally Posted by huhn

windows 10 can mount isos natively. this may helps adding things like that.

This is not new in 10, 8.1 can also do that.