eac3to v3.24 Bugs & Improvements

[tebasuna51]

In this first post I want put a summary of Bugs & Improvements.
Next post can have most extensive descriptions.
Feel free to add comments or other Bugs & Improvements, after discussion I can add to the summary.

Downmix bugs

- When source is 6.1 the -down6 don't work fine. [OK in 3.25]
Workaround: eac3to input6.1 output5.1 -0,1,2,3,5,6,4 -down6

Downmix improvements (http://forum.doom9.org/showthread.php?p=1600695#post1600695)

- Use not normalized matrix to downmix and let the second pass do the normalize if necessary. [OK in 3.25]

- Accept other channel configuration than 5.1 to -down2 [OK in 3.26]

- Add a new parameter for simple stereo downmix. [OK in 3.25]

Decoder bugs

- Nero AC3 decoder fail sometimes, let libav default for AC3. Sample (http://www.sendspace.com/file/7wly61) [OK in 3.25, improved libav in 3.26]

- TrueHD decoder problems. [OK in 3.25]

- AC3 3.0 decode with FR and FC changed (nero and libav) [OK in 3.25]
Workaround: eac3to 3.0chan.ac3 output.wav -0,2,1

- DTS-ES 6.1 -> WAV 5.1 (libav) finish with channel mask of 0x70f (6.1) instead of the expected 0x60f (5.1) (http://forum.doom9.org/showthread.php?p=1569705#post1569705) [OK in 3.25]

Decoder improvemets

- Actualize libav decoder (maybe solve the TrueHD problems). [OK in 3.25, improved libav in 3.26]

- Maybe add AAC decoder to libav.

Encoder bugs

- NeroAacEnc fail sometimes when piped directly by eac3to, work always when use the OS pipe.
Workaround: eac3to input stdout.wav | NeroAacEnc -q 0.5 -ignorelength -if - -of output.m4a

Encoder improvements

- Support for Aften encode other inputs than 2.0/5.1 [OK in 3.25]
Workaround: eac3to input3-4-5channels stdout.wav | Aften -b 640 -readtoeof 1 - output.ac3

Issues with gaps/overlaps

- See next post. [OK in 3.25]

Info

- Document all the working parameters.

- Support SRT subtitles when using -check [OK in 3.25]

- Remove bit-depth display for lossy tracks [OK in 3.25]

- Assign language "english" to mkv tracks without languaje info (MKV rules). [OK in 3.25]

- Remove the message about 24 fps.

- In -test remove the check of MKVtoolnix (I think is not necessary). [OK in 3.25]

Others

- Bad checking between edit position and duration. (http://forum.doom9.org/showthread.php?p=1600983#post1600983) [OK in 3.25]

- Defined framerate conversion is ignored in some circumstances. (http://forum.doom9.org/showthread.php?p=1600986#post1600986)

[tebasuna51]

Issues with gaps/overlaps

First explain the gaps/overlaps audio problems based in the different duration of video and audio frames.
Supose 2 m2ts with 25 fps video and one ac3 track (for easy numbers).
And want extract the full ac3 stream.

See the attached image with 3 options:

https://forum.doom9.org/attachment.php?attachmentid=13080&stc=1&d=1772475505

A) The second m2ts begin with a new audio. For instance a initial credit added before the main movie.
Now we can't recover the perfect sync without recode the audio.

B) The second m2ts begin with the next audio frame (maybe when the delay is low).
Now we preserve the sync only adding the second audio stream to the first.

C) The second m2ts begin with a duplicated frame of the ac3.
Now we need delete the duplicated frame before add the two streams.

Go with a real sample, extract the english ac3 track from Brave BD.
(I'm using the spanish angle but is the same for this track).
There are 9 .m2ts and I extract (eac3to) the ac3 for each file (t01.ac3 to t09.ac3).

I analyze video and audio durations and check if there are ac3 frames duplicated (numbers in ms.):
Audio Dur_Aud Dur_Vid Dif_A-V Acu_Aud Acu_Vid Acu_A-V
------- -------- -------- -------- -------- -------- --------
t01.ac3 44608 44586 22 44608 44586 22
t02.ac3 28288 28278 10 72896 72864 32 Initial frame duplicated
t03.ac3 182496 182474 22 255392 255338 54
t04.ac3 58048 58016 32 313440 313355 85 Initial frame duplicated
t05.ac3 4888320 4888300 20 5201760 5201655 105 Initial frame duplicated
t06.ac3 46272 46255 17 5248032 5247909 123
t07.ac3 324288 324282 6 5572320 5572192 128 Initial frame duplicated
t08.ac3 34912 34910 2 5607232 5607102 130
t09.ac3 45152 45128 24 5652384 5652230 154
Then the full audio is 154 ms longer than video.

I delete the duplicated frames and repeat the check:
Audio Dur_Aud Dur_Vid Dif_A-V Acu_Aud Acu_Vid Acu_A-V
------- -------- -------- -------- -------- -------- --------
t01.ac3 44608 44586 22 44608 44586 22
t02.ac3 28256 28278 -22 72864 72864 0
t03.ac3 182496 182474 22 255360 255338 22
t04.ac3 58016 58016 0 313376 313355 21
t05.ac3 4888288 4888300 -12 5201664 5201655 9
t06.ac3 46272 46255 17 5247936 5247909 27
t07.ac3 324256 324282 -26 5572192 5572192 0
t08.ac3 34912 34910 2 5607104 5607102 2
t09.ac3 45152 45128 24 5652256 5652230 26
Now the audio finish with only 26 ms. of difference.
And always the difference is less than 32 ms. (ac3 frame duration)
If we join the ac3 files we have a perfect stream in sync with the video.

If I use eac3to to extract the full stream from the .mpls I have the WARNINGS:
[a03] Audio overlaps for 22ms at playtime 0:00:45. <WARNING>
[a03] Audio overlaps for 10ms at playtime 0:01:13. <WARNING>
[a03] Audio overlaps for 22ms at playtime 0:04:15. <WARNING>
[a03] Audio overlaps for 31ms at playtime 0:05:13. <WARNING>
[a03] Audio overlaps for 20ms at playtime 1:26:42. <WARNING>
[a03] Audio overlaps for 18ms at playtime 1:27:28. <WARNING>
[a03] Audio overlaps for 6ms at playtime 1:32:52. <WARNING>
And after realize the gaps/overlaps finish with a ac3 with the same length than first method.
But aren't identical.
Seems eac3to delete initial frame in t02.ac3 (correct) but also in t03.ac3 (incorrect).

Delete a correct frame, or preserve duplicated frames, most the times is unnoticeable, but sometimes can be detected like here (http://forum.doom9.org/showthread.php?p=1584532#post1584532).
Also for a perfect decode of the audio, a frame need a correct initialization from the previous frame and, if isn't the correct one can produce glitches, like was detected here (http://forum.doom9.org/showthread.php?p=1587184#post1587184).

For this BD you can obtain the correct english ac3 stream with a .bat file like this:
@echo off
"YourPathTo\eac3to.exe" 00952.m2ts 2: t01.ac3
"YourPathTo\eac3to.exe" 00960.m2ts 2: t02.ac3 -32ms
"YourPathTo\eac3to.exe" 00954.m2ts 2: t03.ac3
"YourPathTo\eac3to.exe" 00961.m2ts 2: t04.ac3 -32ms
"YourPathTo\eac3to.exe" 00956.m2ts 2: t05.ac3 -32ms
"YourPathTo\eac3to.exe" 01042.m2ts 2: t06.ac3
"YourPathTo\eac3to.exe" 00958.m2ts 2: t07.ac3 -32ms
"YourPathTo\eac3to.exe" 00968.m2ts 2: t08.ac3
"YourPathTo\eac3to.exe" 00959.m2ts 2: t09.ac3
copy /B t01.ac3 + t02.ac3 + t03.ac3 + t04.ac3 + t05.ac3 + t06.ac3 + t07.ac3 + t08.ac3 + t09.ac3 english.ac3
pause

I test the same procedure with DTS and DTS-HD and seems work fine.

BTW, not always delete the duplicated frames can be enough to mantain the sync, because can have type A join, then I suggest:
- First check if there are a duplicate frame and delete.
- If the accumulated delay is greater than the audio frame duration (not than half duration like seems work now eac3to) then delete a frame.

[tebasuna51]

Downmix -down2 and simple stereo for all standard channel configuration.

If exist the parameter -mixlfe add:
FL' = ... + 0.7071 x LFE
FR' = ... + 0.7071 x LFE

2.1
Stereo
FL' = FL
FR' = FR

2/1 or 2/1.1
Stereo
FL' = FL + 0.7071 x BC
FR' = FR + 0.7071 x BC
Dpl
FL' = FL + 0.7071 x BC
FR' = FR - 0.7071 x BC

2/2 or 2/2.1
Stereo
FL' = FL + BL
FR' = FR + BR
Dpl
FL' = FL + 0.8660 x BL + 0.5000 x BR
FR' = FR - 0.5000 x BL - 0.8660 x BR

3/0 or 3/0.1
Stereo
FL' = FL + 0.7071 x FC
FR' = FR + 0.7071 x FC

3/1 or 3/1.1
Stereo
FL' = FL + 0.7071 x FC + 0.7071 x BC
FR' = FR + 0.7071 x FC + 0.7071 x BC
Dpl
FL' = FL + 0.7071 x FC + 0.7071 x BC
FR' = FR + 0.7071 x FC - 0.7071 x BC

3/2 or 3/2.1
Stereo
FL' = FL + 0.7071 x FC + BL
FR' = FR + 0.7071 x FC + BR
Dpl
FL' = FL + 0.7071 x FC + 0.8660 x BL + 0.5000 x BR
FR' = FR + 0.7071 x FC - 0.5000 x BL - 0.8660 x BR

3/2/1 or 3/2/1.1
Stereo
FL' = FL + 0.7071 x FC + BL + 0.7071 x BC
FR' = FR + 0.7071 x FC + BR + 0.7071 x BC
Dpl
FL' = FL + 0.7071 x FC + 0.8660 x BL + 0.5000 x BR + 0.7071 x BC
FR' = FR + 0.7071 x FC - 0.5000 x BL - 0.8660 x BR - 0.7071 x BC

3/2/2 or 3/2/2.1
Stereo
FL' = FL + 0.7071 x FC + BL + SL
FR' = FR + 0.7071 x FC + BR + SR
Dpl
FL' = FL + 0.7071 x FC + 0.8660 x (BL + SL) + 0.5000 x (BR + SR)
FR' = FR + 0.7071 x FC - 0.5000 x (BL + SL) - 0.8660 x (BR + SR)

[nixo]

Regular stereo downmix was discussed some time ago:
http://forum.doom9.org/showthread.php?p=1386125#post1386125

If it's not too much hassle, I'd still like to see it implemented.

--
Nikolaj

[nautilus7]

A very good adition would be the header patching for dts-hd "strange setup" files, so the arcsoft decoder can decode them properly. User xkodi, has made a lot of posts regarding this.

[tebasuna51]

Regular stereo downmix was discussed some time ago:

I can put all the options in Downmix post.

A very good adition would be the header patching for dts-hd "strange setup" files, so the arcsoft decoder can decode them properly. User xkodi, has made a lot of posts regarding this.
In my opinion ArcSoft decode properly the dts-hd "strange setup" now.

[madshi]

- NeroAacEnc fail sometimes when piped directly by eac3to, work always when use the OS pipe.
Is there a way to reliably reproduce this?

In my opinion ArcSoft decode properly the dts-hd "strange setup" now.
You mean there's a new decoder dll version from ArcSoft which fixes the problem? Which version number does that have?

[Overdrive80]

You mean there's a new decoder dll version from ArcSoft which fixes the problem? Which version number does that have?

Maybe, Tebasuna51 is referring to 1.1.0.8 version.

[filler56789]

Suggested improvements:

--- use dcaenc besides Surcode

--- use fhgaacenc and qaac besides Nero AAC Encoder

--- look for MKVtoolnix files in the PATH environment-variable, not only in the Windows Registry

--- NO "undocumented" options anymore ;) :)

[Overdrive80]

Suggested improvements:

- Sonic just doesn´t exist therefore it delevelop is discontinued. Maybe Roxio encoder is alternative, isnt?

[Snowknight26]

Suggestion:
- Use ffmpeg/libavformat for MKV muxing
- Being able to output to NUL in Windows
- Support SRT subtitles when using -check
- Remove bit-depth display for lossy tracks

Bug fixes:
- Incorrect container frame rate for seamlessly-branched M2TS files

[nautilus7]

Suggestion:
Use ffmpeg/libavformat for MKV muxing.+1

Nobody uses haali anymore.

[sneaker_ger]

- support AAC ADTS and MP4 input and output
- support input from pipe
- support timestretching and pitch change

[madshi]

Guys, as I said in the eac3to thread, bugfixes and *SMALL* improvements, only. Some of what you're suggesting would be major changes.

[Atak_Snajpera]

madshi don't forget about my two improvements

1) switch for custom block size for flac encoder (required by lossywav)

2) support for stdin ( eac3to.exe input.stdin ... )

[sneaker_ger]

Guys, as I said in the eac3to thread, bugfixes and *SMALL* improvements, only. Some of what you're suggesting would be major changes.

I've read that, but I thought we'd let tebasuna and you evaluate what's minor and what's not.

Feel free to add comments or other Bugs & Improvements, after discussion I can add to the summary.

[sshd]

4-channel FLAC is identified as FLAC 3/1, but the FLAC format specifies it to be 2/2.

This messes up channel mapping for 4 channel surround.

An option to convert it to FLAC 3/2 would be nice.

[tebasuna51]

- "NeroAacEnc fail sometimes when piped directly by eac3to" - Is there a way to reliably reproduce this?
I don't know.

- You mean there's a new decoder dll version from ArcSoft which fixes the problem?
Nope, I use 1.1.0.0. We can decode to WAV Lss,Rss,Lsr,Rsr -> SL,SR,BL,BR, but decode Ls,Rs,Lsr,Rsr to WAV is not possible because don't exist the equivalent channels for Ls,Lr. Then the mix what ArcSoft put in SL,SR,BL,BR is correct for me.

- use dcaenc besides Surcode, use fhgaacenc and qaac besides Nero AAC Encoder.
You can use this encoders with 'pipe'.

