osgZach
12th February 2010, 20:27
This is probably a really stupid idea, but I'm considering ways to automate dupe removal for Hybrid material with shifting patterns throughout the source.
I'm wondering if the following observation is correct.
Let's say I have a group of patterns over a range of frames.
cnccn cnccn cnccn cnccn nnccn nnccn nnccn cncnn cncnn cncnn
etc...
does it stand to reason, that whenever a N match, be it a single N, or consecutive N's are followed by a C match. The last single N match, or the last N in a group of consecutive N matches, will always (or almost always) be the same frame as the C match that is coming in the next frame ?
for example. in (1 to 5 ) CNCCN frame 2 & 3 are most certainly the exact same frame (exlcuding corruption from noise, compression artifacts, combing etc)
and again in the case of a pattern shift in a group ( 1 to 15 ) CNCCN -NNCCN - CNCNN
Frames [2+3] - [7+8] - [10+11 ] should be the same or really close ?
Again, sorry if its a silly question, but it seems my observations of the particular source I am using (the pattern is made up for purposes of this post though) leads me to the same results of reliably being able to detect dupes to decimate in Yatta, while I am stepping through the file manually ( I don't like using pattern guidance as I can still manually step through and find groups that have not been touched, or reported as warnings at all) .
Of course that is monotonous and I am bound to start making mistakes as I try to maintain a consistent speed of work, or my eyes bug out, etc..
However I am toying with the idea of creating a small program that will read the matches in 5 frame blocks (from the yatta project file) and for each block, compare against a dictionary of defined patterns and mark the appropriate frame for decimation in an overrides file, based on the pattern used for the 5 frames its looking at.
That's probably an oversimplified explanation of how it will exactly work though.
It's more of a convenience tool, as even though working in 5 frame blocks in Yatta can be decently fast, automating it further would reduce the time substantially. I am very prone to creating errors all by myself when stepping through the source and hitting various keys to do stuff as it is.
But if this is something that can change based on the source, then obviously I wouldn't want to waste my time.. Unless I can think of a way to quickly identify and adapt to changes of dupe placement within a given group.
Seems sound to me though... Feel free to tear my n00b theory apart though.
I'm wondering if the following observation is correct.
Let's say I have a group of patterns over a range of frames.
cnccn cnccn cnccn cnccn nnccn nnccn nnccn cncnn cncnn cncnn
etc...
does it stand to reason, that whenever a N match, be it a single N, or consecutive N's are followed by a C match. The last single N match, or the last N in a group of consecutive N matches, will always (or almost always) be the same frame as the C match that is coming in the next frame ?
for example. in (1 to 5 ) CNCCN frame 2 & 3 are most certainly the exact same frame (exlcuding corruption from noise, compression artifacts, combing etc)
and again in the case of a pattern shift in a group ( 1 to 15 ) CNCCN -NNCCN - CNCNN
Frames [2+3] - [7+8] - [10+11 ] should be the same or really close ?
Again, sorry if its a silly question, but it seems my observations of the particular source I am using (the pattern is made up for purposes of this post though) leads me to the same results of reliably being able to detect dupes to decimate in Yatta, while I am stepping through the file manually ( I don't like using pattern guidance as I can still manually step through and find groups that have not been touched, or reported as warnings at all) .
Of course that is monotonous and I am bound to start making mistakes as I try to maintain a consistent speed of work, or my eyes bug out, etc..
However I am toying with the idea of creating a small program that will read the matches in 5 frame blocks (from the yatta project file) and for each block, compare against a dictionary of defined patterns and mark the appropriate frame for decimation in an overrides file, based on the pattern used for the 5 frames its looking at.
That's probably an oversimplified explanation of how it will exactly work though.
It's more of a convenience tool, as even though working in 5 frame blocks in Yatta can be decently fast, automating it further would reduce the time substantially. I am very prone to creating errors all by myself when stepping through the source and hitting various keys to do stuff as it is.
But if this is something that can change based on the source, then obviously I wouldn't want to waste my time.. Unless I can think of a way to quickly identify and adapt to changes of dupe placement within a given group.
Seems sound to me though... Feel free to tear my n00b theory apart though.