2.4.1.0 Preview layer break buggy

[LIGHTNING UK!]

That's probably just directshow's doing?

 

Try turning the 'don't use overlays' option on in the setting and see if that's any better.

 

As I mentioned previously, I'm stepping though this frame by frame in the capture and what you're describing isn't happening here. It sounds like it should be really obvious but it isn't to me.

[blutach]

I won't know for some time whether this somehow affects burning/playback of the DL discs at the layer break

How could it? It is simply a previewer (an adaptation of DVD2AVI) - it does absolutely nothing to your video files. If you are happy enough with them to burn them, then nothing will change.

 

i.e. my confidence is somewhat lowered by the *glitch*.

This is totally absurd. I think you are trying to find fault where none logically exists. Be happy that you have a preview with audio.

 

Regards

[JohnnyBob]

That's probably just directshow's doing?

 

Try turning the 'don't use overlays' option on in the setting and see if that's any better.

 

As I mentioned previously, I'm stepping though this frame by frame in the capture and what you're describing isn't happening here. It sounds like it should be really obvious but it isn't to me.

Yes, it appears to be a DirectX phenomenon. If I check that box in Irfanview settings as you suggest, it replaces the *glitch* with a black screen for the first 0.5 second, after which everything is normal. I can accomplish the same thing by disabling DirectDraw Acceleration using the C:\WINDOWS\system32\dxdiag.exe system utility. I'm running DirectX Version 9.0c (4.09.000.0904). I'll check to see if my 5-year-old computer can handle an update.

 

Note that I've revised my estimate of the duration of the *glitch* from 1/5th second to 0.5 second. This is due to introduction of a trusty stopwatch ordinarily used to time sporting events such as the 100 meter dash (or 100 yard dash on this side of the Atlantic). After repeated tries, it's fairly clearly 0.5 second (plus or minus 0.1 second), or fairly close thereto.

 

I've been frustrated in my attempts to capture the preview screen during the *glitch*, or indeed at any time. I can only get a black box with utilities such as Irfanview and Gadwin's PrintScreen, perhaps another peculiarity of my 5-year-old computer which has no separate video card (only shared memory)(?). The BMP button on the ImgBurn preview screen works fine to save a BMP, but I'm not quick enough to hit it with my mouse during the 0.5 second that the *glitch* is onscreen at the start. I wonder if there's a keyboard equivalent to pressing that BMP button?

 

blutach: Sorry, no offense intended. I was trained as a scientist so am simply making impartial observations, as I see it.

[LIGHTNING UK!]

I usually find the 'Print Screen' button works quite well

 

That won't work when overlays are enabled though

 

I wonder if the black screen isn't just it seeking to a decent start point.

 

It lets you stop playback anywhere you like but it must search for something before playback begins. That might have something to do with syncing the audio? I no expert on the previewer or its code.

[blutach]

If you were trained as a scientist, you'd know that your files have not been touched. 1/2 second is one GOP (Group of Pictures). It's probably, as LUK says, your 5 year old machine with no video card trying to find the frame. Live with it.

 

Regards

[JohnnyBob]

.

[LIGHTNING UK!]

I'm more interested in the one with directshow overlays disabled - at least it rules that stuff out then!

 

Just to get it straight though, when you 'seek' to a position (either via the buttons or the slider), does the preview window not show the correct frame?

 

Then when you press play the frame goes from being 'right' to being 'wrong' (a squashed section of the screen as shown in your first pic) before then being 'right' again and displaying properly as per the bottom pic?

[JohnnyBob]

Thanks for your continued interest. It sounds like you don't understand when my *glitch* happens. Sorry. I'll try to explain it again. The following are true statements, as precisely as I know how to word them, and will hopefully clarify everything...

 

(1) The above *glitch* as depicted in my graphic only happens when I press the Preview Selected Cell button.

(2) I do not see it at any other time.

(3) It only happens once.

(4) It does not happen again unless I press the Preview Selected Cell button again.

(5) If I use the slider bar or VCR controls (<< < > >>) followed by the Play button, the *glitch* does NOT appear.

 

Did I clarify it?

Edited April 11, 2008 by JohnnyBob

[Cynthia]

Did I clarify it?

 

I'm more interested in the one with directshow overlays disabled - at least it rules that stuff out then!

 

Did you try to see what happens if you have that setting disabled?

 

[mmalves]

The problem that JohnnyBob describes also happens to me, and only when using DirectDraw Overlays. If you disable DD overlays it works OK.

 

LUK, what's that preview_return.tcl file that ImgBurnPreview.exe leaves in the Temp folder? Is it supposed to do that?

[Cynthia]

This is what's in my preview_return.tcl file.

 

# Title: VTS_01, PGC 1, Chapter 13, Cell 12 & 13 (01:02:35)

set preview_break false

set absolute_lba 1757683

 

[blutach]

@mmalves - It's a temp file that's part of the preview - been there since day 1 of PgcEdit preview. You can safely delete it or just leave it.

 

Regards

[Cynthia]

tcl = Tool Command Language (pronounced "tickle"), a simple textual language used for sending commands to text editors, debuggers, and shells.

[LIGHTNING UK!]