- look for MKVtoolnix files in the PATH environment-variable, not only in the Windows Registry
I don't know for what eac3to need MKVtoolnix.

- NO "undocumented" options anymore.
OK.

- Sonic just doesn´t exist therefore it delevelop is discontinued. Maybe Roxio encoder is alternative, isnt?
I don't know, but maybe we can use only free soft.

- Use ffmpeg/libavformat for MKV muxing
Maybe. I don't know if is possible and the benefits, please explain.

- Being able to output to NUL in Windows
Please explain for what.

- Support SRT subtitles when using -check
OK. Maybe is little info bug.

- Remove bit-depth display for lossy tracks
OK. I have the same opinion.

- support AAC ADTS and MP4 input and output
OK with input (already in my first post). ADTS output is now possible with qaac and fhgaacenc 'pipe'.

- support input from pipe/support for stdin ( eac3to.exe input.stdin ... )
I don't know if is easy to implement. Please explain the usage.

- support timestretching and pitch change
Is interesting but maybe not easy. I don't know a good free soft to do this with audio multichannel. Pending.

- switch for custom block size for flac encoder (required by lossywav)
Encoders have many parameters and eac3to can't manage all. When I need a special parameter for AC3 I use the 'pipe' method. BTW, madshi have the last decission.

- 4-channel FLAC is identified as FLAC 3/1, but the FLAC format specifies it to be 2/2.
I can't reproduce this. A 2/2 wav encoded to FLAC is recognized, and decoded, with eac3to like 2/2.

- An option to convert it to FLAC 3/2 would be nice.
Please suggest generic improvements, eac3to can't do all audio jobs.

[Sparktank]

Suggestion:

Extract chapters to a text file in IfoEdit/OGG|FrameCount/TimeCode format.

[Atak_Snajpera]

@tebasuna51
eac3to.exe input.flac output.stdout I lossywav.exe - -- I eac3to.exe input.stdin output.lossy.flac

regarding -B 512/1024/... switch this should probably be the easiest thing to implement on madshi's list since eac3to uses libflac. he just have to expose that to user.

[Brazil2]

Regular stereo downmix was discussed some time ago:
http://forum.doom9.org/showthread.php?p=1386125#post1386125

If it's not too much hassle, I'd still like to see it implemented.
+1

Regular stereo downmix is a very basic feature that is really missing in eac3to.

[filler56789]

- look for MKVtoolnix files in the PATH environment-variable, not only in the Windows Registry
I don't know for what eac3to need MKVtoolnix.


Me neither, LOL
eac3to -test
eac3to (v3.24) is installed
Nero Audio Decoder (Nero 7) works fine
ArcSoft DTS Decoder (1.1.0.1) works fine
Sonic Audio Decoder (3.24.0.0) doesn't seem to be installed
Haali Matroska Muxer doesn't seem to be installed
http://haali.net/mkv
Nero AAC Encoder (1.5.4.0) is installed
Surcode DTS Encoder doesn't seem to be installed
http://www.surcode.com
MkvToolnix doesn't seem to be installed
http://www.bunkus.org/videotools/mkvtoolnix

[pandv2]

Well, this is my bug report. One easy to fix, I hope: bad checking between edit position and duration.

With this command line:

"C:\MasProgramas\eac3to\eac3to.exe" "C:\Temp\VideoSynch\Vsy_Segmento_Aud_000.ac3" "C:\Temp\VideoSynch\Vsy_Segmento_Aud_000_sil001.ac3" -silence -edit=0:00:00.544,1088ms

Eac3to shows a error:

Invalid edit format "edit=0:00:00.544,1088ms

And also with: -edit=0:00:00.544,544ms

but not with: -edit=0:00:00.544,543ms

If the silence duration to insert, is bigger than the insertion position, eac3to trows a error. So:

-edit=0:00:00.789,800 is a error
-edit=0:00:00.789,788 is not

[pandv2]

And the second one: defined framerate conversion is ignored in some circumstances.

eac3to v3.24
command line: "C:\MasProgramas\eac3to\eac3to.exe" "G:\Sc\H1.mkv" 2:"C:\Temp\VideoSynch\Vsy_Tmp_Audio_1.ac3" -320 -25.000 -changeTo23.976
------------------------------------------------------------------------------
MKV, 1 video track, 1 audio track, 1 subtitle track, 0:22:43, 25p
1: h264/AVC, 1080p24 /1.001 (16:9)
2: MP3, Spanish, 2.0 channels, 320kbps, 48kHz, 1500ms
"Audio en Castellano"
3: Subtitle (ASS), Spanish, "Subtítulos para el audio Castellano"
[v01] The video bitstream framerate field doesn't match the container framerate. <WARNING>
[a02] Extracting audio track number 2...
[a02] Decoding with libav/ffmpeg...
[a02] Applying RAW/PCM delay...
[a02] Encoding AC3 <320kbps> with libAften...
[a02] Clipping detected, a 2nd pass will be necessary. <WARNING>
[a02] Creating file "C:\Temp\VideoSynch\Vsy_Tmp_Audio_1.ac3"...
[a02] Starting 2nd pass...
[a02] Extracting audio track number 2...
[a02] Decoding with libav/ffmpeg...
[a02] Applying RAW/PCM delay...
[a02] Encoding AC3 <320kbps> with libAften...
[a02] Applying -0,21dB gain...
[a02] Creating file "C:\Temp\VideoSynch\Vsy_Tmp_Audio_1.ac3"...
Video track 1 contains 34071 frames.
eac3to processing took 23 seconds.
Done.


You can see I am trying to convert a mp3 track from a mkv video from 25.000 to 23.976. But the video is a 23.976 avc1 encode, converted by the mkv container to a 25.000 play speed.
Eac3to doesn't does the framerate conversion.

[tebasuna51]

@tebasuna51
eac3to.exe input.flac output.stdout | lossywav.exe - -- | eac3to.exe input.stdin output.lossy.flac
Wow!

Don't work this?:

flac -d -c input.flac | lossywav.exe - -- | flac -b 512 -o output.lossy.flac -

[Atak_Snajpera]

try again with large flac (2h41m avatar soundtrack for example).

[tebasuna51]

Maybe:

flac -d -c input.flac | lossywav.exe - -- | flac -b 512 -o output.lossy.flac --ignore-chunk-sizes -

[Atak_Snajpera]

nope. flac cannot decode to 4gb+ wavs.

[Brazil2]

nope. flac cannot decode to 4gb+ wavs.
Use this one ;)
http://www.hydrogenaudio.org/forums/index.php?showtopic=84014&view=findpost&p=725304

[nada2k]

Hello, maybe you can have a look at point 1 listed in this topic (http://forum.doom9.org/showthread.php?p=1461841#post1461841)? The sample there can be decoded in eac3to v3.21, but not in v3.22 and v3.24.

[tebasuna51]

- Extract chapters to a text file in IfoEdit/OGG|FrameCount/TimeCode format.
I think the actual output format with only Timecodes is the standard. Is easy convert to the suggested format.

- Bad checking between edit position and duration.
OK.

- Defined framerate conversion is ignored in some circumstances.
OK. I can't make a test but maybe madshi can explain or solve the problem.

- eac3to.exe input.flac output.stdout | lossywav.exe - -- | eac3to.exe input.stdin output.lossy.flac -block 512
I hope than a mod flac version can solve the problem, because I think is to much effort for eac3to to solve a particular case.

- The (MLP) sample there can be decoded in eac3to v3.21, but not in v3.22 and v3.24. (http://forum.doom9.org/showthread.php?p=1461841#post1461841)
I hope a libav update can solve the problem. Pending.

Please comments about Issues with gaps/overlaps (http://forum.doom9.org/showthread.php?p=1600694#post1600694)

[sshd]

- 4-channel FLAC is identified as FLAC 3/1, but the FLAC format specifies it to be 2/2.
I can't reproduce this. A 2/2 wav encoded to FLAC is recognized, and decoded, with eac3to like 2/2.

- An option to convert it to FLAC 3/2 would be nice.
Please suggest generic improvements, eac3to can't do all audio jobs.

Try ripping one of these movies:
- Edward Scissorhands
- Journey to the Center of the Earth (1959)
- Poseidon Adventure

eac3to will correctly identify the audio as 3/1.

When saving the audio as FLAC it is saved as FLAC 3/1. Unfortunately there is no such thing. FLAC with 4 channels is by FLAC specification 2/2.

Any player that follows the FLAC specification, will play the center channel in the right surround speaker.

Only option to play this correctly (with FLAC) is to duplicate the surround channel and save as FLAC 3/2.

[filler56789]

Only option to play this correctly (with FLAC) is to duplicate the surround channel and save as FLAC 3/2.

Another option is to drop FLAC and start using WavPack ;) or MLP. :)

[tebasuna51]

Then isn't a eac3to problem.
I suggest you decode to wav and after use BeHappy to encode to flac with this .avs:

a=RaWavSource("YourPathTo\decoded.wav")
fl = GetChannel(a, 1)
fr = GetChannel(a, 2)
fc= GetChannel(a, 3)
bl = GetChannel(a, 4).Amplify(0.7071)
br = bl
MergeChannels(fl, fr, fc, bl, br)

[b66pak]

ac3 3.0 is decoded with center channel switched with the right one...

workaround:

eac3to 3.0.ac3 audio.wav -0,2,1,3,4,5

make -down2 as simple stereo and not dpl...
_

[tebasuna51]

ac3 3.0 is decoded with center channel switched with the right one...
OK. Verified with -nero and -libav, seems a regression, longtime ago I check all channel configs.

make -down2 as simple stereo and not dpl...
Nope, but a new parameter to simple stereo.
Downmix matrix already included in third post.

[doom-nine]

eac3to cannot recognize the DDPlus audios in the bluray disk. Hope it could be solved in the new version.

[Atak_Snajpera]

Use this one ;)
http://www.hydrogenaudio.org/forums/index.php?showtopic=84014&view=findpost&p=725304

it still cannot decode to 4gb+ wavs (ERROR. wav too big...)
Also encoded preprocessed 4Gb+ wav is odd. (no seek bar and duration in winamp)

http://i.imgur.com/FFNCI.png

but the same preprocessed wav encoded by eac3to is ok

also the same problem in madflac
http://i.imgur.com/ig25Q.png

I would really prefer to use eac3to instead of outdated/buggy flac.exe but i need at least -block switch

[xkodi]

- You mean there's a new decoder dll version from ArcSoft which fixes the problem?
Nope, I use 1.1.0.0. We can decode to WAV Lss,Rss,Lsr,Rsr -> SL,SR,BL,BR, but decode Ls,Rs,Lsr,Rsr to WAV is not possible because don't exist the equivalent channels for Ls,Lr. Then the mix what ArcSoft put in SL,SR,BL,BR is correct for me.

i completely don't agree with that, because there is no "strange setup" file that contains a recording which actually uses the real channel order to which the file is set - take even for example "Qtec Hi-Definition Reference Disc" - it has the same 24-bit/96kHz multi-channel track in LPCM, TrueHD and DTS-HD MA which is set to "strange setup" - LPCM and TrueHD are correctly decoded bit-perfect, but Arcsoft 1.1.0.0 decode is not bit-perfect. however, the channel order seems wrongly set in the DTS-HD MA to "strange setup" and it doesn't reflect the true channel order of the recording inside - same applies for me for Scandinavian version of "Sin City" that is another famous example with "strange setup" files. so, if we assume Arcsoft 1.1.0.0 decodes the DTS-HD MA sample from "Qtec Hi-Definition Reference Disc" correctly as "tebasuna51" believes then it means that any existing LPCM and TrueHD decoder is wrong, because the same track in LPCM and TrueHD from that demo-disc is decoded in way different than Arcsoft 1.1.0.0.

BTW, if "madshi" is interested to implement a fix for that, he can contact me to give him simple proof-of-concept code for DTS-HD MA header-parching in C that switches the channel order as currently 'eaqc3to' do for DTS files - i guess that way implementing the real fix in 'eac3to' would be matter of minutes. also, when 'eac3to' decodes all 8 channels of DTS-HD MA "strange setup" bit-perfect then people like "tebasuna51" that believe that's wrong can mix them to their liking. however, it's very simple and believe no any code example is necessary when check the document here:

http://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf

and just change the channel order bits and re-calculate the CRC.

[BigPines]

I have uploaded a couple of files that illustrate the Brave/Finding Nemo TrueHD bug.

The first sample file is one I demuxed from Brave 3D: http://netload.in/dateiJYstyUhRic/test.thd+ac3.htm

eac3to test.thd+ac3 audio.wavs

TrueHD/AC3, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
Extracting TrueHD stream...
Decoding with libav/ffmpeg...
Remapping channels...
Writing WAVs...
libav Substream 0 parity check failed
libav Substream 0 checksum failed
libav Substream 0 length mismatch.
The libav decoder reported error -1 while decoding.
Aborted at file position 262144.

The second file is an actual m2ts from Brave 3D: http://netload.in/dateiQUPHaqw7BA/00950.m2ts.htm

eac3to 00950.m2ts audio.wavs

M2TS, 1 video track, 6 audio tracks, 4 subtitle tracks, 0:00:28, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: TrueHD/AC3, English, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
3: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
4: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
5: AC3, French, 5.1 channels, 512kbps, 48kHz
6: AC3, French, 5.1 channels, 640kbps, 48kHz
7: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
8: Subtitle (PGS), English
9: Subtitle (PGS), English
10: Subtitle (PGS), French
11: Subtitle (PGS), Spanish
Track 2 is used for destination file "audio.wavs".
a02 Extracting audio track number 2...
a02 Extracting TrueHD stream...
a02 Decoding with libav/ffmpeg...
a02 Remapping channels...
a02 Writing WAVs...
a02 libav Substream 0 parity check failed
a02 libav Substream 0 checksum failed
a02 libav Substream 0 length mismatch.
a02 The libav decoder reported error -1 while decoding.
Aborted at file position 1048576.

I believe the demuxing problem is related. This is a seamless branching disc and problems are encountered while trying to demux the main feature:

eac3to 00801.mpls -demux

