sanewcomb

Audio Format My main point is it shouldn't resample the audio if the audio file is already in 48 kHz. An option wouldn't be of much use since most people wouldn't understand the difference. Just trying to preserve the best quality for those who rip their CDs in 48 kHz and use the templates. For people using the Create Custom, they can set it to 48 kHz already. You could have P2E check the sampling rate of the audio file(s) and, if they are in 48 kHz format already, don't convert them to 44 kHz. Added Numbers to AVI Filenames I don't understand this. I have Ulead DVD Movie Factory 2se, and it uses filenames in whatever form I use. It creates DVD files in all 3 of the following ways. Slideshow name is Sample.pte ONE 1. Press Video> Create AVI (DVD template checked) 2. Dialog box shows Sample_vid 3. Press Save 4. A file is created called Sample_vidxxx.avi 5. This is the filename I load into Movie Factory, and it automatically becomes the title of the video 6. makes DVD fine TWO 1. Press Video> Create AVI (Create Custom checked) 2. Dialog box shows Sample_vid 3. Press Save 4. A file is created called Sample_vid.avi (no random numbers) 5. This is the filename I load into Movie Factory, and it automatically becomes the title of the video 6. makes DVD fine (I can also remove the _vid in step 2 and it makes it fine.) THREE 1. Press Video> Create AVI (DVD template checked) 2. Dialog box shows Sample_vid 3. Press Save 4. A file is created called Sample_vidxxx.avi 5. I rename this file Sample.avi with Windows Explorer 6. This is the filename I load into Movie Factory, and it automatically becomes the title of the video 7. makes DVD fine So, I don't see any of the problems you are talking about. Or I don't understand the problems. But I can create a DVD with no errors even when I use Windows Explorer to rename the proprietary AVI file half way through the process and using the Ulead product. Steve Tucson, AZ USA

Background Music for Show Dialog Box Project Options > Music Tab On my display, the window showing the list of music files clips or crops the filenames, even though there is a scroll bar. I can't read the full filenames. Seems like the calculation for the window involving the font isn't correct. Windows XP Home NVidia GForce 6600 GT 1024x768x32 Windows and buttons: Windows XP style Font size: Large Fonts Steve Tucson, AZ USA

Issues Concerning AVI Output First I want state the current implementation is very good and it is not too difficult to get a working DVD movie slideshow if you directly use one of the DVD Authoring programs that has a template. Audio Format The DVD standard requires all audio to be sampled at 48 kHz (with one exception). It allows several different formats, one of which must be either PCM (uncompressed) or AC-3 (NTSC) /MPEG-1 Layer II (PAL). P2E's templates produce 44.1 kHz PCM audio files, even when the input is a 48 kHz PCM file. It should produce 48 kHz PCM files. Even if the DVD Authoring program compresses it to AC-3, outputting to 48 kHZ would avoid degradation caused by resampling. Users that want to maintain the highest audio quality should rip their original CDs to 48 kHz WAV (same format as PCM) files. Added Numbers to AVI Filenames I noticed that P2E adds what seems to be random numbers to the filenames when using the predefined settings (VCD, SVCD, DVD...). This is unexpected since the program prompts for a filename before creating the proprietary (temp) AVI file. It causes problems for users who want the DVD Authoring program to use the filenames as names in their menus. Is there a purpose for this? If a filename already exists, won't Windows alert the user and prompt for a different name (which would be the desired case for people using filenames in menus)? Interlaced vs. Progressive I'm confused about these settings with respect to settings in the encoding software (DVD Authoring program or MPEG encoding software). Is P2E passing on a request to the 3rd party encoders, or is the output of P2E itself interlaced/progressive? Knowing what is actually happening will help users who manually set parameters in P2E as well as 3rd party encoding programs. Steve Tucson, AZ USA

This version of your beta does eliminate the difference between the editing window view (by moving blue arrow) and preview/created slideshow in Lin's original slideshow post. Thank you for your reply. Steve Tucson, AZ USA

