eac3to - audio conversion tool

[kasper93]

Yeah, it does, but according to dcadec author. Decoding of DTS Express streams still need some work. But 192KHz is done.

[Nebudchanezzer]

I've posted about this before, but I thoght it hade to do with how eac3to handled overlapping audio in case of a seamless branching disc, but I recently tried it with the new "Taken 3" wich has 5.1 audio and when doing a FLAC-track on the fly (when demuxing) there is diffrences when using either arcsoft or dcadec, but if you extract the DTS-HD MA first and then convert it to flac there is no diffrences.


Comparing:
"L:\Taken.3.Unrated.FLAC.5.1.24bit.from.DTS-HD.MA.arcsoft.flac"
"L:\Taken.3.Unrated.FLAC.5.1.24bit.from.DTS-HD.MA.dcadec.flac"
Compared 332088173 samples.
Differences found: 3670 values, starting at 0:39.455521, peak: 0.0000610 at 0:39.455875, 5ch
Detected offset as 0 samples.

[a03] Audio overlaps for 11ms at playtime 0:00:39. <WARNING>

As you can see the tracks both have the exact same amount of samples and that 3670 samples differs in 5 channels, and that the first difference is found at the same spot that eac3to reports beeing the first overlapping audio, both tracks beeing produced the same way - "on the fly" when demuxing.
Again, if I extract the DTS-HD MA track using eac3to and after that convert to FLAC there is no difference found....

I'm sorry but I cannot provide a sample here, or do not know how as you have to do it on the "fly" when demuxing from a seamless branching blu-ray to reproduce this.

The two lines used for the track:
"C:\Program Files (x86)\eac3to\eac3to.exe" "P:\" 1) 3: "L:\Taken.3.Unrated.FLAC.5.1.24bit.from.DTS-HD.MA.arcsoft.flac" -arcsoft
"C:\Program Files (x86)\eac3to\eac3to.exe" "P:\" 1) 3: "L:\Taken.3.Unrated.FLAC.5.1.24bit.from.DTS-HD.MA.dcadec.flac" -dcadec

And from the eac3to log:
[a03] Decoding with ArcSoft DTS Decoder...
[a03] Decoding with libDcaDec DTS Decoder...

[Libeluratio]

Is the flac you get from the demuxed DTS-HD MA track the same as one of the two flac you get from demuxing "on the fly" from your seamless branching blu-ray ? Instead of flac, have you tried to demux to wavs files and compare the results ?

[Nebudchanezzer]

Is the flac you get from the demuxed DTS-HD MA track the same as one of the two flac you get from demuxing "on the fly" from your seamless branching blu-ray ? Instead of flac, have you tried to demux to wavs files and compare the results ?

No it ain't, but that is to be expected, du to the nature of beeing forced to keep entire DTS-frames when editing the DTS-stream.

Yes, I have tried to demux to wavs instead of FLAC and it doesn't matter, the difference is still there, when doing it "on the fly".

And using a hex-editor to edit the wav-stream to "correct" the first differences the next differences occur at the time of the next warning of overlapping audio in eac3to.

[Libeluratio]

Have you tried demuxing the DTS-HD MA track with makemkv/tsmuxer and compare the 3 results ?

[Nebudchanezzer]

Have you tried demuxing the DTS-HD MA track with makemkv/tsmuxer and compare the 3 results ?

No I haven't since tsMuxer doesn't do flac or wavs or any sort of audio conversion and MakeMKV doesn't do a second pass to fix overlapping audio so that would be pointless as well.

[Sparktank]

MakeMKV doesn't do a second pass to fix overlapping audio

But it does fix overlapping.
If you check the logs, overlapping on segmented files for playlists does get fixed.

[Nebudchanezzer]

But it does fix overlapping.
If you check the logs, overlapping on segmented files for playlists does get fixed.

Yes it does but that is the same as eac3to's "[a03] Skipping identical DTS frames (seamless branching)..."

And has very little to with eac3to's second pass where additional overlapping audio is fixed.