M2TS, 1 video track, 6 audio tracks, 4 subtitle tracks, 1:34:12, 72p /1.001
1: Chapters, 37 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
4: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
6: AC3, French, 5.1 channels, 512kbps, 48kHz
7: AC3, French, 5.1 channels, 640kbps, 48kHz
8: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
9: Subtitle (PGS), English
10: Subtitle (PGS), English
11: Subtitle (PGS), French
12: Subtitle (PGS), Spanish
v02 The video bitstream framerate field doesn't seem to match the timestamps.
Creating file "00914 - Chapters.txt"...
a03 AC3 encoding doesn't support back channels. Will mix them into the surround.

v02 Extracting video track number 2...
a03 Extracting audio track number 3...
a06 Extracting audio track number 6...
a08 Extracting audio track number 8...
s10 Extracting subtitle track number 10...
a03 Extracting audio track number 3...
a05 Extracting audio track number 5...
a04 Extracting audio track number 4...
a03 Extracting TrueHD stream...
s12 Extracting subtitle track number 12...
s11 Extracting subtitle track number 11...
a06 This track is not clean.
s09 Extracting subtitle track number 9...
a07 Extracting audio track number 7...
a03 Extracting TrueHD stream...
a03 Decoding with libav/ffmpeg...
a03 Remapping channels...
a03 Mixing surround channels...
a03 Encoding AC3 <640kbps> with libAften...
a03 libav Restart header sync incorrect (got 0x0598)
a03 The libav decoder reported error -1 while decoding.

When attempting to decode the entire playlist to wavs, I get the following error:

eac3to 00801.mpls audio.wavs

M2TS, 1 video track, 6 audio tracks, 4 subtitle tracks, 1:34:12, 72p /1.001
1: Chapters, 37 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
4: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
6: AC3, French, 5.1 channels, 512kbps, 48kHz
7: AC3, French, 5.1 channels, 640kbps, 48kHz
8: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
9: Subtitle (PGS), English
10: Subtitle (PGS), English
11: Subtitle (PGS), French
12: Subtitle (PGS), Spanish
v02 The video bitstream framerate field doesn't seem to match the timestamps.
Track 3 is used for destination file "audio.wavs".
a03 Extracting audio track number 3...
a03 Extracting TrueHD stream...
a03 Decoding with libav/ffmpeg...
a03 Remapping channels...
a03 Writing WAVs...
a03 libav Restart header sync incorrect (got 0x0598)
a03 The libav decoder reported error -1 while decoding.
Aborted at file position 1048576.

The 2D version has the same problem as does Finding Nemo.

Thank you in advance for looking into it.

Mike

[BigPines]

One very small enhancement request that would make my life easier is to change the names of the surround output wav files. The output wavs are currently named as follows: audio.L.wav, audio.R.wav, audio.LFE.wav, audio.SL.wav and audio.SR.wav.

The DTSEncoder looks for different names in the surround channel. It would be as simple as changing the output names as follows:

from audio.SL.wav to audio.LS.wav
from audio.SR.wav to audio.RS.wav

This would enable us to drop a single file (the left channel) onto the DTS encoder window and the rest of the files would load themselves automatically.

Just a small thing that would make a BIG difference to those of us using the DTSEncoder.

Thank you for your consideration.

Mike

[shon3i]

make it opensource ?

[tebasuna51]

... take even for example "Qtec Hi-Definition Reference Disc" - it has the same 24-bit/96kHz multi-channel track in LPCM, TrueHD and DTS-HD MA which is set to "strange setup" - LPCM and TrueHD are correctly decoded bit-perfect, but Arcsoft 1.1.0.0 decode is not bit-perfect. however, the channel order seems wrongly set in the DTS-HD MA to "strange setup" and it doesn't reflect the true channel order of the recording inside
If I understand correctly, you say than this DTS-HD was erroneusly coded to Ls,Rs,Lsr,Rsr when it must be encoded to Lss,Rss,Lsr,Rsr?

All "strange setup" DTS-HD have the same problem and Ls,Rs (110º) must be decoded directly to SL,SR (90º)?

... when 'eac3to' decodes all 8 channels of DTS-HD MA "strange setup" bit-perfect then people like "tebasuna51" that believe that's wrong can mix them to their liking.

I don't have the problem because I have only 5.1 audio systems.
But I think is more important preserve the channels positions than the samples was "bit-perfect".

The DTSEncoder looks for different names in the surround channel. It would be as simple as changing the output names as follows:

from audio.SL.wav to audio.LS.wav
from audio.SR.wav to audio.RS.wav

Take in mind than SL (M$ definition) means SideLeft (90º) but Ls (DTS definition) mean LeftSurround (110º).
The correct equivalence to SL is Lss (LeftSurroundSide, 90º).

BTW this is not important for 5.1
And my preference is use M$ names por wav files: FL,FR,FC,LFE,SL,SR (or FL,FR,FC,LFE,BL,BR both the same for 5.1 files)

[tebasuna51]

...
I would really prefer to use eac3to instead of outdated/buggy flac.exe but i need at least -block switch

And this 2 pass procces can work for you?

eac3to input.flac stdout.wav | lossywav.exe - intermediate.wav

eac3to intermediate.wav stdout.wav | flac -b 512 -o output.lossy.flac --ignore-chunk-sizes -

Because I think more dificult to implement the input.stdin.

[Atak_Snajpera]

eac3to intermediate.wav stdout.wav | flac -b 512 -o output.lossy.flac --ignore-chunk-sizes -
ok this creates correct flac at least. Nevertheless exposing -block switch for user is just a 10 min work (libFLAC has it anyway). Madshi could also implement automatic block size for extension .lossy. (44.1/48Khz - 512 , 96Khz - 1024 , 192Khz - 2048 and so on...)

eac3to input.flac stdout.wav | lossywav.exe - intermediate.wav
This does not work yet but author is working on compatibility with eac3to.

[Chumbo]

I had posted this request in the original thread as I didn't know about this one. Not sure if this is a small or large effort.

Any chance of adding chapter detection/extraction from MKVs please? Thanks for considering it.

[sneaker_ger]

Not to keep madshi from adding mkv chapter extraction, but I think mkvtoolnix does it just fine.

[BigPines]

What is this DTS strange setup people are talking about?

Mike

[Revgen]

- Use ffmpeg/libavformat for MKV muxing


Is it better than MKVToolnix?

[tebasuna51]

- Any chance of adding chapter detection/extraction from MKVs please?
Yes we now than eac3to mkv support is not complete, not only with chapters. Pending, not urgent because there are mkvtoolnix.

- Is it (ffmpeg to mux) better than MKVToolnix?
I don't think so, but eac3to uses Haali mux.

- What is this DTS strange setup people are talking about?
The standard 7.1 DTS channel configuration 1 (see attached image) have a exact equivalence with M$ WAV channels:
L,C,R,LFE,Lss,Rss,Lsr,Rsr -> FL,FR,FC,LFE,BL,BR,SL,SR

The strange 7.1 DTS channel configuration 5 don't have a exact equivalence with M$ WAV channels:
L,C,R,LFE,Ls,Rs,Lsr,Rsr -> FL,FR,FC,LFE,BL,BR,?,?

[BigPines]

Thanks for the DTS strange setup explanation tebasuna51.

That is indeed a strange setup. Not sure why anyone would set up their system like that (or encode for that) since there is so little separation between speakers, it would probably not make any difference to have the rear channels at all if you were using that config. So how do we know if an audio stream has been encoded for strange setup?

Mike

[tebasuna51]

eac3to say you when is a 7.1 strange setup:

DTS Master Audio, 7.1 (strange setup) channels, 24 bits, 48kHz

[BigPines]

eeeewwwww. I've never noticed that. I'll definitely have to check that out. Someone should start a list of titles that have this "problem".

So, you are saying eac3to will decode a 7.1 file differently depending on if it is strange setup or not? Shouldn't levels and delays be handled by the producer/artist? What does the encoder/decoder do differently for these type of streams? Why does eac3to need to know the difference? In my mind, the encoder should just combine 8 discrete channels of audio and it shouldn't be messing with the content at all but maybe I am wrong.

Mike

[Chumbo]

Not to keep madshi from adding mkv chapter extraction, but I think mkvtoolnix does it just fine.
So does MKVExtract, but it would be nice to just use one tool. ;)

[Hobbe]

Use ffmpeg (libav) instead of aften when encoding AC3?

[phate89]

I have 2 improvements
1) i use a lot eac3to editing and it's a pain actually that the point you use have to be bigger than the edit you do. So if you have to add 2 seconds of silence after the first second you can't, if you have to add 11 seconds of silence after 10 second you cant', if you have to add 31 seconds of silence after 30 seconds you can't and so on.

2) (probably it's not even fixable by eac3to but from the decoder), to be able to manage mixed content, i work a lot with mixed ac3 (both 2.0 and 5.1 from tv transmission recordings) and i always have to use besweet because is the only tool i know that can decode to wav without destroy the audio or to have to clean the stream. if i pass for example an audio that is all 5.1 but have a frame 2.0 at the start it considers all frames as 2.0 so the length is 3 times the original. instead besweet leave where is only 2.0 puts the sound in l and r channel and leave with silence the other 4 channels so you'll get in output a full 5.1 good track.

[tebasuna51]

1) Already included in first post: Bad checking between edit position and duration. (http://forum.doom9.org/showthread.php?p=1600983#post1600983)

2) Yes, is a decoder issue.

[BigPines]

I stumbled across what appears to be another eac3to bug. This time it showed up on The Lorax 3D. Although the disc is 3D and has an SSIF folder in the STREAM folder, eac3to does not appear to recognize it as a 3D disc. The right eye does not show up in the list of tracks nor can it be demuxed using eac3to.

Z:\Internal HD\Volumes\LORAX_NA_3D\BDMV\PLAYLIST>"C:\Program Files (x86)\eac3to\
eac3to.exe"
1) 00031.mpls, 00028.m2ts+00035.m2ts, 1:26:19
- Chapters, 20 chapters
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS, Spanish, multi-channel, 48kHz
- DTS, French, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, English, stereo, 48kHz

2) 00027.mpls, 00028.m2ts, 1:02:37
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS, Spanish, multi-channel, 48kHz
- DTS, French, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, English, stereo, 48kHz

3) 00030.mpls, 00035.m2ts, 0:23:42
- h264/AVC, 1080p24 /1.001 (16:9)
- DTS Master Audio, English, multi-channel, 48kHz
- DTS, Spanish, multi-channel, 48kHz
- DTS, French, multi-channel, 48kHz
- AC3, English, stereo, 48kHz
- AC3, English, stereo, 48kHz

Mike

[DarkSpace]

BigPines, does that also happen when you select a playlist or only in the general overview? Try e.g.

Z:\Internal HD\Volumes\LORAX_NA_3D\BDMV\PLAYLIST>"C:\Program Files (x86)\eac3to\eac3to.exe" 1)

It may simply not show the right eye stream because it only parses the playlist files* and not the actual files on the disc, whereas it will analyze the actual files when you specify a playlist.

* The Playlist files may or may not contain incorrect data about the streams. I think I remember a case in the eac3to thread where the Playlist file specified an AC3 track but the actual format of the track was DTS-HDMA (as correctly detected by eac3to when parsing the files).

[get8p]

If I may, I would like to suggest some features that I think are important. Consider these, please:

1) avi, mp4, mov, mpg, flv support for demux(maybe even muxing, that would be fantastic). Basically, avi/mp4 support is most important feature I think eac3to is lacking, along with..
2) Proper ac3 decoding. As a freeware progs like azid or tranzcode can properly decode ac3, it's a real shame such powerful instrument as eac3to uses nero/libav for that.
3) ac3(maybe also dts)dialnorm applying. There's also a freeware tool ChangeDN(I think it's even opersourced), which can simply apply a given dialnorm to ac3 without decoding.

/Thanks in advance

[tebasuna51]

1) avi, mp4, mov, mpg, flv support for demux(maybe even muxing...)
... that would be fantastic, yes.:)

2) Proper ac3 decoding. ... it's a real shame such powerful instrument as eac3to uses nero/libav for that.
¿What is the problem with libav decoder?

3) ac3(maybe also dts)dialnorm applying.
¿For what you need dialnorm? I think is useless.
This was discussed long time ago in the main eac3to thread.

[BigPines]

BigPines, does that also happen when you select a playlist or only in the general overview? Try e.g.

Z:\Internal HD\Volumes\LORAX_NA_3D\BDMV\PLAYLIST>"C:\Program Files (x86)\eac3to\eac3to.exe" 1)

It may simply not show the right eye stream because it only parses the playlist files* and not the actual files on the disc, whereas it will analyze the actual files when you specify a playlist.

* The Playlist files may or may not contain incorrect data about the streams. I think I remember a case in the eac3to thread where the Playlist file specified an AC3 track but the actual format of the track was DTS-HDMA (as correctly detected by eac3to when parsing the files).
Thanks for the suggestion but it didn't work. When I specified the playlist as you suggested above, I got the same results. It only shows AVC and acts as if it is a 2D disc.

It looks like this may be becoming more common too. I just found the same problem with Arthur Christmas 3D. :(

It must have something to do with the structure of the disc. I wonder if the studios are doing this on purpose or if it is just poor disc authoring? I'm going to take a look in BDEdit to see if I can see the problem and 'fix' it.

Maybe someone knows how eac3to determines if a disc is 3D? Maybe a fix could be created from the eac3to side?

Mike

[BigPines]

UPDATE ON ABOVE: This may purely be operator error. I was using decrypted backups made by MakeMkv but those don't include the necessary SSIF files so the disc was not detected as 3D. Once I backed up to an ISO, it seems to have worked. I'll confirm this is the case with both of the above titles and report back.

Mike

[get8p]

... that would be fantastic, yes.:)
So is that a "yes" or ..?

