eac3to - audio conversion tool

[Overdrive80]

Somone might have a link to a binary with the date eac3to expects.
Or whatever codec pack you're using (if any), you could ask them to update their installer.

Thanks for you answer, i use cccp códecs, i gonna try klcp. (Really is not importante but eac3to in this sense show message wrong)

[howzz]

I think that 1MiB for read is ok. The problem is most likely in write size. However some cheaper SSDs still need larger size for max speed. Personally I own C100 so I wouldn't mind if read size was increased up to 16 MiB - 64 MiB for max performance.



it's good to see the maker of ripbot actively involved in eac3to. hopefully in the future release of ripbot, we'll see a faster version of eac3to, and waiting for demuxing will be the thing of the past, that's my dream.

:thanks:

[Groucho2004]

Personally I own C100 so I wouldn't mind if read size was increased up to 16 MiB - 64 MiB for max performance.
That's ridiculous and you obviously didn't read madshi's post about write block sizes.

[Atak_Snajpera]

That's ridiculous and you obviously didn't read madshi's post about write block sizes.

Read my post again.
I wrote 16 MiB - 64 MiB for read chunk not for write chunk. I understand that memory issue is only for write.

Personally I do not mind 16 MiB for read and write. Madshi could limit this value if bluray movie has insane number of streams. Also I don't see problem if eac3to will temporary eat 2 GiB of my ram. Most decent pcs have atleast 4GiB.

[howzz]

i wonder how much ram it would consume if the read/write chunk were optimized to 16M/16M. if Atak's benchmark is any consolation, even 16MB will pretty much provide the majority of performance increase.

i am sure 2GB of working allocated memory shouldn't be anything anyone should worry about. only person i know in my life that's still using 4GB memory is my mother in law, and she doesn't know what eac3to is. even then, she's on a 64bit win7.

anything Madshi can do would be greatly appreciated. :)

[Atak_Snajpera]

Like Madshi said It depends how many streams (VIDEO,AUDIO,SUBTITLES) you have in container.

[Groucho2004]

i am sure 2GB of working allocated memory shouldn't be anything anyone should worry about.
You're ignoring the fact that eac3to is a 32 Bit application which limits the user address space to 2G (4G with some tweaking on a 64 Bit OS).

[Groucho2004]

Read my post again.
I wrote 16 MiB - 64 MiB for read chunk not for write chunk. I understand that memory issue is only for write.

Personally I do not mind 16 MiB for read and write. Madshi could limit this value if bluray movie has insane number of streams. Also I don't see problem if eac3to will temporary eat 2 GiB of my ram. Most decent pcs have atleast 4GiB.
Have a look at the ATTO ssd benchmarks, for example on Anandtech. Most ssd's max out at 64 K block size, read or write.

I don't know how you wrote your benchmark but copying files with a size of e.g. 1MB 100 times is not the same as copying a file of 100 MB with 1 MB block size.

[arrgh]

Oh. It's possible that eac3to isn't comparing the chapters when deleting "duplicate" playlists from the listing.

is there an Option to suppress the deletion of "duplicate" playlists? In times of "playlist obsfucation / screen pass" that might be a useful Option...

[Atak_Snajpera]

Have a look at the ATTO ssd benchmarks, for example on Anandtech. Most ssd's max out at 64 K block size, read or write.

I don't know how you wrote your benchmark but copying files with a size of e.g. 1MB 100 times is not the same as copying a file of 100 MB with 1 MB block size.

1. atto by default works with compresible data
This allows sandforce controller to cheat.

2. atto is using by default queue depth=4
The most common depth in real tasks is queue = 1.

[Atak_Snajpera]

My bench works in queue 1.