Igor, This question is still unanswered, "Why is the preview/create output different than the editing window (blue arrow) output?" It's not a visual problem. The output really is different. Since the preceision of the slideshow depends on the engine creating what is shown in the editing window, it seems like a pretty important issue. Your solution would also restrict all cyclical effects (motions reoccurring over and over) to have the same periodicity, so that at the end of their cycle they all are in the same position and orientation as the start. I'm not sure how important the second issue is overall to P2E, but the first one will likely cause other problems, and problems difficult to figure out, in slideshows involving multiple effects. Steve Tucson, AZ USA

The developers should consider looking into/reworking the registation system. When I registered a few months ago the key did not come attached to the email. It had been incorporated into the text of the email at the bottom. However, several characters had been dropped off so the key could not be registered properly. I had to add the characters back myself to get it to work. Was using a POP3 email server and Eudora client. This type of out of box experience should be avoided. Steve Tucson, AZ USA

Thanks Igor. I'm glad to hear the program will be making internal checks on the requirements and avoiding crashes. One of the difficulties in evaluating beta software is not knowing what the developers are (and have already done) behind the scenes. Cheers, Steve Tucson, AZ USA

Thanks Ken and Lin. Your answers beg another question that has been in the back of my mind. Since P2E relies on running an EXE file, it is a potential path to spreading viruses. Has there been any consideration to putting some kind of checksum routine to verify the file initially created by P2E is the same file at a later time (Igor?). It doesn't seem too hard to imagine someone with a lot of slideshow EXE files on their harddisk getting an infection, which then infects the slideshows, followed by sending these on when sharing the EXE files with friends. If P2E had a way of checking itself before running, it would reduce the chance of a virus infecting another computer. It certainly is a concern of many people to download an EXE file and run it. Putting it in a ZIP file doesn't prevent an infected EXE file from being transferred to another computer, although it may (I'm not sure) prevent an infection occurring while sitting on a server waiting to be shared. I'm not questioning the use of EXE files as I understand it is what allows the high quality. Just pointing out it does limit the distribution of slideshows somewhat as some people just will not run EXE files (or EXE files contained in ZIP files) they receive in their inboxes. If it checked itself, it would at least give users of P2E confidence if they send out an infected file, it won't infect the receiver's computer. Steve Tucson, AZ USA

Check for Hardware and Software Requirements If it wouldn't add much overhead, I think a check for hardware (primarily the 32MB Video RAM requirement, possibly others) and software (minimum DirectX installed) would be preferred over program crashes and error messages. The aim being reducing the frustration users will encounter when they try to share their slideshows. The following is what actually happened to me recently. After spending many hours crafting and perfecting a beautiful slideshow I emailed my friend with a link to the file. Her first email stated "It downloaded and opened but I just saw some blue boxes with file names real big floating around the screen and there was music. Then it said it encountered an error and had to close." This description didn't tell me what might be going on. Thinking it was probably related to having an old version of DirectX I emailed and asked her to run dxdiag on her machine and email me the results. I also asked her to redownload the slideshow in case the download got messed up somehow. Her second email said "I checked and I have Direct X 9.0c. It appears the entire 14.1 Mb downloaded. Like I said when i try to run it I get the music and a floating (in and out) and at angles, blue box that says Image Load Error: and then the file path for the picture ( like best/blackcanyon/....) Its weird. Maybe I don't have the right graphics?" This puzzled me, but then I remembered there were some minimum requirements for the video card. After searching the forum and finding a minimum of 32 MB Video RAM for PZR effects, I emailed her again trying to describe how she could check the amount of Video RAM. Her third email said "Well, the mystery is solved. I only have 16 MB approximate total memory under the Display tab The point I'm trying to make is tracking down the problem took considerable effort between two people pretty well versed with computers. I can't imagine trying to go through this with grandma or a tech-challenged person. If the program could check for the most likely to cause fatal errors before it runs the slideshow (or perhaps an exit note), I think it would save a lot of users and their friends frustration tracking down why it doesn't work. Plus, it really is bad coding ethic to have your program crash. It should either check for resources it needs to run ("This program requires DirectX 8.x or better....") or have error checking to prevent crashes. To clarify, I'm not asking for a complete system analysis to see if the slideshow will run well on any given computer. I'm talking about checking for critical resources that, if not installed on the machine, leads to P2E crashing. Steve Tucson, AZ USA edit: This was suppose to be posted to the beta #4 thread - sorry

EXE or ZIP I've noticed that many P2E users are posting their finished slideshows as archived ZIP files instead of the uncompressed EXE file. Aside from the nominal (small) amount of size savings, is there any other reason not to use the EXE file on web servers to share with others? I've tried it both ways and seems to work the same on the few computers I have to try it on. For me, I'd rather spend a few extra % in file size to save others the added step of uncompressing the slideshow before viewing. And it is a potential barrier (if a computer doesn't have ZIP decompression software) to viewing the slideshows on public computers found in libraries, etc. Just wanted to know if there were possible problems with using EXE files for web distribution that others had experienced. Thanks Steve Tucson, AZ

