There is a provision for CRC checksums, but for encoded data only, and even those are mostly useless. There is no way to check losslessness/correctness of the output, as far as I can tell. I could imagine that XLL itself can be checked, but maybe not the final core+XLL combined data? Some of the problems you describe are clear signs of some corruption/misparsing.īTW, does the XLL extension have some sort of CRC check so that dcadec can check if the final decoded result is really bit perfect? I know that TrueHD has such a CRC. Thanks for the samples, I will investigate what's going on. Contained are the original DTS files and ArcSoft decoded WAV files, so you have a reference to compare to. However, several of them failed to decode properly. I'd say about 60-70% of them decoded identical to the ArcSoft DTS Decoder. Then I've run XLL decoding tests, using my XLL sample collection with various format combinations.
#DCADEC DTS DECODER FULL#
However, what should I do for lossy decoding? Is the full 32bit data always filled? In that case I should probably always treat the dcadec lossy decoding results as 32bit PCM, so that eac3to later dithers the data down to the final output bitdepth, correct?
One question: The "samples" buffer always seems to be 32bit? For lossless decoding I suppose I can simply extract the lower 16/24 bit and ignore the other 8/16 bit, correct? That's what I'm currently doing and it seems to match what dcadec.exe produces. Great job, in any case! The dcadec interface is easy to use, and decoding generally looks promising. conversion to FLAC), having some sort of indication whether decoding was perfectly lossless or not would be very helpful. This might not be crucial for realtime playback, but for reencoding purposes (e.g. I could imagine that XLL itself can be checked, but maybe not the final core+XLL combined data? Having some way to check that for lossless-ness would be very helpful, of course, so that users can know if lossless decoding succeeded or not. Upload will take about 1,5 hours, so wait a little before you download:īTW, does the XLL extension have some sort of CRC check so that dcadec can check if the final decoded result is really bit perfect? I know that TrueHD has such a CRC. Everything is fine, but dcadec.exe stops at "Progress: -95%".Decoding runs through without any errors, but the final result doesn't match the ArcSoft decoder.dcadec.exe reports "PCM output overflow".And decoded data is not correct, anymore. libdcadec.dll's dcadec_context_filter() function suddenly changes bits_per_sample from 16 to 14 with one of the samples, when this happens. dcadec.exe reports "PCM output parameters changed".
#DCADEC DTS DECODER CODE#
dcadec.exe reports "Failed to decode block code + invalid bitstream format".Testing your decoder, I've started with simple channel order tests, using conventional DTS files (no HD), testing all possible speaker/channel configurations: All tests passed with flying colors.
0 kommentar(er)
