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. |
14th November 2015, 22:03 | #13661 | 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 |
|
|
15th November 2015, 06:54 | #13662 | Link |
47.952fps@71.928Hz
Join Date: Mar 2011
Posts: 940
|
The updates have been very enterprising lately.
__________________
Win10 (x64) build 19041 NVIDIA GeForce GTX 1060 3GB (GP106) 3071MB/GDDR5 | (r435_95-4) NTSC | DVD: R1 | BD: A AMD Ryzen 5 2600 @3.4GHz (6c/12th, I'm on AVX2 now!)
|
15th November 2015, 11:35 | #13664 | Link | ||
PgcEdit daemon
Join Date: Jul 2003
Posts: 7,469
|
Quote:
Quote:
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. :-)
__________________
r0lZ PgcEdit homepage (hosted by VideoHelp) BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV |
||
15th November 2015, 11:40 | #13665 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
|
||
15th November 2015, 14:42 | #13667 | Link |
PgcEdit daemon
Join Date: Jul 2003
Posts: 7,469
|
OK, it's indeed the best solution. Thanks again. :-)
__________________
r0lZ PgcEdit homepage (hosted by VideoHelp) BD3D2MK3D A tool to convert 3D blu-rays to SBS, T&B or FS MKV |
15th November 2015, 15:22 | #13668 | Link | |
Life's clearer in 4K UHD
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,227
|
Quote:
Cheers
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
|
|
15th November 2015, 15:46 | #13669 | Link | |
Registered User
Join Date: Aug 2002
Location: France, Paris
Posts: 672
|
Quote:
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
__________________
Want to know all about your media files? http://mediaarea.net/MediaInfo Last edited by Zenitram; 15th November 2015 at 16:10. |
|
15th November 2015, 19:09 | #13673 | Link |
Registered User
Join Date: Apr 2014
Posts: 32
|
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? Last edited by Yoshi; 15th November 2015 at 19:22. Reason: Addition |
15th November 2015, 19:45 | #13674 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
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. |
15th November 2015, 21:04 | #13675 | Link |
Registered User
Join Date: Sep 2006
Posts: 2,197
|
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?
__________________
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) Last edited by Thunderbolt8; 15th November 2015 at 21:26. |
15th November 2015, 21:13 | #13676 | Link | |||||||
Registered User
Join Date: Apr 2014
Posts: 32
|
Quote:
Quote:
Quote:
Quote:
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? Quote:
Quote:
Quote:
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. |
|||||||
15th November 2015, 21:16 | #13677 | Link | |
Registered User
Join Date: Apr 2014
Posts: 32
|
Quote:
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 ... Last edited by Yoshi; 15th November 2015 at 21:56. Reason: Addition |
|
15th November 2015, 21:27 | #13678 | Link |
Registered User
Join Date: Sep 2006
Posts: 2,197
|
I edited my post and added another information.
__________________
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) Last edited by Thunderbolt8; 15th November 2015 at 21:37. |
15th November 2015, 22:37 | #13679 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,730
|
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?
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
16th November 2015, 00:26 | #13680 | Link |
Registered User
Join Date: Sep 2006
Posts: 2,197
|
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.
__________________
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) |
Tags |
eac3to |
Thread Tools | Search this Thread |
Display Modes | |
|
|