[LOCKED] EAC3TO Bug Reports and Feature Requests Only

[Curly]

Thank you!

[Curly]

yes yer right that fails with 3.36 but not 3.43
because I fixed that a long time ago
we need nautilus7 to follow up with a sample and/or clarification

[Guest 3]

When the Free Guy french (or german) eac3:

4: EAC3, French, 7.1 channels, 48kHz, dialnorm: 0dB
"DDP 7.1"

is extracted and loaded in eac3to show correctly:

E-AC3, 7.1 channels, 0:01:01, 896kbps, 48kHz, dialnorm: -27dB
(core: AC3, 5.1 channels, 0:01:01, 512kbps, 48kHz, dialnorm: -27dB)

maybe is a problem parsing the mkv

And I don't know any eac3 7.1 without core 5.1 (EAC3 or AC3 for BD's) like I show previously

[Curly]

Thank you, Guest 3. I don't know offhand how deep eac3to parses into elementary streams when the input is an MKV. I'll look into it. Even better, let's add it to the official list.
gonna ask you
what is the most important thing
i shud be working on right now for eac3to
in yer humble opinion

[nautilus7]

yes yer right that fails with 3.36 but not 3.43
because I fixed that a long time ago
we need nautilus7 to follow up with a sample and/or clarification

Hi, sorry for the delay. Here's the sample of the aforementioned EAC-3 track.
https://drive.google.com/file/d/1eHR9vg ... sp=sharing

Merry Christmas,
nautilus7

[Curly]

Thanks! Got it.

[Curly]

I looked into the stream and the error. As best I can tell, and Rocky agrees, the code that detects and reports these "errors" makes no sense at all. It looks like an attempt to determine if an AC3 core is present, but the input string looked at has no relation whatsoever with parameters of the stream. Instead it is simply a list of all the eac3 tracks. So that code can't possibly be doing anything useful. Accordingly, I have deleted it entirely.

The false 0dB dialnorm is still an issue. The code literally passes 0dB as a hardcoded constant when the container is MKV. I have to try to find out why that is done when things work just fine for AC3. Bottom line is these things are cosmetic and do not affect demuxing, etc.

[oniiz86]

When the Free Guy french (or german) eac3:

4: EAC3, French, 7.1 channels, 48kHz, dialnorm: 0dB
"DDP 7.1"

is extracted and loaded in eac3to show correctly:

E-AC3, 7.1 channels, 0:01:01, 896kbps, 48kHz, dialnorm: -27dB
(core: AC3, 5.1 channels, 0:01:01, 512kbps, 48kHz, dialnorm: -27dB)

maybe is a problem parsing the mkv

And I don't know any eac3 7.1 without core 5.1 (EAC3 or AC3 for BD's) like I show previously

That is a great discovery, thanks so much for testing that, it looks like the 0dB value is incorrect, there is the same 4dB attenuation of dianorm (-27dB) applied like the AC3 tracks, I wonder why the discrepancy?

[nautilus7]

Hi, previous versions of eac3to filtered out BD playlists. For example in this disc the playlists consisting of the same file did not show.

Code: Select all

F:\The Girl with the Dragon Tattoo 2011 CEE Blu-ray 1080p AVC DTS-HD MA 5.1>eac3to
1) 00003.mpls, 15:17:14
   [262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262+262].m2ts
   - Chapters, 500 chapters
   - MPEG2, 1080p24 /1.001 (16:9)
   - AC3, English, stereo, 48kHz

2) 00800.mpls, 00800.m2ts, 2:38:08
   - Chapters, 16 chapters
   - h264/AVC, 1080p24 /1.001 (16:9)
   - DTS Master Audio, English, multi-channel, 48kHz
   - AC3, Czech, multi-channel, 48kHz
   - AC3, Hungarian, multi-channel, 48kHz
   - AC3, Polish, multi-channel, 48kHz
   - AC3, Russian, multi-channel, 48kHz
   - AC3, English, stereo, 48kHz
   - AC3, Turkish, multi-channel, 48kHz
   - AC3, Ukrainian, multi-channel, 48kHz

3) 00099.mpls, 0:50:33
   [499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499+499].m2ts
   - Chapters, 101 chapters
   - h264/AVC, 1080p24 /1.001 (16:9)


F:\The Girl with the Dragon Tattoo 2011 CEE Blu-ray 1080p AVC DTS-HD MA 5.1>

[Curly]

That was changed intentionally to allow demuxing of menus.

[Peter]

First of all, thanks for the taking over the development of this very handy tool.

