Last/first frame in every scene not correctly displayed in WIN8.1

junafriikki wrote on 8/21/2014, 3:00 PM

Already sent this question (friikki22) to Magix Forum (in English), but somehow I can not see English forums replies - only German... Maybe because I have registred myself on German site first and forum thinks that I'm German - not true - live in Finland.

[edit] OK. Now my first question is deleted from German site. Hopefully someone can help me with this question.

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

Have been using Movie Edit Pro 2013 since Jan. 2013 in my HP ENVY 1443eo WIN8.1 64 bit desktop computer. I mainly edit only HDV material captured from Canon HV30.

The (only) annoying thing is that on the movie time line captured from camcorder in every scene the last frame of a scene is the same as the first frame of next scene. Pls see image captured from (HP ENVY WIN8.1) screen.

I thought this is simply "a thing" you must live with, but now I have tested MEP2013 in a Lenovo 410 laptop which runs WIN7 64 bit. Here the last/first frame are correct (!).

The funny thing is that this error appears only in WIN8.1 environment. If I open the (WIN7) captured project/movie files in WIN8.1 this error pops up. I assume that the WIN7 produced files are ok, but somehow MEP2013 in WIN8.1 makes this funny glitch while opening the project files.

I do not know if Magix is aware about this error. I have installed all available patches. My (latest) version of MEP2013 is 12.0.4.2.

I would be pleased to hear if other WIN8.1 users have noticed the same error - or is it something (mysterious) to do with CANON HV30 HDV files.

---

From early history -- 2010:

Have noticed same error (1 frame glitch) already with my previus MEP 14 (in my old XP computer). In fact I asked this question on Finnish Digivideo -forum and got reply that the same thing has been noted with HV30 and Pinnacle Studio (version?) combination. Then I also tested if this happens with MEP16 (evaluation version) - and yes - there it was.

So probably HV30 firmware includes this famous "1 bit error" built in. All sw people know this phenomen.

The most funny thing is error does not appear in MEP2013 & WIN7.

Comments

Scenestealer wrote on 8/28/2014, 6:25 AM

Hi

How have you created the individual scenes in the timeline, from the large continuous HDV capture file? Is it by scene detection after dragging the captured file to the timeline? If so have you tried playing with the scene detection sensitivity slider in the scene detection window?

Or are these takes that have been stored in the takes folder and brought back to the timeline.

Just a long shot - have you tried running MEP in "Compatibility Mode" for an earlier version of Windows from within 8.1?

Ss

Last changed by Scenestealer on 8/28/2014, 6:25 AM, changed a total of 1 times.

System Specs: Intel 6th Gen i7 6700K 4Ghz O.C.4.6GHz, Asus Z170 Pro Gaming MoBo, 16GB DDR4 2133Mhz RAM, Samsung 850 EVO 512GB SSD system disc WD Black 4TB HDD Video Storage, Nvidia GTX1060 OC 6GB, Win10 Pro 2004, MEP2016, 2022 (V21.0.1.92) Premium and prior, VPX7, VPX12 (V18.0.1.85). Microsoft Surface Pro3 i5 4300U 1.9GHz Max 2.6Ghz, HDGraphics 4400, 4GB Ram 128GB SSD + 64GB Strontium Micro SD card, Win 10Pro 2004, MEP2015 Premium.

junafriikki wrote on 8/30/2014, 8:19 AM

Thank you for your reply,

In most cases I do not use takes folder at all.

Usually I do scene detection on timeline after capture using slider in position 5.0. Today I made an experiment with WIN7 and Win8.1 - the same file in both computers. For HDV capture I used my old (and good) WIN XP Mediacenter -- because HDV capture does not work in WIN8.1. This time I used the "Edit after recording ..." option for scene detection after capture (in capture window).

Results:

File opened in WIN7. No errors:

But the same file opened in WIN8.1 still creates this last/first frame error:

Strange??

Just checked what happens if I run MEP2013 in WIN7 compatibility mode. No effect. WIN8.1 still makes this 1 frame glitch.

-- Forgot to mention that if I use timeline - scene detection (WIN8.1), then during the detection process the last/first frame are correct - but later on timeline the first/last frames are incorrect.  Funny?!