EAC3TO Requests and General Discussion

[Boulder]

OK, well is there any issue processing it with eac3to?

He he, you can send him an email thru the board now (if he has it enabled). admin

Hmm.. if we are thinking eac3to only, it does work as specified, outputting the same config it sees.
I decoded the file into separate wavs and it might be true that it should be 3/1. The back center channel is active only occasionally and the front three all the time.

If I may nitpick about something, it's that the remap option requires to input at least six integers even if there are only these four channels in the stream

[Curly]

The remap function huh? Now that I know we have one I'll take a butcher's at it.

What do you enter for the last two?

[Boulder]

The remap function huh? Now that I know we have one I'll take a butcher's at it.

What do you enter for the last two?

TBH, I'm not sure I think you just have to put 4,5,6,7. I just noticed another problem with the feature - you cannot use it to copy a channel because you can use a channel only once. IIRC that copy trick had to be done at least with that Edward Scissorhands track, you had to duplicate a channel to create a 5.0 audio track to avoid any issues.

[Thunderbolt]

does dialnorm removal for DTSHDMA still work with the latest non-mod build by madshi?

[Curly]

???

Obviously I only make mod builds so if any non-mod madshi build used to work it still does. The last available non-mod madshi build is 3.36.

Can you try to clarify your question? I don't know if that feature worked in 3.36. I guess not because I inherited a bug report about it. Why not test it in 3.36 and see if it works? I haven't done anything in the mod builds that would have broken it.

[skull]

@Thunderbolt, this is not the right place for questions about older madshi versions, see the doom9 thread or just try to test yourself. Please don't post again if it's about v3.36 or earlier, unless it's related to a feature or bug in latest build somehow. Cheers!

[Curly]

I'll test it in 3.47 and see what the deal is. If it's broken then I'll fix it.

[oniiz86]

@Curly I believe @Thunderbolt is referring to the DTS-HD MA/HRA DialNorm that is not removed for these codec variants, not sure why he mentioned "still works" as according to my knowledge it has never worked in previous Madshi builds, I've verified that it still is the case with the latest 3.47 release, it is the bug I brought to your attention when you took over eac3to development, it would be great if you could tackle it & the E-AC3 7.1 decoding bug for the 3.48 release

[Curly]

Yes, thank you, that's what I thought too, but I wanted to give him a chance to clarify it.

[Curly]

Page 180

https://www.etsi.org/deliver/etsi_ts/10 ... 10301p.pdf

[DelBoy83]

Hi Curly, I usually always opt for the -demux option as its quicker than typing everything out, the only thing is that raw PCM tracks only come out as raw PCM. Would you be able to add an option for all raw PCM tracks to come out as W.64 tracks via -demux this would be very helpful for myself and hopefully others.

[Curly]

You have an existing request to convert to FLAC. Which one do you want, W64 or FLAC?

[DelBoy83]

You have an existing request to convert to FLAC. Which one do you want, W64 or FLAC?

I'd like FLAC please Curly. Thankyou

[von Suppé]

Lectori Salutem,

When importing an elementary AVC or HEVC stream that has been demuxed from mkv with mkvextract.exe (from MKVToolNix package) in eac3to's frontend UsEac3To, the info-windows throws this message: "The format of the source file could not be detected. <ERROR>".

Whereas when mkv is demuxed by eac3to itself, the elementary video-streams are perfectly accepted on import; no error. This has been since way back and I've always wondered why. I did a few quick & dirty tests with both AVC and HEVC on latest eac3to 3.47 and still the same behaviour.

Would there be something "wrong" with either mkvextract.exe's output, or (Us)eac3to's source-parsing? Hope you don't mind me asking because I can imagine this being a UsEac3to related issue.

[skull]

Please provide the command line that the front-end is using and try it directly with eac3to.exe and report back.

[Curly]

Good advice. Also tell us the filename of the extracted stream and give us a link to a small sample of it (the AVC/HEVC not the MKV). You can cut 50MB of it with DGSplit.

Probably your stream does not contain AUDs. Refer to the to-do list where this is discussed. If that is the case you can mux it to MKV and open that. This is not a problem with the file or mkvtoolnix or UsEac3to, just a long-standing eac3to deficiency that is queued for fixing.

*eac3to can open an MKV containing an h264 stream without AUDs
(it creates and injects AUDs on the fly), but it does not do this for MP4 containers or elementary streams.

* H264 parsing needs to be generalized for pic_order_cnt_type != 0. Currently 0 is assumed.
Also, support streams without AUDs.

[SomeHumanPerson]

You have an existing request to convert to FLAC. Which one do you want, W64 or FLAC?

I'd like FLAC please Curly. Thankyou

