eac3to - audio conversion tool

[Thunderbolt8]

whats the relation between the bitdepth switch fix and your re-opening of that topic at dcadec github?

[Boulder]

eac3to v3.31 released
Thanks, madshi!

[madshi]

whats the relation between the bitdepth switch fix and your re-opening of that topic at dcadec github?
I did what I could do in eac3to to handle all possible situations correctly. There *may* still be something minor to fix in dcadec but nothing dramatic.

[Boulder]

Is dcadec now more accurate what comes to errors while decoding? I tested the new version on a stream which had no errors with v3.29, the new version reports "libDcaDec reported the warning "XLL output not lossless"." while decoding. I don't know if it's related to this, but in this case I have a DTS-HD MA track which is reported as 24 bits but contains only 16-bit data.

[madshi]

Not sure about 3.29, that's too old.

[nevcairiel]

Is dcadec now more accurate what comes to errors while decoding? I tested the new version on a stream which had no errors with v3.29, the new version reports "libDcaDec reported the warning "XLL output not lossless"." while decoding. I don't know if it's related to this, but in this case I have a DTS-HD MA track which is reported as 24 bits but contains only 16-bit data.

"not lossless" warnings appear on totally valid streams sometimes, its just a thing about how the format works when its stitched together on clip boundaries or things like that.
Decoding of these parts didn't change, it now simply outputs a warning instead of silently ignoring such cases.

[Boulder]

Not sure about 3.29, that's too old.Tested with v3.30 as well, the same thing (it doesn't report anything).

If you (or the dcadec dev) want to see the source track, I can provide it. It's a stereo track so it doesn't require a huge amount of space.

EDIT: just read nevcairiel's explanation. Makes perfect sense :)

[NikosD]

eac3to v3.31 released

http://madshi.net/eac3to.zip


* fixed: TrueHD decoding -> AC3 encoding didn't work properly

Thanks.

It works now.

[Thunderbolt8]

can DTS:X (headphone) tracks be delayed? is there any way to implement atmos tracks being able to be delayed?

[GZZ]

is there anyway to control the compression level when encoding to Flac ?

[SeeMoreDigital]

eac3to v3.31 released

http://madshi.net/eac3to.zip

* fixed: TrueHD decoding -> AC3 encoding didn't work properly
Many thanks :)

[Sparktank]

The updates have been very enterprising lately. :)

[73ChargerFan]

