UsEac3to v1.3.6: a different GUI for eac3to

[tebasuna51]

You can asociate extension .au3 to AutoIt3_x64.exe, after that double click over .au3 run it interpreted.

[hardkid]

Originally Posted by tebasuna51

You can asociate extension .au3 to AutoIt3_x64.exe, after that double click over .au3 run it interpreted.

Done. Thank you.

[oniiz86]

@tebasuna51 I'm not sure if you're aware but eac3to development has resumed & a new build v3.53 has just been released, I was just curious how you determined the EAC3 7.1 streams decoded as 5.1 ignoring the additional channels issue?

I demuxed a EAC3 7.1 track & MediaInfo reports it fine below, will the issue present itself if I select the A/V Recode button & then select "Recode to E/AC3, ffmpeg" which I noticed it doesn't have a bitrate greater than 640k to select & then mux it into a mkv container & play it back via my AVR, will it decode it as only EAC3 5.1 & simply discard the additional channel information?

Format : E-AC-3
Format/Info : Enhanced AC-3
Commercial name : Dolby Digital Plus
Format profile : Blu-ray Disc
File size : 737 MiB
Duration : 1 h 54 min
Overall bit rate mode : Constant
Overall bit rate : 896 kb/s

Audio
Format : E-AC-3
Format/Info : Enhanced AC-3
Commercial name : Dolby Digital Plus
Format profile : Blu-ray Disc
Duration : 1 h 54 min
Bit rate mode : Constant
Bit rate : 896 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 737 MiB (100%)
Service kind : Complete Main
Dialog Normalization : -31 dB
compr : -0.28 dB
cmixlev : -3.0 dB
surmixlev : -6 dB

[tebasuna51]

Due to an accident, I'm wheelchair-bound and unable to access my usual equipment to test the new version of eac3to.
However, I don't think it'll modify the previous version for what you're asking for.

Indeed, ffmpeg doesn't encode eac3 7.1, only 5.1, unless you use the method suggested in the thread Encode to 7.1 eac3 for free and volume adjustment.
In any case, I don't see the point of re-encoding an eac3 7.1 version back to eac3 7.1.

[SeeMoreDigital]

Originally Posted by tebasuna51

Due to an accident, I'm wheelchair-bound and unable to access my usual equipment to test the new version of eac3to...

So sorry to hear this. I wish you well...

[oniiz86]

Originally Posted by tebasuna51

Due to an accident, I'm wheelchair-bound and unable to access my usual equipment to test the new version of eac3to.

@tebasuna51 Oh I'm so sorry to hear this, hoping for a speedy recovery & wish you well.

[GeoffreyA]

Best wishes, tebasuna. Take care.

[tebasuna51]

Thanks for the good wishes, I hope it's just a month of discomfort.

[infoxtreme]

Hi tebasuna51 how are you ? I hope you are better, I wish you a speedy recovery.

after the new eac3 version and a clean install of windows 11 25h2 i'm having this problem, any ideas?

[chainring]

@infoextreme,

https://www.microsoft.com/en-us/down....aspx?id=26999

[infoxtreme]

Originally Posted by chainring

@infoextreme,

https://www.microsoft.com/en-us/down....aspx?id=26999

Thanks very much, install x64 x86 all ok, works !!

[oniiz86]

Originally Posted by tebasuna51

The names generated by the eac3to demux put the full language names and comments, for instance:

...Japanese, 'Japanese'.srt
...Korean, 'Korean'.srt
...Spanish, 'Latin America Spanish [SDH]'.srt
...Norwegian, 'Norwegian'.srt
...Polish, 'Polish'.srt

My UsEac3to GUI put only the first 3 caracters to identify the track and can't convert it to the exact language codes.

@tebasuna51 Hey Teba, I had sent you a PM recently about an eac3to bug regarding language code syntax & just noticed this post about how UsEac3to manages language codes, as I had mentioned in my PM, I've been in touch with the eac3to developer & he will release a test version shortly, this is what was mentioned "So, I have to revise eac3to to always use filenames that match the expected
mkvtoolnix filename parsing rules. I will do that. Probably, I will always use the 3-letter
code included in square brackets, e.g., '[eng]'.", is this something that you could update in UsEac3to or is it a permanent limitation that you can't get around?

[Columbo]

"My UsEac3to GUI put only the first 3 characters to identify the track and can't convert it to the exact language codes."

When eac3to is revised to use the [eng] format then UsEac3to can presumably pick that up and use it.

[tebasuna51]

Originally Posted by oniiz86

... I had sent you a PM recently...

My answer to your PM:

