[LOCKED] EAC3TO Bug Reports and Feature Requests Only

[BizkitBoy]

I wonder if the bitstream parsing issue is also preventing eac3to from converting eac3 to simple ac3 directly.
You first have to demux the audio track to .ec3 extension and then it works converting the new file to ac3.
But not when it's included in a container, be it M2TS, MKV or anything else.

[Guest 3]

I believe eac3to has an issue with DTS-HD MA 7.1 streams that have a DTS ES 6.1 Matrix extension "DTS ES XLL", it is incorrectly flagged as DTS ES "5.1" when it should be "6.1"

I don't think so.
Only must be flagged 6.1 when there are 6.1 discrete channels (DTS-ES, 6.1 channels), the DTS ES Matrix have only 5.1 discrete channels and the Back Center channel is analog matrixed in surround channels, with DTS ES 5.1 is plenty identified.

If you decode the core DTS ES 5.1 you obtain only 5.1 channels.

4: EAC3, French, 7.1 channels, 48kHz, dialnorm: -0dB "DDP 7.1"...

Yes, must be:
4: EAC3, French, 7.1 channels, 48kHz, dialnorm: -27dB "DDP 7.1"

[Guest 3]

What is the Dialog Normalization (DN):

Is a constant value set in all frames (metadata values: Bit Stream Information, BSI) of a E/AC3 stream.
And try to normalize the audio volume to obtain the same volume to all Dolby streams.
Can't be deleted but can be set to -31 dB than means do not attenuate the audio volume.
A value of -27 dB (most frequent) means attenuate all the audio by -4 dB.
See GUIDE: How To Properly Encode Dolby Digital Audio.