EDIT: was wrong about that the editing of DTS-MA-stream does occur in the second pass.

However, just for the sake of it, comparing a FLAC made "on the fly" with a FLAC made from the already extracted DTS MA-stream:

Differences found in compared tracks.
Non-zero offset detected.

Comparing:
"L:\Taken.3.Unrated.FLAC.5.1.24bit.from.DTS-HD.MA.sonic.flac"
"L:\Taken.3.Unrated.FLAC.5.1.24bit.from.extraced.DTS-HD.MA.sonic.flac"
Length mismatch : 1:55:18.503604 vs 1:55:18.506667, 332088173 vs 332088320 samples.
Compared 332088173 samples, discarded last 147 samples from the longer file.
Differences found within the compared range: 1664758852 values, starting at 0:39.455521, peak: 1.4852911 at 1:04:32.798833, 3ch
Detected offset as -185 samples.

Comparing again with corrected offset...
Compared 332087988 samples, with offset of -185 discarding last/first samples from total of 332088173.
Differences found within the compared range: 1560398561 values, starting at 0:01.756146, peak: 1.4692689 at 20:48.833771, 3ch

For some reason dcadec gave an error and would not decode the extracted DTS MA-stream:
The libDcaDec DTS Decoder reported the error "Bitstream navigation error" while decoding. <ERROR>
Aborted at file position 2495873024. <ERROR>

But both arcsoft and sonic decoded the track fine and were bitperfect to each other.

[DarkSpace]