Sorry to be contentious, but I think this is a bad idea. -demux should output the untouched stream. At most, for LPCM, it should be wrapped to RF64 WAV (.wav or .w64). It should absolutely not be re-encoded, even losslessly.

If someone wants the track in FLAC, they should either extract separately and specify the conversion (i.e. choose the track and give it a .flac output filename), or post-convert the uncompressed track delivered by -demux.

[skull]

I agree, but I have a suspicion the request was to allow an option/switch, maybe in the .ini, to convert to .flac when using -demux by default for RAW PCM tracks? I could be misreading, but I doubt Curly would force FLAC as only option for -demux when encountering these audio streams. I am also curious how common these audio tracks are in the wild, they seem rare on Blu-rays these days, but up to Curly if he wants to fulfill the request obviously.

[Curly]

Yes, skull, that is correct. I agree with SomeHumanPerson so I've modified the to-do list item to say always wrap in W64 and if possible add an option to do FLAC instead. The first part is easy but the option and associated processing is difficult so may not happen.

[Curly]

To read one thread with all the bugs and feature requests is a bit cumbersome.
Could we have for each issue and feature request it's own thread like the other DG-tools?

We did implement this for the bugs/problems but I forgot to cite hubblec4 for the suggestion. Worse never than late, that's the saying, right?

[von Suppé]

Please provide the command line that the front-end is using and try it directly with eac3to.exe and report back.

Good advice. Also tell us the filename of the extracted stream and give us a link to a small sample of it (the AVC/HEVC not the MKV). You can cut 50MB of it with DGSplit.

Filename of the problematic mkvextract demuxed stream is mkvextract_demux.h264. Stream comes from a 10 seconds mkv testfile

The frontend directly errors after input, leaving no chance to set other params. It's log directy after input:

eac3to v3.47
command line: "L:\Software\UsEac3to133_eac3to347\eac3to.exe" "F:\UsEac3to_with_eac3to347\mkvextract_demux.h264" -progressnumbers -log="L:\Software\UsEac3to133_eac3to347\UsEac3To.log"
------------------------------------------------------------------------------
Running in fast mode
Keeping dialnorm
The format of the source file could not be detected. <ERROR>

= = = =

Entering some process params in direct commandline to eac3to.exe, it's logs:

eac3to v3.47
command line: eac3to.exe mkvextract_demux.h264 24fps_out.h264 -23.976 -changeTo24.000 -progressnumbers -log=Eac3To.log
------------------------------------------------------------------------------
Running in fast mode
Keeping dialnorm
The format of the source file could not be detected. <ERROR>

= = = =

Both GUI and direct eac3to cli work on eac3to-demuxed streams. I reckon you don't need this stream. Link to the problematic mkvextract_demux.h264:

https://mega.nz/file/D9BgGJAQ#8TVNLSA3M ... vnz1yqApoA

In case I've forgotten/misunderstood something, please advice.

[Curly]

My theory was correct. The demuxed stream has no AUDs, which eac3to cannot accept (yet). When eac3to demuxes the MKV, it inserts AUDs on the fly and that's why the eac3to-demuxed stream works with eac3to. When mkvtoolnix demuxes the MKV, it does not insert AUDs, so the demuxed stream cannot be used with eac3to (yet). The inability to accept streams without AUDs is already on the to-do list.

[DelBoy83]

I've just realised that when using -demux using eac3to command line PCM is extracted as a W.64 file. However when using UsEac3to gui PCM is extracted as raw PCM, when using -demux.

[hubblec4]

To read one thread with all the bugs and feature requests is a bit cumbersome.
Could we have for each issue and feature request it's own thread like the other DG-tools?

We did implement this for the bugs/problems but I forgot to cite hubblec4 for the suggestion. Worse never than late, that's the saying, right?

Now it looks like professional, thanks Curly for all your work.

[skull]

I've just realised that when using -demux using eac3to command line PCM is extracted as a W.64 file. However when using UsEac3to gui PCM is extracted as raw PCM, when using -demux.

Pay attention closely and you'll notice that UsEac3To does not actually use -demux when you click the RUN button next to "demux" under Global Parameters section. It uses a wildcard and therefore does no processing on the audio tracks. Here is what it uses below, but you can still manually put -demux in the box for CL parameters to use it instead.

Code: Select all

command line: "C:\EAC3TO\eac3to.exe"  "T:\test.mkv" "G:\\test.mkv_.*" -progressnumbers -log="C:\EAC3TO\UsEac3To.log"

P.S. Fun fact, latest eac3to v3.47 version has officially made its way into Staxrip! We should be reaching a wider userbase now, as a result. Kudos to Curly and everyone else who has helped with development, testing, and feedback!