Problem with Beta 6

[HaroldB]

I don't even know what beta 6 DOES, but when I tried to download beta 5, I got beta 6a.

My problem with it is that it shows certain slideshows differently than 4.0 did. Specifically, the following slideshow segment acts differently... it's as if putting up a new slide with no transition takes (relatively) significantly longer under 4.10 than under 4.0 and therefore the presentation is markedly different for any presentation where lots of slides are put up in very quick succession to work with the beat of quick music.

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

opt_synchpos18=39950

opt_synchpos19=40654

opt_synchpos20=41345

opt_synchpos21=42258

opt_synchpos22=43121

opt_synchpos23=43969

opt_synchpos24=44221

opt_synchpos25=44444

opt_synchpos26=44839

opt_synchpos27=45774

opt_synchpos28=46594

opt_synchpos29=47449

opt_synchpos30=47658

opt_synchpos31=47874

opt_synchpos32=48312

opt_synchpos33=49149

opt_synchpos34=49997

opt_synchpos35=50830

opt_synchpos36=51043

opt_synchpos37=51266

opt_synchpos38=51683

opt_synchpos39=52552

opt_synchpos40=53391

opt_synchpos41=54212

opt_synchpos42=54629

opt_synchpos43=56360

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

Harold

[Igor]

Yes, beta #6 is available! It adds OGG Vorbis support.

Timing in v4.10 should works exactly as in v4.00. I've done many tests and checked up with my presentations.

But I think it happened because there are too small intervals between slides in your presentation (some are only 200 ms., it's a 1/5 of second).

New player takes a little more CPU resources under slow PCs to play mp3 files (10% under Celeron 400), but provides much better sound quality.

However we're continue work on optimization of the playback!

[HaroldB]

Igor,

The small intervals are due to the slides following the beat of the fairly beat-y music.

I ran the WINTOP performance monitor to see what was doing with CPU time, and while WINTOP is obviously not a precise measuring instrument, it seems to be fairly clear that this is not a CPU time problem. Interestingly also, the slideshow seems to repeatedly go out of synch NOT at the slides with the shortest durations.

WINTOP reports four additional threads when running a preview from PTE. Of those four threads, there seems to be one running consistently at about 3.5% of the CPU (I assume that's the music?), so that doesn't seem like it would be detracting significantly. The thread that consumes most of the CPU time seems to peak at about 50% of the CPU during this sequence, which would seem to indicate that this is not a CPU problem. Could it possibly be a program bug? It happens very consistently.

My processor is a 1MH Pentium 3 running Win/ME, so it really shouldn't be very slow at running PTE presentations.

(FWIW, the only time PTE takes almost the whole CPU is when it does fades.)

Harold

[alrobin]

Harold,

What about the transition times - do they overlap the times-on-screen at any point? I find if I leave a little space between the end of the "grey bar" and the start of the next transition, everything works fine.

Of course, large images take longer to process, too. On some of my tests, the processor usage was 100% for several seconds and everything went smoothly, so you are right, it is not just % usage that counts.

I find, too, that "cuts" work more smoothly than short "fades".

[HaroldB]

Al,

In this presentation segment, I am using only cuts (IOW, no gray bars). I've never had problems with that before, and that's why I'm bringing it up as a "problem" with 4.10.

Harold

[Igor]

Harold,

I didn't change anything in the code of preparing slides, but I'll check up for this situation! Please let me know your CPU Mhz, version of Windows, screen resolution and typical graphical size of pictures. And as I understood some slides were skipped during playback of the show or is there a small delay (30.. 50 or 100 ms.) with show of a picture?

Also please try out:

1) How your presentation works in the *Preview* mode (if you press "Preview" button in the main window).

2) When you run READY .exe file.

3) Third test, when presentation will be ran in the "Custmize synchronization" window by the "Play" button. (And you see changing of slides on the area of preview.)

4) And final test. Please convert your mp3 music file into simple uncompressed Wav file and temporary set up it instead of mp3 music.

So it may shows possible delay in the synchronization, because playback of uncompressed WAV music takes in several times lesser CPU loading.

Thanks for testing!

[HaroldB]

Igor,

First, a general comment and then the results for the tests you asked for.

1) Shouldn't the total amount of "work" done on the system not change meaningfully between 4.0 and 4.1? IOW, whatever technique PTE used to play the music in 4.0, shouldn't that ALSO take CPU?

