Ah - you replaced your prior reply...
So you don't need the 500MB sample I just finished uploading?
Quote:
Originally Posted by neuron2
OK, I found the bug that causes the parsing to be different when timestamp logging is enabled.
|
Does this mean, given my description of the stream, that the 'timestamp enabled' case is the INcorrect case?
Quote:
|
Were there any other DGIndex issues you are pointing out to me?
|
I'm not sure. As I indicated, when mpeg2repair parsed the stream it only found 12 bad audio frames. When dgindex extracted the audio, the resulting file was reported as having MANY more than 12 bad frames by delaycut. Further, in many of those cases, it recovered by 'rewinding 170 bytes' to find the ac3 frame sync word. I note the TS packet size is 188 bytes, and wonder if there is a relationship - like hypothetically, did dgindex extract the payload from a ts packet and put it in the ac3 file that it should not have? Or is this perhaps simply related to the parsing error you just fixed?
{Edit:} Hmmm. think I got that backwards. delaycut reports a crc error, then needs to rewind from where it expected to find the next frame; so perhaps dgindex dropped a ts packet, thus producing the crc error and causing delaycut to have to search backwards. hypothetically...{end}
AS AN ASIDE - Based upon your experience, does my description of the video characteristics sound like perhaps this has been subjected to a dgpulldown-ISH process? I note that mpeg2repair reported 273148 frames vs the DGindexed source (with 'honor pulldown flags' selected) reporting 319959.
273148/319959 ~=.85 , 25/30 ~=.83 - Just coincidence? Is that perhaps why mpeg2repair reports 'unexpected tff/rff flag change' all through the file?
Thanks in advance...