Copying is done by simple windows function CopyFileEX with COPY_FILE_NO_BUFFERING flag. (https://msdn.microsoft.com/en-us/library/windows/desktop/aa363852%28v=vs.85%29.aspx)

If think that eac3to also works in queue 1 hence big size of data is needed to saturate all channels in SSD's controller.

[Q-the-STORM]

Imagine 100 tracks with a chunk size of 16MB. That would already bring us to 1.6GB, and a win32 process is only allowed to allocate 2GB. So increasing the output chunk size can quickly result in out-of-memory situations, if I'm not careful.

couldn't you simply give the user the option to use a smaller chunk size? 16MB as default, and flags -1MB -2MB -4MB -8MB for smaller sizes...
or is implementing different chunk sizes a lot of work? 16MB default and an optional -1MB flag would probably do just as well then... or 16 default and 8MB, I don't think there will be many sources with more than 200 tracks... you could also just let eac3to decide, if a source has more than 100 tracks -> use 8MB, more than 200 tracks -> use 4MB...
though I do think 16MB default and flags to let the user decide would be the best thing, especially for people that use most of their RAM in normal use and don't always want or aren't able to spare more for eac3to..

anyways, most times you got 3-20 tracks, so 16MB default would almost always be a good thing...

[r0lZ]

The buffer size could also be computed at run time, according to the number of streams and available free RAM. IMO, it's the best option, and it should ideally be available if the idea of an option with several buffer sizes is implemented, as an additional "auto" size.

[Lenmaer]

This an SSD benchmark thread now?

[madshi]

is there an Option to suppress the deletion of "duplicate" playlists? In times of "playlist obsfucation / screen pass" that might be a useful Option...
eac3to only drops duplicate playlists. That should actually help with obfuscation because the insane number of playlists is reduced a bit by this.

-------

About eac3to performance: It's a bit unfortunate that everybody is talking about chunk sizes now, without looking at anything else. I don't think the chunk size is the problem, nor the key to salvation. As I wrote earlier:

There are various possible reasons for slowdown. Of course it's quite possible that some processing filters in eac3to are wasting time. Or it's possible some external software is wasting time (e.g. Haali MKV muxer). Or it's possible that the SSD or the OS is at fault. It's really hard for me to say. A couple tests you could do:

1) Try "eac3to source -check". That will just read the source and demux it, but not encode or write anything.
2) If 1) already shows slow speeds, try a simply "copy" command line command to check how fast that runs through.
3) If 1) already shows slow speeds, try different containers to see if the problem might be specific to one (or several) containers.
I've tried to increase chunk sizes here on my Samsung Pro SSD, and it didn't help performance *at all*. Same performance as before. The problem is likely to be somewhere else. One suspicion I have is that eac3to's parsing of the video track might be at fault - especially when h264 is involved. eac3to fully parses every bit of every video track, and for h264 even rewrites the stream every time, "bit by bit". This *may* be the decisive slow down factor. Or maybe not. I hope that now not everyone will talk about how to fix h264 slowdown problems in eac3to. I'm just throwing around some thoughts here. None of this is tested or proven. I don't have a lot of time atm, anyway, so if the real cause of the problem is more complex than the chunk size (which I think it probably is), I won't have time to fix that soon. But instead of discussing things I could do, please guys, first try to find out by doing analytical tests where the real bottleneck is.

[Atak_Snajpera]

1) Try "eac3to source -check". That will just read the source and demux it, but not encode or write anything.
2) If 1) already shows slow speeds, try a simply "copy" command line command to check how fast that runs through.
3) If 1) already shows slow speeds, try different containers to see if the problem might be specific to one (or several) containers.

