Support forum for DG Tools

Hi
I observe lately a strange behavior:
while ripping certain disks, at a point, typically in the second half, the audio is simply short-cut, meaning: it is not long enough; but the video is complete;
the latest example is 'Under the Silver Lake' (DTS streams : eng and ger both are around the same point gone)
https://www.amazon.com/-/de/dp/B07SDKVY ... 247&sr=8-1

when I back-up the disk first into a protected iso (ANYD.D), then the procedure runs ok from this image;

(my theory was, that if the ripping becomes slow (disk errors or intentional mastering errors), then DGDemux maybe assumes wrongly that the stream is done because 'no' data is coming... while the video provides always enough data... wild guess... )

There's no timeout on data or anything like you mentioned. I've ordered the disk to investigate. Sadly, gonna take a few weeks to get it.

Does the same thing happen with other demuxers? DGIndexNV? EAC3To? Others?

Does it happen when ripping with other rippers? Make MKV? DVDFab?

Rocky wrote: ↑

Sun Jan 03, 2021 1:48 pm

...
Does the same thing happen with other demuxers? DGIndexNV? EAC3To? Others?

I will check

Also try other rippers if possible (see my post edit).

Apparently, people either love or hate this movie. I'll probably hate it.

Rocky wrote: ↑

Sun Jan 03, 2021 2:49 pm

...
Apparently, people either love or hate this movie. I'll probably hate it.

, yes, it is on the strange side...

but now: don't be too angry with me...
'false alarm', to some extend... => feature request:
I stepped into the prealocation trap...
I tested with eac3to and MakeMKV (both do work) and reproduced with DGDemux;

but MakeMKV gave me the significant hint:
with all the testings a lot of large files were created, which had to be deleted; they ended-up in the recyclebin without actually releasing the disk space;
MakeMKV warned 'file could be x but disk space is y' and ends with an error message when the disk space is used-up;

DGDemux on the other hand continues to read the disk until the end of the playlist (and reports 'done') but of course stops writing ...

so, I would like to convert this into a feature request:
should the ripped files be incomplete DGDemux should throw an error and delete the incomplete files; or should warn during preallocation;
that is important for automated cli-processes; otherwise one realizes the problem only in the final remuxed file...

again: sorry!

Oy, OK. I won't pop a gasket because you've demonstrated that we need to check all the prealloc's and fwrite's and error out on failures. Thank you for your report and status update.

I've added handling for preallocation failures in slipstream 47. Decided not to error test the hundreds of fwrite's in the code. Maybe in my next life.

Marking RESOLVED.