[LOCKED] EAC3TO Bug Reports and Feature Requests Only

[Guest 3]

My comments are always about audio, I let the video management to other users with more knowledge.

The dll's present in the eac3to package are:

Code: Select all

 Decoders
10/03/2015 avcodec-54.dll | libav (ffmpeg) decoders
10/03/2015 avutil-52.dll  | MPX, AC3, EAC3(*), ...
04/01/2016 libdcadec.dll  DTS(HD) obsolete
05/09/2008 hdcd.dll       HDCD source track

 Manage decoded audio
07/12/2008 libMatrix.dll  |
30/11/2008 libSsrc.dll    | resample, dither, etc.
14/08/2005 r8b.dll        | ok for now

 Encoders
10/02/2008 HookSurcode.dll  To commercial Surcode DTS (obsolete)
20/11/2008 libaften.dll     AC3 encoder (obsolete)
16/09/2007 libFLAC.dll      Decode/encode (can be actualized)
18/02/2010 (neroAacEnc.exe) AAC free encoder optional

About encoders: HookSurcode and libaften can be deleted, we can use the 'pipe' to encode to standard DTS or AC3 and many other formats with ffmpeg.
Of course can be more elegant use libav dll's to encode to all formats supported by ffmpeg but have lower priority for me.

How eac3to manage the decoded audio is ok for me also, of course can be improved/updated but also with lower priority.

The first problem for me are the decoders:
ffmpeg (libav) can decode DTS, DTS-HD and also DTS-Express (not supported by libdcadec.dll than can be deleted), can decode AAC (for what we need Nero 7 to decode it?), can decode EAC3 7.1 not only 5.1, etc.

The Core Universe.m2ts is a free demo sample than can be download to test the problem to decode EAC3 7.1, can be extracted with 3.37 but only the core AC3 5.1 is decoded. To understand a bit more about EAC3 frames you can see this post.

[SomeHumanPerson]

SomeHumanPerson, can you be more specific? What do you mean by deprecate? Remove stuff? What stuff do you want removed? And why? Does their presence cause any problems?

I think that the answer above from Guest 3 a.k.a. tebasuna51 is a good explanation. It seems like libav/ffmpeg can do (almost?) everything now, so most/all of those other DLLs/hooks could be eliminated.

I'd also be interested to know if the libav/ffmpeg used by eac3to_mod can ever be updated to current. There's a bolded note in the Doom9 post to the contrary, but I don't know how old that note is, or what the reason was. Maybe Guest 3 can shed some more light on that.

[Guest 3]

In '...eac3to\legal stuff\ffmpeg\compiling' there are info about how create the eac3to dll's but I don't know how can use them because I don't know the eac3to source files.

[Thunderbolt]

SomeHumanPerson, can you be more specific? What do you mean by deprecate? Remove stuff? What stuff do you want removed? And why? Does their presence cause any problems?

I think that the answer above from Guest 3 a.k.a. tebasuna51 is a good explanation. It seems like libav/ffmpeg can do (almost?) everything now, so most/all of those other DLLs/hooks could be eliminated.

I'd also be interested to know if the libav/ffmpeg used by eac3to_mod can ever be updated to current. There's a bolded note in the Doom9 post to the contrary, but I don't know how old that note is, or what the reason was. Maybe Guest 3 can shed some more light on that.

it is e.g. possible to update FLAC version manually, but you'd have to find the right file (libflac.dll x32 or x64, dynamic or not) and also rename it afterwards which is a bit clumsy with trial and error to find out for the average user.

[Thunderbolt]

feature request when the time has come: being able to change the framerate of HEVC .mkv remuxes like it is already possible to do with BDs.

e.g. "eacto 1) 2: video.mkv -changeto24.000" / -changeto23.976 / -changeto25.000

thank you.

[SomeHumanPerson]

feature request when the time has come: being able to change the framerate of HEVC .mkv remuxes like it is already possible to do with BDs.

e.g. "eacto 1) 2: video.mkv -changeto24.000" / -changeto23.976 / -changeto25.000

thank you.

Changing HEVC frame rate seems to be pretty simple based on how it works in ffmpeg, BUT I've seen at least one person claim that if Dolby Vision is involved, you need to separate out the enhancement layer, convert both streams individually, and then re-combine them. I don't know enough to judge the validity of that claim, but it's worth paying attention to if/when someone has an opportunity to work on this feature.

[Guest 2]

Thanks for your efforts!

Please allow us to use generic ffmpeg shared libraries: those included are outrageously old and specifically compiled, not allowing them to be replaced.

Plus, consider a x64 build.

[Curly]

Thank you folks for your great suggestions and requests. I'll update the other thread today.

