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. |
12th November 2015, 22:56 | #13621 | Link |
Registered User
Join Date: May 2009
Location: Belgium
Posts: 1,744
|
I don't really understand your reaction because as your program is supposed to decode HDCD, and if you are curious about all that stuff (and I guess you are, otherwise you wouldn't have created this tool), you should be happy to learn these things and maybe thank people who take time to understand how your tool handle a particular format and make research about it.
People who use your program deserve to know its limits which should be clearly mentioned on this topic or in the help of eac3to. |
12th November 2015, 23:04 | #13622 | Link |
Registered User
Join Date: Sep 2006
Posts: 2,197
|
eac3tos was created to be able to decode/deal with HD movies and their audio tracks. HDCD is not really part of that.
__________________
Laptop Lenovo Legion 5 17IMH05: i5-10300H, 16 GB Ram, NVIDIA GTX 1650 Ti (+ Intel UHD 630), Windows 10 x64, madVR (x64), MPC-HC (x64), LAV Filter (x64), XySubfilter (x64) (K-lite codec pack) |
13th November 2015, 23:58 | #13623 | Link | |
Registered User
Join Date: Apr 2014
Posts: 32
|
Beware of libDca
Quote:
In the case of the US release of "Ex Machina", the libDca decoder produces bad clipping and with the German release of "Still Alice", it produces white noise on all channels instead of the movie soundtrack. Here you can see three times the left channel of the "Ex Machina" 7.1 DTS-HD MA source - 1. processed with eac3to and decoded by the ArcSoft decoder (1.1.0.7), 2. processed with eac3to and decoded by the libDca decoder and 3. processed with MakeMKV and decoded by the libDca decoder. The first waveform is clipped as well, but this is most likely already contained in the source - the usual nowadays mastering stupidity. The second and third are identical, so it's obvious whose fault this is. Maybe I missed something but did anyone actually test that libdca crap before deciding to use it? Same question to the MakeMKV developers which seem to have fallen into the same trap. At least, eac3to can be forced to still use the ArcSoft-decoder. |
|
14th November 2015, 00:10 | #13624 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,347
|
You should first stay calm and not result to insulting peoples hard work in providing a free and open decoder for a format thats been hard to handle completely for a long a time.
Of course its tested, but not every edge case can be thoroughly covered without access to every single disc on the planet, and if the source has baked in clipping, it could result in all sorts of problems - like this. Clearly clipping behavior can be improved by simply flat-lining the clipping instead of overflowing it, but I even saw a change related to that in newer libdcadec versions, so maybe its already resolved, just eac3to not updated yet. On top of all that, if you can provide a short sample that illustrates such a problem, the developers will likely be happy to investigate and resolve these issues.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
14th November 2015, 00:17 | #13625 | Link |
Registered User
Join Date: Sep 2012
Posts: 366
|
EAC3To should probably detect that and then run a second pass to normalise it, something that's probably not possible with Arcsoft.
libDcaDec is open source so can be modified, maybe to output 32 bit. But the problem in this case is obviously in the audio stream itself. |
14th November 2015, 00:36 | #13626 | Link | |||
Registered User
Join Date: Apr 2014
Posts: 32
|
Quote:
Quote:
If a decoder doesn't reproduce the original data of a losslessly encoded source, then it's faulty. There is absolutely no tolerance to that. Quote:
I'm certainly willing to contribute here, otherwise I wouldn't take the effort to compare and make screenshots. |
|||
14th November 2015, 00:49 | #13627 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,347
|
Quote:
The problem in your screenshots is a simple one really. The decoder decodes the signal perfectly, its just that the decoded signal does not fit into the defined integer range and instead "wraps" into negative (just how integers work, too high positive numbers suddenly turn negative). You can actually see the waveform "continue" in the negative - which clearly sounds terrible, but it gives us strong hints to whats going on. So, the answer is instead of decoding it "perfectly", to actually clip the signal after decoding, so you get flatlines instead. Unfortunately a lot of information about DTS-HD MA has to be reverse engineered or "guessed" based on the behavior of other decoders, like ArcSoft. So in short, the best we can do is "lossless to ArcSoft", or any other reference decoder, since thats the only data points we have (unless someone can encode something with such a problem and provide the original PCM) Clearly this is a bug, and should be fixed, but I find it important to clarify a bit on how it came to be. Anyway, like I mentioned earlier, a change was already performed in libdcadec to perform more aggressive clipping, which may just handle this particular sample already. If you can cut a small segment with the problematic areas from the two Blu-rays you have been having issues with, we can make sure, and/or get them fixed - and test losslessness to ArcSoft after any potential fixes. Its everyones goal here to provide proper "lossless" decoding on all sorts of broken samples, of course.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 14th November 2015 at 01:05. |
|
14th November 2015, 01:29 | #13628 | Link | |
Registered User
Join Date: Apr 2014
Posts: 32
|
Quote:
But let's leave source-clipping aside and have a look what libDca does to the calm and innocent intro of "Still Alice" instead. Regarding the test files, I'll send you a PM shortly. |
|
14th November 2015, 01:32 | #13629 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,347
|
That one sure is weird. Will be interesting to see.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
14th November 2015, 01:36 | #13630 | Link |
Registered User
Join Date: Jul 2011
Posts: 19
|
Ex Machina has a new codec called DTS:X (not to be confused with DTS Headphone:X, which is also included on the disc). It is the rival format to Dolby Atmos. Therefore, the DTS-HD MA 7.1 is actually the core track. More info here: http://www.blu-ray.com/movies/Ex-Mac...128113/#Review
Maybe this is the reason libdcadec produces inaccurate results? |
14th November 2015, 01:50 | #13631 | Link | ||
Registered User
Join Date: Sep 2012
Posts: 366
|
Turbo:
Quote:
Quote:
...or is this likely a bug in the DTS encoder suite? |
||
14th November 2015, 01:53 | #13632 | Link | |
Registered User
Join Date: Sep 2012
Posts: 366
|
Quote:
|
|
14th November 2015, 02:02 | #13633 | Link | |
Registered User
Join Date: Sep 2012
Posts: 366
|
Quote:
|
|
14th November 2015, 02:28 | #13634 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,347
|
Quote:
I have let madshi know so he can chime in here. Other software using libdcadec like my own LAV Filters or ffmpeg can decode this file fine.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 14th November 2015 at 02:38. |
|
14th November 2015, 09:33 | #13635 | Link |
Registered User
Join Date: Aug 2010
Location: Athens, Greece
Posts: 2,901
|
Puzzled about this TrueHD sample:
https://www.sendspace.com/file/6cn8ub I tried to convert it to AC3 using eac3to v3.30 source.thd dest.ac3 and the app crashed TrueHD, 5.1 channels, 48kHz, dialnorm: -27dB Removing TrueHD dialog normalization... Decoding with libav/ffmpeg... Remapping channels... Encoding AC3 <640kbps> with libAften... Initialization of the AC3 encoder failed. Aborted at file position 262144. Using eac3to v3.29 source.thd dest.ac3 works fine. TrueHD, 5.1 channels, 48kHz, dialnorm: -27dB thd, 48000, 5.1 Removing TrueHD dialog normalization... Decoding with libav/ffmpeg... Remapping channels... Encoding AC3 <640kbps> with libAften... Creating file "test329.ac3"... The original audio track has a constant bit depth of 16 bits. eac3to processing took 9 seconds. Done.
__________________
Win 10 x64 (19042.572) - Core i5-2400 - Radeon RX 470 (20.10.1) HEVC decoding benchmarks H.264 DXVA Benchmarks for all |
14th November 2015, 11:06 | #13636 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,347
|
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
14th November 2015, 11:22 | #13637 | Link | |
Life's clearer in 4K UHD
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,227
|
Quote:
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
|
|
14th November 2015, 11:54 | #13639 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,347
|
I suppose it is, if its an unmodified version, which it probably is.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
Tags |
eac3to |
|
|