2) The best way I can describe the results of the tests you asked me to do is to say -- interestingly -- that the results were not completely reproducible. In general, it feels that this presentation is running "close to the edge" in 4.10, and it works better some times better than other times. In 4.0, in contrast, every transition was hit at exactly the right time.

Given that, here are my subjective feelings.

The most reproducible timings are when I watch the presentation in the small preview window. Whether I use a WAV file or an MP3 file, the presentation is almost perfectly reliable.

Next most good is the WAV file running from a standalone EXE.

Next most good is the MP3 file running from a standalone EXE. In fact, I wouls judge this as "acceptable", although 4.0 is definitely better.

Next most good is a WAV file running from PTE preview.

Worst is an MP3 running from PTE preview.

You know from the past that I am a big believer that old PTE shows should be able to execute unchanged with newer versions of PTE. The Wintop monitoring indicates that this is not a CPU problem. Perhaps this is some kind of scheduling problem, in the way that the music and display threads (I assume that they are separate threads) are interfacing?

Harold

[Igor]

Thank you, Harold!

I really thoughted that more slower running with "Preview" button may be occured, because I've added some changes. Probably it takes more CPU utilization. Please try this beta #7b with old way of running Preview (as in v3.80 or v4.00): http://www.wnsoft.com/apr_beta1.zip

Concerning usual running of produced .exe file from Windows Explorer.

Best result with WAV when you run .exe file shows that in your case it depends on CPU usage. Wav playback takes in several times lesser CPU load than MP3 playback.