What is the problem with libav decoder?
Audio signal above 17kHz goes -2.5dB.Look here (http://forum.doom9.org/showthread.php?t=161654).

For what you need dialnorm? I think is useless.
Ah, but it's not. What if you have found out that your .ac3 has default DN(-31) whilst it should be, say, -26? I tell you what I do in this case - I go to ChangeDN prog.
It's a minor feature, yes, but it's usefull for such cases.

[tebasuna51]

So is that a "yes" or ..?
Is fantastic, but:
Guys, as I said in the eac3to thread, bugfixes and *SMALL* improvements, only. Some of what you're suggesting would be major changes.

Audio signal above 17kHz goes -2.5dB.Look here (http://forum.doom9.org/showthread.php?t=161654).
Read also the jruggle (Aften and ffmpeg/libav-AC3 developer) posts. If he consider than libav need some improvements I'm sure a libav update (the main request to madshi) can solve the problem.

Ah, but it's not. What if you have found out that your .ac3 has default DN(-31) whilst it should be, say, -26? I tell you what I do in this case - I go to ChangeDN prog.
It's a minor feature, yes, but it's usefull for such cases.
It's your opinion.

BTW:
- To extract AC3 you can use the parameter -keepDialnorm.
- To decode, or recode to other format, you can use the parameter -5dB (31-26), same effect than apply the DialNorm -26.
- To encode to AC3 you can use the external Aften encoder:
eac3to input stdout.wav | Aften -dnorm 26 [more parameters] - output.ac3

[Snowknight26]

DTS-ES 6.1 -> WAV conversion is buggy with libav.

http://forum.doom9.org/showthread.php?p=1569705#post1569705

[tebasuna51]

Yes, I was forget this bug, added to first post.

[BigPines]

I have come across another bug/problem demuxing some 3D playlists (yeah, I have been doing a lot of 3D stuff of late). The problem is, sometimes the left eye and right eye streams do not extract with the same number of frames. Usually, it is only one frame off. Below is the Finding Nemo 3D BD:


M2TS, 2 video tracks, 2 audio tracks, 1:40:54, 24p /1.001
1: Chapters, 32 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/AVC (right eye), 1080p24 /1.001 (16:9)
4: AC3 EX, English, 5.1 channels, 640kbps, 48kHz
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
Creating file "00914 - Chapters.txt"...
v02 Extracting video track number 2...
a04 Extracting audio track number 4...
v03 Extracting video track number 3...
a05 Extracting audio track number 5...
v03 Creating file "00914 - 3 - h264 (right eye), 1080p24.h264"...
v02 Creating file "00914 - 2 - h264 (left eye), 1080p24.h264"...
a04 Creating file "00914 - 4 - AC3 EX, English, 5.1 channels, 640kbps, 48kHz.ac3
"...
a05 Creating file "00914 - 5 - AC3 Surround, English, 2.0 channels, 320kbps, 48k
Hz.ac3"...
v02 Video overlaps for 14 frames at playtime 0:04:46.
v02 Video overlaps for 14 frames at playtime 0:05:38.
v02 Video overlaps for 14 frames at playtime 1:33:24.
v02 Video overlaps for 14 frames at playtime 1:40:29.
v03 Video overlaps for 14 frames at playtime 0:04:46.
v03 Video overlaps for 14 frames at playtime 0:05:38.
v03 Video overlaps for 14 frames at playtime 1:33:24.
v03 Video overlaps for 14 frames at playtime 1:40:29.
a04 Audio overlaps for 6ms at playtime 0:05:38.
a04 Audio overlaps for 27ms at playtime 1:33:24.
a04 Starting 2nd pass...
a04 Realizing (E-)AC3 gaps...
a04 Creating file "00914 - 4 - AC3 EX, English, 5.1 channels, 640kbps, 48kHz.ac3
"...
Video track 2 contains 145149 frames.
Video track 3 contains 145150 frames.
eac3to processing took 26 minutes, 1 second.
Done.


Unfortunately, this causes problems for some software when we try to mux the streams back together. For instance, Scenarist BD refuses to import streams of different size (even if only off by one frame) for 3D authoring.

It seems this would be an easy fix but I admit I don't know enough to say so for sure. It seems like eac3to could be changed to not drop a frame from the left eye stream (if that is what is actually happening). If the frame is simply missing from the original left eye stream, could eac3to trim the right eye stream so the frame count matches between the two?

Mike

P.S. In the meantime, does anyone know how to get around this problem? I have tried joining a frame to the left eye using tsMuxer. This fooled Scenarist BD into accepting the files but it choked on them when it came time to mux. In desperation, I tried trimming the right eye stream using a hex editor. I couldn't figure out the frame structure of the right eye (dependent stream) so that didn't work either. :(

[hubblec4]

an other issue is eac3to dont recognizes the Total Media Thearter5(TMT) installation on Win7prox64.

[phate89]

I have a small improvement.. Right now eac3to increase or decrease volume only with an integer volume (1db -1db etc), shouldn't be difficult to add the possibility to increase even with real numbers (0.5,1.7).. it already does it when it detects clipping so it's in theory an easy change..

[madshi]

Try ripping one of these movies:
- Edward Scissorhands
- Journey to the Center of the Earth (1959)
- Poseidon Adventure

eac3to will correctly identify the audio as 3/1.

When saving the audio as FLAC it is saved as FLAC 3/1. Unfortunately there is no such thing. FLAC with 4 channels is by FLAC specification 2/2.

Any player that follows the FLAC specification, will play the center channel in the right surround speaker.

Only option to play this correctly (with FLAC) is to duplicate the surround channel and save as FLAC 3/2.
Have a look here:

http://flac.sourceforge.net/changelog.html

Search for "WAVEFORMATEXTENSIBLE". You'll find that the official flac encoder and decoder supports any channel configuration you like, by making use of a special channel mask tag in the flac header. Unfortunately this seems to be a somewhat hidden feature because the spec doesn't mention it. But still, the official encoder/decoder supports it, so that's what eac3to and madFlac are using, too, to make any channel mask work with flac. I think newer libav/ffmpeg versions support that, too. I have no intention to drop this functionality. If you don't like this, then simply don't ask eac3to to create flac files for weird channel masks.

And the second one: defined framerate conversion is ignored in some circumstances.
I've tried to reproduce that here, but I failed. Must be a very specific combination of video, audio and container parameters. Can I have a small sample, please?

eac3to cannot recognize the DDPlus audios in the bluray disk. Hope it could be solved in the new version.
It will not be solved because to my best knowledge there's only one blu-ray in the world with such a DDPlus audio track. I'm not going to spend any time on this, just to support one demo blu-ray.

I have uploaded a couple of files that illustrate the Brave/Finding Nemo TrueHD bug.
Thanks. Are you sure that the rip is clean? Can you try to update your decrypt software and rip another time, just to be safe? The warning "This track is not clean" usually only occurs if a rip is damaged. I've never seen this warning with a clean rip yet. Maybe the current AnyDVD version isn't able yet to properly decrypt those Blu-Rays?

2) (probably it's not even fixable by eac3to but from the decoder), to be able to manage mixed content, i work a lot with mixed ac3 (both 2.0 and 5.1 from tv transmission recordings) and i always have to use besweet because is the only tool i know that can decode to wav without destroy the audio or to have to clean the stream. if i pass for example an audio that is all 5.1 but have a frame 2.0 at the start it considers all frames as 2.0 so the length is 3 times the original. instead besweet leave where is only 2.0 puts the sound in l and r channel and leave with silence the other 4 channels so you'll get in output a full 5.1 good track.
In theory eac3to could make this work. It has been on my to do list for a long time, but it's not too easy to implement due to how eac3to works internally, so that's why it's still not there...

2) Proper ac3 decoding. As a freeware progs like azid or tranzcode can properly decode ac3, it's a real shame such powerful instrument as eac3to uses nero/libav for that.
Audio signal above 17kHz goes -2.5dB.Look here (http://forum.doom9.org/showthread.php?t=161654).
Actually, the link you provided shows that eac3to with libav decoding produces better results than azid for AC3 decoding. I'm not sure where you got a different idea? It seems that for E-AC3 decoding libav wasn't producing best results yet. But the test was made 1.5 years ago. Maybe the problem has been resolved in the meanwhile. In any case, I don't think azid or tranzcode can decode E-AC3? Or if they can, they're probably using libav, too, for that, and thus will produce similar results. The only decoders which seem to produce better results are the "official" ones from Nero, Cyberlink and ArcSoft. And again, this only applies to E-AC3. From what I can see, the AC3 libav decoder is best in class, according to the test you linked to.

I have come across another bug/problem demuxing some 3D playlists (yeah, I have been doing a lot of 3D stuff of late). The problem is, sometimes the left eye and right eye streams do not extract with the same number of frames. Usually, it is only one frame off.
How can I reproduce that? Maybe you can upload the very last m2ts file of a seamless-branching Blu-Ray, if it's a rather small file?

[IanD]

It will not be solved because to my best knowledge there's only one blu-ray in the world with such a DDPlus audio track. I'm not going to spend any time on this, just to support one demo blu-ray.

The new release title "Brave" appears to flag/encode the embedded companion DD track as DD+ and this may be (partly or wholely) responsible for audio dropouts when playing the disc in some Bluray/AVR combinations or remuxing issues with eac3to.

If eac3to can not handle this, then the studios have found a way to thwart copying without errors and this approach is likely to be used on many more titles if proven effective. If you can solve this, I think it will offer dividends in the future.

[madshi]

Argh, I had hoped we'd never see E-AC3 used for Blu-Ray primary tracks... :(

[tebasuna51]

But the embedded DD track is standard AC3, at least in spanish edition, and eac3to can extract the AC3 (see http://forum.doom9.org/showthread.php?p=1600694#post1600694 ).

eac3to v3.24
command line: "D:\Programa\eac3to\eac3to.exe" "D:\Temp\BRAVE\BDMV\PLAYLIST\00801.mpls" 1)
------------------------------------------------------------------------------
M2TS, 1 video track, 10 audio tracks, 14 subtitle tracks, 1:34:12, 95.907p
1: Chapters, 37 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: TrueHD/AC3, English, 7.1 channels, 48kHz
(embedded: AC3, 5.1 channels, 640kbps, 48kHz)
4: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
6: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
7: AC3, Catalan, 5.1 channels, 640kbps, 48kHz
8: AC3, Portuguese, 5.1 channels, 640kbps, 48kHz
9: AC3, Russian, 5.1 channels, 448kbps, 48kHz
10: AC3, Ukrainian, 5.1 channels, 448kbps, 48kHz
11: AC3, Kazakh, 5.1 channels, 448kbps, 48kHz
12: AC3, English, 2.0 channels, 320kbps, 48kHz
13: Subtitle (PGS), English
14: Subtitle (PGS), English
15: Subtitle (PGS), Spanish
16: Subtitle (PGS), Portuguese
17: Subtitle (PGS), Russian
18: Subtitle (PGS), Ukrainian
19: Subtitle (PGS), English
20: Subtitle (PGS), Spanish
21: Subtitle (PGS), Portuguese
22: Subtitle (PGS), Russian
23: Subtitle (PGS), Ukrainian
24: Subtitle (PGS), Portuguese
25: Subtitle (PGS), English
26: Subtitle (PGS), Ukrainian

Can't decode/extract TrueHD but work with the AC3.
Also show a fake fps: 95.907p (correct with individual m2ts files)

[IanD]

But the embedded DD track is standard AC3, at least in spanish edition, and eac3to can extract the AC3 (see http://forum.doom9.org/showthread.php?p=1600694#post1600694 )

It's obviously varying between different region releases.

See http://forum.doom9.org/showthread.php?p=1601081#post1601081 for a "Brave" issue.

It also affects some "Finding Nemo": see http://forum.doom9.org/showthread.php?p=1601412#post1601412 and from other comments I suspect "Total Recall" as well.

Just because one release is okay doesn't mean that others will be and considering the number of titles with current problems (and DD+), I expect this will escalate, hence my wish for Madshi to handle DD+ if at all possible.

I do acknowledge there seem to be ways to rip to overcome the issues (apart from where one wants thd+dd+), however it would be great if eac3to handled DD+ as a matter of course (ie providing a working option to rip the thd+dd+ without errors as well as extracting thd and dd+ separately or decoding to ac3 as an option). If the studios will be using DD+ with Bluray, it would be good to be able to extract DD+ without conversion, to retain maximum fidelity, although I'm not sure how many AVR or Bluray players will handle DD+ decoding though.

In the days of HD-DVD, it was common to have an evo file that was 2 evo files joined together with different characteristics such that a file analysis returned strange frame rates, durations, etc. In practice this wasn't a problem for playback as the system simply jumped to the appropriate starting point for each segment and there was no discontinuity. It wasn't a huge issue for ripping as it was possible to edit the xml playlist to bypass any strange introductions. I'm wondering if something similar is happening with the m2ts files. I vaguely recall this issue with "Mission To Mars", where I think there was an embedded introduction. It's harder to rip this sort of thing in Bluray because it is not as amenable to editing as HD-DVD was.

[SquallMX]

But the embedded DD track is standard AC3, at least in spanish edition, and eac3to can extract the AC3 (see http://forum.doom9.org/showthread.php?p=1600694#post1600694 ).



Can't decode/extract TrueHD but work with the AC3.
Also show a fake fps: 95.907p (correct with individual m2ts files)

The American release is affected, looks like a bitrate saving way for Disney in order to include 7.1 tracks (896 Kbps vs 2048 of DTS-HD) for dubs.

[IanD]

The American release is affected, looks like a bitrate saving way for Disney in order to include 7.1 tracks (896 Kbps vs 2048 of DTS-HD) for dubs.

But why include a companion DD+ soundtrack for TrueHD? If the consumer wants better fidelity than DD, then use the TrueHD soundtrack. DD+ has to be decoded to DD anyway for output via SPDIF, so is pointless including as a companion embedded track.

I'm certain this was done deliberately to screw the rippers: it has no logical purpose for Bluray player playback.

I can understand DD+ being used for standalone dubs, although is DD+ a supported Bluray audio standard as I'm not sure many AVR handle it?

[SquallMX]

But why include a companion DD+ soundtrack for TrueHD? If the consumer wants better fidelity than DD, then use the TrueHD soundtrack. DD+ has to be decoded to DD anyway for output via SPDIF, so is pointless including as a companion embedded track.

I'm certain this was done deliberately to screw the rippers: it has no logical purpose for Bluray player playback.

I can understand DD+ being used for standalone dubs, although is DD+ a supported Bluray audio standard as I'm not sure many AVR handle it?

They are not doing that.

The DD+ is for the French 7.1 track (at 896 Kbps with a "core" 5.1 at 512 Kbps), the English track is a huge (6439 Kbps) TrueHD 24 bits/7.1, additionally Disney provides a standalone "classic" Dolby Digital 5.1 (640 Kbps) French track since DD+ is an optional audio format for blu-ray, that way every corner is covered.

Previously Disney was using DTS-HD at 2 Mbps for dubs and DTS-MA for the main language, but now they switched to Dolby, why? I don't have a F clue...

[IanD]

They are not doing that.

The DD+ is for the French 7.1 track (at 896 Kbps with a "core" 5.1 at 512 Kbps), the English track is a huge (6439 Kbps) TrueHD 24 bits/7.1, additionally Disney provides a standalone "classic" Dolby Digital 5.1 (640 Kbps) French track since DD+ is an optional audio format for blu-ray, that way every corner is covered.

Previously Disney was using DTS-HD at 2 Mbps for dubs and DTS-MA for the main language, but now they switched to Dolby, why? I don't have a F clue...

They are including a DD+ embedded companion track with some TrueHD soundtracks according to the results of eac3to, but not on every release of a particular title.

I expect DD+ offers the opportunity to get better fidelity than DD at lower bitrates than DTS-HD or TrueHD.

Why change to Dolby? IMO, there was originally a push to DTS because the open source community had not developed decoders (unlike for TrueHD) and this made life a bit more difficult when it came to ripping and playback: now I understand there are ways to decode DTS, so I think the studios have gone back to Dolby, but started to use DD+ to make it that much more difficult again. I hear that some titles are starting to come out with 10.1 DTS and you can guarantee this will make ripping and playback a little more difficult for DTS, so I fully expect the studios to start to swing back to DTS again after this latest Dolby fad. It's just part of the cat and mouse game between the studios and the rippers: one always trying to keep a step ahead in thwarting the plans of the other.

A similar process has been trialled with Cinavia: only releasing a few titles initially to see how well it works in flummoxing the market. The when it does appear to work, ramp up the titles with it. As soon as the hackers find a way to workaround the protection, introduce something else, rinse and repeat.

[madshi]

They are including a DD+ embedded companion track with some TrueHD soundtracks according to the results of eac3to
I'm pretty sure this is not true because I don't think it's even legal to have a TrueHD audio track with an embedded DD+ track. The reason why eac3to can't decode some TrueHD tracks has nothing to do with which kind of (E-)AC3 track is embedded. eac3to does not even send the embedded (E-)AC3 frames to the TrueHD decoder.

[shon3i]

According BD specs, core/embedded track of TrueHD can be only classical DD not DD+, but also DD+ must have embedded DD track on blu-ray

[madshi]

According BD specs, core/embedded track of TrueHD can be only classical DD not DD+
That's what I had in mind, too.

but also DD+ must have embedded DD track on blu-ray
Yes, but that only applies to primary audio streams. Secondary audio streams (for PiP content like director's comments) is straight DD+, usually stereo, without a DD core.

[nevcairiel]

Wait wait, there is actually a real world disc now with a DD+ primary audio track? Oh noes.

Edit:
And i actually have a copy of "Brave" with a German track in DD+ 7.1, oh well.

[madshi]

I hoped this day would never come. Guess we have no excuses now, anymore... :(

[SquallMX]

I hear that some titles are starting to come out with 10.1 DTS and you can guarantee this will make ripping and playback a little more difficult for DTS, so I fully expect the studios to start to swing back to DTS again after this latest Dolby fad. It's just part of the cat and mouse game between the studios and the rippers: one always trying to keep a step ahead in thwarting the plans of the other.


These are just standard DTS-MA 7.1 tracks with additional metadata for a proper 11.1 upmix.

[IanD]

These are just standard DTS-MA 7.1 tracks with additional metadata for a proper 11.1 upmix.

Any bets on whether the metadata screws up some decoders?

I know these things are supposed to be backwards compatible, but in reality I don't think it is ever 100%.

Doesn't DTS 6.1 cause some issues for some decoders, for example? They should only use 7.1 for compatibility with all equipment (and simply duplicate the mono rear), yet there are a number of 6.1 soundtracks around. Standards are way too lax IMO.

[madshi]

eac3to v3.25 released

http://madshi.net/eac3to.zip

* fixed: option "-down6" didn't handle 6.1 tracks properly
* fixed: option "-down6" for 7.1 content lowered side channels in volume
* fixed: 6.1 DTS/E-AC3 libav decoding resulted in incorrect 70f channel mask
* fixed: a couple of funny AC3 channel configs resulted in swapped channels
* fixed: option "-check" failed for SRT subtitles
* fixed: MKV tracks without language information didn't default to "English"
* fixed: 16bit MLP decoding didn't work at all
* fixed: DTS 2.1 decoding had empty sub channel when using ArcSoft decoder
* fixed: muxing h264 video streams without VUI eventually crashed
* fixed: SMPTE 302M 20bit PCM tracks didn't extract properly
* improved AC3 seamless branching handling by detection of identical frames
* improved DTS seamless branching handling by detection of identical frames
* updated to latest ffmpeg/libav revision
* added support for libav DTS 6.1 and 7.1 decoding (only in core, no DTS-HD)
* added support for encoding all AC3 channel configurations
* added support for demuxing Blu-Ray primary E-AC3 tracks (AC3 core)
* libav is now the default decoder for AC3 and E-AC3
* option "-down2" is now deprecated, but still supported
* option "-downDpl" mixes down to Dolby Pro Logic II
* option "-downStereo" mixes down to standard stereo
* added support for mixing any channel configuration to stereo/DPL
* DPL downmixing doesn't lower volume, anymore (except when clipping occurs)
* editing audio tracks by adding silence is now less restrictive
* trying to mux right eye stream to MKV errors out now, instead of crashing
* doing "eac3to 1) movie.mkv" for 3D BDs now properly skips right eye stream
* FLAC encoding is now done with optimized block sizes for "LossyWAV" files
* encoder bitdepth for lossy DTS tracks is no longer displayed
* option "-test" no longer checks mkvtoolnix
Thanks to tebasuna51 for moderating the bug/improvement list, and for investigating the "duplicate frame" stuff for seamless branching Blu-Rays. I didn't know that overlapping AC3 and DTS frames were actually bit-wise identical! With this information eac3to can now discard such frames immediately, which means that it's no longer necessary to do a 2nd pass for seamless branching Blu-Rays to fix audio overlaps. This new logic should also avoid any audio glitches at the seamless branching edit points - because simply no edits are necessary, anymore, at all. Please note that this only applies to AC3 and DTS (and DTS-HD/MA) tracks. It does not apply to LPCM and TrueHD tracks. However, overlaps with LPCM and TrueHD tracks are rather small, so overlap editing is often not necessary for such tracks, anyway. The new logic also only works if the overlapping AC3 and DTS frames are truely identical. They have been with the 2 Blu-Rays I've tested with. But I don't know for sure if that's the case for *all* seamless branching Blu-Rays. So there's a chance the old overlap logic might still be used for some Blu-Rays.

It seems that mono TrueHD decoding is currently broken when using libav/ffmpeg decoding, but I'm not 100% sure because I only have one such sample and it's pretty short. Maybe you guys can double check (and provide me with a longer sample)? This looks like a libav/ffmpeg bug to me, though, if it's really a bug at all. At least Brave TrueHD decoding seems to be working fine now.

Please note that although eac3to now supports parsing, demuxing and core-extraction for Blu-Ray primary E-AC3 tracks, currently no decoder is available which can decode the full audio information with all 6.1/7.1 channels. Currently only the AC3 core can be decoded which results in 5.1 output only.

[Pomegranate]

Hi! Thank you very much for v3.25. I'm eager to try it out!

"libav is now the default decoder for AC3 and E-AC3"
Does this mean I can get rid of Nero 7 now?

[nautilus7]

Thanks for the update!

[tebasuna51]

Thank you madshi!

We have work for this new year: test all the changes.

[sl1pkn07]

in 3.24 and 3.25

sl1pkn07@sL1pKn07 STREAM $ eac3to 00005.m2ts esee.mkv
trace:loaddll:load_builtin_dll Loaded L"KERNEL32.dll" at 0x7b810000: builtin
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\eac3to.exe" at 0x400000: native
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\advapi32.dll" at 0x7ea90000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\gdi32.dll" at 0x7eb00000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\version.dll" at 0x7eff0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\user32.dll" at 0x7ec20000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\rpcrt4.dll" at 0x7e790000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\ole32.dll" at 0x7e820000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\oleaut32.dll" at 0x7e960000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\comctl32.dll" at 0x7e680000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\shlwapi.dll" at 0x7e3d0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\shell32.dll" at 0x7e450000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\mpr.dll" at 0x7e2f0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\wininet.dll" at 0x7e350000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winspool.drv" at 0x7e310000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\comdlg32.dll" at 0x7e200000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\ws2_32.dll" at 0x7e1b0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\iphlpapi.dll" at 0x7e190000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\wsock32.dll" at 0x7e1e0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\msacm32.dll" at 0x7e0b0000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winmm.dll" at 0x7e0d0000: builtin
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\libAften.dll" at 0x10000000: native
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\msvcrt.dll" at 0x7dff0000: builtin
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\libFlac.dll" at 0x340000: native
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\libSsrc.dll" at 0x370000: native
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\hdcd.dll" at 0x5f0000: native
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\libMatrix.dll" at 0x3a0000: native
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\avutil-52.dll" at 0x66d80000: native
trace:loaddll:load_native_dll Loaded L"C:\\eac3to\\avcodec-54.dll" at 0x6a0c0000: native
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winex11.drv" at 0x7de70000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\uxtheme.dll" at 0x7de30000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\imm32.dll" at 0x7dc60000: builtin
fixme:msg:ChangeWindowMessageFilter 400 00000001
M2TS, 1 video track, 1 audio track, 0:01:32, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: RAW/PCM, Japanese, 2.0 channels, 16 bits, 48kHz
a02 Extracting audio track number 2...
v01 Extracting video track number 1...
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\dsound.dll" at 0x7db50000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\msvfw32.dll" at 0x7db30000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\quartz.dll" at 0x7d920000: builtin
a02 Reading RAW/PCM...
a02 Swapping endian...
v01 Muxing video to Matroska...
trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Haali\\MatroskaSplitter\\mkzlib.dll" at 0x5350000: native
trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Haali\\MatroskaSplitter\\mkunicode.dll" at 0x5370000: native
trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Haali\\MatroskaSplitter\\splitter.ax" at 0x52c0000: native
a02 Encoding FLAC with libFlac...
v01 Starting DirectShow conversion failed.
a02 Creating file "esee - 2 - PCM, Japanese, 2.0 channels, 16 bits, 48kHz.flac"...
-------------------------------------------------------------------------------
trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\quartz.dll" : builtin
trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\msvfw32.dll" : builtin
trace:loaddll:free_modref Unloaded module L"C:\\Program Files\\Haali\\MatroskaSplitter\\splitter.ax" : native
trace:loaddll:free_modref Unloaded module L"C:\\Program Files\\Haali\\MatroskaSplitter\\mkunicode.dll" : native
trace:loaddll:free_modref Unloaded module L"C:\\Program Files\\Haali\\MatroskaSplitter\\mkzlib.dll" : native
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\mmdevapi.dll" at 0x7dc00000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winealsa.drv" at 0x7db20000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\wineoss.drv" at 0x7d9e0000: builtin
trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\wineoss.drv" : builtin
ALSA lib pcm.c:7339:(snd_pcm_recover) underrun occurred
Aborted at file position 256180224.
sl1pkn07@sL1pKn07 STREAM $

install in wine:
ffdshow 1.2.4496 (2012-12-13) (http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/generic%20builds/ffdshow_rev4496_20121213_clsid.exe/download)
HaaliMatroskaSplitter 1.11.288.0 (fom CoreAVC 3.0.1 proffesional), test with official haali and still fail
mkvtoolnix 5.9.0-unicode (not need in 3.25?)

linux:
wine-1.5.20 with external "bottle" only for eac3to. in 32bit mode
archlinux 64bits

any ideas?

is possible add support to use mkvtoolnix/ffmpeg/libav instead to haali to make mkv?

[get8p]

Thanks a lot!

[phate89]

In theory eac3to could make this work. It has been on my to do list for a long time, but it's not too easy to implement due to how eac3to works internally, so that's why it's still not there...



Well i hope you'll find the time, for me it's a major change.. But i understand it's not a priority
What about this (in theory) simple change?

I have a small improvement.. Right now eac3to increase or decrease volume only with an integer volume (1db -1db etc), shouldn't be difficult to add the possibility to increase even with real numbers (0.5,1.7).. it already does it when it detects clipping so it's in theory an easy change..

[7ekno]

Nice update Madshi!

Does AC3 encoding now default to ffmpeg? Or is it still done via an antiquated Aften?

Only reason I ask is the FFMPEG AC3 encoder seems to be of higher quality than Aften now days ;)

7

[kukushka]

can you please get rid of the bug with pseudo dialnorm removal in dts-hd tracks? by forcing -keepdialnorm if there's no other way and probably by displaying a big fat warning when decoding dial normed dts-hd tracks with arcsoft. thanks

[tebasuna51]

The new release 3.25 work fine with my spanish release of BRAVE:

- The ac3 extracted now is bitidentical to the extracted with manual method. (http://forum.doom9.org/showthread.php?p=1600694#post1600694)

- Can extract/decode the TrueHD track, with a message:
[a03] Skipping identical AC3 frames (seamless branching)...
I don't know if the message is appropiated here.

- Can decode the extracted thd, now there are messages:
1%
[libav] Lossless check failed - expected 00, calculated 48. <WARNING>
[libav] Lossless check failed - expected 00, calculated 17. <WARNING>
4%
[libav] Lossless check failed - expected 00, calculated 9b. <WARNING>
92%
[libav] Lossless check failed - expected 00, calculated cd. <WARNING>
93%
[libav] Lossless check failed - expected 00, calculated f3. <WARNING>
99%
[libav] Lossless check failed - expected 00, calculated b0. <WARNING>
[libav] Lossless check failed - expected 00, calculated e8. <WARNING>

maybe related to seamless branching problem.

- The wav's (directly decoded and thd decoded) are bitidentical and with correct duration: 5652.23333 sec., (1h. 34m. 12.23333s.).
The video duration is: 5652.230 sec., (1h. 34m. 12.230s.)
AC3 duration: 5652,256 seconds. ( 1 h. 34 m. 12,256 s.).

All is OK, only the fake fps 95.907p remain.

[IanD]

I must apologise for leading people astray over DD+ soundtracks in "Brave" and "Finding Nemo".

I have been interpreting AC3 EX as meaning AC3 with "extensions" or DD+, when in fact I have now been informed that EX means "matrixed surround" in this instance and DD+ would actually be identified as E-AC3 (verified by testing an HD-DVD).

Surprising no-one has called me on the mistake before now as I am not an eac3to interpretation expert.

So, there probably aren't any DD+ soundtracks in the current titles causing issues (especially as companion soundtracks to TrueHD).

However, I thank Madshi for updating eac3to to better handle certain issues and it is still worthwhile to be able to handle all audio formats that the Bluray consortium might throw our way (in order to upset ripping).

[nevcairiel]

The "Brave" Blu-ray i have at home actually has a DD+ 7.1 track, its not matrixed, it truely is E-AC3 with a AC3 "core" stream and the E-AC3 dependent substream which replaces/adds new channels.
It has a TrueHD 7.1 track for english, and the DD+ 7.1 tracks for German and Italian.

Note that ripping it with eac3to will result in you having only the AC3 "core" track, which may as well be matrixed for backwards compat (the matrixed surround channels are replaced by "clean" the extra channels in the E-AC3 substream if its decoded completely)

[nautilus7]

I can also confirm that the disc has dd+ audio, but not 7.1. Only 5.1 Unless bdinfo doesn't report it correctly.
PLAYLIST REPORT:

Name: 00801.MPLS
Length: 1:34:12.229 (h:m:s.ms)
Size: 27 503 554 560 bytes
Total Bitrate: 38,93 Mbps

VIDEO:

Codec Bitrate Description
----- ------- -----------
MPEG-4 AVC Video 23859 kbps 1080p / 23,976 fps / 16:9 / High Profile 4.1

AUDIO:

Codec Language Bitrate Description
----- -------- ------- -----------
Dolby TrueHD Audio English 6439 kbps 7.1 / 48 kHz / 6439 kbps / 24-bit (AC3 Embedded: 5.1 / 48 kHz / 640 kbps)
Dolby Digital Plus Audio German 512 kbps 5.1 / 48 kHz / 512 kbps
Dolby Digital Plus Audio Italian 512 kbps 5.1 / 48 kHz / 512 kbps
Dolby Digital Audio German 640 kbps 5.1 / 48 kHz / 640 kbps
Dolby Digital Audio Italian 640 kbps 5.1 / 48 kHz / 640 kbps
Dolby Digital Audio Turkish 640 kbps 5.1 / 48 kHz / 640 kbps
Dolby Digital Audio English 320 kbps 2.0 / 48 kHz / 320 kbps / Dolby Surround
Dolby Digital Audio English 320 kbps 2.0 / 48 kHz / 320 kbps

SUBTITLES:

Codec Language Bitrate Description
----- -------- ------- -----------
Presentation Graphics English 35,887 kbps
Presentation Graphics English 23,356 kbps
Presentation Graphics English 79,675 kbps
Presentation Graphics German 26,282 kbps
Presentation Graphics German 74,753 kbps
Presentation Graphics Italian 20,312 kbps
Presentation Graphics Italian 62,818 kbps
Presentation Graphics Turkish 22,944 kbps
Presentation Graphics Turkish 69,697 kbps
Presentation Graphics Turkish 0,061 kbps

Thought, because there's also an ac3 5.1 german and italian track, it makes me think that the e-ac3 tracks are indeed 7.1 and not 5.1. I should report that to the author of bdinfo.

[tebasuna51]

@nevcairel
Then the TrueHd+AC3 (EX or not) english track seems solved.

But the German and Italian tracks are DD+ 7.1 (or 5.1 ?). How work eac3to with that track?

Reading http://en.wikipedia.org/wiki/Dolby_Digital_Plus:
"However, Dolby Digital Plus decoders include a mandatory component that directly converts (without decoding and re-encoding) the Dolby Digital Plus bitstream to a Dolby Digital bitstream (operating @ 640kbit/s) for carriage via legacy S/PDIF connections (including S/PDIF over HDMI) to external decoders (e.g. AVRs, etc.)."

Can eac3to (Nero or libav decoders) decode the track?
There are a method to extract the AC3 'core' without re-encode? (I confess that this option is new for me).

[madshi]

Does this mean I can get rid of Nero 7 now?
It's still the default AAC decoder.

any ideas?

is possible add support to use mkvtoolnix/ffmpeg/libav instead to haali to make mkv?
So the main problem is MKV muxing? You should be able to ask eac3to to demux. Then you could use mkvtoolnix to mux the h264 track to MKV. That should work just fine. Using a different MKV muxer in eac3to would be a lot of work and I don't have time for that anytime soon.

What about this (in theory) simple change?
I don't really see the big benefit of doing so small volume changes? What would you need that for?

Does AC3 encoding now default to ffmpeg? Or is it still done via an antiquated Aften?

Only reason I ask is the FFMPEG AC3 encoder seems to be of higher quality than Aften now days ;)
It's still using Aften. Maybe I'll switch to ffmpeg encoding in the future, but not anytime soon.

can you please get rid of the bug with pseudo dialnorm removal in dts-hd tracks?
What do you mean exactly?

- Can extract/decode the TrueHD track, with a message:
[a03] Skipping identical AC3 frames (seamless branching)...
I don't know if the message is appropiated here.

- Can decode the extracted thd, now there are messages:
1%
[libav] Lossless check failed - expected 00, calculated 48. <WARNING>
That's all "as expected" and correct.

Note that ripping it with eac3to will result in you having only the AC3 "core" track, which may as well be matrixed for backwards compat (the matrixed surround channels are replaced by "clean" the extra channels in the E-AC3 substream if its decoded completely)
Ripping with v3.25 should demux the full track including the AC3 core and the extra E-AC3 substream frames. If you only want the core, use the "-core" parameter.

I can also confirm that the disc has dd+ audio, but not 7.1. Only 5.1 Unless bdinfo doesn't report it correctly.
BDInfo does not report it correctly.

But the German and Italian tracks are DD+ 7.1 (or 5.1 ?). How work eac3to with that track?

[...]

Can eac3to (Nero or libav decoders) decode the track?
Neither Nero nor libav can decode this track with full 7.1 channels. They can both only decode the core. If you ask eac3to to decode such a track, eac3to will automatically extract the core and send that to the decoder. If you ask eac3to to demux the track, it will demux it untouched, so it's still a 7.1 track. If you want eac3to to extract the core, you can use the "-core" parameter.

[Thunderbolt8]

You should be able to ask eac3to to demux. Then you could use mkvtoolnix to mux the h264 track to MKV. That should work just fine.I remember you saying at one point in the past that its better to remux to .mkv directly instead of demuxing the .h264 stream, because then the chain of timestamps (or whatever it was exactly) is more likely to be kept intact or something like that.

does this still apply?

[phate89]

I don't really see the big benefit of doing so small volume changes? What would you need that for?

1 db volume it's not too much but if it's easy to add it's better to have it more accurate... . I use eac3to a lot to reproduce to the audio track the changes i already did with audition so a decimal increase of volume will bring a more accurate result...

[sl1pkn07]

So the main problem is MKV muxing? You should be able to ask eac3to to demux. Then you could use mkvtoolnix to mux the h264 track to MKV. That should work just fine. Using a different MKV muxer in eac3to would be a lot of work and I don't have time for that anytime soon.

yes, the main problem is don't mux in mkv through eac3to/haali (directshow error)

yes, the -demux option works, and yes, i use mmg to mux result video stream into mkv (doble work and space)

[nevcairiel]

Ripping with v3.25 should demux the full track including the AC3 core and the extra E-AC3 substream frames. If you only want the core, use the "-core" parameter.


Oh yeah, i was somehow thinking about re-encoding it on the fly when i said ripping, my bad.

I actually looked into decoding it, and it is relatively easy. It uses default E-AC3 encoding schemes, so all that has to be written in libav is combining the "core" ac3 frame with the 4 extra channels from the E-AC3 frame (replace 2 surrounds, add 2 back surrounds). Unless someone beats me to it, i might try my luck with it at some point.

[madshi]

1 db volume it's not too much but if it's easy to add it's better to have it more accurate... . I use eac3to a lot to reproduce to the audio track the changes i already did with audition so a decimal increase of volume will bring a more accurate result...
Well, I don't know, with testing and everything this might cost me an hour of development time, and you're the only one ever who's asked for this. So probably no.

I actually looked into decoding it, and it is relatively easy. It uses default E-AC3 encoding schemes, so all that has to be written in libav is combining the "core" ac3 frame with the 4 extra channels from the E-AC3 frame (replace 2 surrounds, add 2 back surrounds). Unless someone beats me to it, i might try my luck with it at some point.
That would be quite cool. If you do that, maybe you could look into HD DVD style E-AC3 7.1 decoding, too? I think that's pretty similar, just that the "core" is E-AC3 instead of AC3. If you get to that, I could provide you with samples...

[nautilus7]

madshi, what about dts-hd master audio 7.1ch "strange setup" tracks? Would you implement a fix like xkodi is suggesting so arcsoft decoder can properly decode them?
i completely don't agree with that, because there is no "strange setup" file that contains a recording which actually uses the real channel order to which the file is set - take even for example "Qtec Hi-Definition Reference Disc" - it has the same 24-bit/96kHz multi-channel track in LPCM, TrueHD and DTS-HD MA which is set to "strange setup" - LPCM and TrueHD are correctly decoded bit-perfect, but Arcsoft 1.1.0.0 decode is not bit-perfect. however, the channel order seems wrongly set in the DTS-HD MA to "strange setup" and it doesn't reflect the true channel order of the recording inside - same applies for me for Scandinavian version of "Sin City" that is another famous example with "strange setup" files. so, if we assume Arcsoft 1.1.0.0 decodes the DTS-HD MA sample from "Qtec Hi-Definition Reference Disc" correctly as "tebasuna51" believes then it means that any existing LPCM and TrueHD decoder is wrong, because the same track in LPCM and TrueHD from that demo-disc is decoded in way different than Arcsoft 1.1.0.0.

BTW, if "madshi" is interested to implement a fix for that, he can contact me to give him simple proof-of-concept code for DTS-HD MA header-parching in C that switches the channel order as currently 'eaqc3to' do for DTS files - i guess that way implementing the real fix in 'eac3to' would be matter of minutes. also, when 'eac3to' decodes all 8 channels of DTS-HD MA "strange setup" bit-perfect then people like "tebasuna51" that believe that's wrong can mix them to their liking. however, it's very simple and believe no any code example is necessary when check the document here:

http://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf

and just change the channel order bits and re-calculate the CRC.

[kukushka]

What do you mean exactly?


i mean, when dts-hd track has a non zero dn, it can't be decoded correctly with arcsoft (it will process dialnorm, applying gain to pcm output), only with sonic. now. if i do anything through eac3to with such track without -keepdialnorm, like demuxing, eac3to tries to remove dialnorm, but he's not doing it properly, probably by removing it in the first frame or smth. from this moment eac3to will report that the track don't have any dialnorm but decoding with arcsoft and sonic will give same results with gain applied from "non-existant" dialnorm.

ps thanks for fixing it!

[Pomegranate]

It's still the default AAC decoder.

I forgot about that :o. Thanks for reminding me.

Speaking of aac though, LAVAudio decodes aac to 32 bit floating point, but with nero, eac3to decodes aac to 24 bit integer. For playback, it's not a problem. But for editing, resampling, etc, 32 bit floating point would maybe be more accurate?

[nautilus7]

eac3to has trouble decoding this (http://www.sendspace.com/file/4dhzm4) 5.0 ch dts track correctly using libav. Results in distorted sound (didn't check anything else line channel mapping etc).

eac3to 5.0.dts a.wav
DTS, 5.0 channels, 0:00:52, 1509kbps, 48kHz
The ArcSoft and Sonic decoders don't seem to work, will use libav instead.
Decoding with libav/ffmpeg...
Reducing depth from 64 to 24 bits...
Writing WAV...
Creating file "a.wav"...
libav Number of channels changed in DCA decoder (5 -> 6)
eac3to processing took 2 seconds.
Done.

Is this an eac3to bug or a libav one?

[DarkSpace]

I don't really see the big benefit of doing so small volume changes? What would you need that for?

Personally, I tend to write stuff to batch files and sometimes run them multiple times (because of additions or because I messed up or something, or just for testing things). If there's no possibility to change volume in non-integer levels, I'll be stuck with always using the 2-pass clipping detection, which is (naturally) slow, or decreasing the volume in integer steps, which I consider to be insufficient, knowing that it can be done better. If you added the non-integer volume change, I could simply integrate the calculated gain into the batch file, so I do consider it a meaningful change for conveniency. I understand if you won't do it, but I just wanted to mention it so you'd see that not only phate89 would benefit from this.

you're the only one ever who's asked for this.
I was actually going to mention that sometime as well, just not yet.

[tebasuna51]

Is this an eac3to bug or a libav one?

Is a corrupt dts file, begin with 5.0 (first 5 sec. of silence) but end with 5.1.

Try:

eac3to 5.0.dts 5.1.dts -5000ms
eac3to 5.1.dts output.wav +5000ms

[nautilus7]

tebasuna51, it seems you're right. It's actually 5.1, so no problem decoding.

[madshi]

I remember you saying at one point in the past that its better to remux to .mkv directly instead of demuxing the .h264 stream, because then the chain of timestamps (or whatever it was exactly) is more likely to be kept intact or something like that.

does this still apply?
Yes and no. For Blu-Ray tracks (or similarly clean sources) the container timestamps should be "perfect". For such sources losing the container timestamps should be no problem at all. However, if you have VFR content, or captures with potential corruption in them, the situation is different. There it's better to directly mux to MKV.

madshi, what about dts-hd master audio 7.1ch "strange setup" tracks? Would you implement a fix like xkodi is suggesting so arcsoft decoder can properly decode them?
I've talked to xkodi and he can't get such tracks to decode losslessly, either. So I think there's no hope.

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

[nautilus7]

I've talked to xkodi and he can't get such tracks to decode losslessly, either. So I think there's no hope.

Damn... Will have to live with them then.

eac3to v3.26 released

Thanks for the update and your patch to the libav/ffmpeg ac3 decoder.

madshi, would you consider adding a downmix to mono option?

[madshi]

No, I'm not considering any new features now. My original plan for v3.25 was to just fix bugs, and I've already done way more than that. I'm going back to commercial and madVR development for the next few months now.

[nautilus7]

Ok, I understand. Not a big deal anyway. Thanks again for the updates. I believe you 've covered all pending issues now.

[tebasuna51]

Thanks madshi!
See you later.

[J.Constantine]

Hello,



The's a bug in the new version eac3to 3.26
When I'm encoding an AC3 640 kbit directly to flac, the source has the same duration as the encode - 1:56:30.656 (335 551 472 samples)

When I do this over w64 (ac3 to w64, w64 to flac) there's a difference in the duration - 1:56:30.655 (335 551 456 samples)

The duration of the w64 is correct - 1:56:30.656 (335 551 472 samples)

The problem must be found by decoding of the w64.


Thanks

[mood]

In downmix ac3 6 channels to stereo when clipping is detect many times the second pass fail given an error.

I don't have this problem with 3.24 version.

[Sparktank]

Thank you so much for the updates, mashi! :)
The bugfixes alone are more than pleasing.

[tebasuna51]

The's a bug in the new version eac3to 3.26
When I'm encoding an AC3 640 kbit directly to flac, the source has the same duration as the encode - 1:56:30.656 (335 551 472 samples)

When I do this over w64 (ac3 to w64, w64 to flac) there's a difference in the duration - 1:56:30.655 (335 551 456 samples)
I can reproduce this.

The duration of the w64 is correct - 1:56:30.656 (335 551 472 samples)
But not this. Are you sure?

My test:
A Test.ac3 with 625 frames and a exact duration of 20.00000 sec

Decoded to wav or w64 with libav or Nero finish with a duration of 19.99967 sec. Lose the first 16 samples (288 bytes).

But each time than convert between wav <-> w64 lose one more time the first 16 samples. Seems a bug writting uncompressed audio.

No problem with 3.24.
Please madshi, can you fix this regresion?

[tebasuna51]

In downmix ac3 6 channels to stereo when clipping is detect many times the second pass fail given an error.

I don't have this problem with 3.24 version.

I can't reproduce this.
I only get one message:

1%
[a02] Clipping detected, a 2nd pass will be necessary. <WARNING>
2%
...
[a02] Starting 2nd pass...
...
[a02] Writing WAV...
[a02] Applying -9.26dB gain...

Put a simplified log or upload a sample than produce the fail.

[mood]

I can't reproduce this.
I only get one message:

1%
[a02] Clipping detected, a 2nd pass will be necessary. <WARNING>
2%
...
[a02] Starting 2nd pass...
...
[a02] Writing WAV...
[a02] Applying -9.26dB gain...

Put a simplified log or upload a sample than produce the fail.

for me many times when 2nd pass start given an error.

this is my log:

eac3to v3.25
command line: "C:\Program Files (x86)\MBTools\MBAudioToolGUI\eac3to.exe" "C:\Users\me\Downloads\The.Possession\The.Possession.2012.ac3" "C:\Users\me\Downloads\The.Possession\New-The.Possession.wav" -downDpl -log=NUL -progressnumbers
------------------------------------------------------------------------------
AC3, 5.1 channels, 1:32:14, 448kbps, 48kHz
Decoding with libav/ffmpeg...
Downmixing multi channel audio to stereo...
Reducing depth from 64 to 24 bits...
Writing WAV...
Creating file "C:\Users\me\Downloads\The.Possession\New-The.Possession.wav"...
Clipping detected, a 2nd pass will be necessary. <WARNING>
Starting 2nd pass...
Decoding with libav/ffmpeg...
Downmixing multi channel audio to stereo...
Reducing depth from 64 to 24 bits...
Writing WAV...
Applying -5,59dB gain...
Creating file "C:\Users\me\Downloads\The.Possession\New-The.Possession.wav"...
The destination file "C:\Users\me\Downloads\The.Possession\New-The.Possession.wav" could not be created. <ERROR>
Writing the destination file failed. <ERROR>
Aborted at file position 262144. <ERROR>

I tried with others ac3 files and in 10 times I tried, 7 give me the same error.

And 3.24 version work great with same files.

"-log=NUL" flag not work anymore as you can see in log I post here, write the log anyaway.

[madshi]

for me many times when 2nd pass start given an error.

I tried with others ac3 files and in 10 times I tried, 7 give me the same error.

And 3.24 version work great with same files.
I can only guess what's going on here. There has been one change from 3.24 to 3.25 which is this:

- DPL downmixing doesn't lower volume, anymore (except when clipping occurs)

So basically with 3.24 a 2nd pass was not necessary in many cases, while 3.25 often has to do a 2nd pass. So in that sense 3.25's behaviour is not as good. However, the final output of 3.25 should be better: It should always have identical volume to the original track, except if clipping makes it necessary to lower volume. 3.24 always lowered volume quite noticely.

Anyway, I guess that the reason you don't see problems with 3.24 is that 3.24 didn't actually try to do a 2nd pass in your case. But why does the problem occur when eac3to needs a 2nd pass? I can only guess here but my best guess is that your anti-virus software opens the WAV file created by eac3to after the first pass is through, trying to check whether there's a virus in the new file. Then eac3to tries to re-create the WAV file, but fails because your anti-virus software still has the file open. This is just a guess, but things like that have happened before, so I think it's a rather likely explanation for the problem, considering that the 2nd pass logic seems to work well for most other people.

If you want to double check whether 3.24 has the same problem, simply add a "+10db" command to 3.24 to make it need a 2nd pass, too.

"-log=NUL" flag not work anymore as you can see in log I post here, write the log anyaway.
The "-log" parameter wasn't really meant to support NUL. I guess you could enter an invalid file name to make eac3to write no log, e.g. "-log=?". But that will only stop eac3to from creating a log file in the direction of the destination file. eac3to will *always* try to write a log to the directory where eac3to.exe is located. You can't disable that atm.

[madshi]

eac3to v3.27 released

http://madshi.net/eac3to.zip

* fixed: raw processing cut away 16 samples sometimes

[Carpo]

Would it be possible to use LAVFilters instead of Haali, or is there something that only haali can do that lav cant and that is why its still required?

[sneaker_ger]

LAV cannot mux anything, so it cannot replace Haali.

[mood]

I can only guess what's going on here. There has been one change from 3.24 to 3.25 which is this:

- DPL downmixing doesn't lower volume, anymore (except when clipping occurs)

So basically with 3.24 a 2nd pass was not necessary in many cases, while 3.25 often has to do a 2nd pass. So in that sense 3.25's behaviour is not as good. However, the final output of 3.25 should be better: It should always have identical volume to the original track, except if clipping makes it necessary to lower volume. 3.24 always lowered volume quite noticely.

Anyway, I guess that the reason you don't see problems with 3.24 is that 3.24 didn't actually try to do a 2nd pass in your case. But why does the problem occur when eac3to needs a 2nd pass? I can only guess here but my best guess is that your anti-virus software opens the WAV file created by eac3to after the first pass is through, trying to check whether there's a virus in the new file. Then eac3to tries to re-create the WAV file, but fails because your anti-virus software still has the file open. This is just a guess, but things like that have happened before, so I think it's a rather likely explanation for the problem, considering that the 2nd pass logic seems to work well for most other people.

If you want to double check whether 3.24 has the same problem, simply add a "+10db" command to 3.24 to make it need a 2nd pass, too.


The "-log" parameter wasn't really meant to support NUL. I guess you could enter an invalid file name to make eac3to write no log, e.g. "-log=?". But that will only stop eac3to from creating a log file in the direction of the destination file. eac3to will *always* try to write a log to the directory where eac3to.exe is located. You can't disable that atm.

Thanks madshi for update this great tool and thanks to answer.

I don't know why give me this error on 2nd pass.

Because I don't use any anti-virus, and windows defender are disabled.

[Carpo]

LAV cannot mux anything, so it cannot replace Haali.

it can split them

[tebasuna51]

I don't know why give me this error on 2nd pass.

Try check if v3.24 -down2 -normalize give you the same error.
Do you have enough space in your disk?

[Didée]

In 3.24, every now and then I have/had cases where the 2nd pass would fail with "libav decoder crashed". Not related to downmixing, it occurs also with 6ch->6ch. It's more often with AC3 sources, but might happen with DTS sources too.

Yesterday I switched to 3.26. I didn't get a libav crash (message). Instead, the PC shut down with a bluescreen. (And it's not the hardware, the rig does hours/days/weeks of 100%CPU x264 encoding without problems.)

(Yes this is too little information for a proper bug report. Just telling my joe-user experience.)

[sneaker_ger]

Instead, the PC shut down with a bluescreen. (And it's not the hardware, the rig does hours/days/weeks of 100%CPU x264 encoding without problems.)

Since eac3to runs in user mode, it has to be some kind of hardware/driver/OS problem.

[mood]

Try check if v3.24 -down2 -normalize give you the same error.
Do you have enough space in your disk?


I already check.

And with -down2 -normalize in 3.24 work great.

I have enough space in disk.

I have tried with different ac3 files and sometimes the 2nd pass fails, sometimes not with the same files of test.

but the majority of times fails on 2nd pass.

I use windows 8 pro if interested to know.

[madshi]

In 3.24, every now and then I have/had cases where the 2nd pass would fail with "libav decoder crashed". Not related to downmixing, it occurs also with 6ch->6ch. It's more often with AC3 sources, but might happen with DTS sources too.

Yesterday I switched to 3.26. I didn't get a libav crash (message). Instead, the PC shut down with a bluescreen. (And it's not the hardware, the rig does hours/days/weeks of 100%CPU x264 encoding without problems.)

(Yes this is too little information for a proper bug report. Just telling my joe-user experience.)
Ouch. FWIW, eac3to does not do anything driver related, nor any other tricks/hacks outside of its own process. In theory a normal Windows user process shouldn't be able to bluescreen the OS by accident. So something funky must be going on there.

Since x264 encoding works stable for you, it can't be any hardware which is used by both x264 and eac3to. So it probably can't be RAM, nor normal CPU circuits. One thing I'm wondering about is whether maybe it could be an issue with the x87 floating point unit in your CPU? Probably x264 uses MMX/SSE/... instead of the normal floating point unit? eac3to is compiled with Delphi 7 which isn't really able to use SSE2 for floating point stuff. So libav AC3/DTS decoding results are running through the x87 unit when using eac3to. This is just a wild guess, though, I could be totally wrong. But it's the only thing that remotely makes sense to me. If it isn't that then I've no idea what else it could be. Maybe you could try running x264 with MMX/SSE/... turned off for a while, just to check whether that's stable?

In any case, I've not received any complaints about libav decoder crashes, so it seems to me that the issue is probably specific to your PC somehow.

Or is there anyone else who has problems with libav decoder crashes?

And with -down2 -normalize in 3.24 work great.

I have enough space in disk.

I have tried with different ac3 files and sometimes the 2nd pass fails, sometimes not with the same files of test.

but the majority of times fails on 2nd pass.
Another thing that makes no sense to me from a developer point of view. According to your log eac3to fails to re-create the WAV output file on the 2nd pass. I could understand that if many people had this problem. But you're the only one whom I have seen reporting this specific issue. Do you happen to have another PC you could test this on? Or a VM (e.g. VmWare or VirtualPC)?

[mood]

Another thing that makes no sense to me from a developer point of view. According to your log eac3to fails to re-create the WAV output file on the 2nd pass. I could understand that if many people had this problem. But you're the only one whom I have seen reporting this specific issue. Do you happen to have another PC you could test this on? Or a VM (e.g. VmWare or VirtualPC)?

yes its a weird issue, but happens to me :confused:

and I don't know if happens to someone else or someone else don't know where can report it or simply does not report.

And the problem is not my PC, because yourself say it, "create the file in first pass" just can't read or re-create the same wav file that it created on first pass.

I think that sometimes when 2nd pass is needed delete the wav file that created in first pass and therefore can not re-create the file in 2nd pass because is missing.

If the problem is my PC it could not do the first pass neither.

I don't have your developer skill neither the source code to help you to fix this problem.


But I will try in another PC when I have opportunity because I just have one PC.

And report it later when I have done.

thanks for your concern.

[Chumbo]

...But I will try in another PC when I have opportunity because I just have one PC....
Windows 8 does support Hyper-V by the way so you really don't need another PC. It's just not enabled by default. Here's a couple of links as a resource:
Client Hyper-V (http://technet.microsoft.com/en-us/library/hh857623.aspx)
Developing and testing on Windows 8 with Hyper-V (http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-455T)

[cyberbeing]

@mood

Another thought would be to test running eac3to 3.27 from an administrative command prompt.
A) Permissions issue

Also try writing to a drive or directory which is neither indexed by Windows Search, nor that you've opened in Windows Explorer until after eac3to has completed writing both passes (or error).
B) Something (not eac3to) locking or accessing the file

Last but not least, try temporarily disabling SuperFetch and LargeSystemCache + reboot.
C) It's possible that Windows 8 is writing the first pass WAV directly to RAM in order to improve performance, and is still attempting to write the first pass to disk when eac3to attempts to write the second pass. On Windows 7 I've seen large copy operations cause multi-second delays for certain applications, which fail to access/modify a file until Windows has written it 100% from RAM to physical HDD.


I'm just grasping at straws here, yet I'm also curious what plausible explanation could lead to 2nd pass failing with eac3to 3.25+ on your PC.

[Snowknight26]

It's not A because the file was created the first time and it's not C because caching doesn't work that way. The best bet is to use Process Monitor to see which program is trying to access the file and to what extent.

[cyberbeing]

It's not A because the file was created the first time
I don't think you can rule it out just because the first pass was able to be created. The second pass would likely require Modify permissions, while the first pass would only need Read/Write.

and it's not C because caching doesn't work that way.
It doesn't work what way?

Windows 7 will occasionally perform large write operations directly to/from RAM at >1GB/s speeds while simultaneously writing to disk at the same time with an order of magnitude slower rate. It's also true that when this happens and you immediately attempt to open or modify the file, it will stall for an additional few seconds as Windows finishes writing the file to HDD. Not all applications seem affected by this, but some certainly are. In other words, maybe the Delphi update caused eac3to to handle file operations differently than before (disabled Forced Write Access?). The other possibility being that eac3to 3.25+ time-out and declare the 2nd pass failed, while possibly eac3to 3.24 would wait slightly longer.

The likelihood of this causing such an issue with eac3to seems slim, yet when only a single user's PC is able to reproduce the issue, you never know.

[tebasuna51]

And the problem is not my PC, because yourself say it, "create the file in first pass" just can't read or re-create the same wav file that it created on first pass.

I think that sometimes when 2nd pass is needed delete the wav file that created in first pass and therefore can not re-create the file in 2nd pass because is missing.

To be exact here is a description how eac3to work (madshi can correct me if I was wrong):

1) At first pass create a file: "Your_desired_name.wav"

2) When firts pass end, and a clip is detected, rename "Your_desired_name.wav" to "Your_desired_name.PASS1.wav"

3) The second pass create a new file: "Your_desired_name.wav"

