An X7 file format bug

[Davidk]

I've stumbled across what looks like a bug in X7 ultimate when processing a project with .mov clips in the timeline. The details follow.

A project was created with a sequence about 12 .mov clips. Nothing special in it - no music, text or transitions, just the basis of an outline of the issues recording thru windows.

Loaded in X7 64bit on my HP laptop, the 1st clip in the sequence played to the end and then the whole application failed; no error or other messages, just an instant reversion to the desktop presentation. Very repeatable. Changing the filetype to .mpg and repeating just produced an file format error when the play button was pressed. So the type was reverted to the original. The original photographer can burn a disk of these using X3, so further investigation seemed merited.

Later and at leisure I tested just the first 2 clips on VS X6, running in x86 mode on both a desktop and the same laptop, and on X7 running in x86 mode on the desktop and in x64 mode on the laptop. The results were:
X6: laptop x86 mode - successful (played both clips Ok and especially a smooth change from the 1st clip to the 2nd); desktop x86 mode - successful 9same result as for laptop.
X7: laptop x64 mode - played 1st clip then application failed catastrophically at change to 2nd clip; desktop x86 mode - played 1st clip then application failed at change to 2nd clip.

I trapped the file properties of both clips - apart from a small variation in duration and thus file size, these were identical. I have only added the the details of the clip that seemed to initiate the X7 failure, here:

Has anyone else encountered this sort of failure? is there a fix or patch?

Davidk

[asik1]

As this is .MOV's related I'll immediately put the blame on QuickTime installation

[BrianCee]

Have you installed service pack 1 David

[lata]

Hi David

There are some issues using Mov and mpeg4 type files, saying that there are a lot of flavours of Mov using a variety of codecs and different properties.

I tried in vane to get Corel to support Mov H264, yes they will work with Video Studio but you cannot render to Mov H264. (maybe VS X8)

So don’t be surprised if some types don’t work.

Al Jimenez had problems with his Mov files, reported to Corel who provided a hot fix via the knowledge base.
It may be worth you applying that fix. Certainly won’t do any harm.

Mov Hot Fix


Brian mentions SP1, that does have some reference to Mpeg4 files, so probably worth installing.

Quicktime, make sure its installed and running the latest version.

[Davidk]

Lots of good checks to do, which I have done.

Application Installation versions
Desktop: X6 is x86, X7 is x86
Laptop: X6 is x86, X7 is x64.

Service pack installations.
Both the desktop and the laptop have X7: SP1, and X6: SP1.

Quicktime Versions
Desktop: version 7.7.5
Laptop: version 7.7.4

For reasons that will become apparent, I don't think Quicktime is the source of this problem.

VS X7 Hot Fix
I am not aware of just when the hot fix was issued - there are no dates on the documentation, and the winzip archive download and extracts all get todays date on them. However, if the hotfix was released prior to SP1, it clearly isn't in that package, as the issue arose with the X7 software updated to SP1.

From Trevor's post I downloaded both the written 'how to do it' page, and both the x86 and x64 zip archives of the hot fix. Note, only for X7.
Extracted the hotfixes and applied them to the relevant versions of the X7 program: desktop: x86, and laptop: x64.

I've not yet been able to check the brand and version of the camcorder that recorded the mov files causing the issue, but I suspect that (even tho Al Jiminez had issues and the Corel hotfix is for a Panasonic GH3 unit) all versions of the same brand would be affected in the same way (by software re-use).

Testing
After the hotfix was installed in the VS X7 version on both machines, the same test sequence was rerun - both machines, the .mov files from the same USB memory stick with the following results.
The test clips were 14 sec (18.9Mb) and 16 sec (19.5Mb) long. The 1st clip mentioned in all these posts is the 14sec clip, but I have reversed the clip order and it made no difference to the result.

Desktop
VS X7: in clip mode, 1st clip ran to the end. In project mode, 1st clip began running, about half way thru the display got bursty and quickly failed catastrophically (killed X7 completely). There was an error box displayed this time as follows:

