eac3to - audio conversion tool

[loekf]

Maybe a stupid question, but is there a way to force eac3to into silent mode ? I haven't been able to find any commandline option to disable to "buzzer" sound after an error has occurred or the other sound after completion.

I'm using eac3to in a video transcoding tool I'm writing and these sounds are, I won't say annoying.... , but not preferred... ;-)

[TinTime]

I think you can just delete the two wav files that eac3to uses.

[Xorp]

If a Blu-ray has multiple 7.1 tracks, lets say all three lossless/uncompressed varieties, and I want to downmix to 5.1, does it matter which one I use? I'm guessing the PCM track might better since the layout is more straight-forward.

[Snowknight26]

How can there be clipping when encoding an E-AC3 track to AC3? Isn't the E-AC3 track decoded to floating point before being fed to libAften?

[tebasuna51]

Originally Posted by Snowknight26

How can there be clipping when encoding an E-AC3 track to AC3? Isn't the E-AC3 track decoded to floating point before being fed to libAften?

Yes, when you decode a lossy format to float you can have artifacts over the Max. value (can't be present at original source).

If you only decode and recode (without downmix, resample or other audio change) you can safely use the new -no2ndpass parameter because any clip is a encoder artifact.

[Snowknight26]

Originally Posted by tebasuna51

If you only decode and recode (without downmix, resample or other audio change) you can safely use the new -no2ndpass parameter because any clip is a encoder artifact.

So this would be the libAften's fault?:

eac3to v3.16
command line: eac3to.exe ..\temp\asd.eac3 ..\temp\asd.ac3
------------------------------------------------------------------------------
E-AC3, 5.1 channels, 1:40:23, 640kbps, 48khz
The Nero decoder doesn't seem to work, will use libav instead.
Decoding with libav/ffmpeg...
Remapping channels...
Encoding AC3 <640kbps> with libAften...
Creating file "..\temp\asd.ac3"...
Clipping detected, a 2nd pass will be necessary.  <WARNING>
Starting 2nd pass...
Decoding with libav/ffmpeg...
Remapping channels...
Encoding AC3 <640kbps> with libAften...
Creating file "..\temp\asd.ac3"...
eac3to processing took 7 minutes, 42 seconds.
Done.

[Mtz]

madshi, can you implement extracting the subtitles from HDTV recordings? The subtitles can be viewed if playing the files with VLC.

Here is one example with DVB Subtitles.

TS, 1 video track, 4 audio tracks, 8 subtitle tracks, 0:02:40, 50i
1: h264/AVC, 1080i50 (16:9)
2: MP2, English, 2.0 channels, 256kbps, 48khz, -903ms
3: MP2, Polish, 2.0 channels, 256kbps, 48khz, 18ms
4: MP2, Hungarian, 2.0 channels, 256kbps, 48khz, -149ms
5: MP2, Czech, 2.0 channels, 256kbps, 48khz, -68ms
6: Subtitle (DVB), Dutch
7: Subtitle (DVB), Serbian
8: Subtitle (DVB), Slovenian
9: Subtitle (DVB), Croatian
10: Subtitle (DVB), Swedish
11: Subtitle (DVB), Danish
12: Subtitle (DVB), Romanian
13: Subtitle (DVB), Norwegian
[v01] The video track contains the (probably incorrect) "full range" flag.  <WARNING>
This subtitle conversion is not supported.  <ERROR>

Here is one example with teletext subtitle and DVB Subtitle.
Here is one sample with teletext subtitle.
Here is one TRP file with no subtitles.

Also, the audio delay is not correct on all files.

enjoy,
Mtz

[tebasuna51]

Originally Posted by Snowknight26

So this would be the libAften's fault?:

Fault?
For what fault?
For what libAften?

All is ok.

[Snowknight26]

You said that if there is any clipping when decoding then reencoding (in one step), its the encoders fault. So in this case its libAften.. which isn't plausible.

[tebasuna51]

The clip is at decoder pass (not encoder) and is normal with lossy formats.

[StephenB]

Originally Posted by tebasuna51

The clip is at decoder pass (not encoder) and is normal with lossy formats.

Do you know why it happens though?

Is this because the decoder is not quite compliant?

[tebasuna51]

Originally Posted by StephenB

Do you know why it happens though?

Is this because the decoder is not quite compliant?

Because is lossy compression.
If the source file have some peaks at 0 dB, some of them are encoded/decoded to obtain peaks between -0.1dB (no problem) and +0.1dB (clip to -> 0 dB)

The clipped peak recover the original volume, maybe the problem is in the peak at -0.1 dB.

If you want exact translation you need lossless encoders.

[StephenB]

Originally Posted by tebasuna51

Because is lossy compression.
If the source file have some peaks at 0 dB, some of them are encoded/decoded to obtain peaks between -0.1dB (no problem) and +0.1dB (clip to -> 0 dB)

The clipped peak recover the original volume, maybe the problem is in the peak at -0.1 dB.

If you want exact translation you need lossless encoders.

Well, I do understand that lossy codecs are not exact.

But it seems to me that a well designed encoder would not exceed the clipping limit on any signal it encodes.

After all, all compliant decoders should obtain the same (non-exact) result (at least with standard floating point hardware), so it seems to me that the encoder algorithm can/should prevent the clipping.

[StephenB]

Madshi,

It looks like SOPHOS antivirus software is generating a false positive on EAC3TO V3.16 You can see this here:

http://virscan.org/report/aa2d3e03ec...f9438f232.html

[Jeff Flowerday]

Originally Posted by StephenB

Madshi,

It looks like SOPHOS antivirus software is generating a false positive on EAC3TO V3.16 You can see this here:

http://virscan.org/report/aa2d3e03ec...f9438f232.html

Well then report it to them as a false positive not madshi, he has no control over their virus scanner.

[jruggle]

Originally Posted by StephenB

Well, I do understand that lossy codecs are not exact.

But it seems to me that a well designed encoder would not exceed the clipping limit on any signal it encodes.

After all, all compliant decoders should obtain the same (non-exact) result (at least with standard floating point hardware), so it seems to me that the encoder algorithm can/should prevent the clipping.

An AC-3 encoder actually has very little control over this. I guess it could, in theory, imploy an internal decoder and clipping detection, try to determine the frequency of clipped areas, then add bits to those frequencies using delta bit allocation, hoping removing bits from other places would not cause clipping elsewhere. I very highly doubt that Dolby's encoder even does this, as it would be very impractical, not completely reliable, and would decrease the quality.

It is explictly mentioned in the AC-3 specification that the output signal from the decoder may exceed 100%. Here is the exact text from A/52B section 7.9.4:
"Since the output signal consists of the original signal plus coding error, it is possible for the output signal to exceed 100 percent level even though the original input signal was less than or equal to 100 percent level."

It is up to the decoder what to do about this. Most will probably clip the results though. The specification mentions it so that those implementing a decoder will not assume a certain output range in their calculations.

[StephenB]

Originally Posted by StephenB

Madshi,

It looks like SOPHOS antivirus software is generating a false positive on EAC3TO V3.16 You can see this here:

http://virscan.org/report/aa2d3e03ec...f9438f232.html

SOPHOS says they have fixed this.

[StephenB]

Originally Posted by jruggle

An AC-3 encoder actually has very little control over this. I guess it could, in theory, imploy an internal decoder and clipping detection, try to determine the frequency of clipped areas, then add bits to those frequencies using delta bit allocation, hoping removing bits from other places would not cause clipping elsewhere. I very highly doubt that Dolby's encoder even does this, as it would be very impractical, not completely reliable, and would decrease the quality.

It is explictly mentioned in the AC-3 specification that the output signal from the decoder may exceed 100%. Here is the exact text from A/52B section 7.9.4:
"Since the output signal consists of the original signal plus coding error, it is possible for the output signal to exceed 100 percent level even though the original input signal was less than or equal to 100 percent level."

It is up to the decoder what to do about this. Most will probably clip the results though. The specification mentions it so that those implementing a decoder will not assume a certain output range in their calculations.

It still seems odd to me that professionally mastered AC3 tracks on commercial disks would be encoded so that every AC3 decoder on the planet has to clip.

[ron spencer]

quick question...if I am changing 640 AC3 to 448 with EAC3to and the 640 is stated to have bit depth of 24 bits, will the encode via libAften to 448 reduce bit depth to 16 automatically or must it be specified first?

thanks

-rs

[Snowknight26]

Lossy formats don't have a bit-depth.