Good day,
I occasionally try to back up DVDs of children's films that have some degree of damage on them. Even after the cleaning, polishing and other manual techniques are exhausted I wondered if it would be possible to have some software recovery options in MakeMKV. Currently after MakeMKV fails a read and all its retries it fails the conversion process. In the same situation I think most DVD player firmware actually reads the subsequent sector and re-syncs allowing a jump, pop or click rather than failing to play the media. I don't know if Bluray players do this, but the I-Frames in DVDs do allow a resync going forward from a bad block (I think).
From a software perspective I think adding the possibility of either replacing the sector with a null sector, omitting it, or even replacing it with a black cell (if that is possible) might allow the data that is available to be recovered.
Is it possible to add suck an option to MakeMKV ??
-- I think it would make a great addition
Also, I have noticed a lot of foreign film DVDs have bad UDF filesystem data but valid ISO filesystem data (often the directory points at different start sectors). It could be useful to have an option to ignore the UDF filesystem and use the older ISO filesystem (I think the DVD players may do this by default). Assuming that MakeMKV doesn't already handle this problem silently of course.
Dave
Error Handling ideas for damaged media
Re: Error Handling ideas for damaged media
Assuming MakeMKV can arbitrarily try to read whatever block it wants to, I can imagine a scheme like eg. n retries on unreadable, then skip ahead q blocks and if that can't be read either, keep skipping ahead until you get a readable block and then continue reading as usual. And then replace all the unreadable blocks with dummy data.
But then the resulting mkv might not be playable. It might need some advanced knowledge of the video codec in order to fill in the dummy blocks with something that won't crash the decoder during playback. Or maybe the codecs are already tolerant enough of data corruption -- when I get file corruption due to signal interference on h.264 PVR recordings it just artefacts and skips ahead over the corrupt data. But maybe that's because the chipset's decoder is designed to handle corruption. Maybe not all decoders can deal with corrupt data so elegantly -- I've been getting data corruption recently on my mkv's (due to USB interface corruption it seems) and LAV video decoder sometimes freezes unrecoverably on the corrupt parts, while on others I can seek forward over the corrupt section and resume playback there.
To get a nice clean solution you probably would need some advanced knowledge of the video codecs, something that is probably beyond the scope of MakeMKV developer(s). Maybe that could be handed off to ffmpeg to repair the file afterwards.
But then the resulting mkv might not be playable. It might need some advanced knowledge of the video codec in order to fill in the dummy blocks with something that won't crash the decoder during playback. Or maybe the codecs are already tolerant enough of data corruption -- when I get file corruption due to signal interference on h.264 PVR recordings it just artefacts and skips ahead over the corrupt data. But maybe that's because the chipset's decoder is designed to handle corruption. Maybe not all decoders can deal with corrupt data so elegantly -- I've been getting data corruption recently on my mkv's (due to USB interface corruption it seems) and LAV video decoder sometimes freezes unrecoverably on the corrupt parts, while on others I can seek forward over the corrupt section and resume playback there.
To get a nice clean solution you probably would need some advanced knowledge of the video codecs, something that is probably beyond the scope of MakeMKV developer(s). Maybe that could be handed off to ffmpeg to repair the file afterwards.
Re: Error Handling ideas for damaged media
It's exactly the player resync behavior that gives me the idea that simple omission may prove to be the best choice.. M2T@ and VOB are essentially stream files and the stream formats (I think) already define resync mechanics based on I-Frames or full frames of some kind.. In theory if you have a damaged DVD/BR stream that was say 4.00 G and you simply omitted the bad sectors it would 'shrink' in size, but if the resync mechanics for the streams could handle it you would (I think) get a 'frame gap' on the video stream and a corresponding audio gap on the audio stream.. the exact alignment of the two would actually depend on the multiplexer of the encoder because that decides how to interleave the actual stream blocks within the package file, but it 'seems' like it could work. Substituting a dummy block would as you mentioned require more knowledge of the current stream frame position/muxing and data requirements and be significantly more complex. Replacing it with a null block is also possible, but you would need to test the decoder/demux/players to see if that was at all useful to do.
The reason I suggested looking at it is implementing and testing is actually relatively easy in the command line binary, and after a testing the outcome with a handful of players it should be easy to tell which (if any) of these options actually works to any degree. At that point the one(s) that are potentially useful could be surfaced in the UI. I suggested the generic options based on blocks rather than any stream specific magic methods because those are much more complex to even try..
The reason I suggested looking at it is implementing and testing is actually relatively easy in the command line binary, and after a testing the outcome with a handful of players it should be easy to tell which (if any) of these options actually works to any degree. At that point the one(s) that are potentially useful could be surfaced in the UI. I suggested the generic options based on blocks rather than any stream specific magic methods because those are much more complex to even try..