EAC3TO Requests and General Discussion

[Curly]

alright folky-woksies what to do

i updated the list and it looks like the DN removal for DTS is the top bug right now
shud i work on that or one of the feature requests

[oniiz86]

I noticed the cosmetic bug "-0 dB should be given as 0 dB." will not in fact be fixed, perhaps it is rather trivial but thought it would be deemed as a rather easier enough fix like the DTS "core" cosmetic bug that was displayed as "4" but is now correctly "-4dB", is this definitely not something to be reconsidered at a later time after all more pressing bugs/features functionality that should take priority are addressed?

[Curly]

OK, since you insist, I'll do it. If it's important to you, it's important to me!

[Curly]

I updated the 3.41_test build with the -0dB -> 0dB fix.

[skull]

Haha, love it Curly. Always serving the people.

[oniiz86]

Oh thanks so very much for tackling it so swiftly, you're the man Curly

[new_guy]

[Curly]

r u guys taking the mickey

[Guest 2]

I have updated versions of libaften.dll and libdcadec.dll, looking at the timestamp.

I can't remember when and where I updated from but I think they are more recent.

Evaluate if to include in the package.

updated_dll.7z

(213.86 KiB) Downloaded 508 times

[Curly]

i'll check them out

gotta confess to being a bit dubious about DLLs with no version number and unknown origin
dunno if Rocky would allow us to use them

[skull]

Strongly agree, whenever suggesting updated .dll, the source should be mandatory for review. For those particular (2) .dll files, I usually look to StaxRip for newer versions and still the same legacy files in their latest version.

[SomeHumanPerson]

Ideally, I think the focus should be on removing dependency on those DLLs entirely rather than worrying about updated versions where provenance is always going to be an issue.

If we could transition entirely to ffmpeg-based libraries for anything handled by those (which is something I genuinely don't know the details of, so I'm only putting it out there as aspirational), it would be hugely advantageous since ffmpeg is under active, responsive development and provenance is always easy.

[skull]

I agree, in principle, but sometimes the old adage of "if it ain't broke, don't fix it" applies, even in situations of (old) dependencies, especially given that latest eac3to_mod version is just ~12MB in size and only contains 10 .DLLs, and runs very lean. However, it would be a nice future goal to shoot for, no doubt.

[Guest 2]

gotta confess to being a bit dubious about DLLs with no version number and unknown origin

I took aften from https://github.com/wieslawsoltes/AftenW ... s/releases and I think libdcadec.dll from https://github.com/foo86/dcadec/releases/tag/v0.2.0

[Curly]

Thank you.

[Curly]

Starting with 3.42 we are dropping the _mod. We've already dropped it for the forum name and topic names.

[Rocky]

@skull

The URL for eac3to builds is now simply:

https://rationalqm.us/eac3to

That's consistent with how we manage the other products. You may need to tell videohelp. Thank you.

As Curly said, future builds will drop the _mod, e.g., eac3to_3.42.rar

[skull]

@skull

The URL for eac3to builds is now simply:

https://rationalqm.us/eac3to

That's consistent with how we manage the other products. You may need to tell videohelp. Thank you.

As Curly said, future builds will drop the _mod, e.g., eac3to_3.42.rar

Exciting to see. I also let videohelp support know about this. Cheers!

[Curly]

Got everything straightened out with minimum playlist duration option and all that. Yer gonna be proud of me if yer not. Test build coming. All chapters kept. Oops there go 90% of our users. Sorry Charlie only the best.

was thinking about the splash screen
ya know it doesnt show all the options
shud we have a -fullhelp option or something
and why should it be telling us what eac3to can do
have u ever seen such a thing
lemme know yer thoughts guys no low iq thinking
leave yer comments below

[SomeHumanPerson]

As a matter of practice, I think that all command line tools should have something akin to a man page that provides a comprehensive rundown of usage, syntax, and options. I find it extremely frustrating to rely solely on online resources, especially if those resources are not "official" and therefore might be outdated or just plain wrong. In this case specifically, I probably don't even know half of what eac3to can actually do.

That said, I'm aware that it's probably a substantial undertaking to do this well.

I'm also not opposed to simply having a useful README along with the program that accomplishes the above rather than coding anything in (but I guess if you have a README, just displaying the contents with a "-fullhelp" option would be pretty trivial to implement).