Maybe something in OS crash when try to rename a file still in use by other process and/or create a new file with the same name:
The destination file "Your_desired_name.wav" could not be created. <ERROR>

When you give the ERROR at the beggining of second pass, what files "Your_desired_name*.wav", and sizes, have at your folder?

Maybe other eac3to behaviour can avoid the problem:

1) At first pass create a file: "Your_desired_name.wav"

2) When firts pass end, and a clip is detected, begin the second pass creating "Your_desired_name.PASS2.wav"

3) When second pass end, delete "Your_desired_name.wav" and rename "Your_desired_name.PASS2.wav" to "Your_desired_name.wav"

If a crash occurs at end at least, I hope, "Your_desired_name.PASS2.wav" have the correct output.

Let me know if this workaround work with The.Possession:
"C:\Program Files (x86)\MBTools\MBAudioToolGUI\eac3to.exe" "C:\Users\me\Downloads\The.Possession\The.Possession.2012.ac3" "C:\Users\me\Downloads\The.Possession\New-The.Possession.wav" -downDpl -5.6dB

[madshi]

To be exact here is a description how eac3to work (madshi can correct me if I was wrong):

1) At first pass create a file: "You_desired_name.wav"

2) When firts pass end, and a clip is detected, rename "You_desired_name.wav" to "You_desired_name.PASS1.wav"

