[LOCKED] EAC3TO Bug Reports and Feature Requests Only
EAC3TO Mod Project
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.
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.
EAC3TO Mod Project
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.
Yes, must be:4: EAC3, French, 7.1 channels, 48kHz, dialnorm: -0dB "DDP 7.1"...
4: EAC3, French, 7.1 channels, 48kHz, dialnorm: -27dB "DDP 7.1"
EAC3TO Mod Project
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.
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.
EAC3TO Mod Project
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"Guest 3 wrote: ↑Sat Nov 04, 2023 5:00 amI 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.
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"?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
Do you know what "Bitstreaming parsing" failed means for the EAC3 (DD+) 7.1 tracks?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"
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>
EAC3TO Mod Project
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.
DTS-MA can have many 7.1 speakers configuration like can see in the attached image....do you know why eac3to is reporting the DTS ES XLL audio stream as "strange setup"?
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
It was a old message until v3.36, now must be elimitated.Do you know what "Bitstreaming parsing" failed means for the EAC3 (DD+) 7.1 tracks?
- Attachments
-
EAC3TO Mod Project
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.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?
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?It was a old message until v3.36, now must be elimitated.
EAC3TO Mod Project
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!
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!
Curly Howard
Director of EAC3TO Development
Director of EAC3TO Development
- kedautinh12
- Posts: 3
- Joined: Mon May 30, 2022 6:28 am
EAC3TO Mod Project
Can i rename eac3to_mod.exe to eac3to.exe and replace old ver???
EAC3TO Mod Project
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. <3kedautinh12 wrote: ↑Sat Nov 04, 2023 8:42 pmCan i rename eac3to_mod.exe to eac3to.exe and replace old ver???
EAC3TO Mod Project
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)Guest 3 wrote: ↑Sat Nov 04, 2023 6:58 amReally 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.
EAC3TO Mod Project
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.kedautinh12 wrote: ↑Sat Nov 04, 2023 8:42 pmCan i rename eac3to_mod.exe to eac3to.exe and replace old ver???
Curly Howard
Director of EAC3TO Development
Director of EAC3TO Development
EAC3TO Mod Project
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!
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!
EAC3TO Mod Project
Moe: Let’s go fishing.
Curly: I got the worms.
Moe: That’s ok, we’ll go anyway.
Curly: I got the worms.
Moe: That’s ok, we’ll go anyway.
Sherman Peabody
Director of Linux Development
Director of Linux Development
EAC3TO Mod Project
Folks, please be patient for updates to the bugs/features thread and don't repeat your requests. I don't miss a thing!
Curly Howard
Director of EAC3TO Development
Director of EAC3TO Development
EAC3TO Mod Project
Curly wrote: ↑Thu Nov 02, 2023 8:20 amHere 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
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
EAC3TO Mod Project
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.
EAC3TO Mod Project
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.
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.
EAC3TO Mod Project
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.
EAC3TO Mod Project
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.skull wrote: ↑Tue Nov 07, 2023 11:06 amYou 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.
EAC3TO Mod Project
Well, 3.36 also acts that way. I'll check into it and report back.oniiz86 wrote: ↑Tue Nov 07, 2023 10:02 amHi 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?
EDIT: Apparently it is skipped for DTSMA but not normal DTS. I am checking further.
Curly Howard
Director of EAC3TO Development
Director of EAC3TO Development
EAC3TO Mod Project
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...
Curly Howard
Director of EAC3TO Development
Director of EAC3TO Development
EAC3TO Mod Project
Haha, love the concept. Good to hear, keep up the great work!Curly wrote: ↑Tue Nov 07, 2023 11:38 amI'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...
EAC3TO Mod Project
I like this skull fellow.
- SomeHumanPerson
- Posts: 96
- Joined: Fri Mar 24, 2023 10:41 am
EAC3TO Mod Project
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.
EAC3TO Mod Project
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 staySomeHumanPerson wrote: ↑Tue Nov 07, 2023 12:43 pmThis 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.