The idea is good: you don't need change the volume button between movies, but only if all audio streams, not only Dolby, do the same.
If you listen CD music (see Loudness War), or TV commercials, or other movies without Dolby streams (for what DTS are preferred over AC3 in DVD's?) you need change the volume button of your audio system.

If you want edit, or recode, or know the original sound used to encode it, the DN can't be applied.
For that I was recommend to madshi remove the DN by default, because eac3to was created to decode eac3 streams (from EVO containers) to other audio supported by standard players at that time.
Maybe for only extract the default can be don't touch the DN, but to decode/recode the default must be always cancel the DN attenuation to recover the original audio.

With the free ffmpeg E/AC3 encoder the default is DN -31 dB but you can set any value.


What is the Dynamic Range Compression (DRC):

It is a value of the recommended gain (normally attenuation) for each encoded block (normally each .9 ms, calculated by the encoder) present in the metadata of Dolby streams.
The idea is compress the volume in a range with good dialog volume but without high volumen of explosions etc.
It was a good aid for old hardware/sofware players but with new smart players it is not needed at all, they have functions (like Night mode) to do the job on the fly over all audio streams, not only Dolby.

Of course to obtain the original audio must be decoded/recoded without apply the DRC (in ffmpeg with -drc_scale 0).
With the free ffmpeg E/AC3 encoder we can't create DRC values (like others encoders) an let the compression, if needed, to players.

[oniiz86]

I believe eac3to has an issue with DTS-HD MA 7.1 streams that have a DTS ES 6.1 Matrix extension "DTS ES XLL", it is incorrectly flagged as DTS ES "5.1" when it should be "6.1"

I don't think so.
Only must be flagged 6.1 when there are 6.1 discrete channels (DTS-ES, 6.1 channels), the DTS ES Matrix have only 5.1 discrete channels and the Back Center channel is analog matrixed in surround channels, with DTS ES 5.1 is plenty identified.

If you decode the core DTS ES 5.1 you obtain only 5.1 channels.

Thanks for that, then why does demuxing the core with tsMuxer, well it's including the sub-extension which is the DTS ES 6.1 Matrix extension, it reports it as DTS ES Matrix "7 channels"

Format : DTS
Format/Info : Digital Theater Systems
Format profile : ES Matrix / Core
File size : 1.21 GiB
Duration : 1 h 54 min
Overall bit rate mode : Constant
Overall bit rate : 1 509 kb/s

Audio
Format : DTS
Format/Info : Digital Theater Systems
Format profile : ES Matrix / Core
Duration : 1 h 54 min
Bit rate mode : Constant
Bit rate : 1 509 kb/s
Channel(s) : 7 channels / 6 channels
Channel positions : Front: L C R, Side: L R, Back: C, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 1.21 GiB

I thought it shouldn't matter whether it's discretely encoded or not, DTS ES is always defined as 6.1, MediaInfo is reporting it correctly as 7 channels (6.1) despite it being a Matrix encode, do you know why eac3to is reporting the DTS ES XLL audio stream as "strange setup"?

2: DTS Master Audio, English, 7.1 (strange setup) channels, 24 bits, 48kHz, dialnorm: -4dB
(core: DTS-ES, 5.1 channels, 1509kbps, 48kHz, dialnorm: -4dB)
"DTS-HD MA 7.1"

Do you know what "Bitstreaming parsing" failed means for the EAC3 (DD+) 7.1 tracks?

4: EAC3, French, 7.1 channels, 48kHz, dialnorm: -0dB
"DDP 7.1"
6: EAC3, German, 7.1 channels, 48kHz, dialnorm: -0dB
"DDP 7.1"
Bitstream parsing for tracks 4 and 6 failed. <WARNING>
Demuxing these tracks may still produce correct results - or not. <WARNING>

[Guest 3]

Thanks for that, then why does demuxing the core with tsMuxer, well it's including the sub-extension which is the DTS ES 6.1 Matrix extension, it reports it as DTS ES Matrix "7 channels"

Really I don't know. I never see a software decoder than obtain 7 channels from a DTS ES Matrix, only hardware 6.1 players extract the matrixed channel to Back Center. With 5.1 systems the Back Center is played like a phantom speaker (see the (Cs) in the image) with the common audio in surround channels (analog matrixed) without problems.

...do you know why eac3to is reporting the DTS ES XLL audio stream as "strange setup"?

DTS-MA can have many 7.1 speakers configuration like can see in the attached image.
eac3to can show as "strange setup" all instead the 'A', I see BD's with the 'G' flag.
Talking about XLL (like Atmos) don't exist a fix configuration and maybe for that can show the message

Do you know what "Bitstreaming parsing" failed means for the EAC3 (DD+) 7.1 tracks?

It was a old message until v3.36, now must be elimitated.

[oniiz86]

Talking about XLL (like Atmos) don't exist a fix configuration and maybe for that can show the message

I believe you meant XLL X (DTS:X) as that is like Atmos with its object-based audio metadata, the "XLL" (Extension Lossless) is simply referring to the DTS-HD MA extension.

Do you know what "Bitstreaming parsing" failed means for the EAC3 (DD+) 7.1 tracks?

It was a old message until v3.36, now must be elimitated.

The "Bitsreaming parsing" failed message log is still present in the latest eac3to_mod v3.37, v3.38, v3.39 updates, do you think it is not something to be concerned with & the EAC3 (DD+) 7.1 tracks will demux successfully?

[Curly]

Good morning everyone! I've decided to take a break from this stuff for mental health. Don't worry, though, I'll be back in half an hour.

I'm updating the tracking thread. So far I've added items that resulted from our discussions with madshi. Next I will add items from this thread, the doom9 forum, other web sources, and the madshi bug tracker. Will probably make a release based on the 3.39 test version before attacking other matters.

Thank you so much boys and girls for your contributions here.

Back in a jiffy!

[kedautinh12]

Can i rename eac3to_mod.exe to eac3to.exe and replace old ver???

[skull]

Can i rename eac3to_mod.exe to eac3to.exe and replace old ver???

Yes, I do that, and just keep backup version just in case, to compare if any bugs discovered. Thanks for all the hard work Curly and make sure to take well deserved mental health breaks. <3

[oniiz86]

Thanks for that, then why does demuxing the core with tsMuxer, well it's including the sub-extension which is the DTS ES 6.1 Matrix extension, it reports it as DTS ES Matrix "7 channels"

Really I don't know. I never see a software decoder than obtain 7 channels from a DTS ES Matrix, only hardware 6.1 players extract the matrixed channel to Back Center. With 5.1 systems the Back Center is played like a phantom speaker (see the (Cs) in the image) with the common audio in surround channels (analog matrixed) without problems.

Sorry for the confusion but when I meant 7 channels for DTS ES Matrix, it always means 6.1 channels for DTS ES Matrix/Discrete encodes, as you know MediaInfo always reports the .1 LFE channel as part of the total number of bed-layer channels, so 8 channels (7.1), 7 channels (6.1) & 6 channels (5.1)

[Curly]

Can i rename eac3to_mod.exe to eac3to.exe and replace old ver???

Yes. The _mod is just for distinguishing DG versions from madshi versions. This may change but I want to discuss it with madshi before changing anything.

[BizkitBoy]

Just wanted to ask again if what I asked in my above post is doable (i.e. converting EAC3 directly to AC3, while the former is within a multi-format container).
It took a bit until it got approved and it was probably missed.

Also, 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.

I know these are low priority items as both have workarounds.
I only wanted to check if they'll make it on the list of "to do" items.

Thanks again for taking up the task to continue madshi's amazing work, Curly!

[Sherman]

Moe: Let’s go fishing.
Curly: I got the worms.
Moe: That’s ok, we’ll go anyway.

[Curly]

Folks, please be patient for updates to the bugs/features thread and don't repeat your requests. I don't miss a thing!

[oniiz86]

Here is a test version for the DN changes:

* You now have -removeDialnorm instead of -keepDialnorm. You will keep dial norm
automatically unless you give -removeDialnorm.
* Performance has been substantially improved by removing unnecessary CRC checks.
* In the streams listing the dialnorm values are now always shown. Previously, if the
value was 0 or >30 the value was not shown.
* If -removeDialnorm is given and a stream is already at -31dB, this is shown with
a 'skipping' message. Previously nothing was printed, leaving the user possibly wondering
what is going on.

Your test results will be appreciated.

https://rationalqm.us/misc/eac3to_mod_3.39_test.rar

You will keep dial norm automatically unless you give -removeDialnorm. BTW, -removeDialnorm just writes the dialnorm field to -31 dB. It doesn't actually remove anything. I updated my post above to clarify that.

Hi Curly, I'm a bit confused by -removeDialnorm's behaviour with my sample file that I attached in my first post of this thread, the DTS-HD MA 7.1 audio stream has a DialNorm value of -4dB & when using -removeDialnorm & -logdts it still has a -4dB value not -0dB or -31dB, is that the expected behaviour?

If I use MKVToolNix's "Remove dialog normalization gain" with my sample file it will return a DN value of -0dB which is correct, I believe MKVToolNix is one of the few that can effectively remove DN from both extension sub-streams & the core, it was an issue though with MKVToolNix a few years ago https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2377

[DelBoy83]

From what I've read, when removing dialnorm it will become 31dB instead of 27dB in most cases. I can't really get my head around this dialnorm business, I was reading one of madshi's old posts the other day and he explained that it's important to remove dialnorm. Madshi knows he's stuff so I'm now wondering why others tell you to keepdialnorm? I didn't realise that mkvtoolnix has an option too, now I'm thinking it's better to remove the dialog normalization after all.

[jpsdr]

Hello.

Personnaly, I share manuelrn point of view of not removing the CRC checks. We are not doing a speed race, but more a reliability/quality race.

[skull]

Hello.

Personnaly, I share manuelrn point of view of not removing the CRC checks. We are not doing a speed race, but more a reliability/quality race.

You still have the previous eac3to version as legacy, and think allowing the extra CRC checks and removing DNR to be optional is a good way forward, or perhaps allowing eac3 to have -fast mode or something. I also believe many people are making a mountain out of a molehill as far as DNR goes, if it's ever an issue, it is a mere 4dB! and since when has adjusting volume for movie watching been a source of serious suffering for users? In my lifetime of watching movies at home, the volume I settle on always depends on many factors, and DNR is wayyyy down the list, lol.

[DelBoy83]

Hello.

Personnaly, I share manuelrn point of view of not removing the CRC checks. We are not doing a speed race, but more a reliability/quality race.

You still have the previous eac3to version as legacy, and think allowing the extra CRC checks and removing DNR to be optional is a good way forward, or perhaps allowing eac3 to have -fast mode or something. I also believe many people are making a mountain out of a molehill as far as DNR goes, if it's ever an issue, it is a mere 4dB! and since when has adjusting volume for movie watching been a source of serious suffering for users? In my lifetime of watching movies at home, the volume I settle on always depends on many factors, and DNR is wayyyy down the list, lol.

Your absolutely right in regards to 4dB, it's nothing and you won't even notice it. However keeping dialnorm sacrifice the crc checks? That's what separates eac3to from the rest, the actual checks it does whilst demuxing.

[Curly]

Hi Curly, I'm a bit confused by -removeDialnorm's behaviour with my sample file that I attached in my first post of this thread, the DTS-HD MA 7.1 audio stream has a DialNorm value of -4dB & when using -removeDialnorm & -logdts it still has a -4dB value not -0dB or -31dB, is that the expected behaviour?

Well, 3.36 also acts that way. I'll check into it and report back.

EDIT: Apparently it is skipped for DTSMA but not normal DTS. I am checking further.

[Curly]

Personally, I share manuelrn point of view of not removing the CRC checks. We are not doing a speed race, but more a reliability/quality race.

I'm going to add an option to keep them. -fast or -slow, let the battle begin. It's not a speed race, sure, but I don't like waiting 45 minutes to demux a disk too. It'll be like Burger King, have it your own way.

Gotta finish updating the bugs/features thread...

[skull]

Personally, I share manuelrn point of view of not removing the CRC checks. We are not doing a speed race, but more a reliability/quality race.

I'm going to add an option to keep them. -fast or -slow, let the battle begin. It's not a speed race, sure, but I don't like waiting 45 minutes to demux a disk too. It'll be like Burger King, have it your own way.

Gotta finish updating the bugs/features thread...

Haha, love the concept. Good to hear, keep up the great work!

[Baltasar]

I like this skull fellow.

[SomeHumanPerson]

I'm going to add an option to keep them. -fast or -slow, let the battle begin. It's not a speed race, sure, but I don't like waiting 45 minutes to demux a disk too. It'll be like Burger King, have it your own way.

This approach is appreciated. I don't know how frequently those CRC checks might actually catch a problem that other demuxers would ignore, but at least having the option to use them seems wise.

[trojiteEL]

I'm going to add an option to keep them. -fast or -slow, let the battle begin. It's not a speed race, sure, but I don't like waiting 45 minutes to demux a disk too. It'll be like Burger King, have it your own way.

This approach is appreciated. I don't know how frequently those CRC checks might actually catch a problem that other demuxers would ignore, but at least having the option to use them seems wise.

Fully agreed! Had a couple of instances where regular blu-ray or UHD blu-ray were wrongly ripped and eac3to was one of a few tools which inform me about this upon demuxing the discs so I could re-rip them. Not sure if this was thanks to these CRC checks, but if yes - please let them stay