is there anyway to control the compression level when encoding to Flac ?
See this post (http://forum.doom9.org/showthread.php?p=1742284#post1742284) or search this thread to see other answers.

[r0lZ]

... the dcadec interface changed a bit, allowing warnings now instead of errors.
eac3to v3.31 released

http://madshi.net/eac3to.zip

* libDcaDec: updated to latest build
* libDcaDec: decoding only aborts on critical issues now
* libDcaDec: now reports warnings if something isn't 100% perfect
* libDcaDec: proper handling of clipped files (2nd pass etc)
* libDcaDec: proper handling of tracks that switch bitdepth 16 <-> 24
* fixed: TrueHD decoding -> AC3 encoding didn't work properly
Thanks for the update. I confirm that the new version no longer aborts with a Synchronisation error when converting some DTS-HD-MA tracks. (DcaDec "strict mode" problem reported here (http://forum.doom9.org/showthread.php?p=1745158#post1745158) and here (https://github.com/foo86/dcadec/issues/38#issuecomment-153026239).) Now, only a warning is printed to the log. It's perfect! Thanks!

Madshi, just to be sure, the option I've requested via your bug tracker (here (http://bugs.madshi.net/view.php?id=358)) to turn off the strict mode doesn't seem to be implemented. I suppose that it is not necessary any more, because now eac3to can distinguish a warning from a fatal error, and doesn't stop any more when it's not absolutely necessary, but you have closed the request with the message "Implemented in v3.31." Does it mean that there is a new option to turn off the strict mode? In that case, what is its syntax? Or have you abandoned the idea of the option because it is not longer necessary to implement it?

Anyway, it's only a theoretical question. I suppose I don't need that option any more. Thanks again for the update. :-)

[madshi]

can DTS:X (headphone) tracks be delayed? is there any way to implement atmos tracks being able to be delayed?
There's nothing special about DTS:X or Atmos tracks. DTS tracks can be delayed, with or without DTS:X. TrueHD cannot, with or without Atmos.

just to be sure, the option I've requested via your bug tracker (here (http://bugs.madshi.net/view.php?id=358)) to turn off the strict mode doesn't seem to be implemented.
There isn't really an option, I simply replaced the whole logic by "abort only on critical errors, post warnings for non-critical stuff", which only the very latest dcadec version supports.

[ndjamena]

Jerome is in the middle of giving proper output for DTS ES tracks in MediaInfo... while he's at it, does anyone have a sample of a DTS:X header they'd be willing to share?

[r0lZ]

There isn't really an option, I simply replaced the whole logic by "abort only on critical errors, post warnings for non-critical stuff", which only the very latest dcadec version supports.
OK, it's indeed the best solution. Thanks again. :-)

[SeeMoreDigital]

... while he's at it, does anyone have a sample of a DTS:X header they'd be willing to share?
If it helps, here's a 10 second (m2ts) sample cut off the beginning of Ex Machina: https://www.sendspace.com/file/4cw0yj

Cheers

[Zenitram]

If it helps, here's a 10 second (m2ts) sample cut off the beginning of Ex Machina

I don't find an obvious method for detecting DTS:X in that DTS stream, it loooks like a classic DTS-MA file (and eac3to detects it as such too) but I don't implement the whole available DTS spec so maybe I miss something (anyway, the latest DTS spec has no tip about DTS:X :( ).
Any clue about how to detect DTS:X feature in the extension part of the DTS stream?

Edit Found how to do, thanks to dcadec guy (https://github.com/foo86/dcadec/issues/37)

[ndjamena]

Apparently a bunch of the Pixar movies and others have DTS ES Matrixed DTS-MA 5.1.

Would anyone see any point in EAC3To adding an "ES" tag to the FLAC files output from these movies?

[Yoshi]

I'm sure there are also lossless encodes where the clipping is part of the original PCM, but in this particular sample it is possible to retrieve the audio without clipping, albeit at a slightly reduced volume to make room for the extra data.

How did you retrieve the audio from Ex Machina without clipping? When I apply the -3dB option with eac3to for instance, I get the same clipped result, only at -3dBFS of course.

[madshi]

How did you retrieve the audio from Ex Machina without clipping? When I apply the -3dB option with eac3to for instance, I get the same clipped result, only at -3dBFS of course.
The latest eac3to 3.31 should automatically fix the clipping, without needing you to use any options.

[Yoshi]

Many thanks madshi for your support and hint!

I had used the Arcsoft-decoder with your new version of eac3to, switched back to libDca and now it works as you described.

However, my real problem now is my lack of understanding why it clips with the Arcsoft-decoder but doesn't with the bugfixed libDca-decoder:

http://img5.fotos-hochladen.net/uploads/clippingdj13yki0q4.jpg

Obviously, if libDca is able to recontruct the wave form, the clipping wasn't contained in the source as I assumed first.

Furthermore, eac3to doesn't report any clipping when using the Arcsoft decoder, which - so far - made perfectly sense to me since I logically assumed that when dealing with (I repeat myself, I know) lossless codecs, any clipping which might be encountered in the decoded PCM must have been already part of the source, thus any reduction in loudness level wouldn't give anything (except for intersample peak clipping during D/A-conversion, but that's a topic on its own).

How does eac3to actually sense any clipping at all? Does it analyse the decoded PCM and count successive samples at 0dBFS like many audio editors do it or does it rely on the feedback of the decoders?

Since once clipped, it's impossible to reconstruct anything beyond that point, the level reduction, eac3to performs must occur before decoding, am I right? It probably instructs the decoder to decode the stuff to PCM at a lower level. But why don't the decoders to this on their own? Because they are meant to be used at realtime and hence no 2nd pass is possible, so better clip than being too quiet?*

How much do I have to worry for already converted DTS-HD MA sources by the Arcsoft decoder now? Is Ex Machina a rare "clipping exception" due to its underlying DTS-X-stuff?

I mean, after all, isn't it totally frustrating to deal with lossless codecs just to realize that in not that few cases, it isn't? For me, it is!

*An additional thought: if the clipping can't be generally avoided without 2nd-pass-decoding, how does a stand-alone AV-receiver with all the newest gizmo-support (Dolby Atmos, DTS-X, bla bla codec) do it then? How does the signal look like after its "super officially licensed" decoder before the DAC is fed with it?

[madshi]

eac3to can detect and fix clipping when using libdcadec because libdcadec outputs its decoded samples in 32bit, so there's a lot of headroom to allow clipping to be transported from libdcadec to eac3to. ArcSoft is different, but it's a long time since I looked into the ArcSoft API. Maybe there'd be some way to detect clipping there, too, although I doubt it. In any case, it works with libdcadec, which is now the default decoder, so I don't really have much interest in improving the ArcSoft decoder.

I've no idea how many DTS-MA tracks might have clipping baked in, as Ex Machina does, so I can't comment on whether you need to rerip them or not. I would guess it's probably rare. Maybe it's a side effect of DTS:X, maybe the encoder is not bug free yet, but I really don't know.

DTS supports some sort of dialnorm processing. It's possible that receivers who perform dialnorm processing might avoid the clipping, but I doubt it. I think probably receivers would play Ex Machina clipped. But again I'm guessing, I've no idea.

Lowering volume results in floating point values, which means dithering needs to be applied. This is *not* perfectly lossless, and the compression efficiency goes down dramatically. So lowering volume is not recommend, unless it's absolutely necessary.

[Thunderbolt8]

I am decoding a 1.0 DTS-HD MA track to .wav and now the get info line "libDcaDec reported the warning 'XLL output not lossless'".

what does that mean and how is this relevant for me? does it mean that the track or the conversion is not lossless after all in this case?

edit: have to add theres the information "Original audio track: max 24 bits, average 16 bits, most common 16 bits." at the end of the decoding process. does that mean that this warning is now the default message in case of these mixed bitdepth audio tracks, meaning just to tell us that this track is no real/full 24-bit track, but fine and lossless otherwise?

[Yoshi]

"not lossless" warnings appear on totally valid streams sometimes, its just a thing about how the format works when its stitched together on clip boundaries or things like that.
Decoding of these parts didn't change, it now simply outputs a warning instead of silently ignoring such cases.

I can confirm this kind of warning with "Bates Motel Season 3" as well (DTS-HD MA 5.1). The result is bit identical to Arcsoft's output, though.


eac3to can detect and fix clipping when using libdcadec because libdcadec outputs its decoded samples in 32bit, so there's a lot of headroom to allow clipping to be transported from libdcadec to eac3to.

For me, this arises the question of what word-length the original source had during mastering/authoring in the studio. I thought that the maximum they feed the DTS encoders with would be 24-bit-PCM. :confused:


In any case, it works with libdcadec, which is now the default decoder, so I don't really have much interest in improving the ArcSoft decoder.

However, it seems to be advisable to consider it as some sort of backup/reference in addition. After all, libdca doesn't seem to be perfect either. I mean, one bug fixed, yet the next one to be discovered. :sly:

I've no idea how many DTS-MA tracks might have clipping baked in, as Ex Machina does, so I can't comment on whether you need to rerip them or not.

Is it baked in? I haven't analysed the whole soundtrack yet, but speaking only about the beginning with the helicopter passing by (this is where the first potential clipping occurs, be it "baked in" or "generated while decoding"), it seems that the original source of unknown wordlength must have been halfway clipping-free.

By the way, when using the DTS core of Ex Machina, both decoders show the clipping. Almost philosophical question: is the clipping here part of the DTS file or is just no decoder able to reproduce it? ;)

I would guess it's probably rare. Maybe it's a side effect of DTS:X, maybe the encoder is not bug free yet, but I really don't know.

I understand. However, if I should find another piece without any Atmos or DTS:X - extensions, behaving the same way in regard to clipping (or not), then I guess we all should better start to know.

I think probably receivers would play Ex Machina clipped. But again I'm guessing, I've no idea.

I guess that demonstrates how academic this actually is. I mean even the slight clipping isn't really hearable (however the result with the buggy libdca was) and hardly any "normal user" will ever care what is really played back as long as the logo of the newest audio format lights up on his new AVR. :p

Lowering volume results in floating point values, which means dithering needs to be applied. This is *not* perfectly lossless, and the compression efficiency goes down dramatically. So lowering volume is not recommend, unless it's absolutely necessary.

Now I'm left wondering if the newest eac3to + libDca combo reconstructs the source of e.g. Ex Machina authentically or not. After all, it can't be lossless anymore after the volume change as you put it.

Let me sum this up: so we have a nominally lossless source format like DTS:X (maybe adding some effects in realtime, but let's stick to the 7.1 channels for now) and no real-life-decoder can actually reproduce the source which was used to create it. Instead of slight loss due to a psychoacoustic model, we have (maybe even slighter, but still) loss due to calculations, overhead and clipping. Awesome.

[Yoshi]

does it mean that the track or the conversion is not lossless after all in this case?

Sorry I can't resist: maybe we should have asked Kurt Gödel while he was still around. It might be lossless but we will never be able to prove it since the source is unknown and will be forever. ;)

I start to wonder how lossless my rips I thought they were, actually are.

Gives the same message for "Jurassic World" as well. Since I'm paranoid now, I let decode the same DTS-HD MA track twice to FLAC in one run (dcaDec & Arcsoft) and compare if the FLAC matches.

The FLACs match despite the XLL-warning. Really lossless? Well ...

[Thunderbolt8]

I edited my post and added another information.

[Boulder]

What I've noticed is that the XLL warning often kicks in right when the decoding starts.

Is the warning output only once or every time the decoder reports it? In the latter case, would it be possible to output also the timestamp?

[Thunderbolt8]

it might be the case that some intro or studio logo has a different bit depth than the rest of the movie. that could be one explanation.

[LigH]

Regarding DVD Video, that was one of the reasons to extract "the movie PGC" instead of processing VOB sequences as authored: to avoid trailer audio issues like asynchronity.

Removing trailers from BD playlists may be a different topic...

[Thunderbolt8]

are DTS:X headphone (2.0) tracks which are currently detected as DTS track by eac3to actually lossy or lossless tracks, like other DTS-HD MA tracks? and are DTS:X tracks are not denoted as such by eac3to yet?

[Zenitram]

DTS:X headphone (2.0) trac

Could you provide a sample file of DTS:X headphone?

[ndjamena]

If anyone is interested here's the latest unofficial MediaInfo dll:

http://www.mediafire.com/download/5y4o9xucw6eizhl/MediaInfo.zip

This is what it gets you:

General
Unique ID : 219291506723631580012532402152276823948 (0xA4FA02080541F5119808D773964D0F8C)
Complete name : D:\Zilla.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 36.8 GiB
Duration : 2h 18mn
Overall bit rate mode : Variable
Overall bit rate : 37.9 Mbps
Movie name : Zilla
Encoded date : UTC 2015-11-17 09:05:56
Writing application : mkvmerge v8.5.1 ('Crosses') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Format settings, GOP : M=1, N=10
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 18mn
Bit rate mode : Variable
Bit rate : 34.7 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.698
Stream size : 33.6 GiB (92%)
Language : English
Default : No
Forced : No

Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 2h 18mn
Bit rate mode : Variable
Bit rate : 3 202 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Detected bit depth : 20 bits
Stream size : 3.10 GiB (8%)
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Language : English
Default : Yes
Forced : No

Text #1
ID : 3
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 2h 1mn
Bit rate : 11.4 Kbps
Count of elements : 2084
Stream size : 9.90 MiB (0%)
Language : English
Default : No
Forced : No

Text #2
ID : 4
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 1h 23mn
Bit rate : 198 bps
Count of elements : 36
Stream size : 121 KiB (0%)
Language : English
Default : No
Forced : No

Text #3
ID : 5
Format : PGS
Muxing mode : zlib
Codec ID : S_HDMV/PGS
Codec ID/Info : Picture based subtitle format used on BDs/HD-DVDs
Duration : 2h 9mn
Bit rate : 7 053 bps
Count of elements : 2460
Stream size : 6.52 MiB (0%)
Language : English
Default : No
Forced : No

Menu
00:00:00.000 : en:Start
00:07:48.092 : en:Collision Course
00:17:25.502 : en:Worm Guy
00:25:28.026 : en:"Gojira"
00:36:53.461 : en:Inside a Footprint
00:41:47.880 : en:Insurance Claim
00:48:19.479 : en:Caught on Something
01:01:35.900 : en:"I Got a Bite"
01:11:05.803 : en:New Kid in Town
01:21:38.685 : en:23Rd St. Station
01:30:26.087 : en:Drawing Him Out
01:39:13.989 : en:Fire at Will: One
01:50:23.867 : en:Copter Chase
01:52:28.658 : en:"He's Pregnant"
02:00:36.771 : en:Shaken, Not Stirred
02:05:56.882 : en:Section Five



Of note is "Detected bit depth" (EAC3To's "VALID_BITS" tag), channel layouts despite the fact that it's an EAC3To FLAC file without a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag and all the tracks have bitrates, despite the fact that they're in an mkv and there are two variable bitrate tracks in there.

Subtitle track one has 2084 elements in it, subtitle two has only 36, that one must be forced subtitles, the last subtitle has 2460 elements, which is more than the first, so the first must be the regular subtitles and the last must be SDH.

Oh, right, the flac was muxed straight into the file using MKVMerge, so the UID is 3419832279421249968 and yet its statistics tags are still being applied to it correctly.

And then there's this:

General
Unique ID : 215636814642891718231343589359444197377 (0xA23A23CCC54ADBF1948103B2D1428001)
Complete name : D:\DTS-X.mka
Format : Matroska
Format version : Version 4 / Version 2
File size : 123 MiB
Duration : 3mn 32s
Overall bit rate : 4 861 Kbps
Encoded date : UTC 2015-11-15 15:35:39
Writing application : mkvmerge v8.5.1 ('Crosses') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

Audio
ID : 1
Format : DTS
Format/Info : Digital Theater Systems
Format profile : X / MA / Core
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 3mn 32s
Bit rate mode : Variable / Variable / Constant
Bit rate : 4 859 Kbps / 4 859 Kbps / 1 509 Kbps
Channel(s) : Object Orientated / 8 channels / 6 channels
Channel positions : Object Orientated / Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
Sampling rate : / 48.0 KHz / 48.0 KHz
Bit depth : / 24 bits / 24 bits
Compression mode : / Lossless / Lossy
Stream size : 123 MiB (100%)
Language : English
Default : Yes
Forced : No

DTS:X

and this:

General
Unique ID : 186823894588399821734555224452256288412 (0x8C8CF929A176D63082E6B973CE30CE9C)
Complete name : D:\DTS ES.mka
Format : Matroska
Format version : Version 4 / Version 2
File size : 6.80 MiB
Duration : 4s 11ms
Overall bit rate : 14.2 Mbps
Encoded date : UTC 2015-11-13 23:30:23
Writing application : mkvmerge v8.5.1 ('Crosses') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

Audio #1
ID : 1
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / ES Matrix / Core
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 4s 10ms
Bit rate mode : Variable / Constant / Constant
Bit rate : 2 812 Kbps / 1 509 Kbps / 1 509 Kbps
Channel(s) : 8 channels / 7 channels / 6 channels
Channel positions : Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, Back: C, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy / Lossy
Stream size : 1.34 MiB (20%)
Language : English
Default : Yes
Forced : No

Audio #2
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / ES Discrete / Core
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 4s 0ms
Bit rate mode : Variable / Constant / Constant
Bit rate : 2 269 Kbps / 1 509 Kbps / 1 509 Kbps
Channel(s) : 7 channels / 7 channels / 6 channels
Channel positions : Front: L C R, Side: L R, Back: C, LFE / Front: L C R, Side: L R, Back: C, LFE / Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy / Lossy
Stream size : 1.08 MiB (16%)
Language : English
Default : No
Forced : No


Audio #3
ID : 3
Format : DTS
Format/Info : Digital Theater Systems
Format profile : ES Discrete / Core
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 4s 0ms
Bit rate mode : Constant
Bit rate : 1 509 Kbps
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
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 737 KiB (11%)
Language : English
Default : No
Forced : No



DTS ES in all it's glory.

[Frechdachs]

I have a question regarding a 2.0 24-bit DTS-HD MA file. I've decoded it with dcadec (eac3to v3.31) and the Arcsoft decoder (eac3to v3.28) and the file decoded with the Arcsoft decoder is quieter.

According to eac3to the DTS file has a Dialnorm value of -4dB. If my assumptions about Dialnorm are correct, that means that a gain has to be applied, since neither flac nor wav support Dialnorm. I thought that maybe the dialogue normalization wasn't taken into account while using the Arcsoft decoder, so I encoded it again with the "+4dB" option and tested the difference to the dcadec version. In order to do so I opened both audio streams in Reaper and aplied phase inversion to one of the streams. Now if they are identical they should cancel each other out resulting in complete silence. There was still a sound at about -120dB (deviation from the peak), which is absolutely inaudible, though.

Since I don't know much about Dialnorm I want to ask which version is correct, the one without the gain or the one with it and the dcadec version.
Also, is there a reason there is still a small measurable difference between the Arcsoft decoded file with the gain and the one decoded by dcadec, shouldn't they be the same if the gain is applied manually?
And finally, is there a better way to check if two audio files are identical?

On a side note, I did the same test with Reaper using a 5.1 24-bit DTS-HD MA track without a Dialnorm value. There was no measurable difference between Arcsoft and dcadec, meaning they are in fact completely identical.

[tebasuna51]

@Frechdachs

- Dialog Normalization was a interesting concept if all sounds respect it.
But there are many (TV advertisement, remastered CD's Loudness war (https://en.wikipedia.org/wiki/Loudness_war), ...) than try to offer the max digital volume in the wrong concept than loud volume is better quality. Thats enforce to use the Volume knob between normalized and not normalized sounds.
eac3to is a transcoding tool and, by default, try, if can do, to not apply Dialog Normalization to offer the original sound without attenuation.
What is correct? Is your choice.

- There are other methods to compare wav's but for this pourpose your method is correct (I also use it).
Take in mind than apply -4dB gain (DialNorm), and after a manual +4dB gain, is not a lossless operation and your can lose a bit of precission.
The dcadec output is the lossless source.

[airsoft]

And finally, is there a better way to check if two audio files are identical?



E:\>md5sum Tomorrowland*.wav
8e8d58cc32c6432a0c5222c7086e6444 *Tomorrowland_ArcSoft_decoder_eac3to-3.31.wav
8e8d58cc32c6432a0c5222c7086e6444 *Tomorrowland_default_eac3to-3.31.wav


listing of cmd prompt command dir - filesize and name

8 989 397 060 Tomorrowland_ArcSoft_decoder_eac3to-3.31.wav
8 989 397 060 Tomorrowland_default_eac3to-3.31.wav


I hope it was helpful for you as technique. Seems both "libDcaDec" and "ArcSoft" produces identical files which means according my knowledge the original lossless audio

[AlexKane]

@Frechdachs

Assuming you want the best possible result (sorry), the correct "version" is the one produced by dcadec, since it does not apply 4db of gain reduction. As tebasuna51 mentioned, the Arcsoft file will be lower quality since the LSBs (the noisefloor @ 120db) get trashed as your source file is integer precision format.

[Megalith]

Is eac3to still unable to remove dialnorm from DTS-HD MA tracks?

[SeeMoreDigital]

Is eac3to still unable to remove dialnorm from DTS-HD MA tracks?Come to think of it. I don't think I've ever seen my surround sound amplifier respond to a DTS-HD MA dialnorm flag. I've only ever seen it respond to a Dolby Digital dialnorm flag :eek:

[madshi]

The Dolby Digital spec requires Dolby Digital decoders to apply dialnorm by default, unless the user specifically disables it. DTS is not as stupid, fortunately, so DTS tracks have much less problems with that. When using libdcadec, dialnorm is by default ignored, so eac3to decoding no longer has any problems with that, anyway. eac3to still cannot fully remove dialnorm from DTS-HD tracks, though, because doing so would require to rewrite the whole HD frame structure, including CRCs etc, which is very complicated.

[Thunderbolt8]

does detecting DTS:X headphone tracks work differently from detecting norma DTS:X tracks? from what Ive heard using this info here https://github.com/foo86/dcadec/issues/37 does not lead to success in cases of headphone tracks.

maybe the dcadec developer could be able to figure something out as well in this case?

[Frechdachs]

- Dialog Normalization was a interesting concept if all sounds respect it.
But there are many (TV advertisement, remastered CD's Loudness war (https://en.wikipedia.org/wiki/Loudness_war), ...) than try to offer the max digital volume in the wrong concept than loud volume is better quality.

But why is it used on Blu-rays? There are no advertisments interrupting the movie, so there should be no need to constantly have to adjust the volume.

The Dolby Digital spec requires Dolby Digital decoders to apply dialnorm by default, unless the user specifically disables it. DTS is not as stupid, fortunately, so DTS tracks have much less problems with that. When using libdcadec, dialnorm is by default ignored, so eac3to decoding no longer has any problems with that, anyway.

That means I am misinterpreting dialnorm afterall. I thought that a dialnorm of -4dB would mean that in order to honor dialnorm a positive gain of 4dB has to be applied after decoding. But since you wrote that dialnorm is ignored for DTS-HD while using dcadec and not while using Arcsoft, there is rather a negative gain applied if dialnorm is honored (because in my test using dcadec resulted in a file that was 4dB louder than Arcsoft).

So if I get it straight this time, it meanst that when I use the Arcsoft decoder with the "+4dB" option, there is first a negative gain of -4dB applied (because of dialnorm) and then a positive gain again, which is retarded.

Is this correct?

eac3to still cannot fully remove dialnorm from DTS-HD tracks, though, because doing so would require to rewrite the whole HD frame structure, including CRCs etc, which is very complicated.

You mean when input and output is both DTS? If encoding to flac for example, either dialnorm has to be ignored or there has to be a gain applied, because flac doesn't support dialnorm. Or does it?

[nevcairiel]

You mean when input and output is both DTS? If encoding to flac for example, either dialnorm has to be ignored or there has to be a gain applied, because flac doesn't support dialnorm. Or does it?

When eac3to decodes the DTS track to convert it to FLAC, dialnorm is simply ignored.

[AlexKane]

That means I am misinterpreting dialnorm afterall. I thought that a dialnorm of -4dB would mean that in order to honor dialnorm a positive gain of 4dB has to be applied after decoding.

You indeed misinterpret dialnorm, as it is the exact opposite of what you thought.
A dialnorm flag of -4db means that the decoder needs to apply 4db of gain reduction during decoding. In your case, Arcsoft respects the dialnorm flag while dcadec does not.
If all you want is "Extract the audio as it is stored" and encode it in another format, you need to use dcadec. You can then apply any level adjustment during playback.

[tebasuna51]

...
So if I get it straight this time, it meanst that when I use the Arcsoft decoder with the "+4dB" option, there is first a negative gain of -4dB applied (because of dialnorm) and then a positive gain again, which is retarded.

Is this correct?
Yes Arcsoft apply -4dB (dialnorm) and after eac3to apply +4dB.
But not retarded, when you recode the time to do the operations is not important. Is other problem:

You lose precission in round to int values.

For instance you have a sample with a int 24 bits volume value of 16777211.
When you apply -4dB you obtain a real value than you must round to int:

Int value -4dB Int Up Int Down
--------- ------------- -------- --------
16777211 10585704,5003 10585705 10585704

But round up or down whe you apply +4dB:

Int value +4dB Int
--------- ------------- --------
10585705 16777211,7919 16777212
10585704 16777210,2070 16777210

You never finish with the lossless value 16777211

[Frechdachs]

Thank you for all the replys. Everything makes sense now.

You indeed misinterpret dialnorm, as it is the exact opposite of what you thought.

Yeah, I was probably misguided by the fact that the DTS track isn't very loud to begin with. It's a bit odd that the studio would want to reduce the volume even further during playback.

You lose precission in round to int values.
[...]
You never finish with the lossless value 16777211

That's what I meant when I said that it would be kind of stupid by me to do that. But thanks for the explaination on how the precision loss comes to be. Much appreciated.

[ndjamena]

https://github.com/MediaArea/MediaInfoLib/commit/5d3f12867ab1ee06c22148ac8f4d5b9e34f94144

if (HD_SubStreams_Count == 4) Fill(Stream_Audio, 0, Audio_Codec, "ATMOS");

Is EAC3To's detection of ATMOS any more complicated than that?

Is there anything else I should look out for?

[kukushka]

eac3to + Nero Audio Decoder (Nero 7) are dropping first aac frame on decoding. always. along with faad. ffmpeg & Nero AAC Decoder 1.5.1.0 are doing it correctly. can be verified as example with extracted aac from qaac --no-delay encoding
possible solution - to feed first frame twice to decoder?
oh, and as i've heard, 5.1 aac decoding is broken in eac3to after 3.0.1 version, but it's probably nothing new with it
/just sayin'

[Music Fan]

eac3to + Nero Audio Decoder (Nero 7) are dropping first aac frame on decoding. always. along with faad. ffmpeg & Nero AAC Decoder 1.5.1.0 are doing it correctly.
Did you also try neroAacDec alone to see if the first aac frame is dropped ?