AVC.mkv
General
Unique ID : 245455972442929439196667259541358469211 (0xB8A919C9CFCD744DB899E6E03D99605B)
Complete name : C:\Users\Dave\Desktop\Drive-AVC-remux.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 2.44 GiB
Duration : 10mn 15s
Overall bit rate mode : Variable
Overall bit rate : 34.0 Mbps
Encoded date : UTC 2015-03-14 16:43:32
Writing application : mkvmerge v7.2.0 ('On Every Street') 32bit built on Sep 13 2014 15:42:11
Writing library : libebml v1.3.0 + libmatroska v1.4.1
DURATION : 00:10:15.031000000
NUMBER_OF_FRAMES : 14746
NUMBER_OF_BYTES : 2617507214
_STATISTICS_WRITING_APP : mkvmerge v7.2.0 ('On Every Street') 32bit built on Sep 13 2014 15:42:11
_STATISTICS_WRITING_DATE_UTC : 2015-03-14 16:43:32
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 10mn 15s
Bit rate mode : Variable
Bit rate : 33.4 Mbps
Maximum bit rate : 37.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.671
Stream size : 2.39 GiB (98%)
Default : Yes
Forced : No



VC-1.mkv
General
Unique ID : 178944820121177913025717090745631236997 (0x869F84CC91034C4D9ED0E1E12775E385)
Complete name : C:\Users\Dave\Desktop\Last_Man_Standing_VC1_10Min-remux.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 1.70 GiB
Duration : 10mn 0s
Overall bit rate : 24.3 Mbps
Encoded date : UTC 2015-03-14 16:33:38
Writing application : mkvmerge v7.2.0 ('On Every Street') 32bit built on Sep 13 2014 15:42:11
Writing library : Lavf52.110.0

Video
ID : 1
Format : VC-1
Format profile : Advanced@L3
Codec ID : V_MS/VFW/FOURCC / WVC1
Codec ID/Hint : Microsoft
Duration : 10mn 0s
Bit rate : 23.8 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.479
Stream size : 1.66 GiB (98%)
Default : Yes
Forced : No
DURATION : 00:10:00.058000000
NUMBER_OF_FRAMES : 14387
NUMBER_OF_BYTES : 1822959885
_STATISTICS_WRITING_APP : mkvmerge v7.2.0 ('On Every Street') 32bit built on Sep 13 2014 15:42:11
_STATISTICS_WRITING_DATE_UTC : 2015-03-14 16:33:38
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES



eac3to -check

http://i.cubeupload.com/qrgGIz.png

[madshi]

Ok, thanks, and maybe something without any video tracks?

[Atak_Snajpera]

What do you mean? Audio only?

[trevaaar]

I have a file that eac3to erroneously detects as being HDCD-encoded. It's a 24-bit 5.1-channel FLAC (though most samples are zero-padded 16-bit). The problem with this is that HDCD decoding appears to be force-enabled when converting to a lossy format, so attempts to transcode to AC3 always fail with the error "there is no HDCD data to decode" regardless of whether I pass in -decodeHdcd or not.

First few seconds of the file that exhibits the problem: https://mega.co.nz/#!59kX0ASb!MwwBiFhAQCy8EvCOTuifDxXEFJoSHMSAiEs26I1rBHk

[madshi]

What do you mean? Audio only?
Yes, some file with a similar file length (e.g. some DTS-HD or TrueHD track muxed to MKV or so) without a video track. Just to check if video stream parsing might be responsible for the slowdown.

I have a file that eac3to erroneously detects as being HDCD-encoded. It's a 24-bit 5.1-channel FLAC (though most samples are zero-padded 16-bit). The problem with this is that HDCD decoding appears to be force-enabled when converting to a lossy format, so attempts to transcode to AC3 always fail with the error "there is no HDCD data to decode" regardless of whether I pass in -decodeHdcd or not.

First few seconds of the file that exhibits the problem: https://mega.co.nz/#!59kX0ASb!MwwBiFhAQCy8EvCOTuifDxXEFJoSHMSAiEs26I1rBHk
http://eac3to.bugs.madshi.net

[Thunderbolt8]

what to think of this? http://forum.timramich.com/viewtopic.php?f=16&t=26

[madshi]

It's known that the DTS encoding suite can decode 7.1 channels losslessly. But that's a copy protected software and not easy to remote control from eac3to. So it's not really a good option for eac3to. There might be an open source decoder available soon, though, which might solve this problem. Or maybe not, we'll have to wait and see...

