EAC3TO Requests and General Discussion

[new_guy]

[Baltasar]

You need a wine and a woman with maturity, full-bodied.

[Wonder Woman]

Pay me a visit, handsome.

[DelBoy83]

Could anyone tell me how to save the demuxed files to a specific destination please? ATM all files are demuxed to my c: drive and i'd rather them saved to the source location.

Simple workaround you can use posted here. Cheers!

Thankyou Skull. Your advice will come in very handy.

[Curly]

I hope you noticed this too:

https://www.rationalqm.us/board/viewtop ... 610#p18610

[DelBoy83]

I hope you noticed this too:

https://www.rationalqm.us/board/viewtop ... 610#p18610

Sorry I didn't notice this, thankyou for so much for the help Curly, it's much appreciated.

[SomeHumanPerson]

Looking at the bugs & features thread, I saw discussion about playlists. How exactly did the original eac3to determine which playlists to display/prioritize? Was it also based strictly on duration? Or is there some element of the Blu-ray structure that can be referenced for a list of the meaningful playlists (i.e. main movie, special features, etc. vs. other garbage)? It always seemed surprisingly "intelligent" about the playlists displayed, but maybe I'm remembering poorly.


Second question: does the new function of the .INI file (options to append to command line) still work in the previous way, where .INI options can be overridden on a case-by-case basis by specifying the option on your own command line?

[Curly]

Second question: yeah you're right so I have reverted back to the previous way. Thanks for pointing it out.

As far as I know, eac3to would make a list by descending duration with a time cutoff and within that a higher resolution playlist would come above a lower one. Then from that list the 'weird' playlists were purged as DGDemux used to do.

We want to retain the weird ones as explained elsewhere.

[SomeHumanPerson]

Thanks for the playlist explanation, Curly, and for the .INI reversion.

[Curly]

OK, guys it's time to talk about MKV output support. Do we really need it? The simplest thing to do would be to automatically invoke mkvmerge. But is that really such a great thing, given you can invoke mkvmerge manually after demuxing? So, is the added complexity worth it? And bear in mind eac3to can't currently mux audio in, so all that would have to be developed. And even more...with makemkv we already have a great disk->mkv method. Over to y'all.

[SomeHumanPerson]

I'm in favour of not bothering with MKV muxing at all because fully developing the feature (i.e. supporting all potentially useful mkvmerge options) will be a massive undertaking and that seems redundant to me. I just use mkvmerge directly or via the GUI for muxing.

I suspect come users will have convenience use-cases where direct muxing to MKV would save some time (taking screenshots with AvsPmod comes to mind), but unless there's a good technical reason for doing so... it's just a ton of extra complexity and potential for bugs.

[Curly]

Amen, bro.

[skull]

Amen, bro.

I think that's a fair argument especially with makemkv being a great option, but in that case, I just think the syntax examples in internal docs and any mention of outputting to .mkv should be removed entirely, just to make it clean, as it uses the very old Haali splitter anyway for the few instances where it can do anything to .mkv, and it's not that useful anyway. Just my 2 cents.

[jpsdr]

I also think it's not worth spend extra work on mkv, as there is already mkvmerge.

[Guest 2]

I'm in favour of not bothering with MKV muxing at all because

I can see mkv just as a good container for a whole BD title rip (though there is makemkv too).

For other means I deeply suggest to use https://sourceforge.net/projects/gmkvextractgui

[Curly]

Nothing will be removed but MKV muxing will be deprecated and not advertised
on the splash screen. The muxing support will not be touched. The MKV input
stuff will be maintained and bugs fixed as needed.

[skull]

Nothing will be removed but MKV muxing will be deprecated and not advertised
on the splash screen. The muxing support will not be touched. The MKV input
stuff will be maintained and bugs fixed as needed.

Sounds fair and less confusing this way. Btw, good news, videohelp does seem to have updated eac3to page with a version from Nov 3rd for eac3to_mod, but it's outdated and slight typo in the version #s for notes (mentions 3.37 but should be 3.39 throughout). Not sure who sent that in or they just did it on their own, but if you know whom to contact, maybe send v3.40 release candidate update so they can update the page with latest: https://www.videohelp.com/software/eac3to

[Curly]

I don't know who to contact. Do you want to try? I think the current 3.40 is good to go. Of course lots of work still to do but it is a good working replacement for 3.36.