3) The second pass create a new file: "You_desired_name.wav"
In certain situations eac3to behaves as you say. But this is only the case if the destination file contains a "lossless" representation of the audio data. If clipping is detected and the WAV file format of the written file of the first pass is "integer" then the written WAV file is not lossless, anymore, so it's pretty much useless and gets simply overwritten by the 2nd pass, without being renamed first. The renaming to "pass1.wav" only makes sense if eac3to can save time by not decoding the original file another time. But that's possible only if the first pass produced a "lossless" file that can be used as the new source for the 2nd pass without any quality loss.

In mood's situation the WAV file produced by the first pass had integer bitdepth, I believe, so it can't be used as the source file for the 2nd pass, because you can't remove clipping from an integer bitdepth WAV file. The clipping is "baked" in with such a file. So the 2nd pass needs to decode the source AC3 file another time. So the WAV file produced by the first pass is useless. Consequently it's not renamed, but simply overwritten by the 2nd pass. And that overwriting seems to fail. Thus my guess that some other process (anti-virus comes to mind) still has the file open for some reason. If no AV software is installed, maybe some other software has the file open, for some funny reason. It could even be a virus... :p

Maybe other eac3to behaviour can avoid the problem
Maybe, but I'm not going to change the whole 2-pass logic because one single user has a problem that noone else can reproduce. I don't have the time for that, furthermore changing the logic could introduce new bugs.