Meanwhile, here is build 3.38. eac3to is a very large and complex project, so I'm just slowly getting oriented and dipping my toes in the water. I made my first code change. Hooyah! With 3.38 all video tracks are now demuxed when you give the -demux option. Previously, only the first one and (if present) a second one that is the second stream of MVC was demuxed. So now you will get your DolbyVision track demuxed without having to do it manually. OK, not earth shaking, but it's a start for little Curl.

https://rationalqm.us/misc/eac3to_mod_3.38.rar

[Sherman]

Ha ha, you implemented a feature by deleting two lines of code. You're gonna be in big trouble when you have to add code.

[Curly]

your just jealous
no code bloat over here

[DG]

Great work, Director Howard.

I see you put the project under version control. Bravo.

Not seeing any repositories for the linux stuff. What's up with that, Sherman?

[Sherman]

Oopsie.

I'll take care of it, boss.

[Curly]

knerk knerk pie in the eye

[Curly]

Folks, how do y'all feel about making -keepDialnorm the default, i.e., reverse its current sense?

Some discussion here:

https://forum.doom9.org/showthread.php?t=158044
https://forum.doom9.org/showthread.php? ... post332259

My idea is that when we keep DN we can omit the very expensive CRC calculations that are only needed when the DN data must be changed to remove it. That would require a code change to omit the CRC checks when keeping DN as that is currently not the case.

Note that DGDemux keeps DN and has no option to remove it. We have not received even one complaint about this. I'm looking for solid theoretical or use-case arguments and not your "conventional wisdom".

Here's another factoid. Remove DN does not in fact remove it per se. It simply rewrites it to -31dB. So maybe we should allow an option that sets this value to a requested value, instead of simply re-writing it to -31 dB unconditionally.

[DelBoy83]

Folks, how do y'all feel about making -keepDialnorm the default, i.e., reverse its current sense?

Some discussion here:

https://forum.doom9.org/showthread.php?t=158044
https://forum.doom9.org/showthread.php? ... post332259

My idea is that when we keep DN we can omit the very expensive CRC calculations that are only needed when the DN data must be changed to remove it. That would require a code change to omit the CRC checks when keeping DN as that is currently not the case.

Note that DGDemux keeps DN and has no option to remove it. We have not received even one complaint about this.

I'd be 100% in favour of making -keepdialnorm the default. I don't really understand why dialnorm was automatically moved in the first place, when it didn't need to be. Also just want to say thankyou for all the hard work behind the scenes and also a massive thankyou to madshi for allowing eac3to to move forward and improve. Eac3to is definitely in safe hands.

[SomeHumanPerson]

Folks, how do y'all feel about making -keepDialnorm the default, i.e., reverse its current sense?

...

Note that DGDemux keeps DN and has no option to remove it. We have not received even one complaint about this. I'm looking for solid theoretical or use-case arguments and not your "conventional wisdom".

I am in favour of this. As you say, DGDemux leaves it alone too. Removing it by default has never seemed logical to me.

[Curly]

That's 2 in favor versus 0 against so far. I'd like to hear from Guest 3 on this also.

I did a test on a single AC3 demux from a UHD disk with and without dialnorm "removal":

without: 8 minutes 54 seconds
with: 13 minutes 58 seconds

Of course that is with my local change to omit unconditional CRC checks. That change also improves the 'with' case also. Here's why:

Previously:

without: calls CRC checks just to verify the audio frame
with: calls CRC checks just to verify the audio frame AND calls again after "removing".

After:

without: [nothing]
with: calls after "removing".

So the calls to verify the audio frame were removed, helping both cases. The "removal" here is responsible for about 5 extra minutes (55%). That is not chump change!

Another factoid: On disks I have looked at -27 dB is the assigned DN level. "Removing" it changes it to -31 dB. That is a difference of 4dB. Did you know that a 3dB difference is considered just barely perceptible? So I'm really doubting the value of "removal" here.

[trojiteEL]

feature request when the time has come: being able to change the framerate of HEVC .mkv remuxes like it is already possible to do with BDs.

e.g. "eacto 1) 2: video.mkv -changeto24.000" / -changeto23.976 / -changeto25.000

thank you.

Changing HEVC frame rate seems to be pretty simple based on how it works in ffmpeg, BUT I've seen at least one person claim that if Dolby Vision is involved, you need to separate out the enhancement layer, convert both streams individually, and then re-combine them. I don't know enough to judge the validity of that claim, but it's worth paying attention to if/when someone has an opportunity to work on this feature.

I can 100% confirm that for DoVi HEVC, both BL.hevc and EL.hevc need to have framerate changed separately and then combine to final framerate-changed HEVC file.

I tested "-changeTo..." of eac3to version 3.34 for some UHD blu-rays and WEB-DL HEVC files and to me it seems eac3to is doing framerate change correctly. Of course somebody else could test it and confirm it too.