[skull]

I don't know who to contact. Do you want to try? I think the current 3.40 is good to go. Of course lots of work still to do but it is a good working replacement for 3.36.

I was sure someone on this forum reached out but they must update themselves if they can find newer versions or something. I'll contact them and reach out to update to v3.40 after the libFLAC.dll update confirmed?

[Curly]

Sounds good, thank you, skull.

[Curly]

Had a user ask me in PM what is the rationale for our build numbers/slipstreaming etc. Here is how I answered:

This is what Rocky told me. We have so many products with so many different version control/release/documentation setups that it is a nightmare to manage build numbers. Believe me we have our hands full just managing the code for bug fixes/feature requests. And with the progress bar of life ticking away we like to preserve as much of our available time as possible for that. So we treat the file modified date as a sort of build number. The actual version number is incremented only for significant functional changes. You've learned to work that way so it is apparently working.

[skull]

Had a user ask me in PM what is the rationale for our build numbers/slipstreaming etc. Here is how I answered:

This is what Rocky told me. We have so many products with so many different version control/release/documentation setups that it is a nightmare to manage build numbers. Believe me we have our hands full just managing the code for bug fixes/feature requests. And with the progress bar of life ticking away we like to preserve as much of our available time as possible for that. So we treat the file date as a sort of build number. The actual version number is incremented only for significant functional changes. You've learned to work that way so it is apparently working.

That is a fair and understandable compromise, unless you guys one day decide to switch to a github-like workflow for managing code changes, this is fine. I would suggest perhaps leaving a version behind once it's "officially" made available, like on videohelp or official download link @ https://www.rationalqm.us/mine.html, so instead of slipstreaming one more fix back into that version, just push it forward into the next beta/future build. Just my thoughts on it. I'll send current v3.40 to videohelp though, now that it is stable and out.

Btw, Curly, I noticed the changelog.txt file is not updated to include all the fixes/improvements since v3.36 to v3.40? Any chance you'd be able to update/include that in future or advise what I should tell videohelp to use for changelog? They currently used for v3.39 release the original v3.37 post details from Rocky, which is quite outdated obviously, even for v3.39. Just a thought, as it's most commonly expected by end users if that file is present and could clear up and avoid repeated questions about what is new/changed and increase confidence and uptake by the general community if they see how much work/improvements you've actually made!

[Rocky]

Btw, Curly, I noticed the changelog.txt file is not updated to include all the fixes/improvements since v3.36 to v3.40? Any chance you'd be able to update/include that in future or advise what I should tell videohelp to use for changelog?

Documentation is always a bug-a-bear. We're still stuck on bringing DGDecNV docs up to date. Nevertheless, your request is not as challenging. I'll see if Sherman is busy. But you know Sherm, he's always busy. One way or another we'll get 'er done. May be a day or two. I'll probably do it so Curly can focus on code.

Backward slipstreaming allows us to get fixes into user hands faster.

[skull]

Btw, Curly, I noticed the changelog.txt file is not updated to include all the fixes/improvements since v3.36 to v3.40? Any chance you'd be able to update/include that in future or advise what I should tell videohelp to use for changelog?

Documentation is always a bug-a-bear. We're still stuck on bringing DGDecNV docs up to date. Nevertheless, your request is not as challenging. I'll see if Sherman is busy. But you know Sherm, he's always busy. One way or another we'll get 'er done. May be a day or two.

Thanks Rocky (and Sherman), I told videohelp folks in my message, we will do our best to work on that, but for the time being they can refer to the included eac3to_mod notes.txt for general notes/changes. If we have an updated changelog.txt this week, I can pass it onto them, and obviously it can be updated in the official download .rar. Cheers!

Oh, and I totally understand retroactively slipstreaming, it just has the potential to split the userbase, as some folks will not know about those additional fixes and/or the version on videohelp or some other mirror will be out of date, but I'm sure you guys realize that possibility.

P.S. Looks like videohelp is pretty quick with response time, and v3.40 is now up, so hopefully will become more widespread in the community. I have seen many folks sticking to 3.34 over the past few months, so I'll share the news, if I start to see adoption of v3.40 and logs popping up around the interwebz.

[Curly]

Fantastic, skull. Thank you so much.

Ambassador skull has a nice ring to it.