eac3to v3.24 Bugs & Improvements

[cyberbeing]

Originally Posted by Snowknight26

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.

Originally Posted by Snowknight26

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]

Originally Posted by mood

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]

Originally Posted by tebasuna51

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

Originally Posted by tebasuna51

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]

Originally Posted by madshi

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]

Originally Posted by sneaker_ger

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]

Originally Posted by madshi

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

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]

Originally Posted by 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?

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