eac3to v3.24 Bugs & Improvements

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