eac3to - audio conversion tool

[SeeMoreDigital]

Originally Posted by madshi

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]

Originally Posted by GZZ

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

See this post or search this thread to see other answers.

[r0lZ]

Originally Posted by madshi

... the dcadec interface changed a bit, allowing warnings now instead of errors.

Originally Posted by madshi

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 and here.) 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) 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]

Originally Posted by Thunderbolt8

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.

Originally Posted by r0lZ

just to be sure, the option I've requested via your bug tracker (here) 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]

Originally Posted by madshi

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]

Originally Posted by ndjamena

... 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]

Originally Posted by SeeMoreDigital

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

[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]

Originally Posted by nevcairiel

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]

Originally Posted by Yoshi

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:



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]

Originally Posted by nevcairiel

"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.

Originally Posted by 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.

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.

Originally Posted by madshi

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.

Originally Posted by madshi

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?

Originally Posted by madshi

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.

Originally Posted by madshi

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.

Originally Posted by madshi

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]

Originally Posted by Thunderbolt8

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.