Looking for a eac3 7.1 encoder

[Enverex]

Originally Posted by tebasuna51

In both you need disable the DRC like the images, but if the E/AC3 is sended passtrough by SPDIF/HDMI to your AVR, is the AVR who needs be disabled.

This was the first thing I tried when I initially ran into the problem, it made no difference as though the volume was actually changing in the audio stream, not a DRC issue.

This also wouldn't work even if it was the issue as I obviously can't have everyone disable DRC...

[Balling]

Anyway, could not help myself changing two bytes in EAE.exe in IDA pro 7.7. https://github.com/pabloromeo/cluste...dioEncoder.zip

BTW, priming samples in eac3 of Mediaconcept SFK in eae.exe is ~1760 samples compared to 256 in ffmpeg. And of course mp4 container is not fixing priming in editlist's media time (just set to 0). Not cool.

Also, it can correctly do fully packed 24 bit TrueHD in all cases (https://trac.ffmpeg.org/ticket/5054) and it can even decode mono truehd correctly, our decoder in ffmpeg when it was not broken was not lossless apparently (https://trac.ffmpeg.org/ticket/1726#comment:7).

Who can compare Audiotion 2017 and Plex? I can do, I have both now!

[Balling]

Apparently mlp decoder in ffmpeg is not lossless compared to what EAE.exe gives!!! (That was on DVD, Blu-ray uses TrueHD.) https://trac.ffmpeg.org/ticket/4786#comment:4

Just like mono TrueHD.

Also it applies DRC by default for some TrueHD!! So it also makes it lossy. Wow.

Channels in wav are all in correct place, though.

[Balling]

Who knows how to delete thd DRC? It is really crazy that lossless format has such metadata. It is one thing to apply DR and Gain...

[richardpl]

Stop spreading your nonsense misinformation.

[speedy]

Should I be able to use pcroland/deew these days instead of ymgenesis/audiotool for TrueHD 7.1 to EAC3 7.1 conversion?

How about for the following as well?
1) TrueHD 5.1 to EAC3 5.1
2) DTS XLL 7.1 to EAC3 7.1
3) DTS XLL 5.1 to EAC3 5.1
4) TrueHD Atmos to EAC3 Atmos

Thanks!

[pcroland]

ymgenesis/audiotool uses ffmpeg, which is way worse than using a Dolby certified encoder like DEE (that deew uses).

[richardpl]

pcroland's "software" uses certified software illegally. Breaking Dolby's company intellectual property rights and never asked permission to use Dolby utility, not even asked Plex for permission to write this so called wrapper.

[rwill]

Originally Posted by richardpl

pcroland's "software" uses certified software illegally. Breaking Dolby's company intellectual property rights and never asked permission to use Dolby utility, not even asked Plex for permission to write this so called wrapper.

Can you please elaborate further ?

--
I post on my own and not in the name of the company I work for.

[pcroland]

Originally Posted by richardpl

pcroland's "software" uses certified software illegally. Breaking Dolby's company intellectual property rights and never asked permission to use Dolby utility, not even asked Plex for permission to write this so called wrapper.

It's not included in deew and it has nothing to do with Plex. Have you even looked at the repo? You shouldn't say bullshit like that if you have no clue what you talk about.

[Balling]

Originally Posted by richardpl

pcroland's "software" uses certified software illegally. Breaking Dolby's company intellectual property rights and never asked permission to use Dolby utility, not even asked Plex for permission to write this so called wrapper.

You are not a laywer, are you? Because a) it does not use Plex, it uses DEE that is 400$USD, b) it is not illegal to automate licensed Plex EAE.exe and it is not illegal to use ffmpeg (Plex Transcoder.exe) to use EAE.exe.

And anyway, unless it is commercial, there is no way to prosecute endusers for that, there is almost no precedent.

[Enverex]

Originally Posted by richardpl

pcroland's "software" uses certified software illegally. Breaking Dolby's company intellectual property rights and never asked permission to use Dolby utility, not even asked Plex for permission to write this so called wrapper.

I don't remember anyone asking you. Also they aren't distributing the DD encoder OR EAE, so what are you talking about? Please don't derail this thread with this garbage, it's very important to some of us.

[Balling]

Atmos open source decoder (EAC3 only for now), Paul, please implement this (Huffman tables are on ETSI side):

https://github.com/VoidXH/Cavern/blo...dingDecoder.cs

Here is Huffman entry point: https://github.com/VoidXH/Cavern/search?q=Huffman

FFmpeg did a lot of stuff to add 9.1.6 and other even more complex ambysonic layouts. Of course flac does not support 16 channles, only wv does, yet wavpack decoder (not encoder) in ffmpeg does not support producing 16 channels.