[tebasuna51]

If clipping is detected and the WAV file format of the written file of the first pass is "integer" then the written WAV file is not lossless, anymore, so it's pretty much useless and gets simply overwritten by the 2nd pass, without being renamed first.
You are right, my mistake, when source is AC3 the first pass wav is not renamed only overwritten.

Maybe, but I'm not going to change the whole 2-pass logic because one single user has a problem that noone else can reproduce. I don't have the time for that, furthermore changing the logic could introduce new bugs.
Of course, I don't ask you a new version for a problem that can't be reproduced by others users.

Is the same than the direct encode with NeroAacEnc, sometimes crash, sometimes not. Without a clear diagnose I can't ask you nothing, only expose to see if anyone know a reason for the problem.

[sneaker_ger]

eac3to is reporting video overlaps in this sample, even though it should be 100% CFR.

http://www.mediafire.com/?jp62o9rgy130m74

[Atak_Snajpera]

eac3to is reporting video overlaps in this sample, even though it should be 100% CFR.

http://www.mediafire.com/?jp62o9rgy130m74

May I ask how did you manage to mux .opus into matroska???

[sneaker_ger]

Mkvmerge pre, but this is experimental and subject to change, so it is strongly recommended to stay away from it until the spec is finalized. (Should've created a sample without Opus...)

[Atak_Snajpera]

any leaks when opus will be finally supported by matroska. Sorry for offtopic .

[sneaker_ger]

No, not really.

[robertcollier4]

Nero encoder reporting its progress to the console every single second seems to be making eac3to think Nero is stuck and is making eac3to fail. How can we disable Nero AAC encoder from reporting second by second processing? See below.


command line: eac3to S01E01.mkv S01E01-downDpl.aac -downDpl
------------------------------------------------------------------------------
MKV, 1 video track, 1 audio track, 1:26:26, 24p /1.001
1: h264/AVC, English, 720p (16:9)
2: AC3, English, 5.1 channels, 384kbps, 48kHz, dialnorm: -27dB
[v01] The video track doesn't contain framerate information. <WARNING>
Track 2 is used for destination file "S01E01-downDpl.aac".
[a02] Extracting audio track number 2...
[a02] Removing AC3 dialog normalization...
[a02] Decoding with libav/ffmpeg...
[a02] Downmixing multi channel audio to stereo...
[a02] Reducing depth from 64 to 32 bits...
[a02] Encoding AAC <0.50> with NeroAacEnc...
[a02] Clipping detected, a 2nd pass will be necessary. <WARNING>
[a02] The Nero AAC encoder seems to be stuck... <ERROR>
[a02] [NeroAacEnc] Processed 0 seconds...
[a02] [NeroAacEnc] Processed 1 seconds...
.... (LINES CUT OUT FOR FORUM... THERE IS A LINE PER SECOND) ...
[a02] [NeroAacEnc] Processed 5053 seconds...
[a02] [NeroAacEnc] Processed 5054 seconds...
[a02] [NeroAacEnc] Process
Aborted at file position 2801484127. <ERROR>

[tebasuna51]

@robertcollier4
Please don't post the same in two threads http://forum.doom9.org/showthread.php?p=1610976#post1610976

[Chumbo]

I have a couple feature requests please:
- Would love to see an option that appends to the log. Right now the -log overwrites an existing log, which is how I expect it to behave. But it would be nice to have an "append" option. I just had a situation where I had to manually run eac3to and feed it the mpls playlist files because they were too small for eac3to to handle and wanted to get the output into one file. I wound up using a logger tool which works but it would be nice to have eac3to do it. :)
- Like MakeMKV, would love to see a user-settable option that allows us to override the "minimum" length that eac3to now skips. It can stay as it is now as the default, but would be great to provide it when I know I have a BD that contains many short clips.