[tebasuna51]

what to think of this? http://forum.timramich.com/viewtopic.php?f=16&t=26

To decode "7.1 - L, R, C, LFE, Ls, Rs, Lsr, Rsr" (strange setup) losslessly, like if was "7.1 - L, R, C, LFE, Lss, Rss, Lsr, Rsr", you can use MakeMKV, the dtsdecoderdll.dll from ArcSoft and a profile like the attached.

[nevcairiel]

It's known that the DTS encoding suite can decode 7.1 channels losslessly. But that's a copy protected software and not easy to remote control from eac3to. So it's not really a good option for eac3to. There might be an open source decoder available soon, though, which might solve this problem. Or maybe not, we'll have to wait and see...

The good news is that the "strange setup" can already be decoded completely lossless with this potential decoder, well, at least the sample I had.

Its fun to see what other "reference" decoders do with strange-setup though. Somehow they postprocess the channels to make a "normal" surround setup out of them, because they assume any software couldn't possibly comprehend the extra front-surround channels.

[madshi]

The good news is that the "strange setup" can already be decoded completely lossless with this potential decoder, well, at least the sample I had.
Great! :)

Its fun to see what other "reference" decoders do with strange-setup though. Somehow they postprocess the channels to make a "normal" surround setup out of them, because they assume any software couldn't possibly comprehend the extra front-surround channels.
Yeah. And some ArcSoft versions even produced corrupted sound data... :eek:

[Nebudchanezzer]

To decode "7.1 - L, R, C, LFE, Ls, Rs, Lsr, Rsr" (strange setup) losslessly, like if was "7.1 - L, R, C, LFE, Lss, Rss, Lsr, Rsr", you can use MakeMKV, the dtsdecoderdll.dll from ArcSoft and a profile like the attached.

Didn't know that, very interesting!

Did a test with a small track I have encoded with MA-suite to both
"normal" setup and "strange setup", seems to work great except there seems to be one extra DTS-frame at the end of the "strange setup"-track.

Don't know if that is something added by the MA-suite or if MakeMKV add an extra though.

Thank you for the info anyway!

Looking forward to the new codec!

EDIT:From Foobar:

Differences found in compared tracks.

Comparing:
"N:\Decode.test.reencoded.to.standard.setup.flac"
"N:\title00_track2_eng_DELAY 0ms.flac"
Length mismatch : 4:18.154667 vs 4:18.165333, 12391424 vs 12391936 samples.
Compared 12391424 samples, discarded last 512 samples from the longer file.
No differences in decoded data found within the compared range.

[arrgh]

...just a tiny small remark, not really very critical :

for me it is inconvinient that "-progressnumbers" gives a line feed after each number; I would prefer, if the Output would remain in the same line (CR without LF)...

[Atak_Snajpera]

progressnumber switch was added for gui makers. It is easier to capture output if you have new line.

[r0lZ]

It is impossible to change the --progressnumbers behaviour. It is used by many GUIs, and even a very small change would break them.
If you want only a single line of output, do not specify the --progressnumbers argument, and watch the progress bar.

[madshi]

Btw, does the GUI error message capturing work now with the latest eac3to?

[r0lZ]

Sorry, I haven't tested that yet. I will try tomorrow.

[stax76]

Btw, does the GUI error message capturing work now with the latest eac3to?

yes :thanks:

[r0lZ]

Indeed, the error message is now correctly captured when STDERR is redirected. There are still many control characters and spaces that makes it difficult to parse the error message, but that difficulty is less important. However, if you can remove the formatting characters when eac3to detects that the output (STDOUT and/or STDERR) is redirected, or when an option is specified on the command line, I'm sure that will simplify the life of the programmers of the eac3to GUIs. But don't worry. Currently, I have what I need. Thanks for the fix!