There was no windows error message. The whocrashed tool on the desktop said that there was no windows dump file for the event.

VS X6: in clip mode, 1st clip ran to the end. In project mode, both clips ran as they should - no bursty performance, smooth transition from 1st to 2nd clips.

Laptop
VS X6: ran properly, same way as the X6 install on the desktop.
VS X7: in clip mode, 1st clip ran to the end. In project mode, 1st clip began running, about half way thru the display got bursty and quickly failed catastrophically (killed X7 completely). No error box this time.

Progressive Conclusions
VS Service packs are up to date on both and VS versions.
No apparent issues with QT on either machine or version; v7.7.5 is the latest version, and both it and v7.7.4 on the laptop were part of installations that failed. The fact that an earlier version exists on the laptop and the effect is not corrected in the latest version clearly implies that QT isn't the cause.
Video Studio X6: runs the .mov files correctly, no issues.
Video studio X7: fails when running the .mov files. The hot fix update did not fix the problem on either machine, and the issue applies to the x86 and x64 versions of the program.

I'll advise when I have more details on the original camcorder. But right now it looks like Corel has induced a problem with .mov files in the X7 version (x86 and x64), and the issued hot fix does not correct it in the samples here.

Davidk

[lata]

Hi David

Are you using the files directly from the usb stick.

If yes.

Please try transferring the files to the pc's hard drive and test from there.

[skier-hughes]

MOV is a wrapper, it can contain one of hundreds of different files made with different codecs.
Codecs are a problem area, the installation order can affect how programmes access the codec, so sometimes a programme can call on a codec to use and be given the wrong codec, as it's superiority in the pecking order has been advanced by when it was installed, or other programmes that use it were installed at a later date, or programmes uninstalled.
This means that comparing two machines is not the most satisfactory way of trying to solve a problem.

[Davidk]

I have no info as yet on the camcorder brand or model number.

An extra version of VS on test
However, the original photographer asserted that he could use these files as normal in his X3 version (in the post above). And since I have X5 ultimate on the desktop (not on the laptop) I ran this little project using that version. No issues at all. So on the same machine: X5 and X6 (both fully up-to-date with service packs) that work, X7 fails.

Running on internal drive
Noted Trevor's remark about running it from an internal drive, rather than a USB stick. Copied the whole project as a smart package to one of them, and repeated the test process on all 3 versions of VS on the desktop. No change in results. X5 and X6 work, X7 in clip mode still has the stuttery effect and in project mode it has both the stutters and then outright failure. This time, there was an error message that enabled me to identify the failing module as ntdll.dll. Which, I note, is a different file from the one the hot fix was issued for.

Repeated this process on the laptop, for X6 and X7. No change in the observed results (stuttery on the 1st clip then fail) but this time on the laptop there was an error message I managed (with a lot of fiddling) to trap.

Running the clips from an internal drive at least seems to have gotten more error data, but did not change the problem: X7 fails, others don't.

Machine variations
Testing on different machines is very useful to isolate what isn't wrong: if a problem is machine dependent, that will show on a different build. If a problem is software dependent, different machines will respond in a similar fashion.

File Types.
Comment from Graham about types as a wrapper is well taken - I recently wrote up a multi-page handout for students on the profusion of video file types that has grown up over the last few years. To say its confusing - compared to the standard DVD days - to every user I know of is putting it really politely. And the variations between those file types are often so minor for little apparent benefit that manufacturers often do not support the sub-classes they represent. Given that sort of economic imperative, one wonders what sort of 'high' the standards committees that define the variations really were on. In this case however, to re-state the issue a different way:
- the .mov files are input and played correctly in clip mode in all versions: the image and audio is quite clear, except when it gets stuttery in X7.
- those .mov files correctly inputted play OK in project mode in X3, X5 and X6. In X7 they play for about (very rough estimate) 7-8sec before getting stuttery and then failing. The failure happens in the 32bit(x86) and 64bit(x64) versions, and on different machines.

Generally if there is an issue with the codec, the application won't load the resulting file in the first place.

