View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000243||eac3to||bug||public||2014-11-12 04:15||2015-03-10 20:25|
|Summary||0000243: eac3to crashes on DTSHD -> FLAC, but output file is fine|
|Description||When using the ArcSoft library to decode seemingly valid DTS-HD, the program quite often crashes (displaying the error dialog) at the very end of the process, yet the resulting WAV, FLAC, etc is a perfectly healthy file. The major problem here is that when the program is used in a CLI, the dialog blocks any further execution from the terminal because it requires user input.|
|Steps To Reproduce||Simply try to encode a DTS-HD source that ArcSoft does not like (I can provide torrent links if required).|
|Additional Information||I use eac3to in a CLI script, and it does the job just fine - apart from the irritating error dialog that pops up even though we are using a terminal. I understand very well that ArcSoft-related issues cannot be quite solved, and I am not necessarily expecting a fix in this direction.|
What I propose is a switch to disable the error dialog - if eac3to needs to complain, it can do so in STDERR.
|Tags||No tags attached.|
||Please provide a small sample with which the problem occurs. You can try "eac3to source.dts sample.dts -60000ms" to remove the first 60 seconds. In the same way you can remove almost the entire audio file except the very end. This way hopefully you can cut a sample so that only the last few MBs remain which might still produce the crash. Then please zip the remaining few MBs and attach them to this bug issue. Thanks.|
I have extracted the last 20 seconds of the DTS-HD stream using the method you suggested, but that fragment is encoded without errors. The exception is thrown only when I feed in the entire stream (~700MB).
Any suggestions how to proceed?
||That's too bad. Ok, then please contact me via doom9 PM or email.|
I must apologise, my previous note was partially incorrect. When I demux the entire DTS-HD stream it is also encoded without errors (tested only on one file). The ArcSoft decoder dies with an ugly error only when encoding from the original Matroska container in which the DTS stream lives.
||That's kind of weird. What happens if you split the MKV into small parts? Maybe the last one also produces the crash?|
I have uploaded the last 4 seconds of the MKV - it crashes as expected, but the FLAC is not kept (maybe the sample is too short?). I have another one, slightly bigger (~13MB), that also crashes very nicely, and the resulting (and working) FLAC is kept.
||The attached sample should do fine, thanks. It might take a bit until I get to this, though.|
||I have added a link to my note to the other sample, just in case. Thank you for your efforts.|
||3.28 will handle the ArcSoft crash gracefully. Meaning that there will be a proper "red" error message in the console output. This will probably result in the FLAC file always being deleted in such a situation, though.|
|2014-11-12 04:15||tari||New Issue|
|2014-11-12 09:10||madshi||Note Added: 0000673|
|2014-11-12 18:46||tari||Note Added: 0000674|
|2014-11-12 19:02||madshi||Note Added: 0000675|
|2014-11-12 19:06||tari||Note Added: 0000676|
|2014-11-12 19:08||madshi||Note Added: 0000677|
|2014-11-12 19:37||tari||File Added: sample.mkv|
|2014-11-12 19:42||tari||Note Added: 0000678|
|2014-11-12 19:47||madshi||Note Added: 0000679|
|2014-11-12 19:47||madshi||Assigned To||=> madshi|
|2014-11-12 19:47||madshi||Status||new => assigned|
|2014-11-12 19:47||tari||Note Edited: 0000678|
|2014-11-12 19:48||tari||Note View State: 0000678: private|
|2014-11-12 19:48||tari||Note View State: 0000678: public|
|2014-11-12 19:50||tari||Note Added: 0000680|
|2015-03-10 20:25||madshi||Note Added: 0000719|
|2015-03-10 20:25||madshi||Status||assigned => closed|
|2015-03-10 20:25||madshi||Resolution||open => fixed|