Thanks for the consideration.

[Snowknight26]

Might as well keep this thread going.

eac3to should remove zlib compression from demuxed PGS streams.

[nautilus7]

This is the reason why pgs streams demuxed from matroska are not usable from any other software?

[Snowknight26]

If you use eac3to to demux them, yes. mkvextract can extract PGS streams and remove the compression (and maybe ffmpeg too, haven't checked).

[Brazil2]

Please, add an option to disable dithering when using downsampling.

[madshi]

I think "-dontDither" should already work.

[Brazil2]

I think "-dontDither" should already work.
Yes, it works. I didn't know about this switch as it doesn't appear in the help.
So thanks for the info :)

[Richard1485]

I've installed the latest version of Haali Matroska Muxer, but eac3to -test still states that a new version is available. How do I make eac3to recognize the new version?

[Sparktank]

I've installed the latest version of Haali Matroska Muxer, but eac3to -test still states that a new version is available. How do I make eac3to recognize the new version?

There were a few posts on the other eac3to thread that talks about the Haali versions.

Virtually, every install should be the same. Just the dates different, depending what you used to install Haali.

I believe packagers like K-Lite will have a different date from the official Haali site.

It's safe to ignore the message.
Unless it really bothers you then repeatedly ask the package maintainers to update their Haali installer to match that of eac3to.

There was a beta (testing) release of Haali before the most recent (official) update. Both the beta and the official are the same, just different compiling dates.

The dates for all recent installs are just a minor discrepancy.
Nothing's different between any of the versions.
Unless you managed to keep an older version of Haali or come across some custom-patched version (I believe CoreCodec's CoreAVC comes with a custom Haali install; optional).

[Richard1485]

Thanks. I downloaded Haali from videohelp.com, so I think I'll just ignore the message.

[orion44]

Downmix -down2 and simple stereo for all standard channel configuration.

If exist the parameter -mixlfe add:
FL' = ... + 0.7071 x LFE
FR' = ... + 0.7071 x LFE

2.1
Stereo
FL' = FL
FR' = FR

2/1 or 2/1.1
Stereo
FL' = FL + 0.7071 x BC
FR' = FR + 0.7071 x BC
Dpl
FL' = FL + 0.7071 x BC
FR' = FR - 0.7071 x BC

2/2 or 2/2.1
Stereo
FL' = FL + BL
FR' = FR + BR
Dpl
FL' = FL + 0.8660 x BL + 0.5000 x BR
FR' = FR - 0.5000 x BL - 0.8660 x BR

3/0 or 3/0.1
Stereo
FL' = FL + 0.7071 x FC
FR' = FR + 0.7071 x FC

3/1 or 3/1.1
Stereo
FL' = FL + 0.7071 x FC + 0.7071 x BC
FR' = FR + 0.7071 x FC + 0.7071 x BC
Dpl
FL' = FL + 0.7071 x FC + 0.7071 x BC
FR' = FR + 0.7071 x FC - 0.7071 x BC

3/2 or 3/2.1
Stereo
FL' = FL + 0.7071 x FC + BL
FR' = FR + 0.7071 x FC + BR
Dpl
FL' = FL + 0.7071 x FC + 0.8660 x BL + 0.5000 x BR
FR' = FR + 0.7071 x FC - 0.5000 x BL - 0.8660 x BR

3/2/1 or 3/2/1.1
Stereo
FL' = FL + 0.7071 x FC + BL + 0.7071 x BC
FR' = FR + 0.7071 x FC + BR + 0.7071 x BC
Dpl
FL' = FL + 0.7071 x FC + 0.8660 x BL + 0.5000 x BR + 0.7071 x BC
FR' = FR + 0.7071 x FC - 0.5000 x BL - 0.8660 x BR - 0.7071 x BC

3/2/2 or 3/2/2.1
Stereo
FL' = FL + 0.7071 x FC + BL + SL
FR' = FR + 0.7071 x FC + BR + SR
Dpl
FL' = FL + 0.7071 x FC + 0.8660 x (BL + SL) + 0.5000 x (BR + SR)
FR' = FR + 0.7071 x FC - 0.5000 x (BL + SL) - 0.8660 x (BR + SR)

Could you please provide a formula for the option -down6?

[tebasuna51]

Could you please provide a formula for the option -down6?

I supose from 6.1 or 7.1 to 5.1

The first four channels (FL,FR,FC,LFE) must remain the same to avoid changes in volume, I can't recommend a Normalize like after a down2.

Only the Side and Back channels must be used to obtain 2 Surround channels.

6.1 to 5.1

SL' = BL + 0.7071 x BC
SR' = BR + 0.7071 x BC

Normalized to avoid clip:

SL' = 0.5879 x BL + 0.4142 x BC
SR' = 0.5879 x BR + 0.4142 x BC

Or best option with BeHappy or MeGUI and AviSynth plugin AudioLimiter:

SL' = MixAudio(BL, BC, 1, 0.7071).SoftClipperFromAudX(0.0)
SR' = MixAudio(BR, BC, 1, 0.7071).SoftClipperFromAudX(0.0)

7.1 to 5.1

SL' = BL + SL
SR' = BR + SR

Normalized to avoid clip:

SL' = 0.5 x BL + 0.5 x SL
SR' = 0.5 x BR + 0.5 x SR

Or best option with BeHappy or MeGUI and AviSynth:

SL' = MixAudio(BL, SL, 1, 1).SoftClipperFromAudX(0.0)
SR' = MixAudio(BR, SR, 1, 1).SoftClipperFromAudX(0.0)

With the AudioLimiter plugin we obtain the same volume, most the time, with 2 surround speakers in 5.1 than 4 speakers in 7.1.
Only moments with high volume we can't preserve the volume balance between front and surround channels.

[orion44]

7.1 to 5.1

Normalized to avoid clip:

SL' = 0.5 x BL + 0.5 x SL
SR' = 0.5 x BR + 0.5 x SR


How much volume decrease is this in decibels?

Is there a way to convert these formulas to get values in decibels, for each channel?

[tebasuna51]

The coeficients (X) are relation between voltage the power dB's change are:

dB = 20 * log (X)

20 * log (0.5) = -6.02 dB
20 * log (0.7071) = -3.01 dB
...

[orion44]

When converting a 5.1 or 7.1 audio to stereo WAV, is there a way to equalize loudness during conversion,
so that the normal parts remain unchanged, and loud parts get decreased in volume?

Can this be done in ffmpeg or avisynth? Some filter, maybe?

[tebasuna51]

This is the purpose of SoftClipperFromAudX().
I think is safe to use it to mix surround channels first (7.1 -> 5.1), maybe can be used also to mix front with surround (5.1 -> 3.1) and after to 2.0:

FL' = FL + 0.7071 x FC
FR' = FR + 0.7071 x FC

and Normalize.