Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > General > Audio encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 14th November 2015, 11:54   #13641  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,317
Quote:
Originally Posted by Boulder View Post
Is it possible to build libdcadec.dll outside of eac3to?
I suppose it is, if its an unmodified version, which it probably is.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 14th November 2015, 12:02   #13642  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,070
Yes, it is, but the dcadec interface changed a bit, allowing warnings now instead of errors. Anyway, I'll release a new build with an updated dcadec soon.
madshi is offline   Reply With Quote
Old 14th November 2015, 12:41   #13643  |  Link
Yoshi
Registered User
 
Join Date: Apr 2014
Posts: 30
Quote:
Originally Posted by nevcairiel View Post
I checked a sample provided by Yoshi of this track, and the new libdcadec version produces a bit-identical result to ArcSoft, so as I suspected the clipping issue was already fixed. Just needs an updated version of eac3to with a new dcadec.
Many thanks for checking on this! After you successfully irritated me regarding how lossless lossless can be when dealing with essentially unknown sources (mixes) - what's the consensus, is the nominally correct (identical) PCM-result of libDca and ArcSoft considered to be the true reproduction or not?

The clipping which occurs in the "correct" result is probably already contained in the mix or mastering, isn't it?


@all: since the most recent version of MakeMKV produces the same faulty results, I tried to contact "mike" which seems to be the developer or at least part of the team. Stupidly, I can't register at that forum since my IP range is blocked for some reason which is beyond me.

Just in case, anyone knows if and how to enforce MakeMKV to enforce to still use the dtsdecoder.dll instead of the integrated libDca.
Yoshi is offline   Reply With Quote
Old 14th November 2015, 13:07   #13644  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,317
Quote:
Originally Posted by Yoshi View Post
Many thanks for checking on this! After you successfully irritated me regarding how lossless lossless can be when dealing with essentially unknown sources (mixes) - what's the consensus, is the nominally correct (identical) PCM-result of libDca and ArcSoft considered to be the true reproduction or not?

The clipping which occurs in the "correct" result is probably already contained in the mix or mastering, isn't it?
It seems to be possible to retrieve the audio without clipping by reducing the overall volume in this particular sample, if thats the desired goal is another question.
From what I understand, madshi wants to offer a two-pass option in eac3to to reduce the volume and re-process the file if such clipping issues are detected. It wouldn't be bitexact to ArcSoft or the source, but probably be better than clipping!
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 14th November 2015, 14:00   #13645  |  Link
Yoshi
Registered User
 
Join Date: Apr 2014
Posts: 30
I don't understand this.

This is with that required volume reduction in general.

I'm aware of eac3to's two-pass-feature and understand the requirement for volume reduction depending on the source when downmixing a number of channels into fewer channels than the source since all channels could carry 0dBFS and have to fit into the lower range.

What I never understood is why this is sometimes required when dealing with lossy codecs without downmixing as I don't see the point why I have to reduce the volume just to reconstruct the lossy source.

Now with lossy codecs, you got transformation into the frequency domain and stuff and maybe due to errors introduced by the psychoacoustic model, you might get (intersample) peaks here and there asking for a few additional dB of headroom but why this shall still be an issue with lossless sources is beyond me.

By definition, there can be only one correct PCM result and audio level for any given lossless source. If that clipped, so shall the PCM of course. When lowering the decoded audio level for a clipped lossless source, I would expect the decoded result to clip as well at -x dBFS then, gaining nothing but slightly rising the noise level due to the lower SNR.
Yoshi is offline   Reply With Quote
Old 14th November 2015, 14:08   #13646  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,317
Its probably just a mistake when encoding. Formats like DTS-HD are a bit more complex than a simple codec like FLAC, they have embedded downmixes for stereo and 5.1 and whatnot (and the decoder performs something called "downmix reversal" to get the 7.1 signal), so when all these features are used, its apparently easy enough to screw something up.

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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 14th November 2015 at 14:17.
nevcairiel is online now   Reply With Quote
Old 14th November 2015, 14:22   #13647  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,161
just to confirm, the US Blu-ray of Ex-Machina has indeed a 7.1 DTS:X (+ a DTS:X headphone) track. so this is perhaps why anything else than just extracting the track (well at least if this works as it should) could potentially result in non lossless output as the reis probably no support yet for these kind of tracks via libDAC or arcsoft (unless there are recent updates for arcsoft)