https://forum.ixbt.com/post.cgi?id=a...844:6486:1.png

[Balling]

Checked some real DVDA. MLP is after all decoded same as in ffmpeg!

Instead of setting any cmd.exe variables with SET you can just use Plex Transcoder.exe (ffmpeg) option -eae_root C:\Users\Name.

So that (hacked Easyaudioencoder.exe) and eae_root in Plex Transcoder.exe allow very simple and very nice workflow!

[Balling]

Checked EAC3 too!!! Apprently it applies DRC there too, not cool!! eac3_eae that is, on the left here: https://imgur.com/a/odapgAC

while on the right is FFmpeg decoder. eac3_mf that is in the binary too is also a little different.

QUESTION: is eac3 like TrueHD? 24 bit really, because encoding directly to flac produces 24 bit mode of flac, not 16 (as that is just the default for wav). TrueHD is like that, 100%.

[tebasuna51]

Originally Posted by Balling

QUESTION: is eac3 like TrueHD? 24 bit really...

Lossy encodes (eac3) don't have bitdepth at all, the precission is always less than 16 bits (can't recover the source bitdepth exactly).

BTW, like decoders works with float samples, is always better recover the decodec sources at float 32 or at least 24 int.

[Balling]

Latest commit from https://github.com/VoidXH/Cavern can now create per object 16 channel ADM with iXML. Commit before fixed key problem with decoding atmos. So it is now production ready. Unity app requires .wav and .mkv with eac3 inside to play objects' Brownian motion: see https://photos.app.goo.gl/biAubMWnT8AM18Xm6

We really need to compare ADMs.

[Balling]

You can also create a separate XML + WAV file!! That is done on the last saving state in explorer.exe window.

I also opened an issue that talks about how EAC3 is more than 16 bit technically (and even provided a workaround to force initial 24 bit), I checked two 24 bit file (silence is 0x00 in to 24 bit, but 0xFF in case of doing 16 bit --> 24 bit), one of which was done from default 16 bit ffmpeg wav (a bug really, I asked everyone on the team to fix it, but I suppose they are afraid it will break too much).

I also created an ADM with iXML inside and detached XML using that workaround!! Guys, please check in Dolby Tools and Nuendo + Davinci (no need to use detached XML). Thanks! I want to know it renders the 16 objects correctly using panning position metadata! https://disk.yandex.ru/d/adBuxVIZAG_5wg

Ah, yes, newest verion of CavernizeGUI with ADM and WAV+ADM XML: https://github.com/VoidXH/Cavern/fil.../caverngui.zip

[Balling]

Originally Posted by tebasuna51

Lossy encodes (eac3) don't have bitdepth at all, the precission is always less than 16 bits (can't recover the source bitdepth exactly).

BTW, like decoders works with float samples, is always better recover the decodec sources at float 32 or at least 24 int.

The precision even in flac is not always the same bits! That is not argument, if only 10 bits are needed to preserve the wav file. It may have some parts less than 16 bits, but may have some more.

[tebasuna51]

Originally Posted by Balling

I also opened an issue that talks about how EAC3 is more than 16 bit technically

Encoders convert source time samples (like stored in WAV files) to frequency domain using float maths. Decoders convert frequency domain data to time samples, even until 64 bits float, try:

eac3to input.ac3 output.wav -full
...
Decoding with libav/ffmpeg...
...
The processed audio track has a constant bit depth of 64 bits.

It is not a upsize, are real outputs from libav decoders.

If the source is only 16 bits int how we have now 64 bits float?
But lossy encoders do not guarantee recover the same 16 bits than source, only a good approximation, better with more bitrate (more frequency domain data) was used to encode. For that the quality in lossy encoders is mesured in bitrate and don't have any exact bitdepth.

Lossless encoderst guarantee recover the same 16 bits than source.

I checked two 24 bit file (silence is 0x00 in to 24 bit, but 0xFF in case of doing 16 bit --> 24 bit)

Samples in wav have 3 bytes signed_le from 0x7FFFFF (stored FFFF7F=+1), 0x000000 (0),0xFFFFFF (-0.000001), 0x800000 (stored 000080=-1)

one of which was done from default 16 bit ffmpeg wav (a bug really...)

A bug? Select the bitdepth desired decoding lossy formats.
If you decode lossless and upsize (16 ->24) read about dither.

Originally Posted by Balling

The precision even in flac is not always the same bits! That is not argument, if only 10 bits are needed to preserve the wav file. It may have some parts less than 16 bits, but may have some more.

Without sense.

With lossless encoders the original source can be recovered with all bits exacts.
Average human ears can difference sounds until a precision of 20 bits,
All parts in a lossless encode have the same bitdepth precision,