Log in

View Full Version : Joining 2 one-pass xvid stats files


cybercla
19th July 2005, 09:13
Hello,
I'm wondering if there is a way to join two one-pass stats files so that the resulting stats file would be the same as if the one-pass would have been run on the inital file as opposed to splitting it up in two first.

Thank you

Koepi
19th July 2005, 10:50
For XviD >= 1.0 I don't know of a tool. You can do it with the old stats-format of pre-1.0 builds with the StatsReader.

I couldn't adopt full statsreader-support other than for "looking" at 1.0 statsfiles (don't know right now if i already implemented conversion) since i lost my sources due to a hard disc crash.

Cheers
Koepi

cybercla
19th July 2005, 11:15
Thank you for the fast reply.

Using Statsreader 2.1 I converted the two one-pass .pass files to .stats then merged the two. Comparing the initial .stats file and the one that resulted from the merge in a hex editor yields some differences (the merged one is also a little bigger than the untouched one). Is that something I need to worry about, or are those differences negligeable?

Thanks

Koepi
19th July 2005, 15:16
The problem is that you need to output the .pass-format again.

I've little time unfortunately, it is simple to write an app that does exactly that. I won't find the time to code that though.

Cheers
Koepi

Didée
19th July 2005, 15:38
Never had to merge *.pass files on purpose, but did it a few times when the 1st-pass had crashed (power failure ...).
In those cases, I searched for the last keyframe in the *.pass file, set up a new 1st-pass that started on that keyframe, and in the end just put both files together with a text editor (ofcourse sparing out the header lines from the second *.pass file).

You could do just the same with a splitted encoding. However, it might be a good idea to also work with some "overlap", to be able to reference a keyframe (perhaps even force one at the end of the first part, through a zone). Else, you might experience the famous "off-by-one" phenomenon (or "-by-two), which can have a *very* negative impact on the second half of the final encoding ...