Jump to content

2.4.1.0 Preview layer break buggy


JohnnyBob

Recommended Posts

  • Replies 70
  • Created
  • Last Reply

Top Posters In This Topic

Ok, try this one...

 

(attachment removed)

I agree with blutach. The < bug has been fixed. I tested it fairly extensively. It's OK now.

 

I can use this latest version reasonably OK to select layer breaks, with only minor quibbles remaining...

 

There's still a short freeze of the video at the beginning of the preview, after pressing the Preview Selected Cell button. I don't think it's as long as 0.5 seconds anymore. It's now shorter, maybe 0.1-0.2 seconds, but still noticable.

 

Things are a bit sluggish, in general. Like after pressing the Preview Selected Cell button, there's a 1 second-or-so delay before it takes effect and the preview begins playing. Then if a control such as << or < is pressed, there's also a 1 second-or-so delay before it takes effect. But there's no delay with repeated presses of a control button.

 

The preview video is a bit streaky, with horizontal black lines, when motion is involved. This might be a compression artifact, as if it's being over-compressed. It's still quite legible, just not very pretty.

 

I'm getting happier with this, and could settle for it.

Edited by LIGHTNING UK!
Link to comment
Share on other sites

Might also be a function of your video card JohnnyBob.

 

And yeah, it can take a short time to display after moving things around (eg the slider a long distance), but again, remember, it is a previewer, not a player.

 

@LUK! - God knows what I am thinking of then. If I figure it out, I'll pipe up.

 

Regards

Link to comment
Share on other sites

I had a go at speeding up the '

 

It's quite noticable when previewing from slow media - i.e. direct from an optical drive.

 

The real reason for the delay is that when you press those , >> buttons and the video is playing, the program defaults to playing all the buffered data (note: this is nothing to do with my recently added 64k read buffer - which is now 32k btw). I've told it not to do that now so you should find it's much better. :)

 

(attachment removed)

Link to comment
Share on other sites

I had a go at speeding up the '<' button response times by performing less reverse seeks and more sequential reads.

 

It's quite noticable when previewing from slow media - i.e. direct from an optical drive.

 

The real reason for the delay is that when you press those <<, <, >, >> buttons and the video is playing, the program defaults to playing all the buffered data (note: this is nothing to do with my recently added 64k read buffer - which is now 32k btw). I've told it not to do that now so you should find it's much better. :)

Yes, that improves the responsiveness of the control buttons and operations considerably, which is now "good enough" in my opinion.

 

However there is now a slight rewind at the beginning of the preview. It's only noticable if it begins with a scene that has fast action. The motion is reversed (rewound) very briefly, for perhaps 0.1 second, then continues forward normally. This could be interpreted as a brief freeze if the beginning scene has no fast action. Perhaps that was the case in prior version(s) and I didn't notice it(?).

 

The black horizontal lines remain, especially noticable on white/light color objects/images, which have jagged edges when they're in motion. You interpreted this as possibly an interlacing effect.

 

Charlie Chan say: Remember ancient zen teaching to leave a little imperfection lest the gods get jealous. :teehee::geek::lol:B):):D

Link to comment
Share on other sites

Just been kinda following this to see what happens in the end, but I was curious on one thing. The file size between the one that came with the software and this one is > 200K. Were the changes that needed made that huge, or is there some processing that gets done in the production version like compiler options or compression of the exe that wasn't done accounting for the difference?

Link to comment
Share on other sites

I thought the ImgBurn one had always been about 200k?

Even with the bigger ImgBurnPreview.exe (468 KB vs the original 209 KB), the entire ImgBurn installation folder in windows is only 2.16 MB total. That's an amazingly efficient coding and design IMHO! So I don't believe it's important, unless perhaps as an indicator of a possible compiler problem - but Blutach negates that with the info that Linux was included in the latest version. Well, I don't really know, but am just trying to summarize...

Link to comment
Share on other sites

Ahh oops, it seems I rar'd up the non upx'd version.

 

This one is back to ~210k again :)

I seems to work exactly the same as the bigger version, except perhaps the black horizontal lines through the video (whenever there is motion) are more pronounced.

Link to comment
Share on other sites

lol I didn't change anything just upx'd it.

 

Placebo testing is fun, I should do it with ImgBurn :)

 

Ought to do it with your Beta group to see what new bugs they find or see if they think everything is ok...hehehe. Yeah, I figured it was a UPX thing or something, Borland created pretty decent size exe files from what I've seen...PowerBASIC is about the smallest I know, and of course M$ creates the biggest and still requires other files to run. Not complaining about the size though, much better than Nero's 330MB Nero 7 they force us to download now with every language known to man. I spent yesterday afternoon extracting all files from it, removing the Helpbar virus they force us to include and monitoring what files it uses for English. I deleted all files it never accesses/uses and tried making a smaller version, but somehow it detects they are not there without accessing them and won't even run the install.

 

Needless to say I'm very happy to have found ImgBurn. I used the heck out of the fixed Optimised feature last night saving like 300MB of space on each disc. Love the new warning of "Argh! Too many Duplicate File messages!" What count is it that it gives up on? Having that in the ISO Name warnings when enabled would be cool too if not there already. Sometimes I turn that on when I want to name files on my disc better. Still testing to see if by Branch or by Level file grouping is better on a few discs that seem to jump around a lot and slow down installs...perhaps one of those with the optimised setting will speed them up.

Link to comment
Share on other sites


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.