Either way, this is how it should be done using dovi_tool and ffmpeg:

Code: Select all

dovi_tool demux --input "input.hevc"

ffmpeg -i "BL.hevc" -c copy -bsf:v hevc_metadata=tick_rate=(24000/1001):num_ticks_poc_diff_one=1 "BL_ffmpeg_fixed.hevc"

ffmpeg -i "EL.hevc" -c copy -bsf:v hevc_metadata=tick_rate=(24000/1001):num_ticks_poc_diff_one=1 "EL_ffmpeg_fixed.hevc"

dovi_tool mux --bl "BL_ffmpeg_fixed.hevc" --el "EL_ffmpeg_fixed.hevc"

Huge thanks for continuing with eac3to development btw!

[Curly]

Thank you trojiteEL, and welcome to the forum.

Folks, you know I'm an eac3to noob. So I wanna ask from someone that knows:

1. When does a '2nd pass' get executed?
2. What all happens during a '2nd pass'? Both audio and video stuff?
3. What is good about a '2nd pass'?
4. What issues are possible when doing a '2nd pass', such
that an undocumented option -no2ndpass must be present?
5. Should the sense of -no2ndpass be reversed?

ta

[trojiteEL]

Thanks, Curly, for this warm welcome

@2nd pass: I remember this is executed for audio when for example it is not truly 24-bit, just masking as 24-bit.

Example:

Code: Select all

eac3to.exe C:\BD 1) 3:N:\audio.flac
M2TS, 1 video track, 2 audio tracks, 1 subtitle track, 2:28:46, 24p /1.001
1: Chapters, 12 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 5.1 channels, 24 bits, 48kHz
  (core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: DTS Master Audio, English, 2.0 channels, 24 bits, 48kHz
  (core: DTS, 2.0 channels, 1509kbps, 48kHz)
5: Subtitle (PGS), English
a03 Extracting audio track number 3...
a03 Decoding with libDcaDec DTS Decoder...
a03 Encoding FLAC with libFlac...
a03 Creating file "N:\audio.flac"...
a03 The original audio track has a constant bit depth of 16 bits.
a03 Superfluous zero bytes detected, will be stripped in 2nd pass.
a03 Starting 2nd pass...
a03 Decoding FLAC...
a03 Reducing depth from 24 to 16 bits...
a03 Encoding FLAC with libFlac...
a03 Creating file "N:\audio.flac"...
a03 The processed audio track has a constant bit depth of 16 bits.
Video track 2 contains 214020 frames.
eac3to processing took 7 minutes, 7 seconds.
Done.

I would have a future feature request - if it's possible ofc:

When you do eac3_mod "UHD_BD" 1)
- you get list of all streams like this:

Code: Select all

1: Chapters, 24 chapters
2: h265/HEVC, 2160p24 /1.001 (16:9), 10 bits
3: TrueHD/AC3 (Atmos), English, 7.1 channels, 48kHz, dialnorm: -27dB
   (embedded: AC3, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB)
4: AC3, English, 2.0 channels, 320kbps, 48kHz, dialnorm: -27dB
5: AC3, French, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
6: E-AC3, Spanish, 7.1 channels, 1024kbps, 48kHz, dialnorm: -27dB
   (core: AC3, 5.1 channels, 576kbps, 48kHz, dialnorm: -27dB)
7: E-AC3, Japanese, 7.1 channels, 1024kbps, 48kHz, dialnorm: -27dB
   (core: AC3, 5.1 channels, 576kbps, 48kHz, dialnorm: -27dB)
8: Subtitle (PGS), English
9: Subtitle (PGS), French
10: Subtitle (PGS), Spanish
11: Subtitle (PGS), Japanese
12: Subtitle (PGS), English
13: Subtitle (PGS), French
14: Subtitle (PGS), Spanish
15: Subtitle (PGS), Japanese

Would it be possible to have it like this?

Code: Select all

01: Chapters, 24 chapters
02: h265/HEVC, 2160p24 /1.001 (16:9), 10 bits
03: TrueHD/AC3 (Atmos), English, 7.1 channels, 48kHz, dialnorm: -27dB
   (embedded: AC3, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB)
04: AC3, English, 2.0 channels, 320kbps, 48kHz, dialnorm: -27dB
05: AC3, French, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
06: E-AC3, Spanish, 7.1 channels, 1024kbps, 48kHz, dialnorm: -27dB
   (core: AC3, 5.1 channels, 576kbps, 48kHz, dialnorm: -27dB)
07: E-AC3, Japanese, 7.1 channels, 1024kbps, 48kHz, dialnorm: -27dB
   (core: AC3, 5.1 channels, 576kbps, 48kHz, dialnorm: -27dB)