This sounds like a solution is to join the DTS-HD tracks, decode the joined stream, and only then cut, rather than decoding the streams individually (I remember reading that sometimes the first DTS-HD frame can't be decoded losslessly somewhere on dcadec - link (https://github.com/foo86/dcadec/issues/8#issuecomment-84603411))... not that I actually know what's going on, though, just a guess...

[shark75]

Thanks for your development and the new eac3to version which supports now Dolby Atmos!

If I extract an Dolby Atmos track I got an audio stream called f.e. Audio_4_English.THD+AC3. If I load this track in mkvmerge they split the Atmos track to two separate tracks:

- TrueHD (ID0, Typ: Audio)
- AC3/EAC3 (ID1, Typ: Audio)

Is this correct? If I playback now the mkv file I have two audio tracks - I think THD is the Dolby Atmos track. Do I need the second (AC3/EAC3) track also in my mkv file or can I deactivate the track before I create my mkv file?

Thanks.

[ndjamena]

Blu Rays require the inclusion of an AC3 stream within TrueHD for backward compatibility purposes. Eac3to extracts both from an m2ts to a single file. MKVMerge used to take only the TrueHD stream from m2ts/raw TrueHD files but a recently added feature implemented the option of extracting either or both. Unless you have equipment that can't play back the TrueHD track (or any better codec that you could encode it to) the AC3 track is redundant and can be safely removed.

[madshi]

I've posted about this before, but I thoght it hade to do with how eac3to handled overlapping audio in case of a seamless branching disc, but I recently tried it with the new "Taken 3" wich has 5.1 audio and when doing a FLAC-track on the fly (when demuxing) there is diffrences when using either arcsoft or dcadec, but if you extract the DTS-HD MA first and then convert it to flac there is no diffrences.
Hmmmm... Usually for DTS-HD tracks eac3to reports "skipping identical frames" or something like that, when handling seamless branching titles. And then no 2nd pass is necessary for such tracks. Can you please check if either the old or the new eac3to build (or both) are reporting that? Or do both *not* skip identical frames for this track?

[Nebudchanezzer]

Hmmmm... Usually for DTS-HD tracks eac3to reports "skipping identical frames" or something like that, when handling seamless branching titles. And then no 2nd pass is necessary for such tracks. Can you please check if either the old or the new eac3to build (or both) are reporting that? Or do both *not* skip identical frames for this track?

Both eac3to 3.28 and 3.29 does the same in that regards, reports skipping and does a second pass:
eac3to v3.28
command line: "T:\eac3to.3.28\eac3to.exe" "P:\" 1) 3: "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.28.dtshd"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 4 subtitle tracks, 1:55:16, 53.548p
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: AC3, English, 5.1 channels, 448kbps, 48kHz
5: AC3, Spanish, 5.1 channels, 448kbps, 48kHz
6: AC3, French, 5.1 channels, 448kbps, 48kHz
7: Subtitle (PGS), English
8: Subtitle (PGS), Spanish
9: Subtitle (PGS), French
10: Subtitle (PGS), English
[a03] Extracting audio track number 3...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.28.dtshd"...
[a03] Skipping identical DTS frames (seamless branching)...
[a03] Audio overlaps for 11ms at playtime 0:00:39. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:04:20. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:12:44. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:13:15. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:17:18. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:29:06. <WARNING>
[a03] Audio overlaps for 9ms at playtime 0:30:52. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:33:01. <WARNING>
[a03] Audio overlaps for 5ms at playtime 0:42:04. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:43:08. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:47:51. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:49:17. <WARNING>
[a03] Audio overlaps for 10ms at playtime 0:50:21. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:51:26. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:57:15. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:07:54. <WARNING>
[a03] Audio overlaps for 5ms at playtime 1:13:45. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:14:42. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:16:53. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:22:20. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:23:27. <WARNING>
[a03] Audio overlaps for 11ms at playtime 1:24:31. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:29:43. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:32:04. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:32:25. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:34:20. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:37:09. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:38:37. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:39:47. <WARNING>
[a03] Starting 2nd pass...
[a03] Realizing DTS gaps...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.28.dtshd"...
Video track 2 contains 165878 frames.
eac3to processing took 6 minutes, 39 seconds.
Done.
eac3to v3.29
command line: "C:\Program Files (x86)\eac3to\eac3to.exe" "P:\" 1) 3: "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.dtshd"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 4 subtitle tracks, 1:55:16, 53.548p
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: AC3, English, 5.1 channels, 448kbps, 48kHz
5: AC3, Spanish, 5.1 channels, 448kbps, 48kHz
6: AC3, French, 5.1 channels, 448kbps, 48kHz
7: Subtitle (PGS), English
8: Subtitle (PGS), Spanish
9: Subtitle (PGS), French
10: Subtitle (PGS), English
[a03] Extracting audio track number 3...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.dtshd"...
[a03] Skipping identical DTS frames (seamless branching)...
[a03] Audio overlaps for 11ms at playtime 0:00:39. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:04:20. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:12:44. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:13:15. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:17:18. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:29:06. <WARNING>
[a03] Audio overlaps for 9ms at playtime 0:30:52. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:33:01. <WARNING>
[a03] Audio overlaps for 5ms at playtime 0:42:04. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:43:08. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:47:51. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:49:17. <WARNING>
[a03] Audio overlaps for 10ms at playtime 0:50:21. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:51:26. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:57:15. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:07:54. <WARNING>
[a03] Audio overlaps for 5ms at playtime 1:13:45. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:14:42. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:16:53. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:22:20. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:23:27. <WARNING>
[a03] Audio overlaps for 11ms at playtime 1:24:31. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:29:43. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:32:04. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:32:25. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:34:20. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:37:09. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:38:37. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:39:47. <WARNING>
[a03] Starting 2nd pass...
[a03] Realizing DTS gaps...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.dtshd"...
Video track 2 contains 165878 frames.
eac3to processing took 6 minutes, 55 seconds.
Done.

I'm very curious why eac3to creates different results for the FLAC or WAV(s) depending on wich decoder is used when it comes to seamless branching and overlapping audio.

eac3to "bluray-folder" 1) 3: "audio.flac"

Using a line like that three times, adding either "-dcadec" or "-sonic" creates differences between the results, rather small diffrences but still, diffrences from lossless to lossless.
Take Taken 3 for instance where there is 332088173 samples (332 MILLION) in the FLAC-track, all 3 decoders gives the exact same amount of samples, and between arcsoft and sonic 3650 samples differ, dcadec vs. sonic 3736 differ, dcadec vs. arcsoft 3670 samples differ.