[madshi]

I'm not sure if/how I can detect whether stdout/stderr are redirected. Those control chars are probably spaces and backspaces etc? Won't it break current GUIs if I suddenly drop all those control chars from the output?

[stax76]

A good way to handle output it is make a dedicated class and always capture both stderr and stdout simultaneously. If I remember right only eac3to requires to trim (start and end) or to remove certain chars like back char and only DGIndex requires to use regex because it outputs progress too minimalistic. Another interesting thing is that mkvmerge, mkvextract and ffmpeg output UTF8, I guess it's standard for unix tools, in .NET it can be defined using the properties ProcessStartInfo.StandardErrorEncoding and ProcessStartInfo.StandardOutputEncoding. Handling eac3to output is for beginners definitively the most difficult but I suggest to see it as learning experience. :)

edit:

Won't it break current GUIs if I suddenly drop all those control chars from the output?

Mine wouldn't break I think, I don't mind breaking changes as long as I know about it.

my code is still pretty easy:

Using proc As New Proc
proc.Init("Convert to WAV/FLAC using eac3to")
proc.File = Packs.eac3to.GetPath
proc.Arguments = args
proc.TrimChars = {"-"c, " "c}
proc.RemoveChars = {VB6.ChrW(8)} 'backspace
proc.SkipStrings = {"process:", "analyze:"}
proc.AllowedExitCodes = {0, 1}
proc.Start()
End Using

it's a nice example that array literals are a kick ass feature that C# don't has

[madshi]

Haha! Well, it wasn't my intention to make it difficult. I'm willing to make it easier, so I'm open for suggestions, but I also don't want to break current GUIs.

[r0lZ]

I'm not sure if/how I can detect whether stdout/stderr are redirected. Those control chars are probably spaces and backspaces etc? Won't it break current GUIs if I suddenly drop all those control chars from the output?
It's a risk. It is probably better to implement a new option such as -gui, to output only plain text.

And yes, the control characters are mainly BS and spaces. I don't think the characters that control the color or bold attributes are included in the redirected output, but I'm not sure.

Anyway, as stax76 wrote, it is difficult but not impossible and a good exercise to parse the current format. Don't worry too much, and implement a modification only if it's easy for you.

[Atak_Snajpera]

Haha! Well, it wasn't my intention to make it difficult. I'm willing to make it easier, so I'm open for suggestions, but I also don't want to break current GUIs.

If ain't broke don't fix it ;) -progressnumbers works well. No need to waste your precious time for this.

[r0lZ]

-progressnumbers is perfect as it is and should not be modified. The problem are the other lines printed to STDOUT (and, perhaps, to STDERR). They are difficult to parse, due to the lot of BS and Space characters. But I agree with you. It is not really necessary to fix that problem, as it's not really a bug. I repeat that personally, I don't need a modification, but it might be useful to implement it for others.

[Libeluratio]

Hi everyone,

Trying to make wavs from dolby atmos file, I get these:
[libav] Lossless check failed - expected 00, calculated d7. <WARNING>
[libav] Lossless check failed - expected 00, calculated 71. <WARNING>
[libav] Lossless check failed - expected 00, calculated dc. <WARNING>
[libav] Lossless check failed - expected 00, calculated b2. <WARNING>
[libav] Lossless check failed - expected 00, calculated 24. <WARNING>
[libav] Lossless check failed - expected 00, calculated 78. <WARNING>
[libav] Lossless check failed - expected 00, calculated cb. <WARNING>
[libav] Lossless check failed - expected 00, calculated ee. <WARNING>
[libav] Lossless check failed - expected 00, calculated d6. <WARNING>
[libav] Lossless check failed - expected 00, calculated c0. <WARNING>
[libav] Lossless check failed - expected 00, calculated de. <WARNING>
[libav] Lossless check failed - expected 00, calculated 55. <WARNING>
[libav] Lossless check failed - expected 00, calculated b2. <WARNING>
[libav] Lossless check failed - expected 00, calculated a5. <WARNING>
[libav] Lossless check failed - expected 00, calculated a3. <WARNING>
[libav] Lossless check failed - expected 00, calculated 1f. <WARNING>
[libav] Lossless check failed - expected 00, calculated 8a. <WARNING>
[libav] Lossless check failed - expected 00, calculated 6e. <WARNING>
[libav] Lossless check failed - expected 00, calculated 2e. <WARNING>
Original audio track, L+C+LFE+BL+BR+SL: max 24 bits, average 20 bits.
Original audio track, R+SR: constant bit depth of 21 bits.