08: Subtitle (PGS), English
09: Subtitle (PGS), French
10: Subtitle (PGS), Spanish
11: Subtitle (PGS), Japanese
12: Subtitle (PGS), English
13: Subtitle (PGS), French
14: Subtitle (PGS), Spanish
15: Subtitle (PGS), Japanese

Reasoning:

When you do eac3to_mod "UHD_BD" 1) -demux

- the streams demux like this - not in correct or rather preffered order:

Code: Select all

00055 - 10 - Subtitle (PGS), Spanish, 1302 captions.sup
00055 - 11 - Subtitle (PGS), Japanese, 1256 captions.sup
00055 - 12 - Subtitle (PGS), English, 37 captions.sup
00055 - 13 - Subtitle (PGS), French, 67 captions.sup
00055 - 14 - Subtitle (PGS), Spanish, 56 captions.sup
00055 - 15 - Subtitle (PGS), Japanese, 88 captions.sup
00055 - 2 - h265, 2160p24.h265
00055 - 3 - TrueHD+AC3 (Atmos), English, 7.1 channels, 48kHz.thd+ac3
00055 - 4 - AC3, English, 2.0 channels, 320kbps, 48kHz.ac3
00055 - 5 - AC3, French, 5.1 channels, 640kbps, 48kHz.ac3
00055 - 6 - E-AC3, Spanish, 7.1 channels, 1024kbps, 48kHz.eac3
00055 - 7 - E-AC3, Japanese, 7.1 channels, 1024kbps, 48kHz.eac3
00055 - 8 - Subtitle (PGS), English, 1647 captions.sup
00055 - 9 - Subtitle (PGS), French, 1319 captions.sup
00055 - Chapters.txt
00055 - Log.txt

- this should be the correct or preffered order:

Code: Select all

00055 - 01 - Chapters.txt
00055 - 02 - h265, 2160p24.h265
00055 - 03 - TrueHD+AC3 (Atmos), English, 7.1 channels, 48kHz.thd+ac3
00055 - 04 - AC3, English, 2.0 channels, 320kbps, 48kHz.ac3
00055 - 05 - AC3, French, 5.1 channels, 640kbps, 48kHz.ac3
00055 - 06 - E-AC3, Spanish, 7.1 channels, 1024kbps, 48kHz.eac3
00055 - 07 - E-AC3, Japanese, 7.1 channels, 1024kbps, 48kHz.eac3
00055 - 08 - Subtitle (PGS), English, 1647 captions.sup
00055 - 09 - Subtitle (PGS), French, 1319 captions.sup
00055 - 10 - Subtitle (PGS), Spanish, 1302 captions.sup
00055 - 11 - Subtitle (PGS), Japanese, 1256 captions.sup
00055 - 12 - Subtitle (PGS), English, 37 captions.sup
00055 - 13 - Subtitle (PGS), French, 67 captions.sup
00055 - 14 - Subtitle (PGS), Spanish, 56 captions.sup
00055 - 15 - Subtitle (PGS), Japanese, 88 captions.sup
00055 - Log.txt

Thank your for your effort.

[manuelrn]

...

Personally I would not remove all those checks and verifications that eac3to does. It is not an oversight or poor programming code that adds slowness to the process, it is something that was implemented on purpose to make sure that the source does not contain errors.

eac3to is very much characterized by being very meticulous, checking everything and correcting possible errors (and so many other things related to this, such as the '2nd pass' that you also mentioned previously). Not to simply extract the bits as is, for that there are other alternative tools.

For example when you have made a dump of a BD/UHD disc and it has not been dumped 100% correct (there was some problem that made that in a very short fragment some bits were altered), or you have a MKV that contains a track that is not 100% clean and contain some error, or whatever.... if the user makes a demux/remux of that Full BD/UHD with any other program (MKVToolNix, MakeMKV, etc...) those programs will simply copy the bits from one file to another without processing or verifying almost anything and without reporting this kind of problems, so the user will not know if there is something wrong and will think that everything is correct...
However if there is any problem or corruption in the data, eac3to will almost certainly notice it and notify the user in the log, which will make the user easily realize that there is something wrong and try to find a solution for it (re-dump the disc again, or whatever).

In short, the purpose of eac3to has always been processing and checking and reliability of data handling, not speed.

Greetings and I am glad that eac3to is still in development with you

[Curly]

did u have a point
keep it at 5 year level ok
ten words or less

[Curly]

preferred order

for sure not random like now
duh
thank you

[Levi]

manuelrn my brother, thank you for your blessings. You say don't trade-off too much for performance. It makes sense. Welcome to the forum!

[Curly]

I'd be 100% in favour

That is not enough for me.