Tom, As Lin said the temporary file created by P2E is not an AVI file. I believe it has that extension so 3rd party video software can find and import it easily. They have used a very unconventional method to get the frames output directly from P2E to encoding softwere, but it provides uncompressed frames with virtually no (perhaps none) hard disk space used. Very impressive. More on this in a future post to the video topic forum. Andreas, P2E uses existing CODECs (COmpression-DECompression) installed on the particular computer it is running. So you may get very different results if you don't have the same 3rd party video software and CODECs installed on both machines. Windows comes with some basic ones, and as you install video related programs they add CODECs to your system. Lin, Thanks for the explanations. I'm still trying to figure out how to make the best quality end result, but it looks like creating an actual AVI file (unless it's uncompressed) will add a decompression-compression cycle to the process. Maybe it wouldn't make much visual difference in practice, but some data (quality) would be lost. More on this in a bit. I don't have enough slideshows to fill a DVD yet, but I'm curious to see if I can run that many copies of P2E at once! Thanks, Steve Tucson, AZ USA

WNSOFT development team, I'm impressed with the results of your AVI output work. Good job. Here are some early observations. 1. No matter what quality selection I make (VCD,SVCD,DVD,HD-1080, custom) the output file sizes are identical. Some tag in the AVI is changed to correspond to the desired output dimensions, but the actual dimensions of the frames must be the same for all of them to produce identical file sizes on the hard disk. 2. The Pan and Zoom show up nicely on the TV after the DVD is burned, but Rotations were not as smooth. The degradation was much worse on the TV played by a home DVD player than playing the DVD with a software player (ULead) on the computer. It appears to be related to the specific decoders on these two devices, since the frames in the files are identicle (same DVD used). I don't consider this a fault with the P2E software, although perhaps a better understanding of how decoders works would lead to a more satisfying result on the TV. I'm curious what other people are seeing on their TV sets using home DVD players with regards to Rotations. 3. I don't understand the purpose of creating a temporary only AVI output file. Being able to run through a list of slideshows making corresponding permament files would be easier in the DVD creation process than running 5,6,10 copies of P2E at once. Overall very nice. You overcame my doubts that the huge amount of bits coming out of the video card's GPU could be adaquately represented in much smaller video standards formats. Steve Tucson, AZ USA

Lin, I don't think it's the psychological issue in this case, but it may be a terminology issue. I have thought about this more and think I understand what is going on. The software emulation of zooming, call it soft-zoom, appears to be the linear interpolation of the PERCENT zoomed parameter. So to go from 100% to 200%, the software goes from 100% to 125% in a quarter of the time, from 100% to 150% in half the time and so on. This does not result in a constant change in the distance between the viewer and image (or rather effective distance since it is all happening on a screen at a fixed distance). And this is not what happens in the real world when you "zoom" something. By zoom I mean change the distance between the object and viewer. Try it with your camera, or better yet a video camera. Hook it up to a monitor and move in and away from a subject. You will see the image on the monitor does not slow down as you get closer to the subject (unless you slow down the camera as you approach). I'm afraid the software programmers that originally started calling the linear interpolation of %zoom scale as linear zoom have confused the situation. Doing this does not result in a constant rate of change (linear) of the image size. To acheive a true constant motion of the image in software requires a non-linear interpolation of the %zoom scale mathematically, or by manipulating (possibly with a linear function) a different image or graphic engine parameter. So what they are calling linear is really non-linear motion. There is often a desire to change the speed at either end of the zoom process to add effect, usually a deceleration (for a soft landing so to speak). Adding even more acceleration (or decleration) to this soft-zoom function still results in non-linear motion, only more of it. And it leaves no term for true constant motion. In an attempt to clear up the confusion with the term linear, I would like to suggest a different term to mean a constant rate of zoom in real terms (not percent scale). It could be "constant zoom" or "steady zoom". It would mean the effective distance from the image to the viewer would change at a constant rate and would be very useful in zooming a series of images as well as offering a real life zoom to the software package. I don't know how a rostrum camera is actually used, but I think many of the zooms you see between pictures are done with a constant speed, whereas the ones that zoom to (or from) a stop use deceleration (acceleration) to avoid abrupt stops (starts). Steve P.S. I think you've got the psychological effect reversed. When you are close to a subject (while it appears large) and move away at a constant speed, it appears to be moving away faster than when, at some time later and it is quite small, it appears almost motionless on the horizon, even though you are still moving away from it at a constant speed. If the same effect were in play with the soft-zoom process, the "farther" the image got from you (zooming out) the slower it would appear to move (or change size), but the opposite is observed.

Possible Bug in Ordering and Interdependence of Objects Thanks for your reply Al. It is not a result of the project parameters. In trying to reproduce it with your file I discovered what was happening. Not all of the settings of the parent are passed/connected to the child. In this case, Opacity of the child is independent of the parent. I'm not sure if this is intended or not, but it goes against the conceptional idea of object inheritance. This can cause confusion and lead to unintended results. Looking at the other settings: Inherited by Child Pan Rotate Zoom Not Inherited by Child Opacity Center A case could be made either way for Opacity, but it's hard to understand (for me anyway) why the Center setting shouldn't be inherited. Ideally the child should inherit the state the parent is when the child is created and have an option of overriding if desired. There are pros and cons to how it should be setup, but whatever is decided it should be spelled out in the docs/tutorials if only some settings are inherited. Steve

Possible Bug in Ordering and Interdependence of Objects When zooming out of a slide containing several objects, one of the objects (text picture) gets displaced to the visible screen even though it is a child of an image object and located on this object off the screen. When it zooms out far enough to become visible on the screen it instantly "pops" from the displaced location to where it is suppose to be. It appears to me that it is a problem in the dependence of objects (for awhile the text picture object seems to be on the top level, then becomes the child when it comes into view). I don't know if anyone else has seen this effect and I'm sorry if it has already been addressed. I don't follow all the threads as closely as others. Will send the pte file to Igor since it's hard to describe. Steve

Linearity of Zoom Feature Is the Zoom feature suppose to be linear? To me this would mean it would move towards or away from the picture at a constant speed. Thinking in terms of the mechanical rostrum cameras, when the camera moves towards the photograph it would move at a constant speed. The Zoom in P2E appears to be non-linear, accelerating when moving away from the image (and decelerating when moving in). I was wondering if this is what is intended. It makes it difficult to zoom out of consecutive images (think Google Earth) with either a seamless transition or a sense of continuous motion. While I can see the deceleration (or acceleration) useful in some instances, I find myself wanting to maintain a constant sense of motion in many of my zooms (independent of the transition problem mentioned above). Often the image is zooming too fast by the end of the slide. If it is suppose to be linear, I think the math/equations need to be looked at again. If not, I would find a linear option very useful. It would be nice to have three options. Linear Decelerating In (current form) Decelerating Out (reverse of current) To see the magnitude of this effect, just exaggerate a zoom from 100 to 800 for any picture and notice how slow it gets towards the end of the slide. I think it is more perceptible going in than out, but can be seen in either direction. Steve

Also you can use programs to record whatever your soundcard is "hearing" and save them as sound files on your computer. One program that does this is Audacity, often mentioned on this board as an excellent sound editing program. Just tune into your favorite internet radio station and start recording. The quality is not the same as a CD, but I think it works fine for most computer speaker systems. Also give credit to the musicians so if people like what they hear they can seek out further information/purchases. http://audacity.sourceforge.net/ Tune into your favorite radio station, set the input to Stereo Mix, which appears as a drop down list in the middle) and press record. Cheers Steve Tucson, AZ

Will DirectX 9.0c the minimum DirectX version required to run P2E ver 5.0? If not, what will be the minimum? Steve

PTEShow_H ran smoothly except for a few jitters at the beginning and when the white bordered photos came on the screen. Ran better than orginal PTEShow, which had more and bigger jitters. Music fine on both. Pentium III 600 MHz with 256MB RAM running MS Windows 98 4.10.1998 DirectX 9.0 with a NVidia GeForce4 Ti 4200 w/64MB video card. Steve

UPDATE It turns out this machine had Version 5 of DirectX installed, the version I believe came with the Win98 put on the computer. When upgraded to the current version of DirectX for Win98 from Microsoft's site the errors were gone. It plays the PTEShow demo pretty well with some jitters now and then. Upgrading DirectX was not a simple process though. The viewer probably should check the DirectX version before attempting to run if it has a minimum requirement. Steve

My comment was aimed at a number of posts that indicate some people think there will be a button to produce an AVI that can be burned to a DVD or posted on a webpage with the same quality that they see on the computer screen. I don't think this is possible at the moment for a number of technical reasons, but as I wrote I will be pleased to be surprised if it is. My reading of the "PicturesToExe v5.00 beta #2, Announcement" post is that the program will choose which engine is engaged. If the slideshow has any pan/zoom/rotate in it, it will use the new engine. There will not be a choice to save such a slideshow in the old format, which makes sense. There will most likely be a save to AVI feature for the new engine, but it remains to be seen what quality, performance and file size such slideshows will be. I am personally looking for a way to create slideshows that I can post to my hiking group list that has some pan and zoom effects. I have no control over what machine people will use and want as many people as possible to see them, and as easily as possible. At the moment a product like JAlbum works well for this purpose, but does not have those effects. No doubt this version of P2E is way beyond everyone else in quality and performance running as an app on a Windows machine with a good video card. I'll certainly use it for my own slideshows. Steve P.S. Lin, I came across your site and forum a little while ago and found it very well written and useful. Thank you for your insights and helpful comments.

I know this is beta software, but wanted to remind people they should exercise care in running it and who they send beta made slideshows to. Beta #2 caused critical errors on two of my machines. ERROR #1 Frozen mouse while running P2E 5.0 beta #2 and editing a slideshow. This was on an Win XP SP 1 machine, Athlon XP 2000, 1 GB RAM, and GForce 6600 GT w/128 MB. Mouse Pointer was frozen on screen and all mouse functions were lost, even after P2E was closed. Mouse function did not return until reboot. This has never happened on this machine in 3 years of use, including writing code. ERROR #2 All slideshows created by either beta program crash on a Pentium II with 256MB RAM running MS Windows 98 4.10.1998 with a NVidia GeForce4 Ti 4200 video card. I don't know if ver. 5 is suppose to run on Win 9x, but I couldn't find any OS limitations and ver 4 works on Win 9x. Details of these errors have been emailed to the developers. I am as impressed as others with how well the program/engine performs the pan and zoom effect. As Igor has written, it takes advantage of calls to the video GPU and/or video subsystem directly like video games (I apologize if the terminology is incorrect). But this also makes errors potentially catastrophic, bringing down the entire OS. So take care in running the betas and avoid doing it when running important tasks (other than beta testing P2E 5.0 I wish the best of luck to Igor and his team in eliminiting all bugs and making the code not only leak tight, but "air tight"! I'll continue sending errors that I see to further this effort. Steve P.S. On a related note, I would think this approach will lead to a narrower target market. Not only are other OSs excluded and a steeper hardware requirement, but I think it will be difficult to make AVI files from these slideshows. The advantages gained by making direct calls to the video system are not easily captured by video movie standards. Video games require running the game engine to replicate game demos or "game movies". But Igor & Co. has surprised everyone with this effort so far. Look forward to more surprises.