So far, the only VS version that won't run these .mov files is X7, and the odds for an X7 bug with .mov files gets to almost a certainty: the only absolute way to be sure would be to find/fix it . . . . .

Davidk

[Davidk]

Sorry, screwed up the image posts in that last post: somehow got the desktop shot as the laptop error message as well, but the laptop error message is at least "attached" at the bottom. Is there a way to edit a submitted post to fix this sort mea culpa?

Davidk

[Davidk]

Since posting the last item, I went looking for the "owner" of ntdll.dll on the desktop system. Reported as the source of the error the one time I got a trap on it. Turns out that file is part of Win7 in the /system32 folder. And there's only 1 of them.

So, if X5 and X6 work on the desktop, and the desktop X7 fails using that module, something in the X7 calling interface may the cause. If X5 and X6 don't use that library, and X7 does, same conclusion.

Davidk

[aljimenez]

David, when that hot fix was documented it had the incorrect instructions for the 32bit folder. The instructions gave the Program Files folder for the 32bit instead of Program Files (86). I hope either they fixed the documentation or since I think you know, you did the correct hotfix dll replacement... Al

PS If you make a copy of the troubling file available, I'll try in my system

[Davidk]

Hi Al,

At least I know one other who had hair in a knot with this .mov problem in X7.

The hotfix doco does say to find and overwrite the ulmp4lib.dll file in C:\Program Files\Corel\Corel VideoStudio Ultimate X7, for both the x86 and x64 versions. However, on installation I exercised the option to install the files in a custom folder - specifically, on a physically separate applications drive in a Corel Video Studio Ultimate X7 folder. So that's where I went to find the file to replace. It's that way on the desktop (x86) and the laptop (x64).

The reason - I really don't like cluttering up the C drive with applications and data if there is an option (some vendors don't bother) to put them somewhere else. All that putting them in the C drive does is make it a general tip for everything and slow the machine down when its looking for things. Microsoft admitted long ago that the C; drive for everything method was a mistake but by that time the horse was out and long gone. As an illustration of the benefit, doing backups is about 4-5 times faster - on a machine with multiple hard drive (the desktop) as compared to the laptop (single hard drive even if it does have logical drives on it) - with this approach because the hard drive seek and access time for OS, applications code and data for both is really minimised. Conceptually, it also helps to separate the OS from the user apps and data.

I can send the package (vsp, and 2 clips total 39Mb) using Filezilla. Where to?

Davidk

[lata]

Hi David

Video Studio X7 was the first version to allow us to set project properties to other formats other than Mpeg2 and DV-Avi

There was some playback issues in using Mpeg4 with the wrong project properties.

Yes I realise your files are Mov, but Mpeg4’s were derived from mov.

Unless I have missed something in your posts I have not read the actual properties of your Mov files.

Try setting X7 project properties to use Mpeg4 as near to the properties of your Mov, especially the frame rate.
The default for X7 will be 25 / 29.97, if your Mov files are using 50 / 60fps could affect playback quality?
By default X7 uses the last used properties for new projects.

You can share the Smart Package, first Zip it, maybe use Drop Box or “OneDrive” the later is part of Windows Live.
Then we can give the files a run.

[Davidk]

The properties of the mov files were described in the first post and in the first image there's a screenshot of the properties panel data on one of them. Apart from duration and thus size, the 2 clips involved in all these tests are the same. The video properties list AVC coding, and the sound tracks lists MPEG-4 (all in the properties panel).

I have uploaded to my OneDrive public folder a zip archive containing 2 clips and a vsp to run them. Because I was using 3 versions of VS to test these, it's created in X5 (and that is in the file name) so all the versions I used (X5, X6 and X7) could open it. The onedrive weblink for access to the archive is:
https://onedrive.live.com/redir?resid=F ... file%2czip

I'm very interested in how these play for others.

Davidk

[Davidk]

Interesting note - the weblink in the prior post was truncated by the forum post software (when I pressed the submit button) where the dots in the link are: which is apparently the access ID and password. If using the truncated link is an issue I have retained the original data and can supply by any means that doesn't cause problems.

Davidk