Why does music play differently on two machines?

[CharlesSeymourJr]

Having set up a slideshow on my editing computer and then transferring it to my laptop for playback, I noticed that the music played differently. Musical passages that used to be timed well to individual slides no longer is.

The music is NOT timed and is set to play freely (one time through, only), but it is playing differently on the laptop than on the editing machine.

The editing computer is a P4, 2.0 Ghz with 1 GB of memory. The laptop is a P4, 2.0 Ghz with 512 of memory.

The slideshow I have set up uses two mp3 files. The first one seems to start when it is supposed to, but I can't understand why they don't finish at the same time.

Any thoughts?

Charlie Seymour, Jr.

Outside Philadelphia, PA, USA

[Guest guru]

Hi Charlie!

I had made several tests about this issue before Igor added the time-line. Some little difference can be noticed also on the same machine. This depends by many factors, like the number of open applications, programs running in background, active threads etc.

Therefore it's quite normal some differences in timing can be noticed on two different computers, even if they are seemingly very similar.

[LumenLux]

And should we add - it may not be the music which is playing differently, but actually the slides appearing differently relative to the steady music?

[Guest guru]

Sure Bob, it's not the music what changes, but the presentation time, that is the slides total duration!

[CharlesSeymourJr]

Now I'm REALLY confused.

If each slide is timed and each transition too (down to the millisecond), WHY would the slides be playing at a different rate.

I was the first to post. My difficulty comes from my desk model to my laptop, where the show finished early, with music still to play.

Though I have not synced my slides and music, I thought the timing of the slides would stay as I programmed them to be.

NO?

[think(box)]

Charles, I previously wrote about timing variation, quoted here. I've added a machine speed example to the previous text, in brackets:

I have noticed the same and characterize P2E behavior as follows:

When you set a simple display interval and for this example have transition effects disabled, the way P2E works is it takes an unaccounted-for period of time to load and decompress a photo, and then it starts the clock for the next. Example timing:

Modestly well sized, relatively high resolution JPEG file load and decompress time: 0.3 seconds

Time value entered for display per slide: 1.0 second.

Net interval realized during show playback: 1.3 seconds

Then if you read the photo from CD-ROM the longer access time to just get the JPEG file from CD could result in a net interval of 2.0 seconds, even though you chose 1.0 second.  [ If the CD-ROM drive has stopped spinning during long display intervals, this will make timing more inaccurate. ]

[ Or if you run show on a different machine that has twice the processing speed the unaccounted for load and decompress time can be 0.15 seconds, such that actual display interval is 1.15 seconds per picture ]

PTE could be modified to keep track of the actual time-of-day elapsing, such that it could give you precisely the interval requested (Igor, please!) but it won't always work. For example if it takes longer to read in and decompress photos back-to-back than your chosen interval, then either the interval would have to be missed or some photos would have to be skipped. I prefer the former of those choices. Someone else may say show timing is paramount and insist on the latter (or both options).

The bottom line for P2E shows through V4.01 is:

Synchronized show Music playback is timed precisely to show. If you attempt to display photos at a rate faster than machine can handle, then skipping occurs. You have to create shows for the viewing audience's slowest computer. This entails limiting image resolution to 800x600 (best) or 1024x768 (next best), and keeping display time per picture and fade interval (if used) not excessively demanding, or fast.

Unsynchronized show Timing is approximate, since actual clock time is not used for 100% of the timing constructs that dictate show timing. The software is simply not designed for exact wall-clock timing in unsynchronized show mode.