Excellent result on the time-line when you pressed Play button is explainable. Because pictures in the small preview area are loading with scalable optimization (lesser graphical preview takes lesser CPU time than showing of full graphical size (e.g. 1024x768).

If you temporary replace them on smaller pictures you'll see that each picture will be shown exactly at specified time.

Please however let me know your CPU, version of Windows and average graphical size of a pictures.

p.s. I forgotten to ask you about one more moment.

Has your presentation *at least one* transition effect

or all slides use only quick transition?

[HaroldB]

Please try this beta #7b with old way of running Preview (as in v3.80 or v4.00

This version of preview works much better. The preview and the run of the EXE are now virtually indistinguishable. But (see below) they both still have a definite problem.

Has your presentation *at least one* transition effect

or all slides use only quick transition?

Yes, it does have other transitions before this show segment. However, the problem occurs when this show segment is previewed from the middle with no prior transitions, too.

Please however let me know your CPU, version of Windows and average graphical size of a pictures.

I'm running Win/ME on a 1mh Pentimum 3, and the pictures are all 1024x768 resolution, compressed so that they have an average file size of between 100-200K.

I've spent a bunch more time with this and I am really convinced that this is not a CPU problem, at least not in the sense that CPU is at 100% and unavailable.

Using the 7b beta, the small preview picture in the synch window is also off, although much closer to 4.00. However, both the preview and the EXE are off by quite a bit more.

I used Wintop to watch CPU for execution of the 4.00 EXE. It seems to run in 8 threads. There seems to be a main thread that gets the bulk of the CPU, and another thread that gets about 1.82-2.5% of the CPU. Two other threads get some very small amounts of CPU.

I then used Wintop to watch CPU for execution with the 4.10 7b beta EXE. It seems to run in 4 threads. Again, there seems to be a main thread that gets the bulk of the CPU, and another thread that gets 3.5-4.2% of the CPU. The two other threads get less than 1% of the CPU each.

I'm assuming that it's the music thread that had doubled in CPU use. But notice that even though it has doubled, it is still quite small in CPU consumption.

More importantly, the TOTAL CPU is almost always less than 50%. To me this seems to mean that this is not a CPU problem, because there is CPU available to execute instructions that is not being used.

Also, if it were a CPU problem, I would expect the slide after a really short transition to be the worst. In my example, slide 27 is 84K and is on the timeline at 44.839 seconds. Slide 28 is 185K, and is on the timeline at 45.774 seconds. Surely, that should be no problem, yet slide 28 appears noticeably "late" during the show, EVEN in the small preview box in the synch window.

I think the reason that this problem might be more noticeable in this show is that there are a lot of rapid transitions set to very beat-y music. So if PTE is off by some very small fraction of a second, it would be much more noticeable than in a more typical show.

I then did a test which I think conclusively proves that this is not a CPU problem. In the synch window, I adjusted slide 28 to come in 200 milliseconds earlier on the timeline -- and it worked just fine both in the small box and in full-screen preview mode!! If it were a CPU problem, adjusting it earlier shouldn't have helped, right? What I get is exactly the same show playing differently on 4.0 versus 4.1, and I can adjust the timeline in 4.1 so that it plays the way 4.0 plays without adjustment. That shouldn't happen!

So I think that there is SOME sort of problem with the new PTE synching to music. It's off by a little, but that "little" is very noticeable in beat-y music with lots of transitions.

Harold

[JRR]

Harold:

I was going to e-mail you off-forum, but it seems I can't.

I have followed (somewhat as it is going over my head to a certain degree) but I was going to suggest that you might (not) want to try my Bumble Bee show with the various versions of PTE. It is available at the Cottage.

It is 257 images in just over a minute, all cuts. Images are quite small, less than 50kb and 800x600pixels

Not sure if this would help the cause or not, just a suggestion

[Igor]

Thanks for your testings!

So I'll return previous way to run Preview of presentation.

About timing when running produced .exe file.

I just sent you new special test version of PTE please try with it.

And also I've attached my test example where I check up exactness of synchronization. In this show on 4rd second it will be shown black screen and silence moment in the music (exactly simultaneously).

Please let me know about results!

[HaroldB]

Igor,

I sent you an email describing my test results. Better, but still not quite there.

And Jim, thanks. I was actually wondering about your bumble bee show, but if I recall correctly, thatis not synched.

Harold

[Igor]

Dear Harold,

Please resend your letter again. It didn't arrive yet.

[HaroldB]

I figured if my email was taking more than an hour and a half, I'd bore everybody else and just post it here:

Igor,

The "special version" *is* better, but still not quite right.

I opened the music file that you sent me in CoolEdit, and it shows the silence beginning at 4.208 seconds. You named the file "silence_at_4-183" -- does that mean that the silence is supposed to be at 4.183 seconds? The difference is .025 seconds, but my tests indicate that my show is off substantially more than that.

What I can do, if you want, is email you the music (it's 3883K) and the piece of the PTE file that shows the timings in my show. You can then put in thirty or so pictures of your own choosing, and you can see the difference very clearly when you look carefully at slide 28. The other slides in this segment are also slightly off, but it seems easier to see in slide 28, where even the little preview box in the synch window is visibly off.

Does your email allow you to get something that big?

Harold

[Igor]

Yes, I've just sent you email with details.

p.s. silence place begins starting from 4.183 sec. when I composed this file in Ahead Nero WaveEditor.

[cici]

Hi Igor,

Hi Herald

I made a test with my “COLOURS” project as I used in this show many cuts.

I tested it with beta 6 and beta7.

In Preview mode I noticed some delay during many “cuts” transitions.

When viewing in time line (Little window) I noticed that the whole music track (MP3 /128 Kb sec) was playing just about 2.5/10th seconds ahead!

Of course, in “preview “it is difficult to notice the small delay during the long “fade in/out” transitions, but it exists. And just because of the regularity of the delay, some “cut” transitions appear to be synched at the right time but they are not.

I made a test with the “beta 7 version with old way of running Preview: the result is much better but not perfect (referred to the original project).

Hope it helps.

Igor

I take the opportunity, as I couldn’t do before, to thank you very much for your last improvements to PicturesToExe.

Now it will be much easier to synchronize a show like COLOURS, and you can hear the difference between old and new player. I’m sure that with all the improvement you intend to bring to it, your program will be a very, very important working tool. A toast to PicturesToExe

[JRR]

And Jim, thanks.  I was actually wondering about your bumble bee show, but if I recall correctly, thatis not synched.

Harold:

It is not important in the scheme of things, but

Bumble Bees is synched, I did click the new transitions in by hand, but the beat is so fast that it is not properly "synched" to the music.

Anyway, sounds like you and Igor are working out the issues.

Great !!!

[HaroldB]

When viewing  in time line  (Little window) I noticed  that the whole music track  (MP3 /128 Kb sec)  was playing just about 2.5/10th seconds ahead!

Sam,

<nodding> Yes.... that's about what it seems to be off for me, too.

Harold

[HaroldB]

Yes, I've just sent you email with details.

p.s. silence place begins starting from 4.183 sec. when I composed this file in Ahead Nero WaveEditor.

Igor,

I sent you the music file with details via email.

In CoolEdit, I discovered that each time I save an MP3 file, it adds .027 seconds of silence to the beginning of the file. Is it possible that the Nero program you spoke of does the same thing and you saved it once more than you thought you saved it?

Try opening the current file in Nero and look at the waveforms. Is silence at 4.183 or 4.208?

When I create a soundtrack for PTE, I build the soundtrack and then save it in CoolEdit. Then I open it again (now looking at the file with the extra .027 seconds) and use those timings to input to PTE. Up till now, it has worked perfectly.

BTW, I keep track of exactly what I have done in CoolEdit to build the sound file, and if I need to recreate it, I always do it from scratch again. In addition to only needing to figure in one .027 silence at the beginning of the file, this also ensures a sound file of the best quality.

Harold

[Igor]

Thank you, Harold!

I just received mp3 file and list of time points.

You was right, I also noticed small (about 70 ms.) delay in current betas of v4.10. Only with your wonderful mp3 file and quick transitions without effects it shown this difference on the border of senses!

It can be easily fixed, if this delay is constant and I just will add time correction.

[Igor]

Harold, I very grateful for your help in reaching of high exactly timing!

Here is PTE v4.10 beta #8a which should fixes that time delay:

http://www.wnsoft.com/apr_beta1.zip

p.s. I couldn't see that difference earlier because my LCD Sony M51 has real refresh every 50 ms. And it was needed to test it on 100 Hz's CRT display (10 ms.).

[HaroldB]

Igor,

Great work!

The new beta now works perfectly for every presentation but this one. On this particular very demanding presentation, it seems to be just the TINIEST bit off when compared with 4.00, needing a tiny bit more of push in the direction you pushed it in to create this beta.

I don't know what you changed to get it this good. But if you shifted it 70ms, I'd suggest trying an extra 7ms shift. Similarly if you shifted it 200ms, I might try an extra 15 or 20ms.

To me, it's actually "acceptable" the way it is now, even for this presentation. But I think it may need just the slightest tweka to be totally perfect.

Great work!

I watched a number of my presentations with this new beta, and I noticed that one presentation that used to play flawlessly now "glitches" in one place because of the transition/duration time problem that we've talked about in the past. Apparently, 4.10 is just a tiny bit more demanding, and that makes this particular presentation now "glitch" where it used to work before. This is not a problem, since I can decrease the transition time by 200ms without any problem in this presentation, but I just wanted to say that it would be good if you could fix the "glitch" problem related to transition times versus durations once and for all. Maybe in 4.2 ?

Harold

[JRR]

From Igor's posting of July 23 (2:18 on my screen) (I couldn't get the quote to work)

It can be easily fixed, if this delay is constant and I just will add time correction.

I use COOL EDIT and did not know about this time addition in conversion to MP3 - thanks Harold

BUT I am not sure Igor should build in the delay as not everyone uses COOL EDIT and will not have this delay.

I still use Accoustica and dBpowerAMP from time to time for various reasons. I know to check, and correct for, Accoustica adding up to 1 second when converting to MP3. I have not noticed a delay with dBpowerAMP.

I would rather be aware of the delay bulit in and each of us correct in our sound software.

Two other choices would be:

1. All PTE users are given a copy of COOL EDIT to use.

2. PTE build the sound mixer into the PTE software as ADOBE Premiere does.

Of course there are "minor" cost implcations.......

[Igor]

Please, don't worry!

That delay in previous betas didn't depend on CoolEdit or another sound editors. It was a simple mistake in calculating of real position of playback. Delay was exactly 100 ms. (1/10 of second) from real playback.

So now v4.10 beta #8a and v4.01 (or 3.80) have exactly similar timing.

Also this beta contains a little optimization in the music player. So it takes lesser of CPU resources.

To Harold:

Yes, you could fix that problem if move every transition point to the left on 100 ms. But now it's not necessary to correct presentations created in previous versions of PTE.

About glitch in another presentation. Was it glitch in music playback or just slide had not enough time to be calculated and shown? You can test with WAV music file. If it solves the problem then it's because new music player takes more CPU load.

[HaroldB]

I am not sure Igor should build in the delay as not everyone uses COOL EDIT and will not have this delay.

Jim,

I did not meant to suggest that Igor build in an adjustment for CoolEdit. That adjustment came up in a discussion of a sample file he sent me, where we seemed to be off by .025 seconds.... and that made me think of the CoolEdit addition of .027 seconds. It was about the sample sound file, not about PTE.

So we are all on the same wavelength.

Harold