I believe that I found a bug in v3.43 (the first version that I've tried of the "new" eac3to).

Using 3.43, if I demux a stream (rather than a playlist), the PGS/SUP file is delayed by exactly 10 minutes (and out of sync with video/audio). Using the old eac3to (v3.34), the sync is correct.

v3.43 - first caption start time: 00:11:29.548
v3.34 - first caption start time: 00:01:29.548

The captions (start and end times) are consistently off by the same amount (exactly 10 minutes).

The disc that I used was Baise-moi (Kino Lorber, 2021, USA). I demux the (main-movie) stream, rather than the playlist, for most KL titles, since they typically have 3 streams: the KL logo/animation (with no audio/subtitles), the main movie, and ~1 second of black-screen (with no audio/subtitles)

The command I used (for both versions of eac3to) was:
eac3to "X:\TEMP\BAISE MOI\BDMV\STREAM\00004.m2ts" -demux

[Curly]

Interesting. PGS sync for seamless branching requires the CLPIs, so you have to open the playlist. However, here you have only one M2TS so no gaps. I could operate differently in that case. But maybe you actually have two M2TSs and you're trying to omit the first.

Maybe better would be to have the 'skip first' option like DGDemux.

I'll get the disk and see what I can do. Thank you for the report, Peter.

EDIT: I have KL Color of Night on hand that seems to be similar. I'll start with that while waiting for your disk to arrive.

[Peter]

Thanks for the quick response, Curly. Yeah, since I'm just demuxing a single stream (m2ts) file, I don't think that seamless branching would be a factor here. The video/audio/subtitles are all in sync in the stream. I've been using eac3to for this for quite some time (on nearly all KL titles, since most of them seem to have the structure that I mentioned, as well as others, like some StudioCanal European discs, for example). I don't recall having an issue with the subs (or audio) being out of sync, when using 3.34 to demux a single m2ts file, in the past.

I did also just test with DGDemux, and it works properly, when selecting the "skip first M2TS" option (subs are in sync, no 10-minute delay).

[Curly]

bro
do not doubt

gonna restore the old algorithm for the case of non-playlist input

[Curly]

Peter, can you please test this:

http://rationalqm.us/misc/eac3to_Peter.rar

If it is a bluray input then the new algorithm is used, otherwise the old one is used. I tested it successfully on Color of Night so I'm guessing your disk will be fine too. Note that this build also fixes the spurious EAC3 bitstream parsing warnings.

If it's OK, I'll make a slipstream. Thank you.

[nautilus7]

That was changed intentionally to allow demuxing of menus.

Do menus use the same m2ts repeatedly?

For those not interested in menus, now eac3to produces a lot of spam. Useless and confusing playlists. Maybe you could add an option in the ini file, like for dialnorm, so users can disable menu scanning?

regards.

[Curly]

Do menus use the same m2ts repeatedly?

Sometimes, yes. DGDemux has a collapse option so you can demux only the first one. That could be useful here too.

A new option is not justified IMHO. Probably you can live with it.

[Peter]

Peter, can you please test this:

http://rationalqm.us/misc/eac3to_Peter.rar

If it is a bluray input then the new algorithm is used, otherwise the old one is used. I tested it successfully on Color of Night so I'm guessing your disk will be fine too. Note that this build also fixes the spurious EAC3 bitstream parsing warnings.

If it's OK, I'll make a slipstream. Thank you.

Curly, it is working now. PGS/SUP file matches what was generated by v3.34. Thanks for the quick fix.

[DelBoy83]

Peter, can you please test this:

http://rationalqm.us/misc/eac3to_Peter.rar

If it is a bluray input then the new algorithm is used, otherwise the old one is used. I tested it successfully on Color of Night so I'm guessing your disk will be fine too. Note that this build also fixes the spurious EAC3 bitstream parsing warnings.

If it's OK, I'll make a slipstream. Thank you.

I also has a problem demuxing a single stream ( not playlist) . In my case the runtime was around 10 minutes longer than the actual m2ts used. This was also using a Kino Lorber title. The new build corrects the problem I can confirm so thankyou for the quick fix Curly.

[Curly]

You're welcome and thank you for the confirmation, DelBoy83. I have made a slipstream. Onward and upward.

(i shudda reelalised this at the time but i was fokused on getting UHD working gud
now both work gud so hallie lou lee ah)

[Curly]

@skull

Greetz. Do you know if videohelp just links our EXEs at DG site or do they host an actual EXE? If the latter we will need to let them know to update it, and maybe tell them about how we do the slipstream thing (new version only for new functionality, etc.). Thanks and I hope your holidays are going super dooper.

[HPotter]

Try this:

http://rationalqm.us/eac3to_mod/eac3to_ ... 1_test.rar

Without -showall it is like 3.34/3.36. With -showall all playlists are shown.

It's back to the drawing board to get minimum duration working. Probably that's
why it was removed from 3.36 by madshi.

We'll have to get 3.41 out there quick now, so please test this guys.

Seems -minDuration=600 in 3.43 version again shows parasite playlists like
"1) 00003.mpls, 5:09:24
[6+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7+7].m2ts"

and no possible to not show them.
How to turn off those function as you did for 3.41 and without this was like for 3.36?

[Curly]

Apparently you are not following the thread, sir. As mentioned those playlists are the disk menus, static screens, warnings, etc. They are not parasites. They are legitimate playlists on the disk that may be required by some use cases, e.g., demuxing of menus. You cannot suppress them but you can ignore them if they are not of interest to you. But I guess that you can get used to them.

[HPotter]

For someone it could usefull I agreed, but for 15 years not at once needed for me playlists like this with dubled a lot of times the same one file, just distracts.

Would be nice with deleting -minDuration=600 function from .ini or some turn off this to got shown playlists like was in 3.36 / 3.41 versions.
Possibility is great but when you can turn off if it's no needed.

[Curly]

Sorry not gonna add an option to turn it off. Think positively, now you can look at the list and say, ooh there's the menu, ooh look, there's the FBI warning, ooh there's the main movie.

However, I will likely add a 'collapse' option like DGDemux has. Maybe also add the preview functionality too:

eac3to g:\disk 2) -preview

The collapse option is typically used by 3rd-party applications (e.g., chapterEditor by hubblec4) to support creation of multi-edition MKV files. When given, this option collapses runs of the same M2TS file to singles. E.g., 00040.m2ts+00040.m2ts+00040.m2ts becomes just 00040.m2ts. Then you wouldn't be demuxing the same file multiple times, saving disk space and time.

Generally, people are going to have to expect that features of DGDemux may appear in eac3to, and vice versa. We could for example port dialnorm removal to DGDemux. But mainly, I've been focused on getting eac3to to a point where it properly supports UHD/HEVC, and on fixing long-standing issues. Please try to see the forest for the trees.