Igor

I grateful you! Good idea, I'll think how it can be done. p.s. also I've added in the next beta ability to run Ext. application after last slide. E.g. to make possible creating of sequence of sync'ed presentations.

Harold, Ok, please don't worry! I'll work until the problem not fully fixed. Al, Is the difference between timing in v4.01 and v4.10 beta #8 with this mp3 file? p.s. thank you all very much! We'll continue work to make music player with excellent playback.

Thank you, Ray! Very interesting! I've tried on our special test PC (PI-233, 64 MB, Win95) and playback is excellent on the time-line (7 Mb not-VBR mp3 file). There are no pauses. Please can you try with absolutely another mp3 files (2 or 3 Mb)? By the way, was that mp3 file VBR or with constant bitrate?

Dear Harold, I just tried, but I couldn't sense 50 ms. difference. You have absolute pitch, by the way! But I'm afraid to add this correction. Maybe it better if I add special function which you can call anytime and shift all transition points to the left or right on necessary value of milliseconds? This may help as in your case when highly-exactly synchronized show was created in previous versions of PTE and if some mp3 playback need be a little corrected in v4.10? I suppose it can be a little difference (20-50ms.) in reference point in various music players when they start time reckoning. And it is NOT accumulating mistake. So shift may help, if creator see small difference. And NO PROBLEM at all, if presentation is creating ALREADY in v4.10 with new music player. Because creator adjusts time points according playback of the new music player.

Dear Guido, It seems to me that he've wrote me several months ago, and we've fixed bug of v4.01/3.80 when time-line was not able to display length of music track(s) more than 60 minutes. v4.10 beta fixes this problem. Thanks,

Thanks, I'll wait for the result when there are no transition points. 1) So no problem at all in produced presentations and music DOESN'T pauses? The problem only with time-line? 3) Will the problem occurs with WAV music file (not mp3)? p.s. please make sure that your build is "PicturesToExe v4.10 beta #8 - Your project name" (in the caption of the main window).

Dear Ray, Thanks for letting me know about this difficulty! Please let me know: 1) Was there similar problem with previous versions (4.01 or 3.80) of PTE? 2) Will this problem occurs if you temporary remove all transition points and then click Play button? 3) What usual size (of files in KB and width/height) of pictures? 4) Did you hear pauses in the music playback when cursor goes back or pauses on the time-line? (Thanks Al for last two questions!). 5) Will the problem also occurs with another mp3 file?

Anyway, in the new presentations will be no problem at all! Because we already create timing in the new music player

After I've added that time correction (100 ms.) in the beta #8 with your help, I see no difference between v4.10 and v4.01/3.80 more. Just for test you can try move several transition to the left on 20 ms. It will not take visual difference.

Just I thoughted that it better to don't change more, because this more frequent query of current position takes much higher CPU load (on 10% under Athlon 1600) in the Cust. synch. window. And possible another untested nuances.

Ok, I won't change anything in timing more. Will leave as in beta #8 Thank you all for testings!

I just prepared two new test versions. Harold and Cici please try out: http://www.wnsoft.com/apr_beta_FastTimer_100ms.zip http://www.wnsoft.com/apr_beta_FastTimer_50ms.zip Both variants in 2 times more often check up current position of playback (even much better than v4.01 or 3.80). First variant has 100 ms. time compensation (as Harold tested with beta #8). Second has 50 ms. time compensation. Which variant will provide more exact timing as in v4.01? p.s. interesting moment. Compare how smoothly (in both betas) cursor runs on the time-line under Windows 98/Me than earlier before.

1) Is this delay for one slide or for all slides? 2) How it will work in v3.80 or v4.01? 3) Please make sure again that you really re-compiled the show in v4.10 beta #8. You can compare with beta #7 where there is a delay in 100 ms.

Beta #8 contains fix when time points composed in v4.01 or v3.80 were processed on 100 ms. later than it's necessary in v4.10 beta #1-#7. About moment between two files of music tracks. It possible very small pause in transition effects at this moment. Because CPU tries to quickly process opening of a new sound track. Here v4.10 works as v4.01, as I tested. Please let me know if it is not so!

Thanks for your various suggestions on improvements of PTE! We plan add many improvements to the Vis. editor in the next version. Also in the next version I think to make possible pause and full control on presentation in the synchronized mode, including access to objects.

Really that problem happens only for synchronized show when intervals (not including the time for transition effects) between slides lesser than 500 ms. So, e.g. 1,5 sec. for the effect and 1 sec. for show of a slide are enough for *all* PCs. It's not easy to realize such system for analyzing of situation. We can't determine exact time of preparing of next slide, because it depends on size of a picture, type of transition effect. I need to think about this.

PicturesToExe v4.10 beta #8 is released http://www.wnsoft.com/apr/apr_beta.zip (1.3 Mb) What's new in this beta: * Fixed bug with 100 ms' delay of slides in synchronized presentations created in previous versions of PicturesToExe. The problem is fixed now. + Added optimization to the new music player. It takes lesser CPU usage. p.s. also please let me know how new very important feature of v4.10 works (Instant start of presentation, even with large mp3 files).

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.

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.).

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.

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.

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

Really 99,99% of users needn't never disquiet about this limitation! All things have own limitations. For example, Windows also may fall if you open 200 or 300 applications. Or if we add high-resolution (5000x3000) pictures it will vastly slow down the show of slides About GDI resources (graphical resources - this is Microsoft's technology). Windows NT, 2000 or XP have in 10 times more GDI resources for applications than under Windows 95,98 or Me. You can watch this limit ("Canvas doesn't allow drawing") under Windows 98 when run many (10-20) applications with complex interface. Each picture, or button, or label, or checkbox takes 1 or 2 GDI resources. So you can calculate how many GDI resources take one *visible* window of some program One photo or background picture (even very large!) takes ONLY 1 GDI resource. Usual application uses 150..350 GDI resources. For example MS Word - 140, Media Player 8 - 343, Photoshop 7 - 242. Concerning PTE. PicturesToExe uses 192 GDI resources. And I'm glad to say that usual produced presentation takes only 60-70 GDI resources during all time of show! And it can be 100 Mb show with long mp3 music, and 10000 of slides and 10-20 objects per *each* slide. So please forgive about some limitations. It doesn't matter. p.s. of course, we free objects and main picture after show of a slide, because they are not necessary more. Every slide will be prepared dinamically when it's necessary.

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!

Thanks, Bill! There is a limitation in Windows for creating too much graphical objects (simultaneously at one moment). No problem with usual slides (even 100'000 of large pictures), because they are showing one after another. It's quite another matter when you add many small pictures (as objects) into *one* slide. And they all will be displayed together. In your presentation, you've sent me, there are more than 500 small pictures per slide. Each picture (small or very large) requires 2 GDI resources of Windows. So 500 pictures will require 1000 GDI resources. There is no problem when it added 100-200 and maybe 400 sub-pictures in the Visual editor of objects. And greater number may cause the problem. So I see two possible tricks how to solve this limitation. 1) Optimization (in the memory storage) for repeated picture-objects; 2) Or algorithm which will storages many small pictures into one large bitmap (as mosaic). As I said earlier Windows has an interesting mechanism and 100x100 or 1600x1200 picture requires equal number of GDI resources (2 GDI per bitmap). But both variants require many changes and even not one week of work, unfortunately.