But if you extract the DTS MA track first:

eac3to "bluray-folder" 1) 3: "audio.dtsma"

And then do, using each decoder:

eac3to "audio.dtsma" "audio.flac"

The resulting file is bitidentical (except in the case of Taken 3, dcadec reported an error and exited)

[madshi]

It's a bit sad that although identical frames are being skipped, still audio has to be edited with this Blu-Ray. Normally if identical frames are skipped, no further editing is necessary. Can you double check with eac3to 3.27? Both 3.28 and 3.29 are relatively new and have a change in the code which might explain some different behaviour compared to 3.27. So it would be interesting to see how 3.27 behaves in comparison.

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.

If you do "eac3to audio.dtsma audio.flac", does the resulting file match any of the three files you got from "eac3to bluray-folder 1) 3: audio.flac", using those 3 different decoders? Or is it a forth file, different again to the other 3 files?

[Nebudchanezzer]

It's a bit sad that although identical frames are being skipped, still audio has to be edited with this Blu-Ray. Normally if identical frames are skipped, no further editing is necessary. Can you double check with eac3to 3.27? Both 3.28 and 3.29 are relatively new and have a change in the code which might explain some different behaviour compared to 3.27. So it would be interesting to see how 3.27 behaves in comparison.

3.27 behaves just the same:
eac3to v3.27
command line: "T:\eac3to.3.27\eac3to.exe" "P:\" 1) 3: "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.27.dtshd"
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 4 subtitle tracks, 1:55:16, 53.548p
1: Chapters, 32 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48kHz)
4: AC3, English, 5.1 channels, 448kbps, 48kHz
5: AC3, Spanish, 5.1 channels, 448kbps, 48kHz
6: AC3, French, 5.1 channels, 448kbps, 48kHz
7: Subtitle (PGS), English
8: Subtitle (PGS), Spanish
9: Subtitle (PGS), French
10: Subtitle (PGS), English
[a03] Extracting audio track number 3...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.27.dtshd"...
[a03] Skipping identical DTS frames (seamless branching)...
[a03] Audio overlaps for 11ms at playtime 0:00:39. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:04:20. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:12:44. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:13:15. <WARNING>
[a03] Audio overlaps for 8ms at playtime 0:17:18. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:29:06. <WARNING>
[a03] Audio overlaps for 9ms at playtime 0:30:52. <WARNING>
[a03] Audio overlaps for 6ms at playtime 0:33:01. <WARNING>
[a03] Audio overlaps for 5ms at playtime 0:42:04. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:43:08. <WARNING>
[a03] Audio overlaps for 11ms at playtime 0:47:51. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:49:17. <WARNING>
[a03] Audio overlaps for 10ms at playtime 0:50:21. <WARNING>
[a03] Audio overlaps for 7ms at playtime 0:51:26. <WARNING>
[a03] Audio overlaps for 12ms at playtime 0:57:15. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:07:54. <WARNING>
[a03] Audio overlaps for 5ms at playtime 1:13:45. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:14:42. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:16:53. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:22:20. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:23:27. <WARNING>
[a03] Audio overlaps for 11ms at playtime 1:24:31. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:29:43. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:32:04. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:32:25. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:34:20. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:37:09. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:38:37. <WARNING>
[a03] Audio overlaps for 7ms at playtime 1:39:47. <WARNING>
[a03] Starting 2nd pass...
[a03] Realizing DTS gaps...
[a03] Creating file "L:\Taken.3.Unrated.DTS-HD.MA.5.1.24bit.eac3to.3.27.dtshd"...
Video track 2 contains 165877 frames.
eac3to processing took 6 minutes, 47 seconds.
Done.


If you do "eac3to audio.dtsma audio.flac", does the resulting file match any of the three files you got from "eac3to bluray-folder 1) 3: audio.flac", using those 3 different decoders? Or is it a forth file, different again to the other 3 files?

