Hi there!
I got 2 copies of an mkv encoding and would like to find out which one is the "good" original.
I've let both of the copies first run through
and since this didn't print anything that would have hinted on which one of the files is the good one afterwards throughCode:mkvmerge -o /dev/null input.mkv
but this also didn't give any errors on neither of the 2 versions.Code:ffmpeg -v error -i input.mkv -f null -
Here is the difference shown by a hex-edit-comparator (vbindiff):
Does anybody know of any other way to check the files? I am absolutely certain that they are copies of the same encoding and should be bit-equivalent so one of those versions must be damaged. I am trying to find out which one to delete and which one to keep.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 16 of 16
Thread
-
Last edited by kaefert; 24th Jul 2014 at 04:40. Reason: [SOLVED]
-
Could it be they were muxed using a different muxer, or different version of a muxer?
I'd just open each with MKVMergeGUI and remux them as new MKVs. If MKVMergeGUI doesn't offer any warnings or errors there shouldn't be any problems.
You could try having a look with MediaInfo (switch to either text or html view for detail) or even run them through Bitrate Viewer. -
Extremely rare that an MKV would be an original. Either one or both could be 2nd generation, or later. IOW, you'll never really know for sure.
Scott -
I am absolutely certain that they are copies of the same encoding and should be bit-equivalent so one of those versions must be damaged.
(Only the extracted raw h.264 streams of those two files should match, but they will probably not match the raw input file. )users currently on my ignore list: deadrats, Stears555 -
I guess I didn't say it clear enough. I've got two copies of one file. I know they should be exact copies with no reencoding and no repacking the stream into a new container, simply copie with a file manager. Now somehow they are not the same, and now I'm trying to find out which one is the one that got damaged.
In general, for a "blackbox" binary file this of course is impossible without having a checksum of the known good file to compare against.
But since the file is an mkv video container with one h264 stream and 5 aac streams inside I thought I should be able to find out with video processing tools. The ones I've tried yet and that have given the same output for both "copies" are mkvmerge & ffmpeg (details see first post) and also mediainfo.
@hello_hello Thanks for the hint with the Bitrate Viewer, I'm gonna try that now and report my findings in an hour or so. -
Can you even assume that the "original" is the "good" one?
You could right click the files/properties and check the creation date.
Was one of these files copied from the other, or were they both copied from a third file? -
Could both be the same, only one might have a compressed header. In other words, the mkv container might be the only difference. Try extracting the streams and comparing those instead.
Darryl -
@davexnet sadly, I don't know
@dphirschler my hexeditor screenshot shows a difference with a length of 304 bytes at an Adress 0xE86C4CC0 which translates to ~3718MB though since the address space only allows for 4GB (8 hex digits) and the file is larger than that, this address needs to be interpreted as the result of modulo 4GB. Even so, this proves that the difference is not within the header.
The difference shown in the vbindiff screenshot is the only difference and both files have exactly the same length.
I could not yet find a bitrate scanner for Linux that truly scans the file. I've found a few that give bitrates but I guess they've taken those from metadata since the result is always shown instantaneously. -
If this "bad" copy was the result of copy/paste using Windows Explorer or similar tools, maybe you should run a CHKDSK.
If you're getting this kind of corruption, you may have bigger issues than a bad video file. -
Running mkv validator (http://www.matroska.org/downloads/mkvalidator.html) might show up some problems on one of the files.
users currently on my ignore list: deadrats, Stears555 -
Time spent to manually watch videos and determine if there is a problem - somewhere between 1 and 2x the length of the video. Assuming 1st video copy is OK, he'll have to watch it all the way through to confirm that plus if he finds an error in the second, he can stop watching once he finds it. Reverse the procedure if the 1st video has a problem (ie. stop watching 1st video and watch 2nd all the way through to confirm it's OK).
Time spent asking questions for a miracle answer that means he doesn't have to watch the video - 2 days and counting because he has yet to find the miracle answer he seeks. -
thanks for the hint with the mkvalidator. downloaded and built it, ran it on both version though only got a few warnings and those where the same for both "copies"
WRN0C2: The timecode of the Cluster at 1656835956 is not incrementing (may be intentional)
WRN0C2: The timecode of the Cluster at 4033828443 is not incrementing (may be intentional)
WRN0C2: The timecode of the Cluster at 4116794453 is not incrementing (may be intentional)
WRN0C2: The timecode of the Cluster at 4287650359 is not incrementing (may be intentional)
WRN0C2: The timecode of the Cluster at 5628687571 is not incrementing (may be intentional)
WRN0D0: There are 5430 bytes of void data........................................
Now what I needed would be a way to link the data segmet to the frame (since its only ~300 bytes) it belongs to and maybe try to inspect the frame for any damage. -
Calling mkvinfo (-g for GUI) and enabling all the options under 'Options' might help with finding more details.
Comparing the output of:
Code:mkvinfo -C "Path to file"
If you know some programming you could also parse the raw video files and compare them.users currently on my ignore list: deadrats, Stears555 -
well maybe you can't imagine but actually the last 2 days I did not only wait for your brilliant post but also did a lot of other work. but even if watching the video twice would be quicker, I would not learn anything from it, I prefer this approach thank you.
Also the ~300 bytes damage that seem to exist within the video stream will probably be hard to notice by watching since the damage seems not to be in a fatal spot - otherwise the reencoding attempt (ffmpeg see first post) would already have failed. -
@jagabo wow! thats a brilliant idea! gonna try that tomorrow (and I don't need windows for that, either I'll use wine or avxsynth directly
update: @jagabo --> how do I test the output for non-blank frames?
difference script:
LoadPlugin("C:/Program Files (x86)/AviSynth 2.5/plugins/ffms2-2.20-icl/x86/ffms2.dll")
here = FFVideoSource("here.x264")
there = FFVideoSource("there.x264")
return Subtract(here,there)
[34.4%] 48291/140581 frames, 49.59 fps, 13.80 kb/s, 3.31 MB, eta 0:31:01, est.size 9.64 MB
[34.4%] 48304/140581 frames, 49.58 fps, 13.80 kb/s, 3.31 MB, eta 0:31:01, est.size 9.64 MB
[34.4%] 48317/140581 frames, 49.58 fps, 13.80 kb/s, 3.31 MB, eta 0:31:00, est.size 9.64 MB
[34.4%] 48321/140581 frames, 49.57 fps, 14.05 kb/s, 3.38 MB, eta 0:31:01, est.size 9.82 MB
[34.4%] 48334/140581 frames, 49.57 fps, 14.05 kb/s, 3.38 MB, eta 0:31:01, est.size 9.82 MB
[34.4%] 48347/140581 frames, 49.57 fps, 14.05 kb/s, 3.38 MB, eta 0:31:00, est.size 9.82 MBLast edited by kaefert; 23rd Jul 2014 at 18:51.