Not sure if any of this exceeds the "no low IQ thinking" bar.

[Curly]

Thank you. That's what I was thinking 2 so it's hi IQ (I know yer smarter than me)
The man page should not be difficult given the online resources.
hows my punctation ok?

4 sure definally about not having to code stuff in
needs wisdom and xperience to grok
r u experienced?

[oniiz86]

I was curious if anyone could explain how eac3to actually removes "DTS zero padding" & repairs "outdated DTS ES headers", it's a notable feature "can remove DTS zero padding and repair outdated DTS-ES headers " of this utility, I know it was the only solution in allowing my DTS-HD MA 6.1 audio tracks to be bitstreamed correctly from my OPPO UDP-205 & BDP-105D players to my Denon X8500H AVR, simply demuxing with gMKVExtractGUI & then muxing with MKVToolNix proved to be ineffective, I had to extract the audio stream with eac3to first then mux with MKVToolNix which allowed playback to be successful, DTS-HD MA 5.1/7.1 audio tracks, even DTS-HD MA 7.1 tracks with a DTS ES 6.1 extension are fine, only DTS-HD MA 6.1 audio tracks that typically have a DTS ES 6.1 extension were problematic.

[Curly]

I'll try to do some spec and code reading to answer that but it may be a while as we have some bugs to fix first.

[Curly]

Hmm, I couldn't find an option for that. I suppose it happens automatically when needed. One thing to note is that if the DTS frame has a CRC, then repair cannot be done. That is similar/related to the inability to remove dialnorm for DTS.

Not really sure what you mean by 'how' or how the answer to that could help you. Nevertheless, here is the repair code:

Code: Select all

function TDtsRepairer.Process(whoAmI: pointer; header: boolean; buf: pointer; size: dword; timestamp: int64; keyFrame: boolean) : boolean;
var frame : TPAByte;
    i1    : integer;
    len   : dword;
begin
  if FValid then
    if FUpStreams <> nil then begin
      if FillStreamBuf(0, buf, size) then begin
        frame := StreamBuf[0];
        if frame[4] and 2 = 0 then begin
          if (not FChecked) or FNeedsRepair then
            if frame[12] and $40 <> 0 then
              // DTS-ES
              for i1 := 96 to size - 95 do
                if (not odd(i1)) and (TPCardinal(@frame[i1])^ = $5a5a5a5a) then
                  if FInvalidateXCh then begin
                    FNeedsRepair := true;
                    TPCardinal(@frame[i1])^ := $00000000;
                  end else begin
                    len := dword(frame[i1 + 4]) shl 2 + frame[i1 + 5] shr 6;
                    if len >= 94 then
                      if len = size - dword(i1) then begin
                        // "len" is one too high - needs to be patched
                        dec(len);
                        frame[i1 + 4] := byte(len shr 2);
                        frame[i1 + 5] := byte(len shl 6) or (frame[i1 + 5] and $3f);
                        FNeedsRepair := true;
                        break;
                      end else
                        if len + 1 = size - dword(i1) then
                          // correct
                          break;
                  end;
          if FNeedsRepair and (not FChecked) then
            if FInvalidateXCh then
              Log(ltInfo, 'Removing XCh extension...')
            else
              Log(ltInfo, 'Correcting DTS-ES information...');
          FChecked := true;
          FValid := PassData(false, frame, size, timestamp, keyFrame);
          StreamCap[0] := 0;
        end else begin
          FValid := false;
          Log(ltError, 'The bitstream can''t be repaired because there''s a CRC in the DTS file.');
        end;
      end else begin
        FValid := false;
        Log(ltError, 'The DTS repairer couldn''t allocate enough memory.');
      end;
    end else begin
      FValid := false;
      Log(ltError, 'The DTS repairer upstream property is not set.');
    end;
  result := FValid;
end;

Are you asking what are zero bytes and/or what is an outdated header?

[oniiz86]

Hmm, I couldn't find an option for that. I suppose it happens automatically when needed. One thing to note is that if the DTS frame has a CRC, then repair cannot be done. That is similar/related to the inability to remove dialnorm for DTS.

Are you asking what are zero bytes and/or what is an outdated header?

Thanks very much for that, I was merely curious that's all but yes I was wondering what exactly are DTS' zero bytes & DTS ES outdated headers, the dialnorm issue only pertains to DTS-HD headers not DTS "core" as we know.