It is a 4th result, different again from the 3 others, but in my eyes that is to be expected due to the limitations of editing the DTS-stream, the need to insert or remove entire DTS-frames, (512 samples or 10.666..ms of audio), while with RAW audio you could easily add or remove just 1 sample if you wish.

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.

Yes, this is a tough nut to crack, for now I can only think of one thing...(must be done via PM I guess), however I'm a bit tired and headed to bed now.

[hubblec4]

hi madshi

is a support for DTS Express planed?


OK that was a little bit wrong for understanding...
I mean the demux option with the switch "-demux".

mmg supports now the dts-express track.
and when you support the demux which extension is used?

(like dtsma or dtshr) maybe dtsex?

[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)

http://justpic.info/images1/567f/NPpb1.jpg
http://justpic.info/images1/af48/ixnxz.jpg

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

[Motenai Yoda]

I don't think the lowpass frequency is a good point of comparison.

[soneca]

I don't think the lowpass frequency is a good point of comparison.

It may not even be in terms of comparison but if that loss actually happens considering a conversion starting from a source without loss into the ac3 with decent bitrate I guess I should not be this cut in just 16,5Khz.

[Motenai Yoda]

It may not even be in terms of comparison but if that loss actually happens considering a conversion starting from a source without loss into the ac3 with decent bitrate I guess I should not be this cut in just 16,5Khz.

Yep but ac3 is a quite old codec and not well tuned for >96kbps/ch encodings, and you should consider that throwing away very high frequencies (mainly just noise and dither), it's able to raise the quality of super-wideband ones.
Almost all lossy codecs apply a low-pass filter

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

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]

Got a link for that quote?

these are from mid 2011
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.

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]

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]

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

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]

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]

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.php?p=1600694#post1600694 for more info.

The join points always are innacurate.

[Smithy]

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

http://abload.de/img/aftenguibandwidthimuwx.png

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

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]

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

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]

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]

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.

[LigH]

And in other versions one may use any "virtual CDVD driver" (like Daemon Tools); but it doesn't matter: The question was if it would be possible to handle in eac3to only, without mounting to a drive letter. That may be similar to handling any (possibly uncompressed) archive format like ZIP, RAR, TAR like a virtual directory. Already sounds like heavy duty. I wouldn't be surprised if nev replied, that would not be the purpose of eac3to...

[arrgh]

... I wouldn't be surprised if nev replied, that would not be the purpose of eac3to...

probably a lot of work...
I was mentioning it, because MakeMKV can do this...but it muxes directly in to a mkv without the option to do something inbetween, like converting to aac or other things...

[ndjamena]

probably a lot of work...
I was mentioning it, because MakeMKV can do this...but it muxes directly in to a mkv without the option to do something inbetween, like converting to aac or other things...

MakeMKV CAN convert any DVD or Blu Ray compliant audio to aac, ac3 or FLAC while remuxing from DVDs, Blu Rays or an MKV to MKV...

You just need to learn to use profiles properly.

[arrgh]

...
You just need to learn to use profiles properly.

exactly....which is not straight forward...and if you want to slow down, normalize, add an empty subtitle stream, if needed, than it is still necessary (or at least easier) to demux make the changes and remux again...

[Xor]

Please help me, ho to force eac3to to convert to custom fps range?

Example:

C:\eac3to327>eac3to.exe "AUDIO-ENG.ac3" "AUDIO-ENG-24917.ac3" -23.976 -changeTo24.917
FPS value "24.917" not supported.

Or alternative tools to convert to "custom fps" ???

Thanks

[LigH]

If you have to use such strange relations, you shall better wonder why. No professional video studio should use a workflow which results in such nonsense. Are you trying to mix video and audio from different productions, possibly even with different cuts?

[Music Fan]

Or alternative tools to convert to "custom fps" ???
Hybrid (which uses Sox for audio changes) ;
http://forum.doom9.org/showthread.php?t=153035
You have the choice between fps and duration (specify original and destination) and you can change the pitch or not, very convenient.