Quote:
Originally Posted by nevcairiel View Post
I checked a sample provided by Yoshi of this track, and the new libdcadec version produces a bit-identical result to ArcSoft, so as I suspected the clipping issue was already fixed. Just needs an updated version of eac3to with a new dcadec.
just asking, does that mean that full DTS:X track processing is possible now with that version? or that just one specific error has been fixed?
__________________
Laptop Acer Aspire V3-772g: i7-4202MQ, 8GB Ram, NVIDIA GTX 760M (+ Intel HD 4600), Windows 8.1 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64)

Last edited by Thunderbolt8; 14th November 2015 at 14:27.
Thunderbolt8 is offline   Reply With Quote
Old 14th November 2015, 14:34   #13648  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,317
There are no decoders for DTS:X outside of the hardware receivers.
Note that such things as "bitexact" don't really apply to concepts like DTS:X or Dolby Atmos, as they are designed to be mixed for the speaker setup of the user, so there is no one correct way to "decode" it.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 14th November 2015, 14:42   #13649  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,161
so if you want to have the full Atmos and DTS:X information from an audio track, the only thing which makes sense is to extract the entire track and bitstream it to you receiver, correct?
__________________
Laptop Acer Aspire V3-772g: i7-4202MQ, 8GB Ram, NVIDIA GTX 760M (+ Intel HD 4600), Windows 8.1 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64)
Thunderbolt8 is offline   Reply With Quote
Old 14th November 2015, 14:42   #13650  |  Link
NikosD
Registered User
 
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,387
@madshi
@tebasuna51
@nevcairiel

Any comments on my TrueHD sample and AC3 conversion ?

Is it a bug of v3.30 ?
__________________
Win 10 x64 (17134.228) - Core i3-4170/ iGPU HD 4400 (v.4963)
HEVC decoding benchmarks
H.264 DXVA Benchmarks for all
NikosD is offline   Reply With Quote
Old 14th November 2015, 14:44   #13651  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,317
Quote:
Originally Posted by Thunderbolt8 View Post
so if you want to have the full Atmos and DTS:X information from an audio track, the only thing which makes sense is to extract the entire track and bitstream it to you receiver, correct?
Yes, you should always leave the track intact. Even if some day a software decoder appears, it'll still be the same deal - you need to tell it how your speakers are setup to mix the extra "3D" audio properly, so it should only do this conversion at playback time, and not when re-encoding.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 14th November 2015, 16:21   #13652  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,070
eac3to v3.31 released

http://madshi.net/eac3to.zip

Code:
* 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
madshi is offline   Reply With Quote
Old 14th November 2015, 16:31   #13653  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,161
whats the relation between the bitdepth switch fix and your re-opening of that topic at dcadec github?
__________________
Laptop Acer Aspire V3-772g: i7-4202MQ, 8GB Ram, NVIDIA GTX 760M (+ Intel HD 4600), Windows 8.1 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64)
Thunderbolt8 is offline   Reply With Quote
Old 14th November 2015, 16:33   #13654  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,379
Quote:
Originally Posted by madshi View Post
eac3to v3.31 released
Thanks, madshi!
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 14th November 2015, 16:37   #13655  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,070
Quote:
Originally Posted by Thunderbolt8 View Post
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.
madshi is offline   Reply With Quote
Old 14th November 2015, 16:44   #13656  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,379
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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 14th November 2015, 16:49   #13657  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,070
Not sure about 3.29, that's too old.
madshi is offline   Reply With Quote
Old 14th November 2015, 16:53   #13658  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,317
Quote:
Originally Posted by Boulder View Post
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 14th November 2015, 16:57   #13659  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,379
Quote:
Originally Posted by madshi View Post
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
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 14th November 2015, 17:09   #13660  |  Link
NikosD
Registered User
 
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,387
Quote:
Originally Posted by madshi View Post
eac3to v3.31 released

http://madshi.net/eac3to.zip

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

It works now.
__________________
Win 10 x64 (17134.228) - Core i3-4170/ iGPU HD 4400 (v.4963)
HEVC decoding benchmarks
H.264 DXVA Benchmarks for all
NikosD is offline   Reply With Quote
Reply

Tags
eac3to

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 16:22.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.