I've got an updated version of ffmepg.

Sorry if that was already answered (I didn't manage to find answer to that), but is this a normal behaviour ? Will my wav files be corrupted ?

Thank you !

[madshi]

Ok, I'll keep the console output the way it is for now, thanks for the feedback.

@Libeluratio, is that a seamless branching Blu-Ray? This "lossless check failed" message is expected to appear once for each m2ts part. Have a look at of how many m2ts parts your movie playlists consists. If it's around 19, you should be fine.

[Libeluratio]

Indeed, I extracted the TrueHD stream with TSMuxer from a The Hunger Games Mockingjay: Part 1 BD. The movie is indeed composed of 20 m2ts files (so 19 divisions), so you're saying this behaviour of having 19 "Lossless check failed" is normal ? There will no be any sync problem or audio artefacts/dropouts etc ?

Thank you !

[madshi]

Well, it's better to let eac3to work with the original Blu-Ray files to give it full control. I don't know how TSMuxer deals with audio overlaps.

[Libeluratio]

Ok, thanks madshi for your answers. I'll use exclusively eac3to for handling streams from bluray from now on in order to avoid issues.


EDIT:

I will try with the original Bluray tomorrow, but today I tried with the mkv (that I made with the help of tsmuxer) to handle this problematic Atmos file withe eac3to. I tried two times: first with the HD-DVD/Blu-ray Stream Extractor v0.8.3771, and second with command lines. and the two results seems different !

1 - Log From HD-DVD/Bluray Stream Extractor v0.8.3771:

eac3to v3.28
command line: "C:\eac3to\eac3to.exe" "D:\HG\HG.mkv" 3:"D:\HG\wavs direct gui\1_3_audio.wavs" -down6 -progressnumbers
------------------------------------------------------------------------------
MKV, 1 video track, 3 audio tracks, 3 subtitle tracks, 2:02:49, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: AC3, French, 5.1 channels, 640kbps, 48kHz
"VFQ 5.1 640 Kbps"
3: TrueHD (Atmos), English, 7.1 channels, 48kHz
"VOA TrueHD 7 719 Kbps"
4: AC3, English, 5.1 channels, 640kbps, 48kHz
"VOA 5.1 640 Kbps"
5: Subtitle (PGS), English, "Complet"
6: Subtitle (PGS), English, "Complet SDH"
7: Subtitle (PGS), French, "Complet"
[a03] Extracting audio track number 3...
[a03] Decoding with libav/ffmpeg...
[a03] Mixing surround channels...
[a03] Writing WAVs...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.L.wav"...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.R.wav"...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.LFE.wav"...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.SL.wav"...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.C.wav"...
[a03] Creating file "D:\HG\wavs direct gui\1_3_audio.SR.wav"...
[a03] Original audio track, L+C+LFE+BL+BR+SL: max 24 bits, average 20 bits.
[a03] Original audio track, R+SR: constant bit depth of 21 bits.
[a03] Processed audio track, L+C+LFE+SL+SR: max 24 bits, average 21 bits.
[a03] Processed audio track, R: constant bit depth of 21 bits.
Video track 1 contains 176684 frames.
eac3to processing took 10 minutes, 27 seconds.
Done.



2 - Log from cmd line:

eac3to v3.28
command line: "C:\eac3to\eac3to.exe" "D:\HG\HG.mkv" 3:"D:\HG\wavs direct cmd\1_3_audio.wavs" -down6 -progressnumbers
------------------------------------------------------------------------------
MKV, 1 video track, 3 audio tracks, 3 subtitle tracks, 2:02:49, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: AC3, French, 5.1 channels, 640kbps, 48kHz
"VFQ 5.1 640 Kbps"
3: TrueHD (Atmos), English, 7.1 channels, 48kHz
"VOA TrueHD 7 719 Kbps"
4: AC3, English, 5.1 channels, 640kbps, 48kHz
"VOA 5.1 640 Kbps"
5: Subtitle (PGS), English, "Complet"
6: Subtitle (PGS), English, "Complet SDH"
7: Subtitle (PGS), French, "Complet"
[a03] Extracting audio track number 3...
[a03] Decoding with libav/ffmpeg...
[a03] Mixing surround channels...
[a03] Writing WAVs...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.L.wav"...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.R.wav"...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.SR.wav"...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.SL.wav"...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.C.wav"...
[a03] Creating file "D:\HG\wavs direct cmd\1_3_audio.LFE.wav"...
[a03] [libav] Lossless check failed - expected 00, calculated d7. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 71. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated dc. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated b2. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 24. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 78. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated cb. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated ee. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated d6. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated c0. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated de. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 55. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated b2. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated a5. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated a3. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 1f. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 8a. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 6e. <WARNING>
[a03] [libav] Lossless check failed - expected 00, calculated 2e. <WARNING>
[a03] Original audio track, L+C+LFE+BL+BR+SL: max 24 bits, average 20 bits.
[a03] Original audio track, R+SR: constant bit depth of 21 bits.
[a03] Processed audio track, L+C+LFE+SL+SR: max 24 bits, average 21 bits.
[a03] Processed audio track, R: constant bit depth of 21 bits.
Video track 1 contains 176684 frames.
eac3to processing took 10 minutes, 17 seconds.
Done.


As you can see, the "Lossless check failed" Warnings only appears when I do not use the GUI. Maybe this is only a verbose logging difference ?

Also, the 6 channels are not created in the same order in the two cases, I don't know why and if this is important ?

[Anakunda]

This message certainly suxx on latest eac3to update:

A monitor program has been found running in your system. Please, unload it from memory and restart your program.

Of course I don't know what I should uninstall or unload, there's nothing monitoring or something eac3to is too paranoid. It seems this message appears only if decoding DTS MA using ArcSoft. AC3 went fine.

[madshi]

@Libeluratio, the order of the WAV file creation shouldn't matter. Not sure, though, why you don't get the warnings with the GUI.

@Anakunda, this message doesn't come from eac3to. Must be from ArcSoft, I would guess...

[Anakunda]

@Anakunda, this message doesn't come from eac3to. Must be from ArcSoft, I would guess...

Yep it looks so. Anyway it didn't happen previously with ArcSoft, any info leading to remove the reason of this message would be helpful since the ArcSoft is deactivated in this case

The ArcSoft and Sonic decoders don't seem to work, will use libav instead.
The libav DTS decoder doesn't decode the full DTS-HD information. <WARNING>

[Groucho2004]

This message certainly suxx on latest eac3to update:

A monitor program has been found running in your system. Please, unload it from memory and restart your program.
Do you use IObit malware fighter or some similar crapware?

[Anakunda]

IObit malware fighter or some similar nonsense?
exactly :D

I have installed MBAM and Superantispyware however both in passive mode + Comodo personal firewall (HIPS didn't seem to conflict with EAC3to, not using HIPS)

Anyone can confirm if latest MBAM blocks Arcosft decoders? Not updated anything else.

[r0lZ]

I have MBAM free (also in passive mode) and I have never noticed problems with the Arcsoft decoders. I don't use IObit.