[hubblec4]

Hi madshi

I have a BD - The Expendables 3 which have a mpls that plays two m2ts files.
The first m2ts file has different audio settings as the second one.

mmg abort with an error message at muxing.
eac3to seems to decode the audio as well but im not sure.

here the logs and a link to a test BD (http://forum.videohelp.com/attachments/31440-1430126678/The%20Expendables%203%20-%20BD_test.7z): first m2ts(0001) is cutted with DGSplit after 15mb, the second m2ts(0002) is untouched (other m2ts files are removed)


log-0001.mpls
eac3to v3.29
command line: eac3to "E:\Videobearbeitung\The Expendables 3\The Expendables 3 - BD_test\BDMV\PLAYLIST\00001.mpls" 1) -log="E:\Videobearbeitung\The Expendables 3\log.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 4 subtitle tracks, 0:00:12, 0.059p
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, German, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 448kbps, 48kHz)
4: TrueHD/AC3, English, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
5: Subtitle (PGS), German
6: Subtitle (PGS), German
7: Subtitle (PGS), German
8: Subtitle (PGS), English


log-only-0001.m2ts
eac3to v3.29
command line: eac3to "E:\Videobearbeitung\The Expendables 3\The Expendables 3 - BD_test\BDMV\STREAM\00001.m2ts" -log="E:\Videobearbeitung\The Expendables 3\log.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 4 subtitle tracks, 0:00:06, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: TrueHD/AC3 (Atmos), German, 7.1 channels, 48kHz
(embedded: AC3 EX, 5.1 channels, 448kbps, 48kHz)
3: TrueHD/AC3 (Atmos), English, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
4: Subtitle (PGS), German
5: Subtitle (PGS), German
6: Subtitle (PGS), German
7: Subtitle (PGS), English



log-Flac-encode
eac3to v3.29
command line: eac3to "E:\Videobearbeitung\The Expendables 3\The Expendables 3 - BD_test\BDMV\PLAYLIST\00001.mpls" 1) 3: eng.flac -log="E:\Videobearbeitung\The Expendables 3\log.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 4 subtitle tracks, 0:00:12, 0.059p
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, German, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 448kbps, 48kHz)
4: TrueHD/AC3, English, 5.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
5: Subtitle (PGS), German
6: Subtitle (PGS), German
7: Subtitle (PGS), German
8: Subtitle (PGS), English
[a03] thd, 48000, 5.1
[a03] Extracting audio track number 3...
[a03] Extracting TrueHD stream...
[a03] Decoding with libav/ffmpeg...
[a03] Encoding FLAC with libFlac...
[a03] [libav] Unknown channel layout. <WARNING>
[a03] [libav] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/MPlayer/incoming/ and contact the ffmpeg-devel mailing list. <WARNING>
[a03] Creating file "eng.flac"...
[a03] The original audio track has a constant bit depth of 21 bits.
Video track 2 contains 287 frames.
eac3to processing took 1 second.
Done.

[tebasuna51]

eac3to seems to decode the audio as well but im not sure.
...
[a03] [libav] Unknown channel layout. <WARNING>

The output is wrong, begin with 6 channels but in next m2ts there are 8 channels and the audio data is missinterpreted still like 6 channel.

See the durations:
00002.m2ts -> 6s (6.006)
00001.m2ts -> 6s (5.964)
00001.mpls -> 12s (11.970)
eng.flac -> 13.133s

[ndjamena]

When I transcode audio to FLAC with MakeMKV and look at the track using MediaInfo I get info about the Channel Positions in the output. If I re-encode the same audio in using EAC3To and look at THAT with MediaInfo the Channel Position Data is missing. Is this a problem with Eac3to, is MediaInfo failing to display some default values or has it been decided that adding whatever headers that info is stored in isn't worth the effort?

(Should I be adding the default values myself? What are the defaults for each and every channel count?)

Channel positions : Front: L C R, Side: L R, Back: L R, LFE