UsEac3to is only a GUI for eac3to and the track names are generated with the eac3to info, for instance if eac3to show:
MKV, 1 video track, 5 audio tracks, 0:00:21, 25p
1: h264/AVC, English, 720p25
2: AAC, Spanish, 5.1 channels, 48kHz, dialnorm: 0dB
3: AC3, English, 5.1 channels, 448kbps, 48kHz, dialnorm: -31dB
4: E-AC3, French, 5.1 channels, 448kbps, 48kHz, dialnorm: -31dB
5: FLAC, German, 5.1 channels, 0:00:20, 16 bits, 48kHz, dialnorm: 0dB
6: OPUS, Portuguese, 5.1 channels, 48kHz, dialnorm: 0dB

the track names are generated like 2spa, 3eng, ...
the track number and the 3 first characters of the languaje, sometimes can be recognized by MkvToolNix (but not japonese for instance) if you follow the mbunkus Guide

I can insert a default boundary character to obtain 2-spa, 3-eng, ... but still you need config the 'Recognized languajes' not only add 1234567890 to boundary characters.

BTW when eac3to make the new version I can test it, but I hope not need changes to support it.
Maybe if instead languaje info like 'japonese' is changed by the 3 character code 'jpn' all is ok now.

Remember, when you want use the eac3to demux you must use the demux in Global Parameters.

... Probably, I will always use the 3-letter
code included in square brackets, e.g., '[eng]'.[/B]", is this something that you could update in UsEac3to or is it a permanent limitation that you can't get around?

If that info is included in the log I can modify UsEac3to, waiting for the update. BTW you can use the strict eac3to demux using Global Parameters inside UsEac3To.

[oniiz86]

Originally Posted by Columbo

"My UsEac3to GUI put only the first 3 characters to identify the track and can't convert it to the exact language codes."

When eac3to is revised to use the [eng] format then UsEac3to can presumably pick that up and use it.

@Columbo Unfortunately that doesn't appear to be the case, only if one uses the -demux option then it will be okay, the eac3to developer has mentioned the following "UsEac3to must be revised to make proper filenames when specifying tracks. If it simply uses -demux then things will be fine when using the revised eac3to."

Originally Posted by tebasuna51

If that info is included in the log I can modify UsEac3to, waiting for the update. BTW you can use the strict eac3to demux using Global Parameters inside UsEac3To.

@tebasuna51 Thanks for that info Teba, it's very much appreciated, yes I was advised that -demux will be fine but I prefer to use the Track Input and Output Format functionality.

[Columbo]

Originally Posted by oniiz86

@Columbo Unfortunately that doesn't appear to be the case

Sure it does. As I mentioned and teba apparently confirms he can pick it up from the eac3to log file and it works even if you are not demuxing anything at all.

Anyway, Curly just made a test version for y'all:

https://rationalqm.us/misc/eac3to_oniiz86.exe

Note that mkvtoolnix requires the square brackets so don't strip them off.

[oniiz86]

Originally Posted by Columbo

Sure it does. As I mentioned and teba apparently confirms he can pick it up from the eac3to log file and it works even if you are not demuxing anything at all.

Anyway, Curly just made a test version for y'all:

https://rationalqm.us/misc/eac3to_oniiz86.exe

Note that mkvtoolnix requires the square brackets so don't strip them off.

I've just tested this, I can confirm that everything is now fine when using the Global Parameter -demux option but not when using the Track Input and Output Format function, I have a Spanish PGS subtitle track that when demuxed individually the output filename is with "eng.sup" not "spa.sup" as it had been with the eac3to release versions.

[Columbo]

Originally Posted by oniiz86

I've just tested this, I can confirm that everything is now fine when using the Global Parameter -demux option but not when using the Track Input and Output Format function

Yes, UsEac3to must be modified for using the eac3to test build.

I have a Spanish PGS subtitle track that when demuxed individually the output filename is with "eng.sup" not "spa.sup" as it had been with the eac3to release versions.

Using the revised eac3to with the not-yet-revised UsEac3to will give erroneous or undefined results.

[tebasuna51]

With the new version eac3to show for instance:

MKV, 1 video track, 5 audio tracks, 0:00:21, 25p
1: h264/AVC, [eng], 720p25
2: AAC, [spa], 5.1 channels, 48kHz, dialnorm: 0dB
3: AC3, [jpn], 5.1 channels, 448kbps, 48kHz, dialnorm: -31dB
4: E-AC3, [fre], 5.1 channels, 448kbps, 48kHz, dialnorm: -31dB
5: FLAC, [ger], 5.1 channels, 0:00:20, 16 bits, 48kHz, dialnorm: 0dB
6: OPUS, [por], 5.1 channels, 48kHz, dialnorm: 0dB

And the new UsEac3to extract can be:

3: %_3-jpn.ac3

The - and the . are default boundary characters and can be recognized by MkvToolNix (but still you need configure it to accept 'japonese' like Recognized Languages, by default only eng, fre, ger,ita,por and spa)

EDIT: UsEac3to final v1.3.5 in first post

[tebasuna51]

Originally Posted by Columbo

Using the revised eac3to with the not-yet-revised UsEac3to will give erroneous or undefined results.

Use 'eng' by default because the character [ is not accepted.