EAC3TO To-Do List

[Curly]

These are features and fixes requested for EAC3TO. This thread will be locked and maintained by yours truly. Post ideas for inclusion in the general discussion thread. These are in no particular order. Bugs take priority. More *s more importance. As issues are resolved and appear in a formal or test release they will be removed from this list and explanations posted in the main thread.

Bugs

*** Demuxing PGS subs from MKV files is not working (like with v3.36). Output files are generated, but they contain garbage. [FCrane]
* Demuxing generates two identical log files, e.g.: "log.txt" and "00003 - Log.txt".
* "eac3to disk" does not show subs, while "eac3to disk 1)" does show subs.
* Sometimes the duration shown for an MPLS is different depending on whether the eac3to
command is "eac3to disk" or "eac3to disk 2)". E.g., 00001.mpls in
the disk Drift.Partners.in.Crime.2023.S01D02.GERMAN.
* 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. [Curly]
** With removal turned on (by default or using -removeDialognorm), Dialog normalization does not get applied to DTSMA tracks. Probably due to eac3to not knowing how to update the CRC in DTS-HD
headers. [oniiz86]
* eac3to crashes on MKV files containing mono (1.0) PCM audio.

Features and Functionality

* Provide an option to not demux hidden streams.
* Improve performance generally where possible.
* Make "non-filtering" versions of the readers to be used when not doing
filtering operations (e.g., changing frame rate on the fly). This will allow use
of GetBits() instead of the very expensive CopyBits().
* Port to linux. Newer Delphi versions support compiling for Linux.
* 64-bit version.
* Implement latest FastMM as it is faster than the one included in Delphi 7.
* Upgrade all libraries, especially ffmpeg ones. It's not
completely easy to do because the ffmpeg API is not binary compatible,
so it will need code changes. For example, the
decoder channel order changes all the time. So we'd probably have to
double check every possible (supported) audio decoder channel format
to make sure they're all correct, after updating to a newer ffmpeg
build.

When updating ffmpeg, then it would be nice to also replace
libAften with ffmpeg's AC3 encoder. Unless libAften quality is still
fine, by today's standards? I don't know that for sure. Alternatively,
it could be an idea to replace the libAften.dll with a newly written
one that exposes the same APIs as the original libAften.dll, but
internally uses the latest ffmpeg build. This would allow for eac3to
to continue using the same libAften API calls. Not sure whether that
would be easier overall or not. [madshi]

* Remove/replace obsolete libraries and associated functionality. E.g., ArcSoft, Nero, Aften.
* Please create a setting where eac3to converts all PCM tracks to flac (unless raw PCM is explicitly asked for with out.pcm or out.*) or even have an option where you choose what audio gets converted automatically? [DelBoy83]
* Would it be in any way possible to unpack while extracting a PGS subtitle, which has been previously archived with zlib by MKVmerge during muxing? If it was archived during muxing, it's currently extracted archived and that makes it unreadable to subtitle editing apps. [BizkitBoy]
* Some movies have forced subtitles within the full subtitle stream, would it be possible to demux to its own subtitle track? [DelBoy83]
* H264 parsing needs to be generalized for pic_order_cnt_type != 0. Currently 0 is assumed.
Also, support streams without AUDs.
* AV1 video codec support.
* Still decodes 7.1 EAC3 streams as 5.1 ignoring the depending frames with the extra channels. Maybe fix with updated libav dll's (ffmpeg can't create 7.1 eac3 but decode it fine).
* eac3to currently does not provide you the amount of delay that was not able to be fixed when using the -edit command, as opposed to its behaviour when using just a simple delay. Showing the unfixed delay when using -edit could really help out in some specific cases and also makes the behaviour more consistent.

Development and Environment

* Port to latest Delphi 11. Mainly unicode stuff.
* One day go open source with a very permissive license.
* Replace madCodeHook if possible. Won't be needed until going open source.
Possibly https://github.com/MahdiSafsafi/DDetours.
API hooking is not used *a lot*, just a bit, so it's not even
very critical, maybe it could even simply be dropped completely. But
for example, hooking ffmpeg allows to hide/block some ffmpeg command
line output, making the eac3to command line experience much
cleaner/nicer.
* Transition to DG-style support in the website and release notifications.
* Refactor the main DPR file.

Will Not Be Addressed

* -r8brain causes eac3to to crash in some cases. I'm unable to generate any file with a size larger than 985661440 bytes. I've tried decoding 2 different streams: the first is 7.1 DTS-X, the second is 5.1 AC3. I tried both wav and flac. My options are: "-downStereo -mixlfe -down16 -resampleTo44100 -r8brain -normalize". It works fine without -r8brain. With -r8brain, progress stops, cpu load drops to zero, and nothing happens. Analysis: this is an r8b.dll issue that we cannot fix. r8brain support was disabled.
* Demuxing of base and dependent streams should be possible for MakeMKV backups.
It works fine for AnyDVD backups. Reason: MakeMKV does not create real SSIF files that are used by eac3to(_mod).
You can rip with AnyDVD or demux with DGDemux. It is also possible to create an SSIF file from the SSIF.MAP file using a special utility.
[Frankaboy]
* Fix issues with MKV muxing. Adding support for muxing with ffmpeg to MKV?
Currently, eac3to is still using the very outdated Haali MKV DirectShow filters to mux to
MKV, which is awful. Switching to ffmpeg would also allow muxing audio
files in, which eac3to currently can't do. Alternatively, instead of
using ffmpeg, other options could be to use libmatroska or maybe to use
mkvmerge.exe. For the latter option we would demux separate files and then
use mkvmerge.exe. Possibly that would be the easiest
way that requires the least amount of development time and code. Reason: It's not worth the time and effort when the user can simply demux and then use mkvtoolnix.