Ok, here's another one based on the code I got from jeanl lastnight.

 

(attachment removed)

[JohnnyBob]

Ok, here's another one based on the code I got from jeanl lastnight.

 

(attachment removed)

I tested it with the LBs from a half-dozen long movies. Alas it doesn't have any effect. My *glitch* remains.

 

I burned several DL discs overnight and tried to ignore *glitch*, but found it too disorienting. So at this point disabling DD overlay seems best.

 

FWIW, maybe irrelevant, I found some trialware that will capture ActiveX graphics onscreen: ACA Capture Pro. In other words, it works with the DD overlay active. However it won't capture my *glitch*. It ignores it, even when the capture hotkey is clearly pressed while *glitch* is onscreen. Instead, it captures the bottom image in my duo-graphic above. So it's as if *glitch* doesn't exist.

Edited April 18, 2008 by LIGHTNING UK!

[mmalves]

It's still there for me too. If you guys aren't seeing this then it's probably a video driver bug/limitation.

[Cynthia]

The problem that JohnnyBob describes also happens to me, and only when using DirectDraw Overlays. If you disable DD overlays it works OK.

Works ok if DD Overlays setting is disabled on my 10 year old ME computer, with built in graphic card.

 

[blutach]

I have no gliitch and am using DD overlays. In any event, we are talking about 1/2 second of video - does that not enable the user to set the LB? C'mon now!

 

Regards

[LIGHTNING UK!]

I didn't expect my latest release to fix your *glitch*, but it probably did fix a few other little things.

[LIGHTNING UK!]

Ok, here's 1.1.3.0.

 

I had a little look at why it might be moving and I think it's because the window is initialised in the top left corner of the screen and then gets moved later on. I've tried to move it sooner now but as I never noticed the problem in the first place I don't know if it'll be any better or not!

 

This one also includes a 64k read buffer so it should play ok from optical drives now.

 

I also made the info window default to snapping to the top left corner of the main window rather than popping up at 400 x 400!

 

(attachment removed)

[mmalves]

//edit: at least for me the *glitch* is gone

[blutach]

And mine says English (Australia) Perhaps it just take the language settings from your machine

 

Regards

[JohnnyBob]

Ok, here's 1.1.3.0.

 

I had a little look at why it might be moving and I think it's because the window is initialised in the top left corner of the screen and then gets moved later on. I've tried to move it sooner now but as I never noticed the problem in the first place I don't know if it'll be any better or not!

 

This one also includes a 64k read buffer so it should play ok from optical drives now.

 

I also made the info window default to snapping to the top left corner of the main window rather than popping up at 400 x 400!

 

(attachment removed)

Re your new ImgBurnPreview.exe 1.1.3.0 version, I've now tested several layer breaks in assorted movies on my hard drive...

 

My "glitch" is partly fixed. There is no longer a shift from the top left quadrant to the whole preview window. The preview opens and plays entirely in the whole preview window, start to end, after rewinds, etc.

 

There is still a 0.5 seconds (approximate) freeze of the video at the start, right after the Preview Selected Cell button is first pressed. If that freeze is by design (intended), personally I would prefer that it be removed.

 

----------------

 

However a new bug is introduced...

 

The < button (Rewind 1 video frame) is associated with a new bug. The other controls in the preview window (<<, >, >>, slider bar, etc) do not have this bug associated with them.

 

After clicking the < button (one or more times), followed by the Play button, there is a fatal freeze of the preview window. All controls become inactive, the video stops and won't play, etc, nothing works. To escape the freeze, I must click the 'x' (Close) button at the top right of the preview window. That brings up the attached error message graphic. Selecting End Now closes the preview window, and everything behaves normally thereafter.

 

----------------

 

I also noticed something else, I think, but it needs further research... I thought the << Fast Rewind button was supposed to rewind 10 seconds. It doesn't, if pressed immediately after the Preview Selected Cell button. In that case it goes back to the layer break position, where the preview first started playing. Thereafter and in general the << button may indeed rewind by 10 seconds.

 

----------------

 

My other observation [which might not be relevant(?)] is that ImgBurn.exe and ImgBurnPreview.exe are using Normal process priority. I'm surprised, and thought AboveNormal priority (at least) would be used.

[blutach]

Confirm the bug on < and the not responding - probably related to the earlier bug. I do not have the 1/2 second wait to start (or glitch).

 

<< / >> is not 10 seconds and never was. IIRC, it is fixed at 6 GOPs (about 3.5 seconds), while < / > is 1 GOP (very fine tuning - about 15-18 frames).

 

What was 10 seconds (and now isn't) is that cell 1 displayed for 10 seconds (IIRC) and then cell 2 in its entirety (with a 1 second break to honour the non-seamless flag, if any). Now, cell 1 is there in full - which I don't think LUK intends.

 

Why would you want it above priority? I sure don't want my machine taken over by the preview. In read/write and verify modes, you can set the process priority (high is the default for write/verify and normal for read).

 

Regards

[LIGHTNING UK!]

Cell '1' (cell before the LB) has always been there in full, the previewer just jumps in at the 2nd of the two though.

 

I'll look into the step back issue.