rboy1 wrote:
Anaylising File>Fast Remuxing(fails)>Slow Remuxing it is at the point Slow Remuxing is started that the corruption is found in the log file?
No it's the general process limitation. You can work around it but it's very complex the way MCEBuddy is designed. Like I said you can do the actual conversion upfront by editing mcebuddy.conf slowremux section, but I've never tried it and can't predict the impact downstream.This is a concern for me, because it means I end up with 30% of my recordings 4x larger in size. It would be nice if there workaround to the corruption isn't implemented in MCEBuddy, to instead fall back to just renaming the file and moving it instead. How do other converters deal with corruption? Why is it that others and playback work, but with MCEBuddy they don't?
how far in can't say, it depends on the file. When it comes across a corrupted set of frames that it cannot recover from it fails the remuxing the falls back to the next level. It depends on the recording.So if we look at the conversion process:
Anaylising File>Fast Remuxing(fails)>Slow Remuxing it is at the point Slow Remuxing is started that the corruption is found in the log file?